2012下半年的一小段總結

2012得益于加入了兩個不同的項目, 接觸了很多新的東西, 相對前兩年在遊戲項目中的工作感覺好了很多, 至少在代碼的規範和技術的選擇上我得到了很寬鬆的環境.

同時也導致了一些問題. 在做實現的時候, 對於遇到的各種問題, 都選擇了各種開源庫的解決方案, 并沒有非常仔細的分析問題, 也不完全理解所選擇的庫的原理和利弊. 當進度到達一定的階段, 各種奇怪的bug出現的時候, 才感到手足無措, 完全不知道問題可能出在哪裡, 最後花了很多時間去查, 往往是一些細節問題.

對於c++0x提供的新特性, 我感到很新鮮, 於是想盡可能在代碼中使用, 最後寫出來的代碼完全沒有可移植性, 由於各種c++0x的特性在多種編譯器現在都處於嘗試階段, 不同的編譯器不僅僅可能在實現上有很大差別, 而且支持的features都不完全, 我所寫的代碼可能換一個GCC的版本就無法編譯了, 有時候還出現這種尷尬的情況, 家裡寫了代碼, 在公司checkout出來編譯不能通過, 或者反過來. 這種情況是無法讓人接受的, 簡直就像是學生在嘗試自己看到的新語言.

同事也抱怨過, 我的代碼難懂, 我剛開始還洋洋得意, 但是現在只感到心寒, 如果我的代碼無人願意看, 而且代碼中的一些角落我自己都無法完全控制, bug不知道什麽時候會出現,  那麼這樣的代碼價值在哪裡呢? 怎麼能夠有長久的生命力.

  之前我認為自己c++功力還行,  今天基本看完了<exceptional c++>,  覺得要學的東西還非常多, 知道的還太少. 裏面提出過一個我曾經用過的技法:

當時項目規定server端不能使用動態分配的內存, 我當時需要根據一些id的創建出需要的class, 於是我這麼做:

// 利用template推導出所有Class中最大的大小size_t sz = max_size_of<Class1, Class2, Class2>::value;char magic[sz];switch (id) {  case kClass1: {    Class1* c =  new(magic) Class1;    // do something with c    c->~Class1();    break;  }  // ...}

這裡存在一個alignment的問題, 這種分配出來的類型很可能不處於對齊的內存邊界上, 所導致的後果是不可預測的, 這些代碼還存在在當時的server端中, 我甚至不能記起在哪裡了! 一定要找出來改掉才行.

<exceptional c++>中提出不要輕易使用語言中很少使用的部份, 可能會導致很細微的問題, 如無法保證異常安全. google c++ style也指出僅僅使用boost和c++0x中已經被驗證的部份(很少的一部份). 我必須要改變自己寫代碼的方式, 要更認真的去對待寫出的代碼, 那不僅僅在當前能夠編譯執行, 並且能夠長時間的工作良好和被別人接受和維護. 如果這些代碼會讓我處於"不知何時會出什麽bug"的心態中, 那就一定有問題.

記得剛入公司不久, 有前輩告誡我說要選擇簡單的技法, 當時我並不太認同, 現在知道他們說的是正確的. 但是對於他們的工作我並不認同, 因為有很多時候是在逃避問題而不是解決它們.