作者：zollty，資深程序員和架構(gòu)師，私底下是個(gè)愛折騰的技術(shù)極客，架構(gòu)師社區(qū)合伙人！

---

一、一些不好的現(xiàn)狀，及對應(yīng)的改進(jìn)方法

1、前后端代碼綁定在一起，很難維護(hù)，前端UI做得太差，后端也需要大的改善。

????前端代碼亂，是架構(gòu)和規(guī)范問題。

????前端UI做得太差、很掉檔次，是因?yàn)椴粔蛑匾暫蜎]有專業(yè)的人來設(shè)計(jì)和制作。

????改進(jìn)方法：

??? 1）前后端代碼分離，一些人做專業(yè)的前端，提高前端UI質(zhì)量，一些人專注于后端優(yōu)化。

??? 2）前期可以先重構(gòu)，先從技術(shù)上把前端代碼和后端代碼分離，然后專注規(guī)范和優(yōu)化前端（包括html、js和css），同時(shí)相應(yīng)地簡單重構(gòu)后端。

??? 3）后期劃分人員職責(zé)，前端代碼交由專門的前端開發(fā)工程師維護(hù)，新增的頁面功能修改也由前端開發(fā)人員編寫，后端只需要提供數(shù)據(jù)的接口。

前后端人員比例問題：

????對于一些小網(wǎng)站、內(nèi)部系統(tǒng)，如果后臺并不復(fù)雜（通常比較獨(dú)立 幾乎不依賴其他系統(tǒng)，而且用戶不多），但前端功能、展現(xiàn)層的功能較多，那么前端的工作量會是后端的兩倍以上。

????這種情況，建議前端開發(fā)和后端開發(fā)的比例是 2:1，假設(shè)一個(gè)項(xiàng)目6個(gè)人，那么4個(gè)前端+2個(gè)后端。

????另外，針對這種系統(tǒng)，產(chǎn)品很重要，產(chǎn)品需要準(zhǔn)確地給出需求，甚至給出功能的原型，如果界面要求高，可以配置專業(yè)的美工，否則前端可以直接根據(jù)產(chǎn)品的原型設(shè)計(jì)頁面UI。

????對于一些后端比較復(fù)雜的系統(tǒng)，比如分布式的大型網(wǎng)站，或者后端牽涉多個(gè)其他系統(tǒng)，對后端要求較高，則需要較多的后端開發(fā)。

????所以，前端和后端的人員比例，要看項(xiàng)目情況，是偏UI操作？還是偏后端技術(shù)？

????客戶的關(guān)注點(diǎn)是不是在UI上？如果是，那就得加強(qiáng)UI、UX的研發(fā)能力。

2、系統(tǒng)有很多明顯的BUG，有做過正規(guī)的測試嗎？

? ? 正式系統(tǒng)BUG多，是研發(fā)水平低的表現(xiàn)，顯得這個(gè)系統(tǒng)質(zhì)量很差。

? ? 改進(jìn)方法：正式投入運(yùn)營的產(chǎn)品，要有質(zhì)量保證，原則上要通過測試驗(yàn)收，測試不通過不能上線。

????具體方案：

? ? 1）測試參與需求評審，測試參與產(chǎn)品評審；

? ? 2）測試前置（提前介入），必要時(shí)增加回歸測試，性能測試，安全測試。

? ? 3）測試監(jiān)督、考核，質(zhì)量保證。

3、產(chǎn)品水平低，很多地方設(shè)計(jì)不合理

? ? 如果產(chǎn)品設(shè)計(jì)不合理，那后果是最嚴(yán)重的：

• 要么考慮不全，做出來的東西無法滿足要求，甚至漏洞百出；

• 要么不切實(shí)際，實(shí)際開發(fā)過程中困難重重；

• 要么擴(kuò)展性不好，導(dǎo)致后期增加、修改功能時(shí)必須得全部重做；

• 要么用戶體驗(yàn)不好，被用戶吐槽 難以使用。

? ? 改進(jìn)方法：（注意：下面描述了完整的產(chǎn)品環(huán)節(jié)，其他方面并不完整）

??? 1、需求收集階段，廣泛征求用戶意見，同時(shí)產(chǎn)品從專業(yè)角度和用戶溝通，要注意：很多用戶只顧自己，提出的需求有些是不合理的，需要產(chǎn)品人員去正確引導(dǎo)，有些需求是極其片面和個(gè)性化的，需要產(chǎn)品綜合考慮，有些需求是高難度的，需要從成本、時(shí)間、資源等多方面考慮。

??? 2、整理需求階段，將收集到的需求，轉(zhuǎn)換成專業(yè)的產(chǎn)品需求文檔，可以拿這份初步的產(chǎn)品需求文檔，請求資深產(chǎn)品人員、開發(fā)方的項(xiàng)目經(jīng)理、測試經(jīng)理給以評審和意見。最終形成較正式的產(chǎn)品需求文檔。

??? 3、產(chǎn)品設(shè)計(jì)階段，有了產(chǎn)品需求文檔之后，對產(chǎn)品進(jìn)行詳細(xì)設(shè)計(jì)，最好是有可視化的產(chǎn)品原型，并對其中產(chǎn)品需求的細(xì)節(jié)進(jìn)行清晰、準(zhǔn)確的描述。做好之后，將產(chǎn)品需求和原型發(fā)送給資深產(chǎn)品、項(xiàng)目經(jīng)理和測試經(jīng)理審閱。

????4、項(xiàng)目經(jīng)理和測試經(jīng)理拿到產(chǎn)品需求和原型后，初步查閱，提前就不明白的地方與產(chǎn)品經(jīng)理進(jìn)行溝通，同時(shí)就一些技術(shù)問題或者業(yè)務(wù)問題與組內(nèi)的開發(fā)和測試負(fù)責(zé)人初步商議。

????5、產(chǎn)品召開產(chǎn)品宣貫和評審會議，產(chǎn)品、相關(guān)開發(fā)人員、測試人員全部參加，產(chǎn)品負(fù)責(zé)對產(chǎn)品需求和原型進(jìn)行講解說明，開發(fā)和測試一同討論。如果沒有重大修改，會后就一些小的修改項(xiàng)郵件確認(rèn)即可。如果有重大修改，則產(chǎn)品修改后，找時(shí)間再次發(fā)起評審會議。

??? 6、項(xiàng)目經(jīng)理、測試經(jīng)理就產(chǎn)品需求進(jìn)行開發(fā)、提前測試進(jìn)行分工、排期，就完成時(shí)間節(jié)點(diǎn)與產(chǎn)品達(dá)成一致。

??? 7、開發(fā)完成后，提交測試版本，編寫提測文檔，交付測試。測試人員介入，驗(yàn)證測試環(huán)境是否正常，對比開發(fā)的功能是否與需求一致，就不明之處，和開發(fā)進(jìn)行溝通。溝通和初步驗(yàn)證做完后，測試負(fù)責(zé)人發(fā)出接收測試的說明，并安排好測試人員，開始正式測試。同時(shí)，通知產(chǎn)品參加初步的驗(yàn)證測試。

??? 8、每次提測之后修改BUG和優(yōu)化代碼，均需升級測試版本，同時(shí)附上改動的影響范圍，通知測試人員。

??? 9、測試按實(shí)際情況可進(jìn)行冒煙測試、第一、二輪測試、回歸測試、自動化測試、接口測試、UI測試、性能測試、壓力測試、安全測試。

??? 10、在臨近測試結(jié)束時(shí)，通知產(chǎn)品進(jìn)行驗(yàn)收測試。

??? 11、準(zhǔn)備上線。

二、研發(fā)規(guī)范太差

?1、代碼不規(guī)范

解決方案：

????規(guī)范的代碼風(fēng)格，代碼質(zhì)量符合sonar里面的各種規(guī)則。

????使用sonar等平臺和插件自動掃描和判斷代碼質(zhì)量。

2、提交到倉庫中的代碼無法正常編譯

????? 版本管理混亂

解決方案：

????規(guī)范源代碼的管理，提交的代碼需要有質(zhì)量保障，主干（master）分支必須是時(shí)刻可用的。

????版本號管理需要規(guī)范。

3、Maven缺乏維護(hù)（public居然無只讀權(quán)限，導(dǎo)致無法構(gòu)建項(xiàng)目）

???? 從這一點(diǎn)暴露出來的問題：基礎(chǔ)設(shè)施沒有專人長期維護(hù)！！

解決方案：

????嚴(yán)格保障基礎(chǔ)設(shè)施的正常運(yùn)行，指定專人維護(hù)（可以是各個(gè)開發(fā)部門或者運(yùn)維部門、測試部門的人），包括數(shù)據(jù)庫、jenkins、maven、sonar、redis等。

4、數(shù)據(jù)庫表設(shè)計(jì)不合理，甚至有些查詢需要聯(lián)合8個(gè)表，左連接、內(nèi)連接一大堆。

???? SQL嚴(yán)重不符合規(guī)范，效率極低，查詢3條數(shù)據(jù)需要50秒鐘；可維護(hù)性極差，在SQL里面去做各種運(yùn)算，使用了許多函數(shù)。

解決方案：

????增強(qiáng)數(shù)據(jù)庫的相關(guān)規(guī)范，架構(gòu)評審，DBA評審，SQL評審。

????增強(qiáng)開發(fā)框架的約束能力，簡化SQL編寫并保證質(zhì)量。

????使用SQL自動審核工具，例如 Inception。

????線上監(jiān)控，慢查詢等。

三、架構(gòu)能力不足

????項(xiàng)目的框架，項(xiàng)目A和B（真實(shí)名稱略）的都很一般，看得出來，搭框架的水平，差不多是高級工程師的水平。

????我不建議由 高級工程師 隨便搭一個(gè)框架。

????一個(gè)高級工程師搭的框架，能用，但可能并不好用，框架這東西，是項(xiàng)目的基礎(chǔ)，需要進(jìn)一步優(yōu)化。

????解決方案（一）：由資深工程師和架構(gòu)師來選型和搭建，并經(jīng)過評審和實(shí)際驗(yàn)證，才開始規(guī)模使用。

????解決方案（二）：由基礎(chǔ)框架團(tuán)隊(duì)（一個(gè)完整的、專業(yè)的團(tuán)隊(duì)，包括前端、后端、產(chǎn)品、UI、測試）去開發(fā)和維護(hù)，這個(gè)團(tuán)隊(duì)專注于框架的搭建和維護(hù)，公司或者部門都使用他們提供的技術(shù)體系和解決方案。

長按訂閱更多精彩▼

如有收獲，點(diǎn)個(gè)在看，誠摯感謝

總結(jié)

以上是生活随笔為你收集整理的记一次中小公司的研发问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。