程序员优秀之路：一起来看下这 97 位”砖家“能给出啥编程的好建议？（4）

theme: awesome-green

这是我参与8月更文挑战的第4天，活动详情查看：8月更文挑战 本系列共 5 篇，通译自：97-things-every-x-should-know License：由 CC BY-SA 3.0 获得许可； 欢迎点赞、收藏、评论~ O(∩_∩)O

• 本瓜并未逐字逐句翻译，而是取其精要、理解抽象，结合自身进行撰文表达，与各位看官分享。认知好的编程概念，走向优秀~
• 《程序员优秀之路：认知 97 个好的编程概念（1）》
• 《程序员优秀之路：认知 97 个好的编程概念（2）》
• 《程序员优秀之路：认知 97 个好的编程概念（3）》

（痛定思痛，前 3 篇翻译阅读量愈来愈差，每篇 20 小点，通常撰文每小点耗时 10 至 15 min，通篇下来需 3 ~ 5h。时间花费了，但效果甚微，反思这些编程概念、建议点是否过于冗长、空泛，于是转换思路，加大凝练力度，完成大于完美！）

代码告知真相

这位作者想说：

1. 代码才能清楚的告诉别人你的真实意图，需求文档都不一定能说明全部真相；
2. 注释只是辅助功能，别打算用注释来代替代码进行说明；
3. 写代码要像写诗一样，精心去表达；

负责构建

这位作者想说：

1. 项目的构建脚本也要一直去维护；
2. 构建过程应该由研发团队负责，而不是给测试团队或其它“质量保障”团队；
3. 充分了解构建过程，太重要了；结对编程

这位作者想说：

1. 全身心的一人编程很难实现，有太多中断和干扰；
2. 尝试结对编程，促进交流、团队融合，取长补短，共同进步；
3. 结对编程，让新同事快速上手；（真会玩~）精确定义类型

这位作者想说：

1. 举了个真实例子：一个卫星因为程序单位计算错误导致失联；
2. 使用静态类型语言，编译器可以做检查；使用动态类型语言，则依赖单元测试；
3. 精确定义变量的类型（自定义类型），而不仅仅是使用原始类型 String 或 Float 等；避免报错

这位作者想说：

1. 用户错误的使用程序而造成报错，这些情况是能预测，并采取措施进行避免的；
2. 提供有效的提示能避免用户操作报错；
3. 系统需零容忍错误，反思交互，甚至重新设计；

专业程序员

这位作者想说专业程序员：

1. 第一特质是：责任感；
2. 第二特质是：团队合作；
3. 第三特质是：不容忍错误；
4. 第四特质是：手艺人、代码干净；版本控制

这位作者想说：

1. 所有内容都需置于版本控制之下（源代码、文档、构建脚本、测试用例、第三方库等）；
2. 版本控制让一些行为可追踪；
3. 版本控制减少开发之间的摩擦、冲突；
4. 版本控制让团队更高效；放下鼠标离开键盘

这位作者想说：

1. 当你想问题几个小时都不能解决，应该放下鼠标离开键盘，出去换换脑子；
2. 换换脑子之后能有更多创意性的解决想法；

阅读代码

这位作者想说：

1. 程序猿喜欢写代码，但是不喜欢读代码；
2. 思考代码如何易读？
3. 想提高编程技能，可以通过阅读代码实现；学习人文

这位作者想说：

1. 程序的工作往往不是单纯的写代码，不可避免要与人打交道；
2. 学习人文知识能提升你的思维；

造轮子

这位作者想说：

1. 别急着否定重复造轮子的行为；
2. 重复造轮子可以帮助你对工作原理有更深的理解；
3. 重复造轮子更重要的意义是训练、获得经验；

慎用单例模式

这位作者想说：

1. 单例模式确实简单，但是实际弊大于利，它不利于可测试性、可维护性；
2. 单例模式易造成代码单元的隐式依赖，造成耦合；
3. 单例模式不利于单元测试；
4. 下次当你考虑实现或访问一个单例时，请再想一想；代码炸弹

这位作者想说：

1. 高度耦合的代码都是代码炸弹；
2. 有很多方法可以衡量和控制代码的耦合度和复杂度；
3. 衡量耦合有两个指标：扇入和扇出；
4. 借助这些指标来进行调优；还原代码

这位作者想说：

1. 可以通过还原代码来理清混乱；（此小点与前文提过的“用删除来改进代码”契合）

单一职责

这位作者想说：

1. 单一职责原则是良好设计的基本原则之一；
2. 它表示一个子系统、模块、类，甚至是一个函数，不应该有多个改变的理由；
3. 善用单一职责，将因不同原因而改变的事物分开，可创建具有可独立部署的组件结构。从 yes 开始

这位作者想说：

1. 将观点从 no 转变为　yes，再开始工作；
2. 当别人说了一个荒谬得观点，你先别急着说 no，可以先问一下 why ？
3. yes 代表着合作；

自动化

这位作者想说：

1. 可重复得行为都能应用自动化；
2. 自动化不仅用于测试；
3. 在 IDE 中也要自动化；
4. 自动化操作并不神秘；
5. 学习自动化可以边做边学；利用代码分析工具

这位作者想说：

1. 测试只是提高代码质量的众多工具之一；
2. 利用其它代码分析工具，比如 lint 等；
3. 可以尝试自己自定义代码分析工具；测试必需的行为

这位作者想说：

1. 测试陷阱之一就是：测一些偶然的行为，与功能无关的行为；
2. 测试需精确、准确；
3. 测试需对被测单元的接口进行约定，测试行为与所需行为保持一致；

精确而具体地测试

这位作者想说：

1. 测试基本行为而不是附带行为；
2. 测试需要精确、准确；（与上一小点契合）

空余时进行测试

这位作者想说：

1. 测试服务器应该利用起夜间和周末等空闲时间；
2. 长时间运行的测试对于识别内存泄漏和其他稳定性问题至关重要；
3. 当然，这些前提都是已经应用了自动化测试；

小感：虽然每个人的建议都不尽相同，但读完后似乎都指往相同的方向 —— 如何在程序员这个岗位上做的更好！有些小点还是挺有感触的，适合深挖。有些“共识”可能在大家看来已经是“共识”，而我则刚刚知道~共勉。

OK，以上便是系列第 4 篇分享（共5篇），关注专栏，系列持续追踪~ 我是掘进安东尼，输出暴露输入，技术洞见生活，下次再会~