Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Loading in …3
×

Check these out next

1 of 15
1 of 15

More Related Content

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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

  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

×