? ? ? 最近一直在進行架構方面的學習，軟件工程師是比較重要的部分，正好又趕上了公司一些瑣事，頗有感觸，萌生了一個粗略的想法，以個人這幾年的從事一線開發的經驗，整理下對軟件開發過程的理解，一些開發中應當注意的問題和遵循的規則，話不多說，直入正題。
1、需求與原型
一個軟件項目的開發，需求是必須的，在當前的敏捷開發大行其道的形式下，在需求的基礎制作出原型，應該多數團隊采用的方式，畢竟原型比起繁瑣的文檔更加直觀，更容易反應需求中不足之處。比起最初的瀑布模型、增量模型、螺旋模型等方式更加適應當前軟件開發的快速迭代的模式和市場需求，但是快速開發并不代表沒有需求文檔，沒有原型文檔，我就曾經有被叫去開了十幾分鐘會，什么文檔都沒有情況下，被問這個項目多長時間能做完，醉了，個人認為，一個項目開發時間的長度，是要需求功能詳細到一定程度的情況下，來評估，當然，可以提前定時間節點，但要也有詳細的需求，然后在需求上分出主要功能、重要的功能、次要的功能，排期，做取舍，依次來卡時間點下完成的功能。
一個匆忙開始軟件項目（更應該稱之為 demo），最終走向成功的可能性也是微乎其微的，不尊重軟件開發的流程和規則的，最終出來的軟件也不能稱之為產品。
2、代碼庫
代碼庫是軟件開發中必須的工具，可以很好管理代碼的版本，防止丟失，提高多人協作的工作效率，優勢不多說，基本是項目必須使用的。
現在使用最多的應該是 git 了吧，當然 svn 也是很多的，github 有些龐大的開發用戶，我所知道的有些企業就是拿 github 來做自己的代碼倉庫的，其實，創業軟件公司，使用 github 時不錯選擇，比起自建的 gitlab，代碼審查做的比較好，所有良好的軟件開發習慣，git（svn）必不可少。
記得最初公司有個別組的同事，還是使用 U盤互相拷貝代碼，低效易錯，甚至丟失代碼，問題多種多樣啊，當然，他們不使用代碼也有貌似很合情合理的理由，那就是這東西太麻煩了，怎么又沖突了，怎么搞啊？這東西在最初使用總是會碰到問題的，代碼合并時的沖突在所難免，但不會丟失你的代碼，所有不要因為麻煩而不使用他，這些問題網上一搜，解決方案很多，工具很多，沒有理由拒絕一個提升工作效率和安全保障的東西啊。
3、編碼及規范，學會使用工具和 IDE
程序員編碼規范和代碼的整潔度是水平的重要體現，這些年開發下來，基本的水平比較高的，一般的代碼規范都做的很好，風格統一，結構清晰，所以對一個技術研發為主的公司來說，強調編碼規范也就無比的重要了。
為什么提到了學會使用工具和 IDE 呢，因為工作中發現有很多的程序員（當然也包括初期的自己），除了 IDE 的提供基本的功能外，根本不去研究 IDE 里面的其他選項，甚至插件，比如代碼模板、代碼格式化等其他可以切實提供開發效率的功能，比如代碼模板，可以按照規則在創建代碼文件是預生成常用的代碼結構，提供編碼的效率。代碼格式話自然比不說，有時寫著寫難免出現錯亂，一個快捷鍵即可搞定。舉得這兩個例子都比較簡單了，其實還有很多使用的地方，在閑暇時不妨好好研究下，這畢竟是你吃飯的工具啊。
4、單元測試
曾經跟公司一位測試的同事聊到了單元測試，他說，公司里也就你們組提交的代碼有單元測試，其他組的沒有看到過，我當時還是挺驚訝的，不過也不能解釋一些問題了。單元測試是軟件工程必不可少的部分，是程序員在編碼的過程必須要做的，曾經一位大牛哥們，代碼寫的相當的整潔漂亮，單元測試代碼案例完備，他提交的代碼和項目，運行起來基本沒出現過 BUG（不制造 BUG 的程序員是不存在），測試省時省力，服務器上線沒有出現過問題。所以，編碼的過程必須要編寫單元測試的，有些程序員覺得自己很牛，你問他程序測過了嗎，他說測過了，你去看他的代碼，基本上看不到一行單元測試的代碼，然后提交后總要和測試軟件交流幾輪甚至幾十輪后才能通過，這也變項的延誤了項目上線時間。
能編寫良好的單員測試，是程序員上升一個臺階的標準，減少 BUG，提供程序的穩定性。
5、技術積累與流程化自動化
一個公司從最初技術的選型，積累，到重構再積累，是要經過很長的一段時間了，花費很多的心血，并不是隨便的說轉變就可以轉變的，從人員組成，到技術培訓學習，到編碼規范的制定，再到自動化環境的搭建，談何容易。一個云平臺的研發建立，需要的知識和人員也要復雜多，所有，一但定好的技術選型，只要不重新洗牌，就不要輕易的改變。
從公司成立到現在，一套流程的建立不易，最初小作坊式的開發方式，服務器的部署還是 scp，查看 log 遠程登錄到服務器，甚至出現問題直接服務器上修改更新，問題多、Bug 多、風險大、效率低，在多次失敗，初步成長，建立了一套比較完整自動化流程體系，也是基于公司的研發流程，從 git 項目建立開始，到分支的確定，代碼審查與合并，再到測試環境的部署，完成測試后，上線發布，自動化更新，這些流程與工具，簡化了運維工作，避免錯誤，為什么要去打破呢？小作坊式的工作已經被證實是存在不可避免的問題的。
下面也簡單的說下采用自動化方式，git 代碼庫是必不可少的，我們的代碼會有2個基本的分支，master 和 develop，master 為線上運行的代碼或即將上線的代碼（線上代碼也會打個標記，用于線上的 bugfix），develop 為測試環境部署的代碼，每個開發人員開發會有自己的分支，但完成開發需要進行提測是，會合并到 develop 分支，通過 jekins 來自動部署到測試環境，以供測試，測試通過后，合并到 master，通過 jekins 自動化構建，并推送線上的部署系統，最終的部署，通過正式的系統一鍵完成，流程操作快捷簡單，還不容易出錯兒導致問題。
因為項目采用了微服務的架構模式，各服務運行中會有相互的依賴，所以在搭建自己的開發環境時，我自己嘗試使用 TeamCity，這比起 jekins 來說要簡單好多，而且可以實時跟蹤變更，自動部署，再多人多服務開發的情況下，效率可以得到很大的提升。
啰嗦了那么多，也是自己作為程序員在開發路上的一點經驗吧，寫的比較倉促，也歡迎閱讀共同討論，望不吝賜教。
