DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Write Your Good Code First

Write Your Good Code First

James Sugrue user avatar by
James Sugrue
CORE ·
May. 27, 10 · Java Zone · Interview
Like (0)
Save
Tweet
12.73K Views

Join the DZone community and get the full member experience.

Join For Free

Writing good code first is a pretty obvious statement, but I'm not sure if people do this. In fact, I think that we make excuses all the time so that we don't have to.

While catching up on Twitter recently, I checked what @UncleBob (Robert Martin, author of Clean Code) has been saying. Obviously he's a smart guy, as pragamatic as they get, and always has useful insightful things to say. Here's the tweet that caught my attention: 

I'm sure most developers would say that they write good code, always. Think about it? Do you? I know I've definitely compromised my quality standards in the past, deciding that it's better to "fix that later" rather than to get it right first time. The minute you do that, you've broken a window. 

While on this topic of writing good code first, you might wonder where refactoring fits (but I hope that you're not wondering!). Refactoring is inevitable, but what really gets me is when refactoring needs to be put down as a separate task in a project schedule. Looks like UncleBob would agree:

 

So why does it happen?  To me, seeing refactoring in the schedule is an admission that "you're not going to get it right first time, so we'll add in this extra time to fix it later". Surely if there is a concern that the time allocated to a task doesn't cover a complete, clean implementation, the task needs more time. Refactoring is a good thing, but you have to refactor as you go. Don't commit too much code littered with //TODO comments, do it now. 

Having refactor seen as a different task is the same as breaking down each feature into a list of tasks like design, unit test, code, refactor, test. Software developers should know what they need to do in order to produce quality software. The "task" is not just the coding part - it's everything around it. 

 

code style

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Reactive Kafka With Streaming in Spring Boot
  • How To Evaluate Software Quality Assurance Success: KPIs, SLAs, Release Cycles, and Costs
  • SQL vs. NoSQL: Pros and Cons
  • Introduction to JWT (Also JWS, JWE, JWA, JWK)

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo