顯示具有 Design Patterns 標籤的文章。 顯示所有文章
顯示具有 Design Patterns 標籤的文章。 顯示所有文章

我的爛Code重構之路

在《軟體構築美學 pdf p.16 》提到軟體開發中鐵三角的概念。

而作者則提出另一個水平的觀點：

軟體開發的天平
天平左邊放的是（預估的）時程和資源，代表我們希望盡量減少的部分。
天平右邊放的是品質和功能，我們希望這部分愈多愈好。
重點在於天平必須隨時保持平衡，如果要增加一項功能，就必須增加適量的時間和資源來維持平衡。
如果經費不足，你就得做出選擇：要犧牲品質還是功能。
閱讀更多 »
標籤： , 張貼者： 於 1 意見

從EverNote的求職需求看未來開發人員應有的技能

EverNote的求職需求

此篇靈感來自Johnny.Net的Plurk，Johnny.NET貼了一個EverNote的求職連結，從中我們可以看到一些趨勢，我簡單做個整理，各位開發者做個Check List，其中你擁有了幾項技能。

EverNote技能需求

EverNote 職位職責

EverNote技能需求職責

這裡的關鍵點有幾個：

  1. HTML5/CSS/JavaScript的應用程式

    這裡談的是應用程式，不單只是網站網頁，我會強調在application app。

  2. prototype(原型)，我猜這是指JavaScript裡的原型，通常使用到prototype都已經是JavaScript裡的物件導向(OOP)。以前JavaScript可以隨便寫寫，能動就好，現在連JavaScript都開始走物件導向(OOP)。

EverNote 技能最低需求

EverNote技能最低需求

這裡的關鍵點有幾個：

閱讀更多 »
標籤： , , , , , , , 張貼者： 於 3 意見

重構 - List of Sound Bites(原音重現)

以下節錄《重構-改善即有的設計》一書最後一篇的重點清單，此章我認為是《重構-改善即有的設計》此書中最重要的一章，它提出讓程式裡不應該有的壞味道。
p.7
When you find you have to add a feature to a program, and the program’s code is no structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
如果你發現自己需要為或式添加一個特性，而程式碼結構使你無法很方便地那麼做，那就先重構那個程式，使特性的添加比較容易進行，然後再添加特性。
p.8
Before you start refactoring, check that you have a solid suite of tests. These must be self-checking.
重構前，先檢查自己是否有一套可靠的測試機制。這些測試必須有自我檢驗能力。
p.13
Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug.
重構技術係以微小的步伐修改程式。如果你犯下錯誤，很容易便可發現它。
p.15
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
任何一個傻瓜都能寫出電腦可以理解的程式碼。唯有寫出人類容易理解的程式碼，才是優秀的程式員。
p.53
Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior of the software.
重構 (名詞)：對軟體內部結樣的一種調整，目的是在不改變「軟體之可察行為」前提下，提高其可理解性，降低其修改成本。
p.54
Refactor (verb): to restructure software by applying a series of refactorings without changing the observable behavior of the software.
重構 (重詞)：使用一系列重構準則（手法），在不改變「軟體之可察行為」前提下，調整其結構。
p.58
Three strikes and you refactor.
事不過三，三則重構。
p.65
Don’t publish interfaces prematurely. Modify your code ownership policies to smooth refactoring.
不要過早發佈介面。請修改你的程式碼擁有權政策，使重構更順暢。
p.88
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
當你感覺需要撰寫註釋，請先嘗試重構，試著讓所有註釋都變得多餘。
p.90
Make sure all tests are fully automatic and that they check their own results.
確保所有測試都完全自動化，讓它們檢查自己的測試結果。
p.90
A suite of tests is a powerful bug detector that decapitates the time it takes to find bugs.
一整組測試就是一個強大的臭蟲偵測器，能夠大大縮減搜尋臭蟲所需的時間。
p.94
Run your tests frequently. Localize tests whenever you compile – every test at least every day.
頻繁地執行測試。每次編譯請把測試也考慮進去 – 每天至少執行每個測試一次。
p.97
When you get a bug report, start by writing a unit test that exposes the bug.
每檔你接獲臭蟲提報，請先撰寫一個單元測試來揭發這隻臭蟲。
p.98
It is better to write and run incomplete tests than not to run complete tests.
編寫未臻完善的測試並實際執行，好過對完美測試的無盡等待。
p.99
Think of the boundary conditions under which things might go wrong and concentrate your tests there.
考慮可能出錯的邊界條件，把測試火力集中在那兒。
p.100
Don’t forget to test the exceptions are raised when things are expected to go wrong.
當事情被大家認為應該會出錯時，別忘了檢查彼時是否有異常被如期拋出。
p.101
Don’t let the fear that testing can’t catch all bugs stop you from writing the tests that will catch most bugs.
不要因為「測試無法捕捉所有臭蟲」，就不撰寫測試碼，因為測試的確可以捕捉到大多數臭蟲。
我個人是對p.88這一條有些意見。但事後想想，他的意思應該是讓程式自我解釋，不過這有很大的難度。相反的，在一些教科書或實作上，我們希望註解是越清楚越好。
標籤： , 張貼者： 於 0 意見

重構 - Refactoring Lists

如果各位有接觸物件導向程式設計(OOP)，有幾本書大概很難不買，「重構-改善既有程式的設計」、「Refactoring - Improving the Design of Existing Code」，侯捷大師還很用心提供了前六章的免費PDF電子檔。

原始下載點：refactoring-ch1-ch6.pdf
備份下載點：refactoring-ch1-ch6.pdf

以下只是書本首頁有個「重構列表, Refactoring Lists」，為查詢方便，記錄一下。
  1. Add Parameter ( 添加參數 )
  2. Change Bidirectional Association to Unidirectional ( 將雙向關聯改為單向 )
  3. Change Reference to Value ( 將引用物件改為實值物件 )
  4. Change Unidirectional Association to Bidirectional ( 將單向關聯改為雙向 )
  5. Change Value to Reference ( 將實值物件改為引用物件 )
  6. Collapse Hierarchy ( 摺疊繼承體系 )
  7. Consolidate Conditional Expression ( 合併條件式 )
  8. Consolidate Duplicate Conditional Fragments ( 合併重複的條件片段 )
  9. Convert Procedural Design to Objects ( 將程序式設計轉化為物件設計 )
  10. Decompose Conditional ( 分解條件式 )
  11. Duplicate Observed Data ( 複製「被監視資料」 )
  12. Encapsulate Collection ( 封裝群集 )
  13. Encapsulate Downcast ( 封裝「向下轉型」動作 )
  14. Encapsulate Field ( 封裝欄位 )
  15. Extract Class ( 提煉類別 )
  16. Extract Hierarchy ( 提煉繼承體系 )
  17. Extract Interface ( 提煉介面 )
  18. Extract Method ( 提煉方法 )
  19. Extract Subclass ( 提煉子類別)
  20. Extract Superclass ( 提煉超類別 )
  21. From Template Method ( 塑造模板函式 )
  22. Hide Delegate ( 隱藏「委託關係」 )
  23. Hide Method ( 隱藏某個函式 )
  24. Inline Class ( 將類別內聯化 )
  25. Inline Method ( 將函式內聯化 )
  26. Inline Temp ( 將暫時變數內聯化 )
  27. Introduce Assertion ( 引入斷言 )
  28. Introduce Explaining Variable ( 引入解釋性變數 )
  29. Introduce Foreign Method ( 引入外加函式 )
  30. Introduce Local Extension ( 引入區域性擴展 )
  31. Introduce Null Object ( 引入 Null 物件 )
  32. Introduce Parameter Object ( 引入參數物件 )
  33. Move Field ( 搬移欄位 )
  34. Move Method ( 搬移方法 )
  35. Parameterize Method ( 令函式攜帶參數 )
  36. Preserve Whole Object ( 保持物件完整 )
  37. Pull Up Constructor Body ( 建構式本體上移 )
  38. Pull Up Field ( 欄位上移 ) 
  39. Pull Up Method ( 函式上移 )
  40. Push Down Field ( 欄位下移 )
  41. Push Down Method ( 函式下移 )
  42. Remove Assignments to Parameters ( 移除對參數的賦值動作 )
  43. Remove Control Flag ( 移除控制旗標 )
  44. Remove Middle Man ( 移除中間人 )
  45. Remove Parameter ( 移除參數 )
  46. Remove Setting Method ( 移除設值函式 )
  47. Rename Method ( 重新命名函式 )
  48. Replace Array with Object ( 以物件取代陣列 )
  49. Replace Conditional with Polymorphism ( 以多型取代條件式 )
  50. Replace Constructor with Factory Method ( 以工廠函式取代建構式 )
  51. Replace Data Value with Object ( 以物件取代資料值 )
  52. Replace Delegation with Inheritance ( 以繼承取代委託 )
  53. Replace Error Code with Exception ( 以異常取代錯誤碼 )
  54. Replace Exception with Test ( 以測試取代異常 )
  55. Replace Inheritance with Delegation ( 以委託取代繼承 )
  56. Replace Magic Number with Symbolic Constant ( 以字面常數取代魔術數字 )
  57. Replace Method with Method Object ( 以函式物件取代函式 )
  58. Replace Nested Conditional with Guard Clauses ( 以衛述句取代巢狀條件式 )
  59. Replace Parameter with Explicit Methods ( 以明確函式取代參數 )
  60. Replace Parameter with Method ( 以函式取代參數 )
  61. Replace Record with Data Class ( 以資料類別取代記錄 )
  62. Replace Subclass with Fields ( 以欄位取代子類別 )
  63. Replace Temp with Query ( 以查詢取代暫時變數 )
  64. Replace Type Code with Class ( 以類別取代型別代碼 )
  65. Replace Type Code with State/Strategy ( 以State/Strategy 取代型別代碼 )
  66. Replace Type Code with Subclasses ( 以子類別取代型別代碼 )
  67. Self Encapsulate Field ( 自我封裝欄位 )
  68. Separate Domain from Presentation ( 將領域和表述/顯示分離 )
  69. Separate Query from Modifier ( 將查詢函式和修改函式分離 )
  70. Split Temporaty Variable ( 剖解暫時變數 )
  71. Substitute Algorithm ( 替換你的演算法 )
  72. Tease Apart Inheritance ( 梳理並分解繼承體系 )

希望未來能有機會，慢慢為每個項目加上Link，並說明我碰到的情況，期許自己更上一層樓。

加油！
標籤： , 張貼者： 於 0 意見
訂閱： 文章 (Atom)