コード品質向上のテクニック ブログポストリンク集

weekly_report_links.md

コード品質向上のテクニック ブログポストリンク集

LINEヤフー Tech Blog で公開している「コード品質向上のテクニック」のポスト一覧です。

回	タイトルとリンク	一言まとめ	キーワード
34	三十六計分けるに如かず	どのロジックを使うのかが静的に決まる場合は、Strategy pattern の使用を避ける。	strategy pattern, conditional branch, sealed class
33	シェフの気まぐれデコレーション	Decorator pattern を使うときは、その条件を確認する。	decorator pattern, type safeness, data model
32	奈落からの帰還	早期リターンを使う場合は、その存在と条件、およびハッピーパスを目立たせる。	early return, conditional branch, function flow
31	同じ釜のプロパティ	直和型に共通するプロパティを抽出することで、より分かりやすい構造にできることがある。	sum type, sealed class, common property
30	運命の赤い糸 (透明)	関数の間に暗黙の関連性がある場合、関数を 1 つにまとめたり、関連性が明らかな実装に変えたりする。	conditional branch, function precondition, implicit dependency
29	ゴルディアスの変数	データの依存関係が複雑なときは、理想的な中間データを作ることで整理できる可能性がある。	data dependency, function flow, intermediate data structure
28	制約にも相続税	不変性を保証したい場合、継承不能にしたほうがよい。	immutability, inheritance, override
27	依存も積もれば	依存性の注入を行うときは、その目的を明確にする。	dependency injection, dependency explicitness, constructor parameter
26	説明の計は一文目にあり	コメントを書くときは、最初に説明する内容を注意深く選ぶ。	comment, documentation, short summary
25	TL;DR: つまり...どういうこと	レビューコメントでは、最初に提案や要求を書き、理由はその後で補足する。	code review, review comment, explanation order
24	遺産の価値	値が違うだけでロジックが同じときは、継承を使わずに、値の異なるインスタンスを作る。	inheritance, instantiation, dynamic dispatch
23	return の切れ目が edge case の切れ目	早期リターンを使う前に、エラーケースと通常ケースを統合できないかを考える。	early return, error case, function flow
22	To equal, or not to equal	equals が同一性 (identity) と等価性/同値性 (equivalence) のどちらを示しているのかを明確にする。	identity, equivalence, equals
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