首先,如何才能不寫爛代碼,這是改別人寫的代碼的前提.我截取 董偉明 寫的一篇文章,一段很好的話.
好的代碼是什么樣子的呢?
Bjarne Stroustrup(C++之父)說:
邏輯應該是清晰的,bug難以隱藏。
依賴最少,易于維護。
錯誤處理完全根據一個明確的策略。
性能接近最佳,避免代碼混亂和無原則的優(yōu)化。
整潔的代碼只做一件事。
Michael Feathers(《修改代碼的藝術》作者)說:
整潔的代碼看起來總是像很在乎代碼質量的人寫的。
沒有明顯的需要改善的地方。
代碼的作者似乎考慮到了所有的事情。
可以感受到,對好的代碼的理解有很多共通的地方:
代碼簡單,代碼意圖明確,其他人才容易與你協(xié)作。
可讀性和可維護性要高。
以最合適的方式解決問題。
和大家共勉,不要做別人嘴里的「蠢蛋」。
--- 分割線 ---
Python語言給外人第一印象就是簡單,上手快,有其他開發(fā)語言經驗的人一周就可上手工作,好像Python就是這么簡單似得。可是為啥合適的Python高級開發(fā)者這么難找?因為絕大多數開發(fā)者都止步于能完成工作這個程度,也就是我們經常自嘲的一個詞「碼農」。
不記得在哪里看過, 程序員有三種(我重新潤色了一下):
拿錢干活,不爽就換 - 程序員只是一份工作。
只要能實現(xiàn)功能就好,學習進步太累了。這年代做技術沒有管理掙錢多,技術搞得再好有什么用? 還不是買不起房啊。這年代關鍵是你認識多少人。你是不是有眼光去一個能上市會讓你暴富的公司,能不能唬住粉絲兒和投資人。
熱愛程序本身的人, 這些人可能只有1%, 他們有目標的寫程序, 他們愿意思考, 愿意聽取正確地/更好的方法, 他們會熱愛學習新的東西。
現(xiàn)在產品開發(fā)迭代非常快,一周要上多個版本,每天要提多個Pull Request,對于前2種人,只能疲于應付工作,怎么樣能在天賦不夠又不想多花時間進步的前提下完成工作,還能到領導的好評呢?這是一門藝術呢......
優(yōu)秀的工程師在思考、重構,「其他」工程師在給自己找理由:「怎么組織代碼、怎么提升運行效率、原理是什么」這些重要嗎?代碼能跑起來不就完了。需求這么多,做都做不完,哪有時間考慮怎么做得更好啊?
明年的今天「其他」工程師還寫一樣的代碼, 唯一不一樣的是Ta老了一歲。
對于這種「其他」工程師,我也確實沒有辦法,每個人有自己選擇生活和工作的權力,我絕對尊重,本文也不是給這些人看的。假如你不滿意現(xiàn)狀,希望做得更好,但是苦于不知道自己進階,我分享下自己的經驗。
多看書,多讀其他人的博客,閱讀優(yōu)秀的開源項目的代碼甚至語言本身的源代碼。這是一個長期的、瑣碎的、需要學習之后記憶和實踐的過程,看代碼要思考別人為什么這樣寫,組織結構為什么這樣用,這樣寫代碼為什么快。當然最重要的還是實踐。
想好了再開始寫。大家都知道,核心的、重要的系統(tǒng)的代碼上線后改動起來會很麻煩,非常有可能給未來留大坑,甚至于要耗費以年為單位的時間來填。所以前期的數據庫表結構設計、工程實現(xiàn)這些東西要先想清楚了再開始寫。
給自己提要求。實現(xiàn)過程中不斷的提高要求,這個要求就是比你現(xiàn)有的能力要高一點點。一段代碼寫出來的時候考慮一下會不會有比自己寫的好的方法,之前有沒有遇到過別人的實現(xiàn)借鑒下等等。
選擇更強的隊友。遇見什么樣的人,就會變成什么樣子的人。去一個身邊技術水平都比你爛甚至只是相當的環(huán)境,你能提高的空間非常有限。遇到一幫厲害的隊友,能幫助你坐上進階直通車,前提是你的心理素質要高,要不然長期的受到別人吐槽會產生大量不良情緒的。
對別人吐槽狠。這是我的個人秘笈。之前我寫代碼也沒有那么高的要求,后來在代碼評審的時候,我為了證明比人代碼寫的爛,不惜花費大量時間找各種證據吐槽別人(不能說人家寫的爛,但是又寫不出來更好的,做這種嘴炮啊),這個過程對我有極大的能力的提高,也包括搜索信息的能力。而且你吐槽了別人,別人正憋著勁還回來。你總不希望這件事發(fā)生吧,所以你只能讓自己的代碼寫的更好,這無形中讓你對自己的代碼要求要高了很多。