ReadingAgileSamuraiInDwango20111005
tlync edited this page Oct 5, 2011
·
1 revision
参加者：@lchin @futoase @guccii @tlync(メモ係)
- テスト先にするなんて学校じゃ教えてくれなかったとあるけど、普通じゃね
- 学校では教師がテスト(問い)みたいな事を先に準備するよね
- プロジェクトへの導入はどうするか
- 個人でもできる。そこから広げられる。
- よくある言い訳としては「既存のコードがテストに向いてない」
- 現実問題としては、出来るところからやるしかない
- 新しい言語、FW とかだと時間がかかる面はある
- 導入したければ言語、FW など周辺技術も含めてある程度スキルとして身につけておくのがいい
- 某社内レジュメシステムの話し
- テスト書いてない
- ORM とか使ってたり、UI がほとんどなのでテストしにくいし、テストを書く規模でもない
- TDD に関係ないけど Node.js が使われている(…だと!?)
- 先に書くというのが、メンタリティ的に重要
- API を意識をせずに作ってしまう事を防げるのが良い
- 特に普段そのあたりを脳内で意識できてない人
- TDD の効能の話しだよね
- 早めに利用者のニーズを把握でき、よりよい設計に繋がる
- フィードバックループが短くなり、開発リズムが良くなる
- 第5部の構成がおもしろい
- UnitTest > Refactoring > TDD
- TDD のとっかかりはペアがいるとやっぱいいよね
- でも TDD においてペアプロは主軸ではない。もちろんペアプロは良い手法であるけども。
- TDD にイテレーション 0 的な準備期間は必要じゃない?
- いや、TDD にはプロジェクトとしてイテレーション 0 的はものは必要なくて、個人でスキルとして見につけ、実践するものじゃないか
- ボトムアップ的な感じ
- プロジェクトにおいて TDD でやるよと宣言する必要もないし、成果をコミットする必要もないんじゃないか
- 設定ファイルが違う、最新ビルドが分からない、デプロイミスなどなど…
- あるあるストーリー…
- 昔の某社内システムとかシナリオ1みたいな…
- 人によってリリースの方法が違う
- 一部のファイルだけ更新するとか
- php.ini が違うとかあるある
- ソースコード管理に含めてしまった方がいい
- cron なども手書きじゃなくて、ファイルで管理した方がいい
- 大規模なシステム程、こういう問題が起きやすいし備えるのは大変ではある
- やっぱり最初からすごく基本的なでもいいから用意すべきだよね
- できてる? 意外にできてないんじゃない
- だいたいできてる
- 設定ファイルはインフラしか触れないとかあるけど
- iOS とかのスマートフォンアプリ
- クローズドな、依存が少ない環境できる事が多いので特に問題になっていない
- 最初の方のマージの話しはちょっとバージョン管理よりの話しな気はする
- バージョン管理システムの普通な話し
- ソースコード管理を教えなければいけないのが大変
- ファイル共有の仕組みとして捉えられてる
- 最新のソースコードを取得する、テストする、diff を確認するとか、ふつうの話
- ふつうの話しだけど、たまにある?
- git の方がいいよね
- 社内の git はまだか
- 動く人がいない
- バックアップとか、教育とかの導入する為の体制づくりなどが必要
- そこで git-svn
- たまにバグる
- git-svn 使う場合は自分の master で開発すんな
- 本番環境まで掌握していてデプロイできるのはうらやましい
- IRC で発言するとデプロイされるとかいいよね
- github 社内はそうなってるらしい
- 超重要
- 何日もインテグレーションしないチーム、メンバーとかもいるよね
- コミット単位はほんとに最小にして欲しい
- コミットコメントもより分かりやすくなる
- コミットコメントで「いろいろ修正」とか…
- コミットコメントはコミュニケーション
- 今日から心いれかえてやります!
- git は作業単位を小さくする上でも優位性がある
- コードレビューとか、ペアプロも効果ある
- 見られているという意識
- 誰にも見られていないコードが怖い
- まとめ的なスピリチュアルな話し
- 振り返りと打ち上げやるぜ!
- 水曜日に拘らず、みんなが都合つく時にやるよ