高效程序员的良好习惯，敏捷开发修炼之道

Posted 2021-04-25 IT小书虫

态度决定一切

软件开发是智力活动，一些有效个人习惯为敏捷实践打下基础。

做事

指责不会修复bug。把矛盾对准问题的办法，而不是人。“这不是我的错”，这话不对。“这都是你的错”，这话更不对。如果你没有犯过任何错误，你可能没有努力工作。

欲速则不达

不要坠入快速的简单修复中。要投入时间精力保持代码的整洁。不要急于修复一段没有真正理解的代码。

对事不对人

应该聚焦于解决问题。会议不评判、谴责，只陈述自己的观点和建议。团队决策的一些技巧：设定最终期限，逆向思维，设立仲裁人，支持已经做出的决定。

排除万难，奋勇前进

做正确的事。要诚实勇气地说出实情。

学无止境

敏捷不会坐享其成，需要培养习惯来帮助个人和团队成长并自我超越。

跟踪变化

跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。只要你在某些方面成为专家，就能用同样的方法，很容易成为新领域的专家。你要明白为什么需要这项新技术，它试图解决什么问题，它可以被用于什么地方。

对团队投资

提供你和团队学习的好平台。可以通过午餐会议或内部培训，团队成员轮流分享知识和技能。坚持有计划有规律的讲座。持续小步前进。可以是技术也可以是业务主题，也可以是团队建设、沟通、项目评估技巧等。

懂得丢弃

学习新东西，要丢弃会阻止你前进的旧习惯。

打破砂锅问到底

不断问为什么，连续追问五次以上，直到找到问题的根源。

把握开发节奏

保持稳定的节奏，更容易达成目标，能让团队高效运转。

交付用户想要的软件

如果软件不合用户需求，代码再优美也没用。让用户和客户参与开发过程非常重要，以保证项目符合他们的需求。

让客户做决定

让客户做业务决定。提供可选方案，说明每种方案的优缺点，以及成本和收益。和客户讨论各方案对时间和预算的影响。由客户决定选何种业务方案。记录客户的决定和原因。

让设计指导而不是操纵开发

设计满足实现即可，不必过于详细。好设计是一张地图，它会进化。让设计指引你向正确方向前进。

合理地使用技术

根据需要选择技术。为具体问题评估技术，该技术是否可解决你的问题？你会被它拴住吗？维护成本多少？不要开发你能下载到的东西。

保持可以发布

保持你的项目随时可以发布。

提早集成，频繁集成

代码集成是主要的风险来源。要规避这个风险，只有提早集成，持续而有规律的集成。

提早实现自动化部署

一开始就实现自动化部署应用。

使用演示获得频繁反馈

定期或每个迭代结束时给客户演示已完成的功能，获得反馈，以确保方向正确。

使用短迭代，增量发布

增量发布最小可用产品。

敏捷反馈

敏捷方法有效，是因为使用反馈来纠正软件和开发过程。

守护天使

使用自动化的单元测试，好的单元测试能为你的代码提供及时的警报。测试必须有效。只有达到一定的测试覆盖率，才能真正发挥作用。

先用它再实现它

将TDD作为设计工具，会为你带来简单有效的设计。

不同环境，就有不同问题

使用持续集成工具，在每一种支持的平台和环境中运行单元测试。

自动验收测试

为核心业务逻辑创建测试，让客户单独验证，让它们能自动运行。

度量真实进度

度量剩下的工作量，要评估那些需要完成的待办事项。不要欺骗自己或团队。

倾听用户声音

每个抱怨后面都隐藏了一个事实。找出真相，修复真正的问题。没有愚蠢的用户，只有自大的开发人员。如果代码解决不了的问题，可以考虑通过文档或培训来修补。你的用户很可能不会阅读你的文档。

敏捷编码

开发人员遵循以下原则，将有助于开发出易于理解、扩展和维护的代码。

代码要清晰地表达意图

编写清晰易懂的代码，向阅读者明确表明你的意图。因为多数情况下，代码被读的时间远大于开始编写的时间。遵循黄金法则：你希望别人怎样对你，你也得以同样的方式对别人。程序员都有阅读修改别人代码的可能。

用代码沟通

为代码的类或模块添加短小描述，说明其目的和需求及约束。遵循通用编码规范。代码可以传递意图就不用加注释，注释要说明为什么这样写代码。

动态评估取舍

没有适合所有情况的最佳方案，必须在性能、成本、进度和上市时间等方面做动态评估权衡。

增量式编程

在很短的编写、构建、测试循环中写代码。采用增量式编程，创建更小的方法和内聚的类。

保持简单

开发可以工作的，最简单的解决方案。复杂设计和代码并不代表能力，相反，简单而不简陋，简洁而易于理解的代码，更需要功力才能做到。

编写内聚的代码

让类的功能尽量集中，让组件尽量小。

告知，不要询问

将命令与查询分开，查询不应改变对象状态。

根据契约替换

通过替换代码来扩展系统，继承要遵循里氏替换原则。要多用委托而不是继承。is a 用继承，has a 或use a关系用委托。

敏捷调试

调试是开发中非常有用的手段。记录问题解决日志是重用经验、有效团队知识管理的方法。编码应该报告所有异常，出错时应考虑用户感受，提供有用的错误信息。

记录问题解决日志

维护一个问题及其解决方案的日志，是修复问题过程的一部分。以后发生相同或类似的问题，就可以很快找到并使用了。

警告就是错误

提交带有警告的代码，跟提交有错误的代码一样，都是极差的做法。提交构建工具中的代码不应产生任何警告。

对问题各个击破

在解决问题时，要将问题域与其周边隔离开，在构建系统原型、调试时各个击破的方法可以起到帮助作用。

报告所有异常

必须处理所有异常，恢复或者向上传播异常。

提供有用的错误信息

发生问题时，要展示出尽量多的定位细节信息。考虑使用断言，打印日志要注意信息安全，不能泄露敏感信息。

敏捷协作

项目成功与否，依赖于团队成员如何有效工作、互动，以及管理项目活动。高效的协作是敏捷开发的基石。以下习惯可以帮助团队成员全身心投入项目，一起朝着项目目标努力。

定期会面

面对面是最有效的沟通形式，通过敏捷立会让团队达成共识，暴露问题风险。每个人回答三个问题，限时在两分钟内。

架构师必须写代码

架构师要参与编码，指导开发团队，提升水平，解决复杂问题。也要鼓励程序员参与设计。架构、设计、编码和测试，是开发的不同方面。

实行代码集体所有制

让开发人员轮换完成系统不同领域不同模块的不同任务，或者划分模块责任田主、备份机制。让任何一部分代码至少有两人或两人以上能修改，否则项目可能因为成员生病、请假、离职等各种原因陷入风险。

成为导师

成为导师，分享知识、经验，在帮助团队提高水平的同时也能提高自己。教学相长，形式不限。

允许大家自己想办法

作为导师，应该鼓励、引领新团队成员思考如何解决问题。而不是直接提供解决方案。授人以鱼不如授人以渔。除非人家已陷入泥潭，没有任何思路。可设定一小时规则。

准备好后再共享代码

绝不要提交未完成的代码。提交编译不通过或者单元测试不通过的代码，是一种犯罪行为。

做代码复查

代码复查是提升代码质量和降低错误率的有效方法。应该复查所有代码。可以通过结对编程或者提交代码前成员互检将检视代码落到日常开发中，此外，还可增加团队例行化主题检视。

及时通报进展与问题

发布项目进展，不要等干系人来问项目状态如何；不要等到截止日期才报告坏消息，尽早暴露问题风险尚有回旋余地。比如：可以通过发布项目日报、周报/月报对不同干系人发布详略不一的项目进展和问题风险求助，项目管理可视化。