在工作將近一年時，在交接完離任同事的工作，在他留下的工作和程式碼之中發現了很多的問題，對於軟體工程需要新的理解，於是乎買了本《程式設計師修煉之道：從小工到專家》，學習一哈．
以下是樹中的tips以及本人的理解：
care about your carft.
我想這應該是程式設計師最基本也是每一位程式設計師該具備的素質．對自己的程式碼如同藝術品，玩物，理應將它們雕琢得完美，如果沒有相應的技藝，雕琢出來的終究只是粗糙的次品．
2. think! about your work!
思考，在你踏出每一步時都應該先思考是否該這麼做．認真想清除你接下來的行為會產生什麼樣的結果，該怎麼做，因為一時的隨意，可能會導致在接下來的工作中產生大量的麻煩．100行裡有60行是修改的注釋程式碼，那可真蠢．我可不想rollback.
3. provide options,don't make lame excuses.
經理老大叫我去做個工廠全區地圖，而且要用公司現有的花了大價錢買來的平台，可是那個平台弄不了動態地圖，當初我直接就合老大說這個動態地圖實現不了，除非換乙個平台，然後這個專案就慢慢擱淺拖著了．現在想想，如果當初和老大交流的時候先直接找到其它能夠實現的方法，或者在那個平台上自己寫下指令碼，說不定這個專案就下來了而且由我負責，可惜了．對於客戶的需求，永遠不要直接拒絕，可以想先嘗試下其它的方法或不同的方式，因為拒絕，也許在客戶看來，這只是你技術不行或怕麻煩找的藉口，公司找人回來是解決問題的．
4. don't live with broken windows.
破窗戶，代表的是程式中的小瑕疵或者小問題．對破窗戶零容忍，是防止軟體快速腐化的方法之一．如同轎夫的新鞋一般，嶄新的鞋子轎夫會小心避開水坑防止弄髒，可是一旦鞋子不小心被弄髒了，那麼接下來可就不會太過於注意保護自己的鞋子了，因為它已經是"髒"的了．我們在開發軟體時也如此．如果軟體開發過程中從一開始就小心避免bug或小瑕疵的產生，視為藝術品，那麼在接下來的開發中，產生的問題也將也少，誰也不想"弄髒"自己的新鞋．如同前任交接過來的程式碼，小問題一堆堆，看得我完全不想對它進行修改，想讓它就這麼安靜地不更新，然後面對的問題就是使用者反饋回來的問題不能及時拒絕．面對這種情況，也許應該將他原來的程式碼檢查，測試，將新"鞋"洗乾淨，規範化，方便以後的維護及開發．
5. be a catalyst for change.
請求原諒比獲取許可更容易．有時想促成乙個專案並沒有那麼容易，因為每個人都存在或大或小的私人，憑什麼要為你乙個人的想法買單．在這種情況下，可以嘗試想做出樣品或基礎原型，捧著"石頭湯"(之有石頭的湯)去找擁有能改變使得這你軟體變得完善的人，告訴他，我軟體已經做得差不多了，但是如果有你提供得支援，這個專案將變得更加完美．向每個擁有材料的人需求支援，統籌支援，做專案的"催化劑"，你做出來東西了，別人才會更容易同意你的意見．你向老大說："老大，我們做乙個可以3d檢視生產線的軟體吧"，老大也許想了想，你說得這麼廣泛，如果做出來得東西耗無作用咋辦，拒絕了；如果你拿著出了效果的半成品先給他演示一番，及時沒有達到預期的效果，也許老大看你做都做出來了，乾脆就直接同意了呢．嗯，催進改變，推動專案，怎麼感覺有點向專案經理的活兒呢．
6. remember the big picture.
ps:持續更新中．．．
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...