Q&A
元COBOLerからの怒りのコメントですw
COBOLで書けば、似たような見た目になるのは事実ですが、見た目が同じでも、ほっとけばかなりづらくなるので、構造化プログラミングを取り入れ読みやすいコードを意識するようになりました。（日本だとたぶん８０年代の話。）
と書いてプロフィールたら、tacsheavenさんもCOBOL書けるみたいですね。
読みにくさに関しては言語の制限以前の問題であることの方が多いというのが印象です。
最近開発をしていて思うのはコードリーディングは自分でコード書くより大変な時があります。
なんとなく、自分はコードリーディングが下手なのか、書かれているコードがおかしいのか、大した動作をしていないのに、ものすごくコードを読むのに時間がかかることがあります。
読みやすいコードを書くのは基本ですが、現実は読みにくいコードをなんとか読まなければならない状況の方が多いと思っており,共同開発者やオープンソースコミッターがデザインパターンに沿ってコードを書いていることを期待してはいけなく,最近では無からコードを生成する能力に比して,読みにくいコードでも読める力のウエイトの方が実務では大事なのではないかと思うようになりました。(自分が1から書けば良くなることがわかってる状態だとしても,何がしたいのかをコードから読み取らなければならないことが多いからです)
どうすれば読みにくいコードでも効率良く読み進めることができるか方法を思索しています。
最近ではものすごく時間をかけて調査した結果、些細なバグの原因が全くそのクラスと関係ない場所で定義されたメソッドで副作用起こしてるから等がありました。
特に読みづらいと思ったのは以下のような特徴を持つプロジェクトのコードです。
- moduleと継承が混在していて名前空間で分かれていないメソッドの呼び出し(どのファイルで定義された関数,メソッドなのかがわからない)
- そのスコープにおいて有効な変数が多すぎる(やむを得ない場合もありますが一時変数すらインスタンス変数に設定してあるものなど,インスタンス変数の定義場所と使用場所の区別がつかない場合など)
- 処理の途中で違う処理が挟まってる(単一処理できないこともありますが)
- 継承の多用(概念的に綺麗であれば大丈夫ですが分岐や深過ぎる継承同じ概念でまとめられるはずの継承)
- 大き過ぎるメソッド
- 小さすぎる大量のメソッド(的確に切り分けられてないと定義を飛び続けて元のコードの処理を追いづらくなる)
- 処理フローがめちゃくちゃなメソッド（名前と実行してる処理が違う,名前に対して色んな処理をしすぎ）
- 同じ処理が複数ファイルに散在している(読みづらい上に一箇所の変更が複数ファイルに伝播して直すのも大変)
このような特徴を持つコードでも読む時に意識すると読みやすくなるってことありますか？もしコードリーディングで意識していることがあれば教えて下さい。(ファイル上に存在しないメソッドは継承,標準ライブラリ,mixinで的を絞るなど)
よろしくお願いします。
回答6件
0
命名がすごく大事だと思います。
コメントがなくても意図が伝わるようなコードを書ければベストなのではないでしょうか？
http://qiita.com/chooyan_eng/items/72f86a2ce2ca67d3b4a4
個人的にすごく参考になった記事です。
後はメソッド分割。テスタブルなコードを書くことでリファクタもしやすくなります。
投稿2017/02/24 00:38
総合スコア310
0
ベストアンサー
はるか昔からコードの解読しやすさというのは永遠の命題でして（ちと大げさ？）、人がコードを書く以上は避けられないことになっています。
※がちがちに規則を決めて、誰が書いても似たようなソースにしかならないようにする、というアプローチを取ったのが COBOL というのは言い過ぎですかね？
最近はリファクタリングツールや、ソースの整形ツールがあるからまだしもですが、昔はそんなのありませんでしたし。
結局のところ、コードリーディングについては行う人のスキルに依存するしかない、でしょう。
せいぜいがツールを使って、自動整形とか自動で不要なローカル変数を消してしまうとかくらいでしょうか。
あとはデバッグに関して言えば、コードの全てを追いかけようとはせず、まず問題が起きている場所を特定すること。エラーになるとすれば、何らかのエラーを引き起こす情報が変数にセットされたわけですから、そこから変数の内容を全部洗いだして、逆にたどる（どこでその変数の内容がセットされたのか？）、くらいですかね。
投稿2017/02/23 09:07
総合スコア13703
私も2000年問題対応をしたクチですので、そりゃもう古いCOBOLのコードも読みましたし書きましたとも（ｗ
構造化なにそれなコードばかりでしたねえ……
そんな、貴重な体験がたくさんできるのもCOBOLの良さですね。（ヤレヤレ）
COBOLの話ってする場所がないのでつい、話題がそれてしまいました。失礼しました。
やはり読みにくいコードを読むプラクティスみたいのを考えるのってあまりないんでしょうか。
読めば大体なぜ読みにくいかは分かるのですが,読みにくさのパターン化はしにくいですからね・・・。
> 最近はリファクタリングツールや、ソースの整形ツールがあるからまだしもですが、昔はそんなのありませんでしたし。
これは本当にその通りですね。それでも時間がかかって気になるところは絶えないので、今後ももっといい時代になっていく気がしてます。もっとIT業界の生産性があがる技術が出てくるといいですよね。
読みにくいコードって、たいていは「書いた人間が他の人間が読むことを想定していない」ので、プログラマの数ほどバリエーションありますから……言語仕様レベルでドキュメント化を意識している（Java5 以降のアノテーションとか）にしても、せいぜいがメソッドインタフェースレベルですから、メソッド内部のロジックまではねえ。
0
先人の残した良いやり方を学び、素直に取り込んで行く努力ですね。
投稿2017/02/23 11:48
総合スコア2092
なんか内容が数年ほど古いなーっと思ったら、元ネタのスライドショーがそもそも2009年。ES6が出てきて、ReactやAngularJSとかも考えると、今となっては微妙な所も出てきてしまったような気がします。これもJavaScript界隈の進化が早すぎる弊害でしょうか…。
みんながみんなES2015を熟知しているわけではないですし、基礎は大事だと思います。
また、すべてのコードがES2015以降の文法で書かれている / 書ける訳でもありませんので。
ありがとうございます。
リンク先拝見させていただきました。
ベストプラクティスも有為転変していて普遍的なもの+アドホックなものと結構大変ですよね。
JSは会う人会う人みんな書き方違くて面白い反面,キャッチアップの辛さがありますね...。
0
Rubyの話が多いようですが、ほかの言語の話で良ければ・・・
読みずらいなとおもった場合、私の場合はリファクタリングします。
変更後、コミットできない場合も多いですが、理解するには手を動かすのが一番なので、お構いなしにリファクタリングします。（個人でこっそり持っておきます。）
ある程度、ぐちゃぐちゃしたコードだといくつか新しいバグが見つかります。
ロジックの見落としでバグがある場合の原因は、いつもソースコードが読みずらいことに原因があるとみなしています。
あと、自分で書くときは単体テストがやりやすいように書けば、ある程度きれいに書けたとみなしてます。
投稿2017/02/23 09:13
編集2017/02/23 15:31総合スコア2883
テストあるコードは本当に助かりますね。
読めばその関数がどのような処理を望んでいるか分かりやすいので、
書くのが下手だとそのテストも地獄の様相を呈していることがありますが・・・。
0
ソースにコメントがあれば少しは読めるかもしれませんが、コメントすら無いソースだとかなりきついですね。（コメントが間違っているときもあるので厄介ですが）。
そういう時は、自分でコメントを入れていく場合があります。コメントなら動作に影響はないですからね。（ソースを改変してはいけないというのはありますが、コメントを自分で入れたソースは解読のためだけに使用し、ビルドに使わなければ問題はないでしょう）
またはUML図を起こしながら読んで見るというのも有効かもしれません。（私は余りやりませんが、UMLに慣れている方ならそのほうが良いかもしれません）
投稿2017/02/23 09:12
総合スコア3579
0
まだまだ読みづらいコードだし、命名が自分で書いてひどいなぁ…と思うときは沢山ありますが、これは勉強になりました！
https://books.google.co.jp/books/about/リーダブルコード.html?id=Wx1dLwEACAAJ&redir_esc=y&hl=ja
投稿2017/03/04 01:58
総合スコア64
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/02/24 02:50
退会済みユーザー
2017/03/03 02:15