其他

 可理解性: 為什麼幾十萬字的小說看一遍我們就可以理解, 而幾千行code卻要一讀再讀? --Objects are principally about people and their mental models, not polymorphism, coupling and cohesion代碼難以理解是軟體行業的痼疾. 眾多方法和方法論致力於解決這個問題, 不管主觀還是客觀. 造成理解困難的原因有很多, 我們今天討論其中一種: 商務程序被分解在代碼中, 支離破碎.

一、現狀軟體越來越龐大，細節越來越多---->難以改錯，改進開發週期越來越長---->浪費金錢、生命二、原因生產工具與任務之間的差距太大：要砍伐整片森林，手裡只有斧子生產資料與產品之間的差距太大：要蔥油鯉魚，手裡只有魚籽蔥籽要建立一個金融系統，手裡只有C++Java編譯器，UML“建模”工具要建立一個化學反應類比系統，手裡還是只有C++Java編譯器，UML“建模”工具三、其它領域的範例要創作一首曲子，只需寫出它的五線譜，你幾乎不可能用自然語言來描述要證明一個數學定理，只需用數學符號

Q: 為什麼通過單元測試發現的 Bug 很少 ?A: 單元測試不是用來發現 Bug 的, 而是用來預防 Bug 的. 如果採用 TDD, 測試案例完成之時, 產品代碼尚未編寫, Bug更無從談起. Q: 那是否寫單元測試就能提高代碼品質了 ?A: 關於這一點, 似乎有人不這麼看, <<TDD Opinion: Quality Is a Function of Thought and Reflection, Not Bug Prevention>>.不錯,

模式名稱Navigator/導航者, 一種通訊軟體報文處理模式意圖封裝報文資料複雜的內部結構, 通過提供有業務含義的定址操作來避免危險的指標運算, 以減少重複和出錯的可能, 並提供更清晰的業務意義動機在網路通訊軟體的開發中, 為了傳輸效率或完整性的考慮, 通常在應用程式層協議的定義中, 一次可以發送多個單位的淨荷資料, 其具體數量可用報文頭中的某個欄位來描述. 另外一些時候報文體的長度是不定的, 通常也用報文頭中的某個欄位來表示實際的報文多長.而此類軟體通常以C語言開發完成.

Knowing all details at the beginning is considered impossible, or not necessary, so BDUF (Big Design Up Front) is considered harmful.It's usually true, but in some cases, we do need to know details as more as possible. Samples include bug fixing

人類社會能進步，就是因為它學會了既要叛逆也要服從，發現了在漫長歲月裡平衡兩種品性的社會機制 --斯莫林, 物理學的困惑模式名稱基準模式意圖通過從整個團隊都同意的一組原則和實踐開始,避免"強加給團隊既有方案"帶來的負面問題, 包括片面的理解機械的遵守帶來的爭執等.動機開發過程中經常有一些關於實踐紀律的爭論, 比如修複失敗的構建是否是優先順序最高的事情, 比如是否嚴格遵守WIP Limits等. 一邊是諸如XP, Kanban各類實踐的紀律性,

Code is cheap, show me the talk. -- from 力岩.模式名稱CoC, Context over Code意圖通過講解背景問題和曆史, 而不是目前的方案, 使新人(新換入的pair)更快速和透徹的理解目前的代碼動機當新人加入項目開始Pair, 或者交換Pair後, 留守Feature的人要負責向新Pair講解目前的設計和代碼. 而一個壞味道是, 留守的人往往急於開始編碼, 草草帶著新人過一遍代碼就開始新任務了.

The ProblemsTwo problems:Even there're already tons of articles and books talking about the meeting efficiency and effectiveness, but "too many meetings", "meeting takes too long" are still the most popular items in retrospective meetings.People

效能差是一種美德ReSharper已經成為.Net開發必備工具. 其貼心的功能和快速鍵設計讓coding過程可以行雲流水般隨心而動. 可最近在客戶這邊寫代碼時卻總是磕磕絆絆, 只因ReSharper變得奇慢無比, 之前從來沒感覺ReSharper這麼慢. 原因很簡單: 類太大了. 一個.cs檔案普遍在4000~5000行之間, 而partial class被大量使用, 通常一個完整的class大約橫跨3個上述規模的.cs檔案(據客戶開發人員介紹說也是因為太大才用的partial class).

Estimation is the most disputed practice in software development. The reasons include:It's difficult. We can't know every atom in the universe.It's easy to be out of date. Things changed frequently.But the real reason is some kind of human being's

模式名稱SoS, Story over Solution意圖當改變相對複雜時, 通過一個故事或情境引導團隊參與方案的推導過程, 而不是枯燥的說應該這麼做, 以使團隊對複雜的改變更加支援.動機當一種改變看起來與直覺不符, 通常會遇到一些抵制, 典型的反對意見比如”沒必要”, “自找麻煩”, “現在這樣已經足夠了”. 而這些反對意見有時是源於對新改變背後的原理不夠瞭解. 此時如果強制推行, 在實際操作中也會遭到陰奉陽違的抵制, 使效果不夠理想.

萬物有始皆有終. 我們的邏輯鏈條起源於為什麼要持續學習, 然後是學習什麼, 怎麼證明學到了, 最後是為什麼只學一門不夠為什麼要持續學習 -- 知識通脹時代來臨大家大部分都是在職的, 平時應該會存錢. 存錢最害怕什麼? 對, 通貨膨脹. 一旦央行開動印鈔機, 並大量放貸製造流動性, 我們辛苦多年的積蓄就會被迅速稀釋甚至蒸發. 然而現在有一樣東西, 正以前所未有的速度被製造出來, 這就是知識. 並且其流動性在互連網的推動下簡直泛濫成災. 換句話講, 知識正在通貨膨脹. 過去各行各業積攢的各種知識,

 估算是軟體開發中還沒有很好的解決的一個問題, 因此爭論也很多, 水平也參差不齊. 我無法給出更好的估算技術, 只是想拋出幾個問題和觀點 1. 單一職責和問題優先讓我們從幾個常見的問題開始: 估實際工作量(人天)還是相對大小?如果兩個類似的Story有一部分實現代碼是可以彼此複用的, 那麼它們的估算應該是一樣的還是不一樣的? 還是把複用的那部分拆出來單獨估?修複Bug的工作量要不要估算? 要不要算進每個迭代的"速度"裡?Team一起估還是找一個人來估?做了一段時間後,

客戶提到說我們也希望員工能提高自己, 可總是有人動力不足. 徐昊又講了一遍如何散布恐慌. 基本的論述如下:知識在加速貶值. 你花了幾年時間積累的知識, 現在學校都已經開始教了, 比如有的學校都開始講敏捷了, 作為軟體工程的課程內容. 換句話說, 一個畢業生在技能上已不輸一個工作幾年的人, 而起薪要低的多.事實上, 知識通脹時代已經來臨. 大家知道貨幣超發會引發通貨膨脹, 可現在每個行業每天都在產生大量的知識. 各種前所未有, 想都想不到的技能技巧技術海水般湧現出來, 並藉助互連網迅速傳播.

---專家系統給測試和測試人員帶來了不同的挑戰.我們日常接觸到的軟體大多為通用軟體或者公司專屬應用程式, 使用起來比較簡單, 易於理解. 與之對應的,  有一類軟體我們稱之為專家系統, 它們協助某個領域的專家來做出判斷和決策. 比如地質監測, 天氣預報, 還有我們經常在電影裡看到的科學家使用的各種類比軟體: 龍捲風災難類比, 變態教授的分子化學和新藥品實驗等.直觀的感覺, 這類軟體已經與我們日常使用的軟體不同. 具體一點, 我們從軟體測試的角度來來理解一下專家系統帶給我們的不同於通用軟體的挑戰:

Bounded Context人們總是試圖建立一個統一的模型, 某種一致的描述. 物理定律表現出來的一致性震撼人心, 是相對成功的例子. 絕大多數人都相信自然界存在一個終極的理論來描述宇宙的本質.  物理學的曆史也就是不斷趨近這個終極理論的曆史, 不斷有各種彼此獨立彼此矛盾的理論被新的更一致的理論所統一.  比如目前前沿物理學家正在致力於統一自然界的四種力: 強力, 弱力, 電磁力, 引力. 目前已經有理論可以統一前三種, 只剩引力游離在外. 受此啟發,

所謂批量code review是指一段時間, 通常是一個迭代或幾周之後, 團隊坐在一起集中code review. 這種方式有幾個問題:有一些通過code review能發現的bug因此而潛伏下來, 有可能被發布, 就算運氣好發布前通過各種測試被發現, 依然帶來一些overhead像發bug, 定位問題, 修bug等額外的工作.有一些通過code review能共用出來的知識因此而很長時間之後才被共用, 而在此期間, 團隊其他人由於不瞭解這些知識, 有可能犯已經犯過的錯誤, 或走一些彎路,

See Also: AntiPattern: Batch Code ReviewCode review, specially daily code review, is considered a good practice. I've participated lots of code review meetings, and something concerns me. It's the low efficiency. Usually it takes longer time than

As a brainstorming method, the 5 Whys are hard to beat. This technique is inexpensive, easy to implement. Because it is so elementary in nature, it can be adapted quickly and applied to almost any problem. In software development, usually it will be

在我開發基於動態代理的輕量容器過程中，動態裝入外部的客戶自訂介面/類/組件功能是一個必要的組成部分。對於應該選擇用DLL還是BPL來作為自訂群組件的實現方式一直不能確定。在反覆的實驗過程中，發現了一些其中的技術細節，特別是在用字串類型作為參數或傳回值的情況下。凡是用DELPHI開發過DLL的，都知道DELPHI的DLL嚮導產生的程式碼中，在DLL Project