読書メモ ・「BEST SOFTWARE WRITING」 プロジェクト・マネジメント・システム「FogBugz」を開発。MicrosoftでVBAを設計。 ○印象的な言葉 ・Ruby：奇妙だが、魔法のように魅力的で、美しくエレガント ・テスト・メトリクスではテスタを測定できない（ラリー・オスターマン）。テスタのクオリティや生産性を測定することは機能しない。 どんなメトリクスも、テスタやプログラマがメトリクスに合わせて最適化し、スコアが高くなるように誤魔化す。 ・Python：{}で囲むのではなく、インデントするだけ。C系の言語は、人の目はインデントをブロックの定義として認識するが、 コンパイラのほうは{}を見る。１つは人のため、もう１つはコンパイラのためと、２通りの方法を使う必要がある。 コードの見た目と意味が一致していない。 ・ソフトウエア開発はデザインであって、製造ではない ・C++は年々、迷路のように複雑で理解不能なものになっていった ・ほとんど誰にも使われることがなかったSGML ・人間の理解能力を超えたH.323 ・週に残業40H時間以上働くプログラマは、成し遂げる仕事は少ない。プログラミングを日に8Hより長くするとクオリティが下がり、 8H以降にする作業は負の作業にすらなる。プログラマは追加の時間はコード書き以外のことをして過ごす。脳が活動しているから。 ・新しい社員が仕事を覚え、生産的になるには１年かかる ・燃え尽きた社員の代わりを採用するコスト：採用にかかる経費、新しい社員が仕事を覚えるまでの低い生産性、他の社員が採用面接や 採用後に仕事を教えるために取られる時間など。 ・ソフトウエア搾取工場 ・「強い型付け」に代わる「強いテスト」（ブルース・エッケル）。プログラムの正しさを確認するためにはユニットテスト。 コンパイル時により多くのテストをする目的で型を作っていくと、コードが難解になる。 ・スクリプト言語のような動的型付け言語は静的型付け言語より常に遅い ・テストされていないものは、壊れていると思え ・優れたハッカーは自分の使うツールに独善的になったりせず、手近にあって問題を解くのに使えるものなら何でも使う。 問題に取り組もうとしない人よりも、ひどいプログラミング環境から信じられないようなことをやってのける人。 ・ビジネス・プロセスのデザインとソフトウエア・アーキテクチャの間の類似性。現代の複雑なビジネスを正しく構成するには ソフトウエア・アーキテクトのスキルが必要。 ・エクストリーム・プログラミングは産業になり、硬直化してしまった。硬直した必須のプラクティスの教典へと変わっていった ・人と人の対話のためのソフトウエアをどのように設計すればよいか、本当に研究している人はほとんどいない。 ソーシャルソフトウエアを開発者が、ソフトを使うグループに関する社会学や文化人類学について考える必要がある ・禅的体験 |