10x程序员工作法
by:郑晔老师
问题
忙碌原因
-
本质复杂度(Essential Complexity)
- 问题本身复杂
-
偶然复杂度(Accident Complexity)
- 选用方法不当, 导致复杂度上升
事实
- 大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题
解决
- 减少偶然复杂度引发的问题, 让软件开发工作有序、高效地进行; 优秀程序员的开发效率是普通程序员的 10 倍
如何思考
思考框架
-
要诀
-
1、现状
- where are we?
-
2、目标
- where are we going?
-
3、实现路径
- how can we get there?
-
-
需求开发思考
- 为什么要做这个特性，他给用户带来怎样的价值
- 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
- 达成这个目的是否有其它手段？是不是一定要开发一个系统？
- 这个特性上线之后，怎么衡量它的有效性？
-
原则步骤
- 1、以终为始: 工作的一开始确定好真实目标
- 2、任务分解: 找到实施路径
- 3、沟通反馈: 解决与人打交道出现的问题,保证信息对称
- 4、自动化: 解决与机器打交道出现的问题
10x工作法原则
1、已终为始
-
1、已终为始:如何让努力不白费？
-
以结果导向思考模式
- 遇到事情，倒着想，先想结果是什么样子; 反直觉思维
-
想象的共同体
-
任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）
- 其实工作中很多问题, 是第一次创造没有做好,就进入第二次创造。第二次创造成本很高, 所以需要如第一次创造上花功夫。如图纸上构思各种细节, 做产品先做原型文档再交付, 先定义接口样子再进行开发。
-
-
对做软件的人来说，我们应该把“终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来
-
-
2、完成了工作, 为什么还不满意？
-
案例
-
程序员小李的开发工作完成经常让项目经理老张不满意
-
为什么?
- 理解的鸿沟:对"终"理解存在分歧
-
怎么办？
- 弥合差异,“完成” 标准定义(DoD)
-
-
完成的定义(DoD: definition of done): 什么叫完成?
- DoD 是一个的思维模式，是一种尽可能消除不确定性，达成共识的方式
-
DoD怎么用
-
1、DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况，确保你不遗漏任何事情
-
2、DoD 的检查项应该是实际可检查的
-
3、DoD 是团队成员间彼此汇报的一种机制
- 当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”
-
-
在做任何事之前，先定义完成的标准， 杜绝理解鸿沟
-
-
3、接到需求， 要先做哪些事情
-
案例
-
程序员小李开发完登录演示小王认为还需要增加验证码功能
-
原因
- 不同的需求描述方式,影响对需求的理解，信息的传递会衰减，你不可能把你理解的信息 100% 传递给另外一个人，而这中间，如何传递，也就是如何描述将直接决定衰减的比例
- 很多软件开发基于功能列表, 列表规定程序员要做功能,程序员"照单抓药"写代码, 不理解功能背景和使用场景, 这样导致不能理解全局。
- 这种功能列表式的需求描述方式，将一个完整的需求敲成了碎片。 只有所有功能全部开发完成，对接在一起的时候，才是“破镜重圆”的时刻。但此时会有很多意料之外的事情
- 根据这种基于功能列表的需求描述，每个组在安排工作的时候，都会按照自己的理解进行功能排列。如果多团队协同, 可以想象由多糟糕
-
-
解决
-
"用户故事"的方式描述需求
-
站在用户的角度完全描述出使用场景
-
故事样子
-
标题: 故事要干什么
-
概述: 简述这个故事主要内容
-
详述:详细地描述这个用户故事的完整流程，包括操作流程、用户界面等信息。
-
验收标准: 正常使用的流程是怎样的，以及各种异常流程系统是如何给出响应的，这是程序员常常会欠缺的思考。即:正常场景,异常场景
- 验收标准非常重要的一环是异常流程的描述
- 验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量
-
-
-
-
角色转变
- 理想状况:pm用户故事方式完全描述出业务需求, 程序员专注在业务技术实现上
- 现状: pm不能完全描述, 环节缺失,
- 因此需要,扮演不同角色的时候，我们的思考模式是不同的
- 先扮演好产品经理的角色，多花点时间把验收标准制定好，再回到开发人员的角色上去写代码。毕竟，最好维护的代码是没有写出来的代码。
-
用验收的标准看需求是否明确
-
-
4、从持续集成角度看开发
- 集成本是写代码的一个环节
-
5、产品经理不靠谱, 你该怎么办?
-
用精益创业的视角衡量产品特性的有效性
-
办法
- 我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数
- 以终为始。我们是要做产品，那就需要倒着思考，这个产品会给谁用，在什么场景下怎么用呢？
- 软件开发的主流由面向确定性问题，逐渐变成了面向不确定性问题。
-
精益创业
-
解决
- 面向不确定性创造新事物
- 让人们开始理解价值创造与浪费之间的关系
-
总结
-
创造价值是每个人都能理解的，但减少浪费却是很多人忽略的
-
精益创业就是在尽可能少浪费的前提下，面向不确定性创造新事物
-
既然是不确定的，那你唯一能做的事情就是“试”
-
“开发（build）- 测量（measure）- 认知（learn）”这样一个反馈循环
-
当你有了一个新的想法（idea）时，就把想法开发成产品（code）投入市场，然后，收集数据（data）获取反馈，看看前面的想法是不是靠谱
- 得到的结果无非是两种：好想法继续加强，不靠谱的想法丢掉算了。不管是哪种结果，你都会产生新的想法，再进入到下一个循环里。在这个反馈循环中，你所获得的认知是最重要的，因为它是经过验证的。在精益创业中，这也是一个很重要的概念：经过验证的认知（Validated Learning）
-
-
精益创业提出一个非常重要的概念，最小可行产品，也就是许多人口中的 MVP（Minimum Viable Product）。简言之，少花钱，多办事
-
默认所有需求都不做，直到弄清楚为什么要做这件事。
-
-
-
-
6、解决了很多技术问题，为什么依然在"坑"里？
-
更大范围内寻找"终"
-
程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。
-
不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果
-
角色的差异
-
不同角色工作上真正的差异是上下文的不同
- 虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考
- 我并不是靠技术能力解决了问题，而是凭借对需求的理解把这个问题绕过去了
- 而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文
- 当你对软件开发的全生命周期都有了认识之后，你看到的就不再是一个点了，而是一条线
-
工作的上下文不同，看到的维度差异很大
- 单一维度的思考，在多维度思考者的眼里几乎就是漏洞百出的
-
-
扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上
-
-
7、为什么说做事情之前先要进行推演
- 沙盘推演, 从军事指挥室里学来的大学问
- 即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用
- 通向结果的路径才是更重要的
- 在动手做一件事之前，先推演一番。
-
8、工作可以用数字衡量吗？
- 数字化: 一种衡量"终"的方式
- 一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据
- 设计好测量工作有效性的指标，那么就可以更有目的性地去工作了
-
9、启动开发之前, 要准备什么?
-
迭代0： 请在开发前准备好
-
迭代前的清单
-
需求方面
-
- 细化过的迭代1需求
-
- 用户界面和用户交互
-
-
技术方面
-
- 基本技术准备
-
基础架构选型
-
数据库表结构设计
-
- 持续集成
- 构建脚本, 代码风格检查，常见的bug模式检查，测试覆盖率
-
- 测试
- 把测试当作规范确定下来的办法就是把测试覆盖率加入构建脚本
-
2、发布准备
-
数据库迁移
- flyway变更版本控制工具
-
发布脚本
-
-
-
-
-
总结
-
行业最佳实践
- DoD，确定好完成的定义，减少团队内部的理解不一致
- 用户故事，细化出有价值的需求
- 持续集成，通过尽早集成，减少改动量，降低集成的难度
- 精益创业，减少过度开发不确定性产品带来的浪费
- 迭代 0，在项目开始之前，做好一些基础准备
-
思维转变
-
任何事物都要经过两次创造
- 一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）
-
在更大的上下文内发现自己的“终”
-
通过推演，找到通往“终”的路径
-
用可度量的“数字”定义自己的“终”
-
-
如何管理上级
-
第一，管理上级的预期
- 相当于我把自己看到的问题暴露给上级，让他选择
-
第二，帮助上级丰富知识
-
第三，说出你的想法
- 会哭的孩子有奶吃
-
-
2、任务分解
-
1、任务分解：按部就班的前提
-
软件开发的任务分解
-
1、一个大问题，我们都很难给出答案，但回答小问题却是我们擅长的
-
2、任务分解的粒度: 可执行
- 不同的可执行定义差别在于，你是否能清楚地知道这个问题该如何解决
-
-
大师级程序员工作的秘笈
- 将任务拆小，越小越好
-
将大问题拆解成能够解决的小问题
-
-
2、测试也是程序员的一部分
-
开发者也需测试
- 对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码
-
测试驱动开发(TDD)，一种设计挑战
-
测试的属性：A-TRIP
-
测试种类
-
人工测试
-
自动化测试
- 测试框架最大的价值，是把自动化测试作为一种最佳实践引入到开发过程中，使得测试动作可以通过标准化的手段固定下来
-
单元测试
-
集成测试
-
系统测试
-
验收测试
-
-
测试模型
-
冰淇淋蛋卷模型
-
有些情景高层的测试不容易覆盖到的，所以，还要有一些底层的测试，比如单元测试。在这种情况下，底层的测试只是作为高层测试的补充，而主力就是高层测试
-
冰淇淋蛋卷测试模型的人并不多，它是一种费时费力的模型，要准备高层测试实在是太麻烦了， 使用较少
-
-
金字塔测试模型
- 重点就是越底层的测试应该写得越多
- 越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广
- 小事反馈周期短，而大事反馈周期长
- 当测试金字塔遇到持续集成
-
虽然冰淇淋蛋卷更符合直觉，但测试金字塔才是行业的最佳实践
-
-
测试实践
-
测试先行开发(Test First Development)
- 先写测试后写代码
-
测试驱动开发TDD（Test Driven Development）
-
开发节凑
-
红 - 绿 - 重构
-
红，表示写了一个新的测试，测试还没有通过的状态；绿，表示写了功能代码，测试通过的状态；而重构，就是再完成基本功能之后，调整代码的过程
-
重构与测试是相辅相成的：没有测试，你只能是提心吊胆地重构；没有重构，代码的混乱程度是逐步增加的，测试也会变得越来越不好写
- 因为重构和测试的互相配合，它会驱动着你把代码写得越来越好。这是对“驱动”一词最粗浅的理解
-
-
-
-
测试驱动设计
- 编写可测试的代码
- 我的代码怎么写才是能测试的，也就是说，我们要编写具有可测试性的代码
-
瀑布开发方法
-
-
-
3、需求的拆分:用户故事
-
问题
- 基本上，闯入你脑海的需求描述是主题（epic），在敏捷开发中，有人称之为主用户故事（master story)
- 绝大多数问题都是由于分解的粒度太大造成的，少有因为粒度太小而出问题的
- 用户故事，它将是我们这里讨论需求管理的基本单位
-
需求要分解
-
用户故事原则
- 1、Independent，独立的
- 2、Negotiable，可协商的
- 3、Valuable，有价值的
- 4、Estimatable，可估算的
- 5、Small，小
- 6、Testable，可测试的
-
-
需求的估算
- 估算的结果是相对的，不是绝对精确的，我们不必像做科研一样，只要给出一个相对估算就好
- 一般来说，估算的过程也是大家加深对需求理解的过程
-
-
4、优先级管理：做最重要的事情
-
需求分解之后，最重要的是，排列需求的优先级。优先级的排列方式有很多，我们可以借鉴时间管理的方法，把事情按照重要和紧急的维度进行划分，得到了四个象限。我们要尽可能把精力放在重要的事情上，而不是把紧急的事情当成优先级排序的方式
-
确定事情的重要程度, 一种方式就是找回丢失的上下文，如果无法判断好的办法, 那就引入外部更大的上下文
-
-
5、最小可行产品:找到一条可行路径
-
产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。最小可行产品就是“刚刚好”满足客户需求的产品
-
最小
-
想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。最小的代价就是能不做的事就不做，能简化的事情就简化
-
我们要做的是验证一个想法的可行性，甚至不是为了开发一个软件，开发软件只是一种验证手段。
-
例子
- 做产品文档验证方向性想法正确性
- 原型工具做出了相对完整的用户界面, 验证使用性
- 经过多轮测试下来，团队有了一大堆的用户反馈，而且是来自真实用户的反馈。接下来，就是整理这些用户反馈，决定哪些可以真正的开发出来，这时候，团队才真正进入到开发阶段
- 迄今为止，这个团队验证了一大堆的想法，而代码却是一行都没有写，所有花费的工作量都是有针对性的验证
-
-
可行
- 但从产品可行的角度，我们需要转换一下思路，不是一个模块做得有多完整，而一条用户路径是否通畅
- 当时间有限时，我们需要学会找到一条可行的路径，在完整用户体验和完整系统之间，找到一个平衡
-
-
程序员经常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案
-
可行的路径，是一条完整的用户体验路径，至少在用户眼中是这样的。我们常常会想给客户一个完整的系统，但在时间有限的情况下，我们必须学会分解
- 但从产品可行的角度，我们需要转换一下思路，不是一个模块做得有多完整，而一条用户路径是否通畅
-
做好产品开发，最可行的方式是采用 MVP(Minimum Viable Product，MVP)
-
总结: 小步快跑。搞清楚业务方需要什么, 最小代价(产品文档+原型工具)验证, 找到可行性路径, 进行开发
-
3、沟通反馈
-
1、信息论的视角看沟通反馈
-
人生不如意，十之八九！
-
我们努力地学习各种知识，为的就是更好地理解这个世界的运作方式，而沟通反馈，就是我们与真实世界互动的最好方式
-
信息论视角的解释
- 因为每个人经历见识的差异，造成了各自编解码器的差异，形成了理解的偏差
-
改善编解码
- 分别是：编码器，让信息能输出更准确；解码器，减少信号过滤，改善解码能力；还有编解码算法，也就是各种来自行业的“最佳实践”，协调沟通的双方
-
-
2、用业务的语言写代码
-
推荐书籍
- 《程序设计实践》（The Practice of Programming）
-
编写可维护的代码境界
-
计算机科学中只有两大难题：缓存失效和命名
-
命名难题
-
名字起得是否够好，一个简单的评判标准是，拿着代码给人讲，你需要额外解释多少东西
-
代码到底是给谁写的？
- 任何人都能写出计算机能够理解的代码，只有好程序员才能写出人能够理解的代码。
- 我们写代码的目的是与人沟通，因为我们要在一个团队里与人协同工作
- 人要负责将业务问题和机器执行连接起来，缺少了业务背景是不可能写出好代码的。
- 好的命名修改，但从理解上，这是一步巨大的跨越，缩短了其他人理解这段代码所需填补的鸿沟，工作效率自然会得到提高
-
命名，是写程序中最基础，也是一个程序员从业余走向专业的门槛。我以命名为基础，给你解释了写好代码的提升路径。最初的层次是编写可以运行的代码，然后是编写符合代码规范的代码
-
-
-
用业务语言编写代码
-
了解领域驱动设计（Domain Driven Design，DDD），你可能已经分辨出来了，我在这里说的实际上就是领域驱动设计。把不同的概念分解出来，这其实是限界上下文（Bounded Context）的作用，而在代码里尽可能使用业务语言，这是通用语言（Ubiquitous Language）的作用
-
推荐书籍
- 代码整洁之道
-
-
-
3、团队的沟通：轻量级沟通
-
头疼的开会
-
程序员白天都在开会, 晚上才能静心写代码
-
开会是为了解决问题，但真实情况却是开了会又没有解决多少问题，这真是一个奇特的矛盾。
-
凡是效果特别好的会议，基本上都是用来做信息同步的。
- 例如: 领导宣布一个事情，大家收到消息， 结束。
-
会议是一项重量级的沟通
-
-
轻量级沟通
-
改善会议的第一个行动项是，减少参与讨论的人数。
-
第二个行动项是，如果你要讨论，找人面对面沟通
-
如果和大家沟通结果达成一致, 再进行开会
- 开会的目的不再是讨论，而是信息同步：我准备这么干了，相关各方已经同意了，知会大家一下，结束。
-
-
站立会议
-
实践叫站会（Standup）
-
站会人主题
-
1、我昨天做了什么。
- 是为了与其他人同步进展，看事情是否在计划上。一旦偏离计划，请主动把它提出，这样，项目经理可以过问，因为这会涉及到是否要调整项目计划
-
2、我今天打算做什么。
- 是同步你接下来的工作安排。如果涉及到与其他人协作，也就是告诉大家，让他们有个配合的心理准备
-
3、问题和求助
- 我在过程中遇到什么问题, 需要请求帮助。
- 就是与其他人的协作，表示：我遇到不懂的问题，你们有信息的话，可以给我提供一下
-
-
注意事项
-
控制时长(不超过10分钟)
-
晨会规模
- 5-12人是一个恰当的规模
-
避免做成汇报会
-
问题复杂,会后讨论,不要在会上讨论
-
保持参与人集中精力
- 毛绒娃娃随机令牌发言
-
-
-
一些思索
- 每次会议要有会邀, 讨论主题, 相关文档, 会后同步会议记录结论
- 同步沟通(如:开会)，人越少越好。异步沟通的时候，涉及的听众越多越好(如:E-mail)
-
-
4、可视化：一种更为直观的沟通方式
-
关注技术新知识途径
-
InfoQ
-
ThoughtWorks 技术雷达
- 技术雷达就是一种将技术信息组织起来的方式。它通过将技术按照“象限”和“圆环”两个维度进行分类，让人可以直观地看到并理解不同的技术所处的发展阶段
-
-
可视化
-
在我看来，雷达图不仅仅适用于组织，也可以适用于团队
- 雷达图是一种很好的形式，不仅可以用在组织技术，还可以用来组织其它信息，比如，读书雷达。每个公司都可以利用雷达图的形式组织自己所有的技术，每个团队也可以利用雷达图的形式组织自己团队用到的技术，这样，方便团队成员结构化地理解用到技术，也方便新人的学习。
-
可视化的优势
- 因为人的大脑更擅长处理图像
- 处理图像的速度远远快于处理文字
-
项目管理
- 看板
-
-
-
5、持续集成的关键点: 快速反馈
-
目标: 怎样快速地得到反馈，以及什么样的反馈是有效的。
-
做好快速反馈，要把本地能做好的事情，在本地做好；也要通过小步提交的方式，加快代码开发的节奏。什么是有效的反馈？一是即时的反馈，二是引人注目的反馈。有很多种持续集成相关的工具可以帮助我们达成有效的反馈
-
想要做好持续集成，还要有一些纪律要遵循
- 只有 CI 服务器处于绿色的状态才能提交代码
- CI 服务器一旦检查出错，要立即修复
-
-
6、回顾会议：复盘与改善
-
安全性检查，是回顾会议的前提条件
-
在软件研发中，许多问题是反复出现的，很多开发团队会因此陷入无限“救火”中，解决这种问题一个好的办法就是复盘
- 把过程还原，进行研讨与分析的方式，就是复盘
-
复盘，就是过程还原，进行研讨与分析，找到自我改进方法的一个方式。这种方式使我们拥有了客体化的视角，能够更客观地看待曾经发生过的一切。这种方法在很多领域中都得到了广泛的应用，比如股市和企业管理
- 用别人的视角看问题，这就是客体化
-
复盘实践
-
回顾会议
- 定期回顾是一个团队自我改善的前提
- 做得好的、做得欠佳的、问题或建议
- 目的: 改善和提升
-
-
无论哪种做法，分析问题，找到根因是一个重要的环节。“5 个为什么”就是一个常用的找到根因的方式
-
定期复盘，找准问题根因，不断改善
-
枚举关注点，选出重点，深入讨论，列出行动项，找到负责人
-
-
7、用户思维，聆听赖在用户的声音
-
用户视角，你需要来自真实世界的反馈
- 而作为一个程序员，欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”
- 由听产品经理的话，扩大成倾听用户的声音
-
倾听用户声音。这是开发团队普遍欠缺的一种能力，更准确地说，是忽略的一种能力。所以，“吃自家的狗粮”这种听上去本来是理所当然的事情，才被反复强调，成为 IT 行业的经典
-
无论是自己做用户，还是找机会接触已有用户，亦或是没有用户创造用户。只有多多听取来自真实用户的声音，我们才不致于盲目自信或是偏颇地相信产品经理。谁离用户近，谁就有发言权，无论你的角色是什么。
-
-
8、把事情做在前面：变被动为主动
- 遇到问题，最好的解决方案是尽早把问题暴露出来
-
9、写文档、做分享， 也是一种学习方式
-
为什么不喜欢写文档
- 很多人回避写文档的真正原因是，他掌握的内容不能很好地结构化
-
将零散的知识结构化，有很多种方式，但输出是非常关键的一环。
-
输出的过程，本质上就是把知识连接起来的过程
-
输出过程
-
4、自动化
-
1、"懒惰"应该是所有程序员的骄傲
-
不要自动化
- 哪些东西不要自动化
- 做有价值的事是重要的，这里面的有价值，不仅仅是“做”了什么，通过“不做”节省时间和成本也是有价值的
- 说明一件事，写代码之前，先问问自己真的要做吗？能不做就不做，直到你有了足够的理由去做
-
要自动化
- 在为别人打造自动化工具的同时，我们自己的工作过程有没有很好地自动化
- 而如果我们想拥有打造良好的自动化工具，我们需要对软件设计有着充分地理解
-
软件设计
-
在软件开发中，其它的东西都是易变的，唯有设计的可变性是你可以控制的
- 看源码，学习的目的是看背后的软件设计思想，而非软件本身
-
不要混淆了设计和实现
-
-
-
2、构建脚本: 让日常开发变得简单
-
项目自动化流程
- 生成IDE工程
- 编译
- 打包
- 运行测试
- 代码风格检查
- 测试覆盖率
- 数据库迁移
- 运行应用
-
-
3、思考DevOps框架
-
4、持续交付: 一种延伸的"持续集成"
-
5、如何做好验收测试？
-
6、单一职责:划分界限
-
逐步腐化的代码
-
功能堆加
-
低着头完成了一项任务，而代码却变得更糟糕
-
一个解决办法
- 重构
-
-
软件设计
-
SOLID
- 单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）
- 单一职责原则（Single responsibility principle，SRP）
-
-
-
7、分成思维, 是计算机的核心思维
-
8、不同量级的东西不是一回事
- 评估系统当前所处的阶段，采用恰当的技术解决，是我们最应该考虑的问题
- 作为拥有技术能力的程序员，我们都非常在意个人技术能力的提升，但却对在什么样情形下，什么样的技术更加适用考虑得不够。采用恰当的技术，解决当前的问题，是每个程序员都应该仔细考虑的问题
- 用简单技术解决问题，直到问题变复杂
-
9、领域驱动设计:限定上下文
综合运用
1、入职新公司, 如何快速进入工作状态？
-
步骤
-
1、了解业务
-
2、技术
- 技术栈
- 业务架构
- 内外依赖
-
3、团队运作
-
需求, 产品，向谁汇报
-
内部活动
- 站会、 回顾会议、周会、代码评审、内部分享等
-
-
使用“行话”。在交流的过程中，学习一点”行话“。这会让人觉得你懂行，让你很快得到信任，尽早融入团队
-
-
找到关键点，迅速下手
-
由大到小， 由内而外
2、面对遗留系统，如何做？
-
用思考框架对遗留系统
-
步骤
-
1、了解现象和根因
-
2、确定方案
- 确定目标
- 先尝试重构你的代码，尽可能在已有代码上做小步调整，不要走到大规模改造的路上，因为重构的成本是最低的
- 保证功能一致唯一靠谱的答案是测试
- 一方面，建立好领域模型，另一方面，寻找行业对于系统构建的最新理解
-
-
建议
- 构建测试防护网，保证新老模块功能一致；
分成小块，逐步替换；
构建好领域模型；
寻找行业中关于系统构建的最新理解。
- 构建测试防护网，保证新老模块功能一致；
3、如何保证竞争力
- 不断提升自己的核心竞争力
- 焦虑， 对未来不确定性
- 目标: T型人才， 一专多能 有深度有广度
- 有了“一专”，“多能”才是有意义的，否则，就是低水平重复，而这正是很多人职业生涯不见起色的真正原因
总结
少做事,才能更有效的工作
附: 提供md、png、xmind格式笔记地址:
资源地址
167
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
