アドベントカレンダーが空いていたので、なんとなく投下してみます。 プログラマの3大美徳 Perlの作者であるラリー・ウォール氏は、こんな言葉を残しています。 プログラマの3大美徳は、怠惰・短気・傲慢である。 ただし、この3つは、どれも通常の意味ではありません。今回は、この「怠惰」を掘り下げてみます。 極論: プログラムは正しく動けばいい 実用品としてプログラムを書く場合1、そのプログラムの価値は、作るのにかかった時間やコードの分量に比例するものではありません。例えば、仮にある人が2ヶ月かけて、Windowsのメモ帳と全く同じ動作をするプログラムを書き上げたとしましょう。きちんとできあがったとしても、Windows環境下では「すでにメモ帳がある」ということになってしまって、あまり意味がありません。 プログラムは（多くの場合）実用品です。内部の処理がどうとかどんなツールを使ったかとか、そういう

はじめに この記事は、ポエム Advent Calendar 2016 15日目の記事です。 過去 半年前に入社したときのSQUEEZEのコードは、いわゆる不吉な匂いに満ちていました。 重複したコード 長すぎるメソッド 巨大なクラス 長すぎるパラメータリスト などなど。 ただスタートアップでスピード重視の開発をしていたので仕方なかったのだと思います。 現状 ※ まだバグゼロは実現してません。少なからずバグは存在しています。 サービスをよりスケールさせていくために、それに耐えうる品質が求められています。 バグゼロに向けて、現在次のような取り組みを行っています。 テストコードを書く エラートラッキング リリースサイクルを短くする 古いコードのリファクタリング・破棄 コーディングスタイルの統一 コードレビューの徹底 これらに関しては、バグゼロを実現した話とその後の顛末 - Cybozu Insi

ラリー・ウォールの言葉に、「プログラマーの三大美徳は、怠惰・短気・傲慢である」と言うものがあります。 怠惰については以前に考えてみましたが、今回は「短気」について考えてみます。 「短気」の意味 もちろん、この「短気」も普通の意味ではなく、プログラムの動作が遅いことを許容できない、という意味合いです。人間関係については短期になっても得なことはありません。 遅いことによる問題 遅いことそれ自体による問題 セキュリティ上の要請があって「遅い方がいい」プログラムもまれに存在します1し、ユーザーインターフェースのプログラムの場合は「ユーザーの反応速度に合わせる」必要がありますが、そういう場面でない場合、動作が遅いことに対してはデメリットしかありません。Amazonによれば、サイト速度が0.1秒遅くなれば、売上は1%低下するとされています。 負荷の問題 通信などの待ち時間が多くて遅くなっているプログラ