本週的核心任務是節點規劃的平台化，前3天主要的工作量在整合之前的兩個模組，以及提供前端的介面實現上，這兩部分的工作佔據了我們60%的工作時間，但是工作的感覺比較順利。最後三天在聯調的時候發現了很
多問題。
聯調跟開發的工作量差不多，但是工作的感覺差很多，整體比較不順利。隨著系統整合，整個的複雜度增加了除錯的速度變得比較慢，定位問題的速度也變得比較慢。
發現問題往往是出現在乙個非常低階的邏輯錯誤，系統不紮實。
所以整體上後面聯調的時間雖然跟開發時間差不多，但是輸出的**量卻遠遠少於之前，時間都花在找簡單的問題上了，令人痛心。
從平台化的這些事情加上這段時間關於工作的總結：
我們應該先看**《整潔之道》 再看《設計模式》以及其他更高層次的東西，千里之堤潰於蟻穴，如果連乙個函式的命名，乙個函式的職責都考慮不好，怎麼能厚著臉皮再去高屋建瓴地談設計？最終可能就是會變成
紙上談兵。
不是我們不想寫測試，很多時候是我們自己把自己搞得寫不了測試，各種複雜的依賴，資料。如果有個程式能夠分析出系統的複雜度就好了，只要我們系統複雜度到了一定數值我們就應該暫停手中的活修修系統那該多好。
記錄被忽略的問題，平台化的過程中為了實現目標對外交付，我們過程中是做了妥協。以前的做法就那麼遺忘了，但是這回我們是有記錄下來，當然不要讓記錄只是變成文件。應該要作為我們後續優化系統的出發點。
細節決定成敗
剛剛結束asp的期末考，深刻體會那句細節決定成敗的至理名言。巨長的程式題寫的有種要崩潰的感覺，結果一交卷猛然發現，忘了寫單引號。其實這事情在人家來說是粗心，在對我來說，絕對是對細節的在意，導致低智商型錯誤的頻發。說道細節這事，班裡有三個女生，乙個太在意細節性，以至於一件很快能完成的東西，在其手裡作品...
細節決定成敗？
以下文字摘自donews資深作者 郭子威。1 拍 鐵達尼號 的時候，有八卦說，詹姆斯.卡梅隆要求在船上裝載來自歐洲的瓷器，然後在顛簸中全部摔碎，因為 歐洲貨才能還原現場氣氛 結果憑空多出來幾十萬美金的成本。最後 鐵達尼號 賣了18億刀票房。這則八卦，很容易聯想到 細節決定成敗 等偉大的格言。不過你想...
細節決定成敗
在程式設計師的世界裡，細節對於一位程式設計師來說是至關重要的，稍微乙個小的疏忽輕則會浪費大量的時間去定位 而對於一些應用在 重要領域的裝置上的軟體而言，這種重要性更加不言而喻了，醫療，軍事，這些方面的裝置的故障率是0容忍度的 對與很多剛入行甚至已經時行業大牛級別的人物來說，細節的關注 性都是必要的，...