リファクタリング、リアーキテクティング、ビック・リライトの選択〜技術的負債とダンスを(4)
Many teams miss opportunities for refactoring by not realizing the different ways refactoring can fit into their… 『レガシーソフトウェア改善ガイド』では、リファクタリングを実施する際に、安全なステップで行う規律の大切さを先に言及しています。規律あるリファクタリングは、例えば次です。 依存関係をグラフ化して修正の影響範囲を理解するカバレッジ結果を参考に安全にリファクタリングできるコードか否かの判断する書籍『リファクタリング』のように小さなリファクタリングの連続のステップで理想のコードに近づく活動をこまめに継続する（長時間に動作しない状態は避ける）テストを使って外部振る舞いが壊れていないことを頻繁に確認する壊れたらすぐに戻れるようにバージョン管理システムを活用するIDEのリファクタ
レガシー改善活動のゴールのすり合わせを行おう！〜技術的負債とダンスを(3) – 時を超えたプログラミングの道
今回は、前回に引き続き『レガシーソフトウェア改善ガイド』を参考にしながら、チームでのレガシー改善のゴールのすり合わせについて解説します。 現状データを集め可視化する レガシーの現状を指差し確認できるように可視化する改善活動を基本としているScrumの３本柱、「透明性−検査−適応」が知られていますが、レガシーソフトウェアが引き起こす問題を解消する改善活動も透明性に取り組むは良いアプローチです。現状をだれでも指さして確認できるように可視化することで、現状を的確に把握し解くべき課題に合意して行動しやすくします。 例えば、静的コード解析や性能テストや監視モニタリングやテスト実施結果や作業にかかった時間やチケット情報などを集めて可視化します。静的コード解析の診断結果によっては、コーディング規約を守っていないことだけなく、バグを混入しているモジュールに気付くこともあるでしょう。ツールによって重複コード
再考：レガシーとはなんぞや？〜技術的負債とダンスを(2) – 時を超えたプログラミングの道
ソフトウェア開発のコンテキストでレガシーと言えば、マイケル・C・フェザーズの『レガシーコード改善ガイド』が有名です。が、連載ではまず、もう一つ日本語訳されている、『レガシーソフトウェア改善ガイド』を参考にしながら、技術的負債との付き合い方を解説していきます。 『レガシーソフトウェア改善ガイド』は、『レガシーコード改善ガイド』と同様に、プログラマが今眼の前にしているソフトウェアに触れることの対する恐れやフラストレーションを乗り越えることを主テーマにしつつも、何にフォーカスしてレガシーソフトウェアの改善を行えばよいのか、どのように行えばよいのかについて順を追って解説しています。 レガシーとは？先にソフトウェア開発におけるレガシーの意味について揃えておきましょう。『レガシーコード改善ガイド』の「テストがないコードはレガシーコード」の言葉は有名です。が、レガシーソフトウェア改善ガイドの著者において
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
