略談為什麼要重視文檔寫作

一、背景

今天在知乎上看到一篇《作為IT行業過來人，你有什麼話想對後輩說的？》問題的答案，其中一小段摘錄如下：

非常值得在這裡給大家分享一下。

二、感悟

2.1 親身體會

見過很多剛畢業的同學缺乏工作經驗又急于表現，為了盡快做完項目，在沒有了解清楚相關背景和價值，沒有做好完整的技術方案時，就着急開始編碼。導緻很多項目後面會有推倒重來的情況，也沒有充分自測的意識，導緻項目品質也不是很高。

這或許就是所謂的“欲速則不達”吧。

2.2 重視設計

這裡所說的寫文檔更準确說應該是編寫技術方案文檔。

在技術方案文檔中，将業務邏輯梳理清楚，設計好核心功能的技術實作，梳理好依賴的接口，畫清楚系統之間、接口之間的調用關系，考慮清楚各種異常場景等。

然後對技術方案進行評審，讓其他經驗豐富或者了解該塊業務的同僚提提建議，對方案進行優化。

當技術方案設計清楚并評審通過，然後再編碼，心裡就會非常有底。

方案設計合理，編碼隻是一個時間問題。

如果編碼完成後能進行充分自測，并進行代碼評審，那麼項目品質應該不會出現大問題。

2.3 百分比問題

文中提到，設計應該花 80% 的時間，編碼和調試應該花 20% 的時間。

我不是特别認同這個百分比，實際工作中，比如10天編碼的項目，可能要2-3天熟悉需求，然後進行技術方案設計。

如果把這個百分比當做是重要性我道是更傾向于認同。

大家要抓住重點，文章想表達的是技術方案設計的重要性。

三、總結

本文雖然内容不多，但在此呼籲大家在動手之前一定将核心的邏輯，核心的方案想清楚，盡可能落到文檔中。

在項目編碼完成之後，一定要自己先自測，自己先審查一下自己的代碼，然後再提測。

在提測期間，強烈推薦通過 tail -f  error.log  或者其他方式随時觀察錯誤日志，項目相關問題早點修複掉，而不是等測試找到你再去改。

這種意識非常重要，希望剛工作不久的同學一定要重視。

PS: 改天有時間我會寫一下如何寫技術方案，如何寫提測文檔。