本文轉載自：純乾貨丨18個軟件開發常見問題及解決策略，你有遇到嗎？
No.1
每次看這些架構的思想方法的時候，總是和實際的應用沒能很好的結合起來，原因是不是架構設計的實踐不夠？或者是對各種實現的分析和思考太少？
我覺得不僅要有架構實踐，還要有不同場景的實踐。
舉個例子來說，你平時做企業應用架構，沒什麼流量，沒多少數據，複雜的地方都在業務邏輯，這時候你去看那些講大數據、講高併發的文章，很難帶入到場景去。
還有就是一些架構，不自己搭一遍是很難了解其中的優缺點的，這也是另一個原因。
可以考慮有機會自己嘗試，把看到的一些好的架構用一個原型程序搭一遍，造一點數據出來，用工具壓測一下，這樣會更有感覺。
和實際應用想結合的問題，一方面說明你現有的架構可能並沒有什麼大問題，沒有那麼迫切的需求要改造；另一方面可能還是因爲缺少實踐經驗，心裏沒底，不知道真用上了有沒有用。
No.2
比較規範的文檔有哪些，他們功能分別是什麼？
對於瀑布模型，每個階段結束後，都有相應的驗收文檔，而敏捷開發則沒有那麼多硬性的要求，而是根據項目需要，寫必要的文檔。
有些團隊對於測試階段，會有測試用例文檔、測試驗收報告，發佈前還會有部署文檔、維護手冊，但現在這類文檔基本上被測試工具、部署腳本替代了，也沒有什麼存在必要。
我覺得項目中必要的文檔，主要包括這幾類：
- 設計類文檔：這類文檔主要用來說明、討論需求設計、架構設計，可以用來了解、討論和評審，以及記錄後續結果。
- 說明類文檔：這類文檔用來對規範、API、配置、操作等做說明，便於規範和統一。
- 報告類文檔：對事情結果的報告和說明，比如說驗收報告、故障報告、調研等。
而這些文檔的價值，在於幫助成員瞭解設計、參與討論，記錄項目成果，減少溝通成本。重要的不是文檔多豐富，而是這些文檔有沒有價值，你能不能及時通過這些文檔得到想要的答案。
所以你也可以對照一下你的項目中，現在的文檔有哪些地方是可以簡化的，哪些地方是要增強的。
比如說，概要設計 / 接口設計 / 詳細設計是不是可以適當合併，減輕文檔工作？PRD 是不是夠詳細？會不會引起歧義不容易理解，要不要增加原型設計文檔輔助？
No.3
項目團隊的開發人員，基本都是從外包公司臨時找的，水平參差不齊，穩定性差，因此技術選型更多考慮技術的普及度的和是否容易學習掌握，從這方面看基本不太可能選擇比較小衆、但在特定領域很高效的技術。
加上是企業內部管理的系統，數據量和用戶數量可控，因此存在技術瓶頸的可能性很小，綜合下來看，最好的選擇就是最成熟和通用的技術，比如說選擇 java 技術棧，web 開發的ssm 框架等，但這樣長遠看團隊和個人的技術能力很難提升，請問老師在這方面有什麼建議？
我覺得團隊的技術提升和項目的技術選型要分開，不要總想着兩個都兼顧，優先保證好項目穩定、低成本運行。
技術提升這種事，需要讓一部分人先成長起來，然後帶動其他人。我自己工作之外會做一些業餘項目，然後在這些項目中體驗新的技術，體會其中優缺點，然後再逐步應用到工作的項目中，傳授給同事們。
我也鼓勵其他同事這麼做，去做一點自己的項目。但工作中的項目，我是很保守的。
No.4
對於開源技術方面，有沒有什麼經驗來指導選型？
答：開源技術選型，我的經驗一般是這樣的。
- 先找朋友推薦，少走一點彎路。
- 沒有推薦的話，就去網上搜索，找幾個滿足需求的備選。
- 對比以下幾個指標：
- 代碼質量、有無測試；
- 文檔健全度；
- 看 Issue 處理情況、最後更新時間（無人維護的項目後續恐怕有問題都沒法解決）；
- 看 Star 數量，通過 Google 和 StackOverflow 看使用情況。
- 自己按照說明試試看。
No.5
有沒有什麼大的原則可以指導技術選型？比如技術成熟度等？
我認爲在滿足設計目標的前提下，大的原則還是在於項目約束，尤其是成本和時間，然後就是看技術可行性和風險是不是可控，其他看團隊風格，有的偏保守有的追新。
比如說我自己的原則：
- 成熟的好過新酷的；
- 流行的好過小衆的；
- 團隊熟悉的好過陌生的；
- 簡單的好過複雜的；
- 開源的好過商業的（有時候也視情況而定）。
No.6
有着正常職位或頭銜的架構師，對一個全新的項目理解產品需求後進行架構設計，一般會產出哪些“東西”，來滿足後續的架構講解和項目開發過程中的溝通？
互聯網產品特點是用戶多，企業產品特點是業務複雜，所以架構的側重點不一樣。
架構師在架構設計後，產出首先是架構設計文檔，讓大家理解架構。然後還要寫架構開發的文檔，比如如何基於這個架構開發功能模塊，有哪些公共 API 可以調用，怎麼樣是最佳實踐，要遵守哪些規範等。
再要幫助搭腳手架和基礎模塊或示例項目，也就是要搭建一個最基礎的可運行項目，通過這個項目，大家可以直觀地理解你的架構是怎麼落地的，通過基礎模塊或者示例項目，可以知道如何基於框架開發，後面就也可以照葫蘆畫瓢照着實現。
還有就是在開發過程中，要答疑、解決架構中存在的問題，對架構做優化，還要做代碼審查，對於不符合架構規範的地方要指出和修正。
No.7
互聯網架構，要考慮互聯網很快的迭代速度，所以對於擴展等特別注意。企業架構，內部 IT 系統相對穩定，對比互聯網架構，更簡單？
挺好的分析。幫你補充幾點：互聯網架構不僅迭代會快一些，用戶規模通常更大，但業務也會單一些；企業應用通常業務比較複雜，尤其是和行業會有一些結合，但是用戶規模要小很多。這些特點，都會影響架構設計的選擇。
No.8
老師能不能具體講講重構有哪些原則和要注意的地方，感覺一直得不到要領。
重構的要領我覺得兩點。
第一：你要先寫一部分自動化測試代碼，保證重構後這些測試代碼能幫助你檢測出來問題；
第二：在重構模塊的時候，老的代碼先保留，寫新的代碼，然後指向新代碼，或者用特定開關控制新舊代碼的指向（這樣上線後可以自己先測試，有問題也可以及時關閉），然後讓自動化測試通過，再部署測試，新代碼沒問題了，刪除舊代碼。
No.9
有沒有事情管理的工具？因爲如果不記錄下來，一會兒就忘記了。
我個人的話，一般就用系統自帶的記事本記一下，或者貼一個便籤紙在顯示器。如果時間跨度長，我就記到 Calendars 上，加上提醒。工作中的任務，我則會創建成 Ticket。
No.10
現在還有一種說法：提倡基於主分支開發，效率更高；而不是您提到的每人基於自己的分支開發完再合併回主分支。您怎麼看待這個問題？
我認爲對於軟件工程來說，很多問題，並不是只有唯一解，即使是最佳實踐，也得看適用的場景和團隊。
無論是基於主幹還是分支開發，有兩點需要注意的：
- 就是一定要有一個穩定的分支，可以隨時發佈的那種，至於是叫 master 還是叫 release並不重要。
- 合併之前要有代碼審查和自動化測試（配合 CI）。
上面兩點纔是核心。
No.11
如果一個項目有 5 個開發做，持續集成怎麼保證不亂？比如開發 A 剛剛修復的bug1，開發 B 把自己修復的 bug2 上傳，之前的代碼 bug1 沒修復，怎麼辦？如果採用分支怎麼合併？如果是直接更新 master 分支，那 A 不是白做了？
要注意是“合併”而不是“覆蓋”。比如說 bug1 涉及 file1 和 file3 的修改，那麼開發 A 合併的時候只合並 file1 和 file3。
等到開發 B 修復了 bug2，修改了 file1 和 file2，file2 直接合並，file1 需要手動去修復合併衝突才能合併。
每個人開發之前，都會從 master 獲取最新版本，合併的時候，如果出現衝突，要先解決衝突才能合併進去。這些其實應該自己去動手試試，會體會更深刻。
No.12
在微服務架構中，一個服務在測試環境的交付驗證，往往還依賴於其他相關服務的新版本，導致新的 feature 很難獨立的交付。對於這種情況，有什麼好的方法嗎？
我覺得對於大部分時候，微服務之間應該是獨立的，而不是依賴過於緊密，如果每一個新功能都會這樣，那架構設計一定是有問題的，需要重新思考服務劃分的合理性。
但你需要有更多上線或者場景我才能針對性提出一些意見。對於有一些確實需要跨服務合作的大 Feature，這樣也是正常的，就是需要一起協作，實現商量好通信協議，分頭開發，再聯調。
No.13
團隊成員的能力和素質參差不齊，如何有效的去組織和管理項目的自動化測試，自動化集成？
首先，你要先搭建好自動化測試環境，讓自動化測試代碼能跑起來，最好要和CI（持續集成工具）整合在一起，每次提交代碼 CI 都會跑自動測試，然後能看到運行結果。
然後，把自動化測試作爲開發流程的一部分，比如說要代碼審查和自動化測試通過後才能合併代碼。這部分工作如果和 CI 集成會容易很多。
再有就是要培訓，比如遇到不會寫的，開始先帶着他寫幾個，確保他學會了自己能寫，然後下次代碼審查的時候，看到缺了就要求補上，還不會就繼續教，來不及寫的就創建個Ticket 跟蹤起來。
簡單來說，就是代碼審查 +CI+ 培訓。
No.14
各種類型的測試覆蓋率你們一般採用什麼指標？個人感覺在理想的情況下最好是做到百分百覆蓋率。
100% 覆蓋，這個我覺得可以作爲一種理想追求，但是沒必要追求極致，還是要在進度和質量之間有個平衡比較好，畢竟進度也很重要。
另外對於前端業務，我更重視集成測試的覆蓋，對於主要業務場景集成測試覆蓋到位後，單元測試也就有比較多的覆蓋，相對性價比更高，然後再逐步補充單元測試的覆蓋率。
No.15
持續集成怎麼理解呢？我看知乎上說，有的團隊成員在一天內多次進行編譯，發佈或自動化測試。
狹義的持續集成不包括髮布，主要指集成，持續的（每次提交代碼變更都觸發，頻繁地提交）對代碼進行集成（合併到主幹），但集成前要確保自動化測試通過。廣義的持續集成還包括部署，也就是集成後自動部署測試環境 (持續交付) 或者生產環境（持續部署）。
No.16
請問下有沒有介紹開發如何寫好測試不錯的書？
推薦：《how we test software at microsoft》中文版《微軟的軟件測試之道》。不過沒有書其實你也可以找到很多資料的。比如我平時寫前端程序，那麼我會去 GitHub或者 Google，通過關鍵字、語言找跟我項目類似的開源項目，然後看其中有沒有自動化測試寫得好的。
找到了 (例如：reactstrap、electron-react-boilerplate、kitematic) 就照葫蘆畫瓢好了，因爲都是真實項目，所以特別簡單有效，建議你也可以試試。
另外耐心一點，你也可以看到很多關於測試知識分享的技術文章，多看一看也有收穫。
No.17
代碼審覈是純手工做的嗎？沒有好的工具？
代碼審查可以參考 GitHub 上一些開源項目的 PR Review，通常網頁上可以清楚地標記出代碼修改，針對代碼行可以寫 Review 的評論，這就已經很方便了。
其他工具主要是 Lint 檢查代碼規範、語法錯誤等，這個一般在 CI 裏面就集成了。
No.18
有沒有比較齊全的後端Java開發面試題呀？最近想跳槽了
有的，針對後端Java程序員，小編這邊準備了Java基礎知識、Dubbo、異常、JVM、容器、Linux、Mybatis、MySQL、Netty、Redis、Spring、Spring Boot、Spring Cloud、Spring MVC、Tomcat、Zookeeper、併發編程、消息中間件面試專題PDF文檔，以及一份《技術面試需要掌握的基礎知識整理》，足夠面對80%以上的Java技術面試。
技術面試題有了，HR面試題也不可少，小編這邊收集了《70道Hr面試題大全》
