程序员工作法学习记录

程序员工作法

---

1、 以终为始

• 简而言之：以结果作为驱动，从结果处思考问题。考虑指定的结果会带来怎样的改变，这样的结果是否符合预期。是否还有其他更好的结果来替代?

2、DOD（ definition of done）

做事情之前，定义好什么叫做完成。
例如在工作中，遇到新的开发需求，此时的完成定义为（站在开发人员的角度）：

1、功能代码、测试案列编写完成
2、代码测试通过
3、数据库增、改脚本
4、上线环境需求
.....

3、明确需求

接收开发任务时，首先应该明白，需求的各项细节。
例如短信配置：

1、谁来配置？
2、哪些信息可以配置？
3、.....

4、持续集成

在分模块开发时，尽可能的调短集成周期，如每天一次，这样可以避免项目集成过于复杂。

这里给我的感觉更像是在工作中，开发一个需求时，尽量做到没完成一个小的阶段时，就停下来思考，
目前的结果是否符合预期，同时可以向负责需求的人员进行报备、沟通，以避免雪球越滚越大。

5、扩展上下文

Java中很多框架都是用到了‘上下文’这个概念，‘上下文’顾名思义，即是需要你了解一件事情更多的东西，如同故事大纲一般。
工作中，其实也是同样的道理，你需要了解的不仅仅是你手中的工作，同样你需要知道 what you do，当你理解‘上下文’之后，遇到问题，你才能更好的解决，换个角度思考。不识庐山真面目，只缘身在此山中。解决一个问题，有些时候需要的不是技术，是一种艺术。

6、推演 头脑风暴

做任何事情之前，都应该在头脑中思考清楚，一步一步，就像在大脑中执行伪代码一般。我在工作时就喜欢写一点想一点，这样很多时候都会推翻重来。在脑中推演一番，不仅避免这种无效操作，也会培养出一种良好的习惯，三思而后行！

7、数字衡量一切

做事情的时候凭借自己的直觉，这是大多数人做事的一种方式，比如我开车，就是凭借自己的直觉，这样带来一个很大的问题，我的驾驶技术很难取得进步。工作生活亦是如此，务必将那些需要提升的方面，尽量做到能用数字衡量。

例如：在工作中，我经常发表这样的言论，这样改动之后，会导致查询速度极低，但是这种说法本身
其实具备很大的模糊性。低，能够具体化吗？有数据支撑吗？等等。已经很多时候，完成一件事情，
可以用数字来衡量吗？完成即是100%，没有99.9%这种说法。