今天在專案開發中，遇到乙個問題，在嘗試解決無果後，對解決問題的思維產生一番思考。記錄如下。
在我看來，解決乙個專案問題的思維能拆分成若干個環節，這些若干個環節彼此相互互斥，解決問題的過程被對映為一環環固化思維的串接。問題得到解決存在乙個最小思維量。當認知超過最小思維量時，就能推測、預判問題的變化。
思維量存在且不限於以下兩個屬性：思維複雜度和環節確定性。思維複雜度表示解決問題的可能性數量或方向多少。環節確定性指的是：互斥並且單一的指向下乙個思維環節。互斥和單一指向兩者缺一不可。當乙個環節在這個思維過程中與其它環節形成互斥，即表示這個思維環節是解決問題的有效組成成分；單一指向的作用是能促成思維導向同乙個結果：解決問題。乙個方向而不是多個方向，這大大的降低思維複雜度。
另一方面，每個思維環節的確定性大小會影響下乙個環節的確定性。如果乙個環節不確定是對是錯、正確程度未知，就會導致該環節的指向不再單一而是多個。所以，不高的環節確定性會造成較高的思維複雜度，這是不利於工程問題的順利解決的。
結論：基於上述認知，工程能力提高的過程其實就是增加思維環節確定性和數量的過程。
現代軟體工程裡的困惑
在眾多軟體相關的知識中，軟體工程絕對是很特別的乙個。很多人很鄙視軟體工程，說 我一看到軟體工程的書就直接略過 與之相對應，很多人很推崇軟體工程，會花很大的心思去研究敏捷 cmmi等。剛入職場的程式設計師大致上是討厭軟體工程的，因為這東西離自己的實踐有點遠，並且主要是新增束縛。但既然更加複雜紛繁的歷史...
Google 裡的軟體工程學
簡評 原文作者 fergus henderson 在 google 工作了 10 年以上，目前負責 google 的 text tospeech 工程小組。有很多書籍或文章會從 商業 管理 等非技術角度來講 google 是如何運作的，這篇文件則是從軟體工程學的角度來講 google 是如何運作的。...
論軟體工程需求的分類與獲取
摘要 在軟體工程的生命週期中，需求分析是很核心的一環，如果是自頂下上的設計，那麼它就是頂層的核心設計。軟體工程的過程中，不僅僅只有 編寫，明確需求，分析需求，是對產品目標的設計。當需求完整，準確，清晰，具體的時候，軟體的開發才可能事半功倍。那麼如何去獲取軟體需求，軟體需求又有哪些型別，這是我們要去 ...