性能よりも読みやすさを重視するマインドでまいるど～

理由は ソースコードをメンテしやすい形に改修するより性能を向上させる改修のほうがカンタンだから。

例えば、DBへとアクセスを行いデータを取得する処理がある場合。

DBからのデータ入出力においてボトルネックとなりがちなのが DBへの接続処理

１回の接続であればさほど気になることはないが、何度もDBへ接続処理を行うと処理の遅さが気になってくる。

これを抑えるためには１回の処理でまとめてDBからデータを取得して接続処理の回数を少なくすればいい。

それは分かっているんだけど、最初の実装時点では 性能要件を満たしている限り遅くてもいいからシンプルにデータを取得する べき！！

理由は以下。

まとめて処理するとコードがどうしても複雑になっちゃう

複雑になったコードは読んで理解するのが困難。

読めるコードを改修するのは容易いが読めないコードを改修するのは困難。

複雑だとバグも出やすいし、テストも漏れやすい。

趣味であれば自由にできるけど、仕事でコードを書いている場合。

性能が悪いから改善して！というタスクはユーザーに関わるタスクのため今必要な仕事として着手できる。

しかし、コードが読みにくいっていうのはユーザーにとって何の関わりもないタスクだし、後回しにされやすい。

性能が事足りていれば手を付けられることもなく、次にそのコードに触るときは新項目を追加する等DBや処理内容に修正が入るときになる。

この時点でコードが複雑になっているとデグレードが恐ろしくてリファクタリングしにくくなっちゃう。

リファクタリングしてデグレードしたら原因の切り分けがちょっと大変になるし。

確かにまとめて処理した方が早いのだが、その差が0.2秒だとかの差である場合も多い。

数字上は確かに早くてもユーザーの使用感としてはどちらも変わんねぇよ？ってなる。

また明らかな差があったとしても使用していてストレスを感じないのであれば上記に書いたデメリットを鑑みてソースコードをシンプルに保つべき。

この手を最初から期待するようになると技術者としてど～なの？って感じだけど・・・

今はクラウドネイティブの時代でサーバースペックの変更がほんの数分でできるようになり、ハードウェアの変更に対する敷居は下がっている。

組み込み系やビッグデータの取込処理ならまた話は別だが、少なくとも昔みたいにメモリまで制御意識して処理の高速化を図るなんてことは少なくなった。

というコードの組み方にするのが今のワタシのベストプラクティス。

一回作り終わったら縁を切るんじゃなくて、段階を踏んでちょっとずつ改善していく心構えで実装していかなくてはいけないと思うよ。

まぁ、コードの複雑さに泣きそうになるときって大抵他人が書いたコードを改修するときなんですけどね・・・