良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
ソフトウェアアーキテクトに必要なシステム設計知識を学んだ17冊 - yoshikipom Tech Blog
はじめに アーキテクチャ・デザイン全般 ソフトウェアアーキテクチャの基礎 Clean Architecture 達人に学ぶソフトウェアの構造と設計 Design It! ソフトウェアシステムアーキテクチャ構築の原理 データ指向アプリケーションデザイン マイクロサービス マイクロサービスアーキテクチャ マイクロサービスパターン 実践的システムデザインのためのコード解説 ソフトウェアアーキテクチャ・ハードパーツ ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 現場で役立つシステム設計の原則 要件定義 はじめよう！プロセス設計 ～要件定義のその前に はじめよう！ 要件定義 ～ビギナーからベテランまで はじめよう！システム設計 ～要件定義のその後に Web, Web API Webを支える技術 プロになるためのWeb技術
Clean Architecture を毎日１章ずつ完読しました（PDF公開） - そこに仁義はあるのか(仮)
以前のブログで100日かけてエリック・エヴァンスのドメイン駆動設計を完読しましたと書きましたが、それに続いて Clean Architecture も完読しました！ 4/21から始まり、（家庭の都合で2日おやすみもありましたが）毎日１章ずつ、全34章を無事に完読しました 🙌 そして、今回もそれぞれの章で学んだことを毎日ノートにまとめてツイートしていきました。 Clean Architectureもかなり長い間積んでいた本だったので、やっと消費できてよかった…。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘ドワンゴAmazon ツイートはこちらのモーメントにまとめています。 今回は他の方のツイートも一緒にモーメントに追加していきました。 モーメントは100個までしかツイートを登録で
100日間かけてエヴァンス本を完読しました（PDF公開） - そこに仁義はあるのか(仮)
11/25から3/4の100日間かけてエリック・エヴァンスのドメイン駆動設計を完読しました！ ソフトウェア開発の複雑さに立ち向かうための方法に「ドメイン駆動設計」があります。 エリック・エヴァンスのドメイン駆動設計（以降、エヴァンス本）は発売から20年・日本語訳発売から10年経っても読まれていて、ドメイン駆動設計の原著であり、多くのエンジニアが名著という一冊です。 その分厚さや内容が難しそうというイメージからずっと積んだままになっていている人も多いのではないでしょうか。 エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon 私もそんな一人で、ドメイン駆動設計をなんとなく知った風に過ごしていましたが、ドメイン駆動設計に関する勉強会への参加をきっかけにエヴァンス本と向き合い、知ったこと・学んだことを毎日1ページにまとめてツイートする活動を始めました。 100日間
抽象クラスにはなるべく実装メソッドはない方が良い？
タイトルの文面がどこで得た情報なのかが記憶が定かではないのですが、C#において、抽象クラスにはなるべく実装メソッドは書くべきではないと見聞きしたような覚えがあります。 しかし、上文の通り、どこで得た情報なのかが定かではなく、故に記憶違いの可能性もあり正しい知識なのか不安になったため、ここで質問させていただきます。 Webで調べてみても、解説しているコードの抽象クラス内に「抽象メソッド」と「実装されているメソッド」が混在しており、「タイトルの内容は間違いでは？」と半ば結論付けてはいるのですが、確信があるわけではありません。 参考までに、現在私が直面しているコードの内容を簡潔に一例として挙げさせていただきます。 【参考内容】 ※実装されているメソッドを「実装メソッド」と呼称します。 抽象クラスHogeBaseクラス内に、抽象メソッドHogeCalc、実装メソッドHogeDrawがある Hoge
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
表示順という属性を別テーブルに分ける - そーだいなるらくがき帳
最近、この説明を複数回したので記事にする。 要約 普段は 今北産業 派なのだが、3行考えるのが面倒なため、今後は大人の表現を使う。 「今北産業」をスタートアップ語にすると「マジ価値サマリー」になるらしい ちなみにここだけの話ですが、大人語にすると「要約」になります pic.twitter.com/Q8SflvBX7c— ところてん (@tokoroten) 2022年1月24日 画面に表示したい順(以下、表示順）は振る舞いの属性なので分ける 似たような振る舞いに関わる属性は別テーブルにわけると良い 普通に正規化しましょうって話。 表示順をカラムを追加して表現する よくあるテーブルは画面情報と合わせて表示順カラムがあるパターン。 こういうテーブルを作って SELECT * FROM items ORDER BY display_order_number; で表示順に取り出すパターン。 表示順
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
CSSの設計 | 第1回 枠とモジュールで考える
CSSの設計 第1回 枠とモジュールで考える このシリーズでは、なるべくメンテナンスしやすい、可読性の高いCSSを設計する考え方を解説します。第1回目は、現状のCSSの問題点と、枠とモジュールで設計する考え方を紹介します。（監修：フロントエンド・エンジニア高津戸 壮） はじめに 初出 この文章は『CSS Nite LP, Disk 26「CSS Preprocessor Shootout」』で高津戸が行った講演「CSSの設計」を元に、テキストとして再構成しています。 CSSはとてもシンプル 今「CSSの設計」を改めて考えるのは、なぜでしょうか。CSSの基本はとてもシンプルです。例えば、次のようにHTMLにクラスを付け、そのクラスに対してのスタイル指定をCSSで行うだけです。 <div class="box"> hoge </div> .box { color: red; } HTMLの要素
現場で役立つシステム設計の原則メモ - Qiita
This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ
《REST思想》と《リソース指向》と《Webページ》に関する（主にRailsの）話 - Qiita
これはいわゆるWeb APIについて、ということかなと推測しました。RESTというのはAPIのプロトコルのことだと思われている傾向がありますが、そういうわけではありません。Web全体についてのもので、APIについてもWebアプリについても適用されるものです。 実はRESTでは「統一インターフェイス」の制約からメソッドについて規定されていますが、URLの形については特に規定されません（もちろんAddressabilityの面で重要であることは言うまでもありません）。なので実は/books,/books/1でなくてもいいのですが、これを規約(CoC)でズバッときれいに決めてしまったのがRailsのすごいところの1つです。 本の追加や削除を行う場合は、本情報をJSON形式でPOSTリクエストのボディとして送ります。application/x-www-form-urlencoded形式で送ることは
はてなで大規模サービスのインフラを学んだ - ゆううきブログ
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
「設計なんて不要でしょ」について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 経緯 以前とある席で偶然シニアエンジニアの方と設計について議論することがありました。 その時に特に耳に残っていたのは以下の様な内容です。 クリーンアーキテクチャってテストしやすくする為のですよね？ 設計はコード書ける人が他のコードを書ける人に威張るための道具なのではないか？ 設計を学習するならブロックチェーンとかを勉強して技術力を高めるべきなのではないか？ リーダブルコードさえ読んでいれば設計は必要ないのではないか？ 設計なんて不要でしょ その方はかなり詳しく設計の歴史をしっていて尤もな事を言っていましたが、平成も終わる頃においてはその
変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレー
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方: 仙塲大也: 本
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
