Hacker News new | past | comments | ask | show | jobs | submit login

How does one keep these things in practice in the reality of an over-committed software team with shifting priorities, difficulties interfacing with product management, and bad specifications/requirements that eventually result in significant scope creep? I often feel like I want to refactor code, but the cost of doing so is so high that it would slow me down to the point of missing a deadline. "It works" is usually as much as I have time for.

Maybe I'm just not a very good programmer...




Instead of trying to dedicate time specifically to refactor try to clean up classes as you come across them when fixing bugs or adding features.

Whenever I open a file, I try and take a quick glance to see if there's anything that could use refactoring before working on the actual issue (if it's either a particularly large file or one that hasn't been touched in years I'll check Sonar[1]).

[1] http://www.sonarsource.com/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: