I'm CaLendarW Blog

作為一個架構師，主要任務是提供了初部結構和安排不段增長和隨著時間而改變的軟件系統，而且幾乎總是在你和利益相關者沒有預見下重做，或者和其他系統溝通。儘管我們是所謂的架構師，我們由建築和工程方面借用了許多隱喻，但偉大的軟件不是建造，而係成長出來的。

唯一最大既避免軟件失敗係軟件規模;由大型系統開始設計幾乎沒有任何好處。然而，在某個時候我們都將受到誘惑而這樣做。除了作為容易附帶的複雜性和慣性，設計大型系統的前期意味著更大的項目，這些項目更有可能失敗，更可能是無法測試，更可能是脆弱的，更可能有不必要的和不使用的部分，更可能是昂貴的，而且更有可能產生不利因素。

因此要抗拒試圖設計一個大型完整的系統，無論是多麼誘人，以“達到或超過”已知的要求和期望的特性。已經是一個宏大的目標，但不一定是一個大的設計。令你同你的系統學習適應環境及不可避免的改變。

如何做到這一點？最佳的途徑係從一開始確保軟件系統可以成長和適應不斷發展。誘導系統成長代表從一個較小的系統運行，做一部分架構既工作 – 做最簡單而最有可能完成的部份。這初生的的系統將有很多可取的性能和能教育我們了解更多大型系統的架構，或者更糟的一堆架構文件。你更有可能參與了其實現方法。而細小的介面將可更輕鬆地進行測試，因此不容易耦合。這只需要一個較小的團隊，間接降低協調項目的成本。而且其特性將會更容易被觀察，更輕鬆地部署。它會教你和你的團隊在最早的時刻知道什麼做到和什麼做不到。它會告訴你的系統不會容易發展、有可能是堅固、或者係脆弱、又或者有可能被破解。也許最重要的是可以從一開始給予利益相關者一些理解和確實的情況，使他們能夠為整體設計成長。

設計最小的系統，您可以幫助實現它，並讓它朝著宏偉構想。雖然這可能會覺得自己放棄了控制，甚至推卸的責任，最終您的利益相關者將會向你表示感謝。不要混淆循序漸進的辦法與不理要求，可怕的逐步，或建設一個將會扔掉的系統。

##############################################

As an architect you are tasked with providing the initial structure and arrangement of software systems that will grow and change over time, will have be to reworked, will have to talk to other systems, and almost always in ways you and your stakeholders did not foresee. Even though we are called architects, and we borrow many metaphors from building and engineering, great software is not built, it is grown.

The single biggest predictor of software failure is size; on reflection there’s almost no benefit to be had from starting with a large system design. Yet at some point we will all be tempted to do exactly that. As well as being prone to incidental complexity and inertia, designing large systems upfront means larger projects, which are more likely to fail, more likely to be un-testable, more likely to be fragile, more likely to have unneeded and unused parts, more likely to be expensive, and more likely to have a negative political dimension.

Therefore resist trying to design a large complete system to “meet or exceed” the known requirements and desired properties, no matter how tempting that might be. Have a grand vision, but not a grand design. Let you and your system learn to adapt as the situation and requirements inevitably change.

How to do this? The best way to ensure a software system can evolve and adapt is to evolve and adapt it from the very outset. Inducing a system to evolve means starting with a small running system, a working subset of the intended architecture – the simplest thing that could possibly work. This nascent system will have many desirable properties and can teach us much about the architecture that a large system, or worse, a collection of architectural documents never can. You are more likely to have been involved in its implementation. Its lack of surface area will be easier to test and therefore less prone to coupling. It will require a smaller team, which will reduce the cost of coordinating the project. Its properties will be easier to observe. It will be easier to deploy. It will teach you and your team at the earliest possible moment what does and does not work. It will tell you where the system will not evolve easily, where it is likely to crystallize, where it is fragile. Where it might break. Perhaps most important, it will be comprehensible and tangible to its stakeholders from the beginning, allowing them to grow into the overall design as well.

Design the smallest system you can, help deliver it, and let it evolve towards the grand vision. Although this might feel like giving up control, or even shirking your responsibilities, ultimately your stakeholders will thank you for it. Do not confuse an evolutionary approach with throwing requirements out, the dreaded phasing, or building one to throw away.

by Bill de hÓra (edited by RMH Sept. 26, 2008) in 97 Things Every Software Architect Should Know

This work is licensed under a Creative Commons Attribution 3

前日子維 send 左個 post 比我, 內容幾好, 都係講緊 software improvement – 8 ways to be a better programmer in 6 minutes

1. 用大 Size 既字
當用左大 Size 既字後, 因為睇既野少左, 所以你就要開始諗點寫短一些既 method, 從而減低軟件既複雜性及增加可讀性

2. 將 hard code 既 string 變得討厭
這樣可以鼓勵你寫少一點 hard coding, 同埋指示你那裡有 hard coding

Visual Studio Options

3. 學習一下關鍵字 (keyword)
每隻 language 既關鍵字都有佢既用途, 請認識一下 language 不同關鍵字既用處. 以我為例, 呢兩年都開始學多左用不同既關鍵字, 例如 (is, as, ?? opertor 等), 識多一點更會簡化自己既 coding, 亦對自己既寫作有幫助.

以下係原文提供既幾個 .net languages 參考: C#, VB.net, F#.

4. 增加 1% 代碼覆蓋度
除左用自動化單完測試外, 進一步測驗一些內容深入難明或易錯既地方. 增加 1% 覆蓋度對代碼更有幫助

5. 閱讀 Open Source Project
學習一下 Open Source 既代碼, 對自己會有幫助. 近年都開始睇緊 NHibernate, Rhino-Tools 等既 Source Code, 當然係有些難度, 不過真係 improve 到好多方面既 skill, 例如學下人地 d Test Case 點寫, Inheritance 既 Test Case 點寫, 人地用咩 keyword 去處理事件, 同埋人地點設計等等.

亦可以參考原文建議既 Hanselman’s Weekly Source Code series.

6. 用代碼分析軟件進行分析
這個可減少代碼既複雜性.
原文有幾個 Tools:  fxcop, StyleCop, clone detective, ndepend, 或者 code metrics feature of VS 2008

7. 找一個最醜既 method 進行重構
重構一個不唔清晰既 method 可以提升到軟件既架構, 可讀性, 重用性等多個方面

8. Stop Reading, Start Writing
學以致用才是最好既學習模式, 最好由最基本既寫起, 原文建議寫 Complier. 另一方面, 我見過既好多人都有個好重要既問題, 就係佢地從來都無 Start Reading, 有些連學校教既野都唔會去用, 寫出黎既野完全難以重用!! 請記住, 係 Stop Reading 之前係有個 Start Reading 的, 如果你無一個清楚既概念, 無 Start Reading 既話, 就好難會學得好!!

有時工程師會因為想將自己既履歷表寫好一點, 而推薦用一些未必係最善長或者最好既科技同方法去解決問題, 這些決定往往會影響成果.

其實, 最好既工作前路係由一班因為你為計劃作出了最好既決定而滿意既顧客為你建立的. 良好既信譽會比起你用最好既科技或方法帶來更大既好處. 在重要或者緊急既時間, 最新既科技永遠不應該放進客人的計劃內.

你要記住你被委託的職責, 作為架構師, 你應忠誠於公司及避免所有有衝突既興趣. 除非計劃有足夠時間及機會, 才可滿足你工作既需求. 如果你為計劃內應用最佳既建議而不使用未善長最新既科技或方法, 所有人都會因為你用最適當既科技多而感快樂.

當然, 有時新既科技往往太動人而難以抵抗, 甚至不適用於現在既情況. 有最好既解決方法, 計劃才有開心既團隊, 開心既客人. 這會給予足夠既時間來深入現有既科技, 你或者可以用自己既時間學習新既科技. 與其用不熟識既科技在唔夠時間既環境下完成計劃, 不如用熟識既科技來處理當前既問題, 再用空閒既時間去上堂, 又或者陪下屋企人吧.

無論如何, 將顧客放得比自已短期目標前是不會錯的.

##############################################

As engineers we sometimes recommend technologies, methodologies and approaches for solving problems because deep down we want to have these on our resume and not because they are the best solution for the problem. Such decisions very rarely result in happy outcomes.

The best thing for your career is a long string of happy customers eager to recommend you because you did the right thing by them and for the project. This goodwill will serve you orders of magnitude better than the latest shiny object in the latest shiny language or the latest shiny paradigm. While it is important, even critical, to stay abreast of the latest trends and technologies this should never happen at the cost of the customer. It’s important to remember that you have a fiduciary duty. As an architect you have been entrusted with the well-being of your organization and its expected that you will avoid all conflicts of interest and give the organization your undivided loyalty. If the project isn’t cutting edge or challenging enough for your current career needs then find one that is.

If you can’t do that and you are forced to be in such a project, then you and everyone else will be happier using the right technology for the customer rather than for your resume. It’s often difficult to resist utilizing a solution that is new and cool, even when it’s inappropriate for the current situation.

With the right solution, the project will have a happier team, a happier customer and overall far less stress. This will often give you time to go deeper into the existing older technology or to learn the new stuff on your own time. Or to go take that painting class you always wanted to do. Your family will love you for it, too – they’ll notice the difference when you get home.

Overall always put the customer’s long-term needs ahead of your own short term needs and you won’t go wrong.

By Nitin Borwankar in 97 Things Every Software Architect Should Know

This work is licensed under a Creative Commons Attribution 3