There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結

Talked at Cloud Native Lounge #2「クラウドネイティブなシステムの継続的改善と企業文化」. https://forkwell.connpass.com/event/215798/

CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して

clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

※追記あり。最後の追記は 2021/04/25 21:40頃※ タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。 この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。 ※この記事では Web Application を前提とした話になっている。 DDDとは？https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 DDD、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ

iCARE Dev Meetup 20 で発表した資料です #icare_meetup p.7,8,61 https://graphql.org/ p.18 https://twitter.com/a_suenami/status/1379270185207484417 p.33 [SQLQL…

概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ

2021/04/10開催　Developer eXperience Day 2021 「クソコード動画『Userクラス』で考える技術的負債解消の観点」の解説資料です。 https://dxd2021.cto-a.org/program/time-table/b-3 クソコード動画はこちら …

はじめに 品質管理部の河野です。先日、 ソフトウェアテストシンポジウム 2021 東京 の企画セッションで「仕様整理のためのテスト設計入門」というタイトルで発表してきましたので、本ブログでは発表に至った経緯や発表の感想などを報告いたします。 発表の経緯 まず、タイトルを見た方は、仕様を整理するためにテスト設計を使うのか？ と考えられたと思いますが、その通りでテスト設計はテストケースを設計する行為なのですが、実はテストケースを設計する過程で仕様を整理していることが多いです。ということで、テスト設計のための技術である、テスト設計技法を理解しながら、演習を交えて仕様の整理を実感できるような構成でチュートリアル形式で90分の発表を行いました。 それで、このようなテーマを思いついたきっかけは、私が以前作成したテスト設計の入門のテキストを近くの開発者の方に「開発者向けにやったら需要ありますか？」と質問