项目的关键在开始

 一直很鄙视叫嚣“软件蓝领”和“程序员吃的是青春饭”的一些人，这些人肯定没经历过维护糟糕代码的经历。很多人鼓吹重要的是设计啦，架构啦，于是乎出了好多的架构师，软件设计师，居然还有软件设计师认证考试。于是大家一股脑的想往架构师发展，包括我面了很多人，问：“将来怎么规划啊？” ，基本上清一色回答：“想做架构师”。我承认设计和架构是很重要，甚至可以说没有好的设计和架构的软件注定是要失败的。但是我发现很多中国人包括我自己都容易忽视细节。有外国人问，“你们中国很厉害可以把飞船弄到月球上去，为什么有些小的事情办不好？比如公路造了又挖，挖了又造”。

　　神在细节之中：宏大建筑中最细小的部分，比如关不紧的门、有点没铺平的地板，甚至凌乱的桌面，都会将整个大局的魅力毁灭殆尽。然后你就不会珍惜那些地板，因为它本身就是低劣的，你也就没心情给它打蜡，它也就越来越差，最后你觉得这房子真是太差了。---------好的设计师不仅设计整个架构，也亲自挑选每扇门的把手。我也一直认为源代码就是设计，糟糕的代码等同于糟糕的设计。

　　其实每个热爱软件的程序员都是艺术家，艺术家愿意在他们满意的作品上花费大量的时间，倾注自己的心血。但是面对拙劣的半成品时，都巴不得离得远远的，碰都不要碰。当我们看到混乱不堪的代码时 ，已经没有心情去重构，甚至在自己编写的时候都不再简洁，只是想着早点写完脱离掉。曾经接手过一个项目，时间紧，要求多，代码也够混乱。我们连续加班了几个星期，最后大家只想早点结束这个项目，因此代码里充斥着复制黏贴的东西。最后项目交付了，但是之后一直需要维护。这个软件已经深陷泥沼，还不如推倒重来。

　　破窗理论：窗户破损的建筑让人觉得似乎无人照管。于是别人也不再关心，他们放任窗户破损。最终自己也参与破坏活动，任由垃圾堆积。最后一扇破损的窗户开辟了大厦走向倾颓的道路。就像到了高级优雅的地方，你自然会约束自己的行为与环境相符，同样到了嘈杂混乱的环境，如果你继续保持“优雅”，不会被其他人认同。慢慢的你也会变的“嘈杂混乱”。所以不要让第一扇窗户被打破，或者马上修复它。

      “我想重构，但是代价太大了！”

　　 这是我做过的一个项目的体会，一开始就发现了代码充斥着很多不好的东西，而且缺乏注释，然后我对项目经理说，这个我重构一下吧，他表示支持，然后我就动手了，很快，代码就变得整洁一点了，但是问题出来了，没有单元测试，我不知道我的改动是否对系统不会产生坏的影响。只能等到集成测试的时候，这个时候冒出了很多的bug，接着***就说这里不能这样，另一个***说那里是不能这样的。最后我把代码再重构了下，总算好了，但是这么一折腾进度就花了很多时间，项目经理开始对我施压，然后我就放弃了，我也开始复制黏贴。最后项目结束了，大家都高高兴兴的。但是隐藏在里面的那么多问题有谁关心呢，这以后的维护成本有谁去算过呢？特别是在没有设计文档，糟糕的注释甚至没有注释，到处混乱的代码，如果一个新人接手，不出bug也难吧。

　　如果你是位医生，病人请求你在给他做手术前别洗手，因为那会花太多时间，你会照办吗？当然不，为什么？因为医生比病人更了解疾病和感染的危险。如果医生按照病人说的办，就是一种不专业，甚至是犯罪。

　　同样的当产品经理因为进度问题，要牺牲某些洗手时间的时候，我们能勇敢负责的拒绝吗？多少次我们因为项目时间的紧急没有写设计开发文档，没有写单元测试，甚至没有写注释。我们以为这就是节约时间，但是出来混总要还得，从长远看利息还不低。

　　如果一头狮子领导一群羊和一头羊领导一群狮子打架，谁会赢？

　　很多问题需要领导和制度来保障------重要的不是产品，而是为产品提供支撑的团队和员工，以及为他们提供保障的制度。

　　如果你想做好一件事，你要同时做好很多件事，只有这些配套的事情都做好了，你才能把这件事给做好。所以上面说的目前也就停留在我的YY中。