在系統開發方面，可以想像新人面對兩種不同開發方式時所遇到的情況：在沒有工具的狀況下只從系統結構面切入，需要學習的深度與廣度範圍過大且不容易找出規則順序都會帶給新人很大的負擔；在使用開發工具的狀況下，對於需要關心的內容都已經被收集在工具裡，而且是順著思考邏輯（僅有少數實作被參考）編排，比較有助於新人進入狀況。
當新人比較瞭解開發規則後，都會需要跟隨著進入程式碼研究實作的方式，這時候就會遇到程式碼很難看懂的問題。連幾位資深人員都互相認為其他人的程式碼寫得很難懂，又怎麼能期望新人要快速看懂他們的程式？運用一些撰寫思考習慣的改變，鋪陳出任何一個“正常人”都能迅速讀懂的程式碼應是資深者的責任。將寫程式的目標從“電腦上正常執行”拉抬到“讓人一看就能懂”卻是極少人會去做的。
運用工具輔助開發人員明瞭系統開發的範圍與方法，需要深入研究時就由工具與程式實作的介接點進入，進入後的程式碼使用符合人類思考的面向編排並包裝。這樣的安排將有助於快速進入任何一個有興趣的區塊之中研究。
最後，故事再回到最原始的那張硬體架構圖。這個時候看著這張圖，心裡想架設在上面的系統是什麼模樣的呢？
發表文章
真實的狀況是那新人素質很好，而且他們文件只有三份，而且我們也有拿到一樣的，重點是他們有一個月的受訓。
回覆刪除別把文件想的太美，在共同的受訓時候，我們才知道他們什麼文件也沒有。
正確的說，他們後來又跟training單位（另外一家公司）要到一份文件，加上跟原廠取得一份，與原來三份，總共有五份文件，所有東西都在那五份裡面。
回覆刪除其中有兩份是c的.h檔案直接印出，有兩份是error code列表。事實上，問他大多數自己試不出的事情還是要用email回到原廠才知道。
直到要上線了，要一份完整的error code列表還不可得，因為沒有任何人有。就可以知道文件的素質為何。
文件的迷思啊。