「遅く念入りな仕事は早すぎる最適化」by Paul Graham氏を再び思い出す | 「ぼくはこうしてプログラミングを覚えた」をどう読みましたか？ - F's Garage

「ぼくはこうしてプログラミングを覚えた」をどう読みましたか？ - F's Garage - BLOGOS（ブロゴス）

・・・フェイスブックのエンジニアで史上ベスト３に入るといわれるEvan Priestley氏・・・「質v.s.スピード」ではなく「質＝スピード」・・・「コードが最悪だったとしてもフェイスブックはどエラいサービスになった」・・・「後から、彼が頑張って直した」・・・「コードが最悪でも成功した」理由は・・・「想いを実現したいと思った人が書いているから」・・・プログラミング能力と、サービスを作る能力は全く別のもの・・・「質とスピードの両立」・・・ただし、優先されるべきキー値は、「絶対的に時間」・・・「コードの質にこだわらずに、スピードを優先した」・・・「コードの質にこだわっていたら、三振した」というのは最悪・・・・「判断力をつける」ということ・・・「あえて完璧にしない」・・・判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすること・・・

本当にそう思う。

質が良くても遅いコーディングはアプリケーションにとってリスクだ。たとえ良いコードでも、ユーザーに受け入れられないアプリケーションコードは無駄になる。逆に質が悪くても現実に耐える早いコーディングはチャンスを生む。ユーザーに受け入れられなくても別のコードを書く時間を得られるから。

だから「カッコいいコード」は目指さず、カッコ悪くても「現実に動くコード」を目指すことが重要だと思う。つまり、まずはスピードを優先させて、あえて完璧を目指さない。

記事ではその行動原理の元を「判断力」と呼んでいるようだけど、自分の言葉でいうとそれは「優先順位」だと思う。スピード優先を基本としながらも、時には質が優先されることもあるから。

「今、何をすべきか、何をすべきでないか」このバランス感覚を常に磨く必要があると思う。

これはPaul Graham氏がおっしゃる「遅く念入りな仕事は早すぎる最適化」に通じると思う。

琴線探査: 遅く念入りな仕事は早すぎる最適化 - 「ハッカーと画家」Paul Graham著

最適化はできる時にやればいい。最適化しなくても現実に耐えるコードであれば、最適化する必要はない。そう思う。