Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
コードはナマモノ
腐らせないために
今までやってきたこと
2013.11.09 DevLove甲子園
@oinume (生沼一公)

13年11月10日日曜日

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

2
職務経歴
• 2005年∼ (株)ミクシィでFind Job !の開
発∼運用エンジニア

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

13年11月10日日曜日

3
本題
•
•

コードはナマモノです
何もしないでおくと腐っていきます

•
•
•
•

13年11月10日日曜日

担当者にしかわからないコード
積み上がる技術的負債
エンジニアのモチベーションの低下

何年も続くWebサービスではコードを...
13年11月10日日曜日

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

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

13年11月10日日曜日

6
今まで何を
やってきたか

13年11月10日日曜日

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

8
コードレビュー
•

Good

•
•
•
•
•

チーム内で同じようなコードを書くことが少なくなる
担当者不在時の問題対応もやりやすくなる
良いコード・ダメなコードが明確になっていく

Bad

•
•
13年11月10日日曜日

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

13年11月10日日曜日

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

• 少ないコストで実施可能
• 効率的に技術的負債の発生が防げる
• Bad
• フォーマット化しづらい
13年11月10日日曜日

1...
ペアプロ
•

Good

•
•
•

スキル差があるペアでやると効果てきめん
プログラミング以外でも可(設計の相談など)
ペアの人の作業画面が見れる

•
•
•

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

Bad

•
•

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

• 結果として、コードが腐りにくくなる
13年11月1...
まとめ
• コードレビューとかペアプロは少しずつでもい
いからやるべき

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

13年11月10日日曜日

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

13年11月10日日曜日

15
Upcoming SlideShare
Loading in …5
×

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

1,860 views

Published on

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

  1. 1. コードはナマモノ 腐らせないために 今までやってきたこと 2013.11.09 DevLove甲子園 @oinume (生沼一公) 13年11月10日日曜日 1
  2. 2. お前だれよ? • @oinume • (株)サイバーエージェント所属 • 主にサーバサイドエンジニア • 使用言語:Java, Python, Ruby, etc... • ブログ:おいぬま日報 13年11月10日日曜日 2
  3. 3. 職務経歴 • 2005年∼ (株)ミクシィでFind Job !の開 発∼運用エンジニア • 2010年∼(株)サイバーエージェントでア メーバピグの開発・運用 13年11月10日日曜日 3
  4. 4. 本題 • • コードはナマモノです 何もしないでおくと腐っていきます • • • • 13年11月10日日曜日 担当者にしかわからないコード 積み上がる技術的負債 エンジニアのモチベーションの低下 何年も続くWebサービスではコードを腐らせないこ とはとても大事 4
  5. 5. 13年11月10日日曜日 5
  6. 6. ゴール • チームメンバー全員がコードをいい状態に保つ ということを意識すること • 「他の人が書いた部分は自分関係ないから気に しない」みたいなのはダメ 13年11月10日日曜日 6
  7. 7. 今まで何を やってきたか 13年11月10日日曜日 7
  8. 8. 今までやってきたこと • コードレビュー • 設計レビュー • ペアプロ • コードに対する価値感を揃える • これはいいコード、悪いコード • 例)コーディングガイドライン 13年11月10日日曜日 8
  9. 9. コードレビュー • Good • • • • • チーム内で同じようなコードを書くことが少なくなる 担当者不在時の問題対応もやりやすくなる 良いコード・ダメなコードが明確になっていく Bad • • 13年11月10日日曜日 他の人が書くコードは参考になる 時間・手間がかかる 対象を絞ることである程度は回避可能 9
  10. 10. 設計レビュー • コードを書く前に設計のレビューをする • データベース設計 • アーキテクチャ設計 • クラス設計 • 何かしらの設計図を書いてもらって、Face to Face で説明してもらう 13年11月10日日曜日 10
  11. 11. 設計レビュー • Good • コードレビューよりも上流工程であるため、 問題が発覚しても手戻りが少ない • 少ないコストで実施可能 • 効率的に技術的負債の発生が防げる • Bad • フォーマット化しづらい 13年11月10日日曜日 11
  12. 12. ペアプロ • Good • • • スキル差があるペアでやると効果てきめん プログラミング以外でも可(設計の相談など) ペアの人の作業画面が見れる • • • 便利ツールを教えてもらえる Bad • • コストがかかる 1日8時間フルでやると疲れる • • 13年11月10日日曜日 その人の仕事の仕方が盗める 週に3,4時間ぐらいがちょうどいい 同じメンバーで長くやっていると得るものがなくなってくる 12
  13. 13. 得られる効果 • 「コードはみんなのもの」という意識の醸成 • チーム内の一体感も強くなる • 良いコード、ダメなコードが明確化される • 担当者によってコーディングスタイルが違う とか • 結果として、コードが腐りにくくなる 13年11月10日日曜日 13
  14. 14. まとめ • コードレビューとかペアプロは少しずつでもい いからやるべき • やらないと技術的負債がどんどん増える • 「コードはチームのもの」という意識をつくる こと大事 13年11月10日日曜日 14
  15. 15. ご清聴ありがとう ございました 13年11月10日日曜日 15

×