人生從來就不是單一和乏味的，總是充滿著理性和感性。
作為乙個喜歡文科的人，我應該是比較感性的，但是作為乙個程式設計師，我似乎更多的是應該保持理性。
感性容易引起別人的共鳴，而理性更應該拿資料說話，也許顯得有些無趣，卻可能更有實用的價值。
五年來，我經歷了三家公司，也可以說是兩家。
前兩家都是外包給移動，後邊這一家是外包給聯通。乍一看，似乎我一直從事的都是電信行業，但實際上並不是，我只是一直都在電信行業的公司而已。
在第一家公司基本都是圍繞著電信主業務做的一些邊緣系統，第二家公司則應該算是電信增值業務：電信裡的支付。
到了現在，看起來也是電信公司，但實際上則主要是車聯網。
軟體開發，開發的就不是軟體本身，只是以軟體表達特定的業務而已。對於一直喜歡車的我，進入車聯網行業，無疑是非常幸運的。
進入這個公司後，我總是不由自主的去了解許多本身工作任務之外的業務，也總是情不自禁的為我們服務的車企主動打廣告，更總是時不時沒來由的感覺到一些說不清的自豪感。
這一切，都讓我想起網上一些文章說的那句話：「做自己喜歡的工作是一件多麼幸福的事」。
以前雖然一直也覺得這句話似乎有道理，實際卻並不能真的體會。
那時候總會想，做自己喜歡的工作是一件多麼困難的事，除非是想辦法喜歡上自己的工作。
雖然，想辦法喜歡上自己的工作，也算是一種辦法，但是回過頭來看，和做自己喜歡的工作，還是有很大的區別。
喜歡和想辦法喜歡，這本身就不是乙個概念。
有的人，充其一生也無法找到自己喜歡的工作，有的人，費盡心思還是對自己的工作不喜歡！
有人說，世上唯一不變的就是改變。
在軟體這個行業，真的是得到了非常好的詮釋，主流的技術和框架都總在飛快的變化著，稍有不慎，可能就已經跟不上主流的步伐。
很慶幸的是，五年來，我雖然經歷過大大小小十幾個專案，但從大的方向來說，專案中的技術始終都是前沿主流的技術。
在入行之初，分布式和非關聯式資料庫的概念及技術才剛剛興起的時候，我們就已經開始嘗鮮，就如下圖所示：
雖然說這裡邊的技術我有些並沒有實際用到，但是因為專案涉及了，所以我多少有些了解，最起碼在眼界上得到了足夠的開拓。
人和人之間差距的拉開，有時候可能就只是因為知道和不知道，因為知道的多一點，於是可能就多做了一點，然後知道了更多，進而再多做一點，慢慢的，可能差距就越來越明顯。
從技術棧上而言，這是第乙個正式的業務，所有的技術其實都是耳目一新。
世界的技術總是在飛快的改變，但是乙個公司的技術其實並不會也那麼快的改變，所以下乙個讓我覺得比較有代表性的整體技術替換時間，是在我入行大概兩年半的時候，也就是我換第二家公司的時候。
那個時候是微服務這個概念剛剛流行起來不到一年，新公司的新業務也剛好進行了追心，於是我幸運的又一次擠在了某些技術的前沿。
在這家公司，我覺得比較有代表性的技術架構大概是下邊這樣的，只是為了職業道德和商業秘密，肯定不能展示真實的架構，只能是根據自己的理解畫乙個大概：
細心之人可能會發現，這個圖和上邊那個有乙個共同點，那就是都用了storm和flume。
這也剛好證明了我說的我可以算是經歷了兩家公司，也可以算是經歷了三家。
第一家和第二家，都是給同乙個公司外包的，所以從大的架構而言，就自然具有了一定的共性。
從技術棧上而言，第二家公司給我最大的影響無疑就是微服務和springboot，除此之外，就是簽名加密了解，就像前邊說的一樣，讓我知道了這樣乙個東西，有了乙個安全的概念。
對於同一家公司來說，部分技術的更新和替換自然是沒有問題的，但是想要大刀闊斧的一次性整體改變，必然是充滿了風險，也不是很現實。
所以，讓我第三次覺得整個技術架構和技術棧天翻地覆的時間，也是我進入第三家公司的時候。
如果說在第一家公司我所做的都是邊緣的業務，那麼第二家公司應該能算是次邊緣的業務，而第三家公司就已經是非常核心的業務了。
因此第三家公司我所見到的、所理解的業務也是最最複雜的，單純的從技術棧上就能看出來：
在這裡，以微服務為基礎，同時了解和應用了容器技術以及現在比較火的雲產品。
不僅如此，在軟體安全方面，不論是ssl、單點登入還是認證授權，也都從以前僅僅是概念深入到了應用，從以前僅僅是知道，變成了現在一定的理解。
有人說之前的公司不好，學不到什麼東西；有人說外包不好，學不到什麼技術。
但是我覺得其實也都挺好的，什麼事都有例外。
人世總在變化，存在即是合理，想透才能淡然，看開但不消極！
軟體開發實操彙總（二）軟體開發基礎
有了上述經營戰略 內部資源配置及專案自身情況等內容的彙總及分析，針對不同情況，在開發前，應具體深入的進行專案的前期調研，梳理出專案的具體需求及各種問題，將需求和問題一一落實到文件編制。此過程是專案是否能夠順利實施並取得預期效果的關鍵，大體分為以下幾個步驟 1 需求和問題的歸納 2 編制需求文件 問題...
軟體開發的五個步驟
1 分析 軟體需求分析是回答做什麼的問題。它是乙個對使用者的需求進行去粗取精 去偽存真 正確理解，然後把它用軟體工程開發語言 形式功能規約，即需求規格說明書 表達出來的過程。本階段的基本任務是和使用者一起確定要解決的問題，建立軟體的邏輯模型，編寫需求規格說明書文件並最終得到使用者的認可。2 設計 軟...
軟體開發的五個階段
軟體開發一般分為五個階段 1.問題的定義及規劃 此階段是軟體開發與需求放共同討論，主要確定軟體的開發目標及其可行性。2.需求分析 在確定軟體開發可行性的情況下，對軟體需要實現的各個功能進行詳細需求分析。需求分析階段是乙個很重要的階段，這一階段做的好，將為整個軟體專案的開發打下良好的基礎。唯一不變的是...