コードはナマモノ腐らせないために今までやってきたこと

2013.11.09 DevLove甲子園@oinume (生沼一公)

113年11月10日日曜日

お前だれよ？

•@oinume• (株)サイバーエージェント所属•主にサーバサイドエンジニア•使用言語：Java, Python, Ruby, etc...• ブログ：おいぬま日報

213年11月10日日曜日

職務経歴

•2005年～ (株)ミクシィでFind Job !の開発～運用エンジニア

• 2010年～(株)サイバーエージェントでアメーバピグの開発・運用

313年11月10日日曜日

本題• コードはナマモノです• 何もしないでおくと腐っていきます• 担当者にしかわからないコード• 積み上がる技術的負債• エンジニアのモチベーションの低下• 何年も続くWebサービスではコードを腐らせないことはとても大事

413年11月10日日曜日

513年11月10日日曜日

ゴール

• チームメンバー全員がコードをいい状態に保つということを意識すること

• 「他の人が書いた部分は自分関係ないから気にしない」みたいなのはダメ

613年11月10日日曜日

今まで何をやってきたか

713年11月10日日曜日

今までやってきたこと• コードレビュー• 設計レビュー• ペアプロ• コードに対する価値感を揃える• これはいいコード、悪いコード• 例)コーディングガイドライン

813年11月10日日曜日

コードレビュー• Good• 他の人が書くコードは参考になる• チーム内で同じようなコードを書くことが少なくなる• 担当者不在時の問題対応もやりやすくなる• 良いコード・ダメなコードが明確になっていく• Bad• 時間・手間がかかる• 対象を絞ることである程度は回避可能

913年11月10日日曜日

設計レビュー

• コードを書く前に設計のレビューをする• データベース設計• アーキテクチャ設計• クラス設計• 何かしらの設計図を書いてもらって、Face to Face で説明してもらう

1013年11月10日日曜日

設計レビュー• Good• コードレビューよりも上流工程であるため、問題が発覚しても手戻りが少ない

• 少ないコストで実施可能• 効率的に技術的負債の発生が防げる

• Bad• フォーマット化しづらい

1113年11月10日日曜日

ペアプロ• Good

• スキル差があるペアでやると効果てきめん

• プログラミング以外でも可（設計の相談など）

• ペアの人の作業画面が見れる

• その人の仕事の仕方が盗める

• 便利ツールを教えてもらえる

• Bad

• コストがかかる

• 1日8時間フルでやると疲れる

• 週に3,4時間ぐらいがちょうどいい

• 同じメンバーで長くやっていると得るものがなくなってくる

1213年11月10日日曜日

得られる効果

• 「コードはみんなのもの」という意識の醸成• チーム内の一体感も強くなる• 良いコード、ダメなコードが明確化される• 担当者によってコーディングスタイルが違うとか

• 結果として、コードが腐りにくくなる

1313年11月10日日曜日

まとめ

• コードレビューとかペアプロは少しずつでもいいからやるべき

• やらないと技術的負債がどんどん増える• 「コードはチームのもの」という意識をつくること大事

1413年11月10日日曜日

ご清聴ありがとうございました

1513年11月10日日曜日