【感想】ソフトウェアアーキテクチャの基礎

背景

エンジニアとして４年目を迎えようとしており、新規開発やリファクタ等をやるうえで目指すべき理想のアーキテクチャを明確にすべく、下記の本を購入。

www.oreilly.co.jp

1か月かけて読み切ったので、購入を検討される方向けに感想をメモ。

概要

アーキテクトとして必要な知識を丁寧に丁寧に今風の視点から解説した本。

実践的なアーキテクチャの解説から関係者とのコミュニケーションまで様々な角度から知識の説明がなされ多くの場面で読み返したいと感じた。

本書に実際のコードはあまり登場せず、詳細な実装よりも高レベルなアーキテクチャパターンの説明にも重点を置いてる。

良かった点

伝統から先端までアーキテクチャパターンを広く説明している。

本書の中盤では、伝統的なレイヤードアーキテクチャから流行り?のマイクロサービスまで、パフォーマンス・コスト・スケーラビリティ等様々な観点から、多くのページを割いて評価している。

これ一冊を読んでしまえば割と多くのパターンをカバーしてしまえる。良いコード／悪いコードで学ぶ設計入門や現場で役立つシステム設計の原則などの設計入門的な書籍を読んだ後にこの本を読めば新米アーキテクトとして知っておくべき最低限の知識は補完できるのではないだろうか。

アーキテクトの仕事の進め方を具体的な事例で紹介している

開発者とどんな関係性であるべきか、アーキテクチャの理解を進めるためのプレゼンテクニック、ビジネス側との交渉方法など、分析手法からちょっとした言葉遣いまでアーキテクトの具体的な業務の進め方を説明している。

自身が今まで失敗してきた事例はおおむねこの本にアンチパターンとして言及され、対処法まで細かく説明されているので、アーキテクトのみならず開発者も業務に入る前に通読しておくとストレスが少ない。

用語の説明など初心者への導入部分が手厚い

本書の序盤では、そもそもアーキテクチャとは？、何が良いアーキテクチャなのか？など定義や用語の説明に全体の1/3ほどのページを割いており、アーキテクト駆け出しの私でも序盤の説明があるおかげで本書を通読することができた。

また意外と図表も多く用いられており、「この説明図にする必要ある？」と感じるほどだ。(しかしこれが記憶の定着に役立つのかも)

注意が必要な点

本書は具体的なコードはほとんどなく、アーキテクチャの抽象的な説明(ex. イベント駆動)が多いので具体例は引用されているリンクやGitHub上のコードを探して読むと良い。

また丁寧に用語の説明があるとはいえ、私の場合は初めて聞く技術や概念も多かったので、読書中はnotionに知らない単語をメモしつつ適宜調べて文章への理解度を深める工夫をした。

まとめ

今回は「ソフトウェアアーキテクチャの基礎」を読んだ感想を述べた。

場面に応じて読み返すことで、より精密な理解を得られるので普段の業務中に手元に置いておきたい。

【書評】「Linuxカーネルの教科書」を読んだ

背景

c言語のmainメソッドはどこから呼ばれるのか？を追求した本 を読むにつれてOS(Linux)の知識不足を痛感し、半分読んだところで読み進めることが辛くなってきた。

さらに読み進めるためには、知識を補完する必要があると感じ以下の本を購入。

info.nikkeibp.co.jp

この記事はそれを読んだ時の感想であり僭越ながら書評です。

書評

想定される読者レベル

  • 基本情報レベルの知識がある
  • WSLでもDockerでも何でもいいのでLinuxのような環境でコマンド操作をしたことがある人

良いところ

内容としては、Linuxカーネル周りの初歩の初歩が広く浅くカバーされていると感じた。

この網羅性を割と読みやすい分量でまとめてあり、本腰を入れれば1週間以下で読了できるのではないかと思う。

また各章の最後には、サンプルプログラムを動かし章の内容を「手を動かして」裏付けるような演習があり読者の理解を進めやすいような工夫がされている。

タスクスケジューリングのシミュレーション

物足りないと感じたところ

本の後半は難解と感じる分野が登場したが(コンテキストスイッチ・メモリ管理)、ページ数の関係から若干省略されたような説明が目立った。

もちろん概観をつかむのが本書の目的であるため、より深く時間をかけて理解したいという方はLinuxのしくみがおすすめ。（まだ読んでない

「Linuxのしくみ」を書店でパラパラめくったところ「Linuxカーネルの教科書」よりさらに演習が凝っていてかつカバーされる範囲が多いので、「Linuxカーネルの教科書」を読み終えた後に読んでみると良いと感じた。

まとめ

というわけで「Linuxカーネルの教科書」を読んでの感想等をまとめた。

もちろんいい本だと思うのでインフラに興味が出始めた方や、インフラエンジニアを目指す人にはお勧めしたい。

以上。

NestJS x TypeORMでcustom repositoryをDIしたかった

注) やりたいことについて、ただ失敗しただけなので有用性は有りません

これはなに

NestJSのORMとしてTypeORMを使っていた際、かゆいところに手が届かなかったので、これのメモ

背景

TypeORMは自動生成したRepositoryをDI(注入)し、saveやupsertメソッドを独自実装することなく使用できる。

@Module({
  imports: [TypeOrmModule.forFeature([User])], // Dynamic module
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User) // users.module.tsでprovidersに登録されたrepositoryをDI
    private usersRepository: Repository<User>,
  ) {}

  async findAll(): Promise<User[]> {
    return this.usersRepository.find();
  }
  ...

しかしこの方法だとDB操作に関する処理を独自に追加したくなったとき、サービスクラス(ロジック)にDBに関する処理が流出してしまう。 また単体テストを書く際に、Repositoryをモックしづらく、テストコードの整備が進まない。

そこでStack overflowを参考にTypeORMのRepository<T>を継承したクラスを追加

export class ArticlesRepository extends Repository<Article> {
  async customSave(dto: CreateArticleDto): Promise<Article> {
    console.log('custom save called!!');
    return await this.save(dto);
  }
}

@Module({
  // entityでなくrepositoryを引数に渡す
  // https://stackoverflow.com/questions/60777204/typeerror-repository-method-is-not-a-function-nestjs-typeorm
  imports: [TypeOrmModule.forFeature([ArticleRepository])],
  controllers: [ArticleController],
  providers: [ArticleService],
})
export class ArticlesModule {}

実行、、、失敗

[Nest] 74  - 07/26/2022, 8:55:33 AM   ERROR [ExceptionsHandler] this.repository.customSave is not a function
TypeError: this.repository.customSave is not a function
    at ArticleService.create (/backend/src/articles/article.service.ts:13:28)
    ...

調査するとこんなIssueが

カスタムリポジトリのインスタンスは @nestjs/core ではなく typeorm ライブラリによって生成されるため、依存性注入機構を利用することはできません。それでも、EntityManager (typeorm からカスタムリポジトリに渡される) を使って、いつでも別のカスタムリポジトリのインスタンスを取得することができます。

なんだと、、、

EntityManagerをDI(コンストラクタインジェクション)することはできんのか、、？

PS) Laravelでクリーンアーキテクチャやるときみたいにロジックはインターフェースを使うよう(抽象に依存)にしたらいいのかも

まとめ

  • よく言われる「NodeのまともなORM問題」の一端に触れた気がする
  • 今やるならPrismaなのか？？？
  • 指摘歓迎

【読書ノート】人は話し方が9割

  • 人は誰しも自分に一番興味がある。人は自分をわかってくれる人を好きになる。つまり話し方より聞き方のほうが重要
  • 「正しさ」自体は必ずしも求められない。
  • 話し上手な人は余計な人ことは言わない
  • 苦手な人と無理に話す必要はない
  • 悪口は言わない（無理です。）

【読書ノート】勉強の哲学

読書ノート

  • 勉強とは、所属している環境のコード（ノリ）から外れ、ノリが悪くなることである。これはこざかしい、言葉を恐れず言うならば「キモイ」状態となる.

  • 言葉の意味とは、その環境によって変わる。辞書に載っているのは「最もよく使われている用法」が取り上げられているだけである。

  • そのコードから外れるにはボケと突っ込み（ユーモアとアイロニー）がある。ボケはわざとコードからずれる横展開（目移り）、突っ込みはその環境から一歩下がり、その根拠を疑うこと。

  • どちらの方法も勉強の範囲が無限となり手が付けられなくなる。そこで自分の無意味な拘りをもとに、いったんはこれで良しとする。

  • 専門書と一般書は分ける。他者から信頼されているコミュニティ「学問」を基本とし、その上に実践を重ねていく。入門書と教科書から専門書に入っていく。

【読書ノート】FBI捜査官が教える「しぐさ」の心理学

読書ノート

おもいだせるぶｂ要約

  • 偽りの少ない、ノンバーバルなメッセージを読み取れば、良い人間関係を築ける（同僚、友人、家族 etc...）
  • 人間で一番正直な部分（嘘を付けない部分）は足
  • 顔は一番嘘をつく（瞳孔などは正直な反応をするが）
  • 話の内容より、ノンバーバルな行動が重要な場面さえある
  • 嘘を見抜くことは訓練を積んでも6割程度の精度しかない（人間関係を壊しかねないので慎重に！）