開発人生25年で学んだ7つのソフトウェア原則（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Seven things I know after 25 years of development 原文公開日: 2025/01/27 原著者: zverok 日本語タイトルは内容に即したものにしました。 本記事は、私が2024年9月にEuRuKoカンファレンスで行ったキーノートスピーチを大まかに記事化したものです（スピーチの動画はこちらです）。残念ながら録画という形での登壇でしたが、それでも大変光栄なことでした。このテーマは私にとってとても重要なので、テキストで読みたい方のために、本記事で少々手を加えた形で公開することにいたしました。 私はかれこれ25年にもわたってソフトウェア開発に携わってきました。 そのうち20年間はメインの言語としてRubyを用いてきました。 私のRuby言語への貢献や、その他オープンソースへの貢献について
Web API設計ガイドライン | Future Enterprise Arch Guidelines
Web API設計ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに 本ガイドラインはWeb APIを利用する開発者向けに、RESTライクなWeb APIの主な設計手法をまとめ、システム開発プロジェクトにおける設計のベースラインを提供するために作成された。本ガイドラインを用いることで、開発チームは何を設計すべきか、どのような判断を下すべきかについて共通認識を得ることができる。また、設計の属人性を軽減させ、ナレッジやツールの横展開を容易にすることを狙いにしている。 前提条件 本ガイドラインの作成にあたってWeb APIは次の前提を持つと
aposd-vs-clean-code/README.md at main · johnousterhout/aposd-vs-clean-code
JOHN: Hi (Uncle) Bob! You and I have each written books on software design. We agree on some things, but there are some pretty big differences of opinion between my recent book A Philosophy of Software Design (hereafter "APOSD") and your classic book Clean Code. Thanks for agreeing to discuss those differences here. UB: My pleasure John. Before we begin, let me say that I've carefully read through
2024年末にデザインパターンについて考える - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Futureアドベントカレンダーの3日目のエントリーです。昨日は@yamat2667さんのFlutterの記事でした。 デザインパターンというと、普段のプログラミングから一歩踏み込んで設計力を上げたい人が履修すべきコンテンツのように思われているようなツイートなりを見かけます。オブジェクト指向言語全般に使える知識だ、とか、開発者同士のコミュニケーションに使えるぞ、とか、コードの質が上がるぞ、とか。 一方で、パターンを詰め込もうとすると逆にコード量が増えて、パターン由来の変なクラス名が増えたりして、設計が歪むぞ、というのも当初から言われてき
t_wadaさんにTROCCO®︎開発の悩みを壁打ちしてもらいました｜株式会社primeNumber
primeNumberのSoftwareEngineerの中根（@gtnao） です。 今回、特別講師として和田卓人さん（t_wadaさん）をお招きして社内勉強会を開催しました！ 勉強会はprimeNumberのオフィスで実施しました。社内には写真のように、広めのイベントスペースがあり、勉強会や輪読会がよく実施されています。 勉強会の様子。20名近くのメンバーが集まりました。勉強会は、ローンチから6年ほど経過したTROCCO®︎が抱えるリアルな悩みを、CTO鈴木（@kekekenta）と私中根が、t_wadaさんに公開壁打ちしてもらうスタイルで行いました。ここから先は、勉強会のアジェンダに沿って内容をご紹介していければと思います。 TROCCO®の前提知識ディスカッションを始める前に、TROCCO®︎の前提知識をt_wadaさんに説明させていただきました。その場で初めて共有する形式だったの
誰が作成しても1つの構造になるモデリング作成技術、Theory of Models に夢を見る
builderscon 2024 で発表した資料です。以下、トーク概要です。 Webアプリケーションを開発・運用していく中で、1つのテーブルに日時カラムが増えていったり、巨大なテーブルが爆誕した、という経験はありませんか。また、これがプログラムの複雑さに繋がることもあると思います。このような事態を…
「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ
Googleに存在するコードを読みやすく保守しやすい形に保つ取り組みを行うグループ「Code Health」が、「DRYを早まって適用しないこと」と題した記事を公開しました。 Google Testing Blog: Don't DRY Your Code Prematurely https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html DRYは「Don't Repeat Yourself」の略称で、コードを重複させないことを重視する考え方です。重複するコードが存在していると、特定の機能を変更しようとした時に同じ機能を持つ部分を全て探して同時に変更する必要があり、見落としやミスが発生する危険性が高まります。一方、コードの重複を防げていれば一カ所だけを変更すればOKというわけ。 一見DRYを厳しく適用
0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
private 関数にもテストを書きたいとき
「private 関数にはテストを書かない」というのが多数派だと思う。だが昨日、仕事で In-source testing を書いていたらふと private 関数にテストを書きたくなった。そこで、In-source testingができる環境下でもprivate 関数にテストを書くべきかを X で聞いてみたら何か盛り上がっていた。 (In-source Testing: https://vitest.dev/guide/in-source.html) 反応を見る限り、やはり「private 関数にはテストを書かない」の方が主流だった。Kent Beck先生の http://shoulditestprivatemethods.com を紹介するツイートにもそういった反応が寄せられていた。（ぶんぶんさん、教えてくれてありがとうございます。） （このサイト面白すぎますよね・・・） 自分の立場を
凄腕エンジニアさんから学んだ例外の話 - Qiita
はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth
デザインパターン〜とかアーキテクチャ〜〜とか・・・に行く途中の話
こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい
「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士
Ruby on Railsの作者として知られるDavid Heinemeier Hansson（DHH）氏が自身のブログに5月4日付けで投稿した記事「Even Amazon can't make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）が話題になっています。 これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）で紹介された、AWS Lambdaのサーバレスで作られたPrime Videoの監視サービス
ラーメンの構造に学ぶ、コード設計 - そこに汎用性はあるんか （≠Rahmen編）
プログラムを使ってある仕様を実現するとき、多くの場合、そこに"唯一の答"はありません。 同じ仕様、機能を実現するコードにも多様性があります。 プログラミングにおいてしばしば問題になるのが、「その様々なコードのうち、どのコードを選んで実装するか？」ということです。 とりあえず機能が実現されるという点においてはどのコードを選んでも同じであっても、その後の保守性や拡張性などにおいて、自分がどんなコードを選んで書くか という事は重要です。 今の時点では正しく動作しているコードであっても、可読性や拡張性などの観点でクソコード、悪いコードなどと揶揄される場面がしばしば見受けられます。クソコードというのはかなり強い言葉で、あまり良い言葉だとは思わないですが、その言葉を発する人からすると、どうしてもそう言いたくなるような問題があるのでしょう。 ところで、同じ労力で悪いコードを避けて実装できるのであれば、そ
美しいコードは“シンプルで無駄がない” イケてるエンジニアが大事にする「良いコード」「良いアーキテクチャ」とは | ログミーBusiness
エンジニアとして「やりたいことをできる」環境を作っていくためには、どうキャリアの道をつくっていけばいいのか？ 何を考え、何を学習し、日々どういうコードを書いていけばよいのか？ 「Meets Professional #1」に登壇したのは、元DMM、現デジタルハーツCTOの城倉和孝氏。今の開発現場と、これまでの経験からの気づきを共有しました。全2回。後半は、「イケてるエンジニア」になるために必要な学びについて。前回はこちら。 エンジニアはプログラミングの力で世界を変えることができる篭橋裕紀氏（以下、篭橋）：ありがとうございます。他に質問したい方はいますか？ 次のところのほうがもう少し詳しくいろいろな話が聞けるかなと思うので、そしたらテーマ2に。城倉さんお願いします。 城倉和孝氏（以下、城倉）：じゃあテーマ2ですね。先ほどのコースが3つあります。じゃあそれになるためにまずどうしたらいいのかとい
名前空間をさっくり理解する - Qiita
名前、つけてますか？ PHPにはnamespace(名前空間)という言語機能があります。 原初のPHPにはなかったのですが、PHP 5.3くらいからあるので、まあ平安時代には成立していたということです。それ以前の時代は App_Http_Controllers_User のような _ 区切りの擬似名前空間が用いられていたことがありました。現在では App\Http\Controllers\User のような \ 区切りの名前空間が利用できます。 名前空間付きのコード 名前空間が見慣れないという方のためにnamespaceのあるコードとしてLaravelで自動生成したControllerファイルの例を先に出しておきます。 <?php namespace App\Http\Controllers; use App\Models\Book; use App\Http\Requests\Store
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
“A Philosophy of Software Design” を30分でざっと理解する / Understand roughly "Philosophy of Software Design" in 30 minutes
【日本人エンジニア必携】英語命名規則の決定版 - Qiita
現実世界におけるスキーマ設計の妥協
DDD Demystified ~結局DDDとは何なのか？何でないのか？~ #phperkaigi_reject
バックエンドの設計で直したほうが良いコード9選
