■コードを綺麗にするのは読みやすくするためじゃない

https://type.jp/et/feature/26796/

もうホントこいつって害悪だと思う

コードを読むのが下手なエンジニアのためにコードを綺麗にするのは時間の無駄かな、、と。

この発言にもあるように「コードを綺麗にする＝読みやすくする」ってことだと勘違いしてる

コードを綺麗にするのは「バグを少なくする」ためであって読み手のためじゃない

グローバルに一文字変数を使って困るのは「どこでそれを触ってるか分からないから」であって「読みにくいから」ではない（まぁ読みにくいけど）

特に昔だとLintもないし変数の参照先を探すのはgrepぐらいしかなくて

$iとかだと$iiもひっかかるし$iの後ろにスペースがあったり無かったりするともう探すのは不可能に近くなる

それでも動いているなら最悪問題無いんだがバグの修正時にめちゃくちゃ困って

「作り直すしか無いな」

ってなるのでビジネス的にも大きな影響が出る

「どんなコードでも動くコードを作るのが正しい」「done is better than perfect（完璧を目指すよりも、まずは終わらせることが重要） 」のスタンスが効率的だろうなぁ、、と思うおいらです。

これも元の言葉の意味を曲解していて、「終わらせることが重要」というのはバグがあって良いわけじゃない

例えばログインボタンを実装したときに、ユーザー名とパスワードに何を入れてもログインできる状態にするのも「終わらせること」だし

開発初期はとりあえず画面が必要なのでそれで良いかもしれない

ただこのままリリースできるわけではないし、プロダクトとしては「終わっていない」

パスワードを平文で保存して実装するのも「終わらせること」ではあるけれどそのままリリースしていいわけではないし

下手に動いてしまうとそのままリリースされたりもするのでよりタチが悪い

この言葉の重要なのは「better than perfect」の方であって「done」の方ではない

全てを完璧にする必要は無い（し、そもそも完璧は定義できない）ので「perfectでなくていいよ」というだけ

バグがあったり不十分だったりセキュリティ不備があって良いわけではない

毎日論理構成の中に浸ってる人は、推理小説は向いてるかもしれないですね。初期にちょろっと設定したグローバル変数が、最終的な結果に大きく影響してくるとか、「ここで使われてるのかー」みたいな感慨とか。

残念ながら「ああ、まともなコードしか読んできてないんだな」としか思えない

例えば「ユーザーの名前と住所は設定できてるから、性別を設定できるようにして」という依頼があって

コードを確認してみるとuser1, user2, user3という変数が100個用意されていて、user1.name = 'hoge', user2.name = 'gaga' って感じで100行書いてあって、更に住所で100行あって、性別も同じように100行追加しろっていうコードを読んだことが無いんだろう

そしてそのコードのどこかで住所設定が間違えているから確認しないといけないような作業をしてないんだと思う

小説で言うと同じ文章が100ページ続いていて、その中のどこかの漢字が違っていて、そいつが犯人、みたいな推理小説、面白いか？

他にも足したり引いたりこねくり回された変数値が最後に定数値で上書きされてたり、UserのオブジェクトがいきなりWeatherのオブジェクトに置き換えられていて、name属性に晴れとか雨のデータが入ってたりしたことがないんだと思う

汚いコードは伏線を回収しないし最終的に犯人も分からないし無駄に長いので推理小説には全く向いてない

で、やっぱりこういう汚いコードの問題は「バグが混入しやすいかどうか」であって「読みやすいかどうか」ではない

下手するとuserオブジェクトを100行ずつ書いてくれてる方が読みやすさはあるかもしれないが

「user36だけ住所が設定されていない」といったバグが混入し得るし、それを確認するのに多大な労力を必要とする

人間は誰もが間違いを犯すので誰もがバグを混入させる危険性があるんだけれど

その危険性は最大限まで下げるように努力するべきだし、インシデントを引き起こすことでビジネス的なインパクトも大きい

現場猫案件と似たようなもので事故は無くせないけれど、だからといって適当にやって良いわけじゃないし

「優秀なエンジニアは汚いコードですよ〜〜〜」

みたいなゴミ意見を広めるのは害悪でしか無い

Permalink | 記事への反応(2) | 09:21

ツイートシェア