The article was published on the official website ：CoderMrWu , Share high quality technical articles and experiences every week , Welcome to pay attention , Communicate with each other .
I like to read biographical experience articles recently , Because you can find answers to some of the questions you are going through . Learn from history , That's what it means . Below is a list of self reminders from programmers , Pick some of their own more valuable collation translation to share with you . Good English can read the original text ：Notes to Myself on Software Engineering
About program development
- Code is not just about executing . Code is also a way to communicate across teams , It's a way to describe the solution to a problem to others . Readable code is more than just a good coding habit , It should be the basic requirement for writing code . This includes clear decomposition code 、 Choose meaningful variable names and comment on any implicit code .
- Don't ask what your submitted program will bring to your next marketing campaign , Ask what your program can bring to your user community , Avoid using “ Explicit contributions （conspicuous contribution）” Target . If you can't meet the original design goal of your product , Would rather not add any new features .
- The word taste can also be used to describe code . To satisfy one's taste by satisfying the need for simplicity , This is a constraint satisfaction problem （constraint-satisfaction process）. Keep the paranoid pursuit of simplicity .
- occasionally , When someone asks for a function , It doesn't mean you have to do it , You can say “ No ”. There's a lot more than the original design budget （ Maintenance cost 、 Document cost and user's cognitive cost ） The function of , Now you have to ask “ Do we really need to do this ？”, The answer is often “ No need at all ”.
- When you plan to support a new use case （use case） When asked , Remember not to just implement use case functionality on the surface . User's request , Often from their own special personal point of view . You should consider the whole project architecture and future planning . commonly , The right thing to do is to extend this feature , Instead of simply modifying .
- Put more energy into continuous integration , Strive for more unit test coverage , Make sure you're in a secure coding environment .
- You can't plan everything in advance , Look at the result according to the progress of things . But correct the wrong things in time , Put yourself on the right track .
- Good software , It can make difficult things easy . It seemed difficult at first , It doesn't mean that the solution is difficult or complex . Engineers often use reflection solutions , This tends to complicate the problem （ add to ML、 Building new APP、 Add blockchain ）. When writing any code , Make sure the simplest solution is used . Use the most fundamental 、 The easiest way to deal with problems .
- In the software design process , You should consider the overall impact of the software , It's not just a function module . In addition to monitoring the relevant indicators , Your software to users , And the impact of society ？ Are there any negative effects you don't want to see ？ Can you take some measures to solve these problems ？
Design for ethics. Bake your values into your creations.
About API Design
- Yours API There are also users , There is also a user experience . therefore , When you make any decision , Consider your users . From the user's point of view , Whether they're rookies or experienced veterans .
- Use your API when , Reduce the user's cognitive difficulty as much as possible . Hide the unimportant parts of complexity , Reduce the cost of users . The design follows a simple and consistent mindset and workflow .
- The meaning of parameters should be understood when the context is not understood . Parameters should be related to the user's thinking model of the problem , It should not be about the implementation details of the code .API It should have something to do with the problem solved , It's not about the way the backstage works .
- Good thinking models are modular and hierarchical ： It's simple at the top , But the details are also precise . Again , well API It's also modular and layered ： Easy to implement , But it's expressive .
- Yours API The implementation of is one of your implementation options , Especially data structures , You should choose an intuitive structure that is close to the thinking model of natural experts .
- Design API when , It should be a set of atomic functions . Ensure that the upper use case workflow is satisfied in the simplest way , Not because “ May use ” And add unnecessary features .
- Error message , yes API A feedback from user interaction , Interactivity and feedback are essential .
- Documentation is the user experience API Yes, the core , High quality documentation , It will give users high quality feedback . Your document , You shouldn't talk about how software works , It's about how to use it . More instance code will make the document more friendly 、 practical .
Productivity boils down to high-velocity decision-making and a bias for action.
About career
- The improvement in your career is not how many people you manage , It's about how much influence you have ;
- Software development is a team work ; Social skills are as important as technical skills . Be a good teammate , Keep in good touch with others .
- Technology will never be neutral , When making a choice , There are beneficiaries , There will also be victims . Incorporate your values into the design , Be cautious and clear .
- introspection , It's the key to life satisfaction . Make sure you have a complete grasp of your work and life .
The authors introduce ： Mr. manong Wu , focus python/golang/java/devops Learning experience and resource sharing of other technologies ~ On the way to study , Let's move forward together , Believe in every section of the road , It's all a story ~
