《程序员的职业素养》读书笔记 - 热血枫叶 - 51CTO技术博客

《程序员的职业素养》读书笔记 - 热血枫叶 - 51CTO技术博客

  （一）专业主义

（1）"专业主义"就意味着担当责任；

（2）所谓专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误实际上在所难免；

（3）你写的每一行代码都要测试。如果你希望自己的软件灵活可变，那就应该时常修改它！

（4）每个专业人士必须精通的事项；

1）设计模式：必须能描述GOF书中全部24种模式，同时还要有POSA书中多数模式的实战经验；

2）设计原则：必须了解SOLID原则，而且要深刻理解组件设计原则；

3）方法：必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等；

4）实践：必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程；

5）工件：必须了解如何使用UML图、DFD图、结构图、Petri网格图、状态迁移图、流程图和决策表；

（5）坚持学习。

不写代码的架构师必然遭殃，他们很快会发现自己跟不上时代了；不学习新语言的程序员同样会遭殃，他们只能眼睁睁看着软件业径直向前，把自己抛在后面；学不会新原则和技术的开发人员必将沦落，他们身边的人都是益卓越；

（6）业精于勤。

我常用的一个技巧是重复做一些简单练习：不妨早晚都个10分钟的卡塔吧！学习的第二个最佳方法是与他人合作。

（7）每位专业软件人员都有义务了解自己开发的解决方案所对应的业务领域；

（8）雇主的问题就是你的问题，每次开发系统，都应该站在雇主的角度来思考，确保开发的功能真正能满足雇主需要；

（二）说"不"

（1）专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说"不"！

（2）最要说"不"的是那些高风险的关键时刻。越是关键时刻，"不"字就越具价值。

（3）许诺"尝试"，就意味着你承认自己之前未尽全力，承认自己还有余力可施。如果承诺尝试，你其实也在承诺将改自己原来的方案。你是在承认原来的方案中存在不足。

（三）说"是"

（1）做出承诺包含三个步骤：

1）口头上说自己将会去做；

2）心里认真对待做出的承诺；

3）真正付诸行动；

（2）识别"缺乏承诺"的征兆，注意搜寻如下词语："需要/应当"、"希望/但愿"、"让我们"

（3）真正的承诺是，你对自己将来做某件事做清晰的事实陈述，而且还明确说明了完成期限；

（4）如果你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警、越快越好，越早越好；

（5）专业人士不需要对所有请求都回答"是"。不过，他们应该努力寻找创新的方法，尽可能做到有求必应。当专业人士结出肯定回答时，他们会使用承诺用语，以确保各方能明白无误地理解承诺内容；

（四）编码

（1）编码原则

1）首先，代码必须能够正常工作；

2）代码必须能够帮你解决客户提出的问题；

3）代码必须要能和现有系统结合得天衣无缝；

4）其他程序员必须能读懂你的代码；

（2）如果感到疲劳或心烦意乱，千万不要编码。强而为之，最终只能再回头返工。相反，要找到一种方法来消除干扰，让心绪平静下来；

（3）结对是应对中断的一种好方法，另一种有帮助的方法便是采用TDD；

（4）广泛阅读包括软件、政治、生物、航天、物理、化学、数学等，能激发创造力："创造性输出"依赖于"创造性输入"，创造力会激发创造力；

（5）软件开发是一场马拉松，而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛，只有通过保存体力和维持稳定节奏来取胜；

（6）管理延迟的诀窍，便是早期检测和保持透明；

（五）测试驱动开发

（1）TDD的三项原则

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

2）只要有一个单元测试失败了，就不要再写测试代码，包括无法通过编译；

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

（2）TDD是专业人士的选择。它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。

（六）练习

（1）专业人士都需要借助专门训练来提升自己的技能；

（2）保持不落伍的一种方法是为开源项目贡献代码；

（3）我的理解：练习就像是学生时代的课后作业，日事日毕，练习内容可包括：经典算法、常用数据结构、设计模式等；

（七）验收测试

（1）做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化；

（2）验收测试定义为业务方与开发方合作编写的测试，其目的在于确定需求已经完成；

（3）业务分析员测试"正确路径"，以证明功能的业务价值；QA则测试"错误路径"、边界条件、异常、例外情况；

（4）实现某项功能的代码，应该在对应的验收测试完成后开始；

（5）验收测试不是单元测试。单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为；验收测试是业务方写给业务方的，它们是正式的需求文档，描述了业务方认为系统应该如何运行；

（6）整套持续集成系统应该由源代码管理系统来触发。只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试，测试结果会用电子邮件发送给团队所有人；

（八）测试策略

（1）开发小组要把"QA"应该找不到任何错误"作为努力的目标；

（2）QA在团队中扮演的是需求规约定义者和特性描述者；

（3）专业开发人员遵循测试驱动开发的要求来创建单元测试。专业开发团队使用验收测试定义系统需求，使用持续集成保证质量稳步提升；

（4）测试金字塔，由下至上的顺序是：单元测试-->组件测试-->集成测试-->系统测试-->人工探索式测试，其中单元测试是基石。

 

（九）时间管理

（1）站立会议的核心：

1）我昨天干了什么？

2）我今天打算做什么？

3）我遇到了什么问题？

（2）迭代计划会议用来选择在下一轮迭代中实现的开发任务；

（3）凡是不能在5分钟内解决的争论，都不能靠辩说来解决。这类争论依据的不是事实，而是信念。唯一出路是，用数据说话。

（4）用番茄工作法管理时间。（呵，没想到Bob大叔也用这个）

（5）睡眠的重要性怎么强调都不为过，保证7小时睡眠！

（6）要避免的行为：优先级错乱、死胡同、泥潭；如果你掉进入坑里，别继续再挖！

 

（十）预估

（1）专业开发人员不随便承诺，除非他们确切知道可以完成；

（2）专业开发人员能够清楚区分预估和承诺。只有在确切知道可以完成的前提下，他们才会给出承诺。此外，他们也会小心避免给出暗示性的承诺。他们尽可能清楚地说明预估的概率分布，这样主管就可以做出合适的计划；

（3）预估实践方法之三元分析法，即划为乐观预估O、标称预估N、悲观预估P，结果u=(O+4N+P)/6；

（4）预估实践方法之德尔菲法：一组人集合起来，讨论某项任务，预估完成时间，然后重复"讨论--预估"的过程，直到意见统一；

（5）预估是非常容易出错的，控制错误的方法之一是大数定律：把大任务分成许多小任务，分开预估再加总。

 

（十一）压力

（1）即使有压力，专业开发人员也会冷静果断。尽管压力不断增大，他仍然会坚守所受的训练和纪律，他知道这些是他赖以战胜由最后期限和承诺所带来的压力感的最好方法；

（2）在压力下保持冷静的最好方式，便是规避会导致压力的处境；

（3）避免压力的方法

1）不做不切实际的承诺；

2）让系统、代码和设计尽可能整洁；

3）在危机中依然遵守纪律原则；

（4）应对压力

1）避免孤注一掷的想法，鲁莽仓促只会把你带入更深的深渊。相反，要放松下来，对问题深思熟虑。

2）和团队、主管沟通；

3）坚信并依靠你的纪律原则；

4）结对寻求帮助；

 

（十二）协作

（1）不正常的团队最糟糕的症状是，每个程序员在自己的代码周边筑起一道高墙，拒绝让其他程序员接触到这些代码；

（2）专业开发人员是不会阻止别人修改代码的；期望拥有代码的是整个团队，而非个人；

（3）专业人士结对工作，是解决程序间合作的最有效方法，也是分享知识的最好途径；

（4）最有效率最有效果的代码复查方法，就是以互相协作的方式完成代码编写；

 

（十三）团队与项目

（1）形成团队是需要时间的。团队成员需要首先建立关系。他们需要学习如何互相协作，需要了解彼此的癖好，强项、弱项，最终，才能凝聚成团队。否则，那就是团伙，而非团队！

（2）最理想的团队是12人，7名程序员，2名测试人员，2名分析师和1名项目经理；

（3）创建有凝聚力的团队，然后不断地把新项目分派给他们，而不是围绕项目来构建团队；

（4）团队对项目更难构建。因此，组建稳健的团队，让团队在一个又一个项目中整体移动共同工作是较好的做法；

 

（十四）辅导、学徒期与技艺

（1）所谓大师

已经领导过多个重要软件项目的程序员。一般说来，他们已经拥有10年以上的从业经验，曾在多个不同类型的系统、语言和操作系统上工作过。他们懂得如何领导和协调多个团队，他们是熟练的设计师和架构师，能够游刃有余地编程。

（2）专业主义价值观和技术敏锐度需要进行不断地传授、培育、滋养和文火慢炖，直至其深植入文化当中；

Read full article from 《程序员的职业素养》读书笔记 - 热血枫叶 - 51CTO技术博客