关于专题第一篇文章，我考虑了很久写什么主题。起初我想写目前最有兴趣的“生命周期”，但觉得开篇应该还是选择一个更基础的、更通用的，所有程序员都应该遵循的理念，最好还普世。然后我思考了下面两个问题

• 一名程序员最基本的职责是什么？
• 一名优秀的程序员最根本的品质是什么？

用一句话回答这两个问题，让程序工作然后让它变得更好——Make it Work then Make it Better。

Make it work！一名程序员首先要保证构建的程序能预期工作。不管你写的代码多么漂亮友好，用的技术或工具多么先进，如果程序不能预期工作，这个事情便是失败的。

Make it better！优秀的程序员能够不断地减少程序的复杂度，如让程序执行更快更省空间，让程序变更更简单，让程序迭代更快速，让团队协作更有效推进产品希望的方向等。注，越到后面的描述，“程序”一词越抽象，可替换成系统、产品等。这里的关键在于如何定义”更好“；拥有一个系统的易于理解和能够执行的衡量指标十分关键。

首先，你的交付要预期工作。

对于初级程序员，交付的功能能预期工作。

对于高级程序员或一线技术管理者，交付的项目要预期完成并满足要求。为了保证团队能高效协作，需要首先建立项目的工程环境，建立构建和发布的迭代流程，制定程序设计的规范。

对于架构师和高级技术管理者，（我认为）交付的产品要预期完成任务。为了保证各个团队能有效协作和完成任务，需要保证组织架构能适应技术架构，制定产品计划和目标的衡量标准，等等。

其次，你要明白什么方面要提高，定义如何衡量以及采取行动。

代码执行效率是最直接要考虑的地方。

在实际工作中，常见的场景是使用性能分析工具去分析各个代码片段执行的效率，从而找到导致主要影响的代码片段，从而设法改善。如果需要提高的代码片段运用了特定的经典算法，可考虑更换更合适的算法，或者具体调整算法实现细节。这时候去算法知识的储备和对时间复杂度和空间复杂度的衡量方法（大O表示法）会更大程度帮助你。有效的学习路径比较单一，比如学习算法知识（看经典书籍如（如《算法》、《算法图解》或《算法导论》））和刷题加强实践和理解。

相比代码执行效率，代码的可维护性和扩展性往往在工程实践中更关键。简单而言，要考虑如何让代码变更更容易，因为程序需要不断地维护和增加新的功能。

那如何衡量代码设计的好坏？这似乎没有一个统一的衡量标准，但有着许多权威总结或认可的设计原则以及基于经典业务场景下的设计模式可以指导我们做出正确的决定。一般我们可以学习一些经典的代码设计类书籍如《代码整洁之道》，《重构》，《设计模式》，《领域驱动设计》等。

作为初级程序员，往往只需要交付的代码与已有的程序代码设计相一致即可。

作为高级程序员或一线技术管理者，主要要考虑如何控制代码设计的一致性，避免成员的更改容易提高代码的复杂度，进而影响后续的维护和新功能的实现。对此，可以利用一些自动化的代码风格验证工具去避免一些常见的不良代码签入，如命名问题、类/函数的复杂度等；同时提供功能设计模板去规范设计审核过程，保证设计里能覆盖对常见问题的考虑，比如对外部依赖的引入要考虑的方面等。

对于大型系统或产品的架构师和高级技术管理者，由于主要的职责是管理，（从我的观察）他们还需要关注许多能提高团队协作效率，减少管理复杂度的方面，比如

• 加速迭代和减少人力流程。比如建立完善的自动化测试，减少发布之前人为的测试流程；比如加速构建的速度，避免代码实现过程多次迭代里等待构建的时间；
• 保持技术架构与组织架构的一致性，有助于各个团队在技术架构中划清边界，保持各自技术实现的独立性和自主性，进行更有效的协作。据我经验，微软里的许多次部门重组都是为了与最新的或希望的技术架构保持一致。
• 建立产品目标的衡量标准，有助于建立产品目标和团队任务的分配；结合自动化的衡量机制对新功能上线测试做评估，简化了功能正式发布的审核过程，而且详细的衡量结果也有助于进行下一次有效的迭代。在这个方面，微软的Bing做的就很好；个人觉得这是Bing为什么能高速发展的重要武器。除此之外，产品是否有简单明确的衡量标准，也很好地反应了领导层是否真的明确产品的走向。
• ……

最后，我希望这篇“点到即止”的文章能对你有所启发，不仅是在程序员的工作中，同时在生活的其他方面，比如它能够促使你完成生活里的一直想完成却迟迟没开始的事情，比如锻炼身体，旅行，或培养感兴趣的爱好——Just Do it then Be Better！