Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You're going to get a bunch of extreme platitudes in response to this question.

Like "DRY", "YAGNI", SOLID, short vs. long functions, how to test, minimizing vs. maximizing reuse, static vs. dynamic typing, cyclomatic complexity, interfaces, functional programming, immutability, etc. You should definitely be familiar with these principles and their tradeoffs.

My advice though would be to take them all as suggestions, not absolutes, and to look at your specific requirements of your project, what you know about it and your customers (how it's likely to evolve over time, how it has already evolved, how your company will evolve, who the engineers are, etc.), and then find & adjust the principles that apply. There are no silver bullets here, and which techniques are successful depends very much on the context in which they're used. Work backwards from your team, your situation, and your customers.



I agree with this, but I'd like to add one more thing. No matter what you do, if you find that your code is hard to change, then change it so that it is less hard. Next time you visit it, change it again. Keep doing this until it is very easy to change the code. Write enough test support in your code that you can do this kind of work safely.




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

Search: