「何故クックパッドのサービス開発の進化は止まらないのか」のスライドは開発者必見!!

仕組み

f:id:ksakae1216:20070710200056j:plain

みなさん、コウタロウです!!

 

今日はタイトルについて。

 

  • 最後に
  •  

    スライドの紹介

    今日、素晴らしいスライドをはてなブックマークで発見!!

    speakerdeck.com

     

    いや~すばらしい!!

     

    なにはともあれ、まずはスライドを見て下さい。

     

    開発者は必見!!

    開発者は必見です!!

     

    私が開発している現場をこのスライドのようにまとめたらどうなるだろう?

    恐らく、2ページくらいで終わりそう。。。

     

    1ページ目

    コミットのルール:コンパイルエラーにならないこと。

     

    ソースコードレビュー:有識者が行う。但し、時間がないので最初の1本だけ。2本目以降はレビューせず、ソースチェックシート(命名規則などを記載)のみ。

     

    2ページ目

    単体テスト:開発者が行う。自分が作成したプログラムを自分が作ったテストデータで行う。

     

     

    うわ、こうしてみると品質悪そう〜。

     

    今の現場ではこの部分の仕組みも本当は、自分が決めなければいけないのに。。。

    猛省です。。。

     

    みなさんも、自分の現場の開発をスライドと見比べてみてください。

    見直すいい機会になりますよ。

     

    クックパッドは、運用しながらになるので、新規開発の場合と比べられない部分はあると思いますが、それでも参考になるところは山盛りです!!

     

    私の中で衝撃的だったのが、RubyだとJavaやASPの半分のサーバーでいけるんじゃないかという文言。

     

    インフラ構築も経験してきて、且つプログラムの性能、SQLの速度も考えながら開発をする経験をしていますが、言語によってサーバー台数が変わるとの考えはありませんでした。

     

    非常に衝撃的で今後は、この観点も頭に入れてアンテナ貼っていようと思います。

     

    また、自動化できる部分を極力自動化(デプロイ、コードチェック)し、人間が確認すべき所(コードレビュー、スタッフが開発中の画面を確認)は人間が確認する。

     

    スライドを見ると、「これだったら、不具合発生しないだろうな」と納得の開発体制になっています。

     

    最後に

    いや、非常に、勉強になりました。

     

    少しずつでも改善していこう!!

    コメント

    タイトルとURLをコピーしました