读《程序员修炼之道》
2024-07-06 05:05:44
很早之前，在初步工作的时候，我的上级推荐了这本书，但那时忙于工作，没有阅读。
最近闲下来了，无事读了一下，只觉得很鸡肋。倒不是书里边说的不对，而是很多话很务虚。
对于职场新人来说，这书是有用的，但对于老工具人来说，这些说的大概率是基本常识。
正文
本来想按照书中的目录来做摘要，但是想了想，我觉得还是按照自我理解进行总结比较好。
这本书的核心，是给新手上路的程序员梳理了一套工具人的做事准则和标准，讲的更多是偏向于思路和准则，而非具体的行事手段。
所以，这里也只是做个概括和总结，不会在细节上深入探讨。
角色分类
于个人而言，一个程序员能在开发团队中无非扮演三个角色：协调者，开发者，项目猎手。
项目猎手：负责和甲方进行需求谈判，往往会承担一定的产品经理的功能。这个角色不要求有多少开发能力，更偏向于设计者和商务人员，需要非常强的沟通能力。如果有很深的商务或政治背景，那更是如虎添翼。因为我涉及的比较少，所以这里不会涉及更多的讲解。
协调者：一般是项目组长，团队leader，负责协调工程开发的人员和工期安排，以及其他的资源调度。
开发者：工具人，负责解决具体的目标的落实，高级开发会负责攻克技术难点，普通开发负责完成常规的堆量任务。
通用准则
这里首先列举一些通用准则，无论是协调者和开发者，都需要遵循的做事准则。
- 不断学习，提升个人开发能力，对个人开发能力的提升，都是毋庸置疑的，不过协调者只需要了解大概，后者则需要将开发技术用到纯熟。
- 提供方案，而非借口，无论是推卸责任，还是挑起大梁，当项目发生问题的时候，需要的是一个至少是能说服大多数的解决方案，而不是随意的借口用来推脱，很多项目成员用借口来推脱工期，很容易造成项目整体的迟缓。
- 防微杜渐，不要破窗，在项目工期允许的情况下，尽可能的不要留下烂代码，这些埋下的雷，早晚会让自己陷入项目崩溃。
- 不要技术追星，稳定压到一切，项目中使用新技术，一定要保证自己能够把持住，否则新技术的使用，有可能让项目整体陷入停摆。
- 模块不耦合，独立功能块，功能尽可能的独立分割，这会让工程问题的排查和联调方便很多，后续独立升级也会方便。
- 学习项目领域的知识，无论是开发人还是协调人，对于项目涉及领域的知识都要有一定的学习，这样才不会被甲方牵着鼻子走。
- 文本工具很重要，除非个人的记忆能力几乎达到过目不忘的地步，否则不推荐脑记，最好用本子或者是文本工具记录每日的需求及任务，管理好需求。
协调人角度
- 有敏锐的技术嗅觉，做项目的变革者，如果一项新技术能大幅缩短开发周期，减少工作量，那么在你能掌握的情况下，可以试着引入项目中，推动项目变革，这需要你来做这个决断，也需要靠谱的组员来执行，请确定自己的团队在整体有意愿升级的情况下，再做出这个决定。
- 不做最终决定，尽可能做预案，如果你是甲方，可以无视。但是大多数情况下，我们只能不断和甲方做沟通，给出一个方案，然后在确定一个基础版本的情况下进行迭代，推进任务进度。
- 牢记全景，关注进度，无论是每日的快速会议，或者是日报周报，都是为了增加对项目的掌控力，不至于让开发进度失控，目前常规的做法就是日报周报，但是如果你对团队足够信任，团队又足够的自律，其实只需要周报即可。
- 做好版本管理，一个稳定的版本管理，会让所有的意外都有个回档点，这会让所有人的工作量有个读档位置，作为协调者，一定要管理好每人每日的工作量。不然团队工作量的丢失会让团队闹出很大的不愉快。
- 做好评估，排好日程，安排任务的时候，如果时间允许，就要预留一些冗余的时间来防止意外，而任务一旦确定，就要在管理平台或者是文本上做好记录，这便于后续做工作量的评估和管理
开发人角度
相对于协调人的角色，我更多的扮演了开发人的角色，所以这里会更多的提到开发角色应做的事情。
做事准则
- 学会反馈，做好沟通，所谓的沟通不是那种世俗的拍马屁，那种狗屎一样的传统文化必须尽早放弃。这里的沟通，更像是游戏中的报点和卡位，你的反馈就是项目协调者的眼睛，哪怕你遇到了解决不了的问题，一定要反馈，这样协调人才知道给你批多少时间才能解决你遇到的问题，需要给你协调什么资源解决这个问题。
- 不越雷池半步，不要画蛇添足，每次任务迭代，要做什么事情，在任务规划好之后，完成自己的任务即可，不是自己完成部分，不要动，哪怕你知道那里有问题，要和协调人反馈，告知他问题所在及解决时间和方案，由协调者确认后再开始评估。
- 自行开荒，他人即地狱，不要随意让他人涉及你的代码！这是你的工作！哪怕是实在解决不了的地方，在和团队中的高手沟通后，你只有两个选择，要么这个模块不归你负责，要么此后独自开荒。哪怕是一片荆棘，这条路也必须是你来走。
- 做好开发者的个人信用，如果你承担了任务，哪怕再难也只能完成。你的完成程度，将决定协调者对你的评级，决定同为开发人对你的评价，做好开发任务，会让你在团队中成为可靠的存在，这会让你在技术方案决策中拥有更好的话语权。
- 不要动已经很稳定的东西，这点是违反书籍里的说法的，但是实际操作的过程中，无数次验证了这个信条，当一样代码运行的很稳定的时候，不要随意的改动。除非是协调人给了充足的时间去重构，否则这里的变动会让整个项目发生崩溃。
编码准则
- 简单有意义的命名，开发过程中，不要随意命名，这会让团队和自己最后陷入迷魂阵，增加开发难度，拖延开发进度。
- 用简单快速的算法实现任务，早年会对算法的速度有要求，但是现在机器性能上升，可以考虑用简单的算法，这样便于他人接手，也便于自己排查。当然，如果能明显的提升速度，那么就用更快速的算法实现任务。
- 多做测试，虽然开发的最后会有测试来做评价，但是实际开发的过程中，如果自己测试好，保证自己的开发质量，那么在后续的联调中，将会非常容易的完成对接，减少工作量。
- 保持简洁，代码的实现不要整的太过于复杂，在保质保量的情况下，越是简单的代码，越好排查。
- 倾听直觉，当你觉得代码编写总是出问题，举步维艰的时候，可以停一停，和他人交流或者去搜索引擎查查方案，这是你的直觉在告诉你，有更简单的方案。
结语
本书毫无疑问是新手程序员的上路指南，很全面，很基础，挺好的。
但阅读体验不佳，笔者似乎是奔着写论文的感觉来说的，行文很拧巴，也可能是翻译腔的问题。
只能说上级推荐的时候，对当时的我来说很有用，但是现在的我已经远不是当初的我了。
参考书籍
《程序员修炼之道通向务实的最高境界(第2版)》