在《no silver bullet》中，作者提到兩種軟體開發的困難：
1.本質性：軟體本身在概念（conceptual
）建構上存先天的困難；亦即如何從抽象性問題，發展出具體概念上的解決方案。
2.附屬性：將概念上的構思施行於電腦上，所遭遇到的困難。
而造成本質性困難的原因是：
1.複雜性（complexity
）：軟體要解決的問題，通常牽扯到計算步驟，這是一種人為、抽象化的智慧型活動，多半是複雜的。
2.隱匿性（invisibility
）：尚未完成的軟體是看不見的，即使利用圖示說明，也常無法充分呈現其結構，使得人們在溝通上面臨極大的困難。
3.配合性（conformity
）：在大型軟體環境中，各子系統的介面必須協同一致。由於時間和環境的演變，要維持這樣的一致性通常十分困難。
4.易變性（changeability
）：軟體所應用的環境常是由人群、法規、硬體裝置、應用領域等，各因素所匯集而成，而這些因素皆會快速變化。
在《big ball of mud》中，大泥球是指乙個隨意化的結構化系統，純粹**的堆積，會導致很多的錯誤和缺陷。
產生這種缺陷的原因是：
程式設計師在編寫程式的時候遇到問題後的解決方案往往是改動最小的，而不是最合適的。導致程式的結構發生問題，為日後程式崩潰埋下了隱患。其次，由於使用者需求的不斷改變，程式設計師在不斷修改程式的時候會將原有程式變得更為複雜，使程式變成乙個大泥球。因此，為了避免程式最後變成一堆混雜的**，應該在編碼前期盡可能的搭好整個框架，在修改**時也盡可能的考慮整體架構。
在《cathedral and the bazaar》中，有兩種模式的開發方式：
大教堂模式（the cathedral model）︰原始碼在本模式是公開的，但在軟體的每個版本開發過程是由乙個專屬的團隊所控管的。作者以gnu emacs
及gcc
這兩軟體為例。
市集模式（the bazaar model）︰原始碼在本模式也是公開的，不過卻是放在網際網路上供人檢視及開發。作者以linux
核心的創始者林納斯·托瓦茲帶領linux
核心的開發為例，亦引用fetchmail
的開發為例。
在我參與的結對專案中，乙個人編碼，乙個人檢查這種方式類似市集模式。但是在團隊專案中，我們的開發人員本來就不多，沒有辦法專門找人來做檢查。只能大家在移植**的過程中不斷修正錯誤。
在《worse is better》一文中提到：
普遍認為是好的方面：
1.簡單性：從前認為在實現和介面中，設計必須簡單。簡單性是設計中最重要的。
2.正確性：在所有可觀察的方面，設計都必須正確。正確的重要性亞於簡單性。
3.一致性：設計必須一致。但是退一步講設計只要不是過於不一致就好了。
4.完整性：設計要覆蓋很多種情況，但一旦阻礙了其他方面一定會先犧牲完整性。
而我在自己做專案的時候基本上也是根據這些原則做的，可能有時不會把所有原則的重要性排列的如此細緻。
讀完這些文章我認為軟體工程是大學生到公司程式設計師的乙個過渡，很多東西都是在乙個團隊做工程的時候才會遇到的問題。我從這門課中學到的不僅是在編寫**時應該注意的東西，還有在團隊專案中，大家合作時應該注意的東西。雖然很多程式設計師的能力完全可以在一段時間內自己做完乙個工程，但是很多人一起合作的時候，這種效率與正確性是乙個人完成不了的。
個人閱讀作業 2
專案 內容這個作業屬於哪個課程 2021春季軟體工程 羅傑 任健 這個作業的要求在 個人閱讀作業 2 我在這個課程的目標是 學習軟體工程基礎知識以及培養軟體開發能力和專案組織能力 這個作業在哪個具體方面幫助我實現目標 對軟體開發流程有基本的了解 學習用ci id進行專案的整合與部屬 p1 閱讀提問 ...
個人閱讀作業2
乙個學期的軟體工程課程即將結束，從一次個人作業，一次結對作業和兩個階段軟體的開發中，我學到了很多東西。個人作業讓我明白了程式設計師最需要具備的一項技能就是自學能力。從對語言的不熟悉，到能寫出乙個小型的程式，非常考驗我們的自學能力。結對作業重在讓我們有乙個團隊合作的意識，給接下來的團隊專案打下基礎。同...
個人閱讀作業
問題 1.對於高健壯性的 應該先斷言再進行錯誤處理 大全 p193。為什麼不直接用錯誤處理呢？先斷言再進行錯誤處理和直接進行錯誤處理的效果不是一樣的麼？2.完全填充分配到的所有記憶體，這樣可以讓你檢查到記憶體分配錯誤。完全填充已分配到的所有檔案和流，這樣可以讓你排查出檔案格式錯誤。大全 p206 什...