not just get it done

 

gmail的签名档是carmack给abrash的黑宝书做的序中的一句话：

“Much heroic programming ensued. Several hundred thousand lines of code were written. And rewritten. And rewritten. And rewritten”

这句话与其说是出自一个coder之口不如说是出自一个artist之口，只有对待自己的东西如对待艺术品的人才会熬很多个通宵做这样的事情。

我们可以很好的理解这种人的想法，做出来的东西最终能变出多少钱都不是那么重要的，重要的是整个过程写出的东西一定是在审美上是完美的。

设计的更加贴合需求，算法的选择，实现的优雅，甚至针对底层的优化都要做到满意为止。

这种想法是我一直很推崇的，但是在商业公司的时候不可避免的这种艺术家的追求和商业利益（也就是项目进度）有冲突，项目需要的是在预计的时间内，达到一个预计的quality。这显然和前面说的不那么在乎最终利益，却有着极端的品质追求的想法大有冲突。

这也是很多开发者开的公司会拿出那么惊人的作品，而一些大运营商总是拿出一堆烂作的重要原因所在。

同时也是大运营商每年收入那么多，而很多有理想的小公司总是倒闭的一个重要原因。

上面可以说是对于hacker价值观下的对待代码的态度的简述，可以理解在bussiness这一端是just get it done，在hacker价值观的一端是make it perfect。

 

 

回到实战中，可以肯定在项目有压力，需要为接下来的预算奋斗的时候，把代码写到自己实在挑不出毛病为止会耗费过多的时间，肯定是一个不合理的选择。

但是把东西根据需求刚刚完成到“get it done"也不够，get it done到make it perfect之间的这个差距可以理解为毒性，弄了一个get it done的feature到项目里可以理解为它在项目里放了一点点毒，这个毒性的破坏力与项目规模和项目的长度成正比。

在中后期进入项目的同学常常会发现项目的结构设计莫名其妙，代码实现和其命名根本不是一个东西，文档注释和现在的东西也大相径庭。

这些就是前期放出的毒带来的恶果，于是项目变得缓慢而痛苦，最后影响到品质和销量，而大家的辛勤劳动变成这么一堆shit也是很让人不爽的事情，而所有这些并非必须如此，本来是可以变得更好的。

一般情况下，这里有项目里boss的不合理push的原因，也有开发者没有争取去做正确的事情，总想着让boss开心的原因。

所以预估的时候需要把消除毒性的时间加进去，否则前期的毒性将会一直侵蚀项目的质量，这个后果很严重，任何人都应该尽量避免这个事情，大致说来大家看到一个feature被很好的实现了，小人欢快流畅的跑来跑去，但这只是所有工作的%60--%70。

接下来结构的调整，实现过程中内存的调整，文档注释的工作等一定要计算进去。

 

 

小结：

• 需要在hacker价值观与business价值观之间做一个平衡，追求完美的人和追求利益的人都要找到自己的让步点
• 需要充分认识到单纯hacker或者单纯business的做法的坏处，不只是知道，而且要理解
• 在激烈竞争的今天，可以理解项目内部push的情况，但是可以采取加班延长工作时间的方法，但是不能采取跳过正确的事情而作错误的事情的方法，否则后面就是要付出更大而且大的多的多的代价
• 不可违背自然规律做事，很欣赏认真向程序员问问题并尊重开发规律的boss。

 

原文链接： http://blog.csdn.net/ccanan/article/details/5948335