素晴らしいプログラムはほとんどが美しい。
それが記述されている合理的な理由があり、また、最善の記述で書かれている。
パッと見ても「整ってる」と感じるし、細部で見ても「いいなぁ」と改めて感じる。
そして。
ダメなプログラムも一目で分かる。
「どうしてこうなった？」と聞いても、やっぱり理由が釈然としない。
最近驚いたこととして、そんなダメプログラムを引き継ぐときの前任者の発言がある。
注文IDとトランザクションIDがどちらの意味ともとれる曖昧な項目があったので、「これはどっちと受け取ったら良いんでしょうか？」と聞いたら、「どちらともとれるゆるふわな項目としてある」との回答を受けた。
プログラミングで「ゆるふわにしている」と聞いたのは、プログラミングを始めて20年来初めてで、かつ、そんな発想があるのか！と、あんぐりとしてしまった。
「ゆるふわ」自体はさすがに一つだったが、その他にも様々な疑問に思う点があった。
一つの大きな要因としては、「脳で汗をかく」ことを避けている人が作ったプログラムはダメだということだ。
「時間が無かった」という言い訳をよく聞くが、時間が無い中、リリースに耐えうる品質をどう担保するか。
「ここまでなら出来ます」と見切り、マネージャー層に伝える。
もしくは、残業してでもやりきる。
その時点でベストな解は変わるし、いくらでもある。
「バレなければ手を抜いて納品してしまおう」
「このくらいの緩さはゆるして欲しい」
ベストに向かって考えることを放棄し、それが見逃された現場のプログラムは悲惨だ。
それはメタボリックな肉体のようなもので、一見動くが、長期的にはとても耐えられないものとなる。
社会人になって20年で10社超という、そこそこ多めの現場を見てきたが。
８割の現場では、大なり小なりそんな歪みのあるプログラムが動いている。
ただ。
だからこそ、私のような外人傭兵部隊に近いフリーランスエンジニアに、割と良い報酬で仕事が回ってくるのだが。
入会申込
ログイン
