做為乙個合格的程式設計師應該做到哪些事呢？熟悉程式語言，掌握框架結構以及相關技術，了解需求，了解程式執行機制……還有呢？
作為乙個程式設計師，你可能會遇到以下這種情況：你接到了來自你的客戶的需求（不管你的客戶是誰，有可能是你的產品的客戶，有可能是你小組的其他成員，有可能是qa人員），你思考了一下這些需求，然後你毫不猶豫的開始編碼了，但是寫到某個部分你忽然發現有些地方不對勁，你目前這種做法是錯誤的，然後你又刪掉或大量修改已寫好的**，這樣反覆若干次，終於算是做好了，或者說是你以為做好了，然後你感嘆的說「做程式設計師真累啊！」，然後你開始做一些簡單的功能測試，結果發現居然有bug，「天那，怎麼會有bug？」接下來自然是修改**，然後回測。「終於修改好了」，你感嘆的說，但事實並非如此，很快你又接二連三的發現了若干個bug，然後自然又是一通修改，氣人的是你修改的**竟然會帶來更多的bug，這使你很怕自己的**，很怕再修改**了，很怕再找到bug，於是如果稍微有人提出一點對你寫的**的問題你就會毫不猶豫的將問題轉推給別人說明如果別人怎麼怎麼改的話就會沒有問題了，讓別人去改他自己的**，而不是你的**，因為你已經害怕了自己的**！如果若干天或乙個月後你的客戶要求你新增幾項或改動一些功能的話你會愁死，而且你會去盡力阻止你的客戶的這種想法，希望他老老實實的使用現有的系統，不要再「瞎鬧」了，因為已經夠亂的了！這一切的結果是什麼呢？你很恨自己的行業，「為什麼當初我選擇了做程式設計師呢？真想轉行！」，當然這只是結果之一！相信你自己或是你身邊一定有這樣的人存在。
現在的問題是，做程式設計師真的要這麼累嗎？回答自然是不用！上面所描述的場景是非常常見的，其中提到了兩個關鍵問題：
程式設計師沒有做預先的設計工作，所以後期出現多種問題需要修改大量**。拿來就寫的工作模式顯然是需要避免的！請注意設計工作不單單是架構師與設計師的工作（架構實際上就是一種設計，只是更泛化）。許多程式設計師當你問他是否用uml的時候他會說用過，但只是來走走樣式，上面要設計圖紙的時候現做乙個拿來敷衍一下，有的乾脆直接反向乙個出來，改都不改一下就當作設計圖來用了。這是不對的，uml的宗旨是幫助你設計，理清思路的，如果你系統都做好了，那還要uml幹嗎？！
程式設計師沒有計畫好的編碼流程，這樣會在編碼階段丟掉一定的效率，這無非是乙個時間資源與人力的浪費。如果一開始就有乙個流程計畫的話那麼只要按照流程走就可以了，不需要程式設計師去隨時浪費腦力考慮何時應該做什麼。另外乙個經過周詳設計的流程是可以應付大部分編碼工作而又可以幫助評估專案時間的好東東。
我們在《編碼之旅》系列中要討論的也正是這兩大部分。值得一提的是關於問題一中講到的設計工作，實際上需要通過了解並掌握設計模式才能做到，這一部分很廣，同時也比較複雜，當你熟悉它的時候才會了解什麼是真正的物件導向程式設計！你也許會覺得有點誇張，「我早就學會oop了」，真的嗎？！我會在以後擠出一些時間來總結一下設計模式以及ood（object oriented design ）的一些原則，歡迎讀者有時間來討論一下！也就是說，在《編碼之旅》中將不會講解設計模式，而只是簡略的告訴你首先你應該有乙個自己的設計，然後在去按照設計好的去編碼，而不是盲目的去寫**。
那麼，閒話少說，起航吧，接下來讓我們來討論一下編碼流程，let's go！
黃山遊記（一）預備篇
五一前的乙個星期，乙個高中好友突然提議出去旅遊，結果沒花多少功夫我們就一致決定去黃山了。心動不如行動，我們馬上開始分工合作，乙個負責聯絡酒店，乙個負責訂火車票。我充分發揮了google的作用，查處一堆網頁，看看上面的 也不貴嘛，馬上照著訂房 打過去，結果那頭一說，完全不是那麼回事，網頁上寫的標間28...
Spring Boot 原理解析 預備篇
spring boot是為了簡化spring開發而對spring的進一步封裝，是對spring的增強。要弄清楚spring boot，首先需要弄清楚spring boot與spring的使用，到底簡化了那些東西，spring boot對spring封裝時使用了spring的那些東西。我們分別以原生s...
網路通訊預備篇 進製計數
只要記住你的名字，不管你在世界的哪個地方，我一定會去見你。電影 你的名字 在我們的日常生活中，每個人的名字對應乙個唯一的身 敏 份 感 證 詞 號，在internet上也是一樣，每台主機 host 包括所有的具有上網功能的電子裝置都有ip位址，有了ip位址，這些電子裝置聯網之後，才能正常通訊。我們的...