本文作者 Siavosh 是一位程式設計師,他在自己的部落格上發表了,在花了五年開發程式後的心得,這些心得的排序,並沒有特定次序的分別:

  • 程式設計的小撇步:

1. 當效能 (Performance) 成為實作中的一個問題時,如果你能在應用層 (Application) 處理它,就將它從資料庫層 (Database Layer) 獨立出來,像排序 (Order) / 分群 (Group) 的應用就是典型的例子。在實務中,將應用層做橫向擴展 (Scale Out) 要比資料庫層容易許多。

2.  關於平行處理 (Concurrency),如果能避免就儘量避免。如果無法避免,那麼請記住,不要誤以為平行處理的速度一定比較快,也不要做過度的平行處理,因為它會耗用掉更多的資源與提升處理的成本,尤其必須注意執行緒 (Threads) 的應用問題。

Ex : 在 iOS 的應用上,GCD (Grand Central Dispatch) 的核心是分配佇列 (Dispatch Queues) 和運作佇列 (Operation Queues),負責分配調度任務給不同的電腦元件處理,而不需要程式設計師來煩惱這些問題。畢竟,人類的心智不是被設計用來理解 / 記憶所有的事情的 ── 這些都是我自己在實務中所獲得的第一手經驗。

3. 盡可能地簡化 (Minimize State),盡可能地區域化 (Localized),這能讓功能模組 (Functionalist) 是可行且實用的。精簡可重用的方法會對你有幫助的。

4. 程式註解有時是具有風險的,因為不好的註解除了無法提供正確的資訊之外,還有可能會誤導編程人員,但這些問題都不能做為「不寫註解」的藉口。

5.  程式註解並不需要鉅細靡遺,你只需要就關鍵部份具體地描述,因為你的記憶力可能會背叛你,也許在過了一晚,甚至喝完一杯咖啡之後,你就會忘記自己曾經做過的事情。

6. 如果你覺得一個使用個案情境 (Use-Case Scenario)「應該可行吧」,這可能會導致一個災難性失敗的發生。你不應該依賴直覺,應該是透過測試 (Test) 和驗證 (Verify) 來判斷可行性。

7. 如果程式開發人員沒有長期致力於維護自己所開發的系統的經驗,那麼你應該抱持懷疑的態度來檢視這個人。資訊人員有 80% 的血水、汗水和淚水都是在軟體正式發佈後才真正湧現的,而此時他們也開始長智慧了。

  • 享受工作吧

8. 如果你做的是正確的事 ── 你自己會知道那個情境真是順到不行。

9. 你的客戶並不笨,只是對你取巧的做法不以為然。

10. 工作中遭遇任何疑問,都應該和你的組員 / 利害關係人互動交流。

11. 製做核對表 / 工作清單 (Checklists) 能夠幫助你工作更順利。

12. 要做到「享受工作」這個目標,是必須有目的性 / 做特別付出的。

13. 對於系統無預警的故障,還是會讓我不安,儘管做了系統監控 (Monitor),日誌 (Log) 的設定與保存,警告 (Alert) 的提醒與通知,仍然無法避免誤判與鈍化的狀況,對此,你還是應該讓系統維持對故障 / 警報的敏感度。

14. 資訊人員所負責的工作是非常複雜的,所以,你可以按照事情的輕重緩急來做管理與安排。老闆付我們薪水就是要我們來解決難題的,所以,做就對了!

(資料來源:siavoshb ; 圖片來源:Ezutux0racer