過去兩年中我對程式碼重用的體驗
兩年前我有幸加入了一家行業內一流的公司(進入這家公司前是這麼認為的.:P), 當時公司頗有幾個高手, 大家對於建立公司的程式庫或叫做遊戲引擎進行了廣泛而熱烈的討論, 隨著公司專案的進展, 大家也做了很多努力, 但最終未能見到什麼成果. 事隔一年, 公司來了幾個熱血青年, 剛剛從學校出來, 領導決定讓他們負責一個專案, 他們對建立重用的程式碼庫的熱情就象我們當初那樣高. 我在一旁觀察了1.5年, 最後我給他們下的結論是, 他們比我們當初更加失敗. 這兩次事件一直在我腦海中旋轉,感想頗多, 終於忍不住想寫出來了.:)
因為這裡主要講的是我個人的專案體驗, 所以要先來介紹一下專案背景. 我這裡所說的專案主要是指大型遊戲專案, 開發週期一般在1.5年以上, C/C++程式碼30萬左右, 參與專案的程式一般在5人左右. 在這裡我主要想談三點感受:
1.寫出可以重用的程式碼對開發者的要求非常之高.
寫出好的可重用的程式碼需要成熟的開發者. 所謂的成熟首先需要對自身所處的技術領域的歷史和現況都要有相當廣泛的瞭解, 其次要開發過規模相當的專案, 最好是相似的型別的, 這樣才能對需要做什麼, 怎麼做有足夠的認知.
變化是與專案的進展如影隨形的, 這種變化不單單是指需求等外因在變, 作為開發者, 我們自身也在隨專案變化. 隨著專案的發展, 自己對專案的理解越來越深入, 自己在相應的技術領域越來懂的越多, 越來越熟練, 理解的越來越深入, 而我們寫出的程式碼卻時靜靜的躺在那裡的. 我想, 評定自己是否是一個成熟的開發者的標準(只對與此專案或者此領域啊)就在於, 當你伴隨著專案不斷成長的時候, 你是否會改變初衷, 即是否想對專案之初所做的整體設計進行大規模的修改. 如果你的專案做了一半, 你就對之前做的設計不滿意, 甚至憎惡了, 那你這個專案產生的程式碼你會用到下一個專案嗎?
還有一個問題曾經令我非常困惑, 那就是專案中總是存在我們不熟悉的技術或者其它東西, 總有那樣的方面, 讓我們感覺自己不夠成熟, 這怎麼辦呢? 面對這樣無法迴避的問題, 我們沒有那麼多的時間去學習, 去練習, 以使得自己變成熟, 我們只有隨專案的發展而不斷成熟. 應對這樣的問題, 我想“重構“這個概念是一濟良藥, 專案不斷髮展, 我們自己不斷髮展, 當發現程式碼中的bad small時, 就要即時清除.
2.程式碼重用要先從在當前專案中實現程式碼重用開始.
我見過幾位同事, 他們言必及我們現在做的模組要作為公司的程式碼積累, 公司以後可以一直用下去. 我是個比較實際的人, 我認為做好眼前的專案是首位的, 程式碼重用首先是程式碼需要在本專案中被重複利用. 我覺得這一點往往被忽視, 而且很多人會覺得那是當然的, 而我覺得它並不象想象中的那樣簡單.
例如, 在專案中我所負責的模組和另外一個同事負責的模組都需要一個生成簡單幾何體Mesh的功能. 但是我們兩個在具體的需求上還是有些差異, 最後我們還是每個人寫了一個這樣的小模組. 所以我想講, 需要良好的溝通, 良好的規劃, 以及對對專案良好的掌控才能儘量減少這種在單個專案中的重複開發的現象.
我還想談一點就是, 程式碼重用還要從重用好自己的程式碼開始. 我就曾經見過有的兄弟將一段程式碼重複的拷貝到多個地方, 而不是使用一個函式. :( 函式, 模板, class都是最基本的程式碼重用的工具, 基本上是coding層面的東西, 如果這些都掌握不好, 就先不著急談專案之間的程式碼重用吧.
3.應該從小模組開發, 如果想上來就設計一個超過10萬行的可重用的FrameWork, 除非您是天才, 否則註定失敗.
對於我個人處的這個小小的軟體開發的分支--遊戲開發來說, 我覺得在很多技術點上, 與歐美相比我們還算跟的上, 很多同事可以寫一個HDR或者Soft Shadow的DEMO. 但是我感覺在FramwWork層面, 我們還太嫩了(或許是我眼界太窄, 沒見到強的), 一些FrameWork常見的概念很少見諸與國內的引擎中. 我見過的一些引擎, 在結構層面都相當簡陋, 一個引擎能用在3個專案上就已經算上生命力非常頑強的了. 更多的情況上一個引擎經歷了兩個專案的使用, 改來改去的就已經滿目瘡痍了.
最後, 我想談一下為什麼我覺得原來公司裡那幾個熱血青年比我們當時進公司時的那次程式碼重用實踐還要失敗, 藉此給那些比我年輕些的朋友提個醒. 我認為他們水平還遠遠沒有達到可以寫出可重用程式碼的時候, 就過早的強調了這一點. 他們花費了大量的時間去完善文件, 反覆修改程式碼, 但是, 就我觀察他們所完成的程式碼能夠滿足當前專案的穩定執行就哦米託佛了. 例如他們一個兄弟用了大約1人年的時間去寫一個GUI的模組, 同樣的模組我們專案只用了2人月, 更可笑的是最後那哥們因為水平實在太差被開除了! 這樣的模組你在專案裡用著放心嗎? 如果有機會不用這個模組, 你肯放棄這條活路嗎? 這不得不說是一個失敗的案例.
相關文章
- 如何透過babel去操作ast, 並生成對應的程式碼。BabelAST
- 程式碼質量第 2 層 - 可重用的程式碼
- 4.0體驗站|我對OceanBase 4.0社群版的體驗與看法
- 重用其他程式庫
- WPF中的命令模式:打造清晰、可重用的程式碼利器模式
- unidbg過混淆過的arm64程式初體驗
- BI能做什麼?過來人提醒:別聽PPT的,去體驗
- Gartner:IT部門對AI人才的需求在過去四年增長兩倍AI
- C#中透過ObjectPool重用物件提高程式效能C#Object物件
- 程式設計師體驗——我在 RightCapital 的工作程式設計師API
- 基礎設施即程式碼的過去和未來
- 凹凸實驗室的過去與未來
- 入Ali的過去一年,談談我對code-review的理解| 掘金年度徵文View
- Security Signals:研究顯示超過 80% 的企業在過去兩年內都經歷過韌體攻擊
- 為什麼我對簽名訊息的簽名驗證在PHP程式碼中未工作?PHP
- 程式碼分析引擎 CodeQL 初體驗
- 一個SAP顧問的回憶:我過去很胖!
- 2021低程式碼現狀:回顧過去,展望未來
- ScienceMag:過去十幾年中國消化了全球72.4%的塑料垃圾
- Java 繼承與多型:程式碼重用與靈活性的巧妙結合Java繼承多型
- 幽默:我的程式碼不是固體SOLID,而是液體LIQUID - ctrlshiftiSolidUI
- 三七互娛殷天明:這是我們過去八年總結的遊戲出海經驗遊戲
- Java 抽象類與方法:實現安全性與程式碼重用Java抽象
- 為什麼程式碼重用仍然是一個安全噩夢
- 在體驗過無數動作遊戲之後,我對打擊感的設計有了新的認識遊戲
- 18年最慘的總結報告:過去一年,編寫的程式碼總量加起來可繞地球兩圈
- 程式碼安全 兩種程式碼漏洞
- 對不起,我錯了,這程式碼不好寫
- 《我的湯姆貓2》重磅來襲,全新的遊戲體驗不容錯過!遊戲
- 我們去暴雪試玩了“傭兵戰紀”模式 RPG味的《爐石傳說》體驗如何?模式
- 不同人對BUG的反應,程式設計師:誰動了我的程式碼?程式設計師
- 程式碼模板 | 我的程式碼沒有else
- 這兩年多我寫PHP業務程式碼的方式是如何進化的PHP
- Linux 程式編譯過程的來龍去脈Linux編譯
- 小程式的初體驗
- 過去十年間的Linux核心的貢獻對比Linux
- 低程式碼如何快速提升客戶體驗
- 《神經網路的梯度推導與程式碼驗證》之CNN前向和反向傳播過程的程式碼驗證神經網路梯度CNN反向傳播
- 我去餓我去餓完全e'w'q