予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務
「継続性アーキテクト」という生き方 - エス・エム・エス エンジニア テックブログ
介護や医療、ヘルスケア、シニアライフなどの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織づくりやサービスの内製化を進めてきました。 「『継続性アーキテクト』という生き方」というタイトルをつけていますが、タイトルで名詞化しているのは釣りで、アーキテクトの仕事について書いています。これは私がアーキテクトという仕事の可能性について考える中で、「継続性」に注目するとその仕事の価値がより発揮されていくのではないかと考えた内容をまとめたものです。 アーキテクトが抱える葛藤 私は役割柄、採用などでソフトウェアエンジニア（以下、エンジニア）と面談をする機会が多く、年に約200人くらいの方と話をしており、キャリアについて話を聞く機会も多くあります。その中で多くの方のキャリアのゴールと
サービス立ち上げで学んだ「RDB設計で簡単にやってはいけないこと」8選｜いわむ@webエンジニア @k_iwamu
普段の業務でとあるサービスの開発を立ち上げフェーズから携わらせてもらっており、かつ最近嬉しいことに徐々に利用者が増えてきました！👏 そういった立ち上げ時期〜成長期に携わっていると(エンジニアのありがたい成長痛ですが)、 RDBの設計を変更しにくくなったり、機能追加に伴ってRDBの設計自体が複雑化するため、設計を見直したり深く考える機会も増えてきます。 そんな時期を経験しているからこそ、DB設計で学んだこともたくさんあります。 今回はたくさんの学びの中から絞って、 「サービス立ち上げで学んだ、RDB設計で簡単にやってはいけないこと8選」と題してまとめました。 ※ これは必ずしも「やってはいけない」ということではありません。 「導入の際は慎重に検討した方がいいのではないか」と思っていることを書いております。 ※ 私はMySQLを業務で使用しております。もし他のRDBだと違う状況になることなど
人の作ったWebアプリケーションのコードを見るときに注目しているところ - Runner in the High
普段見ているものをなんとなく書き出してみた。 インターフェイス あえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。 言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。 バリデーションロジック すべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのか
SQLアンチパターンもりもりDBを設計しよう！ - Qiita
概要 名著SQLアンチパターンを読み終えたので、それの復習のために悍ましいデータベースを作ろうと思った。 まず前半では、SQLアンチパターンを意図的に盛り込み、目も当てられない酷い設計をします。 そのあとリファクタリングを行なったER図に書き直していきます。 なお、真面目に書くと参考書の丸写しになってしまうので、この記事は アンチパターンもりもりのER図を見て嫌悪感を学習し、設計に役立てようという趣向のもと、詳しい説明は省きます。 とても良い本なので読んでください。 想定するシステムの概要と状況 目的において適切かはわかりませんが、とりあえず考えることの多い”お金”を扱うシステムを想定してみます。 私はブラックジョークが好きなので、今回は「ちょっと怖い金融屋さんが使う債務者管理システム」のER図を設計してみようと思います。 ざっくりした要件 債務者を登録でき、プロフィールを入力できる。 債
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ID生成方法についてあれこれ - Qiita
SOLIDの原則ってどんなふうに使うの？