はじめに 前回に引き続き、ソフトウェア設計に関しての自分の考え方を整理していきたいと思います。今回は前回のモジュールの話の後続として、依存(=モジュール結合度)の話です。 モジュールの依存と種類 コードの複雑さをもたらすものの一つが、モジュールへの依存です。依存とはモジュールAとモジュールBの関係性のことです。あるモジュールのインタフェースに依存が多ければ多いほど、複雑性が高いと言えます。また、前回と同様にここでいうモジュールとは言語機能ではなく、関数/クラス/サービスなどの何等かの機能の塊です。様々な依存が考えられますが代表的なものは以下となります。 外部モジュールへの依存(メッセージ/データ結合) 構造体など入出力I/Fへの依存(スタンプ結合) グローバルな値への依存(共通結合) データフォーマットへの依存(外部結合) 実行順の依存 トランザクション境界の依存 基本的には古典的な結合度

はじめに 最近、APoSD(A Philosophy of Software Design)を読んで、ソフトウェア設計に関して色々思う事が出来たというか、整理してみたくなったので、記事にまとめてみました。なお、APoSDの言葉を多用はしていますが解説記事という分けでは無く、自分の考え方の言語化にしっくり来たので使わせてもらってるという感じです。 TL;DR モジュールとは関数/クラス/サービスなどの何等かの機能のまとまり 良いモジュールは複雑性を隠蔽する 複雑性を隠蔽しないモジュールの価値は低い モジュールとは？ プログラムは正しく動くことがまず何より大事ですが、その次というかほぼ同じくらい大事な事が読みやすく拡張しやすいことですよね？　コードは圧倒的に読みものなので、どう読みやすく、つまり理解しやすい状態にしておくかは重要な事です。APoSDでは複雑性が低いコード、という言い方をしていま

はじめに Next.js にて下記のようなテーブルを作成する際に、テーブルの各行をリンク化させつつ特定のセルをクリッカブル（例だと編集モードにして編集作業を行うイメージ）にするのが面倒くさかったので愚痴っていきたいと思います。 結論 テーブルにて行リンクが本当に必要か再検討すべし。 どうしても必要なら 色々と制約ついてしまうけど行リンクをやめてプログラムによる画面遷移にする div タグを用いて行リンクを実現させつつ（CSS グリッドを用いる）、テーブルを構築する のどちらかで実装するのが良さそう 'use client' import { useRouter } from 'next/navigation' const Table = () => { ... const router = useRouter() const handleRowClick = (row) => { rout

はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？　予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。

はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って

だから意味のない旧来の「詳細設計書」は消えてほしい、というお話。 前提 現場によって、いろいろと粒度や定義が異なるとは思いますが、この記事における旧来の「詳細設計書」とは、ソースコードに書くべき内容を日本語に書き下したものであったり、その「設計書」通りにソースコードを書けば正しいプログラムになることを前提にしている何か、のことを指します。 標記の件について 今さら私が主張するまでもなく昔から言われ続けていることではあります。 ささっとぐぐれば、いろいろな記事が出てきますし（以下は一例） 詳細設計書という名のゴミ | Gm7add9 「コーディングは設計か製造か」という考え方の違い - 人生は長い暇つぶし。 古くて著名なところでは、たとえばマーティン・ファウラーとか。 主張 なぜそのようなものが生まれるのか？ 経験上からは、やはりソフトウェア開発を「モノづくり」に当てはめている現場ほど「詳細

PHP の use 文では、クラス名や関数名、定数、名前空間などのエイリアスを設定できます。 <?php use App\Foo; use App\Bar as ABar; $foo = new Foo(); $bar = new ABar(); https://www.php.net/manual/ja/language.namespaces.importing.php この use 文は指定したシンボルにエイリアスを設定する、言い方を変えると名前空間をインポートするもので、オートロードでクラス定義 PHP ファイルを読み込むものではありません。*1 例えば、上記コードの場合、use 文の時点で App\Foo や App\Bar に対するオートロードは動作しません。 この動きを確認してみます。 use 文のみを実行 use 文でオートロードが動作するかは下記のようなコードで簡単に確かめ

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を厳しく適用

とあるシステム開発会社 ワイ「カタカタカタカタ・・・ッターーン！」 ワイ「よっしゃ、株式会社HogeFugaさんのWebサイト改修、完了や！」 ワイ「ふー、ほなタスクなくなってもうたわ」 ワイ「ワイ、仕事が早いからなぁ〜」 ワイ「すぐにタスクがなくなってしまうわ」 ワイ「なにか次のお仕事がないか、後輩プログラマー君に聞いてみよか」 ワイ「おーい、後輩くん！」 後輩「なんですか、やめ太郎さん？」 ワイ「お仕事なくなってもうたわ」 後輩「分かりました！」 後輩「すみません、ちょっとだけ待っててください！」 後輩「やめ太郎さんでもできそうなタスク、すぐに探しますね！」 ワイ「おう、ありがとうな！」 ワイ「（・・・ん？）」 ワイ「（やめ太郎さんでもできそうなタスク・・・？）」 ワイ「（なんか、ナチュラルに見下しが発生しとるような・・・？）」 ワイ「（いや、気のせいやな！）」 新タスク発生 後輩「や

ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法 作者:Vlad KhononovオライリージャパンAmazon 2021年にO'Reilly Media, Inc.から出版された「Learning Domain-Driven Design」の待望の日本語訳『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』がついに出版されます。 www.oreilly.com 訳者は、増田 亨さん！！ 2020年代に、ドメイン駆動設計を学ぶための最初の入り口としてどの本を読めば良いかは、かなり悩ましい...というのはよく言われるのですが（元祖のエバンス本はさすがにだいぶ古くなってきたし、回りくどい表現も多いし...）、そんな時におすすめできる1冊です。 2021年に原著が出版された時に買ってざっと読んでいたのですが、パート1で戦略的DDD（

プログラミングについて、最近考えてることについてのポエム。 基本的に、 GPT-4 と Claude-3-Opus を使った経験を念頭に置いて話をする。機械学習エンジニアではないので、あくまで利用者に徹した視点での話。仕事で生成AIを使ったパイプラインを作ったりはしている。 生成AIの進化速度を予測しておく 今大事なことは、今AIがどの程度の性能かという定点の話ではなく、その進化の速度を認識すること。 コード生成というタスクにおいて、生成AIモデルを人間に当てはめると、こんな感じの人物像を自分は持っている。 GPT-4: プログラミング経験2年目の大学2年生 Claude-3-Opus: プログラミング経験3年目の大学3年生 ここでいうn年目は、業務経験ではなく、プログラミングの単位がある大学での、教育課程としての経験年数。今のひたすら学習量を増やす方式だと、単に1年に1年分ぐらい賢くなっ

class HOGE{ public string $tel{ set{ if(!ctype_digit($value)){ throw new ValueError("電話番号は数値のみ"); } if(strlen($value) < 10){ throw new ValueError("電話番号は10文字以上"); } $this->tel = $value; } get{ return '電話番号は' . $this->tel; } } } $hoge = new HOGE(); $hoge->tel = '123456789012'; // OK $hoge->tel = 'abcdefghijkl'; // Uncaught ValueError: 電話番号は数値のみ $hoge->tel = '123'; // Uncaught ValueError: 電話番号は10文字以上

こんにちは！Xイノベーション本部プロダクトイノベーションセンターの米久保 剛です。 弊社のテックブログ上では今回が初めての記事執筆となります。アーキテクチャ設計やアプリケーション設計の話を中心に、不定期に情報発信していきたいと考えています。 YAGNI原則 YAGNI原則をご存知でしょうか。 エクストリーム・プログラミング（XP）の重要な原則の一つであるこの原則は、You Ain't Gonna Need Itのアクロニム（頭字語）から命名されています。日本語にすると「どうせ要らないって」というニュアンスでしょうか。推測に基づいて余計な機能を作り込んだところで将来実際に使われる可能性は低く、時間と労力を無駄にするばかりかコードの複雑化などのリスクさえあります。ですから、現時点でわかっている要件をちょうど満たすだけの機能を実装すべきであるとYAGNI原則は主張します。 YAGNI原則は機能（

最近アーキテクトなるお仕事になったようなので、コードやアーキテクチャ関連の本を読み漁っています。何冊か読んでいるんですが、まずは最近Kent Beckが出版した『Tidy First?』の話を書きたいと思います。 Tidy First? (English Edition) 作者:Beck, KentO'Reilly MediaAmazon パート1: Tydings 「Tidy」というと、USでは一時期からコンマリが大流行りしているようで、「Kondo」がそもそも動詞化していたりするなど一大ブームとなっている（た）ようです。コンマリといえばそう、「お片付け」なんですが、なんとなくここから着想を得ているのかなと思います。Netflixでも「Tidying Up with Marie Kondo」という番組が作られていたくらいです。 Tidyingは「片付け」ないしは「整理整頓」あたりで訳せそ

ま、このくらい知っておいてもらわないと&とりあえずこんだけ知ってればだいたいの処理が書けるクラス・インタフェースをまとめてみました。2024年版。 詳しく知りたい人は「プロになるJava」を！ java.lang.Class java.lang.Exception <- new java.lang.Integer java.lang.Object <- new java.lang.Runnable java.lang.String java.lang.System java.lang.Thread java.nio.file.Files <- new java.nio.file.Path <- new java.io.InputStream java.io.InputStreamReader java.io.BufferedReader java.io.OutputStream java.

GitHub CopilotにはCLIがあるのを思い出して、コマンドの実行結果をそのままプロンプトに渡すと、文脈に沿った仕事をお願いしやすいんじゃないか、と思って、試してみた。 git stashをよく使うのだけど、一覧になっていると、何がstashされているかわからないので、stashの保存時に、内容を要約してもらう、というタスクを試してみる。 なんらかのCLIにdry-run機能をつけている途中で、git stashしたいとする。 index f1f5a2f..dd70bf5 100755 --- a/cli.js +++ b/cli.js @@ -19,6 +19,10 @@ command } else { command.help(); } + }) + .arguments(['dry-run']) + .action(async(file) => { + console.lo

以前にデータベースを自作しようとして、SQLiteのアーキテクチャを見てみたらVMだったことに疑問を感じ、それをツイートしたところ作者からリプをもらいました。 作者いわく、次のような背景があったとのことでした。 SQLiteを作った当初はデータベースエンジンのことをよく知らないがコンパイラのことをよく知っていた SQLデータベース・エンジンを書くという問題をコンパイラ構築の問題として扱うのは自然なことだった データベースエンジンのコアの部分をVMにするという発想がまったくなかったので、どんなメリットがあるのか？と気になっていました。 それを作者に聞いたら、詳細な説明ページを作ってくれました。 個人的にVMにしたことで、評価&実行のパフォーマンスは多少良くなると思うが、データベースエンジンのパフォーマンスにそれほど寄与していないんじゃないかな？って思ったりしました。 本記事はそのページについ

仕事していて、こういうときはこうしたら？みたいなことを言ってるのだけど、出典がどこにあるか、というと、だいたいデザインパターンの本に載ってたやつのような気がするのだけど、チームメンバーにいきなり、この本を読もう、とか言い出すと、Java固有の話がほとんどだし、ただちに役に立つわけでもないのでは？みたいなことになるかもしれない。 でも、Java固有の話がほとんどであり…って喋ってる人はこういう本をすでに読んでるわけで、読まない側の人類の暮らしがどうなっているか検討できていないかもしれない。 あと、読んだのが学生のときなので、思い出で美化されていて、今読んだら、全然思ってたのと違う、みたいになってるかもしれない。 オブジェクト指向における再利用のためのデザインパターン 作者:Erich GammaSBクリエイティブAmazon だんだん、オブジェクト指向の人気が下がっていって、気に留める人が少