読者です 読者をやめる 読者になる 読者になる

itochin2の日記(仮)

主に備忘録。Perl、MySQL、Unity、開発管理などについて情報を残していきたい。

俺のコードがこんなに汚いわけがない

昨日、社内勉強会でコードレビュー会を開催した。

 

コードレビューってなんなの?っていう概要説明と

実際にやってみるっていう、2段構成。

 

30分だけの予定だったけど、予想以上に炎上盛り上がって

気づけば1時間半も・・・。

※会議室とプロジェクターをダマで延長レンタルしたのは内緒だ。

 

そんなわけで、コードレビュー会の振り返り。

良かったところ

  • 新入社員の人ともコミュニケーションとれた。
  • DBへの負荷、アプリケーションへの負荷を考えた実装について議論できた。
  • 命名規則が大事という共通認識がもてた。
 
中途で入った人とか、プロジェクト違うと全然話さないので、こういう場があるのはよかった。
エンジニアの共通話題だと話しも振りやすい。
 
プログラムからDBにorder byで全レコード取るより、
全レコード取得してから、プログラムでsortするのが
商用のDBサーバの負荷が下がるよね、とかは良いレビューだった。
 
プレゼントを付与する関数名が「SetOkurimono」はねーよっていうのが
共通見解でホッとした。
あとアイテムを抽選して結果を返す関数名が「pon」っていうのはセンスないと思う。
 

悪かったところ

  • 段取りの悪さ。
  • やはり起こってしまった括弧の位置戦争。
  • 言葉の統一。

 

30分で終わるはずが1時間半とか、見積もりが雑すぎた。

事前にコードを配布しておくとかすればよかった。

 

括弧の位置とか好みの問題だから、あーだのこーだの言うことに時間を割くのは

生産性が低い。ファイル単位で統一されてればおk、くらいで流せればよかったわ。

 

個人的に「ソースレビュー」「コードレビュー」を適当に混ぜて話していたのが

ダメだなーと思った。次回は「コードレビュー」で統一する。

 

総括

人のコードを見たり、指摘を受けるのは勉強になった。

実装のときに気をつけたり、業務に落とし込んで障害を減らしていきたい。

あとプレゼンの資料作るのも地味に大変。

数をこなして内容とスピードを磨いていかないとなー。

 

作った資料↓

 

終わり。