コードはナマモノ 腐らせないために今までやってきたこと
DESCRIPTION
TRANSCRIPT
お前だれよ?
•@oinume• (株)サイバーエージェント所属•主にサーバサイドエンジニア•使用言語:Java, Python, Ruby, etc...• ブログ:おいぬま日報
213年11月10日日曜日
本題• コードはナマモノです• 何もしないでおくと腐っていきます• 担当者にしかわからないコード• 積み上がる技術的負債• エンジニアのモチベーションの低下• 何年も続くWebサービスではコードを腐らせないことはとても大事
413年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日日曜日