读《程序员修炼之道》
2024-12-09 11:13:16

很早之前,在初步工作的时候,我的上级推荐了这本书,但那时忙于工作,没有阅读。

最近闲下来了,无事读了一下,只觉得很鸡肋。倒不是书里边说的不对,而是很多话很务虚。

对于职场新人来说,这书是有用的,但对于老工具人来说,这些说的大概率是基本常识。

正文

本来想按照书中的目录来做摘要,但是想了想,我觉得还是按照自我理解进行总结比较好。

这本书的核心,是给新手上路的程序员梳理了一套工具人的做事准则和标准,讲的更多是偏向于思路和准则,而非具体的行事手段。

所以,这里也只是做个概括和总结,不会在细节上深入探讨。

角色分类

于个人而言,一个程序员能在开发团队中无非扮演三个角色:协调者开发者项目猎手

项目猎手:负责和甲方进行需求谈判,往往会承担一定的产品经理的功能。这个角色不要求有多少开发能力,更偏向于设计者和商务人员,需要非常强的沟通能力。如果有很深的商务或政治背景,那更是如虎添翼。因为我涉及的比较少,所以这里不会涉及更多的讲解。

协调者:一般是项目组长,团队leader,负责协调工程开发的人员和工期安排,以及其他的资源调度。

开发者:工具人,负责解决具体的目标的落实,高级开发会负责攻克技术难点,普通开发负责完成常规的堆量任务。

通用准则

这里首先列举一些通用准则,无论是协调者和开发者,都需要遵循的做事准则。

  1. 不断学习,提升个人开发能力,对个人开发能力的提升,都是毋庸置疑的,不过协调者只需要了解大概,后者则需要将开发技术用到纯熟。
  2. 提供方案,而非借口,无论是推卸责任,还是挑起大梁,当项目发生问题的时候,需要的是一个至少是能说服大多数的解决方案,而不是随意的借口用来推脱,很多项目成员用借口来推脱工期,很容易造成项目整体的迟缓。
  3. 防微杜渐,不要破窗,在项目工期允许的情况下,尽可能的不要留下烂代码,这些埋下的雷,早晚会让自己陷入项目崩溃。
  4. 不要技术追星,稳定压到一切,项目中使用新技术,一定要保证自己能够把持住,否则新技术的使用,有可能让项目整体陷入停摆。
  5. 模块不耦合,独立功能块,功能尽可能的独立分割,这会让工程问题的排查和联调方便很多,后续独立升级也会方便。
  6. 学习项目领域的知识,无论是开发人还是协调人,对于项目涉及领域的知识都要有一定的学习,这样才不会被甲方牵着鼻子走。
  7. 文本工具很重要,除非个人的记忆能力几乎达到过目不忘的地步,否则不推荐脑记,最好用本子或者是文本工具记录每日的需求及任务,管理好需求。

协调人角度

  1. 有敏锐的技术嗅觉,做项目的变革者,如果一项新技术能大幅缩短开发周期,减少工作量,那么在你能掌握的情况下,可以试着引入项目中,推动项目变革,这需要你来做这个决断,也需要靠谱的组员来执行,请确定自己的团队在整体有意愿升级的情况下,再做出这个决定。
  2. 不做最终决定,尽可能做预案,如果你是甲方,可以无视。但是大多数情况下,我们只能不断和甲方做沟通,给出一个方案,然后在确定一个基础版本的情况下进行迭代,推进任务进度。
  3. 牢记全景,关注进度,无论是每日的快速会议,或者是日报周报,都是为了增加对项目的掌控力,不至于让开发进度失控,目前常规的做法就是日报周报,但是如果你对团队足够信任,团队又足够的自律,其实只需要周报即可。
  4. 做好版本管理,一个稳定的版本管理,会让所有的意外都有个回档点,这会让所有人的工作量有个读档位置,作为协调者,一定要管理好每人每日的工作量。不然团队工作量的丢失会让团队闹出很大的不愉快。
  5. 做好评估,排好日程,安排任务的时候,如果时间允许,就要预留一些冗余的时间来防止意外,而任务一旦确定,就要在管理平台或者是文本上做好记录,这便于后续做工作量的评估和管理

开发人角度

相对于协调人的角色,我更多的扮演了开发人的角色,所以这里会更多的提到开发角色应做的事情。

做事准则

  1. 学会反馈,做好沟通,所谓的沟通不是那种世俗的拍马屁,那种狗屎一样的传统文化必须尽早放弃。这里的沟通,更像是游戏中的报点和卡位,你的反馈就是项目协调者的眼睛,哪怕你遇到了解决不了的问题,一定要反馈,这样协调人才知道给你批多少时间才能解决你遇到的问题,需要给你协调什么资源解决这个问题。
  2. 不越雷池半步,不要画蛇添足,每次任务迭代,要做什么事情,在任务规划好之后,完成自己的任务即可,不是自己完成部分,不要动,哪怕你知道那里有问题,要和协调人反馈,告知他问题所在及解决时间和方案,由协调者确认后再开始评估。
  3. 自行开荒,他人即地狱,不要随意让他人涉及你的代码!这是你的工作!哪怕是实在解决不了的地方,在和团队中的高手沟通后,你只有两个选择,要么这个模块不归你负责,要么此后独自开荒。哪怕是一片荆棘,这条路也必须是你来走。
  4. 做好开发者的个人信用,如果你承担了任务,哪怕再难也只能完成。你的完成程度,将决定协调者对你的评级,决定同为开发人对你的评价,做好开发任务,会让你在团队中成为可靠的存在,这会让你在技术方案决策中拥有更好的话语权。
  5. 不要动已经很稳定的东西,这点是违反书籍里的说法的,但是实际操作的过程中,无数次验证了这个信条,当一样代码运行的很稳定的时候,不要随意的改动。除非是协调人给了充足的时间去重构,否则这里的变动会让整个项目发生崩溃。

编码准则

  1. 简单有意义的命名,开发过程中,不要随意命名,这会让团队和自己最后陷入迷魂阵,增加开发难度,拖延开发进度。
  2. 用简单快速的算法实现任务,早年会对算法的速度有要求,但是现在机器性能上升,可以考虑用简单的算法,这样便于他人接手,也便于自己排查。当然,如果能明显的提升速度,那么就用更快速的算法实现任务。
  3. 多做测试,虽然开发的最后会有测试来做评价,但是实际开发的过程中,如果自己测试好,保证自己的开发质量,那么在后续的联调中,将会非常容易的完成对接,减少工作量。
  4. 保持简洁,代码的实现不要整的太过于复杂,在保质保量的情况下,越是简单的代码,越好排查。
  5. 倾听直觉,当你觉得代码编写总是出问题,举步维艰的时候,可以停一停,和他人交流或者去搜索引擎查查方案,这是你的直觉在告诉你,有更简单的方案。

结语

本书毫无疑问是新手程序员的上路指南,很全面,很基础,挺好的。

但阅读体验不佳,笔者似乎是奔着写论文的感觉来说的,行文很拧巴,也可能是翻译腔的问题。

只能说上级推荐的时候,对当时的我来说很有用,但是现在的我已经远不是当初的我了。

参考书籍

《程序员修炼之道通向务实的最高境界(第2版)》

Prev
2024-12-09 11:13:16
Next