好久沒有寫讀書筆記了，說來慚愧。最近一直在整理項目文檔交接的事，感覺智商不夠用。相信大家在理解別人寫的代碼的時候都有過這種經(jīng)歷，這塊邏輯在干嗎？這個算法解決了什么......一萬個為什么在腦海中閃過。
一般來說，代碼是對業(yè)務(wù)邏輯更高級的抽象描述。脫離實用場景和業(yè)務(wù)，代碼只是一堆沒有任何意義的散沙。那么在原有邏輯缺失，能不能從代碼中去推導(dǎo)出原有的業(yè)務(wù)邏輯呢？難，然而我正在接收這樣的考驗。
下面是我反推邏輯時產(chǎn)生的一些想法：
1.必要的注解還是很有必要的。代碼是凝聚了程序員的智慧。思想很抽象，每個人都有看問題的不同之處，當(dāng)然也就有不同的解決方案。怎樣幫助其他人更好的理解這塊邏輯，除非你們思考的一樣（哲學(xué)上說沒有兩片葉子相同）。雖然經(jīng)過大量的時間理解了寫的算法，并對作者的思維方式贊不絕口。可是換個角度這樣的時間成本是否值得？讀者又得到了什么？同樣場景下的同樣業(yè)務(wù)還會再次發(fā)生嗎？也許一個簡單的備注說明它處理什么，收效會好很多。
2.相信代碼中的存在即合理。程序中的每一行代碼都有存在的理由。對于沒有產(chǎn)生作用的代碼要及時的清理。就像建造一個大樓一樣，每塊磚都是一個必要的單元。多余的磚對于建造者來說無可厚非，不影響整體的穩(wěn)定，留著就留著。但是對于參觀者來說，那是不是藝術(shù)家故意為之的呢！為了增加美感而不能缺少的部分！當(dāng)我們很仔細(xì)的了解了那段代碼后，發(fā)現(xiàn)這部分在很長一段時間隨著業(yè)務(wù)的調(diào)整就棄用了，但是代碼保留了下來，這對于其他人來學(xué)習(xí)真是個悲傷的故事。及時clean code很有必要，讓每行代碼都有存在的依據(jù)。
3.文檔的更新。上面說到代碼依靠業(yè)務(wù)，業(yè)務(wù)需要文檔來進(jìn)行整理、存檔，保留智慧。然而在teamsite上發(fā)現(xiàn)的都是最新的業(yè)務(wù)解釋文檔。這一做法很好，很方便新的業(yè)務(wù)人員及時了解項目的進(jìn)展。但是對于開發(fā)人員來說，效果也許就沒那么好了。代碼是很容易看出歷史痕跡的。畢竟從文檔產(chǎn)生的第一天起，相關(guān)代碼就開始隨之生成。如果業(yè)務(wù)變化了，而相關(guān)代碼沒有及時的清理更新（在現(xiàn)實生活中很常見），歷史遺留的代碼就缺少了存在的依據(jù)。對于理解代碼的同學(xué)來說也是災(zāi)難性的打擊。那么有沒有方法避免呢？我想到的一個辦法就是讓文檔也具有歷史性，每有一次新的業(yè)務(wù)，就生成一個新的版本。v1、v2、v3......
4.及時請教當(dāng)事人。當(dāng)理解完一段代碼后，如果能找到當(dāng)時寫的人更好，找不到也要找找曾經(jīng)參與的人幫助你檢驗下你的理解是否正確，能不能簡單的還原出當(dāng)時的場景。一個人的理解能力畢竟有限，特別是在對業(yè)務(wù)不熟悉的情況下，很容易就走向偏路。及時的溝通，就像敏捷迭代那樣，真理也不是一個人慢慢的領(lǐng)悟出來的，都是在一次次的碰撞中形成的。
5.必要的流程圖釋義。對于一個細(xì)小的模塊，代碼足夠清晰，流程圖是沒有存在的必要的。但是對于一個大的業(yè)務(wù)流水線，流程圖就顯得至關(guān)重要了。制作工藝也是先有圖紙，要是看別人的代碼有指導(dǎo)性圖示解釋，想想都覺得很美好。
