我只記得初中的時候有計算機課，老師教我們玩flash，也就做一下補間動畫，沒用到as。高中的時候上過一點點程式設計，用的是什麼語言忘記了，當時就是做了個加減乘除的運算，大概類似
inta=
1;
intb=
2;
int
c;
c=a
+b;
print(c
);
當時就照著老師給的**敲上去了，得出了結果，讓我有一絲興奮，可是我百思不得其解，int是什麼鬼，int a=1又是什麼意思，為什麼一定要這樣子敲才行？詢問老師，雖然老師的解答像是聽天書，但是我還是覺得很神奇的。由於學業繁重，08年的時候資訊網路還沒那麼發達（當時乙個月30m流量根本用不完啊！），也沒處深入學習，就這樣沒有然後了。
大一大二基本都是在學程式設計基礎，當時班裡有幾個從小學就開始程式設計的同學，在我們心中簡直就是神一般的存在，怪叔叔就是其中一位，很感謝他耐心的解答當時我提出的各種奇怪的問題（因為不懂，所以問的問題也很搞笑）。
大三大四才開始初步學習軟體工程，當然也都是在紙上談兵，實踐的時候大家也都是像過家家一樣，不痛不癢，似懂非懂。
那到底什麼才是軟體工程？它與傳統工程有什麼不同？當初我總拿土木工程做模擬，但是到最後發現並非如此。
也就在幾十年前，計算機的硬體還是如此的low，導致我們開發的軟體規模不可能太大，那麼需要的人手也不是很多，大多數軟體都是乙個人完成的。多虧了摩爾定律，如今計算機硬體可以說多數情況已經不列入軟體評估的範圍了。於此同時，軟體的需求也越來越多，規模越來越大，幾個人不能完成了，怎麼辦？召集人手一起幹！然而結果最終產出的軟體產品質量不高，實際生產效率低下，從而導致了「軟體危機」的產生。這迫使人們不得不研究、改變軟體開發的技術手段和管理方法。軟體工程由此而來
我想這是軟體工程與傳統工程最大的不同
如果說軟體的核心是機器，軟體工程也不會是如此困難了，因為機器是可度量的，可操控的，就像流水線上的機器，你讓它幹一整天，它不會說生氣不幹了，並且每一台機器每天的產量是一樣的。
但是軟體開發是乙個創造性的過程，也只有人類擁有創造性思維。
所以軟體開發絕大部分是受到人為因素影響的，而世界上的每個人又不同，如何物色、管理、運用這些人？讓他們發揮其最大的價值？
《人月神話》裡也清楚的表述過，人越多，溝通成本越高，而每個人的技術實力又不同，如果乙個大牛突然生病了，這個影響就很大了，所以你很難用人月來評估專案進度。
這是乙個需要長期思考實踐的過程（貌似無解，不然這麼多年也不會停滯不前）。
軟體是人類智慧型創造的結晶，只可惜它不像傳統工程顯而易見，當你拿著手機在**上購買商品時，你看到的只是軟體ui互動部分，指引你發生購買行為，但是整個過程涉及到的技術以及**量，你是無法想象到的，就算給你原始碼看，難度也堪比登天。
這也就出現了讓我們程式設計師啼笑皆非的提問
這一時半會很真的很難評估……因為這裡面涉及到太多東西了。所以軟體評估量化真的很難，而且實現方法原理都有所不同，這也就說明了軟體是高度複雜的。
這也就牽扯到乙個問題，軟體開發過程中的程式設計師不能隨意更換，否則重新理解閱讀軟體原始碼和學習開發框架是有成本風險的，這也是為什麼軟體工程需要制定規範，撰寫文件等等。
從某種意義上，軟體工程更希望我們像一顆螺絲釘，壞了立馬可以更換。
任何新的技術和方法都不會無緣無故出現，都是為了更好的服務於某一種活動。
我們熟知的物件導向，敏捷開發等各種方法，各種語言，各種框架，其實都是為了解決軟體工程的難題。
所以，有時候我們不必盲目崇拜新的技術和方法，這都需要我們進行評估，你不可能用node.js來寫cpu密集型的程式吧？如果專案組沒人會go語言，我看還是用熟悉的語言吧，不然學習成本和風險太大了。
在給定成本、進度的前提下，開發出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足使用者需求的軟體產品。這才是我們需要思考的問題。
經過時間的歷練，軟體工程一般會有6個階段：
1、可行性分析
「我想開發乙個**系統，你看行不行？」
在我看來，目前任何技術上的問題，都不是問題……，所以這個過程經常討論的是政策、法律、人員、資金方面的問題。
2、需求分析
「就開發乙個類似**的軟體，你看多少錢？」
這樣的問題是個深水炸彈，經驗不足的新人總會不假思索的大概給個估價~，如果你估對了還好，不對就等著扯皮吧！
我遇到這樣的問題，如果沒有足夠把握，一律會要求做一次詳細的需求分析，待甲方確定了需求並且簽字之後，最後進行才進行總體評估，當然，過程中變更是不可避免的，但是有這個需求確認單，可以減少很多扯皮的事情。
3、設計
這個階段就比較考驗技術團隊了、其中包括系統架構師、軟體設計師，對於技術選型，架構設計需要符合當前的系統需求情況，最好做到不多不少，剛剛好~對於日後使用者資料規模變大之後，再進行二次架構變更，這個過程其實是需要演進的，很難做到一開始就設計出完全符合高軟體質量的架構，並且每個特定領域都不一樣，除非技術團隊在這個領域已經有過多年大型開發經驗。
在設計的同時，也要評估具體的專案時間進度，這玩意基本全靠經驗（注意，每個人的生產效率都不一樣），也許大牛這個模組1天搞定，分配到其他程式設計師，3天也搞不定，也許你認為1天可以搞定，可能3天也搞不定…，這時候開個會議進行分工，讓相應的程式設計師自己評估也未嘗不可（類似的方法也有很多）。
4.、實施
這個時候專案經理就起到了很大的作用了，需要把控好整個專案的實施過程。而我們程式設計師要做好的就是，按照設計規範寫**，做好注釋，做好單元測試。
5、 測試
qa大顯身手的時候到了，但是小公司基本上都是程式設計師自己測試，不管用什麼測試方法，總之最後要求軟體符合產品需求，不然就等著扣錢吧。
6、驗收
甲方測試通過，就可以進入驗收階段了，各種文件的交付，軟體部署，運維方案等等，但是這個階段甲方總喜歡骨頭裡挑刺，也會再提一些修改要求，到這個階段，總之要自己權衡了利弊，如果雙方都滿意那真實是皆大歡喜。
3年了，做過外包，搞過產品，目前我對軟體工程的理解就那麼多，再來看一下公認的定義：
軟體工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。在給定成本、進度的前提下，開發出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足使用者需求的軟體產品。目前的規模，軟體在今後很難再是幾個人開發的，而是由幾十甚至幾百人的團隊進行。而人又很難進行度量。
所以我認為歸根結底還是由於人為因素的不確定性，導致軟體工程如此特立獨行。
過了那麼多年，我們還在尋找那一顆銀彈，然而依舊還有很長的路要走呢。
來自為知筆記(wiz)
軟體工程 軟體工程的理解
四 軟體危機 五 軟體工程要素及其作用 針對本學期第一次軟體工程課後的思考題，參考課本以及網路上的資料，作出如下自己的思考理解。在此之前，我所做過的工程僅僅侷限於一些課程的大作業上，並沒有更進一步到軟體上面，僅僅是針對某乙個或者某一類問題進行解決。我的看法 1 書上的定義 書上給出了許許多多的定義，...
軟體工程的理解
軟體工程專業是一門研究用工程化方法構建和維護有效的 實用的軟體工程知識體系全景圖和高質量 的軟體的學科，也是作為乙個計算機研究人員必須掌握的一門重要技術，在我們研究的物聯網專業中軟體 工程是學習軟體的一項必備技能，其中包括軟體的開發和應用，必須要熟練掌握開發語言和應用技巧，它 涉及到程式語言，資料庫...
軟體工程之怎麼理解軟體工程
軟體工程學習第二篇，什麼是軟體工程？隨著軟體規模越來越大，複雜度不斷增加，在軟體專案開發和維護的過程中逐漸暴露出來了一些問題，如 軟體產品質量低劣 維護工作量大 成本不斷上公升，進度不可控 程式人員無限度的增加 增加人員並沒有按時交付 軟體危機 這一概念被提了出來。而軟體工程是為了研究和克服軟體危機...