文章摘要 RisingIce

加载中...|

此内容由DeepSeek根据文章生成，未经过人工审核，仅用于文章内容的解释与总结 投诉

一、前言 ​

实习的时候部门头头给了我一本书，叫做《程序员的README》，我更愿称之为程序员的自我修养，书中内容更多的是教你如何应对代码之外的事情，内容通俗易懂，很适合程序员刚入门时的读物。最近也是在看这本书，正好分享一些书中的摘抄以及个人心得。

书的主旨是针对如何改进、如何学习、如何推荐职业生涯发展、以及如何成为一名更好的开发者提供不同的方法和步骤。包括适应团队的工作流程、处理会议、如期交付、善用学习工具和技术领域的最佳实践，指导人们如何成为团队中有价值的成员。

二、步入自觉阶段 ​

马丁•布罗德威尔将能力分为了四个阶段:

1. 无意识的无能力:意味着你无法胜任某些任务,并且没有意识到这种差距
2. 有意识的无能力:意味着你无法胜任某些任务,但你已经意识到这种差距
3. 有意识的有能力:意味着你可以通过努力完成某项任务
4. 无意识的有能力:意味着你可以很轻松的胜任某些任务

所有的工程师都是从前两个阶段开始，目标是尽快进入第三个阶段

2.1 如何学习 ​

1.在实践中学习

在实践中学到的东西要比你只坐在那单纯的阅读要学到的到的多得多，积极的编写代码并且发布你的代码，尽你所能的去理解你工作会造成的影响，并以适当的谨慎程度行事；

错误是不可避免的，降低风险和让这些错误不那么致命是你的管理者和团队的工作，如果失败了，不要被击垮，写下这次的经验教训，然后继续前行。

2.运行实例代码

运行实例代码会让你真正的了解代码的工作原理，你可以在生产环境之外运行他们，在非生产环境运行实例代码有一个好处就是允许你使用一些具有侵入性的技术。

比如你知道某个方法被调用了，但是不知道这个方法是怎么进行的，你可以抛出一个异常，输出一串堆栈跟踪信息，或者附加一个调试器来查看调用层级。

在复杂的情况下，调试器在面对多线程的时候输出的调试信息可能会对你产生误导，因为每个线程都在向这个接口写入信息，输出的信息会交错在一起无法辨别

一个简单但有用的方法就是在程序执行的入口和出口Logger或者Print一下，搞清楚函数的输入输出。

3.阅读

阅读的内容有很多：团队文档、设计文档、代码、书籍、论文、技术网站；如果你不知道从哪些地方开始，你可以从团队文档和设计文档出发，这些文档会给你一个整体的概念，这样你就可以深入的研究与人工作相关的子系统了

代码从不会说谎，但注释有时候却会，源代码并不总是与设计文档相吻合，所以阅读源代码可以让你更加准确的理解项目的需求以及实现效果

阅读高质量的开源项目，留意其中的惯用写法和风格，学习这种写法并加以运用到自己的代码中

4.观看讲座

你可以从一个优秀的教程、技术讲座中学到许多东西，可以用1.5倍速甚至2倍速观看，节省时间，记得做笔记来帮助记忆，并且学习其中出现的任何不熟悉的概念或者术语

5.适度地参加会议和聚会

会议和聚会非常有利于建立联系和发现新的想法的，它们值得偶尔的参加，但不能过度。

这些提到了一个新概念：信噪比，简单来说就是有价值的内容与所有内容的比例，这里是在说会议和聚会的所交流的信息是非常繁杂的，且不一定都是具有价值的。

会议和聚会的分类：

6.跟班学习并同有经验的工程师结对

跟班学习是指另一个人执行任务的时候跟着他，跟随着作为一个积极的参与者做笔记并且提出问题，这是一个学习新技能的好方法

结对编程是指两名工程师一起写代码，轮流打字，这是互相学习最快的方法之一，并且可以提高你的代码质量

7.用副业项目实践

从事副业项目会让你接触新的技术和想法，当只有你自己工作时，你可以更快速的学习新技术，也可以参加开源项目，大多数的开源项目欢迎所有人贡献力量，这也是一种学习和建立职业联系的好方法，找到你有兴趣去解决的问题，并使用你先学习的工具来解决这些问题，一个你感兴趣的目标会激励你更长时间的参与进去，从而学到更多的知识

2.2 学会提出问题 ​

1.动手调查一下

尝试自己寻找答案，不要局限互联网搜索，善用AI，AI可能不会给你这个问题的答案，但它可能会给你解决这个问题的灵感，记录下你寻找答案的过程，你做了什么，为什么这么做，以及最后学到了什么

2.设置一个时间限制

在你开始研究之前，考虑你最终何时需要答案，设定好你研究一个问题时预期花费的时间，防止收益递减，留出足够的时间来提出问题，得到回答。在你达到了设定的时间限制就需要请人帮忙，学会及时止损。

3.写下全过程

在提出问题的时候描述你已经知道的情况，不要只是提出问题的概念，多描述出现该问题的前置条件，是否属于小概率事件，指出这个问题的紧急程度，简要的描述你所做的尝试和发现

4.不要打扰正在工作的成员

当你被问题卡住的要询问别人问题答案的时候要观察别人的状态，走上去与人交谈会迫使他们作出反应，是他们失去了注意力，如果你需要的人很忙，同时你又被自己的工作进程卡住，学会找到一种异步沟通的方式，说人话就是等别人不忙的时候再去询问问题答案

5.多用“非打扰式”交流

将你的问题发送到一个组而不是个人目标，这样大家可以在自己的位置上做出回应，解决方法也变得可见，其他人以后也能找到当时讨论的内容

6.批量处理你的同步请求

面对面交流可以快速地解决很多问题，但可能会打断团队成员的工作效率，将你的非紧急问题都写在清单上，在周会上一并提出

2.3 克服成长的障碍 ​

这里引出了成长道路中可能会出现的障碍：

1.冒充者综合症

自己明明把工作完成的很好，但一直不相信自己，经常陷入自我怀疑。

解决方法：不要忽视赞美和成就，如果有人称赞你，那是因为他们有充分的理由这么做，重塑自己消极的想法

规划你要完成的任务，注意你完成任务的时候，这样有助于建立信心

2.邓宁-克鲁格效应

与冒充者综合症相反，邓宁-克鲁格效应是认知偏差，认为自己比实际情况更有能力，不能准确的评估自己和他人的表现，批判公司的技术栈，抱怨代码的质量等等

解决方法：有意识的培养好奇心，对犯错持开放态度，培养权衡利弊的心态

2.4 行为准则 ​

三、玩转代码 ​

3.1 软件的熵 ​

含义：混乱的代码是变化的自然副作用，这种无序的趋势被称作软件的熵。

可能的原因：

1. 同开发者可能会误解其他人的代码，也会有编写风格上的差异
2. 不断进步的技术栈和不断发展的产品需求从而导致混乱
3. bug修复和性能优化带来的复杂性

3.2 技术债 ​

技术债是造成软件的熵的一个主要原因，它指的是为修复现有的代码的不足而欠下的未来工作。你不同意的技术决策不是技术债，你不喜欢的代码也不是，要成为技术债，这个问题必须迫使团队"支付利息"，通常是因为项目需要紧急交付而必须冒着出发严重问题的风险去编写代码。

本金：需要修复的原始不足

利息：随着代码的发展没有解决的潜在不足

马丁·福勒将技术债分为了一个2x2的矩阵：

1. 谨慎的、有意的技术债是技术债的典型形式：在代码的已知不足和交付速度之间进行的务实的取舍，只要团队有规划的解决这个问题，这就是好的债务
2. 鲁莽的、有意的技术债是团队在面临交付压力的情况下产生的。通常会出现“.......就.......”或者“........只是.......”这种词就是在暗示讨论的内容是鲁莽的债务
3. 鲁莽的、无意的技术债来自“不知道自己不知道”,可以通过代码评审和持续化的学习的方式来减轻这种债务的危险
4. 谨慎的、无意的技术债是成长经验积累的自然结果，有些教训只有在时候才会被吸收，这种债务是在出问题的领域的反思学习或者作为一名开发人员的必经之路。健康团队会使用诸如项目回顾等做法来发现无心之债，并讨论什么何时以及是否偿还。

总结：技术债是无法避免的，因为你无法防止无意中的错误，技术债甚至可能是成功的标志，因为只有项目存活足够长的时间，才会变得无序

如何解决技术债：

1. 短期来看：偿还技术债会拖慢交付的速度，而承担更多的技术债会加速交付
2. 长期来看：偿还技术债会加快交付的速度，承担更多的债务会减缓交付

解决技术债的正确平衡点很大程度取决于当前所处的环境