サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
qiita.com/MinoDriven
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに? ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、初日の記事です。 これはなに? 日々の開発をただ漫然とこなすだけでなく、獲得した技術や知識を外に向けて発信することは、他のエンジニアを助ける、自己の成長につながる、思わぬ機会を得られるなど、さまざまな恩恵をもたらします。 Qiitaアドベントカレンダー2022という折角の機会ですから、あらためて技術発信することの意義や恩恵を見直し、モチベーションアップに繋げられればと思います。 また、本記事に記したノウハウによって、発信内容のクオリティアップに少しでも貢献できればと思います。 この記事のゴール 以下の理解を得ることをゴールとします。 技術発信はさまざまな恩恵をもたらすこと 技術発信がより有効なものとなるノウハウを把握すること 筆者の発信実績 説得力を持たせるために一応記載します
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、13日目の記事です。 これはなに? コードが複雑化し、技術的負債が蓄積していくと、コードの変更が難しくなり、開発生産性が低下していきます。技術的負債の解消にはリファクタリングが必要です。 しかし、リファクタリングの実施には数々の罠やハードルがあります。 下手すると逆に負債を作り込んでしまうといった、自爆技をやりかねません。 この記事は、リファクタリングのアンチパターンと、その対策をまとめたものです。 この記事のゴール リファクタリングには様々なアンチパターンがあることを知る。 アンチパターンにハマらないためのアプローチを知る。 リファクタリングの効果を高めるにあたり、何のために実施するのか意義を理解する。 前提知識 なぜ自爆技となるのか、自爆だと理解するのに必要な前提知識を挙げ
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに? ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、初日の記事です。 なにこれ? 苦労して執筆した技術記事は、伝えたい人にしっかり伝えたいですよね。 また、最後まで読んでもらいたいですよね。 一方で、構成などに課題があって、伝えたい人になかなか伝わらないことがあります。 この記事は、伝わる記事の書き方について、私の個人的なノウハウを書き記したものです。 これからアドベントカレンダーの記事を執筆される皆さんにとって、少しでもお役に立てられれば幸いです。 この記事のゴール 以下の理解を得ることをゴールとします。 以下2つの要件を踏まえた記事構成を心がけること。 構成要件①:技術を紹介する上で最低限説明の必要な内容を網羅すること。 特に課題をしっかり伝えること。 構成要件②:読み手が段階的に理解しやすい順番になっていること。 告知の仕
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
概要 顧客にとって役に立つソフトウェアを開発するには、モデリングが重要だと言われています。モデリングによってソフトウェアの価値が高まると言われています。 モデリングとは一体何でしょうか。 単にUMLでクラス図を描くだけでしょうか。 本記事は、ドメインモデルの考え方についてなるべく容易に理解できるよう、ゲームを題材に解説を試みたものです。 留意 本記事では実在の製品を例に挙げて解説していますが、モデル図等はあくまで筆者の私見、個人的な推測であり、実際の製品開発で考案されたモデルとは異なるであろうことにご留意願います。 また、「ドメインモデル的な見方をすればこのようなモデルとなるのでは」と私個人が解釈した内容であることにもご留意願います。 ドメインモデルとは何か 「モデル」と言っても文脈により様々な解釈がありますが、本記事ではドメイン駆動設計に登場するドメインモデルに従います。ドメインモデルな
本記事は ドメイン駆動設計#1 Advent Calendar 2019 19日目の記事です。 こんにちは、レガシーコードを 爆殺 リファクタリングするのが大好きなミノ駆動です。 今回はドメイン駆動設計導入上避けては通れない、大事な大事なお金の話を致します。 「ドメイン駆動設計を導入してみたいんです!」 部下「ドメイン駆動設計を導入してみたいんです!」 上司「それって何?なんのために導入するの?」 部下「…………」 はい、僕にもそんな時代がありました。 何のためにドメイン駆動設計を導入したいのか、簡潔に説明できますでしょうか。 「ドメイン駆動設計」のタイトルにあるように、本書は設計に関する書籍です。 ソフトウェア全体の設計手法や思想に関して言及している書籍です。 まずはソフトウェアの価値とは何か、設計とは何か、それぞれ何かを整理してみます。 ソフトウェアの価値 ソフトウェアが満たすべき要件
posted articles:DDD:83%設計:75%モデリング:25%記事作成:17%Rails:8%
この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例1:筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい
このページを最初にブックマークしてみませんか?
『@MinoDrivenのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く