重构

收到了后台妹子的项目周报

我看了下项目的进度

立即推翻了原定的明天周会的内容

是时间要谈谈重构的问题了

IT界有血统论的讲法

按照我粗俗的讲法，一个程序员的血统是如何定义？

就是被大型（500人+）公司草过

流程重不重要？重要

但是非自己发现的错误，真的难以培养出真正的人才

倒也不一定说一定要翻过错是人才成长的必要条件

但是作为公司的负责人

每天流水花花的，确实很难鼓起勇气来用公司自己的项目和效率来培养足够强势的人才

就像我们往往都希望妹子们要么就是短时间内部生孩子或者过了哺育期后再来

所以只能两者结合，用经验来处理项目、流程、人才之间的关系

重构不应该被理解为，项目特定阶段的出现的时机性任务

而是在项目开始时，就分分秒秒伴随其旁的改进节点

那么重构究竟应该由谁提出？

不能指望每个程序员是好的项目阅读者和模块拆分者

甚至对于项目经理来说，会不会在讲解项目的时候思考到将来有可能走的路提出重构？

我想在国内，可能90%的PM是没有这样的能力的

而意识到重构重要性的PM或者技术总监该如何说服包含老板、项目负责人、团队的所有成员进行重构呢？

1、因为重构的价值是隐性的，不懂的人体现不出价值

2、团队成员的精力问题

3、经验决定重构的时间和出发基点

所以之前所有其他公司项目外包的时候，我们都是以结果为导向，专业的表现也许会被客户理解为不专业的行为，做的里外不是人也没意思。

但现在轮到自己的项目了，必须要他们开始思考这样的问题，并且运用到项目中

重构的意义在与精细化开发的项目中，逐渐负重、复杂的的项目主体的变化

而对于小型项目，不如重新开发。

所以他们会在后期的上线和迭代过程中加以熟悉和掌握重构

这样才能将后期的app组群得心应手的设计和执行。

什么样的架构叫做清晰，什么样的功能模块叫做扩展性强

项目经理在拆分模块的时候，如果理解不了市场

还能指望程序员们理解吗？所以对于可运作项目的死因，

提前就能看到“死神来了”

《重构：改善既有代码的设计》

我很多年前用过的很不错的书，今晚给他们上当当定一本

测试手术式体检难

程序员拖延性执行难

模块间依赖循环打散难

deadline的冲突难啊难~~

这不是她妈逼的，是要自己逼