在眾多軟體相關的知識中，軟體工程絕對是很特別的乙個。
很多人很鄙視軟體工程，說：我一看到軟體工程的書就直接略過；與之相對應，很多人很推崇軟體工程，會花很大的心思去研究敏捷、cmmi等。
剛入職場的程式設計師大致上是討厭軟體工程的，因為這東西離自己的實踐有點遠，並且主要是新增束縛。
但既然更加複雜紛繁的歷史都可以總結出規律，軟體開發沒道理就總結不出可以遵循的規律。
也許真的事實是：並不是軟體工程沒有用，而實在是很多軟體工程的書籍理論飄的太高，落地上有困難。
軟體工程乙個很大的困境在於，它總是試圖以軟體整體為研究物件，但軟體的內部分野過多，不同種類的軟體間所適用的方法又充滿矛盾。
這最終就導致很多軟體工程理論往那裡落都有點困難。
而程式設計師或者專案經理這些現場的人往往是非常務實的，面對這種無法接地氣的東西，自然會猶豫和牴觸。
還是以前的那個觀點。
當乙個人乙個組織提倡一種方法時，不單要闡明方法自身，還要闡明方法自身的邊界。
cmmi，敏捷等等都不應該規避自己的有限性。
確實有無限適用於軟體的方法，但這種方**必須基於軟體的根本特質。
對此我們可以講：
從特質上來看，既然軟體是固化的思維，那就必然同時具備思維以及思維所承載之物之特質。
既然思維自身的特質是復合的，那麼作為固化思維的軟體，其特質必然也是復合的：
既有屬於所有軟體的共同特質，也有特屬於某類軟體，甚至同其他類軟體完全相反的獨有特質。
這是兩條完全不同的處理軟體工程的方法，都有前途。
要麼你基於思維的特質去演繹軟體工程，要麼你基於具體的場景去演繹，但要闡明限度。
最怕兩者都不靠，那就導致內部矛盾，成為一種軟體工程自身的困惑。
那軟體工程自身究竟有沒有一種有效的邊界？
如果把所有影響軟體的因素都涵蓋於軟體工程之內，那麼這事兒就變成無邊界的了，財務、公司運營、市場營銷全對軟體有影響，如果把他們都包含到軟體工程的概念內，
軟體工程就變成了四不像，什麼都是可也什麼都不是。
這點上可以向經濟學家取經，經濟學家研究經濟學的方法是：先假設某些因素不發生變動，進而觀察幾個特定因素的變化和關係。
我們可以先抽去商務因素、市場因素對軟體的影響，尋找本質規律，再把商務因素、市場因素的權變加回來，看看如何彎曲本質規律以適應現實。
好比我們畫圓的時候畫出的圓總是不理想的，但只要我們知道了圓的理想方程，我們就總可以畫出盡可能完美的圓。
從學習軟體工程的角度看，也許從《**大全》這書開始是個不錯的主意，這書裡即講軟體全體，又講軟體開發的細節，只要是寫過程式的人，大致都可以從中吸取養分。
個人感覺軟體工程在國內的乙個困境是名詞始終在不停的變換，但實際起作用的卻不多，最終導致剛對乙個絕望，就開始對新的乙個報以希望這樣周而復始的狀況。
這種狀況也許有其更深層次的原因，比如短期內市場、生存壓力等維度上的力量過於強大導致工程力量的長遠價值被漠視，進而使方**並不為解決現實問題而存在，而是為了證書而存在。
本質來看卻一定不是軟體工程毫無價值。
理想流 + 軟體 = 《完美軟體開發：方法與邏輯》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和邏輯推演本質，追求真理。
經典軟體工程對照現代軟體工程
本文 五級的目錄及簡單分析 一 初始級 二 可重複級 計畫及 跟進 合理化建議 會議 工餘 願者參加 所用工具軟體 網路版db軟體 如erp之用sql oracle 開源版db軟體，及從此基本點自行開發具有data mining knowledge management的軟體 要點是 的保質量 自生...
現代軟體工程 備份
自我介紹一下,我叫鄒欣,是微軟亞洲研究院 創新工程中心 首席研發主管 principal development manager 我 和同事們一起把研究成果轉化為商業軟體產品和服務。近期主要專注於垂直搜尋，企業搜尋，軟體開發工具和數字娛樂等領域。在工作之餘,我也寫書 移山之道，程式設計之美 寫部落格...
現代軟體工程的學習
構建之法現代軟體工程 這本書才開始學習，相對於大一緊張繁瑣的android studio來說，確實是很容易理解的一門課程，但是對於寫過千百行 這一要求，對於學生而言確實挺困難的，但是對於資深程式設計師和菜鳥來說，不同的基礎決定著學習的深入，在分析 設計以及測試中投入的時間是很重要的。構建這本書將書本...