【開発哲学3_26】〜『CODE COMPLETE第２版 第26章(下巻)』の感想〜コードチューニングテクニック
感想
コードチューニングの実践的な方法について書いてある章。
大きな改修は、リファクタリングやコードチューニングではなく、
設計自体を見直す必要も冒頭で書いてるし。
コードまではできたけど、処理速度を改善したい
って人は読んどいて損はないかなあ。
ただし、
コードチューニング ＝ アンチリファクタリング
になることもしっかり例示してる。
リファクタリングでコードの読み易さまで求めるなら、
一長一短あることを肝に銘じた方がいい。
処理速度を上げるために、敢えてこういう書き方になっていることをしっかりコメント行を挟んで残すべきかな。
じゃないと、
なんでこういう書き方をしてるかわからない人は、
読みにくいから
ってだけで、
安易にコードを読みやすいように書き換える（リファクタリングする）可能性が高い。
👉処理を流してみたらパフォーマンスが落ちたなんてことになりかねない。
自分がその部署にいるうちは聞けばいいかもだけど、すでにいなくなっていたら、、、って感じ。
システムの寿命は長いからね。
詳細
見出しとしては、
ロジック
ループ
データ変換
式
ルーチン
低水準言語への置き換え
物事は変わったように見えても、実は変わっていない
参考資料
まとめ
って感じ。
最適な方法（＝ベストプラクティス）は、
要求内容や選択したプログラミング言語、データ構成、それまでの処理の流れなどのその時の状況により、実際に、ベンチマークを設定して、何度も処理を流してみないとわからない。
作って検証までした本人には、
わかっても、エビデンスやログが残っていない限り、結果がわからないし。
そんな物を後任者に引っ張り出させる暇があったら、コメントを残してた方がコードだけでわかるから親切。
新しいプログラミング言語で、
ここで挙げられている方法ばかりが正解ではなくなってきてはいるかな💦
例えば、GASだと
二次元配列でスタックを使った方が、一次元配列でやるよりも、処理時間が単純に100倍は改善されるとかね。（％でいうと10000%改善）とかね。
ただし、
処理速度改善が求められる状況の本質と、
改善策を導くやり方や考え方の本質は変わらない。
👉色々なやり方があるんだと知る、触れる
まとめ
コードチューニングについては、前章含めて読みながら、色々な方法を実践あるのみ。とりあえず、
💃最善は善の敵🕺
デザインもそうだけど、
やり方はひとつじゃないってのが、唯一不変の答え
ここまでで読んだ
テスト、デバッグ、リファクタリング、コードチューニングなどの方法を、
いつ、どこで、どんな時にやるのが最適なのか
の勘所を知ることが重要
なのがよくわかる！！！！！！！！！！
さてと、
第5部も今日で終わったねえ〜〜〜〜
ためになるね〜〜〜💃
ためになったよ〜〜〜🕺
コードに関する作法はここまでって感じで、
いよいよ残り9章✨
