CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
1. オブジェクト指向の起源 2003年チューリング賞の受賞者アラン・ケイさんはよくオブジェクト指向プログラミングの父と称されます。ご本人も憚ることなく、幾度、公の場で発明権を宣言しています。しかし、ケイさんは「C++」や「Java」などの現代のオブジェクト指向言語を蔑ろにしています。これらの言語は「Simula 67」という言語を受け継いだもので、私が作った「Smalltalk」と関係ないのだとケイさんは考えています。 オブジェクト指向という名称は確かにアラン・ケイさんに由来するものです。しかし、C++とJavaで使われている現代のオブジェクト指向は当初のと結構違います。ケイさん自身もこれらの言語を後継者として認めないです。では、ケイさん曰くC++とJavaの親であるSimula 67という言語はどんな言語でしょうか。ここで、簡単なサンプルコードを見てみましょう。 Class Recta
フロントエンドのデザインパターン
本書は、Lydia Hallie 氏 と Addy Osmani 氏らによる Learning Patterns (https://www.patterns.dev/) の日本語訳です。原著は大きく 3 つのセクションに分かれていますが、本書は、その最初のセクションである Design Patterns を訳したものとなります。
良いコードの書き方 - Qiita
概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数のスコープを小さくする 変わり得る値は複雑さを生み誤解やバグに繋がるため、プログラムは変数が少ないほど問題が生まれづらい。 プログラミングの大原則として、変数は必要最低限を心がけ、むやみに増やさないようにする。 また、変数はスコープや寿命が大きいほど悪影響が
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 - エンジニアHub｜Webエンジニアのキャリアを考える！
10年モノのサービスをアーキテクチャから再設計─はてなブックマークがScalaとDDDを使う理由 10年以上運用されているサービスには、さまざまな技術的な負債が発生しています。今後の継続的な改善のため、いったん新規開発を止めて4年かけて全面的なリニューアルを実施した「はてなブックマーク」の開発者に、プロジェクトの課題や解決する手法などを聞きました。 改善1つに数カ月かかるなら全てを書き換えられないか 2000年代にトレンドだった開発手法の負債 過去の開発意図を探る考古学的手法 データセンター移行も見据えて刷新しよう ドメインモデル設計とScalaとマイクロサービス化 コアロジックにはScalaを採用 きちんとしたドメインモデルによる設計と実装を継続したい 段階的なリリースとデータの移行という2つの大きな課題 求められる機能に沿ったデータベーススキーマに再構築 新旧の2システムを維持しながら
2021/04/10開催 Developer eXperience Day 2021 「クソコード動画『Userクラス』で考える技術的負債解消の観点」の解説資料です。 https://dxd2021.cto-a.org/program/time-table/b-3 クソコード動画はこちら https://twitter.com/MinoDriven/status/1380773721032433674 YouTubeライブのリンクはこちら https://www.youtube.com/watch?v=ajPaGPdj6tU
κeenです。最近JEITAのソフトウェアエンジニアリング技術ワークショップ2020に参加したんですが、そこで五十嵐先生、柴田さん、Matzとパネルティスカッションをしました。その議論が面白かったので個人的に話を広げようと思います。 年末年始休暇に書き始めたんですが体調を崩したりと色々あって執筆に時間がかかってしまいました。 時間を置いて文章を書き足していったので継ぎ接ぎ感のある文体になってるかもしれませんがご容赦下さい。 というのを踏まえて以下をお読み下さい。 いくつか議題があったのですが、ここで拾うのは一番最後の「プログラミング言語の未来はどうなるか」という話題です。 アーカイブが1月末まで残るようです。もうあと数日しかありませんが間に合うかたはご覧下さい。 そのとき各人の回答を要約すると以下でした。 五十嵐先生：DSLを簡単に作れる言語というのが重要。それとプログラム検証、プログラム
※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎている ちょっとずつゴミコードが追加されていった結果 重複しているコードをutil神クラスに押し込むと、あらゆる関心事が集中してしまう 変更に強いプログラムの書き方 メソッドは短く、クラスは小さく 略語は使わない 意味のまとまりで空行をうまく使う 説明用のローカル変数の導入（変更の影響範囲を局所化） 1つの変数に代入を繰り返す破壊的代入を避ける 意味のあるコードのまとまり（段落）を「メソッド
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか
以下はjavinpaul( Webサイト / Twitter / Facebook / dev.to )による記事、11 Essential Skills Software Developers should Learn in 2020の日本語訳です。 なおリンク先URLは元記事のままであり、和訳にあたり変更などは行っていません。 11 Essential Skills Software Developers should Learn in 2020 注意事項：この記事にはアフィリエイトリンクが含まれています。 この記事に記載されているリンクを踏んで製品やサービスを購入すると、私が利益を受けとることがあります。 ソフトウェア開発を始めてしばらくすると、優れたプログラマになるには何をすればいいのかという考えが時によぎるでしょう。 より良い開発者になるために、2020年には何を学ぶべきでしょう
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
設計を歪める認知バイアス - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだのHatena
某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー
Value Objectについて整理しよう - Software Transactional Memo
Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a
目指せ脱UE4初心者！？知ってると開発が楽になる便利機能を紹介 - DataAsset, Subsystem, GameplayAbility編 -
Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui
オブジェクト指向がわからないあなたへ
どうも、都内の某企業に勤めるフルスタックエンジニアです。この記事では、ITの非専門家に向けて、オブジェクト指向の解説をしたいと思います。 小学生のプログラミング教育が開始されたり、AIやIoTなどの技術が身近になった今日、オブジェクト指向を理解しておくことは極めて重要です。なぜならば、オブジェクト指向はITエンジニアとっての「共通言語」であって、今やあらゆるソフトウェア技術がオブジェクト指向の上に成り立っているからです。したがって、オブジェクト指向を理解すれば、ITのすべての分野の基礎が身についたことになります。難しい概念がいくつか出てきますが、分かりやすく解説するので頑張ってついてきて下さい！ オブジェクト指向とはまず、オブジェクト指向とは何かを解説します。オブジェクト(object)とは、「モノ」のことです。言い換えれば「モノ指向」です。つまり、コンピュータのようなバーチャルな対象では
定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代
良いコード／悪いコードで学ぶ設計入門の感想と注意点
「良いコード／悪いコードで学ぶ設計入門」という本がとても売れているようです。私の所属している開発チームでも、何人か購入した人がいたので、私も購入して一通り読んでみました。 結果として、いくつかの考えが整理され、私としてはこの本によって考えが深まり、本を読んで考えた事自体は有意義であったと思いました。ただし一方で、あまり知識がない状態で（自分の中での判断軸が無い状態で）この本を読むと、色々と誤解が生まれるのではないか？という事を感じました。 一つの技術書がこれだけ売れるという事はそんなに多くはない事だと思うので、つまり、 その内容が改善されるとその効果は相対的に大きい という事になります。そこで、私が本を読んでいて思ったことや、この本の内容で正しいこと、現在も賛否両論とされること、事実として認識が間違っているであろうこと、この本で触れられていないが設計において大事なこと、などについてまとめて
「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
Pythonにおけるデザインパターン 当サイトについて GoFの定義した23コのデザインパターンをPythonで実装します。 ただし、Pythonのビルトイン機能で実現できるパターンもあります。 その際は、ビルトイン機能の紹介に留めます。 Pythonらしい書き方（Pythonicな書き方）ができるものは古典的な実装とPythonicな実装の両方を紹介します。 全デザインパターン パターンカテゴリ パターン名 コメント
2024年バージョンの全面改定された新しい本が公開されているので移動してください 関数型プログラミングをゼロからわかりやすく実用的に幅広い視点から解説！〜 圏論からFRPの構築まで a岡部 健Ken Okabekentutorialbook@gmail.com 関数型プログラミングが『銀の弾丸』である という非常識な常識 2022Functional Programming as the Silver bullet, that is the Insane common sense 2022
JavaScriptの仕様はECMAScriptで、ECMAScript 2015（ES2015）、ECMAScript 2016（ES2016）...というように毎年進化を続けています。 これまでの仕様はES2021でした。 本日6月22日、ES2022は正式仕様として承認され、ES2022が最新仕様となりました。 22.06.2022 Ecma International approves new standards - Ecma International ブラウザ対応も完了しており、全モダンブラウザ（Google Chrome・Firefox・Safari・Microsoft Edge）でES2022の全機能が使えます。 本記事では、ES2022すべての新機能を紹介します。「何が使えるようになったのか？」「どうしてそれが必要だったのか？」が、できるだけわかりやすいように解説しました
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
2021年の「オブジェクト指向」を考える
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
継承は禁止するべき
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Shota Imai@えるエル on Twitter: "コンピュータサイエンスの世界でプログラマーに特に影響のある有名な書籍について、Web上で無料で読めるものがまとめてあります https://t.co/kU9FmMkXDw 現在でも変わらず読まれているものや、昔からこの業界にいるほ… https://t.co/kHEBpVdgrL"
コンピュータサイエンスの世界でプログラマーに特に影響のある有名な書籍について、Web上で無料で読めるものがまとめてあります https://t.co/kU9FmMkXDw 現在でも変わらず読まれているものや、昔からこの業界にいるほ… https://t.co/kHEBpVdgrL
ソフトウェア設計の学び方を考えるソフトウェア設計の 学び方を考える 2019年6月23日 ギルドワークス 増田 亨 DevLOVE X(10周年記念イベント) アジェンダ 1. 設計という課題 2. ソフトウェア設計の品質 3. 学習と成長 4. 設計の初歩を学ぶ 5. 設計の中級者への道 6. 設計の上級者への挑戦 2019/6/23 2 ソフトウェア設計という課題 2019/6/23 3 複雑さとの戦い 構成要素の数 構成要素間の関係 拡張と変更の繰り返し 2019/6/23 4 人間の知的能力の限界 構成要素の数 構成要素間の関係 拡張と変更の繰り返し 2019/6/23 5 ソフトウェア設計の品質 2019/6/23 6 構造と秩序 2019/6/23 7 時間とともに劣化する構造と秩序 2019/6/23 8 時間とともに進化する構造と秩序 2019/6/23 9 ソフトウェア設
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
オブジェクト指向宗教史
OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
Pythonのオブジェクト指向プログラミングを完全理解 - Qiita
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
クソコード動画「Userクラス」で考える技術的負債解消の観点
プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
現場で役立つシステム設計の原則メモ - Qiita
Clean Architectureは全てのプログラマにお奨めしたい良著｜erukiti
2020年の開発者が知っておくべき11の必須スキル - Qiita
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
マンガではわからない ソフトウェア開発の真理 | ドクセル
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
オブジェクト指向はすでに粒度が時代にあっていない - きしだのHatena
オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
Pythonにおけるデザインパターン - Pythonにおけるデザインパターン
関数型プログラミングが『銀の弾丸』であるという非常識な常識2022
正式仕様リリース！ JavaScriptの最新仕様ES2022で追加された「全」新機能
個人的なアプリケーション設計のバイブル3選 - Runner in the High
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
設計/コードレビューで"常に"心がけるポイント - little hands' lab
実はDDDってしっくりこないんです - タオルケット体操
ソフトウェア設計の学び方を考える
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
単一責任原則で無責任な多目的クラスを爆殺する - Qiita