を、読んでいたら、可読性を高めるために役立つプログラミングの原則を紹介されていました。
オレオレ版を書いたら面白いかな？と考えました。
和田卓人「コードコメントには Why not」
コードには How
— Takuto Wada (@t_wada) September 5, 2017
テストコードには What
コミットログには Why
コードコメントには Why not
を書こうという話をした
「設計の段階で検討して捨てた候補を捨てた理由」を書きましょうって話だと思います。 あとからソースコードを見た人が「素直に設計したら別の方法になりそうだけど、なんでこんな実装になっているの？」に応える内容をソースコードコメントに書けってことだと思います。
実際やろうとするとすごい難しいです。 実装終わった時は、出来た達成感からソースコードコメント自体書くのをわすれそうになるし。 「最高の設計できたぜ」って気分から、捨てた設計をすっかり忘れているんですよね。
難しいので好きな格言です。
参考
植山類「ダメなコードを改造しなくてはいけなくなったときは、ダメさを片っ端から潰していくしかない」
リファクタリングの指針というか態度として本当にその通りだと思うし。 ダメさを片っ端から潰していくと見えてくるものがあるのも、本当にそう。
リファクタリングは、解像度が低い段階だと、「古いライブラリを捨てましょう」とか「○○パターンを適用しよう」とかそういう設計の話だと思うかもしれない。 けど、設計の善し悪しを考える以前に、インデントが雑とか、変数名がわかりにくいとか、コメントがまぎらわしいとか、些細な悪いがあるだけで良い設計は見えません。
「なんとかを導入しましょう」みたいなリファクタリングの作戦を考える前に、 まずこういう細かい悪い箇所を直せ。全部直せ、ひたすら直せ。と言うことを教えてくれます。 「機能追加を優先した方が良い？」とか「既存のソースコードを壊してしまう？」とか脳みそが生み出してくる、リファクタリングしないで済ますための言い訳にストレートに現実を突きつけてくれます。
勇気を与えてくれる格言です。
マイケル・ジャクソン「プログラム最適化の第一法則: 最適化するな。」
プログラミングをしていると、すぐに無駄な動作では？とかインスタンス作りすぎでは？とか考えてしまいがちです。 「速いプログラムが書けたらかっこいい」「知っている最適化手法を使ってみたい」などの功名心ではないかと思います。 実際、機能として動かしてないうちに、そんなことを考えるのは早すぎます。 動かしてみたらボトルネックにならないことがほとんどです。 目についたところだけを最適化しているので、どちらかというと、ボトルネック以外を最適化しがちです。
現代のソフトウェア開発は、早い段階で結合します。 すくなくとも結合して、システム全体として動かしてみて、遅いことを確認してから最適化すれば十分間に合います。 この格言1975年なんですよね。僕より年上です。 ずっと昔から言われているけど、プログラマーは克服できていないみたいです。
クヌース先生の「時期尚早な最適化は諸悪の根源だ。」が1974年で先だとか、ロバート・C・パイク「推測するな、計測せよ」の方が意味がわかりやすいとかあるんですが、 「プログラム最適化の第一法則: 最適化するな。」は、言葉として面白くて好きです。
