2019年6月の記事一覧
第4部 選抜テーマ ～優れた設計と読みやすさ～
優れた設計は読みやすいコードと比例するリーダブルコードに例題を単純解決してから問題点を解決するために再設計していき、読みやすいコードに変わっていく過程が記述されている。単純解決したコードから大幅に増えたけど、柔軟性・パフォーマンス・将来性が格段に向上しているのがわかる。
逆に言うと、コードを読みやすくしていけば柔軟性・パフォーマンス・将来性が向上する、ということなので、読みやすいコードを書く意義
第4部 選抜テーマ ～テストコードVol.3～
わかりやすいテスト結果を表示するテストコードにはわかりやすいテスト結果を出力すべき、とのこと。それぞれの言語に用意されているアサートを活用すれば案外楽に書けるけど、自分が欲しい情報が不足していると思ったら自分でアサートを作ってしまえばよい、とのこと。
実質「テスト結果＝エラーになった時の情報」を指している。どんな値でどこでエラーになったかがわかれば、その箇所をエラーになった値でトレースすればよい
第4部 選抜テーマ ～テストコードVol.2～
テストコードは複数にわけて書くテストの入力値は1行だけ書くのではなく、複数行に分けて書く方がよい、とのこと。1行でも適切なパラメータなら良いのでは？と腑に落ちなかったから理解するのに時間がかかった。
もし1行しか書いていない場合、テスト内容が変わったら適切なパラメータを考え直さないといけない。それに、どのケースを網羅しているかわかりにくい。コメントに網羅したケースを書くのもアリかもしれないけど、
第4部 選抜テーマ ～テストコードVol.1～
読みやすいテストコードを書くテストコードが読みにくいと、コード自体の修正に臆病になり、テストコードの追加もしなくなるので、読みやすいテストコードを書くべき、とのこと。テストコードも「コード」だから、読みやすくするべきということだな。当たり前だけど、読みやすくするためにテスト内容を削るという意味ではない。
具体的な内容を見ていくと、今まで学んできた手法をテストコードにも適用するようだ。テストコード
第3部 コードの再構成 ～コードを短くする～
不要なケースをそぎ落とす要求の内、100%全てのケースを満たすのではなく、満たさなくてもよいケースを見つけ、そぎ落として簡単にすべき、とのこと。ありえないケースはコードを書かない、という話だ。
例えば「サッカーのスコアをチェックして結果を表示する機能が欲しい」という要求の場合、以下のチェックは不要だとわかる。
1. スコアに数値以外が入っている場合、エラーにする
2. スコアがマイナスの場合
第3部 コードの再構成 ～簡単に説明できるコードを書く～
コードを簡単な言葉で説明する人に何かを説明する時、あれやこれや話したり難しい言葉やオレ流言葉を使ったりすると、相手が理解しにくい（できない）。だから簡単な言葉で説明する。コードも人に説明する文章だと考えると同じ事が言える、とのこと。
ごもっとも。うまく説明できない時は説明にノイズが入ったり漏れがある。逆にうまく説明できた時はそれがない気がする。コードもプログラムの動作を説明するものだから、同じよ
第3部 コードの再構成 ～一度に一つのタスクを～
コードからタスクを抽出する一度に一つのタスクを行うようにコードを書くべき、とのこと。確かに、一度に複数のタスクを行うコードは複雑で読みにくい。
タスクの単位はリーダブルコードではユルく書かれており、明確な基準はない。自分なりに考え、コードを言葉にした時に「～する」になる単位と理解した。以下のコードを例にタスクを抽出してみよう。
function FormatDate(strDate, form
第3部 コードの再構成 ～無関係な下位問題～
無関係な下位問題を見つけて抽出するリーダブルコードに、無関係な下位問題の抽出について以下の記述がある。
1. 関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する。
2. コードの各行に対して「高レベルの目標に直接的に効果があるのか？ あるいは、無関係の下位問題を解決しているのか？」と自問する。
3. 無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の
第2部 ループとロジックの単純化 ～読みやすい変数～
コードが読みやすくならない変数を削除する一度しか使っていない変数や、わざわざ作る必要のない中間変数。これらは変数にしなくてもコードは明確で読みやすいので削除すべき、とのこと。
確かに、変数が多いとコードが読みにくい。ただ、なんでもかんでも削除すればいいというわけではない。第2部 ループとロジックの単純化 ～巨大な条件式の分割～で理解した「説明変数・要約変数」は、一度しか使っていなくてもコードの読
第2部 ループとロジックの単純化 ～巨大な条件式の分割～
説明変数や要約変数を使って読みやすくするどちらも変数を指すが、自分なりに以下の理解をした。
- 説明変数: メソッドの結果を入れる。
- 要約変数: 条件式の結果を入れる。
例)//説明変数var drive_name = file_path.split('/')[0];if (drive_name == 'C')...//要約変数var is_c_drive = (drive_name =
第2部 ループとロジックの単純化 ～条件式の書き方Vol.2～
ネストは浅くするネストを浅くすると読みやすくなるとのこと。理由は、ネストが深いと今までに出てきた条件を自分の頭の中に「スタック」して条件を判定する度に「ポップ」しないといけないから。スタックしきれなくなるとコードを読み返すことになる。なるほど、読み返す＝読みにくいコードだ。
過去を振り返ると、ネストが深くなることはあった。ネストが深くなることに罪悪感がなかったからかもしれない。。。これを機に「ど
第2部 ループとロジックの単純化 ～条件式の書き方Vol.1～
条件式の引数は読みやすいように書く条件式の引数の読みやすい書き方はリーダブルコードによると「左側は変化する値、右側はあまり変化しない値」とある。英語の用法と一致するからとのこと。
(a) if (age >= 20) //年齢が20以上なら(b) if (20 <= age) //20以上の年齢なら
なるほど。圧倒的に(a)が読みやすい。自分が条件式の引数を書く時、並び順をそこまで
第1部 表面上の改善 ～コメントの付け方Vol.3～
前回に引き続き、コメントの付け方をさらに分析してみた。
自分の考えをコメントにするコメントは、コードを書いている時に考えていた課題や意図、TODOをコメントにすべきとのこと。見てわかることは書く必要がない。
確かに、プログラムは一度作ったら終わりではなく改修/保守していく。その時になぜこのコードを書いたかがわかれば、エラーの原因特定やチューニングの助けになる。自分だけでなく他の人の役にも立つ
第1部 表面上の改善 ～コメントの付け方Vol.2～
前回に引き続き、コメントの付け方を分析してみた。
自分の考えを記録するリーダブルコードにコメントの付け方について以下の記述がある。
映画のDVDにはよく「監督のコメンタリー」がついてくる。映画の製作者が自分の考えや物語について語ってくれるので、作品がどのように作られたのかを理解するのに役立つ。これと同じように、コメントにはコードに対する大切な考えを記録しなければいけない。
引用元：Dustin