技術/その他Tweet2年目、3年目と時が経つにつれて、他人が書いたコード見てコメントをする機会は増えていく。このときに(主にコーディングに関する)自分の考え方を言語化して他人に伝える、というのはとても骨が折れる作業だ。そこで、これまでに他人にしてきたコメントを思い返しつつ「普段どんなことを考えながらコーディングしているか」「プルリクを見るときにどんなところを見ているか」という観点を整理してみた。文字に起こしただけでは伝わらない。何度も繰り返し改善案のコードとセットにして伝える、という積み重ねの先に観点・感覚が身につくはずだと信じている。※この記事では主に「バグが発生しにくいこと」「バグが発生しても原因を特定しやすいこと」を目的としている。※具体的なコード例を載せると長くなるので割愛。名付けについて理解までの時間が最短か実態を表しているか誤解を生まないか正直これについては、感覚的な部分や語彙力(英語)に依存する部分であるので、コメントしたからと言って一朝一夕で身につくものではない。習慣として他人が書いた「筋の良い」コードを読むのが力を身につけるための王道だろうか。引数について引数によって過剰に挙動を制御していないかメソッド名から引数を予想できるか(最も自然な引数になっているか、驚き最小の法則)前者については別のメソッドやクラスに切り分けよう。つめについては例外を使いましょう、というお話。「その時点」ではプログラムが動き続けてしまう。戻り値チェックが行われなかったらおかしなデータのまま後段の処理に進んでしまい予期せぬ挙動を引き起こす原因になる。つめについては空配列や空文字列を使いましょう、というお話。負値をとり得る数値の場合)。データとその型には意味があって、意味に沿ったプログラミングをすれば記述は自然なものになる。返していたら都度戻り値チェックをしなければいけないが、空配列を返しているなら、配列が来ることを想定している後段の処理にそのまま渡して問題ない(場合が多い)。余分な処理が増えれば当然コーディングの量が増えて生産性は下がるし、バグが入り込む余地も増える。つめは「処理の結果によって数値が返ってきたり、配列が返ってきたりする」みたいなことになっていないか、というお話。実は2つめの内容を内包している。後段の処理も1種類の型を想定すれば済む。オブジェクト指向プログラミングなら継承の仕組みもうまく使いたいところ。例外について例外を握りつぶしていないか失敗等のときにすぐに例外を投げているかパフォーマンス面を気にするのであれば、また事情は変わってくるが。メソッドが大きすぎないか複数箇所のデータにアクセスしていないか一言で表すことができる名前をつけられるか名付けに悩んで良い答えが出ないときは、往々にして設計を見直したほうが良いという場合がある。つめの話は設計の領域に入ってくるので、少し抽象度が高く伝わりにくいかも。つめは「暗黙の前提条件を満たさないと正しく動かない」ということがないか、というお話。呼び出してから使わなければいけない」とか。生やすなどして、間違って使われる余地が少なくなるような設計にすると良い。集中力が分散し、「見落とし」が起こりやすくなる。対称性があると「異物」を見つけやすい。前節で説明した「階層」「粒度」が揃っているかが分かりやすい。余談ここまでまとめてきた内容は、概ね次の3つの資料でカバーされていると思う。#1」で登壇してきた話。関する勉強会の講師というものをやってみた話。okashoi参加グループプログラミングはてなブログをはじめよう!okashoiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。