リファクタリング、リアーキテクティング、ビック・リライトの選択〜技術的負債とダンスを(4)
Many teams miss opportunities for refactoring by not realizing the different ways refactoring can fit into their… 『レガシーソフトウェア改善ガイド』では、リファクタリングを実施する際に、安全なステップで行う規律の大切さを先に言及しています。規律あるリファクタリングは、例えば次です。 依存関係をグラフ化して修正の影響範囲を理解するカバレッジ結果を参考に安全にリファクタリングできるコードか否かの判断する書籍『リファクタリング』のように小さなリファクタリングの連続のステップで理想のコードに近づく活動をこまめに継続する（長時間に動作しない状態は避ける）テストを使って外部振る舞いが壊れていないことを頻繁に確認する壊れたらすぐに戻れるようにバージョン管理システムを活用するIDEのリファクタ
継続的システムレボリューションは小さなリファクタリングの連続から始まる〜技術的負債とダンスを(8)
はじめに前回までは、『レガシーコード改善ガイド』を解説していました。今回からはリファクタリングについて解説していきます。１回目は、リファクタリングステップの例を示します。2018年に『Refactoring 2nd』が出ましたが、 本家も１章はサンプルチュートリアルになっています。 今回は、本家に似せたチュートリアルの序盤に相当する、Extract Functionを中心にした構造化のステップを示します。この例を通じてテストを頻繁に実行しながら小さなステップの連続でコードの構造変換を行うリファクタリングの妙技が伝われば幸いです。 リファクタリング前のスタート地点の確認generateReadedReportファンクションがリファクタリング対象です。インプットに２つパラメーター(readedList, recommendList)、アウトプットにテキスト文字列でレポート出力するようになってい
立ち上げ時のふりかえりKPTの４つのコツ
https://www.flickr.com/photos/visualpunch/7477997812「問題対私たち」のチームになっていくには？チーム立ち上げのころは相互参加−相互貢献−相互尊重−相互信頼がまだチーム内で醸成されていない状態であることが普通です。このタイミングでは、チームメンバーは些細な困りごとを安心して話すこともできず、仮に本丸の取り組むべき問題をチームで見つけても、チームメンバーが協力して前向きに取り組むことできないことがあります。チーム内の人と人とのコラボレーションの質が低い状態の場合は、ふりかえりの場が、無関心、他責、厄介事の押し付け、一方的な説得、ディベート（言論で打ち負かす）の言動を取りがちで、機能不全に陥ります。 では、どうやって、本丸の重要なテーマの問題にも「問題対私たち」で取り組める相互信頼のあるCool&Sexyなチームになっていくのでしょうか？ KP
テスト駆動開発における進化的設計とデザインパターンの勘所とは？〜テスト駆動開発をやめて、なお残すべき習慣とは(9)
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って
あなたはTDDのパターンを知っているか？〜テスト駆動開発をやめて、なお残すべき習慣とは(8)
今回から書籍を数回に分けて辿りTDD再考を試みます。第1回は本の全体像を見てみます。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 書籍は３部＋付録の構成１〜２部はTDDを体験するチュートリアル１部はJavaで多国通貨の計算、２部はPythonを使ってステップ・バイ・ステップでxUnitに近づいていくお題となっています。もしまだ１部、２部を利用してケント・ベックとペアプロするような感覚でTDDを追体験したことがないのであれば、一度ゆっくりと試してみることを強くお勧めします。１回と言わずプログラミング言語を変えて数回試して下さい。スポーツが練習を繰り返して本番に立つようにプログラミングも練習が欠かせません。TDDの練習の型と
モダンなアーキテクチャに影響を与え続けるUnixの設計思想とは？
Photo credit: osde8info via VisualHunt / CC BY-SAソフトウェアの設計判断は多数存在しますが、大きな影響を与え続けているもの一つにUnixの哲学があります。本日は書籍『UNIXという考え方』で紹介されている定理の一つを紹介します。 定理２：一つのプログラムには一つのことをうまくやらせる 指針もなく機能の追加修正を続けていると、はじめは短かったコードも時間経過とともに混みいった醜いコードに変貌し、担当が抜けるとやがて誰も手が付けられない恐れや憎悪の対象となってしまいます。ここまでコードが悪化すると、市場からの予期しなかった重要な要望に対して俊敏に応えることは不可能になってしまいます。 そこで、本日ご紹介の定理です。一つのプログラムには、多数混ぜ込むのではなく、一つのことだけうまくやるように絞り込み、一つ一つの小さなプログラムを組み合わせて、達成し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
