借部门的一次读书会上，我挑选了 Bob大叔的《代码整洁之道》这本书。在读了这本书的前面几章节时就觉得感触极大，今天刚好读完，希望下面我的感受也能帮到想成为专业程序员的你。
什么是专业程序员
专业程序员并不好当。
作为一个专业程序员，最重要的一条是坚守原则，为自己的承诺负责。如何坚守？在面对外界（项目经理，产品经理，客户等）强制的要求时，应该用自己专业的知识去衡量问题的可行性，而不是轻易妥协。
“试试看” 这类的词不应该从一个专业程序员口中说出，因为你说的“试试看”对你来说是代表着可能完成，可能完成不了，但是在外人听来，他们认为你说的是可以完成，而最终当问题没法在他们预期的时间完成时，受到影响的不单单是公司的利益，你的信誉也收到了损害。
所以，在面对一个自己觉得没法在指定时间完成的任务，应该坚决的说不，并且坚持这个底线。而在觉得问题可行的情况下，也应该准确的说是，并为自己的承诺负责。
专业的程序员并不代表什么都懂，他们勇于接受他人的帮助，知道什么时候该结对编程。同时，他们也乐于帮助其他人，辅导新人。他们会抽出时间去阅读，编码来提升自己。
专业的程序员对自己的每一行代码负责，没经过测试的代码绝不提交。
我们应该把“QA应该找不到任何错误”作为努力目标，对QA找到的每一个问题，都应该高度重视、认真对待。应该反思为什么会出现这种错误，并采取措施避免今后重犯。
测试驱动编程（TDD)
什么是TDD？简单来说就是：先写测试，再写功能。这听起来好像很扯，但是了解其意义之后，你会为TDD喝彩。
因为自己这段时间也在负责部门 React-Native 项目单元测试的实践（不过并没有执行TDD，而是采用了相反的方式，即先功能后测试）。
过程中，深刻体会到单元测试其中的一个好处：强迫自己抽象，再抽象。为了让自己所写的函数可测试，你需要做到尽量让其内部逻辑简洁，单一，耦合性低，否则你根本就测不了它，或者说你要写更多的case才能完整覆盖它。
其好处自然就很明显了：
- 通过测试的代码，我们可以很有信心的将他提交；
- 简洁的代码，既提高其可读性，也提高其健壮性。
TDD相关的书籍我没阅读过，借助作者的简单描述，我在项目的一个模块重构上做了实践，效果是真不错。之后也打算更深层次的去理解它，并在以后的项目上加以实践。
作者提到了TDD 的三项法则，这里摘抄了下来：
- 在编好失败单元测试之前，不要编写任何产品代码；
- 只要有一个单元测试失败了，就不要再写测试代码：无法通过编译也是一种失败情况；
- 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。
时间管理
这部分应该说不单单是面向专业程序员，而是面向所有希望走向成功的人。
毫不夸张的说：能否对自己时间有个好的管理是决定你能走多远的必要条件。但是我们大多都做的不够好，甚至一塌糊涂。从专业程序员角度，作者也说了下面几点：
- 如果发现参加某个会议是在浪费时间，就应当想个礼貌的办法退出来，继续参加对你没有太多意义的会议，是不专业的行为。你有责任合理分配老板给你的时间和金钱，所以，选个合适的机会离席，并非不专业的行为。
- 如果观点无法在短时间（5-30分钟）里达成一致，就永远无法达成一致。唯一的出路是，用数据说话。
- 注意力点数会随时间流逝而减少，使用合理的方式进行恢复：充足的睡眠（不熬夜的情况下7-8个小时足够了）；也可以选择小憩，看杂志等方式；另外可以通过训练肌肉注意力（骑车，吉他等方式）来提升自身的心智注意力。
- 番茄工作法
- 如果你掉进了坑里，别挖
- 陷入泥潭，别继续往前
在参加会议这块，我经常表现的不够专业，参加了一个会议或者讲座，发现根本听不下去或绝对对自己没什么用处，但是又不好意思中途离开，所以就干脆玩起了手机。最后讲座没收获，自己时间也浪费了。在看了作者说的话后，默默的给以后的自己提了个醒。
番茄工作法的书籍我也读过，也因此在App Store上买了个便宜的软件（穷哭），但是实践起来是真的难，排除掉那些繁琐的步骤，你需要做的就是：
- 列出你当天要做的事情；
- 启动番茄钟（一般设置25分钟），开始执行任务；
- 时间到就停止手中的事情，休息5分钟。（3个番茄钟结束后休息15分钟）
难就难在，在番茄钟的25分钟里，你需要专注，高效率的去执行。但是，自身的注意力以及外界的突然打扰总是会让我分心。这一分心，回头再看下时间，番茄钟快结束了，我还什么都没做呢。
番茄钟工作法其中一个重要原则是：严格按照番茄钟去工作，该工作时认真工作，该休息时认真休息。这样做的好处是：可以培养你在短时间内快速进入专注状态，因为你必须在这25分钟里高效输出。
番茄工作法我目前也在实践着，不过每次受到外界因素影响时我都没法说出：等我20分钟之类的话。当我能很好的去遵循番茄工作法时我也会给大家分享下我更多的心得。（番茄钟到了，我休息5分钟）
代码总是会随着业务功能的增删改而变的混乱，之前设计很好的实现方式，也会逐渐不适用，这时是选择继续用这种设计方式去实现新功能，还是推翻重构呢？作为专业程序员，应该清楚的认识到，继续以这种方式去迭代，只会导致后面开发效率越来越低，代码也变得很难维护。刚进入泥潭你可能可以继续往前，但是你会发现，你会越走越慢，最后进退两难。所以，重构是明智的选择。
引用书的最后，触动到我的一句话：
你还记得你写的第一个程序跑起来的那个时刻吗？它改变了你的生活并指引你大步踏上编程之路了吗？
