LINEヤフー Tech Blog で公開している「コード品質向上のテクニック」のポスト一覧です。
回 | タイトルとリンク | 一言まとめ | キーワード |
---|---|---|---|
21 | コンストラクタを叩いて渡る | 準備できていないインスタンスは使えないようにする。 | initialization , constructor , factory |
20 | 異例の過剰包装 | 例外処理中に例外が発生した場合、どちらを優先するべきかを検討する。 | exception , error handling , wrapper |
19 | チャイルドロック | オーバーライド可能な範囲はできる限り制限する。 | override , super , inheritance |
18 | 関数を見て関係を見ず | 抽出を行う際は、「コードが何をするか」の意味のまとまりに注意する。 | extraction , boundaries of concept , nested loop |
17 | 砂上の楼閣 | ビルダーパターンの代わりにコンストラクタやファクトリ関数を使うことを考慮する | naming , grammar , attributive phrase |
16 | 火の null 所に煙は立た null |
エラーの値を区別する必要がある場合は、Null Object パターンを使わないほうがよいことが多い。 | error value , type safeness , null object pattern |
15 | 文法は名を表す | 命名をするときは、宣言・定義側の一貫性よりも、使う側での誤解のされにくさに着目する。 | naming , grammar , attributive phrase |
14 | 責任を課すというたった一つの責任 | 責任の分割によって依存関係が複雑になることがある点に注意する。 | single responsibility , dependency , implicit constraints |
13 | クローン家族 | 2つの継承ツリー間での暗黙の対応関係を避けるために、継承をコンポジションや集約に置き換えたり、パラメトリック多相を利用する。 | type safeness , inheritance tree , implicit correspondence |
12 | セット割引 | 状態の更新タイミングや値の組み合わせを制限するインターフェースを用意したほうがよい場合がある。 | mutability , updating interface , state object |
11 | 関数にたこができる | レシーバの状態を確認するコードは、そのレシーバの関数内で実行したほうが良い場合もある。 | state check logic , responsibility , implicit precondition |
10 | 起きば浮世の壱を見ん | 別のレイヤの詳細な動作に、暗黙的に依存するコードは避けるべき。 | implicit dependency , module structure , responsibility |
9 | 来た道を戻れ | 双方向の変換を行う場合、一方の変換ロジックからもう一方のロジックを演繹的に求めるのが好ましい。 | type conversion , bidirectional , single source of truth |
8 | 実像と虚像 | 関数の戻り値について、取得後に変化しうるかどうかを明確にする。 | view of collection , copied value , mutability |
7 | 新事成語 | 新しい要素を追加したときは、既存コードの名前の変更を検討する。 | naming , new element , inclusive relation |
6 | 乱切りか角切りか | コードの改行を行う際は、意味の区切りを意識する。 | line-break , code chunk , operator precedence |
5 | 悪列挙は良層を駆逐する | 外部で定義された値を変換するコードでは、内部の値と外部の値を互いに独立させて定義する。 | value conversion , externally defined value , enum |
4 | ドア破壊テスト | ユニットテストでは、内部的な動作についてよりも、仕様にあった振る舞いをしているかを確認するほうが好ましい。 | unit test , dependency , specification |
3 | 戦略なき戦略 | ループ中に大きな条件分岐がある場合は、分岐とロジックの対応付けがわかりやすい構造に書き換えることを考慮する。 | loop , conditional branch , strategy pattern |
2 | 確認したかどうか確認した? | 「チェック済みである」ことを暗黙的に前提にしたコードは、できる限り避けたほうが良い。 | implicit dependency , state check logic , type safety |
1 | 覆<error>盆に返らず | エラーがどの程度回復可能かに応じて、適切なエラーの表現方法を使う。 | recoverable error , logic error , exception |