次の、
第26章~コードチューニングテクニック
とセットで読も🕺

感想

コードチューニング　＝　高速化プログラミング

について書いてる章。

コードチューニングは、

代替ツール検討やコードが正確か、リファクタリングなどの全ての検討と確認が終わってから、最終段階でやる

＝ツールがある程度出来上がって、動きはするけど、処理速度なんかを改善したい時など、

👉ある程度完成してからやる作業。

コードを書き始めた時に、最初から処理速度向上まで踏まえて書ける人なんてまず存在しないし、
それを最初から意識してやると、いつまで経っても改善点がわからない。
だって、完成してないんだから。

おそらく、

コードに携わる人とってには一番関心が高く、
ユーザーさんにとっては、ユーザービリティ（見栄えの良さとか使いやすさなど）が大事であって、裏側のコードがどうのはどうでもいい内容かなあ。

なので、

開発の世界に蔓延る悪しき神話は一読の価値あり！
（うそや迷信を信じ込んでいるエンジニアさん山ほどいたね〜〜〜）

開発環境が進化して、プログラミング言語も新しくなってる以上、過去の経験なんて何の役にも立たないんだけどね。
新しいプログラミング言語や開発環境であれば、自分の下手な経験は白紙にして、まっさらでやる方がいい。

プログラミングの世界でも、

• パレートの法則

• フィッシャーの基本定理

大事✨

詳細

見出しとしては、

1. パフォーマンスの概要

2. コードチューニング入門

3. 脂肪や糖蜜の類

4. 測定

5. 繰り返し

6. コードチューニング手法まとめ

7. 参考資料

8. まとめ

てな感じ。

以前の現場で、

（嘘みたいな本当の話だけど、）

コードの行数が少なければ少ないほど、処理効率が上がる

ってゆー悪しき神話を殆どの人が信じ込んでいて、その割に、

ルーチン分割のやり方とリファクタリングを取り入れていなかった

結果、

組織開発で一番重要なコメント（不要なコメントではなく、）を

書かない、あったら消す

をやってた。
コメントアウトしてる時点で、処理自体に全く影響のないのに、、、。
おっそろしい事するなあって思ってたら、

コード読めばどんな処理してるかはわかるから、コメントは必要ない

の一点張りだった。

そういう人ほど最終的には、

なぜ、この機能を追加したのか、誰がいつ追加したのかすらわからなくなり、改修しようにもできない自体に陥っていた、、、。

普通、

いつ・誰が・どんな目的で・何を作った or 追加した

などをバージョン管理情報として、コメントは残すんだけどね。

バージョン管理ツール（SVNとか）を使っても、

コメントなしだと、詳細がぱっと見わからないし。

まとめ

チューニング　＝　調整
💃ピアノが出来上がっていないのに、調律する調律師はいない🕺
👉どんな作業も、作業目的をはっきりさせることが大事。
リファクタリングすべき時にコードチューニングしても効果は薄い。

第５部は次で読み終わるし、

読み終わったら、プログラミングでいつも意識してる４つの法則について、【開発哲学_ちょいとブレイク】書こっと。

参考文献

他の記事でも触れた経営学の本だけど、

の第16、25〜27章あたりに、
今までのやり方を捨てずに、デジタル革命に乗り遅れた企業の失敗した原因が書いてて、興味があれば参考に。