记一次中小公司的研发问题
作者：zollty，資深程序員和架構師，私底下是個愛折騰的技術極客，架構師社區合伙人！
一、一些不好的現狀，及對應的改進方法
1、前后端代碼綁定在一起，很難維護，前端UI做得太差，后端也需要大的改善。
????前端代碼亂，是架構和規范問題。
????前端UI做得太差、很掉檔次，是因為不夠重視和沒有專業的人來設計和制作。
????改進方法：
??? 1）前后端代碼分離，一些人做專業的前端，提高前端UI質量，一些人專注于后端優化。
??? 2）前期可以先重構，先從技術上把前端代碼和后端代碼分離，然后專注規范和優化前端（包括html、js和css），同時相應地簡單重構后端。
??? 3）后期劃分人員職責，前端代碼交由專門的前端開發工程師維護，新增的頁面功能修改也由前端開發人員編寫，后端只需要提供數據的接口。
前后端人員比例問題：
????對于一些小網站、內部系統，如果后臺并不復雜（通常比較獨立 幾乎不依賴其他系統，而且用戶不多），但前端功能、展現層的功能較多，那么前端的工作量會是后端的兩倍以上。
????這種情況，建議前端開發和后端開發的比例是 2:1，假設一個項目6個人，那么4個前端+2個后端。
????另外，針對這種系統，產品很重要，產品需要準確地給出需求，甚至給出功能的原型，如果界面要求高，可以配置專業的美工，否則前端可以直接根據產品的原型設計頁面UI。
????對于一些后端比較復雜的系統，比如分布式的大型網站，或者后端牽涉多個其他系統，對后端要求較高，則需要較多的后端開發。
????所以，前端和后端的人員比例，要看項目情況，是偏UI操作？還是偏后端技術？
????客戶的關注點是不是在UI上？如果是，那就得加強UI、UX的研發能力。
2、系統有很多明顯的BUG，有做過正規的測試嗎？
? ? 正式系統BUG多，是研發水平低的表現，顯得這個系統質量很差。
? ? 改進方法：正式投入運營的產品，要有質量保證，原則上要通過測試驗收，測試不通過不能上線。
????具體方案：
? ? 1）測試參與需求評審，測試參與產品評審；
? ? 2）測試前置（提前介入），必要時增加回歸測試，性能測試，安全測試。
? ? 3）測試監督、考核，質量保證。
3、產品水平低，很多地方設計不合理
? ? 如果產品設計不合理，那后果是最嚴重的：
要么考慮不全，做出來的東西無法滿足要求，甚至漏洞百出；
要么不切實際，實際開發過程中困難重重；
要么擴展性不好，導致后期增加、修改功能時必須得全部重做；
要么用戶體驗不好，被用戶吐槽 難以使用。
? ? 改進方法：（注意：下面描述了完整的產品環節，其他方面并不完整）
??? 1、需求收集階段，廣泛征求用戶意見，同時產品從專業角度和用戶溝通，要注意：很多用戶只顧自己，提出的需求有些是不合理的，需要產品人員去正確引導，有些需求是極其片面和個性化的，需要產品綜合考慮，有些需求是高難度的，需要從成本、時間、資源等多方面考慮。
??? 2、整理需求階段，將收集到的需求，轉換成專業的產品需求文檔，可以拿這份初步的產品需求文檔，請求資深產品人員、開發方的項目經理、測試經理給以評審和意見。最終形成較正式的產品需求文檔。
??? 3、產品設計階段，有了產品需求文檔之后，對產品進行詳細設計，最好是有可視化的產品原型，并對其中產品需求的細節進行清晰、準確的描述。做好之后，將產品需求和原型發送給資深產品、項目經理和測試經理審閱。
????4、項目經理和測試經理拿到產品需求和原型后，初步查閱，提前就不明白的地方與產品經理進行溝通，同時就一些技術問題或者業務問題與組內的開發和測試負責人初步商議。
????5、產品召開產品宣貫和評審會議，產品、相關開發人員、測試人員全部參加，產品負責對產品需求和原型進行講解說明，開發和測試一同討論。如果沒有重大修改，會后就一些小的修改項郵件確認即可。如果有重大修改，則產品修改后，找時間再次發起評審會議。
??? 6、項目經理、測試經理就產品需求進行開發、提前測試進行分工、排期，就完成時間節點與產品達成一致。
??? 7、開發完成后，提交測試版本，編寫提測文檔，交付測試。測試人員介入，驗證測試環境是否正常，對比開發的功能是否與需求一致，就不明之處，和開發進行溝通。溝通和初步驗證做完后，測試負責人發出接收測試的說明，并安排好測試人員，開始正式測試。同時，通知產品參加初步的驗證測試。
??? 8、每次提測之后修改BUG和優化代碼，均需升級測試版本，同時附上改動的影響范圍，通知測試人員。
??? 9、測試按實際情況可進行冒煙測試、第一、二輪測試、回歸測試、自動化測試、接口測試、UI測試、性能測試、壓力測試、安全測試。
??? 10、在臨近測試結束時，通知產品進行驗收測試。
??? 11、準備上線。
二、研發規范太差
?1、代碼不規范
解決方案：
????規范的代碼風格，代碼質量符合sonar里面的各種規則。
????使用sonar等平臺和插件自動掃描和判斷代碼質量。
2、提交到倉庫中的代碼無法正常編譯
????? 版本管理混亂
解決方案：
????規范源代碼的管理，提交的代碼需要有質量保障，主干（master）分支必須是時刻可用的。
????版本號管理需要規范。
3、Maven缺乏維護（public居然無只讀權限，導致無法構建項目）
???? 從這一點暴露出來的問題：基礎設施沒有專人長期維護！！
解決方案：
????嚴格保障基礎設施的正常運行，指定專人維護（可以是各個開發部門或者運維部門、測試部門的人），包括數據庫、jenkins、maven、sonar、redis等。
4、數據庫表設計不合理，甚至有些查詢需要聯合8個表，左連接、內連接一大堆。
???? SQL嚴重不符合規范，效率極低，查詢3條數據需要50秒鐘；可維護性極差，在SQL里面去做各種運算，使用了許多函數。
解決方案：
????增強數據庫的相關規范，架構評審，DBA評審，SQL評審。
????增強開發框架的約束能力，簡化SQL編寫并保證質量。
????使用SQL自動審核工具，例如 Inception。
????線上監控，慢查詢等。
三、架構能力不足
????項目的框架，項目A和B（真實名稱略）的都很一般，看得出來，搭框架的水平，差不多是高級工程師的水平。
????我不建議由 高級工程師 隨便搭一個框架。
????一個高級工程師搭的框架，能用，但可能并不好用，框架這東西，是項目的基礎，需要進一步優化。
????解決方案（一）：由資深工程師和架構師來選型和搭建，并經過評審和實際驗證，才開始規模使用。
????解決方案（二）：由基礎框架團隊（一個完整的、專業的團隊，包括前端、后端、產品、UI、測試）去開發和維護，這個團隊專注于框架的搭建和維護，公司或者部門都使用他們提供的技術體系和解決方案。
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
總結
以上是生活随笔為你收集整理的记一次中小公司的研发问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .NET Core 3.0稳定版发布
- 下一篇： 利用Helm简化Kubernetes应用