diff --git "a/_posts/\347\250\213\345\272\217\345\221\230\344\277\256\347\202\274\344\271\213\351\201\223-\344\273\216\345\260\217\345\267\245\345\210\260\344\270\223\345\256\266\345\210\206\344\272\253\357\274\210\345\211\215\344\270\244\347\253\240\357\274\211.md" "b/_posts/\347\250\213\345\272\217\345\221\230\344\277\256\347\202\274\344\271\213\351\201\223-\344\273\216\345\260\217\345\267\245\345\210\260\344\270\223\345\256\266\345\210\206\344\272\253\357\274\210\345\211\215\344\270\244\347\253\240\357\274\211.md" new file mode 100644 index 00000000000..fa6541fd01d --- /dev/null +++ "b/_posts/\347\250\213\345\272\217\345\221\230\344\277\256\347\202\274\344\271\213\351\201\223-\344\273\216\345\260\217\345\267\245\345\210\260\344\270\223\345\256\266\345\210\206\344\272\253\357\274\210\345\211\215\344\270\244\347\253\240\357\274\211.md" @@ -0,0 +1,213 @@ +# 前序 +《小工到专家》 2005年出版 +《通向务实的最高境界》第二版 2020年出版 + +Andy Hunt是一位木匠和音乐家 +Dave Thomas细化驾驶单引擎飞机 +书中提出：“编程是一种技艺，一种需要用心学习的技艺” + +涵盖的主题：个人责任、职业发展、代码保持灵活、易于改编和复用的各种架构技术 +目标是： +![image.png](https://cdn.nlark.com/yuque/0/2024/png/758294/1708226382528-be0df187-941c-4fde-afe3-cee370a54e10.png#averageHue=%23121623&clientId=u46299b2b-c9a5-4&from=paste&height=716&id=u736f4573&originHeight=716&originWidth=1330&originalType=binary&ratio=1&rotation=0&showTitle=false&size=1004328&status=done&style=none&taskId=u2445e392-4636-49d4-ad05-77f37c5e913&title=&width=1330) +适用对象：初学者、有经验的程序员 + +建议： +1、尽可能阅读原著，看一手信息，减少翻译过程的gap +2、每一个原则都需要细品，多读几遍同时必须要实践 +3、频繁的高强度的外部刺激（遇到的项目、团队）和自主的有意识的反复提醒有利于加速原则和知识的内化 + +陈述的方式：书中的观点+背景+解决方案+结合材料展开（网上的例子、观点、附录中提到的论文和资源） + +# 个人成长 +## 我的源码让猫给吃了 +![image.png](https://cdn.nlark.com/yuque/0/2024/png/758294/1708228217762-077946e9-049d-476f-b3b6-4d1ea43bd163.png#averageHue=%23c7c7c7&clientId=u4140d099-0619-4&from=paste&height=610&id=u3af72dd5&originHeight=610&originWidth=1672&originalType=binary&ratio=1&rotation=0&showTitle=false&size=164038&status=done&style=none&taskId=u8cf04b65-7004-4c6d-bc86-562e46782cb&title=&width=1672) +### 负责 +原则：提供各种选择，不要找蹩脚的借口 +背景：你承诺确保某件事情正确完成，但是不一定可以直接控制事情的每一个方面，除了尽可能完成之外，还必须得先分析风险是否超出了控制。 +解决方案： +分析风险是否可控 + +- 如果是风险无法控制的事情，有权不为项目的结果负责 +- 如果同意为项目的结果负责，出现问题时，不是找借口，而是给出各种可行的解决方案。 + - 如果需要额外的资源，不要害怕提出要求，也不要害怕承认需要帮助 + +举例： +![image.png](https://cdn.nlark.com/yuque/0/2024/png/758294/1708236997941-c0f46d6c-abc4-4f7b-9d3b-95f299901471.png#averageHue=%23979797&clientId=u7c009fbc-3bc0-4&from=paste&height=250&id=u4dacc238&originHeight=250&originWidth=1656&originalType=binary&ratio=1&rotation=0&showTitle=false&size=132829&status=done&style=none&taskId=u62a76fd0-35b7-4e69-83aa-98aac415f98&title=&width=1656) + +## 你的知识资产 +知识资产是有时效的。 +### 工程师如何学习？ +#### 书中观点 + +- 每年至少学习一种新语言。不同语言以不同方式解决相同的问题，可以帮助拓宽思维 +- 每季度阅读一本技术书籍。 + - 技术深度：阅读和项目有关的书籍 + - 技术广度：阅读和项目无关的书籍 +- 参加本地用户组织。不要只是去听讲，而要主动参与。打听公司以外的人在做什么 +- 持续投入学习，保持技术敏感度 +- 批判的思考你读到的和听到的 +#### 引用观点 +go业界大佬曹大的博客关于这个话题给出了一些学习方法和经验，个人感觉非常有用 + +- 阅读书籍 + - 网络博客内容缺乏体系，不系统，很多博主为了掩饰自己的未知，不懂的关键点就一笔带过，最终获取的只是二手资料 + - 能够读懂英文技术书籍是工程师的硬实力，大部分优秀的技术书籍以英文为主 + - 英语阅读能力怎么训练？逼迫自己去翻译一些英文文档 + - 翻译The Go Programming Language + - 翻译 es权威指南 +- 信息源 + - 技术书籍存在一个明显的缺点，时效问题 + - github trending + - github trending代表一种风向， + - follow优秀的工程师 + - 希望自己能在技术上做到一直精进，同时随着年龄和工龄的增长又会时不时陷入迷茫，这时候去看看同龄的优秀工程师，年纪更大的优秀工程师在这个时间段在写什么代码，在写什么博客，可能对于解决自己特定时期的迷茫有益。或许就发现了一个新的领域值得自己去奉献青春。 + - reddit相关社区 + - 国内的社区生态被人为地割裂了，建议关注国外的社区 + - 阅读论文 + - 除了工程之外，前言的理论知识需要通过论文去了解 + - 技术会议和公开课 + - 除了阅读文字之外，阅览视频和与人面对面交流有时候不可缺少 + - youtube + - b站 + - 多做开源 + - 业务时间，用最严格的标准来要求自己编写自己的开源项目 + - 多做总结 + - 建立自己的blog + - 建立自己的blog +- 锻炼演技 + - 软技能的训练，提前做好准备 + +## 交流（可以不讲，没啥亮点） +### 书中观点 +没有有效的交流，一个好想法就只是一个无人关心的孤儿。 +如何进行交流？ + +- 知道你想要说什么 + - 规划你想要说出的东西，写出大纲，不断优化想要表达的话 +- 了解你的听众 + - 不同的观众需要获取的东西是不一样的，针对不同的人进行适当的修正 +- 选择时机 + - 要让所说的适得其时，在内容上切实相关 +- 让听众参与 + - 获取听众的反馈 +- 做倾听者 + - 鼓励大家通过提问来交谈 +#### 引用观点 + +同级交流 +向上沟通 + +# 代码架构 +## 软件的熵 +当软件中的无序增长时，程序员们称之为“软件腐烂” +原则：不用容忍破窗户 +> 一扇破窗户，只要有那么一段时间不修理，就会渐渐给建筑的居民带来一种废弃感。于是又一扇窗户破了，人们开始乱扔垃圾，出现了乱涂乱画，严重的结构损坏开始了，建筑被损毁的超出了业主愿意修理的程度，导致废弃感变成了现实。 +> “破窗户理论”启发了纽约和其他大城市的警察部门，他们对一些轻微的案件严加处理，以防止大案的发生 + + +背景：破窗户代指：低劣的设计、错误的决策、糟糕的代码 + +解决方案： + +1. 有时间：发现一个修一个 +2. 没有时间：用木板把破窗户钉起来 + 1. 出问题的代码加入注释 + 1. 显示“未实现”消息，用虚设的数据加以替代 + +## 重复的危害 + +维护不是时有时无的活动，而是整个开发过程中的例行事务，同时会发现，在我们开发的规范、过程和程序中很容易重复表示知识。 如果有多个地方表达同一个事务，需要更改其中一处的时候，必须记得改变其他各处 +原则1：DRY - Don't Repeat Yourself + +- 强加的重复（imposed）：开发者觉得他们无可选择--环境似乎要求重复 + - 编写简单的过滤器或代码生成器。 + - 根据在线数据库schema、或是最初用于构建schema的元数据，自动生成类定义 + - 把注释保留给其他的高级说明 + - 如果把注释给低级的代码，我们就是在重复知识，每一次改变都意味着既要改变代码，又要改变注释 + - 不可信的注释比完全没有注释更糟糕 +- 无意的重复(inadvertent)：开发者没有意识到他们在重复信息 + - 来自于设计中的错误![image.png](https://cdn.nlark.com/yuque/0/2024/png/758294/1708243154402-2cad43c4-72b2-4a94-ac2b-a2e4caf07a39.png#averageHue=%23d9d9d9&clientId=u7c009fbc-3bc0-4&from=paste&height=1022&id=u00961aa2&originHeight=1022&originWidth=2140&originalType=binary&ratio=1&rotation=0&showTitle=false&size=386217&status=done&style=none&taskId=ua61faee5-6d38-4158-8412-0f862fa595e&title=&width=2140) + - 可以因为性能原因而选择违反DRY原则，但是需要将影响局部化，对DRY原则的违反没有暴露给外界。 + - 经常发生在需要缓存数据的时候，只有类中的方法需要关注DRY,“保持行为良好”![image.png](https://cdn.nlark.com/yuque/0/2024/png/758294/1708243266447-a675bf4b-f2d6-48b7-9cbc-d9a766541127.png#averageHue=%23dadada&clientId=u7c009fbc-3bc0-4&from=paste&height=1066&id=u7abd6785&originHeight=1066&originWidth=1646&originalType=binary&ratio=1&rotation=0&showTitle=false&size=259060&status=done&style=none&taskId=u744bfdb4-be35-4cb2-b0aa-b219f64885e&title=&width=1646) +- 无奈性的重复(impatient)：开发者偷懒，他们重复，因为那样似乎更容易 + - 在项目有时间压力的挑战下，如果可以避免无奈性的重复，更能体现个人能力。 +- 开发者之间的重复(interdeveloper)：同一个团队（或不同团队）的几个人重复了同样的信息 + - 鼓励开发者相互进行主动的交流 + - 设置论坛讨论常见的问题，可以永久保留所有讨论的痕迹 + +原则2：Make it easy to reuse +如果复用很难，大家就不会去复用。所以要营造一种环境，让复用变得更容易 + +## 正交性 +### 书中观点 +正交性指：用于表示某种不相依赖或是解耦性。如果多个事务中的一个发生变化，不会影响其他事物，这些事物就是正交的。 +原则：Eliminate Effects Between Unrelated Things(清除无关事物之间的影响) +好处： + +- 提高生产率 + - 改动影响局部化，开发时间和测试时间降低 + - 促进复用。如果组件有明确而具体的、良好定义的责任，就可以在新场景进行复用。 和乐高的思想一致，拼乐高，实际上就是在搭积木。 + - 对正交的组件进行组合，做的事情会更多，某个组件做M件事情，另外的组件做N件事情，正交会实现M x N的效果。如果非正交，做的事情就会重叠。 +- 降低风险 + - 有问题的代码区域被隔离开来。不会影响到系统的其他部分同时更换成健康的新模块也会更容易 + - 系统更健壮。对特定区域做出小的改动与修改，所导致的任务问题都将局限在改区域中 + - 正交系统很容易得到更好的测试 + +实际应用： + +- 项目团队 + - 怎么把团队划分为责任得到了良好定义的小组，并使重叠将至最低？ + - 量化的指标：每个需求改动时需要涉及多少人。人数越多，团队的正交性越差 + - 没有简单的方案，取决于项目、变动的区域、人员 +- 系统设计 + - 使用模块化、基于组件、分层的思想指导系统设计 + - 量化的指标：如果显著地改变某个特定功能背后的需求，有多少模块会受影响。数据越多，系统设计的正交性越差 +- 编码 + - 代码保持解耦 + - 通过接口抽象的方式，实现代码内聚 + - 避免使用全局数据 + - 避免编写相似的函数 + - 策略模式 +#### 引用观点 +实际上耦合的架构、代码设计会降低效率，好的业务架构，本质想尽一切办法减少沟通，只有沟通少，效率才会高，质量才会好。 +而好的业务架构需要一些可衡量的指标 +陶文的代码防腐实用技术给出一个解法 +业务逻辑可以被拆分成： + +- 编辑时：拆分成文件、文件夹、Git仓库 + - 这种拆分标准屏蔽了不同编程语言和编程框架的影响，不用争论什么是Class，什么是Module，什么是Package。 + - 目标是：“代码防腐” + - 量化的指标（列举部分） + 1. 会议时间 + 1. 如果一个需求的改动需要花费大量的沟通成本，需要重新审视业务逻辑拆分 + 2. 接口改动/实现改动 比率 + 1. 可以指导仓库拆分的成本 + 2. 如果实现改动的非常多，指导使用配置化的方式 + 3. 过度抽象怎么衡量 + 1. 强行把一堆不相关的东西拧巴到一起，引入了“必要参数占比”和“咨询量” + 2. 必要参数占比 + 1. 调用方是否必传的参数 + 2. 如果必要参数占比过小，把一些小众场景的具体业务以额外的方式加进来了，每个额外参数都增加了调用者的负担，是额外的学习和维护成本 + 3. 咨询量 + 1. 针对的是可复用模块，模块的使用成本很高，文档不清楚，沟通成本很大 +- 运行时：拆分成进程 + - 避免拆分出来的东西见仁见智，我们只能选择不那么用户可见，但是又相对稳定的东西。进程是歧义比较少的东西。 + - 目标是：“只负责自己写的代码” + - 量化的指标（只列举部分） + 1. 故障定位时长 + 1. 孤立的一个进程很难完成所有工作。业务逻辑不可避免地要拆分成多个进程。如何找到出问题的进程。 一个进程也很难仅由一个 Git 仓库构建而来。业务逻辑不可避免地要拆分成多个 Git 仓库。如何找到进程的问题是哪个 Git 仓库造成的。 故障定位延迟是指故障从开始定位，到找到根本原因所花的时间。进程边界，Git 仓库的边界，越不依赖人的经验，越不依赖人的现场沟通，就越可能降低故障定位延迟。 + + +# 总结 +1、负责，体现在如何处理问题，应该给出多个选择方案，而不是找借口 +2、不要留破窗户，代码质量问题往往就是从一次“破窗户”开始的 +3、作为一名程序员，需要坚持终身学习，修炼内功，保持技术敏感度 +4、交流，在适当的时机说适当的话 +5、DRY原则，减少重复，关注复用 +6、抽象比细节活得更加长久 +7、自动化提效 + +# 附录 +1、工程师应该怎么学习 [https://xargin.com/how-to-learn/](https://xargin.com/how-to-learn/) +2、那些年，我从微信支付学到的东西 [https://mp.weixin.qq.com/s/qvTWcsjAPTJTEu30zapsQg](https://mp.weixin.qq.com/s/qvTWcsjAPTJTEu30zapsQg) +3、代码防腐实用技术 [https://autonomy.design/Modules.html](https://autonomy.design/Modules.html)