程序员成长那些事儿

Posted 2022-09-09 turingbooks

我是一名移动端程序员，目前已经工作六年多了。

六年的职场生涯，让我从一个职场小白，到现在从容面对各类工作挑战。

不禁感叹，时间真是过得飞快，我现在还清晰记得六年前我刚入职时的茫然无措。

最近在读《程序员的 38 堂成长课》，感触颇多，这本书分为五部分：

这五部分每一部分单独拿出来自成一体，连在一起又相得益彰，覆盖了大部分程序员成长过程中遇到的问题。

的确，程序员的成长并不是一蹴而就的。它是一个循序渐进的过程，结合此书，我想和大家聊一聊我对于程序员成长的一些看法。

编程乃余事

编程是一名程序员的本职工作，同时也是最基础的工作。

但不同程序员对于代码有不同看法：

• 初级程序员专注于功能实现，堆砌代码；

• 高级程序员兼顾功能实现与代码的健壮性，以便后期维护和拓展；

• 架构师则从全局出发，搭建项目架构，制定编码规则。

可以这么说，越往上走，你操心的事儿就越多，也更容易开始关注自己的发际线。不过从另一个角度看，如果一个发量不是很乐观的程序员去面试，很可能被面试官当做专家。

在编码的过程中，有几个值得我们注意的地方：编码规范、测试、bug 追踪、架构演进。处理好这几方面，对于提升我们的技术工作很有帮助。

1、编码规范

每一门编程语言都有自己的编码规范，每个互联网公司内部也会有自己的编码规范。

当你入职新公司的时候，首先要做的，就是通过具体的文档或者项目中现有代码，来熟悉当前公司的编码规范，然后尽量与之靠拢并保持一致。

当然，如果你感觉自己的编码规范更加合理，也可以提出来，和同事讨论决定，最终使得编码规范一致。

2、测试和 bug 追踪

艾兹格·迪杰斯特拉说过：“如果调试程序是移除 bug 的过程，那么编写程序就是把 bug 放进来的过程。”

这里的测试是指自测，而不是测试人员进行的测试。程序员如果没有自测，或者敷衍自测流程，那就代码价值就会越来越低。

保持良好状态可以防止破坏和犯罪，这就是典型的破窗效应。

《程序员的 38 堂成长课》给出了多种 bug 追踪方案，我觉得还是比较实用的，比如异常捕获（使用断言和日志）、二分法、软件考古（查询版本控制系统中提交的历史记录）、排除法、迂回策略（放空一下再回头看、说给别人听）等等。

3、架构演进

架构不是一成不变的，或者说没有什么东西是一成不变的。

就像公司的组织架构一样，有的互联网公司半年或者一年就会进行一次调整，以便适应公司的发展策略。

项目架构同样如此，随着业务的骤增或者骤减，原先的架构支撑现有业务已经很吃力，这个时候不可避免就需要进行架构演进。

刻意练习，成就卓越

作为一名程序员，日常工作中，我们或许需要注意这三个方面，以便让我们工作起来得心应手，事半功倍：

1、刻意练习

作家格拉德威尔在《异类》一书中提出了一万小时定律。“要成为某个领域的专家，需要 10000 小时（1.1415525 年），按比例计算就是：如果每天工作八个小时，一周工作五天，那么成为一个领域的专家至少需要五年。这就是一万小时定律。”

刻意练习是指的是坚持做一件事情，比如每天坚持阅读优秀源码并进行总结，想想代码这样写有哪些好处，长此以往，当你再回首看你以前写的项目代码时，发现你现在可以仅用三分之一原先的代码即可完成功能开发，并且更高效，更简洁、更安全，这就是一个成长的过程，成就卓越的过程。

2、版本控制

版本控制是代码的时间机器，使得软件考古更加容易，同时提供了中央备份。它同时支持可逆性，如果发现项目历史中的任何更改是错误的，则可以通过撤销回滚它。

版本控制系统的演进：

版本控制提交信息应当是清晰、简洁、明确，这样便于其他人以及自己以后查找回溯。

3、软件发布

软件开发流程就像是一个有机肥料的管道，但又不太正确，因为它不是一个线性过程 。

但实际开发中，这样是不可取的，主要问题出在程序员开发过程和 QA 之间的协作，正确的做法应该是紧密结合，程序员开发出一个功能模块，QA 就立马进行测试，及时反馈，这样开发人员可以尽早安排修复，以至于在最后期限前交付完美软件。

束身修行

更聪明而不是更努力的工作。

程序员最好做好如下几点，保障工作顺利进行下去：

1、自测

比如单元测试的开展，即使没有单元测试，也要有实际测试，避免一些眼高手低的问题

2、明确发布意图

不要直接把打包的内容发给测试人员，然后随便说一句“看看这个怎么样？”应该明确说明此次发布更新了哪些内容，或者修复了哪些 bug。让测试人员可以更好的抓住测试重点，避免做无用功。

3、欲速则不达

不要急于构建发布版本，因为匆忙之下做的决定大部分是不完善的，要做到心中有数。

4、自动化

你可以通过创建一个脚本来自动签出代码、进行构建、运行所有单元测试、创建安装程序和部署到测试服务器，并将构建结果及其版本说明上传到服务器，这样就可以消除多个步骤中出现人为错误的可能性。

使用自动化来避免人为错误，有助于每次都能创建可以正确安装且不包含回归的版本，QA 人员会因此而感激你。

5、尊重

不要直接将未经测试的软件交付给测试人员，以免出现尴尬局面。

6、正确看待故障报告

QA 人员发布的故障报告，被领导不经意见看到了，这个时候开发人员心理难免会犯嘀咕，你这不是故意找我茬吗？改变这样的心态~

计日成功

预防坏习惯比改掉坏习惯要容易得多。

拒绝成为荒岛式开发，没有哪个开发人员应该成为孤岛，这样做太过危险，也太过狭隘，过于拘泥于一个角度看问题，以至于看不到问题的全貌，更不用说去解决它了。

那么如何解决孤岛式开发呢？

• 结对编程，定期与其它程序员进行回顾和代码评审，以求改进。

• 适当放低个人姿态，勇于和别人交流，接受别人善意的援助。

有时候一个人很容易走进死胡同，这个时候一定要站起来休息一下，喝杯咖啡，然后找个人诉说一下你目前的想法，然后像过电影一样，这样子自己很容易就可以找到问题所在，如果实在找不到人，那么对着办公桌上面的玩具诉说也是可以的，这个还是它是你的倾诉对象。

多角度思考问题，有时候你想到的第一个方案往往不是最优的，可以发散一下思维，想多种解决方案，从中再选取最优解。

我们解决问题的态度应该是这样：最有效的解决问题，并且克服本能，不要一个人在那里低头蛮干，走入死胡同而不自知，这个只会距离解决问题越来越远，有时候要学会利用团队的力量。

寻找良师益友

我们是所处环境的产物，就像植物需要土壤和水分，需要一个良好的氛围健康成长，我们也一样。

优秀的程序员能够与同事愉快的合作共事，如果你想变得优秀，那一定要学会和别人通力合作，更要学会取长补短，从善如流。

近朱者赤近墨者黑，要刻意让自己融入到一群杰出的程序员当中，每天耳濡目染、简单而又影响深远，这使得每天都能在编程技巧和态度方面有所积累。

沟通也很重要，与机器沟通，让机器能够看懂你编写的代码，与评审你代码的人沟通，代码就是沟通的桥梁，不要让你的代码成为你个人的专属代码。

以上就是我读完这本书之后的一些感悟，共勉！

---

好书推荐

---

幽默诙谐，提炼方法和技巧

38 个话题，提升你的代码感