Joel Spolsky 有一個關于 軟件開發周期的階段 的帖子，該貼出乎意料地結束了我自己的觀察。在Joel看來，第一個階段是藝術（設計階段），第二個階段是工程（構建階段）第三個階段是科學（調試和測試階段）.
Joel的興趣是軟件管理和管理工具，但我對于開發工具有更多的興趣。一旦你認出了軟件開發的工程方面和科學方面的分水嶺，你就可以更好地理解開發方法的很多緊張對立，其中的一種對立導致了很多辯論。之所以產生這種不安，是因為基本的不變的不可褻瀆的（更別說神圣的圣潔的虔誠的）工程法則有時候和科學實踐是不一致的。
也就是說：抽象和模塊性是軟件工程的心和肺，法則1,2,3是“局部化關注點，也就是DRY，分離關注點，使關注點正交”。更簡單的說：使用抽象并且不要違反。通過使得一個關注點完全不注意（也就是說：參數化）另一個關注點，你可以最大自由地改變一個關注點而不影響另一個關注點。這是因為(allows for)局部化的原因，依次引發了獨立的開發和維護。訓練有素的開發者創建分層抽象，并且一絲不茍地遵循他們的邊界。
但是當開始調試時發生了什么呢？教條地（Dogmatically）遵循抽象邊界就像戴了一個眼罩；當一個bug第一次出現的時候，你根本不知道它是隱藏在哪個抽象里，還是在層與層的交互之間。另一個思考抽象盒子內部的通常的推論是 沖動地假設這個bug是別人的錯誤。（“一定是編譯器的錯!”） 我想起 Knuth 關于計算機科學的引用：
這樣的人非常擅長處理不同的法則應用到不同情況下的情形，他們是那些可以快速地改變抽象層次，可以同時觀察很多大的事物和小的細節的人。——引自 Hartmanis 的圖靈獎獲獎感言
我認為這里的描述更多的是在軟件開發的科學面或者也可以說是設計方面的——但不是工程方面的。
因為調試和測試是和觀察和理解一個現有的系統相關的，而不是構建或修改一個系統，我們自己構建的藩籬（譯注：指層次抽象）使得我們的工程原則變成了障礙。調試工具，集成開發環境，測試框架，等等都被一種需要違反抽象邊界的需求而賦予了特色。
結果，干凈和骯臟（就像 Mitch 叫他們的）開始撕咬混戰，他們爭斗的問題是：我們的軟件開發框架 對他們對 FIaI(NtMSHaG)LoE (ML) （譯注：實在不知道怎么翻譯）的堅持 是應該絕對嚴格呢，或是絕對寬松(Smalltalk)？ 我不知道通過 構建涵蓋這些不同開發模型的軟件框架，我們是否能夠做的更好。
=================================================================
原文：
Joel Spolsky has a post about the
phases of the software development cycle that's remarkably close to my own observations. In Joel's view, the first phase is
art (i.e., design phase); the second is
engineering (construction); and the third is
science (debugging and testing).
Joel's interest is in project management and management tools, but mine is more in development tools. Once you recognize the divide between the engineering and science aspects of software development, you can better understand one of the tensions in the approach to development, a tension which leads to plenty of heated debate. This tension comes about because the Fundamental Immutable and Inviolable (Not to Mention Sacred, Holy, and Good) Laws of Engineering are sometimes at odds with the practice of science.
To wit: abstraction and modularity are the heart and lungs of software engineering. Rules #1 , 2 and 3 are "Localize concerns, i.e.
, separate concerns and enforce their orthogonality." More simply: use abstractions and don't violate them. By making one concern completely oblivious to (i.e., parametric in) another, you maximize your freedom to change one without affecting the other. This allows for local reasoning which in turn leads to separable development and maintenance. Disciplined developers create layered abstractions and fastidiously respect their boundaries.
But what happens when you start debugging? Dogmatically adhering to abstraction boundaries is like wearing blinders; when a bug first arises, you never know which abstraction layer it's hiding in, or if it's in the interaction between layers. Another common consequence of thinking inside the abstraction box is impulsively assuming the bug is someone else's fault. ("The compiler must be broken!") I'm reminded of Knuth's quote about computer scientists:
Such people are especially good at dealing with situations where different rules apply in different cases; they are individuals who can rapidly change levels of abstraction, simultaneously seeing things "in the large" and "in the small."
-- quoted in Hartmanis's Turing Award lecture
I think this is describing more the science and perhaps also the design aspects--but not the engineering aspect--of software development.
Because debugging and testing are about observing and understanding an existing system, rather than constructing or modifying a system, the barriers we construct to enforce our engineering principles become obstacles. Debugging tools, IDE's, testing frameworks, etc. are all characterized by a need to violate abstraction boundaries.
As a result, the Cleans and Dirties (as Mitch calls them) fight tooth and nail about whether our software development frameworks should be absolutely strict in their adherence to the FIaI(NtMSHaG)LoE (ML) or absolutely lax (Smalltalk). I wonder if we couldn't do better by building software frameworks that were aware of these different modes of development.