軟體工程在工作中到底起多大作用？

12-30

本人今年6月cs畢業，年後面了三家公司，A上市公司，B小公司，C比B大點。
面B時，面試官竟問我MVC還可以和三層一起用？C公司讓直接上班，所以有幸看了他們的代碼，用的WebForm，項目除了大，說真的，我看不上。A等了一天通知也過了，便無疑問選擇了A，互聯網，細分行業里算行業前三。
看了代碼，簡直沒有規範可言，沒有文檔，耦合很大，業務邏輯到處有，命名各種首字母，要靠猜的，資料庫欄位也一樣，沒有文檔，猜欄位。
近兩天有新功能要做，想著以前就算了，新功能總該有個文檔吧，我們我們頭技術還是很高的，然而什麼都沒有，給幾個模塊，讓我做，然而原型圖和資料庫里的欄位都對不上，問過之後，原來資料庫完全建錯了。
不是嘲笑公司的技術，公司技術還是挺好的，在裡面我是最差的，但是我想說的是比較接近軟體工程的東西，編碼規範，設計，文檔，等等與技術無關的東西，因為舊代碼看起來真的要死。

在學校里想的工作後的項目都是先需求分析文檔總體設計等等流程走下來，各種抽象各種解耦，然而事實不是這樣的。
我想知道是個例，還是在不大的公司里普遍存在現象。軟體工程在行業里到底起到多大的作用。謝謝了。
-----------------------分分分-----------------------分分分----------------------
加班剛回來，單休的傷不起。在公司忙完後，拿出買的構建之法裝逼，經理看見了露出鄙夷。今天改的一個東西，看錶能猜出，預先是想把菜單做的靈活，然而現在的代碼竟是把菜單寫死了，竟然是在view里用直接調底層函數，而且參數寫的是固定的id 1。這給修改帶來了無限的麻煩，然而經理說寫死。是呀，如果寫死將是很簡單的，然而真的是愁了，自己竟然要寫醬的東西。
查了下公司貌似是沒有CMMI的相關信息的，雖說是細分行業前三，然而行業不是面像大眾的，去年初剛上的市，技術團隊，幾十個人，雖說比一般小公司大，然而大應該是談不上的。
相對於自己的水平，能進這家公司很滿意了，雖然代碼寫起來很難，慢慢開始吧，剛上班三周呢。
相關問題：
為什麼有些大公司技術弱爆了？ - 互聯網

先上一個圖：

(來源：山東智障農民撿泥土石塊建七層小樓令人佩服）

不講軟體工程的項目，就像上面的圖一樣。團隊成員搬磚很努力，樓的高度也有，但是你敢住么？它有上下水么？你在頂樓入廁，一衝水，會不會把整個樓給沖沒了？

那麼，為何有些不講軟體工程的公司也似乎混得風生水起呢？你把上面這個樓房放到一千年前，也是方圓幾百里的一朵奇芭，也能拿幾輪風投的。軟體行業的一些局部領域和建築業相比，就是建築業幾千年前的水平，大家剛剛從洞穴裡面爬出來，看到一個廣闊而變化快速的市場，也不知道寒冬什麼時候到來，那就各顯神通了，趕緊活下來再說！眾多競爭者只能在 {快，好，便宜} 這三者中選一到兩個優化。

在面試的時候，看不了源代碼，怎麼了解對方公司的軟體工程水平呢？可以問他們這10個問題：現代軟體工程講義源代碼管理問完之後，可以給他們的CTO，項目領導人打個分。

最後說一句：大家要招高質量員工的話，請從這些班級的學生中挑選：http://www.cnblogs.com/xinz/archive/2011/11/27/2265425.html

題主的這一問很好，真的，問到了根子上。軟體工程在實際工作中到底有沒有用？如果沒什麼用，我們為什麼要學呢？

This is a fundamental question，值得仔細掰一掰。

B小公司，C比B大點。面B時，面試官竟問我MVC還可以和三層一起用？

B 是三流公司吧，這位估計也是培訓班畢業，建議不要去。

軟體工程在工作中到底起多大作用？

以下我分兩個層面來說：對企業（及團隊），與對個人。

軟體工程對於企業的作用

軟體工程對不同的市場、不同的企業起到的作用與效果不同，所以要看你去的是哪一類企業。

一

對於世界一流的軟體企業，軟體科學、軟體工程的作用非常大，因為這些企業普遍具有崇尚科學、工程的價值觀和企業文化，邏輯是這樣的：沒有內部成熟的軟體工程管理，他們不可能超越幾乎所有對手，研發出如此複雜、如此精妙的世界一流、領先的技術和產品。

軟體工程對於一流頂尖企業有多重要？這裡我僅舉一例。你們知道在 Apple 負責軟體研發的大 V 是誰嗎？就是這位：

Craig Federighi (born May 27, 1969) is Apple"s senior vice president of Software Engineering. Federighi oversees the development of iOS, OS X
and Apple"s common operating system engineering teams. His teams are
responsible for delivering the software at the heart of Apple"s
products, including the user interface, applications and frameworks.

Wikipedia:Craig Federighi

Federighi 先生是 Apple 的軟體工程 SVP，作為核心人物領導 iOS、OS X 的研發以及 Apple 的公共操作系統工程團隊，並直接向 Tim Cook 彙報，可謂一人之下、萬人之上。軟體工程高級副總裁，我在國內很少聽說這樣的頭銜，CxO 倒是一大堆。這件小事例說明了什麼？Apple 為什麼要這樣命名呢？

這說明了軟體工程對於蘋果公司的極端重要性，軟體工程在蘋果所有產品研發中的顯赫地位與關鍵作用，這無疑是一家崇尚科學與工程、充斥著工程師文化的企業。

二

對於二三流企業（例如國內的江湖），尤其二流乙等以下的，軟體工程不重要，也完全不是決定性的主要因素，而是次要因素。道理是這樣的：

企業的第一要務當然是賺錢，這是企業生存的根本。然而賺錢，賺大錢，真的要靠很好、很成熟、很先進的管理與技術嗎？非也。

在不成熟的市場經濟中，大搞關係，善用潛規則和漏洞，善趟灰色地帶，精通各種貓膩和作弊手法，強化各種忽悠、炒作、洗腦式營銷，這些才是更為重要、不能忽視的、「敏捷」的賺錢術（而且合法），賺錢效應遠比靠提升企業自身的軟體工程管理與技術水平來得更為直接和有效。前者，能迅速為企業帶來短期可觀的贏利，屬於收入項；而後者，純粹是企業內部需要在一段較長時期內大力投入的開銷，屬於成本項；哪個更划算？不言自明。

軟體工程無用論在中國流行了也快 20-30 年了吧。先進的軟體工程對於國內多數企業來說，可能用處不大，這是由經濟規律以及軟體人（尤其老闆、管理者）的觀念、意識決定的。

軟體工程對於個人的作用

。。。

點評

我想知道是個例，還是在不大的公司里普遍存在現象。

相當普遍。

在中國，這種開發模式人稱「糙快猛」方法，雖然它與教科書上所講的一板一眼的正規軟體工程方法大相徑庭，看上去有點亂糟糟的，到處不合理、有漏洞，但確實簡單、有效啊，還能賺很多錢（只要不捅大簍子）。

在學校里想的工作後的項目都是先需求分析文檔總體設計等等流程走下來，各種抽象各種解耦，然而事實不是這樣的。

學校里教的軟體工程內容來自哪裡？主要還是來自美帝，來自美國的產業界、學術界的研究成果和成熟經驗。可是不要忘了，雖然都是江湖，但美帝的江湖與中國人的江湖是大不同的。美國人的許多做法、規則和規律在中國是行不通的，包括軟體工程的那些所謂最佳實踐。

我個人估計，我國的民用軟體工程水平大概至少還比美國落後 8-10 年以上的時間（我說的是平均水平）。當然，像 BAT、HZ 之類的一流企業中的核心產品研發部門，軟體工程的管理與技術還是相當領先的，可以說世界一流，你在那裡可以看到完全不同的狀況，這是事實的另一部分。

看了代碼，簡直沒有規範可言，沒有文檔，耦合很大，業務邏輯到處有，命名各種首字母，要靠猜的，資料庫欄位也一樣，沒有文檔，猜欄位。

近兩天有新功能要做，想著以前就算了，新功能總該有個文檔吧，我們我們頭技術還是很高的，然而什麼都沒有，給幾個模塊，讓我做，然而原型圖和資料庫里的欄位都對不上，問過之後，原來資料庫完全建錯了。

代碼規範、文檔規範，難道不是起碼的要求么？

如果是普遍現象，這類企業連 CMM 2 級也沒有，屬於 CMM 1 級（最爛級）吧，自然更談不上什麼軟體開發過程了。A 是上市企業大公司，估計 CMMI 3 級早過了，可 A 股裡面的爛公司還少么？

話說回來了，只要企業、部門還能持續贏利，人員基本穩定，內部研發管理差點、軟體工程落後點問題不大。許多這樣的二流企業撐個 10-20 年沒問題，作為碼農能進入上市企業、大公司也不容易，好好待著吧。

。。。

前幾天上軟體工程課程，軟工所的大Boss也談到了這個問題，為什麼現在這麼多互聯網公司的開發模式不按照軟體工程來？「其中根本原因還是我們現在軟體工程的教育方式不對，你們本科時候軟體工程的課多無聊，也就是背背書考考試，做其他課程的大作業時候你們根本想不起來用軟體工程的方法，大作業？在ddl前熬幾個夜做完的，誰還寫注釋啊，更別說文檔了。」大量這樣的畢業生到了工作單位，軟體工程的思想早看不上了……

老師舉了個他自己的栗子，十分讓我震驚。

他是90年代的大學生，電子專業，本科畢設好像是做一個測試晶元結構的程序。那個年代，都是那種體積巨大的那種機器。他和一個師兄都做這個題目，但是各自方法不同。他用軟體工程的方法，頭兩個月先花流程圖，寫文檔，給他導師急得……最後花兩個星期寫代碼，最後一次編譯通過，沒有任何bug。在驗收的時候，發現結果不對，直接就敢判斷是某兩根線接反了……果然是這樣！

他師兄呢，則是直接寫代碼，一個月寫完，兩個月調試，最終效果還是一樣的，不過這位仁兄就痛苦的多。

工程，任何時候都是取捨的問題，永遠沒有絕對的標準化，只是不斷地博弈，和人，和環境。

軟體工程亦是如此。書上說的東西，考試的東西，大多都是一些基本原則或者參考樣例，並不是標準答案。

一個大型軟體項目不是一天構成的，一個公司完整的工程流程也是如此。公司需要根據自己實際的資金能力，員工的技術水平技術背景做取捨。舉個例子，敏捷推崇結對編程，可是對於僅有幾名程序員卻工作量巨大的公司來說，結對編程只會讓公司死得很難看。

理想和現實總有不同，如果你能思考一下一家公司工程制度為什麼這個樣子，以後你除了做好自己的事情以外還能如何推動它改善，那會給你帶來很多收穫。

能在細分行業前三的企業做tech leader的人，你說他完全不知道軟工為何物，那是不可能的。

軟體工程試圖解決的問題，所有參與工業規模軟體開發的開發者都會遇到。你管理的代碼越多，功能越複雜，需求越不穩定，這些問題就越尖銳。

一個tech leader，哪怕他不是SE科班出身，也會在工作中使用各種軟體工程方法，一些方法可能來自於自身的總結，一方面來自於對網上書上的最佳實踐的學習。即使他滿嘴對軟體工程的不屑，最終他還是會或多或少地用軟體工程的方法去解決問題。

如果你系統學習過軟體工程，那麼你就會發現軟體工程解決問題的手段只有一種：我們姑且稱之為「物化開發者」。通過復用最佳實踐經驗，來把開發者變成生產線，實現大規模軟體開發的並行作業。就像雷老闆造手機一樣，高通的CPU，天馬的屏，他們自家的廣告UI，是由不同的人在不同的地方，同時生產的。

但是，實施最佳實踐也不是沒有成本的，其中最大的成本，就是你需要招募一批能夠理解並執行你的設計的開發者。這，並不如你們想像的那麼容易。特別是在這個互聯網大爆發，各家都在擴張需求的時期。

打個比方，你去拿5000塊招聘熟悉設計模式和軟工過程的開發者，那是不可能招到的，絕對不可能，除非你能給足夠吸引力的其他利益，否則連我這樣的都不會鳥你。

但是很多公司迫於成本的壓力，不得不招募一些廉價的勞動力來填格子，你給人家的那點錢，也只夠做這點事不是？

所以很多CTO加一幫格子工格局的公司，最初的代碼都精鍊而優雅，越往後越是一團糟。那是因為最早的代碼，framework和core functions是CTO(們)寫的，那就是他們那個水平的開發者的正常發揮，後面的功能都是格子工依葫蘆畫瓢附會上去的，所以各種坑也是正常發揮。

外行來強答。

做了半年的PM和PM，大概能認知到，計算機系統的建設，有一根金線在那放著，這根金線就是軟體工程的要求。所有的文檔，架構設計，敏捷方法論，都是為了達成這根金線而努力。

未能達成的部分，都會形成技術負債。

而軟體工程的受重視程度，跟技術負債的償還成本是成正比的。如果你的產品（軟體）生命周期很短，很多負債來不及還系統就不會再用了，那自然不會在乎這個償還成本。互聯網公司試錯型的發展邏輯，和一些非核心的業務功能，顯然就屬於這種情況。損失20%的質量節約80%的時間這種事，大家喜聞樂見。

但是百度的搜索排序，網易雲音樂的播放數據流這種核心功能，大家還是會妥妥進行完整的測試，充分的設計，留下足夠文檔的（搞不好還要發論文）。

軟體工程很重要

但個人感覺, 瀑布模型已經過時了

作為一個新手（不到半年）「Tech Lead」，我覺得我可以試試回答這個問題。

重要的事先說三遍：執行好的軟體工程實踐，需要花費大量的時間和金錢！

且聽我慢慢道來，這裡我們只說兩件事: 項目和人。

項目就是一個很複雜的事，涉及到: 時間，成本，周期，技術棧等等。我們是乙方，所以我們從不考慮成本的原因。然後先說說我們在軟體工程方面的實踐，我不敢說是國內最好的，但我相信至少是數一數二的。我們採用的是敏捷的工作流程，不過我相信那些對於嘗試過敏捷的人來說可能會有些反感。

先說說我們平時是怎麼做的：

每日站會。大概會有十幾分鐘的溝通時間，主要看有沒有遇到什麼問題。
結對編程。這意味著兩個人做一件事情。我們大概兩天會換一次Pair。
測試(TDD)與測試覆蓋率。大部分公司的代碼都是沒有測試覆蓋的，即使是BAT也是一樣的。如果我們花一天寫功能代碼，那麼至少還要有半天的時間要寫測試。
持續集成。你要經常提交你的代碼，還要有測試，還要和別人的代碼集成——而且是一天多次。
進行Code Review。每天大概會有三十分鐘到一小時的Code Review時間，而且是集體Review今天的代碼。
技術債。在我們的上個項目中，由於是新的開發框架。在後期，我們發現我們積累了一些技術債——主要是代碼質量問題。然後，我們一周抽時間來一起重構代碼。
每周兩次的技術Session。技術Session的主要目的是提高團隊成員的技術水平。

我就不對上面的優點展開了。現在，讓我們來算一下我們需要多付出多小的成本。

假設，我們現在有四個人，每個人獨立工作，可以在一周內完成。即一個人需要 8*5 小時的工作時間。

如果採用上面的工程會多出來多少的成本？

一天480分鐘 - 60分鐘Code Review - 15分鐘站會 - 平均的技術債修復時間 15分鐘 - Session花費30分鐘 = 360分鐘 = 6小時。

接著，再減去寫測試的時間，就只剩下 4 小時。

然後，因為是結對編程，所以每個人只有2小時的時間。。。

這就意味著，我們可能要四周才能完成這個項目！！對於一個短期的項目來說，這簡直是不可接受的。

但是需要注意的是：

採用敏捷就意味著，生產力是固定的、代碼質量較高、技術平均水平較高！

這一點特別適合大的、長期的項目。請再聽我慢慢道來：

因為採用結對編程，所以每個人對整個項目的代碼都很熟悉。這就意味著，不用擔心有人離職要影響項目的穩定性。當有一個人離職時，整個項目的產出率也不會因此而變化。並且新人會因為採用結對編程而上手更快。因此只要不是一起離職，即使一年後，這個項目的人都已經換了一遍，項目仍然可以繼續下去。

同樣的有Code Review、測試和結對編程的存在，組內的代碼質量會達到相當高的水平。雖然這在早期可能意義不大，但是請注意一點：Bug在越後期的修復成本越大。

除了結對編程，還有技術Session可以提高組內成員的技術水平。

。。。

最後，你會發現在這裡，取主要因素的是人以及流程。

歡迎關注我的微信公眾號：phodal

http://qm.qq.com/cgi-bin/qm/qr?k=Bhki8MNtEb9-vibPBo-6CbBqIROWI9mv (二維碼自動識別)

根據我的工作經歷，我覺得軟體開發產業的管理瓶頸不在於開發流程（當然開發流程確實能減少開發過程的很多問題），而是最基本的業務流程和成員激勵的問題。一個沒有什麼流程的團隊可以做出很棒的軟體，一個流程嚴格的團隊也可以一無所成。

軟體行業在我看來最大的管理弊病在於，很多時候是外行管理內行，一群對技術模模糊糊知道一些的管理層來管理具體做事的員工。對於走技術路線升上去的經理，情況稍好，然而期待他能懂組裡所有人做的事，也比較難。

外行管理內行的最大害處，在於不能以產出來衡量業績。比如，一個BUG，也許很難但是我一天就改好了，可能還不如一個不那麼難但是讓人覺得工作態度端正的人花幾天改好的人評價好。

所以，在軟體行業，你需要 -

1，態度端正，在公司少上外網不能打遊戲。

2，要做「大活」，要做領導看得見的活，對於難活能推則推。

3，及時向領導彙報成果，而且要適當誇大。

4，積极參与公司公共事務，比如年會什麼的。

5，訓練好PPT技能，經常做 knowledge share，英文 presentation 能力強。

為什麼要這樣，是因為這些東西領導看得見並且易於評價。真正的業務部分，是難以評價的。比如，你花幾個月時間改一個BUG而不向經理強調它有多麼難解決，也許經理不會認為它難而是認為你蠢。

更進一步問，為什麼公司不強調業務能力還能活的好好的？因為軟體開發和維護過程中，真正的難題不會超過其中的 10%，大部分人從事的工作都是區分不了業績的，至少是很難區分業務水平的。認為軟體行業是智力密集型行業的說法正確，然而認為軟體行業智力越高會混得越好，則是錯誤的。

軟體構建是需要方法的。比如說 scrum, refactor 都是一些提高軟體質量的概念。但是「軟體工程」是一個有很大誤導性的概念。因為軟體和傳統的工程有很大不同。

時間跨度不同，單位時間跨度里構建出來的複雜度也不同。拿航空發動機來比較，航空發動機確實非常複雜，但是以航空發動機積累的時間來看，在單位時間裡航空發動機複雜度的增長沒有一個軟體系統快。

類似的，單位投資對應的複雜度也不同。傳統工程一般是投資封頂。就算工程師能想到一些複雜的點子，投資者也不會讓他開始去做。就是說不管能不能做出來，連啟動資金都沒有。而軟體系統是複雜度封頂。只要程序員能想到，不管最後是不是預算超支或者延期，總有啟動資金支持你去做。

所以你的第一課應該是停止用「軟體工程」這個名字來思考。

什麼是軟體工程? wiki之Software engineering, 然後再看一下什麼是Engineering.

以上是上下文.

所以說, 如果你說軟體工程是你大學或者藍翔教的課, 確實不重要, 而如果你認同wiki定義的enginnering以及software engineering, 那肯定是重要的. 就好比年輕人經常問的, 演算法在工作中有啥重要的?當然重要了! 這些都是所謂的principle以及building block. 你必須要有一個工具箱, 裡面有鎚子, 釘子, 夾子等等, 你幹活的時候更要知道拿什麼工具處理什麼事情.

通俗的例子: 彈吉他, 如果你是一個好的吉他手, 你可以不用彈200, 可是你要有彈200的能力.

好的吉他手: engineer

壞的吉他手: code monkey

冒著要被 @曹政急的事實, 以及以後在新加坡也不能蹭上飯的風險, 我還是理智的寫下了一些東西.

曹老師說的是現實, 可是他只說了一半, 我就補充一下.

首先"work is everything, 等你做老闆的那天你就明白了", indeed, 不需要做到老闆我們也需要知道, work is everything, till shit happens.

1) mock不需要架構

2) prototype也不需要架構

3) 甚至日常生活也不需要架構, till shit happens.

第一次第二次shit來了, 沒事, 每個人都是這麼成長了, 不過以後你每次寫個東西, shit 隨時happens, 怎麼辦?

老闆說改改這, 改改那, 改不了怎麼辦?

改了全壞了怎麼辦?

再次"實話說，現在誰跟我談架構我跟誰急" 確實, 誰跟我說架構, 我也跟誰急, 我只認同show me the code, benchmark一下, 我面試過超過200人, 見過不少人在簡歷上寫"重寫架構"之類的, 我就一個問題, 多少improvement? 答不上的請出門右拐直接gg.

最後, talk is cheap, code is also cheap. 我們建立一個團隊, 建立一個公司, 公司發展當然是首要的, 但是也不能忽略團隊的建設, 水桶原則 vs 人往高處走.

再最後, 軟體工程其實簡單來說就是proper engineering, 不要over engineering也不要under engineering, 當有個人跟你說software engineering不重要的時候, 你真的要清楚了.

按照我的經驗, 衡量proper engineering的方法挺簡單的, 每天聽到WTF的次數心裡就有數了.

真的最後了, 如果你是一個軟體工程師, 其實我只是單純的希望, 你每過一年, 都能對自己負責而已.

題主是學軟體工程的，但對軟體工程的真正理解還需要好好打磨幾年，現在你理解的「軟體工程」其實並非軟體工程。

什麼是軟體工程呢？軟體工程是寫軟體的方法。我們寫一個編輯器，做界面，做正則表達式解釋，做用戶界面優化，這些「寫軟體」，如何安排模塊之間關係，選擇什麼介面和協議，選擇什麼部件，這叫「軟體構架」，但誰來寫什麼軟體，進度間如何配合，如何進行質量保證，如何安排軟體生命周期，這是「軟體工程」。

軟體工程並非CMM，並非需求分析，並非width-band delphi方法，更不是編程規範，文檔寫作或者流程規範。

軟體工程是最優的組織軟體開發的的方法——即使只有一個人開發軟體的時候。

所以不管你在學校學了什麼，請首先搞明白企業中真正導致這個企業活下去的原因是什麼。你在學校里學的是理論，是面面俱到的理論，但理論不是用來實用的，實用的東西是基於這些理論進行的力量分布，真正的經驗也是知道在特定的行業中，什麼實踐才是為其生存提供最大貢獻的要素。這才是軟體工程的本質，軟體工程的本質就是對資源和力量的調整能力。

2000年左右的時候，印度ODC公司和我們談合同，還在關心CMM，現在和我們談合同，CMM一字不談，只談成功經驗，以及長期合作的籌碼，你可以掂量掂量這其中的差別。

所以，我建議題主謙虛點，先清空自己，寫好自己的程序，實踐自己的方法，欣賞自己所在的公司如何生存，這對誰都有利。

我剛畢業的時候跟你一樣有這個疑惑，甚至在自己公司論壇上吐槽代碼注釋不規範被部門領導約談過。

公司算是行業至少前二，其實日常工作中多數時間是疲於奔命，不是我不想搞那些各種文檔各種規範各種評審，我是真的沒有那個時間。

雖然以上各種客觀理由，現在目前我所在的項目組每次修改，每次提交都必須有固定格式的注釋，寫明修改時間，因為什麼需求，修改單編號是什麼，修改版本是什麼，涉及哪些文件。

如果有人不按規則提交，首先格式不對是提交不成功的，即使格式對提交成功如果內容不對跟實際修改內容不一樣，配置管理會發郵件通報，堅持一段時間就會養成好習慣。

對於你來說現有的環境確實很難改變，但是你可以從自己做起，涉及自己的文檔寫好，代碼寫好，注釋寫好，慢慢影響其他人。一味的抱怨不能解決問題，我們要在發現問題的同時想辦法去改變。

軟體工程就是用額外的投入換取項目複雜度上限的一種技術。

軟體工程要做到什麼程度，取決於對項目複雜度的預估。

軟體工程是有成本的，過度投入是一種浪費。

複雜度超過上限就會出現項目雪崩現象，即bug修不完且互相影響，同時新功能擴展困難。

軟體工程是一個一直存在的東西，一個軟體項目從開始到結束，必然要遵循一定的規律，而軟體工程就是解釋這個規律並且給出建議的學科。

就好像拿著一張照片去找建築師建立一棟一模一樣的樓，建築師也要從設計圖開始，進而施工，驗收，交付；拿著一張明星照片去找醫生整容，醫生也要從規劃開始，進而手術，跟進術後恢復，直到完全恢復。

但軟體開發是抽象的，難以憑直覺量化，在不了解軟體工程的人看來，要做網站只要一個psd，然後把psd還原出來，網站就可以上線了。而且按照這個路子胡搞瞎搞，最終做出來的東西也不是差得離譜，慢慢就被接受為常態了。

畢竟大多數低質軟體的生命期並不足以暴露缺乏軟體工程帶來的惡果，比如做一個微信傳播的頁面，可以不做代碼版本控制，可以不做單元測試，上線前跑一遍主業務流程沒問題就提交，反正過幾天就沒人再打開了。

在做了很多minisite的外包之後，想要把重複的部分做成組件，這時候就需要分析業務邏輯了。建立組件以後，對每個組件做單元測試，而組件拼裝好上線之前要做回歸測試。再然後，打算做一個可視化編輯minisite的平台，需要規劃產品功能和開發計劃，引入版本控制工具，引入自動化測試。

所以軟體工程不是玄學，是工作中水到渠成的事情，只要你受不了在泥潭中掙扎，無論從那邊上岸，岸上都刻著軟體工程四個大字。

前兩天正好和朋友說起這個事情，ta說

我隨便找幾個朋友做的網站就不錯，管理後台也挺好的，現在又要寫文檔，又要重構，是不是你們程序員都喜歡什麼都自己從頭來一遍，把時間都浪費了。

我說，以前我們家門口有個人每天在路口要飯，他也覺得吃的很飽，偶爾還能吃到肉，然後我過去和他說這樣不行，是沒有保障的。他伸手給了我一耳光，說

「TM居然讓老子去種地！」

軟體工程是會提高程序員幸福度的東西

然而並沒有人希望你幸福

多寫代碼，自己能做到「低耦合高內聚」這6個字再說。

所有文檔也好，管理也好，流程也好，無非都奔著這6個字目標去的。

首先需要了解什麼是軟體工程，以及軟體工程學適用的範圍以及解決的問題；

贊同 @曹政的觀點；

work is everything

所有的工程學都是基於大量實踐的抽象總結；而任何一種實踐是否對自己的組織有用最關鍵的是執行。

沒有銀彈。

也推薦了解下軟體工藝 (豆瓣)

騷年，你工作幾年知道為什麼了。我們是搬磚的，老闆真沒把我們當成工程師。你這不是很正常嗎？五個人的活花四個人的錢給三個人干？加班都搞不過來？誰還考慮規範性、低耦合這些啊。

工程是管理過程的是管理模式的複製使用模式是不斷反覆沉澱為了復用抽象提煉的

所以我們看到工程模式都是以復用為前提如果我們做的項目沒有復用的前提傳統軟體工程的美好就會大打折扣同時業務總是第一位的（即使再強調軟體工程也總會讓步業務）商業目標往往壓倒一切當項目不是為了復用（例如蘋果的產品、微軟的office等大規模複製的軟體產品）那軟體工程的目標降低為質量高維護成本低 blahblah 所以需要大範圍的剪裁否則模式過重會嚴重製約業務目標達成（有限成本作出符合商業需求的項目）

例如敏捷模式就是抓住精髓在某些場景下的大範圍剪裁看看敏捷宣言表明的就挺到位

因此在現在這個各行各業皆需要軟體互聯網雲計算工業4.0在強調軟體核心地位的「動蕩」年代不是追求復古的傳統的完整的軟體工程的好年代很像孔老夫子哀嘆沒有禮國不存但是事實證明完整的周禮不存在了但是國家還是會繼續存在與發展有了法律道德潛規則等規範和制約

因此不是說不需要軟體工程了而是現在軟體工程面對軟體需求爆炸的年代跟不上節奏了當然縱觀近30年歷史軟體工程一直處在跟不上節奏的狀態呵呵

面對更廣闊的場景傳統軟體工程抽象化程度已經不夠了

最後用一句總結就是無之以為用有之以為利共勉破除執障祝你早日進入到不困惑有方法的境界