Here I usedsmart，lazyandprogrammerThese words. What I mean by these words is:
- Programmer: energetic, focused on using code to solve real-world problems, not referring to those dreamers, those who only think but never do.
- Smart: able to think thoroughly about problems (not those who play petty tricks).
- Lazy: just like lazy-loading in programming, it means delaying the time of writing code (not someone who is idle).
Correct software development should be lazy development, also called patient development; this development style is shown by spending a lot of time before actually writing code to comprehensively consider all possible solutions and approaches. This can be seen asdelayingwriting code, never starting to write code before fully understanding the problem. First understand the problem clearly, make sure the code to be written can truly solve the problem; this will avoid writing a large amount of useless code later.
What is meant here byfirst understanding the problemis reflected in:
- Truly understand the requirements, let the product department (business analysis department) clarify what they really need.
- These departments usually don't give enough time to organize requirements.
- They often don't consult domain experts, but instead defer to the leaders' opinions.
- They are usually unable to provide consistent or complete requirement opinions.
- Be clear about what interactions are needed with other programmers in your team or programmers in other teams, and how to interact. This includes:
- Communicating using a whiteboard
- Drawing flowcharts (UML or Visio)
You need to spend a lot of time researching to make sure the requirements match the reality, and to do work that gives you and your colleagues a common language and semantics for communication. However, programmers all like to rush into programming immediately and like to keep typing code in front of the computer.
In real software development, only 5% of development time is efficient (you can refer to "The Programmer's Development Efficiency Paradox"). If you find a programmer staring at the screen 100% of the time, then this programmer is the worst programmer.
If a programmer is always coding at the computer, this is definitely a bad sign.
Efficient programmers constantly check their understanding of the requirements to ensure their code and requirements arein sync. Efficient programmers communicate frequently with product managers/business people; you can often see them using whiteboards to discuss and exchange ideas with colleagues and architects. The experience and wisdom of programmers are used to improve development efficiency. The best programmers:
- They spend more time thinking about code and less time writing code.
- A thorough understanding of the problem makes debugging faster.
- Code written after careful thought runs faster.
- The code is shorter in length.
Psychologically, programmers all love their own code.
Bad programmers don't like to modify the bad code that has already been written. Rather than optimizing their own code, they prefer to simplyaddmore code to make up for previous defects. What's worse, they like to blame others. In the end, another pile of bad code is added on top of a pile of bad code, and the whole system becomes full of bugs and extremely unstable.
Excellent programmers also often write bad code, but they can see which code needs optimization and which needs rewriting. The difference between excellent and non-excellent programmers lies in their attitude toward problematic code. The excellent programmer's approach is:
- If the code is good overall, refactor it.
- If the code has problems overall, rewrite the code.
When there are places in the code that need optimization or rewriting, the longer you delay, the harder it is to go back and solve these problems. Because the programs that depend on this code will become more and more numerous and deeply dependent. When you optimize this code, the related dependencies also need to be modified accordingly. When accumulated problems grow, it has become impossible to easily optimize/rewrite this code. And using the approach of continually adding code to make up for previous code problems will make the system more and more unstable.
If your mind hasn't thought it through, then be lazier and push the time of writing code later.