単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
「レガシーコード改善ガイド」のススメ 第4回：既存のコードに極力手を加えずにテストで保護する
既存のコードをテストで保護する 前回の記事では「スプラウトクラス」（Sprout Class）という手法を紹介しました。これは、レガシーコードに機能を追加する際に、既存のコードにはほとんど手を加えず、新機能を実現するために新しいクラスを作るという手法でした。この手法の基本にあるのは、既存のコードにテストを書くことはあきらめるとしても、せめて新しく書いたコードだけはテストで保護しよう、という考え方です。 こうした手法は時間が少ない状況で新しい機能を追加する際に有効です。しかしこれを使い続ける限り、いつまで経っても既存のコードは改善しません。 そこで、既存のコードをテストで保護する手法が必要になります。『レガシーコード改善ガイド』では、こうした手法が数多く紹介されています。今回の記事では、その中のもっとも基本的な手法の1つを紹介しましょう。 テストが困難な既存コードの例 ここでは、あるスーパー
「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する
増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
vim で実践！ コードリファクタリング
