プログラミングの真髄

短いロジック(少ない手数)で、求める結果(=最大の効果)を得ること。

ロジックが短いとは、表面上の短さでなくそのロジックで行われる処理
の総量が少ないことを指します。

短いロジックはロジックの実行に要する時間が短い、即ち、処理速度が
速い。

何もしないのが一番速い、が真理。ではあるものの、何もしないわけ
にはいかない。

実装の前にすべきことはロジックで実現すべき処理全てが本当に必要か
どうか機能要件を再検討し、その処理のうち必須ではない部分を削れる
なら削ること。

機能要件が膨らむことはあっても減ることは殆どないのが現実...かも
しれないが、不必要な(あるいは費用対効果の薄い)ロジックを
作りこむことを避けられるに超したことはない。

機能を削るのは限度があり、外部要因によりできないケースも多いとは
思うが、機能要件を再検討する事は必須だと思う。

充分、機能要件の再検討を行った後に初めて、実装に踏み込み、
求める結果を得られる最短・最速のロジックを自分にできる範囲内で
考える。

何もしない状態に近づけるためにロジックをできる限り短くし、必要
最小限の処理以外は何もしないロジックにするのである。

ロジックをできる限り短くするからといって、ただ単純に短くするの
では駄目。

短く書き換えるのは処理速度を書き換える前よりも速くするため。

書き換えたことで処理速度が遅くなるような変更は変更前の状態に戻す。

ロジックに何もさせないのが一番速いということを肝に銘じておこう
(自戒も込めて...)。

つづく...推敲中