読みやすいコードに対するエンジニアのレベル

「ソフトウェアエンジニアの心得」で説明している資料からの引用です。

---

1. 読みやすさどころではない
   • 初心者の場合には、読みやすさまでは注意がいかないし、コーディングが終わった後でも、読みにくいかどうかが判断つかないレベル。
   • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
2. コーディング中に気づかない
   • コーディング中はコードを書くことにのみ意識がいき、読みにくいコードや重複したコードを書いているかどうかまで注意が回らない。しかし、コーディングが終わった後で、見直してみたらそれに気づき、修正するレベル。
   • プログラムは動作すればよいと考えてしまい、デバッグが終わったら読み易さに対して無頓着。
3. コーディング中に書き直す
   • コーディング中でも、常に読みやすさや改善すべき点に気づき、コーディング中にどんどん修正するレベル。
4. デバッグ後も重要だと認識している
   • 単体テストでデバッグが終わっても、コーディングが終了したとは考えない。さらにコードを書き直して出来る限り綺麗に読み易くして、コーディングが終了したと考える。
   • 常にコードをクリーンにすることを心がけている（ボーイスカウト・ルール）。

このおおざっぱなレベル1からレベル4ですが、社会人となってどのような開発組織でソフトウェア開発を行ってきたかによって、4、5年以上のソフトウェア開発経験があっても、レベル1かレベル2程度であったりします。

さらに、テスト駆動開発によるリファクタリングを経験したことがない人は、テスト駆動開発でリファクタリングが安心してできる開発に移ってきても、「Red-Green」で終わってしまい、「Red-Green-Refactor」ができなかったりします。

コメント 1

今日も読み難いコードでモチベーションが急降下でした．首切りで来週末で抜け出せるのが，悲しいより嬉しいくらいです．

バリデーションと書いたメソッドの中で、ネットワークに繋いで画像のダウンロードとか正気ですか？ネットワークエラーとバリデーションエラーを混在させておかしいとは思わないんですか？エラー処理を切り分けるという発想はないんですか？素直に2パス3パスでバリデーションしようとは考えないんですか？areaをareと略すのは止めましょうよ．一文字減らしたせいで混乱増えるよ．他にもゴロゴロ．
継承の乱用を始め，オブジェクト指向は全く理解してないご様子．デザパタを使えば楽になる部分もアチコチにあるんだけど，そんなの夢のまた夢．

それで文句を言ったら首切られたし．意見は許可されない．コードは糞汚い．でも保守は必要．いったいどーしろと．日本のIT業界の未来は暗いなあ．


この四段階のレベルには，それを超えるレベル０とでもいうべき層がいるような気がしますね．

レベル０：よみやすさ，なにそれおいしいの
○どんな汚いコードを見ても無頓着．リファクタリングの「匂い」がプンプンしてるコードでも，彼等の感覚には全く臭わない．言わば視覚や嗅覚が完全に破壊された状態．目や耳，鼻と言った感覚を完全に封じた「手探りプログラミング」とでも名付けましょうか．
○プログラミングの際にコードを読む習慣がない．コードも結果も見ずに，ただ自分の見たことのあるコードを隙間に押し込むだけ．まるでゴミ箱に入るだけゴミを押し込んで，臭い物に蓋をしたらあとは自分には関係無いとでもいうような．彼等にとってゴミコードとは，自分達が片付けるものではなくゴミ回収の人に押しつける程度のものなんでしょうか．

by TM (2014-03-21 00:34)