Open winterggg opened 4 months ago
本文取材自：https://brunokiafuka.substack.com/p/think-twice-code-once
作者在做 code review 时发现一些新手程序员往往提交一些「拧巴」 的代码 -- 要么过度工程化，要么过度复杂. 作者通过询问，发现问题的关键似乎在于这些实现只是他们的第一个想法，他们并没有去认真分析这个实现是否恰当.
针对这个问题，作者提供了一个软件开发工程的思考过程：
获取上下文. 收集信息和需求，通过 5why 分析法充分理解上下文，理解代码变更的原因和影响；
写下假设. 基于上一步对上下文的理解，提出假设（assumption）-- 即要做什么以及如何做，给出不同实现路径的优缺点并进行排序. 重复多次进行该步骤，但为了避免分心或失去焦点，需要限制假设的数量;
实现. 从上一步的实现路径中选择一个去最终实现.
最后作者推荐了 Leslie Lamport 大佬的一个 talk，mark 了有空看看：https://www.youtube.com/watch?v=-4Yp3j_jk8Q&ab_channel=MicrosoftResearch
想法：
我认为可以参考的地方有两个：
感觉这个其实是一种风险管理策略在软件开发中的应用，记得之前刷油管有个博主说非商科专业出身的人往往缺乏风险管理的意识，之后有空了可以多看看这方面的案例分析.
Think twice, code once!
作者在做 code review 时发现一些新手程序员往往提交一些「拧巴」 的代码 -- 要么过度工程化，要么过度复杂. 作者通过询问，发现问题的关键似乎在于这些实现只是他们的第一个想法，他们并没有去认真分析这个实现是否恰当.
针对这个问题，作者提供了一个软件开发工程的思考过程：
获取上下文. 收集信息和需求，通过 5why 分析法充分理解上下文，理解代码变更的原因和影响；
写下假设. 基于上一步对上下文的理解，提出假设（assumption）-- 即要做什么以及如何做，给出不同实现路径的优缺点并进行排序. 重复多次进行该步骤，但为了避免分心或失去焦点，需要限制假设的数量;
实现. 从上一步的实现路径中选择一个去最终实现.
最后作者推荐了 Leslie Lamport 大佬的一个 talk，mark 了有空看看：https://www.youtube.com/watch?v=-4Yp3j_jk8Q&ab_channel=MicrosoftResearch
想法：
我认为可以参考的地方有两个：
感觉这个其实是一种风险管理策略在软件开发中的应用，记得之前刷油管有个博主说非商科专业出身的人往往缺乏风险管理的意识，之后有空了可以多看看这方面的案例分析.