1. コードはナマモノ
腐らせないために
今までやってきたこと
2013.11.09 DevLove甲子園
@oinume (生沼一公)
13年11月10日日曜日
1

2. お前だれよ？
• @oinume
• (株)サイバーエージェント所属
• 主にサーバサイドエンジニア
• 使用言語：Java, Python, Ruby, etc...
• ブログ：おいぬま日報
13年11月10日日曜日
2

3. 職務経歴
• 2005年∼ (株)ミクシィでFind Job !の開
発∼運用エンジニア
• 2010年∼(株)サイバーエージェントでア
メーバピグの開発・運用
13年11月10日日曜日
3

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

5. 13年11月10日日曜日
5

6. ゴール
• チームメンバー全員がコードをいい状態に保つ
ということを意識すること
• 「他の人が書いた部分は自分関係ないから気に
しない」みたいなのはダメ
13年11月10日日曜日
6

7. 今まで何を
やってきたか
13年11月10日日曜日
7

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

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

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

11. 設計レビュー
• Good
• コードレビューよりも上流工程であるため、
問題が発覚しても手戻りが少ない
• 少ないコストで実施可能
• 効率的に技術的負債の発生が防げる
• Bad
• フォーマット化しづらい
13年11月10日日曜日
11

12. ペアプロ
•
Good
•
•
•
スキル差があるペアでやると効果てきめん
プログラミング以外でも可（設計の相談など）
ペアの人の作業画面が見れる
•
•
•
便利ツールを教えてもらえる
Bad
•
•
コストがかかる
1日8時間フルでやると疲れる
•
•
13年11月10日日曜日
その人の仕事の仕方が盗める
週に3,4時間ぐらいがちょうどいい
同じメンバーで長くやっていると得るものがなくなってくる
12

13. 得られる効果
• 「コードはみんなのもの」という意識の醸成
• チーム内の一体感も強くなる
• 良いコード、ダメなコードが明確化される
• 担当者によってコーディングスタイルが違う
とか
• 結果として、コードが腐りにくくなる
13年11月10日日曜日
13

14. まとめ
• コードレビューとかペアプロは少しずつでもい
いからやるべき
• やらないと技術的負債がどんどん増える
• 「コードはチームのもの」という意識をつくる
こと大事
13年11月10日日曜日
14

15. ご清聴ありがとう
ございました
13年11月10日日曜日
15