Core Design Principles for Software Developers by Venkat Subramaniam
Devoxx is a conference directed towards the Java, Android and HTML5 community.
Some points that are language agnostic, and can be applied universally are summarized below:
- Good code can be changed without much hassle.
- It is always impossible to get it right the first time.
- Be unemotional in coding.
- People who are dangerous to work with (So you shouldn’t become them): People who can’t follow instructions, and people who only follow instructions.
- Take time to review code. (You can learn, and you can improve the design)
- Simplicity is hard. Strive to achieve that.
- Simple keeps you focused (Imperative vs Declarative)
- Write code to solve real problems. (Don’t code without knowing what it should do)
- Complexity (Inherent vs Accidental). Inherent Complexity comes from the problem. Accidental Complexity comes from the solution.
- Simple != Familiar (just because you know what it does, doesn’t mean its simple)
- Good Design is one that hides Inherent complexity, and eliminates Accidental Complexity
- YAGNIy (You Aren’t Going To Need It (yet)) Don’t implement things that you don’t need yet. Do the important things first.
- Cost of implementing now > Cost of implementing later = Postpone
- Cost of implementing now = Cost of implementing later = Postpone
- Cost of implementing now < Cost of implementing later = Do it now
- Have a Good Automated Testing. This prevents fear of postponing
- Cohesion is a code that does one thing and one thing only. This makes it easier for change.
- Similar code stays together. Dissimilar code stays away
- Coupling is what you depend on. Try to see if you can remove coupling. (You can’t remove all dependencies, so make them loose)
- Knock out before you Mock out
- Good Design has High Cohesion and Low Coupling
- DRY (Don’t repeat yourself) (Don’t duplicate code, and effort)
- Every piece of knowledge in a system should have a single unambiguous authoritative representation
- CPD (Copy Paste Detector to find duplicated code)
- Don’t write overly long functions and methods
- How long is a long method? SLAP (Single Level of Abstraction Principle)
- SLAP: What was the level of abstraction of your function
- Don’t comment what, comment why
- Open Closed Principle: A software module should be open for extension, but close for modification
- Use DRY and YAGNI often