2017/04/26 タイトルに「なぜ放置されるのか」を追加。（半分ぐらい、可読性の低いソースが放置される状況について話しているので） 「可読性が低いことが、問題として認識されていない」を追加
転職して、受注するソースが半分ぐらいクソなので、うんざりしてしてしまいます。
まあ、前職では須くクソだったので、それに比べたらマシ…とは思います。（新規開発したシステムですら、上層部の意味不明な押し付けによりクソになった）
エンジニアの方々は、ソースの可読性は重要だと、いろんな人から口酸っぱく言われていることでしょう。
もしくは、唐突に可読性の低いコードの修正を依頼され、不貞腐れていることでしょう。
なんとなく、そんな可読性の低いコードが生まれるのか、ざっと妄想して書いてみます。
なお、生まれる場合と、放置される場合の両面です。
見出しの下の太字文字は、そういう時に聞こえてきそうなセリフです。
時間がない
ソースの可読性？そんなのは後でいい！提供は目の前だ！
なお、私の知る限り、「後でいいから」と言って後で直したという話は聞いたことがありません。
とにかく納期が短い、もしくは納期が差し迫っている状態です。
そりゃあもう、システム提供しなかったらやばいかもしれませんもんね。
システム開発は、常に納期があるものなので、妥協が必要な場合があります。
そういう時は、可読性を犠牲にするのは、悪くない取引だと思います。
この、「あえて可読性を落としたソース」を「技術的負債」と呼びます。
（負債 = いつか返さなければならない、ということを意味する）
『C#実践開発手法』では、
との説明があります。
この技術的負債を返済せず、積み重なるとどうなるか…わかりますよね？
「可読性の高いソース」が「品質が良い」という認識がない
動いてるじゃん。修正する意味あるの？
可読性が低い状態を正当化する言い訳です。
既に生まれた、可読性の低いソースが放置されている状態です。
さて、この可読性の低い機能と似たような機能を新規に作成する時が来ました。どうなるか…（下に続く）
コピペ万歳
こっちに似たような機能あるから、コピペして作ったら早いよ。
可読性が良くても悪くても、コピペは悪です。
いや、たった２、３行とかのコピペも許すな！とか言うつもりはないです。
この業界でコピペというと、たとえば1000行ぐらいあるクラスをコピーして使うとかなので…
そして、一度コピペされたソースは、後続の人が次々とコピペしていきます。
後続の人は「もうコピペされてる」という免罪符があるし、共通にしてリファクタリングするとしても、修正箇所が「自分のソース」 + 「コピペ元」 + 「コピペ元のコピペ元」となるため、まず修正できません。
（コピペしないと作れない人に、リファクタリングを任せるのも、酷な話です）
要件が曖昧
また要件が変わっただと！？既存のソースを修正しなければならないのか…
大抵、炎上するパターンですね。
度重なる要件の変更に耐えられず、ソースが（システムと共に）崩壊していくパターンです。
これは…もうね。同情します。
発注者の問題もあるでしょうし、プロジェクトマネジメントがまずいとか、設計がクソとか、いろいろあるでしょうけど、プログラマーに罪はないと思います。ただ不運を呪うしかないです（たぶん）。
プログラマーの技量不足
こんなのできないお…(´・ω・`)
これもまぁ、珍しい話ではないと思います。
そもそも、「可読性が高い」ソースをどう書けばよいのか知らない、という場合です。
まぁ、「プログラマ歴がそこそこ長い」人間がこういう状態だと、救いようがないですが。
これに対して思うのは、
- レビューしろ
- 教育しろ
といったところでしょうか。つまり、技量不足でできないのは当然で、それに対する教育や修正する機会を確実に用意すべき、と思います。
（だから、今できないことを気に病む必要はない。次頑張ればいいの）
なお、新人や若手に対するレビューも教育もなく、ただ「なんでもいいからソースを書け」という職場は、ほぼ確実にブラックなので、さっさと脱出しましょう。
可読性が低くてもシステムは動く
動いてるじゃん。修正する意味あるの？（二回目）
もしバグったとき、責任とれるの？
バグらない一番の方法は、ソースを修正しないことだ
下の二つは、リファクタリングを主張したときに、実際に言われたセリフです。
死ね、と思いました。が、それを覆す主張ができなかった自分が悪いです。
なお、そのシステムは今頃クソコードに苦しめられているようです。（自分は余裕があるうちのリファクタリングを勧めたし、できる範囲でリファクタリングしていたので、今さら知ったことではない）
個人的に、可読性の低いソースが生まれ、いつまでも取り残される理由の第一位が、これです。
以下のような理由から、この話は出てくると思います。
- 上層部の、可読性の低いソースに対する理解が足りない
- 既存機能を修正するリスクを、「修正しないでいるリスク」より高く見積もる
- バグらない保証が担保できない
- バグることに対する罰則が異常なほど重い（どんな理由でバグっても、罰金取られるとか）
これには、別の見方もあります。
ソースコードを、あくまで「機械に対する命令」とみなす限り、可読性は重視する必要はないです。
可読性が低いことが、問題として認識されていない
システムは仕様通り動いていますけど、なんで修正する必要があるんですか？
よくありそうなのは、既存システムの保守を受けた場合でしょうか。
ソースを引き受けて内容を確認したところ、とにかくクソだったと、そういう状態です。
修正したほうが良いと分かっていても、あるべき姿への理解は浅いし、客が上のような状態なので、修正に必要な費用も出ないし…といった感じです。
可読性の低さを引き起こしたのは自分たちではないので、ひたすら理不尽で気の毒なパターンです。
これをどうすべきかというと、拡張性の低さや将来の保守費用の増大（可読性の低さ故に、修正難易度が漸増していくことによるもの）あたりをネタに、可読性向上のための費用を取りに行くか、さっさと撤退するべきだと思います。
クソコード（クソシステム）を相手にしていると、心が荒むと思うんですよね。
ましてや、何の愛着もない（受注したばっかりの）ソースをメンテするとなると、なおさら。
まだまだありそうですが、いったん区切ります。（後で思いついたら追加します）
なぜ、可読性が低いとダメなのか
上でちょっと触れましたが、ソースコードを「機械に対する命令」とみなす限り、可読性はどうでもいいです。
しかし、クソコードに触れた人（そして、それに怒りを覚えた人）ならわかるはずです。
受け売りですが、
ソースコードは、書く機会より人間によって読まれる機会のほうが圧倒的に多いです。
どれほど最初は有益なシステムでも、内部がクソで、ソースを読める人がいなければ、システムはそれ以上発展しません。
システムの発展性を阻害する、という意味で、可読性の低いソースは「悪」です。
私が大好きな言葉があります。
ソフトウェアの最終的な目的は、ユーザの役に立つことである。しかし、それ以前に、そのソフトウェアは開発者の役に立たなければならない。
『エリック・エヴァンスのドメイン駆動設計』第10章
この言葉は、エンジニアになって３年目ぐらいに出会いましたが、いまだに最も大事な原則だ、と思っています。
可読性を捨てるとき（例外）
こういう時は、可読性は無視されますが、正当な理由によるものとみなせます。
パフォーマンスチューニングが必要な機能
SQLとか、チューニングで何とかした結果、可読性が落ちるもの。速度が絶対的に必要な場合は、妥協点かとそもそも、言語がクソ
batとか。可読性確保するにも、言語機能が貧弱すぎて、どうにもならない
工夫で何とかするにも限度がある（そもそも、batはプログラミング言語なのか？）
といったところで、また。
可読性を上げるためにどうするか、というのもいずれ書きたい。（でも、リファクタリングの本はいろいろあるから…それ以上のものは書けない）
