Developer Migration 2013に参加しました。有用な話が多々聞けてとても充実したイベントでした。
開発者は仕事でリーダブルなコードを書けるのか?(株式会社クリアコード 須藤 功平さん)
プレゼンメモ:
- コードは書いた人の意図を語る→書いた人の意図がわかりやすいコードはリーダブル。
- B2D(Business to Developer)
- リーダブルなコードによって、誰でも直せる&助け合える
- コミットコミュニケーション
- 1時間に1回もコミットしていないのは異常。
- コードレビューは、まず自分がレビューアになること、時間を決めてレビューすること。
- みんながみんなのコードを読む文化を作ろう。
クリアコードの須藤さんの発表でした。ククログのデータ駆動テストのエントリはつい最近お世話になったばかり。
SIerのイメージの「自分の責任にならないようにする」「できる人に負担がかかる」文化ってのは耳が痛いw
今はメンバーの違う2つのプロジェクトに関わっているけど、どちらもコードレビューが一方向になってしまっているので、うまく打破したいなぁと思います。
質疑では1時間に1回は最低コミットという点に関連して、コミットのタイミングについての質問がありましたが、ペアプロでの1回1回のまとまりが近いみたい。そこでぽろっと言ってた「自分が書いたコードは忘れるようにする」ってのが印象的でした。「コードを読んでも(書いた本人を含めて)誰もわからない」ではなく「コードを読んだら誰でも分かる」ようにしないといけないですよね。
DevOpsが引き金となるインフラエンジニアの進撃 どうする?デベロッパ(株式会社ソニックガーデン 安達 輝雄さん)
プレゼンメモ:
- 変化することは大切なこと。
- DevOpsは方法論であって万能ではない→直面している問題を捉えて何のためにDevOpsをするのか明確にすることが重要
- DevとOpsでGive&Takeの体制をつくり、1年くらいかけて開発スキルを学んだ。
- システム制御処理もRuby。全員がRubyの知識を持っているので共通化できる。
- DevとOpsの概念を取り去り、数人で20近いサービスを開発、運用できるようになった。
お話はOps→Devの立場でしたが、自分はDev→Opsの立場になるので、その場合、いきなり仕事で何かインフラをやろうとはせずに、趣味の範囲で色々とためしてみるのがよい、とのこと(質疑応答)。私もできるところからOpsの分野も開拓していきたいと思います。
今回のサクセスストーリーは、安達さんがずっと「DevとOpsの両方ができるハイブリッドなエンジニアになる」ということをモチベーションに取り組まれていたことが大きな要因だと感じました。あとは会社としての社風とかもあると思いますが(自分の会社と比較して)。
2013年の開発現場で求められるエンジニアとは?(パネルディスカッション)
- AWSが出た当初、同じ物を作ろうとしたが、Amazon S3だけは追いつける気がしなかったので、徹底的に使い込む立場にシフトした。一環として、社内サーバ購入禁止令を発動。
- キャリア戦略<実績。
- 今の環境でベストを尽くせない人は新しい環境でもベストを尽くせない。
- プレゼンは聞いている人は覚えてないと分かると、緊張しなくなる。
- ストレス耐性が高い人のほうがパフォーマンスも高い傾向はある。
- ドキュメントもコードも言葉。きれいなコードを書く人はドキュメントもきれいに書く。
- IaaSはAWS一択。上の人を巻き込んでメリットを理解してもらおう。
セッションでは聞けませんでしたが、大石さんの発言がインフラやクラウドに弱い自分にとっては、時代の流れと共にためになりました。
改めて、行った甲斐のあるイベントだったと思います。主催、発表者、参加者のみなさま、おつかれさまでした。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (111件) を見る