チーム開発実践入門読んだ
明日(今日)進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) - DevLOVE関西 | Doorkeeper があるので、記憶が上書きされる前に残して置きたかった。
チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)
- 作者: 池田尚史,藤倉和明,井上史彰
- 出版社/メーカー: 技術評論社
- 発売日: 2014/04/16
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (6件) を見る
メモと妄想と入り混じった感じだけどとりあえず書きます。
気をつけること
- 「正解はケースバイケース」
- ツールは正解を持たない
- ツールによって想定された使い方とか、 ベストプラクティス?と言われるようなものはある。
- でも確かにIt depends on 状況、ですよね。ここでは2つの考え方があるんじゃないかな。
- 自分たちの状況をペストプラクティスが対象とする状況に合わせる
- ベストプラクティスを自分たちの状況に合わせる
- 長い目で見ればベストプラクティスを適用できる形にプロセスを変えていくべきかなと思っています。
- そういう覚悟?が無いやつはレガシーコードと一緒に沈む可能性が高い気がする。根拠はないけど。
- ツールが想定してる使い方をせずに,無理やり自分たちのプロセス上動かそうとして、導入に失敗、「◯◯は使えない」とか悲しいよねー
タスクの管理について
- タスクの優先順位を決めるためにITS使おう
- ITSじゃなくてもよい.開発以外の関係者も見られるもの
- 優先順位をはっきり決められるのがよい。これはGithubを使ってもいい。
- ITSが重すぎるならホワイトボードと付箋でも
バージョン管理を有効に使う
- バージョン管理超大事。常にバージョン管理でコードの変更を追跡できるように。
- コミットログを活用しよう
- ITS,CIサーバとの連携も視野に
- 意味の無いコミットメッセージは無いように
- ITSとの連携でコード変更の理由まで簡単に追跡できるようにしよう
- ブランチ・タグはうまく使おう
- ソースコード以外もバージョン管理
テストコードは必須
自信をもってコードの変更できるように常にテストを書こう
- レガシーコードは無理しない
- 状況を悪くする可能性もあるので少しずつ
- 追加するコードはテスト可能なように書こう
- でもテスト書くにもスキルが必要な点は留意すること
- 慣れないうちは素振りとか超大事
CI回そう
- VCS,ITSと連携すると幸せになれる可能性高まる
- 可能なら検証環境も簡単に用意できるようにしておこう
- CDもいいけどハードルは高め
- Chefとか使えると幸せ
- 可能なら検証環境も簡単に用意できるようにしたいね
- 運用にはそれなりにパワーが必要な印象
以下、読んでる最中に脳内でこぼしてた愚痴
- 自分たちで良くなっていく意志のないチームは何をやってもダメ
- 「でもうちのチームのやり方には歴史があって・・・」、「他のコードに合わせないと・・・」
- 今までより良くするために変えていく
- コメントであろうがなんだろうが意味をなしてないものは削除
- 関数は積極的に分割してテスト可能に変更
- とかとか
- 「で,それは誰がやるの?」、「◯◯のときどうするの?」
- どうするの?じゃねーよ。おめーがやるんだよ
- せめて「◯◯のときいい案無いかな?」とかもう少し、ほら、ね?
- どうするの?じゃねーよ。おめーがやるんだよ
- 「でもうちのチームのやり方には歴史があって・・・」、「他のコードに合わせないと・・・」
おわりに
台風来てるし中止にならないか心配。