More Related Content
Similar to 分析チームのチーム開発 Mod
Similar to 分析チームのチーム開発 Mod (20)
分析チームのチーム開発 Mod
- 2. データ分析はスコープ外です • 本質的に難しい • 教え方 • 複雑さを制御する方法 • 私も大して詳しくない(あなた方の方が詳しい) 以下の話はプロダクションコードの開発のみという事で （ただし参考にはなるかも？)
- 3. チーム開発の意義 メリット • Best Practiceの共有 • 教育 • プログラムの経験のばらつき • チーム開発の経験のばらつき • コラボレーションの促進 • チーム感 リスク • 自由さを制限 • データ分析の難しさ • 無駄な作業の増加 • 良く失敗する
- 4. チーム標準の定義 • Gitの使い方 • githubモデル • コミットログのテンプレート • フォルダ構成とスケルトン（ネーミングコンベンション） • コミットのクライテリア ＞プロダクションコードのみ
- 5. gitの作業フローを決める 1. トピックブランチを切る（git checkout –b t_branch1) 2. 作業してコミット*N (git commit…) 3. masterをプル (git checkout master; git pull) 4. トピックブランチをrebase (git checkout t_branch1; git rebase master) ＝＞ここでレビュー 5. トピックブランチをmasterにマージ(git merge t_branch1) 6. git push 7. トピックブランチを削除 (git branch –d t_branch1)
- 6. レビューの難しさ • ただ攻撃するだけになりがち • 生産的なレビューを正しく行うには訓練が必要 • モデレータの設置 ＝＞正しく行うのは現状は困難 • まずは小さく始めよう • 明確なクライテリア違反のみ指摘 • それ以外のフィードバックは原則しない（まぁ多少はいいけれど） ＝＞ クライテリアが明確で、しかも定義されている必要性
- 7. コミットの二つのクライテリア • コードの追加と変更にはUnitTestを原則必須とする • リファクタリング時は不要 • リファクタリングとそれ以外のコミットの分離 • なるべくリファクタリング側で作業する • この作業を通してgitの使い方を学ぶ • cherry-pick • resetによるHEADの移動 • トピックブランチ • amend
- 8. UnitTest • 関数ごとのテスト • Run fast • 通信はしない • 決定的な結果(たまに失敗したりしない) • 外部のシステムは使わない（redisとか） • 乱数は使わない • その他奥が深いが、まずは上記くらいから始める Dependency Injection
- 9. TDD (Test Driven Development) • UnitTestを書けるようにコードを書く、という手法 • テスタブル＝＝良いデザイン という前提 • テストを書こうとする事で、正しいデザインを教えてくれる ＝＞自習向き • その他たくさんのメリット
- 10. リファクタリング • 広義の定義 挙動の変更を伴わないコードの変更 • 狭義の定義 挙動の変更が無いと分かっている変更の組み合わせだけで出来る変更 • extract method • method object • その他 http://refactoring.com/catalog/ にある変更 • だいたいは狭義の定義で多少ゆるく
- 11. リファクタリングベースの開発の意義 • 他人の変更の読みやすさ向上 • リファクタリング部はカタログの組み合わせを理解するだけで読める • 実装や変更の部分だけが局所化されるのでそこを注意出来る • プロフェッショナルなコミットログ ＞ミーティングやドキュメントがあまり要らなくなる • コード品質の向上 • 割り込みと変化に強い • いつでもやめられる（通常5分程度、最長でも半日程度） • 早いフィードバックによる生産性の向上 • UnitTest中心の開発 • adaptive (最初の予想が外れても問題無い）
- 12. リファクタリングベースの開発の典型例 ＡからBという状態に変更したい場合 1. 最初の状態Aを確認する手順を確立 2. もっともBに近いA’まで、Aからリファクタリング 3. 1と同じ方法で挙動が変わっていない事を確認 4. コミット!!! 5. A’からBに変更 6. Bが正しく動いている事を確認する（出来たら手順確認） 7. コミット
- 13. 新メンバーに対する教育方法 1. rebaseが終わった所でレビューする 2. クライテリアにミートしていない所だけ指摘して直してもらう 3. 以上を最初の2週間～1か月くらい行う 4. 出来るようになったらレビューする側に回る（指摘内容はだれが やっても同じなので誰でも良い）
- 14. コミットログ • 一行目は80文字以内のタイトル(git log –onelineなど用) • 二行目は空行で三行目以降記述（GUIツール用） • リファクタリングは一行目先頭を[Refactoring]で始める
- 15. おまけ： このプロセスをおすすめする理由 • プログラムの経験が浅くても理解しやすい • リファクタリングとUnitTest • 各自が自動的に必要な事を学習していける • 経験豊富なベテランの指導が無くても運用出来る • 最先端のBest practiceである • あまり一人の人間に作業が集中しない（レビューが 検閲削除:XXX さ んに集中しない）
- 16. 参考文献 • レビューしやすいコミット履歴でバグ削減 • https://moneyforward.com/engineers_blog/2015/11/30/reviewable-commit-log/ • gitの使い方はこれを基本に • A successful Git branching model • http://nvie.com/posts/a-successful-git-branching-model/ • モダンな開発サイクルの話。トピックブランチとか。 • こちらも読んでおくと理解は深まる。 https://gist.github.com/Gab-km/3705015 • Ｇｏｏｇｌｅの単一レポジトリの話 • http://www.publickey1.jp/blog/15/2045000google.html • FBでもどこでもだいたい同じ（現時点での業界のコンセンサス） • プロジェクトでレポジトリを分けちゃダメで、たぶん李さんチームで一つのレポジトリを使うべき • （でも少しこちらはエンジニアリングレベルを要求されるので、ある程度チーム開発に慣れてきたらでいいと思う） • 私がConfluenceに書いた UnitTest入門 • (検閲削除: 社内の自分が)
- 17. 参考文献2 (メールから転載、体裁は気にしない） • 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES) Martin Fowler 固定リンク: http://www.amazon.co.jp/dp/427405019X • リファクタリングといえばこの本。 • Test Driven Development: By Example by Kent Beck Link: http://amzn.com/0321146530 • TDDの話はこれ。少し能書きも多いが薄い本なので軽く読み流すのがおすすめ。和訳は腐っているので原書で。 • レガシーコード改善ガイド (Object Oriented SELECTION) マイケル・C・フェザーズ 固定リンク: http://www.amazon.co.jp/dp/4798116831 • 依存の切り方という点ではこの本が一番詳しい。ただしC++とかの例が多いので分析屋には向かないか。 • xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros Link: http://amzn.com/0131495054 • Unit Testの書き方という点ではこの本が一番良いが、分厚くて和訳が無くて（ほんとか？）同じ話が三回くらい繰り返されてるので • 読むのは結構だるい。読むのはTechnical Lead一人でいいかなぁ、という所。 • ただしテストの命名規則などは詳しく、だいたいこれに揃えておくのが良い。