アル中プログラマの備忘録。もはやコーディングしてないけど。

酔いどれまさになう。プログラマとして就職し、システムエンジニア、プロジェクトマネージャーと立場を変えながら、システム開発に関わるとあるアル中の成長記録。

システム開発

エリック・エヴァンスのドメイン駆動設計(DDD本)読書会

投稿日:2013年12月15日 更新日:

エリック・エヴァンスのドメイン駆動設計
エリック・エヴァンスのドメイン駆動設計(DDD本) の読書会を社内有志で行いました。
その時の記録を残しておきます。

第0回

準備を兼ねた第0回は、スケジュールや進行方法について相談しました。

スケジュールと目標

進行

  • 週1で1回1.5〜2.0時間
  • 年内にやり切ることを目標

進行方法

事前に考えてきた方法で第一章を進行してみました。

  • 交代で音読:50分ぐらい
  • なにかあれば付箋にメモ:音読と並行
  • 説明しながら付箋を貼る:10分ぐらい
  • 注目度が高い点について自由に話す:15分ぐらい
  • 何かまとめる:5分ぐらい

第0回
これだけ見てもわからないかと思いますが、次のような結論になりました。
「【ドメイン】と言うのはよく分かりませんが、この本の内容はどうも既になんとなく知っていることのようです。ただし、正しくと分かっているかも怪しく、知っているとできているかは違うのでこれからしっかり勉強しましょう。」

ふりかえり

最後にこの読書会自体に対してのふりかえりとして10分程度でKPTをやりました。
KPT
結果として、次回は音読する人は立って情熱的に読むことに決まりました。
また問題点にある【人が少ない】というのは人が増えてくれたらいいですね。そのためにも、楽しく何か得るものがある会にしたいです。
個人的にはきちんと終わらせて、打ち上げ飲み会ができたら最高だと思います。

ここまででちょうど1.5時間でした。第一章は短いのでこの程度でしたが、ボリュームがある章では少々厳しいかもしれません。適宜、進行方法をアップデートしながらやって行きたいと思います。

第1回

前回決めたタイムテーブルに従って進めます。早速、前回のTryであがったお菓子についてメンバーが持ってきてくれました。
お菓子

第2章輪読

輪読自体は1時間ほどで終了。各々のメモを貼って、ディスカッションをしました。(写真だと見づらいですね)
第1回輪読
以下は抜粋です。

  • 【モデル】≠図である。(図はあくまでモデルを説明する手段の一つ、完全な図を目指すのはお門違い)
  • DSL(ドメイン固有言語)や暗黙知の共有に通じる話だなぁ
  • 各々の頭の中にあるイメージをどのように共有して統一(整合)していくかという話なのかな
  • やはり今まで暗黙のうちにやられていたことのようだ(ただし、理解してやるのは大事だと思う)

メンバーの共通見解として、この章の言いたいことは【同じ言葉で語ろう!!】という事にまとまりました。
同じ言葉を使うのは、ドメインエキスパートと開発者の間でもあるし、会話・設計書・図・コードの間でもあります。

ふりかえり

第1回に対してのKPTです。
KPT
立っての輪読は継続となりました。お菓子も好評です。

写真を見ると分かると思いますが、ペンが薄いので新しいものが欲しいというのと、誰の意見かわかるように付箋の色を変えたいというのが出ました。(現在4人しかいないので、分けるのは簡単です)

まとめが弱いというのは人数が少なく意見も少ないというのもありますが、だんだん良くなっていくといいなと思います。

一旦立ち止まるというのは、1章を4人で読むと量が多いので途中キリの良いところで立ち止まって、理解度や疑問点について問題ないかを確認するタイミンが欲しいというものでした。

なんとか無事2回目を終えてホッとしています。

第2回

第3章【モデルと実装を結びつける】輪読

輪読
【モデル】は分析の手段にも設計の手段にもなります。ただし、それぞれで別のモデルを使ったり、分析に偏りすぎて(実装がJavaの場合はオブジェクト指向に則るなどの)設計側の原則を無視していたり、逆に実装に偏りすぎていてドメインの必要な概念が欠落したモデルだとうまく効果を発揮できません。
優れた【モデル】は一度では作成できず、知識を噛み砕き、何度も洗煉させていく必要があります。そのためにもモデラとプログラマを分けるは得策ではない。
といったことが書いてあったと思います。

ふりかえり

ふりかえり
今回まで1章を約1.5h〜2hでやってきていましたが、自分が読んでる部分が頭に入らないなどの意見がでました。
また、1章を4人程度の人数一周で読みきってしまうのは、担当分が長く感じるという意見も出ました。
とりあえず次回はキリのいいところではなく、単純にページで区切ってやってみることに決まりました。

第3回

第2部【モデル駆動設計の構成要素】〜 第4章【ドメインを隔離する】のドメイン層はモデルが息づく場所(P73)まで輪読

今回からは前回のKPTで出た案にしたがって、章単位ではなく時間が来た時点で終わりという形式で進めます。1人1ページずつ読んでいき、割と頻繁に区切って意見交換することにしました。だいたい50分で10ページほど進みました。
輪読
第2部からは少し具体的な話になりました。「ドメインに関する部分を、他の関心ごとと分ける」ために、具体的な手法として【レイヤー化アーキテクチャ】や【MVC】などについて説明されています。

レイヤー化アーキテクチャやMVC自体は既にに知っているので目新しさはありませんでしたが、それを綺麗に実践できてるプロジェクトにはなかなか会えないですねという話が出ました。
レイヤー化アーキテクチャ・MVCも考え方はシンプルですが、モデル駆動設計を実施するためにはとりあえず【ドメイン層】が分離されていれば良いらしいです。そうすることで、表示や永続化やその他もろもろのことを気にすることなく、【モデルと実装との整合性を保つ】ことができるそうです。。逆にそうでない場合は、コードを読んでもよくわからないし、テストは煩雑となかなかに辛いことになるそうです。(確かに、そういうのはよく目の当たりにしますし。コードの分かりづらさは頑張れば何とかなりますが、テストしづらいというのはいつも困ります。)

ですので、きちんと分けましょうと書かれていました。

ふりかえり

KPT
今回変えた進め方については概ね好評でしたが、前回までよりペースが落ちました。しかし、早く進めることより、理解しながらやりたいという事で今回の方式を継続することになりました。追加で実施するTryは決めませんでした。
ワークショップってのは、この読書会の時間を使って何かやってみたいという意見です。

第4回

第4章【ドメインを隔離する】「利口なUI アンチパターン」(P.74)〜  第5章【ソフトウェアで表現されたモデル】「エンティティ」(P.91) の途中まで輪読

輪読

利口なUI

前回【ドメインを他のことと分ける】ということを学びました。そして、その例としてきたのが【レイヤー化アーキテクチャ】でした。今回はその逆のパターンとして【利口なUI】とう選択肢について考えます。

【利口なUI】とは次のような実装です。

  • ビジネスロジックをUIに入れる
  • アプリケーションは機能毎に独立したIFとして実装し、ビジネスルールもそこに入れる
  • 関係DBをデータ共有のリポジトリとして使う

利点(言い訳)

  • 単純なアプリケーションの場合は簡単ですぐ作れる(モデル駆動設計は単純なアプリケーションでもスキルを要求する)
  • 機能単位で分割しているのでリリースタイミングを調整しやすい

問題点

  • 再利用も抽象化もされず、コピペのオンパレード
  • リファクタリングしづらい
  • 複雑になってくるとお手上げで、一度「利口なUI」を選択すると、それをやめてモデル駆動設計を行うにはすべて作り直し

モデル駆動設計に取り組むには、最初からふさわしい やり方で設計をする必要があるそうです。つまり残念なことに、実際の仕事では既に手遅れのプロジェクトも多数あるということです。

エンティティ

第5章では【エンティティ】、【値オブジェクト】、【サービス】というモデルを表現する3つの要素について説明しています。
まず、モデル間の関係を減らすこと(疎結合にする)ことが大切とされています。これはオブジェクト指向などでも言われておりその通りだと思います。ドメイン駆動設計の場合は、そうすることで残った関係がより本質を表すようになるらしいです。

その上で最初の【エンティティ】とは定義が属性によってではなく【同一性】によって行われるオブジェクトのことだそうです。
例えば、「ある人」は属性として「名前」、「年齢」、「身長」、「体重」 などを持っていいます。そしてもし、これらが変わったとしても、別の人にはなりません。この場合、何をもって「ある人」が同一か判断するかは少し難しいですが、ソフトウェアシステムでは一意の識別子を割り当てるなどして対応ができます。
すべてのオブジェクトがエンティティになるわけではなく、たとえ現実世界では同一のものでも、アプリケーションが対象としている問題によってエンティティになったりならなかったりするそうです。(例では座席について書いてあり、指定席は座席番号で識別できるエンティティであるが、自由席は識別する必要ないのでエンティティでないと説明されていました)

ふりかえり

KPT
いったん付箋に書いて、それを貼りながら話をしていましたが、人数も少ないので直接ホワイトボードに書き込みながらの方がいいねという話になりました。付箋ですと小さくて見づらいという意見も出てたので、次は随時直接書き込みながら進めてみることにします。

第5回

「エンティティをモデル化する」(P.91)〜「値オブジェクト」(P.102)輪読

輪読
前回の続きで【エンティティ】の説明と、モデルの別の構成要素である【値オブジェクト】の説明でした。エンティティだけの説明では、だからどうしたのかと思っていましたが、値オブジェクトと比べることで違いはよく分かりました。
ただし、依然としてそれでどうなるのかというのはやや曖昧です。

エンティティと値オブジェクトの違い

本文には【エンティティ】が同一性(どれであるか?/誰であるか?)を重要視するのに対して、【値オブジェクト】は何であるか?のみを重視するとあり、例として「何色のペンかは大事だが、どのペン(代えのものかどうか)は重要じゃない」などと説明されていました。

エンティティの説明の中で、同一性の重要性を説明してあるため、つい全てに同一性をもたせるのがいいように思えますが、やりすぎると良くないようです。やりすぎると同一性を持つという事の意味も薄れるし、管理も大変なため関係と同様に本質でない部分は減らしていく必要があるようです。

値オブジェクトの不変という性質

何であるかが重要な【値オブジェクト】にとっては、値が違うという事は別のものという事になります。つまり、値を変えるには、別のオブジェクトで置き換えるしかありません。

これ(値が変わらないことが保証されていること)によって、DBスキーマの非正規化を使った高速化をしてもデータの整合性を保証したり、デザインパターンのFlyweightパターンを安心して使えたりします。

ふりかえり

KPT
少人数の同じメンバーで続けているため、そろそろネタが出てこなくなってきました。
せっかくやってるので、色々意見ある方が愉しいですが、難しいです。
そういう状況ですので、次回は再度進行についても話し合えたらと思います。

第6回

「サービス」(P.103)〜「モジュール」の途中まで輪読

輪読
前回までで【エンティティ】と【値オブジェクト】について勉強しました。しかし、どちらに属するのも不自然な処理がある場合は【サービス】として定義します。

  •  サービスは状態を持たず、それ以前の操作に影響されません(状態を持つならその状態とともにエンティティか値オブジェクトになります)
  • サービスにもレイヤーがあります(インフラストラクチャ層や、アプリケーション層など)
  • 複数のエンティティや値オブジェクトの協調動作をまとめてサービスとすれば、適切なインターフェースになります

後半はモジュールについてです。少々脱線しますが、(メンバーにRubyを使っている人がいたので)Rubyのモジュールという機能(?)の話が聞けて面白かったです。
よく言われる高凝集・疎結合の話について書かれていました。作っている途中で初期の分類が良くなかった事が分かることはよくあります。しかし、リファクタリングするには影響範囲が大きく、初期の分類のまま放置されることが多い気がします。モデル駆動設計では、モジュールをうまく使い全体の俯瞰や関係ある部分の詳細のみへの注目などをやりやすくします。モデルがあれば、会話時にもどの部分についての話かもわかりやすく便利です。
理想はそうでしょうが、どうしても要素を足していく際にぎこちなくなってしまうというのが意見として多かったです。特に既存部分に一切手を入れれない事情がある場合はそうならざるを得ないと嘆いていました。

ふりかえり

KPT
内容ではなく進行方法についてふりかえりをしました。今の方法ですとおおよそ10P/回程度のペースですので、約500Pあるこの本ですと1年かかってしまう(当初の目標までに終わらない)と指摘が出ました。計算し直すと、年度内(回数では20回ほど)で終わりを目指すには約30P/回のペースですすめる必要がありそうです。まずは試しに1回の読書会を時間ではなくページで区切ることにしてみます。2時間あればよめそうですが、無理ならまた考え直します。宿題は次回までにスケジュールを組むことです。

第7回

「モデリングパラダイム」の続き(P.117)〜「リポジトリ」の途中まで輪読

輪読
オブジェクト世界における【オブジェクトでないもの】とはなにか?代表は関係データベースです。ドメインモデルは(オブジェクトモデルでなくても良いため)【オブジェクトでないもの】を加えることができます。ただし、うまくやらないとすぐにモデル駆動設計が失われてしまいます。うまく混ぜるには次のことを気をつけます。

  • ユビキタス言語に頼る(一貫する)
  •  UMLにこだわらず、合ったものを使う
  • 懐疑的であること ※難しかった

技術的な側面にとらわれると、モデルがダメになるので気をつけなければいけません。

輪読
オブジェクトには単にコンストラクタでメモリ上に生成されてからGC等で抹殺されるまでの期間を超えて(ライスサイクルが)存在します。そのライフサイクルを実現に関係する、【集約】と【ファクトリ】と【リポジトリ】について書かれています。大事なことは、オブジェクトに対する変更の一貫性を保つことです。

【集約】は文字通り、複数のオブジェクトをまとめており、1つの【ルートエンティティ】が存在するします。集約の定義は、その内外の境界線の定義と等しく、外からは【ルートエンティティ】経由でしか内部への操作ができません。重要そうな特徴には以下のものが有ります。

  • 【ルートエンティティ】は普遍性をチェックする
  • 集約外のオブジェクトは(一時的な使用を除き)集約内のオブジェクトへの参照を保持することはできない
  • 集約内への変更は集約全体の不変条件すべてが満たされなければならない

【ファクトリ】は以下のような理由でオブジェクトの生成を隠蔽します。

  • 複雑な生成操作はオブジェクト本来の責務と無関係
  • 上記理由で利用側が組立を行うとカプセル化に違反している
  • 利用側に対して実装を隠蔽したい

ファクトリは隠蔽しているだけですので、ドメインモデル上で何の責務も負っていませんがドメイン設計の一部です。定義する場所としてふさわしいのは以下になります。いずれの場合も不変条件を満たしたオブジェクトを生成するのが大切です。

  • 集約のルートエンティティ(既存の集約に要素を追加する場合など)
  • オブジェクトの生成に関わるオブジェクト(生成に必要な情報を取得する)
  • 専用のオブジェクト(自然な置き場所がない場合)

ふりかえり

KPTではなく雑談ベースで実施しました。今回から30P/回にしてみましたが、図が多かったせいか、時間では1時間40分ほどでおわりました。無理の無さそうなペースではありますが、内容が難しくなると厳しいかもしれません。予習するべきかについても話題になりましたが、手が回らないためしばらく今回の方法で続けて見ることに決定しました。

第8回

「リポジトリ」(P.148)~「オブジェクトの生成」(P.176)輪読

輪読
第6章は特に集約に注目しているようです。前回、集約の要素の生成時に不変条件を満たすために【ファクトリ】を学びました。【リポジトリ】は、ライフサイクル(newされてからGCで回収されるよりも長く、永続化などを通して、本当に不要なるまでは続く)に注目しています。一度DBに保存されたオブジェクトのは検索すればどこからでも取得可能です。しかし、どこからでも取得してしまうとドメイン層が侵食されてしまいます。それを回避するために、【リポジトリ】にDBアクセスなどをカプセル化してしまおうということのようです。(利用側からはメモリ上にあるのか、DB上にあるのか、もしかしたらファイルにあるかもしれないですが、その区別がつかないようになります)
簡単にまとめます。

  • 【リポジトリ】は集約のルートエンティティに対してのみ提供する(境界線)
  • 追加、削除、取得のメソッドを提供し、その実装は隠蔽する(ドメインモデルに集中できるようにオブジェクト取得の技術要素は隠す)
  • 複雑なオブジェクトの生成を隠蔽するという意味ではファクトリと似ている
  • ただし、生成と再生成はやはり意味が違うので、リポジトリでDBから取り出し、オブジェクト構築はファクトリに移譲する事もできる

続いての第7章「言語を利用する:応用例」は今まで見た以下のパターンを組み合わせて使う例になっています。

  • ドメインの隔離(レイヤー化アーキテクチャなど)
  • 関連、エンティティ、値オブジェクト、サービス
  • 集約、ファクトリ、リポジトリ

写真では右半分の図について考えていきます。

  1. ドメイン層の隔離を考えます
  2. エンティティと値オブジェクトを区別します(区別必要なものか?交換可能か?などで判断します)
  3. 関連の設計します(不要な相互参照を消していき、必要なものを目立たせます)
  4. 集約の境界を決めます(誰から見ても一意なエンティティが集約のルートエンティティ候補)
  5. リポジトリを選択します(各ルートエンティティに対して検索などが必要かで判断します)
  6. シナリオでチェックします(違和感ないか)
  7. オブジェクトの生成について考えます(モデルの不変条件を満たした状態でオブジェクトを生成できるように)

ふりかえり

今回はスキップしました。

第9回

「リファクタリングのために立ち止まる」(P.177)〜「ブレイクスルー」(P.206)輪読

輪読
ケーススタディの続きです。前回の段階では循環参照によってオブジェクトの生成が大変でした。今回はこの問題にリポジトリを追加することで対応します。リポジトリを介することで、生成が楽になります。(サンプルコードがあればよいのですが・・)

続いてモジュール分割について考えます。良くない例として各オブジェクトを【エンティティ】や【値オブジェクト】という種類で分類するケースが書かれています。ドメイン(ここでは輸送)について無意味なのでダメだそうです。良い例では「顧客」や「輸送」、「請求」に分類しており、モジュール間の関係だけでもざっくりと意味がわかる用になっています。見比べると断然後者のほうがわかりやすいです。

最後に、これに対して機能を追加しますが、「アナリシスパターン」と「エンタープライズセグメント」という知らない言葉が出てきます。詳細は本書の後の方や「エンタープライズ アプリケーションアーキテクチャパターン」に説明があるらしいです。


輪読
ローン管理アプリケーションを例に設計のブレイクスルーの様子を説明しています。ブレイクスルーはいきなり起こそうとしても無理で、ドメインへの理解を深める必要があり、そうしているとある気がつくように起きるらしいです。また、ブレイクスルーが起こるとモデルがガラリと変わってしまうため、修正は大変になるそうです。そのあたりは実際の仕事では、影響範囲が大きくなかなかGOサインが出ないように思います。

ふりかえり

今回は、技術的要素より読み物的な(ストーリ性のある)話で面白かったです。

第10回

「暗黙的な概念を明示的にする」(P.207)〜「仕様」の途中(P.236)輪読

2人しかおらず、ホワイトボードも書けなかったので簡単にまとめます。

  • 深いモデリングとは重要な概念が明示的に表現されています。
  • 重要な概念に気付けるよう、知識の噛み砕きとリファクタリングの繰り返しが必要です。
    • ドメインエキスパート(その分野の人)が使う言葉に注意します
      • より簡単な表現、用語は?
      • 用語の使い方を訂正されてないか?
      • 特定のフレーズを使った時にドメインエキスパートの困惑が消えることがないか?
    • ぎこちなさを精査する
      • 手続きによって説明しにくい複雑な処理があるか?
      • 新しい要求が出てくるたびに複雑さが増しているようなところは?
    • 自明のことを漏らさないように文献を読む
  • 「制約」はあちこちのメソッド内に散在し暗黙的な概念になりやすいです
    • 明示的にするには分離して名前をつけます
  • 【仕様】とは満たすべき基準を示すオブジェクトです
    • ビジネスルールなど(エンディティ、値オブジェクトの責務に合わない)
    • ドメインから切り離すことはできないので区別してドメイン内で扱います
    • 判定とともにルールとしてくくりだすことができコードもスッキリとします

ふりかえり

会話パートは面白いです。

第11回

「仕様」の途中(P.237)〜「概念の輪郭」の途中(P.267)輪読

輪読
前回学んだ【仕様】を用いたサンプルです。化学製品が詰まったドラム缶を収容可能なコンテナの条件を「コンテナ仕様」としてくくりだしています。これにより、うまくコンテナとドラム缶を対応付ける方法を考えます。(本書の例では最適化まではされていませんが)具体的なコードとクラス図があるのでイメージがつかみやすかったです。
輪読
第10章のしなやかな設計についてです。今回は関係するパターンのうち以下のものについてです。

  • 意図の明白なインスタンス( 名前が超重要です!名前から機能が分からず実装の中身を確認されるなんてカプセル化の意味がないということ)
  • 副作用のない関数(副作用の影響範囲を調べようとして中身を見ると(以下同様))
  • 表明 (事前条件、不変条件、事後条件がはっきりしてれば気にすることが少なくて済みます)
  • 概念の輪郭( 適度な粒度で凝集したまとまりに分割しよう)

ふりかえり

前回とは別メンバーですが、2人だけだと寂しいですし、読むのが大変です。

第12回

「概念の輪郭」の続き(P.268)〜「攻める角度」(P.297)輪読

輪読
前回に引き続き「しなやかな設計」のためのテクニックについてです。

  • 独立したクラス(そのクラス単体を調べれば理解できるように、不要な依存関係0を目指して可能な限り徹底的に低結合に保ちます)
  • 閉じた操作(操作が閉じていると安心して組み合わせることができます)
  • 宣言的設計(言語として強要できないため、モラルが必要だと思います)

コンテナ仕様を例にコードが載っていますが、量が多く読み疲れてしまって、あんまりすんなりと理解できませんでした。前回から出てきていましたが、まずは「副作用のある関数」と「副作用のない関数」にわけるのがテストもしやすいですし、手始めとしていいと思いました。
関数型言語Scalaの本を少し読みましたがやはり副作用は嫌われています。(すべてがダメというわけではないが、無いほうがミスが少なくなる)本自体はようやく半分すぎだが、大枠は学べたのと集まるのが難しくなってきているので、そろそろ終わりになりそうです。

ふりかえり

残念ながら今回も2人でした。2人だと白板を書いている余裕もなく大変です。

第13回

「アナリシスパターンを適用する」(P.299)〜「なぜ、フライウェイトではないのか?」(P.328)輪読

輪読
深いモデルとしなやかな設計について学んでいますが、実践には多くの話し合いと試行錯誤が必要になります。その過去の経験が「アナリシスパターン」にまとめられており取っ掛かりにすることができます。ゼロからモデルを考えるよりは、ベースがある分、モデルの形成が早くできそうに思えます。また、アナリシスパターンの他にもデザインパターンをモデルに関係づける方法についても書かれています。デザインパターンは具体的なクラス図にまで落とされていて、技術的側面のほうが強いように思われますが、中にはモデルを豊かにするものもあるとのことでした。本書ではストラテジーパターンとコンポジットパターンが説明されています。逆にドメインモデルに合わないものとしてフライウェイトパターンが紹介されています。
ただ、本質は話し合いと試行錯誤なので、カタログ(パターン)だけでどうにかしようとしてもダメそうです。あくまで参考程度に使うのが良さそうです。

ふりかえり

今回で集合での読書会は終了になりました。各自必要に応じて読み直しや、残りの部分を読むことになりました。
はじめて開いた会だったので本の最後まで行けなかったのは残念ですが、一人で読むよりはモチベーションを維持できて良かったと思います。また機会があれば開いてみたいと思います。

酔いどれまさになう。


-システム開発

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

セミナー

QCon Tokyo 2012に行って来ました

QCon Tokyo 2012 はじめて同時翻訳のレシーバ利用しました。 その場で訳されていてすごいと思いました。ある程度は台本があるのでしょうか? ラウンジではアジャイルマインドの同人誌が売っていた …

「増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編」WEB用のデザインパターン

入門書として 最初のたとえ話がありイメージをつかみやすい。 その後にサンプルのクラス図とシーケンス図、パターンのクラス図を見ればだいたい分かることができる。 それでも難しいところはコードと解説を読めば …

Jenkins実践入門

Jenkins 執事さん!公式サイトの人で、 CI(Continuous Integration、継続的インテグレーション)のためのサーバー(ソフト、サービス)。 継続的に開発、ビルド、テスト、修正、 …

Review

設計レビューを効果的に行うには、目的を理解してそれに沿った方法で行おう

レビューあるある 長い 喧嘩してる、槍玉に上げられてる 脱線する 重箱の隅をつついていている 不具合を見つけたけど黙ってる などなど、結果として時間はかかる、気分も悪い、その割には後で不具合が見つかる …

体系的に学ぶ安全なWebアプリケーションの作り方〜脆弱性が生まれる原理と対策の実践〜

体系的に学ぶ 安全なWebアプリケーションの作り方 Kindle版の方が安かったため、そちらを買いましたが、適宜参照しやすい紙の方を買ったほうが良かったです。 主なサンプルコードはPHPで書かれていま …

カテゴリー