forked from qiubaiying/qiubaiying.github.io
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
1e07aa2
commit 115bd01
Showing
1 changed file
with
213 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,213 @@ | ||
| # 前序 | ||
| 《小工到专家》 2005年出版 | ||
| 《通向务实的最高境界》第二版 2020年出版 | ||
|
|
||
| Andy Hunt是一位木匠和音乐家 | ||
| Dave Thomas细化驾驶单引擎飞机 | ||
| 书中提出：“编程是一种技艺，一种需要用心学习的技艺” | ||
|
|
||
| 涵盖的主题：个人责任、职业发展、代码保持灵活、易于改编和复用的各种架构技术 | ||
| 目标是： | ||
|  | ||
| 适用对象：初学者、有经验的程序员 | ||
|
|
||
| 建议： | ||
| 1、尽可能阅读原著，看一手信息，减少翻译过程的gap | ||
| 2、每一个原则都需要细品，多读几遍同时必须要实践 | ||
| 3、频繁的高强度的外部刺激（遇到的项目、团队）和自主的有意识的反复提醒有利于加速原则和知识的内化 | ||
|
|
||
| 陈述的方式：书中的观点+背景+解决方案+结合材料展开（网上的例子、观点、附录中提到的论文和资源） | ||
|
|
||
| # 个人成长 | ||
| ## 我的源码让猫给吃了 | ||
|  | ||
| ### 负责 | ||
| 原则：提供各种选择，不要找蹩脚的借口 | ||
| 背景：你承诺确保某件事情正确完成，但是不一定可以直接控制事情的每一个方面，除了尽可能完成之外，还必须得先分析风险是否超出了控制。 | ||
| 解决方案： | ||
| 分析风险是否可控 | ||
|
|
||
| - 如果是风险无法控制的事情，有权不为项目的结果负责 | ||
| - 如果同意为项目的结果负责，出现问题时，不是找借口，而是给出各种可行的解决方案。 | ||
| - 如果需要额外的资源，不要害怕提出要求，也不要害怕承认需要帮助 | ||
|
|
||
| 举例： | ||
|  | ||
|
|
||
| ## 你的知识资产 | ||
| 知识资产是有时效的。 | ||
| ### 工程师如何学习？ | ||
| #### 书中观点 | ||
|
|
||
| - 每年至少学习一种新语言。不同语言以不同方式解决相同的问题，可以帮助拓宽思维 | ||
| - 每季度阅读一本技术书籍。 | ||
| - 技术深度：阅读和项目有关的书籍 | ||
| - 技术广度：阅读和项目无关的书籍 | ||
| - 参加本地用户组织。不要只是去听讲，而要主动参与。打听公司以外的人在做什么 | ||
| - 持续投入学习，保持技术敏感度 | ||
| - 批判的思考你读到的和听到的 | ||
| #### 引用观点 | ||
| 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)：开发者没有意识到他们在重复信息 | ||
| - 来自于设计中的错误 | ||
| - 可以因为性能原因而选择违反DRY原则，但是需要将影响局部化，对DRY原则的违反没有暴露给外界。 | ||
| - 经常发生在需要缓存数据的时候，只有类中的方法需要关注DRY,“保持行为良好” | ||
| - 无奈性的重复(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) |