1樓：
關鍵的點其實在於工程二字。但是國內的軟體工程並不灌輸工程的概念。
說軟體工程有用沒用，如果打算止步於作坊式的工作環境和方法，那就沒用。如果打算個人全面成長，以專業的方式做事，與專業的人共事，那麼就有用
2樓：
軟體工程不是什麼言必稱三十五層架構、cmmi、人月神話、敏捷開發、快速迭代、極限程式設計、面向xx程式設計等等，這都是虛的。真正實的東西都已經被做成工具，成為開發本身的一部分了，你甚至沒有意識到這些就是軟體工程的精華。
比如重構和單元測試都是IDE的標配。
比如bug跟蹤軟體是開發必備。
比如版本控制軟體甚至成了程式設計師的簡歷。
比如mvc模型是一些web開發框架的預設選擇，想要不用還挺難的。
比如延遲載入、工廠方法和單件等已經做到類庫里了，你呼叫就行，管他什麼模式。
說到虛的，我只服這本
3樓：
難道沒有考慮到後期的維護嗎？估計二次開發的程式設計師都會問候別人祖宗，有的只是為了完成工作上班 ， 你還沒有遇到有 `工匠精神的程式設計師`。
4樓：
題主是學軟體工程的，但對軟體工程的真正理解還需要好好打磨幾年，現在你理解的「軟體工程」其實並非軟體工程。
什麼是軟體工程呢？軟體工程是寫軟體的方法。我們寫乙個編輯器，做介面，做正規表示式解釋，做使用者介面優化，這些「寫軟體」，如何安排模組之間關係，選擇什麼介面和協議，選擇什麼部件，這叫「軟體構架」，但誰來寫什麼軟體，進度間如何配合，如何進行質量保證，如何安排軟體生命週期，這是「軟體工程」。
軟體工程並非CMM，並非需求分析，並非width-band delphi方法，更不是程式設計規範，文件寫作或者流程規範。
軟體工程是最優的組織軟體開發的的方法——即使只有乙個人開發軟體的時候。
所以不管你在學校學了什麼，請首先搞明白企業中真正導致這個企業活下去的原因是什麼。你在學校裡學的是理論，是面面俱到的理論，但理論不是用來實用的，實用的東西是基於這些理論進行的力量分布，真正的經驗也是知道在特定的行業中，什麼實踐才是為其生存提供最大貢獻的要素。這才是軟體工程的本質，軟體工程的本質就是對資源和力量的調整能力。
2023年左右的時候，印度ODC公司和我們談合同，還在關心CMM，現在和我們談合同，CMM一字不談，只談成功經驗，以及長期合作的籌碼，你可以掂量掂量這其中的差別。
所以，我建議題主謙虛點，先清空自己，寫好自己的程式，實踐自己的方法，欣賞自己所在的公司如何生存，這對誰都有利。
5樓：未配妥劍過盡千帆
當公司得體量大到乙個程度時。
當公司得人員流動量開始變大時。
軟體工程對於軟體開發整個過程得意義就體現出來了。
既然題主你有這個覺悟，覺得題主可以換個相對規範的軟體開發環境，學習一下正規軍是怎麼打仗的
6樓：昆吾
工程，任何時候都是取捨的問題，永遠沒有絕對的標準化，只是不斷地博弈，和人，和環境。
軟體工程亦是如此。書上說的東西，考試的東西，大多都是一些基本原則或者參考樣例，並不是標準答案。
乙個大型軟體專案不是一天構成的，乙個公司完整的工程流程也是如此。公司需要根據自己實際的資金能力，員工的技術水平技術背景做取捨。舉個例子，敏捷推崇結對程式設計，可是對於僅有幾名程式設計師卻工作量巨大的公司來說，結對程式設計只會讓公司死得很難看。
理想和現實總有不同，如果你能思考一下一家公司工程制度為什麼這個樣子，以後你除了做好自己的事情以外還能如何推動它改善，那會給你帶來很多收穫。
7樓：大馬
軟體工程就是用額外的投入換取專案複雜度上限的一種技術。
軟體工程要做到什麼程度，取決於對專案複雜度的預估。
軟體工程是有成本的，過度投入是一種浪費。
複雜度超過上限就會出現專案雪崩現象，即bug修不完且互相影響，同時新功能擴充套件困難。
8樓：
軟體工程適合搞軟體。網際網路不算軟體，按傳統軟體的流程去搞，別人黃瓜都吃了，你才播種子。傳統軟體可能按月甚至是年計算工期，而網際網路是按天或周計算工期，按月計算工期的專案很難活下來。
專案設計文件？對不起，有資料庫字段說明文件就謝天謝地了。
9樓：白色的藍
首先需要了解什麼是軟體工程，以及軟體工程學適用的範圍以及解決的問題；
贊同 @曹政 的觀點；
work is everything
所有的工程學都是基於大量實踐的抽象總結；而任何一種實踐是否對自己的組織有用最關鍵的是執行。
沒有銀彈。
也推薦了解下 軟體工藝 (豆瓣)
10樓：這誰頂得住啊
「軟體工程是重要的」
相信大多數自稱軟體架構師、程式設計師、碼農們的傢伙，內心都會認可這個說法，
但是現實卻是下面的對話。
私企老闆說：我們要做XX系統，什麼時候能拿出可用版本？半年？！WTF！！兩個月行不行？
大型企業的中層經理說：我們要增加這四個新功能，多長時間可以完成？乙個月？！WTF！！兩周夠不夠？？
所有boss都希望快快快，沒有多少人會考慮時間、質量之間的糾結關係，只要能快速拿出產品，其他東西（文件、規範、架構設計等等）都可以緩一緩。當然了，這緩一緩意味著什麼估計開發者都在工作中親身感受過……
11樓：
根據我的工作經歷，我覺得軟體開發產業的管理瓶頸不在於開發流程（當然開發流程確實能減少開發過程的很多問題），而是最基本的業務流程和成員激勵的問題。乙個沒有什麼流程的團隊可以做出很棒的軟體，乙個流程嚴格的團隊也可以一無所成。
軟體行業在我看來最大的管理弊病在於，很多時候是外行管理內行，一群對技術模模糊糊知道一些的管理層來管理具體做事的員工。對於走技術路線公升上去的經理，情況稍好，然而期待他能懂組裡所有人做的事，也比較難。
外行管理內行的最大害處，在於不能以產出來衡量業績。比如，乙個BUG，也許很難但是我一天就改好了，可能還不如乙個不那麼難但是讓人覺得工作態度端正的人花幾天改好的人評價好。
所以，在軟體行業，你需要 -
1，態度端正，在公司少上網路不能打遊戲。
2，要做「大活」，要做領導看得見的活，對於難活能推則推。
3，及時向領導匯報成果，而且要適當誇大。
4，積極參與公司公共事務，比如年會什麼的。
5，訓練好PPT技能，經常做 knowledge share，英文 presentation 能力強。
為什麼要這樣，是因為這些東西領導看得見並且易於評價。真正的業務部分，是難以評價的。比如，你花幾個月時間改乙個BUG而不向經理強調它有多麼難解決，也許經理不會認為它難而是認為你蠢。
更進一步問，為什麼公司不強調業務能力還能活的好好的？因為軟體開發和維護過程中，真正的難題不會超過其中的 10%，大部分人從事的工作都是區分不了業績的，至少是很難區分業務水平的。認為軟體行業是智力密集型行業的說法正確，然而認為軟體行業智力越高會混得越好，則是錯誤的。
12樓：馮東
軟體構建是需要方法的。比如說 scrum, refactor 都是一些提高軟體質量的概念。但是「軟體工程」是乙個有很大誤導性的概念。因為軟體和傳統的工程有很大不同。
時間跨度不同，單位時間跨度裡構建出來的複雜度也不同。拿航空發動機來比較，航空發動機確實非常複雜，但是以航空發動機積累的時間來看，在單位時間裡航空發動機複雜度的增長沒有乙個軟體系統快。
類似的，單位投資對應的複雜度也不同。傳統工程一般是投資封頂。就算工程師能想到一些複雜的點子，投資者也不會讓他開始去做。
就是說不管能不能做出來，連啟動資金都沒有。而軟體系統是複雜度封頂。只要程式設計師能想到，不管最後是不是預算超支或者延期，總有啟動資金支援你去做。
所以你的第一課應該是停止用「軟體工程」這個名字來思考。
在工作中什麼是上心
林下輕風 主動點，把自己分內的事情在工作前就想一想，並想如何完善。再從全域性的位置想想自己現在的工作，對整體工作的作用是怎樣的。做完事再思考明天該幹什麼，今天的進度怎樣，今天為明天的工作準備些什麼。 千年墨 自己工作完成好。多想想為什麼要這樣做，很多時候，知道自己工作在整個事情中的地位和重要性，會對...
在工作中受了委屈怎麼辦？
Jack jiang 放正心態，先自身找原因 2.過不去的坎，可以通過好朋友一起分析 3.不同的職場人，受到不同的環境影響，但可以肯定的是職場不比學校 4.有一句話講的非常好 在職場上真生氣，不管你對和錯，你都是敗者。 人生都難免碰到委屈，別說工作了。看你這個情況，委屈是肯定的，首先要調整自己的情緒...
你們有沒有在工作中迷惘過
當然有了呀，不過那時我是在實習的時候。就在去年暑假，我去了優衣庫做實習生。剛開始的時候，再對優衣庫實習生工作沒有很了解的時候，還對優衣庫的實習生工作抱有特別大的期望，非常的有熱情，感覺裡面的環境等各方面都是特別的好，特別的融洽，但是一段時間的工作下來，發現自己真的太天真了。我不是說做優衣庫的實習生或...