《程序员的职业素养》——总结
前言
在Bob大叔的整本书中，重点传达了一种精神，就是专业精神。解释出来会有很多种精神，但是我觉得概括下来，就是工匠精神，就是责任感。要对项目负责，对代码负责，对公司负责，对个人负责。对于整个项目而言，不合乎情理的需求，可能对项目造成很严重的损害。就像一个任务在保证质量的前提下，需要10天才能完成，可是提出需求需要3天完成，我们身为专业开发人士，不能一味的为了迎合需求，就勉强答应。而答应下来，必然的结果就是抛弃项目质量优先的原则，为了追赶工期，不顾项目的质量问题，从而勉强达到需求。这样导致的必然结果是这段糟糕的代码会对日后的工作产生更多负面的影响，影响其他模块的工作，拖慢工期，或者又需要拿出额外的时间来对这段糟糕的代码进行重构。不管哪种情况，都必然会导致更长的开发周期，为了节省着几天的时间，赔上更多的时间，得不偿失。所以，我们身为专业人士，应该站在专业人士的角度，理性的分析需求的可行性，如果可行，才对需求做出承诺，言必信，行必果，做出承诺就代表我们一定会完成这个任务。如果不可行，我们应该当即向业务人员或者客户说明，指出需求中的弊端，说明这样对整个项目的重大影响，对于这样的需求不能容忍包庇。在不接受需求的情况下，我们身为专业人员，应当尽可能的提供一种备用方案，在保证质量的前提下，来间接满足需求。很多时候，客户其实也并不知道他们想要的是什么，或者也并不是想要在这么短时间内完成，这只是客户用来和开发人员博弈的手段，我们在沟通过程中，做到坦诚相待，诚信，客户能体会到。
在对项目负责的同时，我们身为公司的员工， 有义务为公司负责。公司付给我们薪水，给我们创造好的工作环境甚至还有生活环境，我们应该感恩，对于公司有认同感，有责任感。在接到公司任务时，应该对任务负责，精益求精，而不是敷衍了事。对于软件产品而言，任何一部分糟糕的代码，都将以整个软件的名义，给用户造成糟糕的用户体验，这对于整个软件项目来说，是恐怖的。如果说这段代码还对项目中别的模块造成恶性影响，那将简直是灾难。而且我们身为开发人员，对于我们编写的每一段代码，都是我们自有知识的固化，糟糕的代码，意味着我们的知识的糟糕、贫乏。对自己的代码不负责，就相当与对自己的知识不负责，我觉得任何人都不会想让自己看起来很没学问吧。一个项目团队，在编码方面，由架构师制定整个软件项目的结构，之所以不是由架构师直接完成整个项目，就是因为还需要程序员来负责细节方面的控制，这是程序员的责任和义务，所以，如果连细节和质量都控制不好，那也不好意思说自己是程序员，完成了程序员的工作。
在完整看完本书之后，我对于Bob大叔想给我们传达的东西做了一些简单提炼，下面将分几个模块介绍一下。
第一节 说“不”和“是”
在面对不专业的需求时，开发人员应当勇敢的提出异议，向客户或领导说明情况，从保证项目质量的角度出发，尽可能的贴近需求。不能为了讨好客户和领导，而偷工减料，以降低项目质量的代价，来达到客户和领导的要求。在需求不能接受的时候，开发人员和客户或领导应当进行协商，双方都明确的提出自己的需求，然后双方协商一个最好的方案进行。
在项目周期中的任何时期都不能放松这个标准，不管在哪个时期放松标准，都将对整个项目造成严重的影响。当到了项目的关键时期时，越要更严谨一点，越要勇敢的说“不”，因为越到关键时刻，放松标准对项目的影响越大。
身为专业人士，在做出决定前，要有专业人士的责任感，要对你做出的决定负责，要站在专业的角度，全面清晰的分析这个决定可能会造成的影响，在遇到会对项目质量造成损害的，应该提前说出来，避免拖到项目后期，对项目质量和项目工期产生更大的影响。
在经过仔细的思考后，做出承诺，那就要说到做到。言必信，行必果。只有做到诚信，才能让别人感到专业，才能让你说出的话，提出的建议，更加的有重量
对自己的承诺负责这是我们自己必须做到的，但是很多时候放在别人身上可能并不一样了。有时候，我们需要学会分辨他们口中的伪诺言，以免获取到错误的信息，从而影响自己的工作、项目的周期、项目的质量等。
有些时候，我们对于任务的预估也会有些差错，可能会无法践行诺言，那么在这种情况下，最重要的是我们应该尽快向承诺对象发出预警，越快越好，越早越好，越快越早才能让承诺对象有缓冲期，可以调整策略，降低无法践诺将要造成的影响。
我们身为专业人士，不一定需要对所有事情说“是”，但是，我们应该想到创新办法，尽可能做到有求必应。当我们做出肯定回答时，我们应该使用承诺用语，以确保各方能够明白无误的理解承诺内容。
第二节 编码
在编码时，要有一个好的结构，模块化清晰。当开发增量时，不能破坏软件之前的功能。自己写的代码不应当对自己的写的代码之外的代码造成不好的影响。在开发过程中，要不断优化代码结构，在不断的重构中，代码性能和稳定程度都会得到增强。要勇于修改代码和善于修改代码。在编码的同时，一定要随时进行测试，对于每一个执行单元，都要设计单元测试。同时也要使用测试驱动开发方法来提高代码的可测试性。对于测试，应该保持认真和严谨，不能为了赶工期，应付式的进行测试，要保证整个项目的质量。认真严谨的测试，对于我们保持敏感的错误感知能力有很大的作用，在编码过程中，敏感的错误感知能力很重要，越早的发现Bug，对于项目影响就越小。在编码过程中，还要注意多从大局出发，不要把视角局限在一个角落，要保持自己理性的思考能力，局限在一个角落编写出来的代码，对于整个项目而言很鸡肋，后期还是需要进行重构的。
专业人士应该对与自己的时间有一个很好的管理。知道什么该做，什么不该做，知道在什么时间做什么事情。就比如公司发给我们工资，那么我们就应该在工作时间为公司创造利益，而不是在工作时间做自己的事情，所以其实每周应该制定60小时的工作时间，其中40小给公司，20小时给自己。在20小时中，我应该多读书、多练习、多查阅，提高自己的职业水平，才能获得更好的职业待遇，过上更好的生活。同时，在遇到疲劳、焦虑、烦躁等状态时，不应该勉强编码，在这种状态下，很可能眼睛盯着屏幕，手放在键盘上，但是大脑中却有一个后台进程一直在不断进行，或者时根本无法集中精神，这样编码出来的结果很可能就是后期的重构。每个人的注意力都是有限的，Bob大叔在书中的原话是说每个人的注意力就像是地下城里面的疲劳值一样，会逐渐递减，但会缓慢回复。所以，每个人需要学会怎样高效的使用注意力。身为专业人士，应该对自己的能力、自己能保持饱满状态的时间，有一个清晰的认知，在自身无法聚精会神的时候，应当进行适当的休息，以保证自己写出的代码质量，避免匆忙之间写出的代码错误过多，造成后期的重构，需要更多的时间来填补这个坑。专业人士要确保自己已经将睡眠、健康和生活方式调整到最佳状况。这样才能确保在每天的8小时工作时间全力以赴。
第三节 团队与协作
形成团队是需要时间的。团队成员首先要建立关系，需要进行沟通，经常的沟通能增进团队成员之间的互相了解，以及学习互相之间如何相处，如何配合，才能做到在项目中互相协作，成员之间需要了解彼此的癖好、强项、弱项，最终，才能凝聚成一个团队。在团队克服个体差异性，默契配合、彼此信任，形成真正有凝聚力的团队之后，不应该立即拆散这个团队，只需要不断的给这个团队任务就行，他们会不断的磨合，不断提升彼此的默契，从而不断的提升团队的工作效率。
在团队开发中，要注意沟通。不要害怕让其他人看到你的代码，不要在自己的代码上树起围墙，要互相交流。真正的专业人士是不会阻止别人来修改自己的代码的，和别人分享交流是一种快速有效的学习方式。在开发时遇到问题，结对编程是解决问题最有效的方式。专业人士之所以结对，是因为结对是代码复查最好的方式，系统中不应该包含没被其他程序员复查过的代码。最有效率最有效果的代码复查方式，就是以互相协作的方式完成代码编写。
在团队交流中，应当保持热情，积极交流。同时要互相帮助，给与帮助，接受帮助，乐于帮助。
当你在团队中处于学徒期时，有一名老师手把手带你那当然是极好的。但是如果没有那种条件，那应该仔细观察他人的工作，从中学习，快速成长。在学徒期，应十分密集的进行结对编程，学徒要了解设计原则、设计模式、各种纪律和固定的操作方式等，还要学会TDD、重构、预估等技巧。
第四节 实用技艺
1.专业人士必须精通的事项：
设计模式，必须能描述GOF书中的全部24中模式，同时还要有POSA书中的模式的实战经验；
设计原则，必须深刻了解组件设计原则和SOLOD原则：
1）一个对象只承担一种责任，所有服务借口只通过它来执行任务
2）程序实体，比如类和对象，只对扩展行为开放，对修改行为封闭
3）子类应该可以用来替代它继承的类
4）一个类对另一个类的依赖应该局限在最小的借口上
5）依赖抽象层（接口），而不是具体类
方法，必须理解XP、Scrum、精益、看板、瀑布、结构化分析以及结构化设计等；
实践，必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程；
工件，必须了解如何使用UML图、DFD图、结构图、Petri网络图、状态迁移图标、流程图和决策表；
2.要想保持潮流，保持进步，就要多练习、多学习。读书、看相关文章、关注博客和微博、参加技术大会、访问用户群、多参与读书和学习小组。
3.测试驱动开发。测试驱动开发应该是测试先行，将代码分成很多小模块，进行单元测试。这样，当代码有改动时，只要进行这些单元测试，便能知道是否会影响原有的功能。同时，由于单元测试做的很细，在对于错误排查方面也更加容易，更加能够跟踪到错误点。测试驱动开发所形成的大量单元测试，就相当于一份完善的文档，在单元测试中，可以看到关于方法的任何调用形式。测试代码的一个问题是隔离待测试代码，也就是解耦。如果要测试的代码调用了另一部分代码，那就需要想办法解除之间的耦合性，这就迫使你去思考什么是好的结构。测试驱动开发的三条法则：
1）在编写失败的单元测试之前，不要编写任何产品代码
2）只要有一个单元测试失败了，就不要编写测试代码；无法通过编译也是一种错误情况。
3）产品代码恰好能够让当前失败的测试代码通过即可，不要多写。
4.预估方法。在项目中，进度安排管理是很重要的事情，要安排好进度任务，那就要对任务耗时有一个正确的预估。Bob大叔在书中介绍了一种预估办法—PERT方法，主要包含三个要素，乐观预估（O）、标准预估（N）、悲观预估（P）。由这三个基础量，可以得出一个比较靠谱的期望完成时间：u = （O+4N+P）/ 6，同时概率分布标准差，既波动范围，
m = （P - O）/ 6
r-lat�Գ�
---------------------
作者：tooky_poom
来源：CSDN
原文：https://blog.csdn.net/tooky_poom/article/details/76665023
版权声明：本文为博主原创文章，转载请附上博文链接！