1.系統流程梳理
以乙個很簡單的例子來說明流程梳理對軟體開發的意義，比如你要進行一次演講，但是這次演講是即興的，你不是專業的即興演講家，那麼在沒有準備情況下，你要對著台下的人進行演講，這個時候你走上台去，腦子裡的東西還沒有形成有條理的演講內容，講完後台下的人都不知道你在講什麼，可能你自己都不知道你剛剛講了些什麼，這就是失敗的演講，沒有做好充足的準備。對於軟體開發來說也是同樣的情況，每乙個開發者不應該僅僅拿到的是一些文件，而是應該大家坐在一起，由熟悉該軟體業務的管理者或者其他人來進行一次嚴謹的描述，並進行討論，加以完善和改進，讓參與編碼的開發者在這個過程中不僅能夠熟悉自己要做的那些功能的細節，還能對這個系統有乙個大致的了解和熟悉，只有這樣，在開發中才會避免一些不必要的問題發生，而且還能發現一些隱藏的問題，要知道改問題時需要花費很多時間和精力的，比如編碼和業務是有衝突的，本人有遇到過，**不能完全跟著業務走，業務也在適當的時候在滿足正常場景下根據編碼風格做適當的調整。最終達到一種整體和諧的一種美感。在編碼的前期要讓每乙個參與專案的人能夠清晰的知道我要做的是什麼，最終的目標是什麼樣的，我要關注的重點有些，還有哪些疑慮我需要討論或者解決的。準備工作做好後，對每乙個團隊成員專案的進度是非常清晰的。
2.技術框架的選擇
一般選擇技術架構有幾個衡量的點
第一點 效率：在開源領域能完成同乙個技術目標的框架是多個的，比如在web開發的，最終開發出來的產品是要經過效能這一關的，如果選擇有誤，整個軟體可以說是失敗的，因為不能用，你需要重新選擇技術框架，並且要從新讓每乙個開發者在新的框架上進行開發，這是在開發乙個新的軟體。
第二點 成本：第乙個是學習成本，第二個是經濟成本，只討論學習成本，因為本人非常反對使用商業軟體，把這筆買商用軟體的資金來激勵和培養員工效果會更好，這裡不做什麼討論，不是商業上的東西就很安全，開源的東西也很安全，只說一句：大部分情況都是浪費！關於學習成本要考慮到團隊實力和團隊人才培養方式，如果專案團隊沒有什麼培訓和學習氣氛，那麼這個團隊選擇框架的原則是非常簡單的，在這種情況下就選擇自己熟悉的能有把握的；還有一種情況就是團隊中有實力非常強的開發者或者學習能力非常強的開發者，那麼可以選擇一款相對最適合整體架構的新技術框架，並加以絕對重視，因為這是新的東西，風險也是非常高的，只要重視了，而且技術上可行的，結果是完美的；這是根據團隊的實際情況進行參考，勇氣也很重要。
第三點 穩定性：選擇乙個合適的軟體版本，個人比較傾向於在最新的平台和框架上進行開發，因為有新的特性，有可能心的版本有進行一些優化。
對穩定性的考慮，舉乙個例子，根據實際情況已經選擇要使用乙個a框架了，假設a框架有兩個版本，v1和v2，v1是穩定版本，v2還是測試版本，v2中新增了一些新的功能，而這些功能正好滿足你的專案需要，並且穩定版本是在你編碼完成前就會發布，那麼眼前有兩個選擇第乙個選擇，選擇v1版本並且要選擇乙個新的b框架來滿足專案需要，這種方式風險是最低的；第二種選擇，選擇v2測試版本，最終等到穩定版本發布後進行替換，這種方式也是可以選擇的，不過風險相對第一種選擇要高些，有乙個優勢就是這乙個框架就可以完全滿足你的專案需求，成本相對低一點。兩種情況我都有實踐過。
3.編碼
*編碼中需要注意的一些巨集觀問題
第一點：**風格。乙個年輕的團隊很容易遇到這個問題，乙個軟體開發完了，回頭去看裡面的**，編碼風格很不統一，有5個開發者就有5種**風格！怎麼樣避免這種情況，只能在編碼之前進行**編碼風格宣講和討論，把規則制定下來，大家按這種風格進行**編寫，還有一點要做的就是**檢視，不要因為忙而忽略這個，一周花乙個下午來看看別人的**，不僅能看到一些問題，而且還能看到自己的一些問題，當開發一段時間過去以後，**不斷的調整，最終的原始碼看上去就是乙個人完成的一樣！所以開工之前把這方面工作做好，事半功倍，後面還有很長的軟體維護工作要做，如果整體**一團糟，我想沒人願意去維護這麼糟糕的**。這樣的專案本人也遇到過，深有體會。
第二點：注釋。
比風格統一的更難的可能就是注釋了，我想你不會這麼認為，我也想自己這種認識是錯的，因為寫注釋這種活總比編碼要容易得多吧，不是這樣的，很多人應該都看過國內一些開源的程式設計師寫的開源軟體吧，很膜拜吧？呵呵，我也有看過，說下我的感受吧，首先**很少有注釋，乙個類檔案看下來只有**，注釋非常稀少，不知道他是怎麼想的，再簡單的**也要有方法和類注釋吧；其次，**裡面有稀疏的注釋，好不容易啊，結果是英文的，還有文件裡面都是英文的，乙個說中文的傢伙為什麼搞成英文版的呢。另外，列印日誌不加級別判斷，還有一些編碼問題在裡面。很想罵幾句，但是人家畢竟是開源的，不容易啊！ 精神可以鼓勵，但是態度值得懷疑。如果你現在剛編完**或者要開始編碼了，請把**寫好的同時把注釋寫好吧！如果乙個剛入門的程式設計師能直接通過注釋就能讀懂你的程式**，那麼你寫的注釋已經非常成功了。
第三點：**目錄結構。
這點和編碼風格是掛鉤的，也可以屬於**風格裡面的一部分，但是單獨拿出來肯定有獨特的含義。你有沒有想過或者遇到過通過**目錄結構就能夠大致看懂該專案是要做什麼，有哪些功能，如果看到這樣的工程是不是有一種很想再往裡面看的衝動？本人有參與這樣的專案編碼，當時我們做的還比較成功，剛開始做有點不習慣和編碼風格不同，關於**目錄結構我們進行了單獨的討論，根據本身的技術架構來制定的，把這點做好，開發者編寫**更加清晰了，效率也有所提高了，後期維護哪怕是新人來維護，只要稍微講講，也會很容易的接受，一切都變得更加簡單了。
第四點：命名。
這點也可以同屬於**風格。坦白講單獨拎出來說也沒有多大意思，因為**風格裡面就會強調，但是你不覺得這麼重要的東西很容易忽略嗎，比如大小寫，id我是寫id還是寫成id呢，沒有多少人會在意，只有出現問題了，**冗餘量增加了，才會發現，命名也是非常重要。還有一些，類檔案的命名詞不達意的，我想提醒你的是，既然這麼重要那麼請謹慎對你的**進行命名！
第五點：贊成有必要的重構。重構需要注意時機，有兩個點是最好進行重構了，第一點是在自己編寫完**以後進行優化和重構，轉測試之前；第二點就是當專案初期大家沒有意識到要去重構，也就是第一點沒有做充分，導致**重複率比較高等一些整體問題，在這種前提下找乙個時間段，對整體**進行一次重構計畫，這是有必要的。
第六點：一些提高**的工具使用。
有幾類工具，網上有很多資料，根據自己的語言進行選擇。
第一類：**自動檢視bug工具
第二類：**統計工具
第三類：**重複率和圈複雜度工具
第四類：**覆蓋率工具
第七點：不要隨意修改**，特別是別人的**
修改**應該是放在乙個時間段，而不是隨意進行修改，目前比較流行的敏捷開發中有乙個現象就是版本發布比較快比較多，修改**是有很大的風險的，修改的**很有可能是公共**，多處地方有呼叫，很有可能造成其他地方出問題，小問題解決，大問題來了。當需要修改其他開發人員的**時一定要和對方溝通下，避免造成不必要的誤會和引發潛在的問題。
*編碼中需要注意的一些微觀問題
這些就是編碼功底了，我自身的感受就是，要不斷的回頭看看自己的**，很多地方值得你重新思考和關注。
平時有時間可以靜下心來閱讀比較經典的書籍，看不懂或者不太記得沒有關係，重新再看。
4.測試
當然是編寫單元測試用例。盡量覆蓋每乙個場景，這對軟體質量起到乙個很關鍵的作用，你平時也不會老是收到測試人員的折磨，他其實也不想折磨你，因為這是他應該做的，測試人員也希望他測的功能問題比較少，問題多測試的工作量也會打起來，為了避免這些問題，開發能做的就是寫單元測試發現一些潛在的問題，把大部分的bug提前發現。從管理角度來講，測試也會輕鬆很多。開發一款相對完美的軟體絕對是乙個優秀程式設計師的追求。也是在程式設計師這條道路上的一筆收穫。
太陽系 -
軟體開發應該注意的細節
1.系統流程梳理 以乙個很簡單的例子來說明流程梳理對軟體開發的意義，比如你要進行一次演講，但是這次演講是即興的，你不是專業的即興演講家，那麼在沒有準備情況下，你要對著台下的人進行演講，這個時候你走上台去，腦子裡的東西還沒有形成有條理的演講內容，講完後台下的人都不知道你在講什麼，可能你自己都不知道你剛...
軟體開發應注意的細節 3 資料的統計
先舉乙個庫存的統計做為例子，在做庫存統計時，一般的做法是這樣的，先設計乙個庫存餘額表，所有與庫存相關的單據寫入庫存餘額表裡，在統計庫存時，從庫存餘額裡直接讀取，很多人覺得這樣做讀取庫存很快。不過，這樣做有個很麻煩的問題，就是有進資料不準確，而且軟體維護量很大。有幾個問題需要注意的 1 每一次進倉 銷...
元件化軟體開發細節記錄
公司從原來的軟體作坊模式轉型到元件化軟體模式已經有一年多了.在此記錄一下其中的細節 元件化微服務是把大的服務拆分成小的服務.類似於微服務的思想,元件化是把乙個大的web專案拆分成多個小的web專案.分為基礎元件和業務元件.基礎元件例如 postgresql,redis.activemq,ldap,t...