《程序员的职业素养》- 读书笔记
这本《程序员的职业素养》内容相对比较简单，但是涵盖了一些程序员在工作过程中需要注意的一些细节问题，如果读者是程序员的话会对职业发展有很大帮助的。
本书一直围绕着“专业”二字展开，以作者的观点阐述了何为”专业的程序员”：专业的程序员是如何思考，如何解决问题，如何承担责任。笔者将一些比较有体会的部分摘录出来，结合自己的心得整理出这篇读书笔记。内容的顺序和书中的顺序基本不符，完全按照笔者按照几大块归类整理而成。
一. 专业的程序员如何写代码
应该写出易于修改的软件
所有软件项目的知道原则是，软件要易于修改。如果你希望自己的软件灵活可变，那就应该市场修改它！要证明软件易于修改，唯一的办法就是做些实际的修改。如果你发现这些改动并不像你预想的那样简单，你就应该改进设计，使后续修改改变简单。
有时开发期已过进入测试阶段，可能还会加一点需求(大家有体会吧)，在开始入职的时候笔者个人是很反感的，因为如果是影响到逻辑上的改动会比较麻烦，每次都要改一些时间。但是反过来想，如果每次改都要很长时间，是否是因为我本来的代码不易扩展和修改呢？所以，今后在写代码的时候要考虑多种可扩展的情况，让代码的可扩展性，可定制性达到很高的水平，这样一来，以后如果要增加需求或者更改需求的时候能够应付自如。
应该尽力让QA找不出任何问题
什么样的代码是有缺陷的呢？那些你没把握的代码都是！把自己没有把握的代码发送给QA这么做本身就是不专业的。 尽管公司可能设有独立的QA小组专门测试软件，但是开发小组仍然要把“QA应该找不到任何错误”作为努力的目标。
以笔者短暂的职业经验来看，出bug的地方一定是自己没有完全理解的地方，没有之一，全部命中。所以渐渐的，养成先好好看代码，将逻辑都理清了再重构或者再写代码的习惯，显然出错率少了很多。
应该以零bug为目标
没人能写出完美的软件，但这并不表示你不用对不完美负责。不能一而再，再而三犯同样的错误，职业经验多了以后，你的失误率应该快速减少，甚至渐进于零。失误率不可能等于零，但是你有责任让它无线接近于零。
不应该单打独斗
也许你认为自己一个人工作时会做得更好。也许确实如此，但这并不意味着你一个人工作时，整个团队会做得更好。况且，，事实上，一个人单独工作时，不太可能会工作得更好。
确实是这样的，笔者前一段时间一直是半脱离团队的，有问题也很少请教别人，虽然明知道这样可以节省很多的时间，但是由于笔者的性格比较喜欢独立解决问题，所以经常做一些“自负的行为”。后来渐渐的发现自己做确实吃不消，而且听到团队其他人互相帮助的时候确实为自己省下来不少时间，改掉了这个毛病，效果甚好
应该明确代码的业务价值
专业程序员的首要职责是满足雇主的需求。这意味着要和你的经理们，业务分析师们，测试工程师们和其他团队成员很好地协作，深刻理解业务目标。你需要理解手上正在编写的代码的业务价值是什么了解你的企业将如何从你的工作中获得回报。 专业程序员会花时间去理解业务。他们会和用户讨论他们正在使用的软件，会和销售人员和市场人员讨论所遭遇的问题，会和经理沟通，明确团队的短期目标和长期目标。
二. 专业的程序员如何沟通
应该准确把握“完成”的定义
专业开发人员的“完成”只有一个含义：完成，就是完成。 完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可，这，才是完成。
应该准确预估
将大任务分成许多小任务，分开预估再加总，结果回避单独评估大任务要准确很多。这样做之所以能提高准确度，是因为小人物的预估错误几乎可以忽略不会对总的结果产生明显影响。
不应为了保住颜面而虚报事实
我忽略了测试环节，整个过程中只考虑如何保全自己的颜面，却没有估计客户和雇主的声誉。我本该早点担起责任，告诉Tom测试还未完成，自己不能按时交付产品。
其实刚进公司的时候自己也是蛮好面子的，生怕同事觉得自己技术不过关，有的时候跟人家说完全做完了，但是实际上晚上回家后开夜车写代码才给搞定。其实这种习惯是不好的，虽然表面上看来还不错，但是实际上为了颜面而不考虑效率将工作推到回家之后显然是不专业的。做完了就说做完了，没做完就说没做完，没有任何借口，就算做不完也要好好想想为什么没有及时完成，找到提高效率的方法才是专业的态度。而不是想着“反正有晚上呢”，通过时间的积累来解决问题。
专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”。你的经理期望的是，你能像他那样竭尽所能地捍卫自己的目标，这样你们才能得到可能的最好结果。
当你的能力明显达不到经理的期望的工期的时候，要敢于说“不可能”。要说明自己尽力所能达到的效果，要让经理知道实际情况，跟经理一起找到双方都能接受的解决方案，而不是屈服于权势而打肿脸充胖子，因为如果你没能实现你的“豪言壮语”，背锅的就是你。
应该提供真正的承诺
真正的承诺：对自己将会做的事情做了清晰的陈述，还明确说明了完成期限。
没能履行承诺的原因以及解决方法：
- 依赖其他的事情，只承诺自己完全掌控的事情。
- 如果不确信是否能完成，应该全力前进，使用可以支配的全部时间来完成。
- 如果遇到突发事件导致无法按时完成，要及时向承诺对象发出预警，越早越好，以便于整个团队采取措施作出对策。
应该用数据争论
凡是不能在5分钟内解决的争论，都不能靠辩说解决。争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。在没有数据的情况下，如果观点无法在短时间达成一致，就永远无法达成一致，唯一的出路是，用数据争论。 切忌用个人能力赢得争论。他们可能提高嗓门，近距离与你对视，或者摆出不屑的姿态。但这都不重要，长期来看，强力是无法解决争论的，最终还是要需要数据。
三. 专业的程序员如何自我管理
应该不断的学习
在工作余下的时间里花点时间为雇主工作也是合理的，但是别忘了，那20个小时是为你自己的，它们会让你成为更有价值的专业人士。
我通常会把学习的时间分为两种：第一种是学习纯iOS知识，另一种是学习提高代码能力的知识。
前一种知识我选择相对于自己目前的水平稍微难一点的知识，这样一来，学习起来也不累，而且提升效果也比较明显。就好比敏捷开发：对于自己的学习，也就着轻量迭代，快速迭代的原则。
后一种知识我选择一些能提高代码效率和质量的书，而且还有一些提升程序员素质和视野的书(就好比这一本)，因为我认为人不论做什么事情，都要跳出这件事本身，以更高的层次来思考。
应该勤于练习
只完成日常工作是不足以成为练习的，那只能算是种执行性质的操作，而不是练习。练习指的是日常工作之余专门练习技能，以自我提升。
说来惭愧，入职这段时间只是总结之而已，包括工作中学到的知识和下来自己学习的知识。但是从未刻意练习过某项技术。前一阵子看到一篇文章说是将一本书的代码抄7遍来练习，效果显著，而那本书恰是iOS领域的:《Effective Objective-C 2.0 编写高质量iOS与OS X代码的52个有效方法》。等这次迭代结束之后我打算尝试一下。
应该保持精力充沛
疲劳的时候，千万不要写代码。奉献精神和职业素养，更多意义上指要遵循纪律原则而非成为长时间工作的工作狂。要确保自己已经将睡眠，健康和生活方式调整到最佳状况，这样才能在每天8个小时的工作时间内全力以赴。
关于这一点，笔者需要好好检讨自己了。之前因为独立负责公司一个项目，为了要项目如期上线，每天都工作到2点以后，虽然产品如期上线，但是回想一下过程发现，完成的效率并不是很高，由于有些地方需要重写，浪费了不少时间。在这之后，尽量调整自己的生物钟，将睡觉的时间渐渐提前，效果甚好。
四. 专业程序员的时间管理
邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你，所以，如果你收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实显著的成效，否则不参与。 你应当明白，继续待在会议室里是浪费时间；就行参加对你没有太多意义的会议，是不专业的行为。因为你有责任合理分配老板给你的时间和金钱，所以，选个何时的机会行亮如何离席，并非不专业的做法。
书的作者在最后推崇了学徒制，呼吁了在专业毕业生毕业后进公司时不应该马上投入工作，而是应该采取学徒制来对毕业生进行大学内无法提供的教育。
推崇学徒制
学校能够传授的是计算机编程的理论。但是学校并不会也无法传授作为一名编程匠者所需要掌握的原则，实践和技能。这些东西只有经由师徒个体间多年的细心度到和辅导才能获得。软件行业中像我们这样的一批人必须要面对这一事实，即指引下一代软件开发人员成熟起来的重任无法寄希望于大学教育，现在这个重任已经落到了我们的肩上。建立一种包含学徒期，实习期和长期指引的机制已经是迫在眉睫。