技術書から得る

本

特に印象深かった技術書を紹介し、その知見やアイデアがどのように視野を広げ、開発に影響を与えたかを書いています。読者にとって、次の一手に繋がる技術書の発見や、新たな知識の吸収に役立…

運営しているクリエイター: たかふみ | Webエンジニア

「ドメイン駆動設計モデリング/実装ガイド」を読んでDDDを学ぶ。

どうも、たかふみです。開発に携わっているプロジェクトではドメイン駆動設計（Domain-Driven Design）が取り入れられています。「基礎からきちんと学んでおきたい」「だけど、難しい書籍で心折れたくない…」ということで、本書「ドメイン駆動設計モデリング/実装ガイド」を読み始めました。本記事には読んでいて重要だと感じたところ、覚えておきたいところをメモとして残しておきたいと想います。第1章 DDD概要Q.良いモデルとは？ A.ドメインの課題を解決で

【第1章】「WebAPI The Good Parts」を読んで"良いAPIとは何か"を学ぶ

どうも、たかふみです。より良いAPI設計・開発をするため、オライリー本「Web API The Good Parts」を読んでいるので、覚えておきたい内容をメモとして本記事にまとめておきたいと思います。本書の目的APIを開発するに当たり「どのように設計すれば良いのか」「どのような点に気をつければ良いのか」を知ること 1章 WebAPIとは何か1. APIの重要性 APIの公開により、他開発者による”サービスを活用したサービス開発”ができる。 2. パターン 3

あるべきを知ってバグを生む構造に気付く！「良いコード/悪いコードで学ぶ設計入門保守しやすい成長し続けるコードの書き方」を読んで

設計の入門書として名高い、ミノ駆動（@MinoDriven）さん著「良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方」を読みました。本書について著者があるべき設計をするために活用している”オブジェクト指向設計の実践的ノウハウを記した本”です。本書には各章の解説内容と「入門・実践・応用」のどれに該当するのかが一覧でまとめられているページがあるので、自分の読みたい内容・段階に応じて読み進めることができます。 ▼本書について著者本人が書いて

【設計の原則(7〜11章)】SOLID原則で変更に強いソフトウェアを作る@Clean Architectureを読んで学んだことメモ

どうも、たかふみです。前回に続き、今日は「設計の原則(第7章〜第11章)」です。 SOLID原則第7章：SRP 単一責任の原則関数をまとめる際は使用する人ごとで分ける。同じ処理をする関数だからといって使用する人が別なら分割する。第8章：OCP オープン・クローズドの原則この保護レベルに従うように設計を行う。ソフトウェアは「拡張のためのプログラム追加が簡単&修正に対する他機能への影響が小さい」という状態が理想的。そこで「機能の分割→コンポーネントの階層構造にまとめる」

【5章~6章&まとめ】ソースコードは依存度が低い&不変な状態にすべき！「プログラムですべきではないこと」まとめ@Clean Architectureを読んで学んだことメモ

どうも、たかふみです。前回に続き、今日は「第5章〜第6章」と「まとめ：3つの縛り」です。第5章：オブジェクト指向プログラミングオブジェクト指向設計でもっとも強力なのが「ポリモーフィズム」であると書かれています。 "ポリモーフィズム"によって、システム内のソースコードを独立させることができ、他機能への依存度を下げることができます。それにより関数の再利用ができたり、画面・処理・データの各担当者が別々で開発・デプロイをすることができたりすることができます。第6章：関数型プ

【3章~4章】プログラムは証明するために小さく分割する！@Clean Architectureを読んで学んだことメモ

どうも、たかふみです。前回に続き、今日は「第3章〜第4章」です。 3章：パラダイムの概要プログラミングをする際には3つの縛りがあり、これらによって我々がプログラミングをする際に"何をすべきではないか"ということが表現されています。(*1) この後の章でそれぞれの縛りについて説明されています。 4章：構造化プログラミングまず、テストはバグを見つけるために実行するものです。そのため、テストによってプログラムが正しく動くということは証明できませんが「テストが問題無い＝プロ

【1章~2章】Clean Architectureを読んで変更に柔軟なシステムを作る！@Clean Architectureを読んで学んだことメモ

メンテナンスしやすいシステムが作りたい！いや、Webエンジニアとして作らねばならない！ということで読み始めました「Clean Architecture 達人に学ぶソフトウェアの構造と設計」！読んだ章から学んだことや感じたことを自分のメモとして順番にまとめていきたいと思います。「これは少し違うんじゃない？」などあればコメントで頂けると嬉しいです！第1章設計とアーキテクチャシステム開発にかけられるお金・人手・時間は限られています。その限られたリソースで必要な条件

【3章】「いいよ。」って賛成と反対のどっちの意味で使います？会話もコードも"誤解されない"ことが重要です。@リーダブルコード

『これ一緒にしない？』「いいよ」『どっちの"いいよ？"』こんなやり取りを今まで何回繰り返してきたのでしょうか。日本語は曖昧ですね。 3章のテーマは「誤解されない名前をつける」です。コードを読む人に「どっちの意味？」と聞かれないように誤解されない名前をつけましょう。 ◼️あいまいな英語を使わない例えば下記のようなコードがあるとき、 resultに入っているのはどちらでしょうか。さて、どちらだと思いますか。本書には最善の名前とは"誤解されない名前である"というよ

【2章】変数を我が子のように扱う。そしたら命名するのも慎重になるのではないか。@リーダブルコード

家計簿をつけているのですが、コンビニで買うお菓子の散財率が高過ぎる。節約するならこういう所から削っていかないとですね。 2章から始まる第一部のテーマは「表面上の改善」です。変数名を変更したり、簡潔なコメントをつけたりと、すぐに良くできるところから変えていこうという内容です。コードの改善も節約も塵も積もれば山となる！小さなことを積み上げていきましょう。 2章：名前に情報を詰め込む一章と共通しているのは「知らない人がコードを読んでも短時間で理解できること」です。曖昧な命名

【1章】リーダブルコードで脱初心者！要約と感想を書いていく

"あらゆるエンジニアがオススメする！" "web系技術書で販売数トップクラス" "脱初心者したいなら読むべき！" 等々のキーワードが並ぶ本「リーダブルコードより良いコードを書くためのシンプルで実践的なテクニック」。会社にあったので借りて少しずつ読んでいます。今回は、読んで知ったこと、学んだことをnoteにまとめていきたいと思います。それでは始めます！一章理解しやすいコード優秀なプログラマになるために "理解しやすいコード"を書かなければいけない。知らない人が読んで