程序员，工作多年的你真的专业吗
此文是《程序员的职业素养》的读书笔记
这本书是从公司的图书馆借的，计划是1.26-2.6直接看完，最终是2.17才看完，书不太厚，净阅读时间应该在8小时左右，还是学到了一些东西。
整体感受
先抑后扬吧
最不好的感受就是翻译太生硬了，看的我尴尬，有些感觉真的就是按照字面意思翻译，并没有进行本土化的渲染，主要是美剧看多了，现在的翻译组都太强大了，刚开始看的时候特不习惯，后来习惯了这文风也就还好了，如果翻译更加自然一点就太好了。
本书作者是一个经验非常丰富的程序员，几乎是跟着计算机技术一起成长，其实我觉得全书就是在讲述什么叫专业，我们大多数人其实都不够专业。但是发现自己的思想变化，学习成长还是在往作者所说的专业上靠的，但很多做的不够，包括身边大多数程序员。
编码能力只是你最基本的功力而已，而已
拎几点感触比较深的。
学会说 不
大多数时刻我们都会毫不犹豫地答应产品或老板的要求，在多长的时间内完成什么样的任务，程序员对于产品延期貌似并不感冒，觉得是一件很正常的事情，但是其实很多情况下，老板，其他团队是没有办法接受这部分延期的，我们并没有确切地告诉他们这其中的风险，有时候我们使用了模棱两可的语气，比如说
我试试
应该可以
或是有时候就是直接过于自信地拍胸脯保证
这个 bug 我马上就解决
这种场景太常见了，我们太善于以程序员的通病来为自己开脱，这就是程序员的通病，但是这不是件值得骄傲的事情，在规定的时间内完成我们必须要做完的工作是应该的，如果没有办法完成，严厉地拒绝老板，说 不。
如果在项目期限上有可能性的浮动，我们一般喜欢擅自加班解决，加班没有错，但是我们应该要让老板知道这部分的浮动，以方便他们根据我们专业上的见解来进行战略上的调整，否则即便你加班加点的完成了你承诺的工作，但是质量一般，老板也不会对你的加班加点，辛勤工作而感恩戴德，我们要为自己的承诺付出代价。
作为一个程序员，你要能接受加班，但并不应该以加班为常态，也不应该以加班为荣。
学会说 是
说 是代表着一种承诺，如果你作出了承诺，就必须要为这个承诺付出代价
意指
- 口头承诺
- 内心认真对待
- 真正付诸行动
在团队协作中，大多数时候我们并没有为我们说过的话负责任，其实这就是一种极度不专业的表现，然而我们没有意识到，程序员善于自嘲，对别人的指点却嗤之以鼻，真正的专业我想是这样的。
有个朋友是同济大学化学系的研究生，他说他们实验室的器材从来不买国产的，只买日本的，同样的器材，国产15w，日产25w，但是他们还是会买日本的，因为当你的仪器出现问题，打电话给了维修中心，维修中心派人来维修，同样都收5000块维修费，他们问：它还会出现这样的问题么，再次出现怎么办，还要收维修费么。
国产
这个我不能保证，但是它现在已经能正常运行了，如果再坏还是要付钱维修的
日产
在我有生之年我不希望我再修复这个问题第二次，这对我是一种耻辱，不管我以后是否还在这家公司就职，这个问题我们都会为你免费解决
这就是专业，但是大多数时候我们都是不确定的，我们没有为承诺做出100%的努力，在现在的大环境下，我们不相信软件是不会有 bug 的，所以我们大多数时候都没有对待，得过且过，才导致问题百出
我还经常大言不惭地在老板面前鼓吹 程序是不会没有 bug 的， 以此来推卸线上出现问题的情况，工作已经三年，我感觉到非常羞愧。
测试
在赶进度时，代码往往没有通过自己100%的测试就移交给 QA，然后 QA 提出一大堆的 bug，我们再去修复这些 bug，但是其实很多时候这些 bug 都是不应该存在的，非常低级的错误，所以在修复问题和写代码时都不能太急躁，以赶进度写出比较烂的代码是极度不专业的，专业的程序员无论多忙都会按照优质的开发流程来进行开发，如果在时间充足的时候你是按照 TDD，知道代码需要架构，需要封装，需要用到设计模式，但是在比较忙的时候你就忘了这些，那说明你从内心深处是不相信这些可以提高工作效率的，或者你的编码架构能力还不够，仅此而已，没有任何借口
预估
预估是件非常有难度的事情，预估进度时我们往往会漏掉细节和过于乐观，在上个版本时我们团队就出现了这样的问题，完成时间比预估时间晚了一个星期左右，我们在预估时经常会考虑最乐观的情况，或是 说如果不出现什么样的问题，就可以在多少天完成，但是其实最终一定会出现这样的问题，我们知道，但是我们拒绝相信，然后最后为了解决这些已经被预料到的还有没有被预料到的问题忙得焦头烂额，甚至我们在预估时还会加上自己额外的时间，晚上，周末等等，这些都是不应该的，关于预估，我们 CTO 也给我们讲了很多，这是一个需要长期学习的过程，尤其是在团队越来越大，预估成本也就更高。
但是有几个很重要的原则：
- 不可过于乐观
- 你觉得可能会出现的问题，一定会出现
- 正视发生的问题，并及时调整计划
应对压力
身处压力之下，工作效率非常低下，而且通常第二天再来看自己的代码就想重构，在压力下如果没有办法保持冷静，可以找同伴寻求帮助，或是先去解决给你带来压力的那件事情
从专业的角度来说，私人生活影响工作是不对的，但是如果真的发生这样的情况，要试着先去解决，释放压力，再进行工作。
如果是因为工作上的原因，因为解决一个问题而无比焦躁，可以考虑结对编程，找团队中的其他人和你一起解决。
同样，如果我们看到团队中的某个人正处于巨大的压力中，我们也要主动伸出援手
团队凝聚力
团队中的每一个人都要以解决问题为最重要的目标，团队应以项目为驱动，团队利益优先，一般团队都会经历一个磨合期才能配合默契，所以在团队的扩张过程中，总会有一定的混乱期，大家不知道别人的进度，无法与他人合作无间，形成一个有凝聚力的团队往往需要一些时间，少则几个月，多则一年，大家一起解决问题，一起搞定一切，每个人都应该承担起团队的每个错误和失误，而不是互相推卸。
以上是我感触比较深的几点，书中所讲当然远不止这些，有兴趣的可以看看，但是这本书可以不用从头看到尾，看起来也算比较轻松，希望我们都能成为一个专业的程序员。
