上篇：程序员的职业素养之读后感

2020-07-19 / 咨询顾问高老师 / 厚仁精英工作室

微信客服
wholerenguru3 (厚仁学术哥）

留学申请咨询

24小时咨询

美国拨打: +1 (412) 756-3137 中国拨打: +86 191-2318-4284

立即在线咨询 >

中文书名：《代码整洁之道：程序员的职业素养》

英文书名：《The Clean Coder：A Code of Conduct for Professional Programmers》

作者 Robert C. Martin,世界级软件开发大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，C++ Report 前主编，被后辈程序员尊称为“Bob大叔“。20世纪70年代初成为职业程序员，后创办Object Mentor公司并担任总裁。Martin 还是一名多产的作家，至今已发表数百篇文章，论文和博客文章。除本书之外，还著有《代码整洁之道》《敏捷软件开发：原则、模式和实践》等。

关于本书：

这本书主要阐述软件开发者的专业精神，大部分书中内容源于真实的开发场景，包含了许多实务性的意见，作者从从多种视角试图回答下列问题：

1）什么是软件专业人士？

2）软件专业人士如何行事？

3）软件专业人士如何处理冲突，应对很紧的工期，如何和不讲道理的管理人员打交道？

4）软件专业人士何时应该说“不”？怎么说？

5）软件专业人士如何应对压力？

书中内容体现了一种奋力突破的积极态度。这种态度倡导诚信，要富有荣誉感、自尊心和自豪感，要勇于承担作为一名手艺人和工程师所肩负的重大责任。这种责任包括要努力工作，出色完成任务；要擅于沟通，能够就事论事；要管理好时间，能够坦然面对艰难的“风险回报”决策。除此之外，这种责任之中还包括神圣的使命感。身为一名工程师，你比任何管理者可能都了解的更透彻。了解这些也意味着你肩负着要敢于行动的重大责任。

书中内容主要包含四大部分：沟通技巧、编码交付、任务规划、团队协作。

第一部分：沟通技巧（源自书中1-3章）

当我们提及沟通时，一般包括参与沟通的主体，要交换或者传递的信息本身以及场景等主要因素，而信息本身则随着主体和场景的不同，产生不同的视角和理解，甚至发生巨大的变化。书中第1章提到的专业主义，就是要让程序员时刻清楚自己要什么，让务实且勇于担当责任的态度贯穿与整个沟通过程。让我们猜一猜和程序员沟通的目标，相信你会同意：完成软/硬件开发需求这个泛指的开发任务。

作为职业程序员，首先，不行损害之事，比如不要破坏软件功能、不要破坏软件结构；

其次，掌握软件工程本身所需要的技能，比如软件设计模式，编程语言等，这需要程序员坚持学习，练习编码，与时俱进。

最后，研究和学习软件所要表达的业务功能，需要你了解业务领域，同业务人员一起学习合作，确保没有偏离业务轨道，很多时候保持一个谦虚谨慎的学习态度是很有必要的。

“能就是能，不能就是不能，不要说‘试试看’。”

谦虚的态度不意味着向事实妥协，尤其是当面对上级管理者时，务必本着实事求是的原则面对即将可能发生的开发任务。尽力而为不代表承诺，不代表一定会如期发生，否则当开发结果远远低于约定的预期目标时，那将是程序员的灾难时刻，甚至会令程序员丧失信心，断送职业发展。书中第2章提到，越是关键时刻，“不”字越具有价值。同时在团队面前，一定要避免消极对抗，即使开发任务超出现存能力所及的范围。

专业人士不需要对所有请求都回答“是”，不过，他们应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定的回答时，请使用正式的承诺，以确保各方能明白无误的理解承诺的内容。书中第3章提到，如何回答“是”，这其实就是一个计算问题，诸如估算，确定最后期限，尤其是确定开发任务的细节，当业务方没有给出任务细节时，请做好记录，反复确认，直到达成一致再开始逐步落实，否则就是一次充满不确定性的冒险行为。

第二部分：编码交付（源自书中4-8章）

当我们通过沟通，拿到确定性的开发任务后，我们接下来会优先考虑交付策略，其中包括三个环节：编码、测试、验收。

编码之前请做好准备，如果感到疲劳或者心烦意乱，千万不要编码，强而为之，最终只能再回头返工。一定要及时调整自己到高效率状态，有时候这种状态也称之为“流态区”，这是程序员在编写代码时会进入一种意识高度集中专注但思维视野却会收拢到狭窄的状态，这种状态效率极高，往往会感到”绝无错误“，自信且高效。编码过程中，时刻让自己保持在线状态，保持节奏，比如在开车回家路上，在洗澡的时候，脑海里都在潜意识的思考开发任务，如果开发遇到困难，请及时求助，不要单点恋战。

书中还提到编程柔道场，比如卡塔练习，还可以通过阅读开源代码提高自身经验，总之坚持学习和练习。

测试伴随着编码，甚至先于编码而进行，书中提到测试驱动开发（TDD），简要讲述了TDD的优势和局限。TDD的三项法则：

1）在编好失败单元测试之前，不要编写任何产品代码

2）只要有一个单元测试失败了，就不要再写测试代码

3）产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。

作者认为TDD是专业人士的选择。它是一项能够提升代码确定性，给程序员鼓励，降低代码缺陷率，优化文档和设计的原则。当然TDD并非宗教信仰，即使你完全按照3项法则去做，也有可能写出糟糕的代码，因为写出好的单元测试也并非易事。

未完待续…

附：

第1章：专业主义

第2章：说“不”

第3章：说“是”

第4章：编码