軟體工程師的15個信條

原文連結： 15 Tenets For The Software Engineer http://regulargeek.com/2011/11/18/15-tenets-for-the-software-engineer/

特別說明：歡迎積極參與【iTran樂譯】第2期

許多人討論關於使一個軟體工程師能夠勝任其職位所需的知識，另一些人則討論所需要的品質。一般來說，這些話題表面讀起來可能很不同，但是他們的卻有許多相似之處。在現實當中，一個軟體工程師缺少了上述兩個條件中的任意一個都不可能成功。我將這些想法總結成了下面15個信條供您檢閱：

牢記基礎。如果你忘記了你的程式語言的基礎特性，你將失去最基本的知識。那永遠不會是件好事。

總是假設最壞的情況。如果你有經歷過正規的電腦科學教育，你一定學過“大O記號（big-O notation)”（用於表示複雜度的如O(n),O(logn)）。瞭解演算法效率低下的原因是一件好事。弄明白“為什麼在某一個情況下總是特別慢”是你保持成功的關鍵。

測試你的程式碼。無論你使用TDD或其他方法，保證你的程式碼是經過測試的。根據不同型別的測試，你可能需要達到不同級別的覆蓋率，即使如此，你仍然應該寫儘可能多的測試。

不要因為技術新潮而使用新技術，使用它們如果它們可以解決你的問題。在技術方面，我們應該懷著能夠找到“銀彈”的心情去關注熱門技術。酷不是關鍵，實用才是王道。

多閱讀。如果你不閱讀領域知識，你將會落於人後，而且可能還會得職業恐懼症（career threatening complication）。

多嘗試新技術。對，我之前說過不要為了新潮而使用新技術，但是你確實需要去嘗試新東西，以此來決定這些新東西是否有用。而且，嘗試新技術能幫助你走在行業的前沿。

從失敗中學習。退一萬步來說，你至少可以從失敗中學到這個方案不可行，然後你可以完善你的方案。在某些情況下，你甚至可以將失敗看做是一次小的成功。

不要回避問題。有時候你僅僅是為什麼了完成工作，但是你必須清楚你的技術“債務”。如果你持續的迴避軟體而不還清技術債務就是時候，你的噩夢就降臨了。

用正確的方法做事。大多數開發者總有一個實現設計的正確想法，但是他們不是總是專案管理需要的。這或許與上一條“不要回避問題”原則矛盾，但是在他們之間需要找到一個平衡點。

總是寫乾淨的程式碼。不要想著傳揚重構的好處，想想你是不是要維護一堆越來越糟糕的程式碼。如果你每次改動的時候都清理它一下，那麼它可能不會像現在那麼糟糕。

考慮併發訪問。如果你在構建一個web應用（我的意思不是說那種Facebook級別的應用），在負載加重的情況下總可能出現一些奇怪的現象。即使是隻有100個併發使用者的應用程式，都可能出現奇怪的問題，當我們使用併發讀寫比如HashMap時。（譯註JAVA的HashMap不支援併發控制，在這種情況下應使用ConcurrentHashMap。）

儲存可能是自由，但是I/O是糟糕的。你或許認為，把所有東西寫入磁碟是持久化資料的一種絕佳方法。一般來說是這樣，但是如果你把磁碟當做是一個臨時儲存區域，你的應用程式可能瞬間就變成“龜速”。物理儲存應該僅限於資料的持久化或者當資料放不進記憶體的時候。（譯註：這條說的不清楚，作者的意思應該減少不必要的磁碟I/O，因為磁碟I/O比訪問記憶體要慢很多）

記憶體沒有你想象中的那麼快。。開始時，許多人會將應用程式和資料庫放在一臺伺服器上。如果應用和資料庫都是輕量級的，那麼這個方案是可接受的。比如，你可以在一臺518MB記憶體的機器上執行一個TOMCAT和其WEB應用。然而，一旦你要處理規模問題，你不得不根據持久化的需要（RDBMS,NoSQL)加更多的記憶體，你可能很快就會上到8G記憶體，這完全依賴於有多少使用者訪問你的系統和在記憶體中儲存多少資料。（譯註：沒看出小標題和內容的關係。）

快取可以解決一切問題，在它把伺服器搞垮之前。如果你在尋找防止大量資料庫查詢的方法，你最終會使用一些形式的快取。問題是快取相比你傳統的應用程式，需要更多的記憶體，尤其是當在處理的資料隨著使用者數量的增長而增長的時候。快取最糟糕的問題就是它會大量吞噬記憶體直到你出現OutOfMemory異常（在JAVA中）或其他類似情況。到那時，你的伺服器要麼垮掉，要麼變得不能響應或者快取無法正常工作因為它自己也變成了問題的一部分。

像諮詢師一樣思考。作為一個員工，總有一條不成文的規定：作為僱員，往往有條不成文的規定，只要公司能辦成事情，他們就不會去麻煩顧問。最後期限可能延遲，範圍可能擴大，開發者需要找到一個應對新限制的方法。作為一個員工，你需要用你的力量去陳述：最後期限不能變更因為還有大量的工作需要做，或者在資源不增加的情況下範圍不能擴大。往往允許顧問以不同於僱員的方式來管理專案，而我們的工作就是改變這一切。

在我的腦子裡還有許多其他的想法，但是上面這些是我能列出的最好的列表了。對於軟體工程師來說還有其他什麼信條麼？