很多人都参与过失败的项目，
代码脏乱差，补丁套补丁，
硬编码，版本紊乱，
加班严重，人肉文档，
幻想中的需求，人心涣散。
我们都不想看着它失败，
但是又无能为力。
不少能人异士，
提出建设性的方针，
提高开发能力，架构能力，
管控需求，加强团队建设。
似乎可以力挽狂澜一样，
好像真的可以。
实际上，地基如果坏了，
项目就已经完了，是无法挽救的，
不如想想怎样重新来过吧。
我们需要做的，
不是抱怨，也不是消极处理，
而是承认事实，理智对待。
质量只会变得更差
软件质量，一旦比昨天差，
明天只会更差。
一个房子如果窗户破了，没有人去修补，
隔不久，其它的窗户也会莫名其妙地被人打破。
——破窗效应
明天有明天的事情，
如果明天替今天买单，
那今天还不如不做。
期望以后来整理它，
那么这个时间永远都不会到来，
除非那天你不务正业。
当天的事情，当天解决。
永远保持离开时的露营地比你发现它时更整洁。
——童子军规则
如果发现代码质量出了问题，
唯一的办法就是停下手头的活，
偿还技术债务，
把它弄好了再继续。
否则，明天需要偿还的会更多。
需求不需要稳定，需要控制
没有稳定的需求，
作为专业程序员，
早就应该承认这一点。
需求是不可能不变的，
软件的存在就是为了适应变化的需求。
但是，这并不是说我们不用去控制它，
至少我们应该让它阶段性的稳定。
而且，程序员不是仅仅抱怨一下就完了，
软件本来就应该采用灵活的设计。
如果需求乱了，并不是一个人的问题，
抱怨也没有用，所有人都该停下来，
承认事实，再想办法。
早就该调整的架构
没有永远合理的架构，
架构是随着业务发展演变的。
好的架构，
是适用的，同时也应该是易于调整的。
当所有人都意识到模块划分不合理的时候，
早就应该调整结构了，
很多人都知道应该怎么做，
但是，几乎没有人做过，
是因为现在做起来成本太大。
这就给了人们一个假象，
结构调整是复杂的，
不是短期就成实现的。
其实不然，
治理的最高境界，
在于防患于未然。
善战者无赫赫之功，善医者无煌煌之名。
——《曹选》
持续调整，成本并不大，
累积起来，就变成不可能完成的事情了。
团结是每天都需要保持的
等到涣散了再考虑人心，
为时已晚。
不团队的队伍，
再训练也无法变得团结一心。
开除任何一个人，
也无法改善已有的状态。
那怎么办？
我们得承认事实，
有的事情糟了，确实是不可挽救的。
真到了这个地步，
只能全部都干掉。
或者下更大的成本，
用新人组织新的团队，
只加入一个老兵。
我们可不想到这一天，
那么我们今天要怎么做？
还能没有办法吗？
结语
有时候，人们之所以乏力，
是因为还在抱有幻想，
不承认既定事实。
如果一开始就认为，
软件项目做烂了是无法挽救的。
那什么都不一样了，
今天我们只会竭尽所能避免它变坏，
不然等到那一天，
一切都太迟了。