[软科学.程序篇]
40条程序员编程箴言
40 programmers programming proverbs
话说,造物主,一定是个程序员!
1、重构是程序员的主力技能。
1. Refactoring is the main skill of the programmer.
2、工作日志能提升脑容量。
2. Working log can improve brain capacity.
3、先用profiler调查,才有脸谈优化。
3. Use the profiler survey before you can talk about optimization.
4、注释贵精不贵多。杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释,实际就是背景噪音。
4.It is not expensive to comment. Put an end to the aunt's "example". All over the mountains, you can read the notes, which is the background noise.
5、普通程序员+google=超级程序员。
5. Ordinary programmer + google = super programmer.
6、单元测试总是合算的。
6.Unit tests are always cost-effective.
7、不要先写框架再写实现。最好反过来,从原型中提炼框架。
7. Don't write the framework before writing the implementation. It is best to reverse the process and refine the framework from the prototype.
8、代码结构清晰,其它问题都不算事儿。
8, the code structure is clear, other problems are not serious.
9、好的项目作风硬派,一键测试,一键发布,一键部署;烂的项目生性猥琐,口口相传,不立文字,神神秘秘。
9. Good project style hardcore, one key test, one key release, one key deployment; The bad project is obscene, word of mouth, not written, mysterious.
10、编码不要畏惧变化,要拥抱变化。
10.Don't be afraid to change. Embrace change.
11、常充电。程序员只有一种死法:土死的。
11. Often charge. There is only one way for programmers to die: earth to death.
12、编程之事,隔离是方向,起名是关键,测试是主角,调试是补充,版本控制是后悔药。
12. Programming, isolation is the direction, naming is the key, testing is the leading role, debugging is supplementary, version control is the repenting medicine.
13、一行代码一个兵。形成建制才能有战斗力。单位规模不宜过大,千人班,万人排易成万人坑。
13.One line of code a soldier. The formation of a system can be effective. The unit size should not be too large, thousands of classes, 10,000 people easy to become a mass grave.
14、重构/优化/修复Bug,同时只能做一件。
14. Refactoring/optimizing/fixing bugs and doing only one thing at a time.
15、简单模块注意封装,复杂模块注意分层。
15. Simple modules pay attention to encapsulation, and complex modules pay attention to layering.
16、人脑性能有限,整洁胜于杂乱。读不懂的代码,尝试整理下格式;不好用的接口,尝试重新封装下。
16.The human brain is limited in performance and neatness is better than clutter. If you can't read the code, try to arrange the format; Bad interface, try to re-encapsulate.
17、迭代速度决定工作强度。想多快好省,就从简化开发流程,加快迭代速度开始。
17. The iteration speed determines the work intensity. To save more quickly, start by simplifying the development process and speeding up the iteration.
18、忘掉优化写代码。过早优化等同恶意破坏;忘掉代码做优化。优化要基于性能测试,而不是纠结于字里行间。
18.Forget optimizing write code. Premature optimization equals malicious damage; Forget about code optimization. Optimization is based on performance testing, not between the lines.
19、最好的工具是纸笔;其次好的是markdown。
19.The best tool is a pen and paper. The next best thing is markdown.
20、Leader问任务时间,若答不上来,可能是任务拆分还不够细。
20. When the Leader asks for the task time, if not, it may be that the task is not detailed enough.
21、宁可多算一周,不可少估一天。过于“乐观”容易让boss受惊吓。
21.Better a week than a day. Being too "optimistic" tends to scare the boss.
22、最有用的语言是English。其次的可能是Python。
22.The most useful language is English. The second possibility is Python.
23、百闻不如一见。画出结果,一目了然。调试耗时将大大缩短。
23.Seeing is believing. Let me draw the results. Debugging takes a lot of time.
24、资源、代码应一道受版本管理。资源匹配错误远比代码匹配错误更难排查。
24.Resources and code should be managed together. Resource matching errors are far more difficult to troubleshoot than code matching errors.
25、不要基于想象开发, 要基于原型开发。原型的价值是快速验证想法,帮大家节省时间。
25. Do not develop based on imagination, based on prototype development. The value of prototyping is to quickly validate ideas and help you save time.
26、序列化首选明文文本 。诸如二进制、混淆、加密、压缩等等有需要时再加。
26. Serialize the preferred plaintext text. Such as binary, confusion, encryption, compression, and so on.
27、编译器永远比你懂微观优化。只能向它不擅长的方向努力。
27.The compiler is always better than you at microoptimization. You can only work in the direction it is not good at.
28、不要定过大、过远、过细的计划。即使定了也没有用。
28.Don't make plans too big, too far, too thin. It doesn't work even if it's fixed.
29、至少半数时间将花在集成上。时间,时间,时间总是不够。
29.At least half the time will be spent on integration. Time, time, time is not enough.
30、与主流意见/方法/风格/习惯相悖时,先检讨自己最可靠。
30. When contrary to the mainstream opinion/method/style/habit, review yourself first.
31、出现bug主动查,不管是不是你的。这能让你业务能力猛涨、个人形象飙升;如果你的bug被别人揪出来…..呵呵,那你会很被动~≧﹏≦
31. Bug active check, whether it's yours or not. This can make your business skills soar and your personal image soar. If your bug is caught by someone... .. Well, then you will be very passive.
32、不知怎么选技术书时就挑薄的。起码不会太贵,且你能看完。
32.I don't know how to choose a technology book. Not too expensive, at least, and you can read it.
33、git是最棒的。简单,可靠,免费。
33. Git is the best. Simple, reliable, free.
34、仅对“可预测的非理性”抛断言。
34. Only the "predictable irrationality" is claimed.
35、Log要写时间与分类。并且要能重定向输出。
35. Log time and classification. And you want to be able to redirect the output.
36、注释是稍差的文档。更好的是清晰的命名。让代码讲自己的故事。
36.Notes are a slightly worse document. Even better is the clear naming. Let the code tell its own story.
37、造轮子是很好的锻炼方法。前提是你见过别的轮子。
37.Making wheels is a good exercise. The premise is that you've seen other wheels.
38、code review最好以小组/结对的形式。对业务有一定了解,建议会更有价值(但不绝对)。而且不会成为负担。管理员个人review则很容易成team的瓶颈。
38.Code review is best in group/pair form. Be aware of the business, and the recommendations will be more valuable (but not absolute). And it won't be a burden. The administrator's personal review is easily the bottleneck of the team.
39、提问前先做调研。问不到点上既被鄙视,又浪费自己的时间。
39.Do your research before asking questions. I can't ask you to be despised and waste your time.
40、永远别小看程序媛(╯3╰)
40, never look down on luca brasi (╯ 3 ╰)
心智认知实验室
领取专属 10元无门槛券
私享最新 技术干货