継続的システムレボリューションは小さなリファクタリングの連続から始まる〜技術的負債とダンスを(8)
はじめに前回までは、『レガシーコード改善ガイド』を解説していました。今回からはリファクタリングについて解説していきます。１回目は、リファクタリングステップの例を示します。2018年に『Refactoring 2nd』が出ましたが、 本家も１章はサンプルチュートリアルになっています。 今回は、本家に似せたチュートリアルの序盤に相当する、Extract Functionを中心にした構造化のステップを示します。この例を通じてテストを頻繁に実行しながら小さなステップの連続でコードの構造変換を行うリファクタリングの妙技が伝われば幸いです。 リファクタリング前のスタート地点の確認generateReadedReportファンクションがリファクタリング対象です。インプットに２つパラメーター(readedList, recommendList)、アウトプットにテキスト文字列でレポート出力するようになってい
ユニットテスト可能なコードに変換するには「接合部」をマスターしよう〜 技術的負債とダンスを(6) – 時を超えたプログラミングの道
はじめに前回から『レガシーコード改善ガイド』の解説しています。今回は、『レガシーコード改善ガイド』を理解する際の肝となる「接合部」について、改善のコード例を示しながら解説します。 接合部とは？『レガシーコード改善ガイド』によると、接合部、許容点の定義は次です。 「接合部(seam)とは、その場所を直接編集できなくても、プログラムの振る舞いを変えることができる場所である」 「どの接合部にも許容点(enabling point)を持つ。許容点では、どの振る舞いを使うかを決定できる」 接合部にはいくつか種類があり、オブジェクト指向言語を使っている場合はオブジェクト接合部がとても役立ちます。プロジェクトで採用しているのがオブジェクト指向中心ではなく、ファンクション中心の場合も接合部と許容点を作って、ユニットテストできるコードに変換することが可能です。 下記は JavaScript における接合部の
『レガシーコード改善ガイド』再入門〜 技術的負債とダンスを(5) – 時を超えたプログラミングの道
前回までは、『レガシーソフトウェア改善ガイド』を参考に、改善のゴールのすり合わせや設計改善の進む道のヒントとなるリファクタリング、リアーキテクティング、ビック・リライトを紹介しました。今回からは、『レガシーコード改善ガイド』を取り上げていきます。 テストがないコードはレガシーコード『レガシーコード改善ガイド』は、コードや設計の腐敗が始まったコードへの向き合い方を著者の経験をもとに整理されています。「テストがないコードはレガシーコード」の力強い言葉とても有名です。 テストコードがなければ、修正の際に期待通り動作するか否かや今までの振る舞いが壊れたのか否かの判断が難しくなります。日々の小さなリファクタリング活動も怖くて実施困難です。ユニットテストを考慮した設計となっていないためユニットテスストの実施が難しくなりがちです。その結果、機能修正や障害解析に苦痛と共に多くの時間を割く羽目になります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
時を超えたプログラミングの道 「技術的負債とダンスを」 - Togetter
