はてなブックマーク

こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、初日の記事です。 これはなに？ 日々の開発をただ漫然とこなすだけでなく、獲得した技術や知識を外に向けて発信することは、他のエンジニアを助ける、自己の成長につながる、思わぬ機会を得られるなど、さまざまな恩恵をもたらします。 Qiitaアドベントカレンダー2022という折角の機会ですから、あらためて技術発信することの意義や恩恵を見直し、モチベーションアップに繋げられればと思います。 また、本記事に記したノウハウによって、発信内容のクオリティアップに少しでも貢献できればと思います。 この記事のゴール 以下の理解を得ることをゴールとします。 技術発信はさまざまな恩恵をもたらすこと 技術発信がより有効なものとなるノウハウを把握すること 筆者の発信実績 説得力を持たせるために一応記載します

こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、13日目の記事です。 これはなに？ コードが複雑化し、技術的負債が蓄積していくと、コードの変更が難しくなり、開発生産性が低下していきます。技術的負債の解消にはリファクタリングが必要です。 しかし、リファクタリングの実施には数々の罠やハードルがあります。 下手すると逆に負債を作り込んでしまうといった、自爆技をやりかねません。 この記事は、リファクタリングのアンチパターンと、その対策をまとめたものです。 この記事のゴール リファクタリングには様々なアンチパターンがあることを知る。 アンチパターンにハマらないためのアプローチを知る。 リファクタリングの効果を高めるにあたり、何のために実施するのか意義を理解する。 前提知識 なぜ自爆技となるのか、自爆だと理解するのに必要な前提知識を挙げ

こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏

こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、初日の記事です。 なにこれ？ 苦労して執筆した技術記事は、伝えたい人にしっかり伝えたいですよね。 また、最後まで読んでもらいたいですよね。 一方で、構成などに課題があって、伝えたい人になかなか伝わらないことがあります。 この記事は、伝わる記事の書き方について、私の個人的なノウハウを書き記したものです。 これからアドベントカレンダーの記事を執筆される皆さんにとって、少しでもお役に立てられれば幸いです。 この記事のゴール 以下の理解を得ることをゴールとします。 以下2つの要件を踏まえた記事構成を心がけること。 構成要件①：技術を紹介する上で最低限説明の必要な内容を網羅すること。 特に課題をしっかり伝えること。 構成要件②：読み手が段階的に理解しやすい順番になっていること。 告知の仕

この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は ドメイン駆動設計#1 Advent Calendar 2019 19日目の記事です。 こんにちは、レガシーコードを 爆殺 リファクタリングするのが大好きなミノ駆動です。 今回はドメイン駆動設計導入上避けては通れない、大事な大事なお金の話を致します。 「ドメイン駆動設計を導入してみたいんです！」 部下「ドメイン駆動設計を導入してみたいんです！」 上司「それって何？なんのために導入するの？」 部下「…………」 はい、僕にもそんな時代がありました。 何のためにドメイン駆動設計を導入したいのか、簡潔に説明できますでしょうか。 「ドメイ

posted articles:DDD:83%設計:75%モデリング:25%記事作成:17%C#:8%

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行

/// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary> /// <param name="amountExcludingTax">税別金額。</param> /// <param name="salesTaxRate">消費税率。</param> /// <returns>税込金額。</returns> public int CalculateAmountIncludingTax(int amountExcludingTax, decimal salesTaxRate) { return (int)(amountExcludingTax * (1.0m + sales

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をその

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業