タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

programmingとqiitaと設計に関するyuki_2021のブックマーク (6)

  • API設計まとめ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 自分は2021年に新卒でWeb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りとNode.js(Nest)やRailsを用いたバックエンド(API)の開発をしています。 その中で使っていたAPI設計について改めて学び直したのでまとめて行きます。 この記事の対象者 エンジニア初心者から中級者 APIについて学びを深めたい人 この記事の目標 APIについて学ぶ 我流ではなく正しいAPI設計について学ぶ この記事でやらないこと 具体的にコードを

    API設計まとめ - Qiita
  • リファクタリング自爆奥義集 - Qiita

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

    リファクタリング自爆奥義集 - Qiita
  • 設計を歪める認知バイアス - Qiita

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

    設計を歪める認知バイアス - Qiita
  • プログラムの依存関係とモジュール構成のこと - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさん、メンテナンスしやすいプログラムにするための設計に苦労してませんか? 次々と現れるフレームワークやデザインパターンに振り回されてませんか!? プログラムの設計については、パターン周りを中心に長い間多くの人を悩ませているように見えます。例えば MVC などは 1980 年代からあるものなのに、未だに定期的に議論に上がったり改善されたパターンなどが提案されたり、それを元にしたフレームワークが現れたりします。 僕もそういった設計に悩んだ(でる)一人なのですが、最近は新しいパターンも大事とは思いつつも単純に依存関係をきちんとコントロール

    プログラムの依存関係とモジュール構成のこと - Qiita
  • スケールする要求を支える仕様の「意図」と「直交性」 - Qiita

    はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の

    スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
  • 「ビジネスロジック」とは何か、どう実装するのか - Qiita

    アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い

    「ビジネスロジック」とは何か、どう実装するのか - Qiita
  • 1