コードはナマモノ
腐らせないために
今までやってきたこと
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,707 views

Published on

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,707
On SlideShare
0
From Embeds
0
Number of Embeds
82
Actions
Shares
0
Downloads
5
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

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

  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

×