前言：之所以有此一文，不是空穴來風，也不是故意的譁衆取寵，而是最近的一些所見，所感。在本文中總結出來，希望對大家有幫助。
因爲一些工作原因，其他的系列文章沒有接着寫下去，還望大家見諒。
本篇的議題如下：
不要成爲代碼的機器
如何有效的項目評估
不要成爲代碼的機器
開發人員的事情就是coding，沒日沒夜的coding，而且大家都是這樣在coding，但是效果和結局就不一樣：有人coding了N多年，技術還是原地踏步，編寫出來的代碼還是bug連連；有人coding就變成了技術骨幹，甚至有人成爲了CTO, 架構師等。
爲什麼？
首先從一個小的故事說起：一個項目，分配給了項目組的人開發。於是大家就熱火朝天的幹了起來。當時，就發現了一個現象：任務已分配完成之後，有人就開始coding了，噼裏啪啦的開始敲代碼，不久之後又開始噼裏啪啦的改代碼，然後又開始不斷的調試，找出bug，然後修改bug。很快，這個迭代的期限就到了，原計劃要完成的功能很多沒有實現，有的人也確實做完了，問題也一大堆，有人也確實完成了，沒有bug，但是在審查他的代碼的時候，就是看不懂。
這裏想起了自己剛剛步入IT開發行業時候的情景。總是希望儘快的把事情搞完，因爲只要沒有做完，就拖了項目的後腿，很可能被leader訓導，甚至可能被認爲沒有能力而被開除。在寫代碼的過程中，發現一點：儘管寫代碼的速度是快了，但是在寫完了之後，每次編譯，都發現錯誤，編譯通過了吧，邏輯又有錯誤，然後就這樣不斷的縫縫補補，功能是完成了，但是心裏有一種想法：以後千萬不要讓我來看和來改這段代碼。因爲代碼寫的很爛，爛的連自己都不想看，而且很多實現的方式也是很詭異。反正結果是：功能完成了。其實自己心裏也很清楚，在寫代碼的時候，腦子有點糊，而且寫着寫着就不知道寫什麼了。
後來慢慢的發現：如果再這樣下去，對自己的發展是沒有好處的，而且原本認爲很有技術含量的編程活動也變成了一種沒有技術含量體力活，有時候甚至不用腦子。
就如軟件開發中的需求一樣：變化。
人也要：改變。
所以在之後的項目開發過程中，就給自己定了一個目標：寫完一個小功能的代碼，確保一次就編譯通過（當然，在寫代碼的時候肯定得注意邏輯，但是偏重在使得編譯通過），於是，在開發的時候，就開始“用心”了，或者說是更加的細心了。
一段時間的磨練之後，這個目標達到了，而且還超出了期望的值：寫完一個大的功能代碼之後，編譯也沒有錯誤。
所以這裏悟出了一點：同樣是做事情，做的也是同一件事，目標不同，結果就不一樣。
這樣之後，寫的代碼質量確實是提高了，但是另外的問題又出來了：寫出來的代碼總是在縫縫補補，總是這裏差一點，那裏差一點。很多地方很欠考慮。
怎麼辦？
發現了怎麼一個問題：每次在任務分配了之後，就開始coding。這沒有錯。大家都這麼做的。但是有一點：每次在實現一個功能的時候，總是一邊寫代碼，一邊思考，就這樣，一步步的把功能實現。其實這就是問題所在。
就好比下棋，你總是走一步算一步，但是你的對手在走一步的時候，已經想到了後面的3步，4步，甚至更多步怎麼走。如果你和這樣的對手下棋，輸家常常是你。
寫代碼也是一樣的，不要走一步算一步。在寫代碼之前，首先從業務上，要把這個功能的流程搞清楚，然後再考慮：如果實現這個流程，要怎麼寫代碼。然後在開始寫代碼，於是帶着這個思想，發現自己寫出的代碼邏輯錯誤就少了，起碼在總體的流程上是對的，可能在有些地方缺少一些考慮，如驗證等。這樣bug也少了，開發的速度自然快了。
說白了，就是在實現一個功能之前，先要設計，或者專業一點，畫畫流程圖，其實流程圖也不一定非得用UML畫的那麼標準，很多時候，就是拿一支筆和一個練習本開始畫了，只要自己認識就行了。
採用這種方式之後，發現不僅自己的設計能力提高了，而且對開發出來的功能也是很有信心的。
一個功能，在草紙上設計，一個模塊，也這樣設計，甚至一個小的體統也這樣設計，慢慢的，就可以上機coding之前，整個功能就已經在頭腦中實現了，剩下的就是轉爲代碼的事情了。
如何有效的項目評估
在項目中，總是想控制項目的進度，但是每次在開會的估算一個功能什麼時候可以做完的時候，往往聽到的卻是這樣的話“應該可以在一週之類完成”，“估計應該可以吧”，等等，諸如此類的沒有把握的話，最後的結果是：什麼時間規劃都是白搭，延期，再延期。
其實很大的程度上就反映了設計的問題。
怎麼說？
其實當我們在估算項目的時候，很多的時候我們沒有一個準確的估算，或者說只有一個大概的估算。其實這就是設計做的不夠。
當一個任務分配下來之後，我們確實一直在考慮業務流程和怎麼實現，但是終究只是停在“考慮”上，沒有進一步的細化，細化的顆粒度不夠，沒有細化到用到幾個類，幾個方法，很多的時候只是大概的想想怎麼實現。就因爲這樣，項目的風險很大，甚至不能控制項目，而且也不知道項目是否按照計劃在在進行。
如果設計做的充分的好，最後的結果就是：整個類，流程都基本敲定，只是填充方法的實現而已，這樣項目是否按照計劃進行就一目瞭然。
當然，這裏不是閒着沒事專門的說教，也不是說些大話，空談，大談。
其實，編程終究是需要動腦的，多多的思考。