1. 程式人生 > >掌握“複製-貼上-改”的IT技能

掌握“複製-貼上-改”的IT技能

“Stop Trying to Reinvent the Wheel(不要重複造輪子 )”, 可能是每個程式設計師入行被告知的第一條準則。在公司裡面,我也會對團隊裡面每個新進的成員反覆灌輸這個理念。但要真正做到這一點也非易事。

尋找輪子

所謂“輪子”可以理解為行業裡面的技術解決方案。特別是當今開源社群的盛行,開源軟體以及開源技術方案層出不窮,這為尋找輪子提供了豐富的途徑。

避免重複造輪子

一個輪子能夠個被複用,體現了軟體的複用性。

使用輪子,本身就是“站在巨人的肩膀上”,最大化享受當今技術所帶來的便利,避免了從零開始開發的繁瑣以及複雜,有效降低成本。

以ORM框架為例,在Java鄰域,真正做到強大的唯有Hibernate幾家,一方面,開發如何自己來實現ORM在技術有一定的難度,另一方面,開發自己的ORM需要很多的人力以及技術投入,一般的小公司根本沒有能力來做這方面的研發。

以 GNU/Linux 作業系統為例,如果不是 Linux 作為作業系統核心,提供給了 GNU 計劃,那麼 GNU 也許不知道要延遲多少年才能推出自己的作業系統;另一方面,GNU 計劃,提供了很多 GNU/Linux 作業系統的生態軟體,讓 GNU/Linux 作業系統更為普通使用者所接受。

輪子難找

因為選擇很多,所以很難選。目前,軟體行業空前發展,以分散式訊息服務框架,光開源的產品就有很多,包括Apache ActiveMQ、RabbitMQ、Apache Kafka、Apache RocketMQ等。這就對個人的資訊檢索能力有非常高的要求。同時,也正因為有很多選擇性,這也對使用者各種技術要有一定的瞭解,各種技術的優缺點要了如指掌,才能做出合理的選擇。這對於使用者的技術要有很高的要求。老衛的《分散式系統常用技術及案例分析》一書,為開發者提供了非常好的選擇依據。

其次,這個輪子好不好用,需要時間來論證。不能一眼就判斷出一個專案的質量以及易用性,這其實需要大量專案經驗的積累。即便做出了選擇,也需要一定的時間來驗證合理性。畢竟專案很多問題,只能在執行中才能體現出來。

最後一點是,好輪子需要打磨。要想將一個開源專案成功整合到自己的專案中,需要對這個專案有比較深入的瞭解。大部分的開源專案的文件質量參差不齊,當使用輪子時,只看文件往往是不夠的,還需要閱讀原始碼甚至深度修改定製。即便整合到了自己的專案中,也可能需要不斷的進行修正調優以符合自己專案的實際。

掌握IT技能的“複製-貼上-改”

合理複用現有的好輪子,以最大化降低開發專案的成本。如果說,輪子代表了框架級別的可複用的專案,那麼“複製-貼上-改”則是更加精細顆粒度的程式碼層次的複用。

很多開發者都很鄙視“複製-貼上-改”,認為所有的程式碼必須要從0開始敲出來才能真正牛人。這其實有失偏駁。比如,開發人員C君在A專案裡面寫了一段方法,經歷住了上線的壓力,目前也在線上能夠穩定執行。那麼如果專案B也需要同樣功能的方法,C君有必要再從頭去敲一遍程式碼呢?為什麼不直接“複製-貼上”,除非有特殊的需求或者有對該方法的更好的改進,那麼大膽的“複製-貼上-改”即可。或者將該方法重構出來,放到專案A和B共享的公用專案裡面不是很好?從頭敲一遍已有的程式碼,除了增加自己的敲錯的機率意外,實在不知道還有什麼好處。當然,可能鍛鍊了打字速度。

也掌握“複製-貼上-改”的技能,最難是要做到“改”這一點,因為這一點做不好就是抄襲了。以前,老是說騰訊的軟體大多數模仿云云,但恰恰是人家“改”的功能出神入化,時間證明了,那些曾經被騰訊模擬的公司、專案,要不死了要不半死不活,而騰訊卻穩坐大佬的位置,可見“改”功的重要性。

很多配置檔案,其實能少打就不打。比如 Maven 的 pom 檔案座標,你想要什麼類庫直接上中央倉庫去查詢並“複製-貼上-改”下即可,實現是沒有必要手打,打錯了XML也不會給你提示哦。

以下是 MvnRepository 提供的Maven座標。

以下是 MvnRepository 提供的Maven座標

真實案例

理解了複用了輪子的理論重要性,我們來看下真實的案例。

據統計,Google 有軟體工程師平均一天寫 100 ~ 150 行程式碼,而且已經算是業界高效的了。這從側面反饋了,寫程式碼並不是一天中工作的重心,高效的工程師更加註重於花時間在程式碼的思考上面。

筆者的視訊課程《基於Spring Boot的部落格系統實戰》(http://coding.imooc.com/class/125.html),遵循了業界軟體開發的真實開發方式,採用敏捷的漸進式開發的,後續章節會基於前一個章節的內容來延生。這個不是重複,而是最大化重用現有的程式碼。遞進的每個章節的內容都是前後關聯的,讓前幾章的程式碼內容,為後續章節所用,即為“學以致用”。

當然,這種開發方式也不是見得為所有的開發者所接受。正如開篇所講的,熱衷於重複造論的人還是不少。

參考引用: