《代码整洁之道程序员的基本素养》内容表达与读后感

关于本书：
  本书的作者是大佬，资历丰富，能力强，项目也多。他写这本书的用意就是希望自己踩过的坑别人不要再踩。但是以我的经历来看，坑还是不断地再踩。
  作者有本书论述敏捷开发及敏捷开发历史的，那本书我十分推荐阅读。
  本书一百四十多页以故事为主，只是密度低，所以阅读起来非常快。但是因为内容过分真实，是很值得让人回味的。还有各种建议、方法论。

书本内容表述

大致说一下本书要表达的内容

人要搞清楚什么是专业
不要行损害之事
要有职业道德：了解你的领域、持续学习、学会合作、了解业务、与客户保持一致、保持谦逊、保持练习
要学会说“不”，因为说“是”需要担起责任。
永远不要说“试试看”，这经不起推敲。如果保持原来的方法是不会成功的，如果试用新的高效方法为什么之前没用？之前工作没用尽全力？总的来说，要么是之前在摸鱼，要么就是在糊弄人。
要学会说“是”。不要敷衍别人，表达承诺应该说清楚乐观、平均和悲观的情况，并说出自己的应对策略。
编码的时候要保持高效，不要熬夜写代码也不要在焦虑下写代码，因为大概率这些代码需要返工。
写代码的时候需要思考，最好不要用边听音乐边写，小心把歌词写进注释里。
学会保持节奏
帮助他人是在帮助自己，总有收获的
了解TDD
保持练习
要和业务侧一致，多沟通，通过验收测试
要和QA保持联系，尽量别让QA发现bug
要会管理时间，保持规律生活
学会预估工时，了解PERT方法
在压力面前要保持专业性，要沟通，不行就寻求帮助。
要保持和团队一致，共同完成项目。

感想

本书给我的最大感想一个就是此时此刻正如彼时彼刻。
书中描述了情况就是需求方不断要求快速迭代，不要做测试，不要重构，直接上线，尽可能的快速“完成”。现实中确实如此，甚至更过分。

作者在讨论“面对压力”内容时的一些话很让人认同。既然在压力面前，选择了不优化、不测试、不重构，那就是你认为这样能更快的写出可运行代码，那当初为什么要优化、测试和重构。也就是说，在危急关头的抉择，表面了内心对方法的相信。再换个说法，面对压力的时候放弃了这一切方法只管埋头写代码的时候，程序员就是否认了这些专业方法的必要性。

还有一个就是关于“试试看”的讨论。当工期要求必须多少天内完成的时候，自己又不能确保完成工期，说“试试看”意味着什么。也许endtime不断靠近，程序员反馈进度一直很好，结果到最后一天要交货的时候说还差进度百分之20，代码还不能运行。这是不应该发生的事情。专业人士面对问题都是想着大家一起解决问题，而不是让问题暴雷。

做不到就是做不到，应该要如实的反馈才行。不是所有工作都要自己一个人抗，当确实无法完成的时候是必须给予反馈的，通过和同事的协作开发也好，和产品协商取消部分功能也好，甚至是改变方案只写个展示demo让产品应付也好。大家实一个团队，核心的目标都是实现项目的交付，所以团队的信息需要保持同步。

我看的收获：相信自己的专业技术。
如果一个事情做起来很简单，那是不需要多少技巧的。我相信大家都是承认这点，门槛越低，越不需要专业性。为了快速处理各项事务，面对别人处理不了的情况，专业人士应该是内心有一套可以处理的方法论的，而且方法论越是先进，处理的效率越高。当面对危机的时候，为了更恰当的处理当前情况，人就应该越是冷静，去用已有的专业技巧去处理这些问题。
所谓做不到就是做不到，所谓的试试其实就是一种幻想，不断地祈祷能提前完成只会收获失望。为什么会这样？墨菲定律讲了，当一件坏事可能发生的时候，这事其实是必然发生的。
再从概率论角度来讲，当把每一种情况拆分出来并平均分摊出来，搞砸一件事的可能性是远远大于把事情做好的。总之应该放弃幻想面对残酷的现实。

人们总是觉得有奇迹，实际上奇迹都是有代价的。项目的开发是一场马拉松，为了赶项目可以加班，甚至熬夜。但是这个周期勉强赶上了，下个周期呢。这不是加班的奇迹，这是透支的奇迹。我是见过大家周一过来啥事都不想做的情况，明明任务很多，但是大家只能以低效的工作效率在工位上熬。
如果说有的项目能完成别人不能完成的奇迹，除了运气因素，那应该是专业导致的奇迹。掌握项目情况，合理规避风险。在危机前做出正确的抉择，在暴雷前把问题暴露出来。总之个人和团队的能力是有局限性的，所以需要协作完成一个项目，所以需要各种专业的方法论把项目进行下去。

**但是又有多少人能在压力面前不妥协呢?**如果能做到，那应该就是有专业素养的人吧。
我的目标很简单，提升各种能力，让产品上线前减少bug的出现，最后大家不需要熬夜，完成一天该完成的工作，所以需要不断地学习以提升能力。