项目微管理10 - 工匠
Posted 一名技术宅的管理经
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了项目微管理10 - 工匠相关的知识，希望对你有一定的参考价值。
在这两年的政府报告中，“克强经济学”屡次提到一个词叫“工匠精神”。
工匠精神
工匠精神，是指工匠对自己的产品精雕细琢，精益求精的精神理念。工匠们喜欢不断雕琢自己的产品，不断改善自己的工艺，享受着产品在双手中升华的过程。
说到“工匠精神”，就不得不提一下它的代表人物-英国航海钟发明者：约翰·哈里森 。
木匠出生的哈里森费时40余年，经过不断研究和试验，先后造出了五台航海钟，其中最优秀的“哈氏4号”，航行了64天，只慢了5秒，完美解决了航海经度定位问题。这就是典型的“工匠精神”，虽然同时他也是为了获得2万英镑的奖金。
四代小的时候，还是各种工匠盛行的时候。记得有一年，四代家刚搬进新家以后，觉的客厅需要一套家具，于是找了邻村的一个木匠打了一套家具。这么多年了，这套家具家具还摆在这个老房子里，质量那是杠杠的。
对于好的木匠来说，他时刻都会在可能的前提下，不断的完善家具的细节，因为他从师傅那就是这么学下来的，这就是他们传承下来的“火的意志”（《火影忍者》语），这里有他们作为专业人士的责任感、对产品的敬畏感，对职业的荣誉感。
当然了，也有息息相关的利益在里面，因为做不好就不会有客户，没有客户就要饿肚子。
老实说，这些东西靠任何的培训和流程是无法传递的，只有靠师徒之间的情感交流和行为感染，才能传承和发扬。对于现在的很多公司来说，缺少的就是这种传帮带，这种工匠的精神。
重构就是工匠精神的体现
而重构就是工匠精神在软件开发中的体现，重构就是对代码精雕细琢，精益求精，不断打磨的过程。
四代认为，软件代码设计具有两个特点：
第一个特点是设计具有静态性，也就是说在某个时间点上，设计总是此刻软件功能的代码实现。在这个特定的时刻，团队基于目前掌握的需求和反馈，采用编程的基本技术和原理，实现了软件的功能；这份实现的代码就是设计，这就是设计的“静态性”，也可以称为“时效性”。
但是软件总是处于变化中的，不管是需求，还是技术，团队成员也是处于变化中的，不管是数量，还是质量，为了应对这种情况，设计必须要具有第二个特点：动态性。
在软件的整个生命周期中，团队总是基于需求的不断变化，技术的不断更新，团队成员的不断更替，不断调整实现软件功能的设计和代码，这就是设计的“动态性”，也可以称为“迭代性”。
代码规范，设计原则，设计模式，架构等技术之所以非常重要，就是因为它们在软件静态设计中起着至关重要的作用。
而重构之所以非常重要，是因为它在软件动态演化中起着至关重要的作用，它真实的反映了软件从一个稳定的状态变化到另一个稳定状态的合理方式，非常符合哲学中“量变和质变”的基本原理：那就是通过不断的重构去促成代码的量变，最终达到软件质量的质变。
而四代坚定的认为项目经理必须首先是一个优秀的程序员的非常重要的一个原因就在于此，因为不是优秀的程序员不可能认识到这些。
基于这些看法，在每个Release的开发任务中，四代是这么定义“任务的完成状态”的：代码提交，测试通过，尝试重构，尝试改善用户体验。
重构和迭代构成了软件开发的基本旋律，深刻的阐述了“工匠精神”，在开发过程中深刻意识到它们的重要性并合理的利用它们可以使得代码质量始终保持在一个良性循环的状态。
克己
确实，在不考虑任何其他因素的前提下，我们可以无限重构下去，让软件无限的接近此刻最完美的设计。
可惜的是，我们不是活在真空中，我们的客户像嗷嗷待哺的孩子一样，正眼巴巴的等待着我们产品的发布。而公司也一样，对任何功能的规划都是有时间节点的，因为公司也像等着米下锅的巧妇一样，急切的盼望着产品及时发布。
所以在真正的研发过程中，PC团队的重构工作有几点是四代特别强调的：
第一，哪些东西要重构，哪些东西不重构。
简单的说，新提交的代码，违反代码规范的要重构，有更优方案的要重构。那么有不用重构的吗？有，已有代码在工作正常，不需要修改的时候坚决不要去重构，除非吃饱了实在没事干的时候，可以考虑一下。而实际上，在堆积如山的需求面前，就没有这种情况。
第二，什么时间点推荐重构，什么时间点可以不重构。
在PC团队，当代码发现应该要重构的时候，当天就最好重构完。那么任何时候都要立即重构吗？不，进入集成测试最后一阶段，面临发布的时候，不推荐重构，尤其是大范围重构。
在集成测试最后一阶段，四代会划分出一个阶段，叫“代码提交申请阶段”，这阶段，任何人要提交代码都要向四代申请，通过后才能提交。而集成测试结束后的临发布阶段，叫“代码提交禁止阶段”，在这阶段，不允许提交代码，除非四代觉得有必要修复的BUG，要求团队修复它，才能提交代码。而这两个阶段，都不需要执行重构。
第三，重构要分布到每个Release中。
很多人都梦想经过一次大范围，大面积的重构，整个软件的状态立即变好了，而现实条件下，这几乎是不可能的。且不说整体重构的难度有多大，就说时间这一项，公司就等不了，那得花多少时间啊，客户还在等新功能呢！
所以，重构要分开到每个Release中，持续的进行。汤师爷曾经说过：步子迈的大了容易扯着蛋。真是至理名言啊！
但是做到这些也还是不够的，因为代码质量只是软件质量的一个侧面，四代觉得他们团队还需要别的手段来保证软件的质量，还缺些什么呢？
以上是关于项目微管理10 - 工匠的主要内容，如果未能解决你的问题，请参考以下文章