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