從開發到上線差不多用了3個月，其實第一個月就把大部分功能實現了，之后兩個月都是需求的再次確認和修改BUG，期間穿插的做別的一些事情。總的來說比較順利，一馬平川沒有任何卡住的地方，也沒有出現“大腦CPU使用率突然飆升的情況”，但瑕疵太多，在此做一下簡單的記錄。
簡單介紹一下我們的作戰方式。頁面由專門的人切，只制作出部分頁面，類似的自己搞定，之后的樣式問題自己搞定，一個產品經理，兩個程序員，所有的需求都問產品經理，基本上是除了切頁面，其他的都由我們程序自己搞定。做的是一個公司內部的項目管理軟件(網站)的改版和升級，對於我來說基本上是新開發一個系統，因為以前的實現方式不太好，我換了一個實現方式，大約重寫了91.1%的代碼。
對需求的理解不夠全面。了解需求來自兩個方面一個是產品經理另一個是現有代碼。產品經理先跟我大致的介紹了一下，然后自己看現有的代碼，兩者結合得到自己的想法，於是開始開發，期間有問題隨時問產品經理。剛開始的時候加入太多自己的想法在里面，導致對需求的理解有些偏差，導致后期做了一些不必要的修改，修改就是對原有代碼的破壞，本來寫得還行的代碼，被一點點的修改，因為小的修改我們總是不在意，慢慢的代碼就變得不好理解，到后期對部分代碼產生陌生的感覺，我怎么會寫出這樣的代碼。盡管開發期間多次確認過需求，但還是有的地方被忽略掉了。用於理解消化需求的時間太少，導致后期一連串的惡化反應。代碼被改得不好理解，在改之前是別人對你的否定以及自我否定，因為你理解需求有誤，而現在的實現方式又是你對需求理解的結果，毀掉自己的代碼是痛苦的，特別是自己認為寫得好的代碼，還有就是很浪費時間。總之一句話：在需求調研時引入的BUG危害是最大的。
出來混遲早是要還的。不要抱僥幸心理，以為這不會發生，用戶不可能這樣操作，但是要知道，有的測試人員是很“變態”的，用戶也是很懶的，測試人員的一些變態操作會深深植入你的腦海，於是你在測試過程中也會做出異常的因為，於是你的程序就崩潰了，好的，你終於意識到這是個問題，於是你又開始了你的代碼修改之旅，也許是個快樂的旅程，更可能多的是痛苦的枯燥的沒什么意義的自我批評。可能你還是無視測試人員的變態，運氣好的話這種問題一直都沒出現，直到遇到一個相同變態的用戶，地獄之門突然向你打開，你開始承認錯了，你該承認錯誤了，在開發中我認為可能出錯的地方大部分都被測試人員發現了，沒有被發現的，我也默默的改了，因為我相信出來混遲早是要換的。
成也蕭何敗蕭何。程序員成就了自己的軟件，也是最了解自己作品雞肋在哪的人，如果我們像測試人員一樣摧殘我們的軟件，或許我們能發現測試人員發現不了的問題，同樣測試人員發現的BUG就越少，你的BUG列表就干凈多了，在這次開發過程就是自己測試太少了，前前后后至少改了大大小小150個BUG。也明白別人發現自己那么多錯誤多沒意思，你發現的問題越多跟別人口水的時間久越少，效率一直都是我追求的，也是因為一直追求開發效率導致這么多BUG。
要有一點喬布斯精神，追求完美。因為我們是程序員，我們是有思想有主見的人。我們不能別人讓我們怎么做我們就怎么做，這樣很沒勁，被否定久了就必須反擊。需求可能不是很合理，咋們可以給個更合理更完美的實現，頁面板塊的色調搭配不合理，我們就應該大膽的質疑，給出自己的方案，你不覺得否定別人的方案給出自己更好的方案很爽嗎，軟件是我們程序員的作品，它應該有我們的思想，我們的設計理念，軟件對於我們來說不應該僅僅是執行、實現。我們必須打一場漂亮的反擊戰，反擊設計、反擊測試、反擊產品經理。只有這樣更好的提高自己，才可能做出更好的軟件。軟件使我們的孩子，必須有我們的DNA，我們應該讓他出生后比人的孩子更帥更聰明，直到有一天你很淡定的告訴別人：這是我的優良品種。
心有多遠，思想就有多遠，軟件隨想還在繼續......
作者：陳太漢