はじめに前回までは、『レガシーコード改善ガイド』を解説していました。今回からはリファクタリングについて解説していきます。１回目は、リファクタリングステップの例を示します。2018年に『Refactoring 2nd』が出ましたが、 本家も１章はサンプルチュートリアルになっています。 今回は、本家に似せたチュートリアルの序盤に相当する、Extract Functionを中心にした構造化のステップを示します。この例を通じてテストを頻繁に実行しながら小さなステップの連続でコードの構造変換を行うリファクタリングの妙技が伝われば幸いです。 リファクタリング前のスタート地点の確認generateReadedReportファンクションがリファクタリング対象です。インプットに２つパラメーター(readedList, recommendList)、アウトプットにテキスト文字列でレポート出力するようになってい
はじめに前回から『レガシーコード改善ガイド』の解説しています。今回は、『レガシーコード改善ガイド』を理解する際の肝となる「接合部」について、改善のコード例を示しながら解説します。 接合部とは？『レガシーコード改善ガイド』によると、接合部、許容点の定義は次です。 「接合部(seam)とは、その場所を直接編集できなくても、プログラムの振る舞いを変えることができる場所である」 「どの接合部にも許容点(enabling point)を持つ。許容点では、どの振る舞いを使うかを決定できる」 接合部にはいくつか種類があり、オブジェクト指向言語を使っている場合はオブジェクト接合部がとても役立ちます。プロジェクトで採用しているのがオブジェクト指向中心ではなく、ファンクション中心の場合も接合部と許容点を作って、ユニットテストできるコードに変換することが可能です。 下記は JavaScript における接合部の
前回までは、『レガシーソフトウェア改善ガイド』を参考に、改善のゴールのすり合わせや設計改善の進む道のヒントとなるリファクタリング、リアーキテクティング、ビック・リライトを紹介しました。今回からは、『レガシーコード改善ガイド』を取り上げていきます。 テストがないコードはレガシーコード『レガシーコード改善ガイド』は、コードや設計の腐敗が始まったコードへの向き合い方を著者の経験をもとに整理されています。「テストがないコードはレガシーコード」の力強い言葉とても有名です。 テストコードがなければ、修正の際に期待通り動作するか否かや今までの振る舞いが壊れたのか否かの判断が難しくなります。日々の小さなリファクタリング活動も怖くて実施困難です。ユニットテストを考慮した設計となっていないためユニットテスストの実施が難しくなりがちです。その結果、機能修正や障害解析に苦痛と共に多くの時間を割く羽目になります。
Many teams miss opportunities for refactoring by not realizing the different ways refactoring can fit into their… 『レガシーソフトウェア改善ガイド』では、リファクタリングを実施する際に、安全なステップで行う規律の大切さを先に言及しています。規律あるリファクタリングは、例えば次です。 依存関係をグラフ化して修正の影響範囲を理解するカバレッジ結果を参考に安全にリファクタリングできるコードか否かの判断する書籍『リファクタリング』のように小さなリファクタリングの連続のステップで理想のコードに近づく活動をこまめに継続する（長時間に動作しない状態は避ける）テストを使って外部振る舞いが壊れていないことを頻繁に確認する壊れたらすぐに戻れるようにバージョン管理システムを活用するIDEのリファクタ
今回は、前回に引き続き『レガシーソフトウェア改善ガイド』を参考にしながら、チームでのレガシー改善のゴールのすり合わせについて解説します。 現状データを集め可視化する レガシーの現状を指差し確認できるように可視化する改善活動を基本としているScrumの３本柱、「透明性−検査−適応」が知られていますが、レガシーソフトウェアが引き起こす問題を解消する改善活動も透明性に取り組むは良いアプローチです。現状をだれでも指さして確認できるように可視化することで、現状を的確に把握し解くべき課題に合意して行動しやすくします。 例えば、静的コード解析や性能テストや監視モニタリングやテスト実施結果や作業にかかった時間やチケット情報などを集めて可視化します。静的コード解析の診断結果によっては、コーディング規約を守っていないことだけなく、バグを混入しているモジュールに気付くこともあるでしょう。ツールによって重複コード
ソフトウェア開発のコンテキストでレガシーと言えば、マイケル・C・フェザーズの『レガシーコード改善ガイド』が有名です。が、連載ではまず、もう一つ日本語訳されている、『レガシーソフトウェア改善ガイド』を参考にしながら、技術的負債との付き合い方を解説していきます。 『レガシーソフトウェア改善ガイド』は、『レガシーコード改善ガイド』と同様に、プログラマが今眼の前にしているソフトウェアに触れることの対する恐れやフラストレーションを乗り越えることを主テーマにしつつも、何にフォーカスしてレガシーソフトウェアの改善を行えばよいのか、どのように行えばよいのかについて順を追って解説しています。 レガシーとは？先にソフトウェア開発におけるレガシーの意味について揃えておきましょう。『レガシーコード改善ガイド』の「テストがないコードはレガシーコード」の言葉は有名です。が、レガシーソフトウェア改善ガイドの著者において
自分が、ここ数年アジャイルのトレーニングの際に必ず示している図がある。それが「エクストリームプログラミング」の第一版から第一章で提示されている、ソフトウェア開発に関するリスクについての図だ。 先日、Agile459のオンライン読書会で紹介したら好評だったので図を貼って置くことにする。 念のため、エクストリームプログラミングを読んだことのない人向けに説明しておくと、これらの元ネタは書籍（初版では１章まるごと、第二版・新訳版では１章で部分的に）では列挙されているが、本文に列挙されているだけなので、自分なりに整理してこのような図にしている。 実現できないスケジュールが遅れたり、度重なる遅延で実現の前に資金がなくなりプロジェクトが終わってしまうというリスクがまず最初にある。 動かないなんとか実現しても、欠陥が多くまともに動かなかったり、その結果としてシステムが劣化（＝メンテナンス不能に）になり、作
Fit for Developing Software (https://goo.gl/FqRtmo)前篇に引き続き、Ward Cunningham（Wardと略） の活動について解説します。前回は、Wikiとパターンについて触れました。今回は、CRCカード、エクストリームプログラミング（XP）、Fit、そして技術的負債について触れます。 Ward CunninghamとKent Beckとの出会い前編でも触れましたが、ソフトウェア開発の歴史の上で Ward とKent Beck の出会いは大きかったと言ってよいでしょう。 http://wiki.c2.com/?WardAndKent 複数人でカードを使って対話しながら設計する CRCカード２人は、パターンの他に、Smalltalkの分野でいくつかのライブラリ−を公開し、CRCカードを使った設計アプローチの論文について1989年に公開しま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
