最近公司的一個大項目進入了收尾階段,于是乎抽一點時間來寫些東西,也許這篇文章中的一些點,你也曾經歷過?也許你正在經歷,又或者你也在做著同樣的事兒,不管如何,希望能對大家有一點的幫助。

項目概況

項目是一個資管類的平臺,重構的一個版本,全部都是新代碼,整個項目投入了大概10個前端,20個后端左右的資源,工程量還是蠻大的,前后做了大概3個月。前后比率大概是1:2。

人員狀況

據小呆了解,團隊成員的平均工作年限在5-8年左右,最低也是3年的工作年限。按理來說,這樣的配置,應該算是中高配了,可是項目開始之后發生的事情,讓小呆開始懷疑人生。

問題暴露

1.項目結構

搭建過項目的小伙伴一定知道,項目的結構一定程度上決定著代碼文件的層次度和清晰度??墑竊謖庖豢嫉牡鼗廈?,就讓小呆大吃一驚。由于項目采用vue-cli生成,所以只需要在生成項目的結構上面稍加梳理,就是一個比較完善清晰的目錄??墑俏頤塹慕峁廣妒僑瞇〈艟裊訟擄?。

├── src
│   ├── components  ---組件目錄
│        ├── base ---基礎組件庫
│        ├── bpm ---項目文件夾組件庫
│             ├── list --- 列表頁組件
│                  ├── card --- card組件目錄
│                  ├── card.vue --- card組件文件
│   ├── view --- 頁面目錄
│        ├── bpm ---項目頁面目錄
│             ├── list --- 列表頁目錄
│                  ├── style --- 列表頁樣式目錄
│                  ├── list.vue --- 列表頁文件

小呆提出的目錄結構如上圖所示,組件與頁面一一對應,比較容易找。大家也欣然接受,可是大家在建各種負責的??檳柯際?,變成了這樣(因為沒有統一的前端負責人)。

├── src
│   ├── components  ---組件目錄
│        ├── metaData ---項目文件夾組件庫
│             ├── list --- 列表頁組件
│                  ├── components --- 已經不知道是什么了(下面還有好多層)
│        ├── bpm ---項目文件夾組件庫
│             ├── list --- 列表頁組件
│                  ├── card --- card組件目錄
│                  ├── card.vue --- card組件文件
│   ├── view --- 頁面目錄
│        ├── bpm ---項目頁面目錄
│             ├── list --- 列表頁目錄
│                  ├── components --- 已經不知道是什么了(下面還有好多層)
│                  ├── style --- 列表頁樣式目錄
│                  ├── list.vue --- 列表頁文件

這還僅僅是頁面與組件的關系,就已經讓人摸不著頭腦了,別提其他的??榱?。每個人都在按照自己的想法隨意的建立目錄,也為后來的開發挖了大坑。

注釋問題

關于注釋的問題,長久以來都爭論不休,有人說寫注釋,方便自己,也方便他人,有人說,寫注釋占用大量資源,沒有注釋的代碼才是好代碼。于是乎,我們的代碼變成了如下兩派:

注釋派(小呆屬于這一派)
注釋派

無注釋派
注釋派

可能小呆截得這幾段代碼還比較基礎,有人會說有沒有注釋影響不大,但是如果一個組件的props傳了10幾個參數,每個參數都是一個對象,一個組件的方法有1000多行,同時引用了components的組件,和這個組件目錄下的components的組件以及其他組件時,讓你去改或者增加一個功能,我相信你會有打死這個不寫注釋的人的想法。(而我們寫注釋和不寫注釋的人是3:7)

接口文檔

接口文檔,相信大家應該都不陌生,在我前端的生涯當中,見過的接口文檔大多都是這樣的:
正常的

而這個項目的接口文檔是這樣的:
非正常的
非正常的

更有甚者,直接貼了一段Java代碼,讓我看著Java代碼自己寫,這里就不貼了。

你告訴我怎么調,后端美其名曰開發任務重,沒時間寫接口文檔,自己猜+試去吧,掀桌(╯°Д°)╯︵ ┻━┻,這樣的后果也導致了對接+調試接口時,花費了大量的時間(我們JAVA架構師,改一個查詢列表的接口,改了3天,后續這位大佬在接口已經調試完畢,測試完畢之后,把接口返回數據和接口傳參又先后改了7遍,前后用時半個月)導致之后每次小呆跟這位大佬調試接口都瑟瑟發抖。

溝通交流

如果以上幾點,你都能接受的話,那么最后這一點,我覺得你可能會改變你的看法。小呆在跟一個后端妹子對接接口的時候,接口報錯,并且小呆已經確定是后端的問題了,釘釘對方,一直不回消息。等小呆把其他功能都做完,就差這個接口之后,跑到妹子面前說,你這個接口報錯,發你消息也沒回,幫忙看看唄,調試一下。

妹子冷冷的看了我一眼,然后手指在鍵盤上敲了幾下,回了我一句:我本地沒問題,然后就視我為空氣了。最后找了他組長,他組長幫她改了代碼,直接跟他組長對接了…

復盤

其實這些問題,在小呆看來根本就不是什么大問題,都是壞習慣所導致的。只不過小呆之前的公司,同事配合和寫代碼都有比較好的習慣,而且大家都很自覺,所以一直以為這些都應該是業界標配,從來沒發生過這種情況。結果來了這個項目當中,才讓小呆知道什么叫驚呆了下巴。

項目結構和代碼注釋的問題,完全可以通過自覺和強制的形式避免掉,可能大家之前在各自的公司配合的比較少,所以導致在這種多人協作的項目中,依舊延續了之前獨樹一幟的習慣,導致項目變得亂七八糟。

而后端依賴程序自動生成接口文檔本來是一件高效省時的方式,但是因為比較懶,又不愿意寫注釋,導致浪費了前端大量的開發時間。這種開發方式,萬萬不可取,極易產生口頭及肢體沖突。

溝通交流本來是促進協作的一件事,結果因為本地環境是好的,就不管測試環境和開發環境的好壞,說白了還是懶在作祟。

雖然接下來的很長一段時間里,小呆都會處在這種狀態下工作(總監離職,群龍無首),但是還是希望看到這篇文章的小伙伴們,能夠嚴于律己,方便他人,養成良好的寫代碼和溝通的習慣。