嘗試完成分配給我的一個需求，度過了糟糕的一天。了解了需求的邏輯，再對應(yīng)到代碼中去看，需求中只要添加一個地方，但小小的改動牽扯了一大片的邏輯。
當(dāng)開始接需求時候，我的吐槽也開始了。

需求文檔很重要

不熟悉每個字段的含義，對待許多個條件的判斷便無從下手。
以往接手的項目后端都會提供接口文檔，標(biāo)明字段的含義和包含的值。
看這這份文檔，再結(jié)合對應(yīng)代碼邏輯的判斷，便很快的進入熟悉的狀態(tài)，一個需求過后一部分功能就都很熟悉了。
但到了這里工作，文檔竟然不完善，也沒有人能完全把字段都說清楚，這就對閱讀邏輯增加了不少的難度，看了一天下來也是一臉懵逼。
他們之前在做項目時，加一個簡單的功能，只是返回一個字段而已，靠口口相傳字段的含義完成需求，懶得花時間去寫一個字段的含義到文檔中，因為太簡單，腦瓜子記得很清楚，便選擇忽略記在文檔的必要性。
經(jīng)過長年累月的迭代，字段越來越多，新的記得清楚，舊的早已淡忘，由于忽視了記錄，便忘記了很久之前的字段含義。更要命的是人員在流動，寫字段的人走了，接手的人成了接盤的俠，可以想象接盤俠是何等的抓耳撓腮卻無計可施，
望著一行行代碼，陷入了深深的煩惱中。
所以在做項目中，寫文檔至關(guān)重要。沒有文檔的記錄，看代碼，只能抓瞎。

加注釋有指導(dǎo)意義

項目代碼經(jīng)過幾個人的手，迭代了多個需求，代碼的可讀性已經(jīng)變得非常的差。
一個文件總共有4千行代碼，查看一個判斷，要從開始的200行，拉到中間的2000行，還要反復(fù)的拉上落下來確定邏輯的正確性，這簡直就是浪費時間。
一個判斷能超出一屏之外，還有很長，左右滑動記住來字段的名字，簡直就是反人類。就不能折行顯示，一眼掃下來全部在視線內(nèi)，不至于手滑的疼痛。
洋洋灑灑寫了很多行代碼，竟然沒有一句注釋，這留給后來人簡直就是噩夢，要一行一行的讀，多個判斷交織在一起，壓根都不知道是做什么用的。順手加行注釋的事，就是沒人去做
不要求每一行都加上，至少也要在一大塊寫點注釋。功在當(dāng)代，利在千秋呀！

代碼規(guī)范很重要

代碼風(fēng)格一點都不統(tǒng)一，大家都按照自己的喜好來寫代碼，有人喜歡加分號，有人不喜歡；有人喜歡等號兩邊空格，有人就喜歡不加空格；有人的縮進是4個，有人的縮進是2個；有人用N年前的技術(shù)手段，有人喜歡用最新的技術(shù)方案。這樣的代碼一眼就能看出來是經(jīng)歷了多人之手，風(fēng)格完全不一致。
這里沒有代碼規(guī)范一說，有檢測代碼的工具，卻是擺設(shè)，沒人使用，因為太嚴(yán)格，很多人不適應(yīng)，隨棄。
代碼風(fēng)格的好處是統(tǒng)一組員參差不齊的風(fēng)格，使之很多人寫出來就跟出自一人之手一樣。

所加入的團隊沒有做好接口文檔、注釋、代碼風(fēng)格統(tǒng)一，接手的人處在泥塘中苦苦掙扎著。