程序员如何挽救日渐失控的项目？

回复内容：

以上的情况，都遇到过。
典型的一个业务导向的公司，糙猛快的开发习惯，缺乏懂技术通产品，能控场能抵抗业务压力的技术话事人。随着时间流逝，开发无规，代码堆积，人员流动，能力下滑，架构腐化，逐渐走向结构性崩溃的场景：业务压迫带来了贴膏药的代码，膏药代码导致更大的技术压力，人才流失，疲于奔命，然后带来更大的业务压力。就像飞机掉入了失速螺旋，怎么也改不出来。
曾经花了半年时间，带团队花大代价改出过这样的恶性循环，花了大几百个人日全面重构一个有7、8年历史的老系统，代价是自己的当时绩效对外不好看。
所谓善战者无赫赫之功，此之谓也。
前人栽树，后人乘凉。 干这种活，没有识货的老板，是吃力不讨好。

千言万语，凝聚成一句话：全公司要有靠谱的技术管理和技术文化。这是CTO的职责。
给你归纳翻译一下，问题简化为这些：

1. 如何提高代码质量？【开发能力】
   
2. 如何提高架构水平？【架构能力】
   
3. 如何控制产品需求的合理性和迭代节奏？【项目管理-需求分析/项目规划】
   
4. 如何降低加班强度？【项目管理-资源管理】
   
5. 如何积累知识库，降低口传心授的依赖？【团队建设-知识库建设】
6. 如何提倡团队合作文化？【团队建设-价值观建设/绩效设计】
7. 如何培养团队技术梯队，不强依赖几个核心员工？【团队建设-梯队培养】
8. 如何避免自有通过QA才能保障产品质量的困境？【开发能力-质量保障】
9. 如何提升系统稳定性和可用性？【架构能力】
10. 如何通过产品大图整理出清晰的业务模型？【架构能力-产品规划】
11. 如何拒绝业务方的不合理需求？【项目管理-需求管理】
12. 如何降低人员流失率【团队建设-可惜离职率】
13. 如何在飞速发展的业务环境下回答以上问题？【可落地方案】

自顶向下，依次需要解决的点是：

1. 价值观建设
1. 提倡团队合作。提倡合作？然并卵，谁鸟你，一句现在很忙就把你憋死。作为leader，还是要搞好人际关系，靠刷脸去推合作。
2. 提倡敬业和激情。自己先要成为榜样，不过重要的还是看激励政策。
2. 绩效设计原则
1. 重视拿结果，更重视执行过程。发现、表扬、提拔代码写得好，业务也玩的溜的人。管理不能停留在表面上，要到代码里去。
2. 重视个人技术能力，更重视技术传承、培养人。诶，说你呢，没带过人的同学别想加工资，想晋升给我先带3个徒弟出来。
3. 重视技术创新。天天重复自己的人，再老资格也要给他敲警钟，该fire就fire。挤出项目的时间余量给有想法的人做点不一样的事；必须要有一支发明家队伍，而不是码农队伍，所以，搞条鲶鱼进去动动风水，会有好处的。
3. 产品研发流程
1. 流程保护。和产品团队、业务团队磨合出固定的迭代流程和节奏，并能坚持下来，坚决抵抗不合理的需求和节奏，有理有据地向上反馈。
2. 产品话语权。一个产品设一个技术owner，要具有对该产品的需求评审，设计评审权，开发人员要参与业务调研/业务分析，影响产品设计，争取产品规划和业务模型的话语权。避免成为单纯的技术资源，疲于奔命。
3. 跨部门沟通。提前和产品部门沟通双方的预期和能力，将产品规划和技术规划结合起来考虑，3个月协调一次。
4. 团队建设
1. 人才梯队建设。高手不能太多，也不能太少。微妙，自己意会，橄榄形社会最有活力。
2. hire and fire。60%流失率，这窟窿！还是先加工资要紧，狠狠加，先把队伍拉起来，才有余力做重构的活。
3. 团队文化建设。不管是美国还是中国，哪个总统/主席，都得有个施政口号，让人知道你要干什么，分清敌我。
4. 团队技术能力发展。先把人找齐了。。。
5. 项目管理
1. 敏捷也好，瀑布也要，反正要找个合适自己的项目流程，并严格灵活地执行下去。
2. 加强项目复盘环节，code review。
3. 维持一个合适的工作松紧度。
4. 项目管理的精髓是什么》》》我个人认为是制度化，制度化的坏处其实非常多，但有一条好处，就值得我们采用：那就是有强大的理由能按我安排的时间、我安排的地点来打仗。优秀的pm无一不是时间管理的高手，敢于向试图越过制度胡乱插手的领导说不，这就是项目团队的福音。
6. 系统架构
1. 与实际需求相关，无非就是提升稳定性，可用性、可维护性、安全性的那些架构招数，譬如SOA、服务治理、中间件、负载均衡、降级等等。一个简单清晰可靠、可快速横向扩展的系统架构是基石。
7. 业务架构
1. 业务模型重构
2. 模块化，插件化设计
3. 平台化架构
8. 产品质量
1. 编程规范
2. 设计模式
3. 单元测试和自测
4. QA 和 code review
5. 故障复盘
9. 组织发展
   
1. 知识传承
2. 挖掘技术深度和创新意识
3. 内部培训和外部培训
4. 鼓励创新的机制

写完回顾一下，自己都觉得好笑，有点空列大纲无法落地的感觉，呵呵，实际的困难肯定远远超出预期。要想改变一条船的航向，首先你得有舵手的影响力（成功资历，直接管理技术团队），其次获取船长（老板）的支持，再次你得真的知道正确的航向（怎么做），接着得到船员的支持（公司其他团队的理解），优化调动自己的力量（所有开发都认同你的理念，招聘合适的人才），然后还要避开暗礁（别让项目失败），通过一次次的胜利来巩固你的正义。

太他妈的难了，所以很多人都劝你开溜，他们是对的，因为99%的老板都看不懂以上这些文字和它们的价值，但老板还知道加人加工资，说明有希望。~~

问问自己，有这个实力吗，确信，扑上去。 这就是所谓的“技术债务”。
就跟公司债务不能全靠会计解决一样，程序员能发挥的作用有限。
当然，作为一个程序员，职业道德里确实应该包含《Clean Code》里说的"童子军规则"：以当童子军为荣，以有女朋友为耻！（错了，错了，不是这个，是　当你离开一个地方的时候，要让它比你来的时候更整洁干净。）
不要重构！不要重构！不要重构！（三体人从半人马座发来遥远的问候～～） 题主接触这个项目多久了？是空降进来的还是一直在做的？

如果是空降来的。依个人经验，越是复杂的项目，不同的人对项目的判断就越容易产生偏差。尤其是之前有一些质量相对高些的项目的经验的人，反而可能会先入为主的对旧项目的表面质量产生要求，但实际并不一定能够找到症结所在，找到了也不一定能制定出周全的方案。

如果是一直在做成长到负责人的，项目做砸有你一份：）那么之前的做法肯定有不合理的地方。这时候可能已经知道项目有诸多问题，但受人在此山中思维定势的影响，已经撞到了手段的天花板了。不接受新方法新思路的熏陶，只能一筹莫展。

个人建议是，起两个团队：一批外部调任招聘为主，技术水平要高，主做支持系统；一批项目内抽调为主，业务理解要精深透彻，主做核心业务重构。两个团队要保持高度沟通随时交换经验，同时要顶住压力不被抽掉去攻坚新业务（苦了剩下的人了：P）。节奏上建议选择有代表性的核心模块，一直做到藕合度满意为止。

通常第一步是最难的，第一个业务拆分结束后，成本投入和实施步骤都有谱了，业务架构的方法论也有了，后面第 N 个依法泡制就行了。 与大多数人相反，我认为这反而是大展身手的时候。

首先，难道你们都没发现“项目在赚大钱”这一点吗？面对一座金矿，难道你一定要买来全世界最好的镐头才能开始挖？你就不怕被别人挖光了？

第二，没有多少公司有google那么牛逼可以只招全世界最顶尖的人才。几个牛人带着一堆普通人才是业界常态。这种情况下，代码质量不可避免的会有所降低。讲句不好听的，就算是google，随着时间的推移，也会有一堆不知所云的垃圾代码和冗余架构。各位鼓励跳槽的，难道就不担心下一个公司的代码也是如此烂吗？在国内，就算是bat这个级别的公司，烂代码也是不少见的。到时候难道又跳槽吗？

难道你就这么自信一辈子只写好代码不写烂代码？只与顶尖高手合作不搭理刚毕业的菜鸟？

所以，必须学会在高速行驶的汽车上换车胎（以下只关注技术部分，至于跨部门合作／与产品 扯皮之类经验，美女rd可以靠姿色，土豪rd可以靠请客，屌丝rd可以靠同为屌丝的同情心，总之，各村有各村的高招，只可意会不可言传）。

具体来讲，无非就是几个方面：

1. 深刻理解业务。这是一切的前提，这一点决定了你“能不能成为一个架构师”。在理解业务的基础上，你才能进行架构，才知道哪些模块是可以热替换的。事实上，很多庞大的系统其实真正不可热替换的部分只有那么一小点儿，其他东西都是可以通过热替换逐步改善的。当80%的东西都改善以后，剩下的20%也就不难处理了。

2. 打好技术基础。如果说第一点决定了你“能不能成为一个架构师”，那么这一点就决定了你“能不能成为一个好架构师”。有足够的技术基础，你精心refine的架构才不至于又变成别人口中的垃圾，你的继任和属下才不会发出跟你一样的感叹。

3. 代码很脏很乱这一点，是最不重要的点。在有了良好的架构的情况下，代码不管多脏多乱，其影响范围也只有自己模块那一小部分。如果代码已经烂到会影响整个架构的情况，那有以下几点可供参考：a. 你的架构是否藕合度仍然太高？b. 你是否派不够资深的人承当了非常重要的任务？

事实上我认为真正的架构师是绝不会脱离代码一线的。一个系统中最难最有挑战性的部分，正应当是架构师亲自coding的部分。如果你亲自coding的结果都不够满意，那你应当考虑的是，你所拥有的资源是否足够搞定这个项目？是否应当降低项目追求的目标？

4. 架构是一个trade off的过程，过于追求低冗余度和过于追求性能都会导致很高的实现与维护成本。成本是架构师第一该考虑的东西。

5. 可能你并不是架构师。完全没有关系，人人都应当站在架构师的角度去考虑问题。当你站在架构师的角度考虑问题的时候，“代码脏乱”，“架构冗余”，这些问题看上去又会有更深一个层次的感受。你也就不至于在面对庞大而表面上无序的系统的时候，感觉看不到方向，而无从下手了。

总之，还是那句话，放着金矿不挖天理不容。有金矿的前提下，架构乱你才有机会。这么乱的架构都能挣大钱，你把架构随便改善一些，岂不是更能挣大钱？ 像这种系统，我们TFS上面一大堆（十来个吧？！反正绝对超过十个）

大部分都是纯手写的哦（当然不是我写的，我是专门来擦屁股和优化的）。
随随便便开一个aspx都千把行JS，随随便便开个js文件都3K+行JS，随随便便开个.cs文件都几千行，随随便便展开个方法都几百行，你跟我说推了重写~~？！
别想了，就这套破玩意也是百多号人用了几年才写出来的，现在每天还在迁入大量的Code呢。

实在忍不了，大不了直接走人，没什么大不了的事情~~ 少吐槽，多干事。 划分成模块，混成一团就划分一个大模块，只对公共接口写好文档，这样即使里面一坨屎，也没用办法修改，但是还可以继续用，修改就新建一个模块实现新的功能。这样就把那坨屎个从今后的开发中隔离了出去 辞职跑路，祝你早日解脱。 没什么可建议的，你能救的只有自己。

赠几句良言与你：

1. 不在其位不谋其政，钱没给够别瞎找事
2. 没break就别轻易推倒重来
3. 戒掉代码洁癖，dirty fix也是一种方法
4. 再牛逼的架构也不能解决所有问题
5. 做事看人，成事看天
6. 对自己好点，提升自己，爱护自己

我相信你是很有理想的，我也是，但别把一腔热血洒在垃圾堆里，不值得。 跳槽吧