PHPカンファレンス2012メモ #phpcon2012
気になったところのみ。
基調講演
Composer
RubyでいうBundler的なライブラリ依存管理の仕組み。
Symphony2を始めとして多くのものが対応している。
（というかsymfony2はコンポーザーでインストール！）
「みんな対応している」重要
初心者セッション
いまだからできる、ふつうのはなし Gree
終盤5分くらい聞いた。
古いシステムの改善は、機能毎に区切って(縦に切って)少しずつリプレイスしていくのがいいと思ってたけど、どうもそうではなく、既存のシステムに新たに層を2つくらい積み重ねて(横に追加して)いくことで改善を行うような話だったらしい。
聞きたかった・・・
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
と・と・鳥ランド！
最先端Web開発
アジェンダ見たところ、自社開発フレームワーク(dietcake)の紹介かとおもいきや、プレゼン開始直後のスライドでそのアジェンダに取り消し線が入った！
とてもいい話でした。感動した。
PHPという言語自体のポリシーに通じる部分もあり、とても共感できました。
新しくjoinする人をどのように迎え、どのように育ててゆくか。
フレームワークはシンプルに保つ
Symphonyとか1,2で変わりすぎて学習はやり直し、Doctrineのコードなんか全部ちゃんと読める人などほとんどいない。
フレームワークのコードが現実的に読める内容であること。
「変わらない」ということの価値。
グループプログラミング
ドライバー1、ナビゲータ3 でのペアプロ
join.meというサービスでドライバーの画面をナビゲータの端末で共有
なんと生産性自体は一人の時とそんなに変わらないらしい(4倍近くになってる！？)
Githubでプロジェクトの健全性を測る
コミットの回数とタイミングが統計的に確認できる
→ 夜中土日のコミットが多いとデスマってるなーとなる
Git x Pull Request ~ チーム開発最終奥義
gitのメリット
ローカルでの気軽なコミット、手軽なブランチング、賢くて高速なマージ
リリースを細かく
リニューアルとかの大きな案件でも「○○の構造変更」とかだけでリリース等
こうするとあとでマージが大変とかにならない
featureブランチから更にfeatureブランチを生やす
複数人での機能開発での混乱を少なく
PullRequestを通して必ずレビュー
これを繰り返してメンバーの長所短所など特徴を知ることができる
細かい単位で行うことで、レビューの効率がとても良くなる
どのような要求に対してどのような変更を行ったかが重要であり、そこに対して効果的なレビューが出来る
チームにあったやり方で
KLabさんとか、基本master一本でそこからいくつも細かい開発ブランチ生やすようなシンプルなやり方だし。
Composer による依存管理と Packagist によるライブラリ公開
日本語化頑張り中だそう
https://github.com/kawahara/composer
