书写优雅的代码和快速交付软件两者间的艰难取舍

        我一直觉得，判断一种观念的对错或适用与否时，一定要关注观念的提出者的身份背景，啰嗦一点，就是尽可能去了解作者是在什么时候，从事什么工作，遇到什么状况后提出的这种观念，想法？

        我从2000年10月开始在受聘于企业，开始编写企业的应用软件至今，大部分的工作内容都是开发企业信息化管理软件（现在流行叫ERP）。刚开始那几年，心中根本没有编写优雅代码的概念，那时在规定时间内能磕磕碰碰完成公司交付的开发任务就暗自庆幸了（当然经常是延期交付，汗！）。这些年，看了设计模式、编程珠玑之类的书，也看了些共享代码啥的，感觉有了些提高，似乎也能写点优雅的代码了，在用循环处理事情时，也能试着看看能否用递归啥的实现，或者掉过来，看到别人用递归实现时，自己能不能用循环实现之，也用类的思想封装了些商业逻辑和运算逻辑，也用了自定义事件、自定义控件啥的...

         也下载了网上别人很多所谓的垃圾代码，也下载些所谓优雅代码。也自认为自己写了很多优雅代码（估计会被很多人鄙视），或许垃圾代码更多...

但，我今天想说的，以上的这些都不重要。重要的是公司给我的软件的完工日期是何时？还剩多少时间来完成（不敢说完善）我的代码？可以肯定的是，想要用优雅的代码在规定的时间内完成工作任务，不是件轻松的事。并且我知道，业务经理和老板不关心你的代码是否优雅，你的客户就更不关心了。他们都只关心你何时完成，请相信我，我以十二年的工作经历证明了这个事实，当然这不是写垃圾代码的借口。

         再次啰嗦一下我曾经的事实。开始进入软件编程行业的2-3年，我不知道优雅代码这回事。再过2-3年，知道了自己和优雅代码的距离，努力追赶之，经常加班还是经常延期才完成工作任务。后来开始带人了，又从这些人身上看到了当年的自己...

        优雅的代码和快速交付，貌似不可调和。6年前我是这么认为。但现在不是。

        最近的6年，我印象中最大收获是，明白了编程工作的本质，或者说我这份工作的实际意义吧。往抽象处说，编程和其他任何工作一样：第一是，完成工作（不管是规定时间内还是延期，必须完成）；第二是，尽快完成工作（在规定的时间内完成，或者短时延期）；第三是，好好完成工作（规定时间内完成，还要有品质，有优雅的代码）。对于现在的工作，不管是自己直接担负的代码编写任务，还是要分配下去的代码任务，我仅意识到这三点，下面为之浅议：

        首先，根据自己的编程经历，预估时间，再结合程序员自我预估的时间，定一个任务截止日期，在规定时间范围内的前10-30%的时间里，完成最核心的工作，或者说，下一个结论，确认一下这个任务是不是一个可以完成的任务，是不是需要放弃？是不是需要增加人手，或者换人？是不是需要调整任务的截止日期，延长或提前？

        第二步，尽快完成工作。这一步，允许程序员以上一步调整后的截止日期为标准，占用其中的50-60%的时间长度，以最快的速度完成任务，这期间，程序员可以忽略任何编程规则，只求能以他所能达到的最快速度完成。完成质量我是这样要求，程序员可以自己选择相关的业务员，只要该业务员能为之写下基本认可（不强求业务员说OK）该软件的书面报告，本步就算过。

        第三步，剩下的大约30%的时间，程序员尽可能将主体逻辑做成诸如 逻辑与界面分离、相对独立的逻辑拆分成单独的函数或类，逻辑类似或重复的地方抽取出来为函数或类，然后多处引用等等。算是努力向优雅代码靠近吧。

        这就是我在面对二难选择时的选择。

        当然，我也一直因自己没完完全全编写出理想中的优雅的代码而内疚，不知在程序员的世界里与我有同感的兄弟姐妹怎样看待？

        我想起了小时候的一个现象，那时候我们一开始吃饭都是用勺子（当然最开始时小手，哈哈...），后来才开始习惯用筷子，最重要的是，我们一定不能饿肚子。当我们遇到优雅代码（很有可能延时交付,如同用筷子）与快速交付（很有可能是垃圾代码，如同用勺子）时，做如何选择呢？当然也是，我们一定不能饿肚子...

        小小的心愿是，以上这些，对你有所帮助。甚幸甚幸！