至今仍記得當(dāng)時在思沃學(xué)院聽到比較多的一句是：代碼要遵循單一職責(zé)庸推；函數(shù)不超過 15 行蒜茴；最大全復(fù)雜度 3骡显；文件最多多少行來著疆栏，記不清了曾掂。而這里我要說的是一個 64 行的 Api（長度還可以，畢竟項目比較大）壁顶，我看了一周珠洗。
說實話，我真的是不想再看這個 Api 了若专。
一開始領(lǐng)了一張卡根據(jù)控制臺找到了這個 Api许蓖，還有那么些許的開心，這么快就找到要寫代碼的地方了调衰。萬萬沒想到膊爪，我真的只是猜中了開頭，這個 Api 真的太強大了嚎莉。幾乎我所做的任何操作米酬，debug 都進入了這里。
遂找了個正在重構(gòu)這里的“老人”給我講了下這段代碼的大致功能趋箩。這真是不講不知道赃额，一講嚇一跳。這個 Api 可是項目最最核心的 Api 了叫确，沒辦法跳芳，這么多年，唯一會的也就是 Debug 了竹勉，反正就是不停的打斷點筛严，隨機看想看的值，就這么著饶米，終于在第三天完成了這張卡桨啃。天真的我以為我真的再也不用看這個 Api 了，事實證明檬输，再一次猜中了開頭......
接了個 BUG照瘾，又和這個 Api 有關(guān)，真的好想拒絕改這個 BUG丧慈，可是已經(jīng)接了析命，還是試試吧，不行再說逃默。
于是重新開始看這個 Api 了鹃愤。
第一天下午改 BUG 的時候，Team leader 不斷問我找到原因沒完域？只能無奈的說：“沒有”软吐。然后繼續(xù)通過 debug 來了解這個 Api 中調(diào)的各種 Service。
第二天開始各種問“前輩”吟税、QA 業(yè)務(wù)凹耙，以致于后來每次經(jīng)過“前輩”和 QA 旁邊的時候姿现，他們都以為我又要問這個 BUG 了。然而比較慶幸的是肖抱，終于經(jīng)過多番詢問找到了 BUG 的根本原因备典。隨即將這部分功能的流程圖畫了出來。還記得這天 Team Leader 告訴我意述，這部分的代碼你也看到了提佣，想改那么快是不可能的；他其實自己是能改出來的荤崇，就是想讓我鍛煉一下拌屏。
終于在今天寫了一個將近 1000 行的 Api Test 之后，再次通過各種 debug天试，總算改完了這個 BUG槐壳。你以為這就完了嗎然低？并沒有喜每，又掛了一批測試。
該修測試去了雳攘。
The End ~
21 天寫作訓(xùn)練带兜，第 15 天 ing
