程序员修炼之道-从小共到专家9月第一次
该书作者是 Andrew Hunt 和 David Thomas。他们都是敏捷宣言的17个创始者之一。Andrew还是敏捷联盟（Agile Alliance）的创始人。David 则是著名的 DRY(Don’t Repease Yourself) 一词的发明者。这本书也广泛出现在各类计算机推荐书单之中，其受欢迎程度不言自明。
1、开发过程中出现未曾预料的技术问题，交付晚了等情况，没关系，这些是无法避免的。发生了，我们就要尽可能想方设法地职业的去处理它们。程序员这个职业需要诚实和坦率，要敢于承认自己的错误。
2、要对担负的东西负责，如果某些东西真的超出了你的控制范围可以不处理，需要尽早提出这个不可控的点。自己职责所在的事情就需要为其结果负责。当结果不达标，比如磁盘垮了，但你却没有备份代码，那这就是你的错。不要为出错的情况找借口，想老板说"我的源码让猫给吃了”，对问题没有任何帮助，而要向他们提供可行的解决方案，做什么能够最大的挽回局面。
第二节：软件的熵
1、熵是一个热力学概念，指的是在某个系统中的“无序”的总量，热力学定律指出宇宙中的熵总是倾向于最大化。软件工程里中也存在这么一个定律，工程越庞大，代码的“无序”状态越严重。
2、破窗理论指出，当一个东西本身就破旧时，不但没人爱惜，还会朝他仍石头，导致更多破窗。软件开发中也一样，如果我们项目留有很多“破窗户”（低劣的设计、错误的决策、糟糕的代码），之后接手的人也会倾向于是它变得更糟糕。如果代码很漂亮，你自己以及之后接手的人，都可能会格外注意，不把它弄脏的。所以我们应该尽早处理工程中遗留的问题。
第三节：石头汤和煮青蛙
1、三个士兵返乡，路上饿了，路过一个村子，想跟村民借点吃的，但村民粮食贫乏不愿意出借。士兵们没有气馁，他们煮开了一锅水，往里面放了几块石头。村民好奇为他们在干嘛，士兵解释，这叫石头汤，如果能放点胡萝卜的话会更好喝。村民跑回家拿来了胡萝卜，士兵说如果放些土豆会更美味，又有人跑回家带来了土豆。后面又有人加了别的东西，最后士兵和大家一起吃了一顿饱饭。
2、有时候你确切的知道自己需要什么以及怎么做，但请求许可这件事往往会遭遇拖延和漠然，每个人都会护卫他们自己的资源，这让事情变得复杂，这叫“启动杂役”（start-up fatigue）。这时候我们不应该等着所有事情都准备好，而应该先拿出“石头”煮起来，就是想让事情启动起来。只要是有益的事情，你把做出的一部分结果拿给别人看，然后告诉他们如果加的别的什么会更好，大家一般都会帮忙的。
第四节：足够好的软件
1、使质量成为需求问题。很多时候对于质量的评估都是开发人员在进行，我们对质量要求低，交付时会出现很多问题，我们对质量要求高，会很大程度延误工期。所以指定需求时，把质量这一块考虑进去，在商定的时间内，由产品或者客户决定他们可以接受的质量是什么样的。
2、没有完美的软件，应该知道何时止步。今天了不起的软件常常比明天的完美软件更可取。及早让客户使用，他们的反馈常常会把你引向更好的解决方案。
第五节：你的知识资产
1、本杰明·富兰克林说过：知识上的投资总能得到最好的回报。这没问题，但遗憾的是知识是有时效的资产，特别是计算机领域。我们可以把我们了解的技术实现、工作经验视为知识资产，并使用管理金融资产的形式管理这些知识。
2、经营知识资产可以从以下方面进行：
定期投资：定期投入时间学习，即使很小的投资也是很重要的。
多元化：作为底线我们需要对当前所从事的技术熟练掌握。但不要就此止步，技术的发展变化很快，掌握的知识越多，就越能更好的进行调整，赶上变化。
管理风险：不要把所有的“技术鸡蛋”放到一个篮子里。
低买高卖：新技术流行之前就掌握它往往比之后跟风再学得到更大的回报。
这些知道方针里最重要也是最简单的就是：定期为你的知识资产投资。
3、具体方案介绍
每年至少学习一种新语言。
每季度阅读一本技术书籍，习惯之后可以一个月就阅读一本。
也要阅读非技术书籍，记住计算机是由人使用的。
在本地大学或者网上系统地学一门课程。
体验不同的环境，如果你只在 Windows 上工作，可以试下 Unix。如果你只使用某一种 IDE 那可以试试其他 IDE。
第六节：交流
1、知道你想要说什么
当我们面临会议，重要通话，或者只是撰写技术文档，问下自己你要表达的中心想法是什么，围绕这一点进行展开。
2、了解你的听众
比如你要做一场分享，你可以按照 WISDOM 的形式思考这几个问题：
你想让他们学到什么
他们对你讲的什么内容感兴趣
他们有多富有经验
他们需要多少细节
你想要谁拥有这些信息
你如何促使他们听你说话
3、选择风格
传达一个消息，可以是正式的邮件，黑板上的绘图，口头描述，及时消息，选一个适合你的目的的方式。
4、让文档美观
技术文档不光要注意内容也要注意形式，使用 LaTeX 或者 Markdown 进行排版。
5、让听众参与
引导他们提问，以问答的形式推进分享进程。
6、回复他人
你说什么和你怎么说同样重要。尽量不要忽视别人的询问，即使回复他们稍后再联系都会更好一些。
第七节：重复的危害
1、可靠的开发软件，并让我们的开发更易于理解和维护的唯一途径，是遵循我们称之为 DRY 的原则：系统中的每一项都必须具有单一、无歧义、权威的表示。
DRY 是 Dont’t Repeat Yourself 的缩写。
2、重复的产生通常有以下种类：
强加的重复。开发者觉得他们无可选择，其实是有一些方法让我们避免重复的。
无意的重复。开发者没有意识到他们在重复信息。这个需要通过提高代码意识或者 CR 进行减少。
无耐性的重复。开发者偷懒，因为重复可以让事情更容易。有时往往会遇速则不达，在这类重复面前我们应该更慎重。
开发者之间的重复。同一个团队或者不同团队的几个人重复了同样的信息。需要一个统筹的人引导大家交流，提供一个中央区域，管理维护公共代码。
第八节：正交性
1、正交性是一个从几何学中借鉴而来的术语，如果两条直线相交成直角，他们就是正交的。这在向量中的解释是沿着一条直线移动，你投影到另一条直线上的位置不变。
在计算机中，该术语用于表示某种不相依赖性或解耦性。
2、正交的好处是它提高生产效率，各个组件不相互依赖，使得改变得以局部化，促进复用，对于正交组件进行组合也可以提高生产效率，同时它还降低了代码的风险。
3、延伸开来，项目团队的配合也应该遵循正交性。如果成员之间任务重叠较多容易让大家疑惑问题和责任的归属如何划分，这会造成配合的效率低下。
代码设计的时候也应该尽可能考虑正交性，这需要结合一些特定的设计模式以达成目的。
第九节：可撤销性
如果某个想法是你唯一的想法，再没有什么比这更危险的事情了。在设计软件时，我们需要为可能出现的某种错误做准备，比如数据库的更换，开发平台的更换。这需要我们设计之初就考虑到构建一个相对灵活的架构。
第十节：曳（ye）光弹
1、在黑暗中使用机枪射击有两种方式。
方式一：你需要知道目标准确的位置，然后考虑当时的温度、湿度、气压、风力等一系列因素，计算完位置之后进行射击。
方式二：使用曳光弹，发射时，曳光弹中的磷点燃，会照亮它经过的地方和最终位置，我们用曳光弹确认位置之后，就不需要那些繁杂的计算，直接使用机枪进行射击。
2、在黑暗中发光的代码。通常一个项目的开发是非常复杂的，如果只是一个模块一个模块的开发，我们可能直到最后才能确认项目运行情况。更好的做法是，我们要让系统尽早的跑起来，然后根据需要给它完善细节。这样会有以下好处：
用户能够及早看到能工作的东西。
开发者构建了一个能在其中工作的结构。
你有了可用于演示的东西。
你能够感觉到工作进展。
本文作者：阳
本文链接：https://www.cnblogs.com/lmyy/p/16734206.html
版权声明：本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步