質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

89.96%

コードを読みやすくするために意識していることを教えてください。

解決済

回答 6

投稿

  • 評価
  • クリップ 5
  • VIEW 2,162

tkow

score 1198

最近開発をしていて思うのはコードリーディングは自分でコード書くより大変な時があります。
なんとなく、自分はコードリーディングが下手なのか、書かれているコードがおかしいのか、大した動作をしていないのに、ものすごくコードを読むのに時間がかかることがあります。

読みやすいコードを書くのは基本ですが、現実は読みにくいコードをなんとか読まなければならない状況の方が多いと思っており,共同開発者やオープンソースコミッターがデザインパターンに沿ってコードを書いていることを期待してはいけなく,最近では無からコードを生成する能力に比して,読みにくいコードでも読める力のウエイトの方が実務では大事なのではないかと思うようになりました。(自分が1から書けば良くなることがわかってる状態だとしても,何がしたいのかをコードから読み取らなければならないことが多いからです)

どうすれば読みにくいコードでも効率良く読み進めることができるか方法を思索しています。
最近ではものすごく時間をかけて調査した結果、些細なバグの原因が全くそのクラスと関係ない場所で定義されたメソッドで副作用起こしてるから等がありました。

特に読みづらいと思ったのは以下のような特徴を持つプロジェクトのコードです。

  • moduleと継承が混在していて名前空間で分かれていないメソッドの呼び出し(どのファイルで定義された関数,メソッドなのかがわからない)
  • そのスコープにおいて有効な変数が多すぎる(やむを得ない場合もありますが一時変数すらインスタンス変数に設定してあるものなど,インスタンス変数の定義場所と使用場所の区別がつかない場合など)
  • 処理の途中で違う処理が挟まってる(単一処理できないこともありますが)
  • 継承の多用(概念的に綺麗であれば大丈夫ですが分岐や深過ぎる継承同じ概念でまとめられるはずの継承)
  • 大き過ぎるメソッド
  • 小さすぎる大量のメソッド(的確に切り分けられてないと定義を飛び続けて元のコードの処理を追いづらくなる)
  • 処理フローがめちゃくちゃなメソッド(名前と実行してる処理が違う,名前に対して色んな処理をしすぎ)
  • 同じ処理が複数ファイルに散在している(読みづらい上に一箇所の変更が複数ファイルに伝播して直すのも大変)

このような特徴を持つコードでも読む時に意識すると読みやすくなるってことありますか?もしコードリーディングで意識していることがあれば教えて下さい。(ファイル上に存在しないメソッドは継承,標準ライブラリ,mixinで的を絞るなど)

よろしくお願いします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 6

checkベストアンサー

+4

はるか昔からコードの解読しやすさというのは永遠の命題でして(ちと大げさ?)、人がコードを書く以上は避けられないことになっています。
※がちがちに規則を決めて、誰が書いても似たようなソースにしかならないようにする、というアプローチを取ったのが COBOL というのは言い過ぎですかね?

最近はリファクタリングツールや、ソースの整形ツールがあるからまだしもですが、昔はそんなのありませんでしたし。
結局のところ、コードリーディングについては行う人のスキルに依存するしかない、でしょう。
せいぜいがツールを使って、自動整形とか自動で不要なローカル変数を消してしまうとかくらいでしょうか。

あとはデバッグに関して言えば、コードの全てを追いかけようとはせず、まず問題が起きている場所を特定すること。エラーになるとすれば、何らかのエラーを引き起こす情報が変数にセットされたわけですから、そこから変数の内容を全部洗いだして、逆にたどる(どこでその変数の内容がセットされたのか?)、くらいですかね。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/24 11:44

    そんな、貴重な体験がたくさんできるのもCOBOLの良さですね。(ヤレヤレ)
    COBOLの話ってする場所がないのでつい、話題がそれてしまいました。失礼しました。

    キャンセル

  • 2017/02/24 12:06 編集

    やはり読みにくいコードを読むプラクティスみたいのを考えるのってあまりないんでしょうか。
    読めば大体なぜ読みにくいかは分かるのですが,読みにくさのパターン化はしにくいですからね・・・。

    > 最近はリファクタリングツールや、ソースの整形ツールがあるからまだしもですが、昔はそんなのありませんでしたし。

    これは本当にその通りですね。それでも時間がかかって気になるところは絶えないので、今後ももっといい時代になっていく気がしてます。もっとIT業界の生産性があがる技術が出てくるといいですよね。

    キャンセル

  • 2017/02/24 12:12

    読みにくいコードって、たいていは「書いた人間が他の人間が読むことを想定していない」ので、プログラマの数ほどバリエーションありますから……言語仕様レベルでドキュメント化を意識している(Java5 以降のアノテーションとか)にしても、せいぜいがメソッドインタフェースレベルですから、メソッド内部のロジックまではねえ。

    キャンセル

+4

命名がすごく大事だと思います。
コメントがなくても意図が伝わるようなコードを書ければベストなのではないでしょうか?
http://qiita.com/chooyan_eng/items/72f86a2ce2ca67d3b4a4
個人的にすごく参考になった記事です。

後はメソッド分割。テスタブルなコードを書くことでリファクタもしやすくなります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/24 11:50

    ありがとうございます。喋るように書くは私も意識していますね。
    メソッド名が処理フローのインストラクションになることを意識しています。

    キャンセル

  • 2017/03/03 11:15

    命名は大事ですよね。これもまた短くしすぎると何かわからなくなるし、長ったらしいのもコーディングミスにつながるので悩ましいところです。

    キャンセル

+3

先人の残した良いやり方を学び、素直に取り込んで行く努力ですね。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/24 06:20

    なんか内容が数年ほど古いなーっと思ったら、元ネタのスライドショーがそもそも2009年。ES6が出てきて、ReactやAngularJSとかも考えると、今となっては微妙な所も出てきてしまったような気がします。これもJavaScript界隈の進化が早すぎる弊害でしょうか…。

    キャンセル

  • 2017/02/24 07:20 編集

    みんながみんなES2015を熟知しているわけではないですし、基礎は大事だと思います。
    また、すべてのコードがES2015以降の文法で書かれている / 書ける訳でもありませんので。

    キャンセル

  • 2017/02/24 11:55

    ありがとうございます。
    リンク先拝見させていただきました。
    ベストプラクティスも有為転変していて普遍的なもの+アドホックなものと結構大変ですよね。
    JSは会う人会う人みんな書き方違くて面白い反面,キャッチアップの辛さがありますね...。

    キャンセル

+2

ソースにコメントがあれば少しは読めるかもしれませんが、コメントすら無いソースだとかなりきついですね。(コメントが間違っているときもあるので厄介ですが)。
そういう時は、自分でコメントを入れていく場合があります。コメントなら動作に影響はないですからね。(ソースを改変してはいけないというのはありますが、コメントを自分で入れたソースは解読のためだけに使用し、ビルドに使わなければ問題はないでしょう)

またはUML図を起こしながら読んで見るというのも有効かもしれません。(私は余りやりませんが、UMLに慣れている方ならそのほうが良いかもしれません)

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/23 18:16

    大きすぎるメソッドは、分割できないかを考えたりはします。その場合も機能でまとまりのある単位でないと無理ですが。ま、一種のリファクタリングになりますね。

    キャンセル

  • 2017/02/24 11:59

    テスト駆動であれば基本的に大きすぎるメソッドになるはずはないですね。
    大きすぎてもテストの範囲に処理は収まっている(はずと信じたい)のでなるべくテスト駆動で開発できる環境を作れるといいですね。

    キャンセル

  • 2017/02/24 17:01

    テスト駆動なソースなら読めないコードには余りならないような気がします。テスト駆動なのに大きすぎるメソッドというのは何かやり方を間違えているかと。

    キャンセル

+2

Rubyの話が多いようですが、ほかの言語の話で良ければ・・・

読みずらいなとおもった場合、私の場合はリファクタリングします。
変更後、コミットできない場合も多いですが、理解するには手を動かすのが一番なので、お構いなしにリファクタリングします。(個人でこっそり持っておきます。)

ある程度、ぐちゃぐちゃしたコードだといくつか新しいバグが見つかります。

ロジックの見落としでバグがある場合の原因は、いつもソースコードが読みずらいことに原因があるとみなしています。

あと、自分で書くときは単体テストがやりやすいように書けば、ある程度きれいに書けたとみなしてます。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/24 11:57

    テストあるコードは本当に助かりますね。
    読めばその関数がどのような処理を望んでいるか分かりやすいので、
    書くのが下手だとそのテストも地獄の様相を呈していることがありますが・・・。

    キャンセル

0

まだまだ読みづらいコードだし、命名が自分で書いてひどいなぁ…と思うときは沢山ありますが、これは勉強になりました!

https://books.google.co.jp/books/about/リーダブルコード.html?id=Wx1dLwEACAAJ&redir_esc=y&hl=ja

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 89.96%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる