前言：之所以有此一文，不是空穴來風，也不是故意的譁眾取寵，而是最近的一些所見，所感。在本文中總結出來，希望對大家有幫助。
因為一些工作原因，其他的系列文章沒有接著寫下去，還望大家見諒。
本篇的議題如下：不要成為**的機器
如何有效的專案評估
不要成為**的機器
開發人員的事情就是coding
，沒日沒夜的coding
，而且大家都是這樣在coding
，但是效果和結局就不一樣：有人coding
了n 多年，技術還是原地踏步，編寫出來的**還是bug
連連；有人coding
就變成了技術骨幹，甚至有人成為了cto,
架構師等。
為什麼？
首先從乙個小的故事說起：乙個專案，分配給了專案組的人開發。於是大家就熱火朝天的幹了起來。當時，就發現了乙個現象：任務已分配完成之後，有人就開始coding
了，噼里啪啦的開始敲**，不久之後又開始噼里啪啦的改**，然後又開始不斷的除錯，找出bug
，然後修改bug
。很快，這個迭代的期限就到了，原計畫要完成的功能很多沒有實現，有的人也確實做完了，問題也一大堆，有人也確實完成了，沒有bug
，但是在審查他的**的時候，就是看不懂。
這裡想起了自己剛剛步入it
開發行業時候的情景。總是希望盡快的把事情搞完，因為只要沒有做完，就拖了專案的後腿，很可能被leader
訓導，甚至可能被認為沒有能力而被開除。在寫**的過程中，發現一點：儘管寫**的速度是快了，但是在寫完了之後，每次編譯，都發現錯誤，編譯通過了吧，邏輯又有錯誤，然後就這樣不斷的縫縫補補，功能是完成了，但是心裡有一種想法：以後千萬不要讓我來看和來改這段**。因為**寫的很爛，爛的連自己都不想看，而且很多實現的方式也是很詭異。反正結果是：功能完成了。其實自己心裡也很清楚，在寫**的時候，腦子有點糊，而且寫著寫著就不知道寫什麼了。
後來慢慢的發現：如果再這樣下去，對自己的發展是沒有好處的，而且原本認為很有技術含量的程式設計活動也變成了一種沒有技術含量體力活，有時候甚至不用腦子。
就如軟體開發中的需求一樣：變化。
人也要：改變。
所以在之後的專案開發過程中，就給自己定了乙個目標：寫完乙個小功能的**，確保一次就編譯通過（當然，在寫**的時候肯定得注意邏輯，但是偏重在使得編譯通過），於是，在開發的時候，就開始「用心」了，或者說是更加的細心了。
一段時間的磨練之後，這個目標達到了，而且還超出了期望的值：寫完乙個大的功能**之後，編譯也沒有錯誤。
所以這裡悟出了一點：同樣是做事情，做的也是同一件事，目標不同，結果就不一樣。
這樣之後，寫的**質量確實是提高了，但是另外的問題又出來了：寫出來的**總是在縫縫補補，總是這裡差一點，那裡差一點。很多地方很欠考慮。
怎麼辦？
發現了怎麼乙個問題：每次在任務分配了之後，就開始coding
。這沒有錯。大家都這麼做的。但是有一點：每次在實現乙個功能的時候，總是一邊寫**，一邊思考，就這樣，一步步的把功能實現。其實這就是問題所在。
就好比下棋，你總是走一步算一步，但是你的對手在走一步的時候，已經想到了後面的3
步，4步，甚至更多步怎麼走。如果你和這樣的對手下棋，輸家常常是你。
寫**也是一樣的，不要走一步算一步。在寫**之前，首先從業務上，要把這個功能的流程搞清楚，然後再考慮：如果實現這個流程，要怎麼寫**。然後在開始寫**，於是帶著這個思想，發現自己寫出的**邏輯錯誤就少了，起碼在總體的流程上是對的，可能在有些地方缺少一些考慮，如驗證等。這樣bug
也少了，開發的速度自然快了。
說白了，就是在實現乙個功能之前，先要設計，或者專業一點，畫畫流程圖，其實流程圖也不一定非得用uml
畫的那麼標準，很多時候，就是拿一支筆和乙個練習本開始畫了，只要自己認識就行了。
採用這種方式之後，發現不僅自己的設計能力提高了，而且對開發出來的功能也是很有信心的。
乙個功能，在草紙上設計，乙個模組，也這樣設計，甚至乙個小的體統也這樣設計，慢慢的，就可以上機coding
之前，整個功能就已經在頭腦中實現了，剩下的就是轉為**的事情了。
如何有效的專案評估
在專案中，總是想控制專案的進度，但是每次在開會的估算乙個功能什麼時候可以做完的時候，往往聽到的卻是這樣的話「應該可以在一周之類完成」，「估計應該可以吧」，等等，諸如此類的沒有把握的話，最後的結果是：什麼時間規劃都是白搭，延期，再延期。
其實很大的程度上就反映了設計的問題。
怎麼說？
其實當我們在估算專案的時候，很多的時候我們沒有乙個準確的估算，或者說只有乙個大概的估算。其實這就是設計做的不夠。
當乙個任務分配下來之後，我們確實一直在考慮業務流程和怎麼實現，但是終究只是停在「考慮」上，沒有進一步的細化，細化的顆粒度不夠，沒有細化到用到幾個類，幾個方法，很多的時候只是大概的想想怎麼實現。就因為這樣，專案的風險很大，甚至不能控制專案，而且也不知道專案是否按照計畫在在進行。
如果設計做的充分的好，最後的結果就是：整個類，流程都基本敲定，只是填充方法的實現而已，這樣專案是否按照計畫進行就一目了然。
當然，這裡不是閒著沒事專門的說教，也不是說些大話，空談，大談。
其實，程式設計終究是需要動腦的，多多的思考
本文出自 「燕洋天」 部落格，請務必保留此出處
如何成為優秀的開發人員？
對於每個從事開發工作的程式設計師來說，成為一名優秀的開發人員或許是他們一直所最追求的目標。就如何成為一名優秀的開發人員，alan johnson發表了一篇博文 what makes a great programmer?csdn對此文進行了翻譯，全文如下 事情猶如發生在昨天，那是在2000年，par...
如何成為優秀的開發人員？
事情猶如發生在昨天，那是在2000年，pargas博士正在給我們資料結構班講解有關資料結構方面的話題，當他講解部署ssh應用時，乙個同學問了他乙個問題，當時他圍繞 如果你想成為乙個真正計算機科學家，你就要從學習vi編輯器開始。說了一些事情。因為他說這些話的時候，面帶微笑，事後我並不覺得他的話正確。但...
如何成為優秀的技術開發人員？
1.保持學習 乙個非常重要的觀點是 如果你停留在乙個地方不前，並不代表你能一直呆在那裡，而是代表你正在落後 不進則退 往前進並不意味著你是就能進步 這至少你不會淪落到最後 付出就會有收穫 程式設計師為了保持向前發展，就需要不斷學習 我們需要的不是慢慢的往前走，而是我們要奔跑起來！下面列出這方面的幾個...