プログラマにとって大事なこと。
『めんどくせ』って思うこと。
その面倒さがどこからきてるのかというのを考えて、理解する力が大事です。
もしそれを理解できたなら、もしかすると面倒をなくす方法が見つかるかもしれない。
例えばデータベース周りとか、やってること使う機能ってほとんど同じなんだからそれをよりシンプルに、楽に使うためのWrapperを書くことだってできるかもしれない。
というか実際一定以上データベースを使用する場合にはまず真っ先にそれをしますが。
特に難しい機能なんか一切ないんですからまずWrapper作って簡単に使えるようにすべきところ。
主要なコマンドは配列/連想配列渡したら勝手にやってくれるようにする。
手でやったらミスりかねませんしね。
そういうのがプログラマのクオリティを上げていくんだと思います。
『めんどくせ』は大事。
これはガチ。
実際クソ面倒臭いコード書いてしまう人っていますけどね。
技術検証以外でそれをやるのは基本的にアウト。
そんなに高度なことやる場合ってそんなに多くないでしょ？ って。
コードは可能な限り短く、かつ可読性を高く保つべき。
なぜかって、長いと手を入れるのが面倒だから。
そして長いと見落としも発生しやすくなってバグの発生率が上がる。
さらに、長いと影響範囲が相対的に広くなりやすい。
まあ、機能を作るとき単一の機能に切り分けられてないから長くなるんだろって考えを含んでますけどね。
やりすぎるとメソッド数が膨大になる場合もありますけどね。
それはそれでアリなんじゃなかろうか、と。
それだけの機能がないと実現できないシステムなら、ですが。
たまにあるのが同じ動作してる別名メソッドが複数並んでる場合。
これは、普通にアウトですけどね。
そういう意味では分類と命名は正しくすべき。
そこが正しいならそういう間違いの発生率は低くなるんだから。
ちなみにこれは、機器の性能が上がってきた最近の考え方ですけどね。
昔は機器のスペックが低すぎてパフォーマンス上げるために無駄な分岐とかを回避するためにそういう作りになってるシステムとかがありました。
で、今もそういうシステムに『下手に手を入れられないから』という理由で共通化せずにそのまま追加追加で行ってしまってて正直誰がどう手を入れてもバグが出ないはずがない、とか思えるシステムも実在します。
何度か面倒みたことありますけどね。
結局必要なエビデンスが多すぎて根本的な作り直しができなかった辺りは残念。
と、言ってもそんなにデカいシステムじゃねぇんだけどなぁ、と、今でも思う案件は数個ありますけどね。
そのシステム名聞くたびにどこかしらで爆発炎上してるんだから定期的に思い出すのも仕方ないと思うんですよ、ええ。
というかあれだけ爆発炎上してて作り直すという発想が出ないのはなかなかすげぇなと思わなくもないですが。
