10X精简版
2021-09-18 17:03:46 1 举报
AI智能生成
10X精简版是一款高效、实用的软件工具,它通过去除冗余功能和优化代码,实现了更轻量级的运行体验。该版本保留了核心功能,同时减少了资源占用,使得软件在低配置设备上也能流畅运行。10X精简版界面简洁明了,操作便捷,用户可以轻松上手。无论是日常办公还是娱乐休闲,10X精简版都能满足用户的需求。它的快速响应和稳定性能让用户在使用过程中感受到极致的流畅度。总之,10X精简版是一款值得推荐的实用软件,它将为用户提供更加高效、便捷的使用体验。
作者其他创作
大纲/内容
任务分解
重点复习
测试金字塔
测试驱动开发
艾森豪威尔矩阵(Eisenhower Matrix)
最小可行产品
额外收获
对不了解技术的任务,先要去了解技术,然后再做任务分解;
通过一次技术 Spike ,学习新技术;
丢弃掉在 Spike 过程中开发的原型代码;
分清目标与现状,用目标作为方向,指导现状的改变;
多个功能并行开发可以考虑使用 Feature Toggle;
在遗留系统上做改造可以考虑使用 Branch by Abstraction 。
应用的做法和评判标准
尽量不写 static 方法;
主分支开发模型是一种更好的开发分支模型;
好的用户故事应该符合 INVEST 原则;
估算是一个加深对需求理解的过程,好的估算是以任务分解为基础的;
好的测试应该符合 A-TRIP。
改善自己的开发工作
分而治之,是人类解决问题的基本手段;
软件变更成本,它会随着时间和开发阶段逐步增加;
测试框架把自动化测试作为一种最佳实践引入到开发过程中,使得测试动作可以通过标准化的手段固定下来;
极限编程之所以叫“极限”,它背后的理念就是把好的实践推向极限;
大师级程序员的工作秘笈是任务分解,分解到可以进行的微操作;
按照完整实现一个需求的顺序安排开发任务。
沟通反馈
看板
一种来自精益生产的可视化实践。
按阶段将任务放置其中。
可以帮助我们发现问题。
持续集成
做好持续集成的关键是,快速反馈。
本地检查通过之后再提交。
到有效的反馈方式,比如:CI 监视器。
持续集成的纪律。
只有 CI 服务器处于绿色的状态才能提交代码。
CI 服务器一旦检查出错,要立即修复。
回顾会议
软件团队复盘的一种实践。
枚举关注点,选出重点,深入讨论,列出行动项,找到负责人。
5 个为什么
又一个来自丰田的实践。
沿着一条主线追问多个问题。
用信息论理解沟通反馈
写代码的进阶路径
编写可以运行的代码。
编写符合代码规范的代码。
编写人可以理解的代码。
用业务语言写代码。
重点
会议是一种重量级的沟通方式
减少参会人数。
找人面对面沟通。
聆听用户声音
能做自己用户,做自己的用户。
能接近用户,接近用户。
没有用户,创造用户。
Fail Fast
一种编写代码的原则。
出现问题尽早报错。
金字塔原理
从中心论点,到分论点,再到论据。
额外收获
持续集成是一条主线,可以将诸多实践贯穿起来。
从持续集成到稳定的开发分支,到频繁提交,足够小的任务,到任务分解。
从持续集成到可检查,到测试防护网,到测试覆盖率,到单元测试,到可测试代码,到软件设计。
安全性检查,是回顾会议的前提条件
在信息获取上,国内外程序员差别不大,开拓视野,改善工作习惯,是国内程序员亟需提高的。
自动化
持续交付
将生产部署纳入了开发的考量。
持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境
构建流水线保证到了下游的交付物一定是通过上游验证的。
随着 Docker 的诞生,交付由发布包变成了 Docker 镜像。
DevOps
将开发和运维结合到一起。
环境配置工具上的进步,让基础设施即代码成了行业共识。
验收测试
验收测试要站在业务的角度编写。
BDD 是一种编写验收测试的方式
Given…When…Then… 的描述给了一个描述业务的统一方式。
写好验收测试,需要构建测试模型。
SOLID 原则
设计模式背后的道理。
单一职责原则(Single responsibility principle,SRP)。
开放封闭原则(Open–closed principle,OCP)
Liskov 替换原则(Liskov substitution principle,LSP)
接口隔离原则(Interface segregation principle,ISP)
依赖倒置原则(Dependency inversion principle,DIP)
用好单一职责原则,前提条件是看待问题颗粒度要小
DDD
它将思考的起点拉到了业务上。
DDD 分为战略设计和战术设计。
微服务
做好微服务的前提是划分好限界上下文。
微服务的第一步,不要划分微服务。
结束语
算法优化,其实就是尽可能利用已知的信息,少做不必要的事。
有效工作,需要我们把力量聚焦到正确的地方,做本质复杂度(Essential Complexity)的事情,少做无意义的事情。
如何思考
优秀程序员的开发效率是普通程序员的 10 倍。
三个问题
我现在是个什么水平? --- 现状
我想达到一个什么水平? --- 目标
我将怎样到达那个目标? --- 实现路径
如果一个人能够清晰地回答出这三个问题,通常意味着他对要做的事有着清晰的认识。
产品经理的提问
为什么要做这个特性,它会给用户带来怎样的价值?
什么样的用户会用到这个特性,他们在什么场景下使用,他们又会怎样使用它?
达成这个目的是否有其它手段?是不是一定要开发一个系统?
这个特性上线之后,怎么衡量它的有效性?
四个原则
以终为始
任务分解
沟通反馈
自动化
我们不是一个人孤独地在工作,而是与其他人在协作,想要做到高效工作,我们就要“抬起头”来,跳出写代码这件事本身。所以,我在开篇词里说,程序员解决的问题,大多不是程序问题。
面对问题时,用思考框架问问自己,现状、目标和路径。
以终为始
重点复习
DoD,确定好完成的定义,减少团队内部的理解不一致。
用户故事,细化出有价值的需求。
持续集成,通过尽早集成,减少改动量,降低集成的难度。
精益创业,减少过度开发不确定性产品带来的浪费。
迭代 0,在项目开始之前,做好一些基础准备。
思维转变
任何事物都要经过两次创造:一次是在头脑中的创造,也就是智力上的或者第一次创造(Mental/First Creation),然后才是付诸实践,也就是实际的构建或第二次创造(Physical/Second Creation)。
在更大的上下文内发现自己的“终”。
通过推演,找到通往“终”的路径。
用可度量的“数字”定义自己的“终”。
回顾
遇到事情,倒着想
在做任何事之前,先定义完成的标准。
在做任何需求或任务之前,先定好验收标准。
尽早提交代码去集成。
默认所有需求都不做,直到弄清楚为什么要做这件事。
扩大自己工作的上下文,别把自己局限在一个“程序员”的角色上。
在动手做一件事之前,先推演一番。
问一下自己,我的工作是不是可以用数字衡量。
设计你的迭代 0 清单,给自己的项目做体检。
综合运用
新入职一家公司,怎么快速进入工作状态?
运用思考框架
三个问题
Where are we?(我们现在在哪?)
Where are we going?(我们要到哪儿去?)
How can we get there?(我们如何到达那里?)
技术解决的是“怎么做”的问题,而我们第一个应该了解的问题是“做什么”。
三个小目标
业务
技术
团队运作
从大图景入手(由外到内)
业务
技术
团队运作
面对遗留系统,你应该这样做
分清现象与根因
它们只是现象,不是根因。
确定方案
先尝试重构你的代码,尽可能在已有代码上做小步调整,不要走到大规模改造的路上,因为重构的成本是最低的。
一方面,建立好领域模型,另一方面,寻找行业对于系统构建的最新理解。
建议
构建测试防护网,保证新老模块功能一致;
分成小块,逐步替换;
构建好领域模型;
寻找行业中关于系统构建的最新理解。
小步改造遗留系统,不要回到老路上。
我们应该如何保持竞争力?
焦虑的程序员
我们的焦虑来自于对未来的不确定性,而这种不确定性是一个特定时代加上特定行业的产物。
成为 T 型人
有了“一专”,“多能”才是有意义的,否则,就是低水平重复,而这正是很多人职业生涯不见起色的真正原因。
在学习区成长
如果你还什么都不会,那有一份编程的工作就好。
如果你已经能够写好普通的代码,就应该尝试去编写程序库。
如果实现一个具体功能都没问题了,那就去做设计,让程序有更好的组织
如果你已经能完成一个普通的系统设计,那就应该去设计业务量更大的系统。
如何在实际工作中推行新观念?
1:想要推行 DDD,阻力很大怎么办?
找到愿意和你一起改变的人,做一件具体的事。
Talk is cheap. Show me the code.
当你寻求改变时,无论你的角色是什么,你都需要扮演好领导者的角色,“Lead by Example”送给你!
2:测试怎么写?
外部系统对你来说,应该只是一个接口。
如果有任何外部系统,都要设计防腐层,用接口做隔离。
能模拟的就模拟,能本地的就本地。
关于外部系统的测试,你可以先通过接口隔离开来,然后,通过模拟服务或本地可控的方式进行测试。
“综合运用”主题内容的全盘回顾
“学习区”学习模型
舒适区,舒适而缺乏成长。
恐慌区,超出能力范围。
学习区,有难度而可以达成
在学习区练习才能得到足够的成长。
T 型人才,一专多能
知识的广度。
专业技能的深度。
有“一专”,“多能”才是有意义的。
进入新工作,从全面了解了解开始
业务:做什么。
技术:怎么做。
团队运作:怎么与人协作。
大到小,由外及内地了解工作。
面对遗留系统,稳扎稳打,小步前行
基础理念
烂代码只是现象,要了解根因。
能重构,先重构,大规模改造是迫不得已的选择。
小步前行。
实际操作
构建测试防护网。
将大系统分解成小模块,逐步替换。
新旧模块并存,由分发模块调度
建立好领域模型。
寻找行业对于系统构建的最新理解。
程序员的职业发展
程序员的焦虑来自于对未来的不确定性,这种不确定性是一个特定时代加上特定行业的产物。
快速发展的中国经济。
程序员在中国是一个新兴职业。
成为行业专家,制定高目标。
向大师学习,开拓视野。
找到好的问题,和高水平的人一起工作。
0 条评论
下一页
为你推荐
查看更多