分工、流程、标准、职业化——将你的代码工业化

包括软件开发的瀑布、迭代等各种模型以及极限编程在内的各种方法论，无一例外的希望将软件生产作为作为大工业的一种进行流水线化。

1. 将过程精细拆分成若干模块 （时间上分成需求阶段、评审阶段、开发等等、和横向上会有不同的人员），并对各个阶段的时间、人力、软、硬件资源进行精确配置；
2. 然后，将每个阶段的目标量化 ；包括严重bug率、feather完成数量；
3. 之后，经由严格的流程管理 ，每个阶段由谁负责做哪些事情，在做某件事情之前需要经过哪些步骤、需要知会谁等等，都可以快捷的通过电子流程完成；
4. 一旦软件产品在其生命周期的某个阶段出现了问题 ，自然而然要根据预定的方案去跟踪、解决问题。该具体问题及其解决方案在成为团队经验的同时，也会作为评估该产品质量的指标。
5. 更进一步，我们将软件开发中涉及到的方方面面进行标准化 ；这一步和前四点是交替螺旋改进的；

进行以上工作的动力在于：
1. 从资本家的角度，流水线、标准化可以提高工作效率、减小出错概率，极大缩小软件产品的成本；
2. 从行业从业人员（产品、设计、开发、测试等）本身出发，也需要方便的解决问题、减小再学习成本、于是有各种标准库、标准件；
由此来看，我们进行泛化 的根本目的：抽象出问题，减小下次遇到同样场景时的付出 。（这也是讨论设计模式 的根本原因）

不管资本家也好、程序员也好，我希望自己树立工业化软件的意识 ，开始用职业的态度对待以前稍显随意的编码工作；
（想到这一层，就不难理解为什么code complete中会用50页的篇幅对一个变量名的命名方法进行讨论了——因为作者在以工业化的眼光看待软件开发，对他来说，变量名其实是一个大工业中的十分具体的产品，而变量名命名也理应成为一个标准的工业过程。）
当然，我们也仍要尽量以艺术性的眼光看待自己手里的代码，不让自己蜕变成只会机械编码的工业化机器。

 

于是，接下来的问题就是：工作中可以有哪些实践？（因为很多时候，我们会因为繁琐而觉得很多流程上、文档上的东西没有必要，那平衡点在哪里？）