タグ

ブックマーク / qiita.com/MinoDriven (4)

  • リファクタリング自爆奥義集 - Qiita

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

    リファクタリング自爆奥義集 - Qiita
    su_zu_ki_1010
    su_zu_ki_1010 2021/12/14
    とはいえ、ソース設計の大切さは痛い目に合わないとわからないのも事実な気がしている。「痛い目に合う」を早い段階で経験しないとなぁ。動けばOK、なプログラミング研修が多いしなぁ。
  • 設計を歪める認知バイアス - Qiita

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

    設計を歪める認知バイアス - Qiita
    su_zu_ki_1010
    su_zu_ki_1010 2021/12/06
    手を動かしてみないと設計の不備は見えないこともあるんだけど、設計者が自分で手を動かせる状況ではないこともあってなぁ…。
  • 単一責任原則で無責任な多目的クラスを爆殺する - Qiita

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

    単一責任原則で無責任な多目的クラスを爆殺する - Qiita
    su_zu_ki_1010
    su_zu_ki_1010 2020/12/09
    こういう視点は保守運用をやってないと出てこないよなぁ。開発だけして終わり、だと動けばええんねん!なスタイルになるので。
  • 役割駆動設計で巨大クラスを爆殺する - Qiita

    大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例1:筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(, 子供) 趣味ゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい

    役割駆動設計で巨大クラスを爆殺する - Qiita
    su_zu_ki_1010
    su_zu_ki_1010 2019/04/08
    データベース側はこの設計でいけそうだけど、データベースから受け取った値を格納するオブジェクト側が人によっては技術的負債になって糞コードだと呼ばれてしまうかもなぁ、と思ったりした。個人的にはアリ。
  • 1