程序員16個建議

1.多看看「官方文檔」程序員

咱們不少的問題和技術細節,其實,只要咱們認真將官方文檔過一遍,會發覺大部分的問題和認識模糊的地方都消失了。甚至,你還能發現本身以前經過搜索得到的到一些資料,多是不許確或者已通過時的。官方文檔是真正的好東西,由於編寫文檔的人羣,一般就是這些技術或者軟件的開發者,他們纔是對這些東西最瞭解的人,所以,他們寫的文檔質量是很高的,一般也是最新的。算法

官方文檔的不足的地方,大概是中文版本很少,看起來可能會比較吃力。不過,請相信我,下載一個翻譯輔助軟件,慢慢看仍是能夠的。另外一方面,就是這些文檔編寫者,一般是技術界大牛,他們編寫文檔有時候是基於他們本身的技術認知水平,跳過了不少基礎概念,也增長了閱讀難度。不過,這個咱們也能夠經過多查資料,慢慢看來解決,而且一般會帶來額外的學習收穫。設計模式

2.比官方文檔更重要的是源代碼markdown

看源代碼 1)意味着你能夠看到以及學習優秀的代碼;2)意味着即便源代碼有坑,你也會提早在大腦有迴路更容易找到問題所在。框架

看不懂源碼意味着不一樣的幾點:函數

1)你對這個庫或者代碼的功能不熟悉 (知道某段源碼的功能及特色)工具

2)你不會用 Debugoop

3)你的算法基礎薄弱 性能

4)源碼太過混亂單元測試

你須要反思本身屬於哪一項。針對其中某一類下藥上來直接從頭看源碼學東西通常是不可行的。你須要從上層入侵到下層。先用這段代碼才能看懂源碼。而不是在上層都不熟悉的基礎上開始。任何重複的代碼/重複的相似代碼。意味着你框架設計有問題,或者開發語言的表達能力不夠。 

Java 的固定設計模式就是 Java 自己表達能力不夠的表現。流程意味着生命週期,即你不只須要抽象已知的流程。還須要在未說起的點留下一個坑 (函數/接口/鉤子)。每每這些坑在之後的需求變動和項目擴展和維護中是救命的點。日誌很是重要,日誌環境也很是重要,debug 是基礎技能,對應的是開發狀態。日誌則對應穩定的線上狀態。而不能重現的 bug 佔整個開發的很是多的時間。因此錯誤日誌記錄詳細的環境意味着你能夠更快的重現這個錯誤。

3.提高 debug 的能力

從高層往底層找錯

科學方法

不少新手遇到程序執行結果不對(尤爲是圖形程序員),先認爲是機器毛病(浮點精度、硬件故障),而後認爲是驅動有錯,再認爲是系統有錯,最後纔開始排查本身的程序。其實 99% 的狀況下是本身程序有錯,而後那 1% 裏面的 99% 是系統有 bug,再接着那 1% 裏的 99% 是驅動有 bug,最後到硬件問題,已經微乎其微了。

應該從高層往底層查,而不是反過來。debug 通常來講是知道現象,但緣由未知。這一點和不少天然科學的狀況同樣,因此徹底也能夠用科學的方法來:提假說->根據假說作出預言->作實驗確定或否認預言。對應於 debug,那就是假設是某個地方有問題,那麼推斷它必定會致使除了你看到的現象以外的其餘現象,運行程序看你的推斷是否成立。掌握這個方法後 debug 不在變成瞎找瞎試,而是有跡可循有系統可依賴的方法。

4.重構是程序員的主力技能

好多設計模式不是提早就設計出來的,而是重構出來的。不少狀況是咱們在作設計的時候考慮不到的,是寫代碼時也考慮不到的,只有在項目上線後,客戶使用過程當中纔會反應出來,這個時候就須要對項目進行擴展,版本升級,這時就體現老程序員實力的時候了,就是根據已有的情形,結合新的客戶需求,使用合適的設計模式,使得代碼可以優雅的擴展。

5.先用 profiler 調查 纔有臉談優化

若是作.net 代碼的優化,也有對應的 Profiler 工具,這個能夠幫咱們快速的定位瓶頸在哪裏。找到了瓶頸纔有接下來的優化工做。

6.一行代碼一個兵

這裏說的一個關於函數的規範問題,有一種說法是一個函數的內容不該該超過 7 行,若是超過 7 行,那麼確定是把多個 Function 合併到一個函數中的,應該拆分紅多個函數。這個要求可能有點高,很難作到。不過上百行,上千行的函數那是不該該的,必須拆分!

7. 最好的工具是紙筆 其次好的是 markdown

紙和筆只適用於在 Face 2 Face 的交流過程當中,交流後頂多拍照留存,根本沒法創建有效的知識庫,之後想到以前的討論,怎麼檢索?怎麼修改?。寫 Wiki 纔是王道,Markdown 只是一種寫 Wiki 的方式罷了。

8.寧肯多算一週 不可少估一天

程序員在估計工時的時候老是太樂觀。隨便開口就是一個小時就能搞定,半天就能作完。徹底沒有想到該修改對其餘模塊的影響。一個修改後的單元測試,可接受測試,UAT 環境測試,再到上線,不少地方都得花時間的。一旦某個測試不經過,而後又得調試,修改,再進行單元測試,可接受測試~~~~,好吧,誰能保證每次修改都是一次經過呢。

9.安裝一個調試器(OllyDBG 或者 WinDBG) 並設置爲實時調試器

一但有程序崩潰就攔下來,除了能夠搶救一些數據之外,還能夠順手分析下崩潰的緣由,找找代碼中的壞味道,檢討下本身的代碼中哪些設計可能會致使一樣的問題。

10.編碼不要畏懼變化 要擁抱變化 

Embace Change 常被許多新手、XPers 和極端主義者看成老要不停改代碼(code and fix)、重構的一個偉大藉口——擁抱變化,其實真實緣由是由於他們的經驗不足,分析設計能力弱,預見、預構能力差,致使需求和代碼不穩定。 

11.註釋是稍差的文檔 更好的是清晰的命名 讓代碼講本身的故事 

結構清晰、可讀性好的代碼固然很重要。然而對於許多複雜系統軟件,經常只有代碼註釋還不夠,更好的文檔實際上是可視化的程序模型,其中包括各類清晰的命名。 

12.在動手寫代碼前先經過循環不變式證實程序正確性 

對待 Bug 毫不能想固然, 實際工程中, 當你修正 1 個 Bug, 頗有可能會引發另外一系列 Bug 的產生, 類比於雪崩效應. 再優秀的程序也會有 Bug, Bug 埋藏越久越是致命的, 這就是爲何要先證實正確性以減小潛在 Bug 的出現的可能, 一樣地, 在編碼-調試-編碼的過程中修正 Bug 極可能會致使新 Bug 產生, 導致開發效率急劇降低. 另外性能也算是 feature. 不達標也算是 Bug. 二八原則在性能上一樣適用, 20% 的代碼決定着程序的整體性能 (Profile 的時候要記住)。 

13.儘可能利用語言特性來保障代碼可靠 避免讓本身產生過大的心智負擔 

例如養成用 const 的習慣,養成多下斷言的習慣。這個小 trick 可讓不少新手程序員快速擺脫「總感受本身寫的東西哪兒有問題」的感受。 

14.爭取不寫超過 40 行的程序 若是超過 20 行 準備把一些邏輯抽出來當函數 

爲什麼 20 行,爲了一些 quick and dirty 的修改作準備;

這樣 quick and dirty 以後一樣,避免有不少 prop 的 class;

避免不了的話應該申請加工資相對於 forloop,用 index 作遞歸會稍微易讀一些泛化是好的,只要泛化以後你寫的測試不超過百行便可有時候,你發現相對於寫庫,不如寫 boilerplate 和 snippets 方便 curry 通常只爲了一件事情,就是爲了調整參數次序,讓 default par 在 一些沒有 default value 的 par 前面;

其餘時候主要爲了填一些語言設計很差的坑。

 15.提交代碼以前 diff 回顧一下本身的全部修改

 提交以前,用 diff 每一行修改都確認清楚是爲何要這樣作,回想一下整個功能是怎麼實現的、BUG 是怎麼解決的。日子久了就會感受到本身的每次提交愈來愈靠譜了,同時,版本庫記錄裏面諸如「去掉一行註釋」、「去掉一行調試代碼」等等也就不會出現了。

 16.避免踩坑

 1)不符合 kpi 的需求不接,一個資深碼農是懂得刷選需求的 

 2) 必定要搞好監控和異常主動發現,監控不是那種讓 sa 看看的花架子,資深碼農懂得如何刷選監控中的有效信息並指導 bug 主動修復 

 3)對上下游作到代碼級別掌握,這樣在甩鍋上能夠立於不敗之地,再牛逼點的,能夠作到指導上下游開發的方向,讓上下游來配合本身完成開發目標 

 4)搞好自動化測試和集成測試,不少老鳥的自動化測試寫的很是有才,場景覆蓋全,業務分析清晰,看一份牛逼的代碼,推薦從集成測試和自動測試入手

轉自:http://blog.csdn.net/egefcxzo3ha1x4/article/details/78412866

http://blog.didispace.com/cxy-wsm-zml-9/

相關文章
相關標籤/搜索