代碼風格一向是仁者見仁,智者見智的,不過我一直認爲人在寫代碼的時候,或多或少都會被現有的代碼風格所影響,而這個,有時候會影響思路,進而,儅需要實現一個新功能的時候,會影響這個新功能的架構,或者說,實現的方法。
我現在工作的項目,原來是由三個人來做的,我的小Leader,我的一個同事和我。一開始我和我的小Leader的風格或者說思路就很不一樣:他更傾向于C的風格,結構比較平坦;而我更傾向于C++的風格,喜歡做一些封裝,雖然還不至於成了過度封裝。這個也影響對外接口的設計,他的設計裏面,一般都用自己分配一個整數來作爲一個Handle來標識資源,對這類資源的所有操作都通過一個Manager類來完成;而我則比較簡單,把資源包在一個類裏面,把這個對象的純虛接口的指針直接暴露給外界。
我們一起合作的時候,由於我那時經驗不夠,不覺得是個問題,而我小Leader估計是覺得他的架構都做得差不多了,我再怎麽做也不會有太大的影響,再加上我在一些可能會影響到以後的實現思路或者新功能添加的地方都會準備兩個方案和他討論一下,所以他也沒有說什麽。
大概一年前,這個項目完成了大半,框架基本上定下來了,他去了另外一個項目,然後就把這個項目交給了我……而在這一年裏面,這個項目的確也是在原有框架下穩定發展,畢竟主要功能都已經差不多了,要做的也就是一些修補,或者加一些小的地方,或者是實現原來就預留了但那時候沒有來得及做的功能。
前幾天(其實也有兩個星期了)我在做一個新功能的時候,想讓它有更大的靈活性,就想看看如何讓它更好融合到現有框架裏面,結果發現了我之前一直視而不見的小Leader的一行註釋,和我現在的想法是完全不同,往大了說幾乎是兩個極端。最後我決定這個新功能按我的思路做下去,在原來的架構上加一個小瑕疵,而不動原來的架構。但是我最近就時不時想起這個問題,雖然目前的做法還沒有引起問題,僅僅是代碼看上去不是那麽的漂亮,但是繼續下去的話,就不知道在以後如果有類似問題的時候會不會引發大問題了。
我知道我有點吹毛求疵或者杞人憂天,但是這個可能性還是存在的。而且維護起來也會讓人覺得一點點不爽。
前幾天(這就真的是前幾天了)還和偉哥討論了一下,我說C++就要有C++的樣子,什麽樣的語言就干什麽事。他說其實還是要看實際應用的,他也會在C++上面寫更像C的程序云云。我們討論了好長時間(貌似到晚上1點多快2點了),最後勉強把我說服了,不過,如何補救現有代碼,或者,還是就讓他這樣子了,反正以後基本上也不會有大動筋骨的改動。我還沒有一個令我滿意答案。
但其實很顯而易見的是,目前不動它的話,應該不會有問題,而在補救的時候,更容易出問題。現在就讓它拖下去吧,在我可預見的將來,我還沒有看到對框架進行大改動的需要,等到這個需要來了,“補救”方案也許就水到渠成了。
其實,也許,這真不是什麽大問題…………
某些人一直强调C++是多泛型的语言,所以用C++未必要沿着OO的思想往下走。