6月はペースを取り戻しつつあった。終盤だけだけど。
気を抜くと全然読めてないなってなっているのでうまく自分のペースをコントロールしていきたい。
読んだ本
読み手につたわる文章 - テクニカルライティング
booth.pm
会社で献本されたんだけど、出社してなくて結局買って読んだ。
ページ数が少ないからシュッと読めるし、中身が濃いのでおもしろい本だった。
共感を得たり、発見があったのは以下のようなところだった。
- Chapter1 テクニカルライティングをはじめる前に
- 1.2.2 自転車を「知らない」と描けない
- 全く絵が描けないんだけど、絵も一緒なんだなと思った
- Chapter2 エンジニアのためのテクニカルライティング
- 2.2.3 既知から未知に繋ごう
- これは人と話す時に無意識にやっていたことな気がしていて大事だなと思った
- 意識してやっていきたい
- 2.2.4 一つの段落では一つのことだけ書こう
- 大学の英語小論文の授業受けて習った内容の一つに近かった
- 主張を一つにするの大事よな
- 2.2.5 一度に把握できることは７つまで
- 多すぎてもダメなのはイメージつくけど具体的な数はイメージできてなかった
【コラム】変わっていく語感を拾おう
- 誤解を生む表現を誤解が生まれない表現で言い換えるの大事よな
- それが誤解が生まれやすい表現かどうかを知らないと出来ないからこのコラムの気持ちは大事にしていきたい
- 2.4.3 タイトルは「概要」か「○○の概要」か
- Chapter4 よいレビューの仕方とされ方
- 4.1.6 頼まれていないレビューはしない
- これはちょっとわかんないなー
- そもそも論間違ってんじゃんみたいなPull Requestのレビューをしたとき、それは頼まれてないのでレビューすべきではないみたいな話にはならないだろうと思うという点から、ほんのり違和感があるなと思った
そこにあるのが読み手 にとって取り返しのつかないような危険な間違いで、誰がどう見ても MUST FIX な ものであり、こちらから修正案も提供できる、というものでなければ、
- これに該当するとしたら、そもそも必要かどうかという点はレビューすべきものであるという考え方も出来るのかな
- Chapter5 どうやってテクニカルライティングを学ぶか
- テクニカルライティング検定なんてあるんだ
- ちょっと気になるので試験対策本読んでみようかなと思った
技術書の読書術
チームメイトが読んでいて、ちょっと前にセールだったので積んでた本。
そこまで長くない様子だったので読んでみた。
自分がなんとなくやってた読書術は悪くない方針だったんだなってことがわかってよかった。
気になったり共感したりしたのはこのあたり。
- 第1部
- 図書館の活用 ～貴重な本に出会う～
- 無料で読めるのは大きなメリット
- 良い本かどうかわからない本でも買わなくても読めるのは良いよな
- 大学の頃片っ端から図書館の本読んでたのすごく良い体験だった
- 家の近くの図書館も行きたい気持ちがあるけど、大学生の頃と比べるとあんまりなんだよなー
- コラム
- 「心にとっての読書は、身体にとっての運動と同じである」 ──リチャード・スティール（アイルランドの作家）
- くじ引き読書法
- 第2部
- 「『3』の発想」 ～1つのテーマで3冊の本を読む～
- 入門書を3冊見比べる
- 図書館で無料で読めるという選択肢があるとこれがやりやすいんだよな
- 同じ内容の本を読んで同じことを言っていれば大事な内容だし、同じ内容を学んでいるので読む速度も上がるしこの方法は個人的にも好き
- 読書に書ける時間
- 同じ本を何度も読む
- 流し読み => 手を動かしながら => まとめながら読もうという話
- まず一通り全体の流れを理解してからもう一度読むというふうにやっていたのですごくわかる
- 2週目にまとめをしちゃいがちなので、手を動かすフェーズを増やしてみるのもありかもしれないと思った
- 積読の解消法
- 「積読は解消しない」ｗ
- 同時にやるのも一冊ずつやるのもありなのでものに合わせて選択肢を取れると良いっぽい
- 筆者はなるべく感想をはやく返すため人に紹介された本は早めに集中してやるらしい
- 優先順位のつけ方
- 狩野分析法
- 重要度が高くて緊急度も高いものからやろうという話
- 1冊90分で読む時間制限読書法
- 90分で区切るやり方良さそう
- 技術書の飛ばし読みテクニック
- 受験の現代文でやった内容だった
- 特に「日本語の用法を取捨選択のヒントにする」の部分
- 大事な部分を抽出するのもテクニックで出来るのでそういうの大事だよな
- 逆に書く時にはそれを意識して書くことが大事でもあると思っている
- オーディオブックでインプット量を増大させる
- 第3部
- アウトプットの大事さという話
- プログラミングと同じで知識をインプットしたらアウトプットするとさらに良いことがあるからやっていこうなという話と認識した
現場で役立つシステム設計の原則
DDDを実際にどうやっていくかの話をまとめた本という認識。
5、6年前に読んでたけど、再度読んでみた。
- Chapter 1 小さくまとめてわかりやすくする
- 小さなクラスでわかりやすく安全にするという話
- 値を扱うための専用のクラスの値オブジェクト
- Money型とQuantity型いい例だよな
- 責務をクラスに閉じ込める
- Chapter2 場合分けのロジックを整理する
- ifなどの分岐ではなく、クラスに分けてinterfaceやenumを使いそれぞれに責務を分けて実装しましょうという話
- Chapter3 業務ロジックをわかりやすく整理する
- プレゼンテーション層+アプリケーション層+データソース層からさらにドメインモデルを定義する部分を用意する
- 各々の層の関心事と分離して業務ロジックのみに出来るのが良いこと
- Chapter4 ドメインモデルの考え方で設計する
- 業務分析をしっかりやろうという話
- それを元にコードの設計をしようという話
- すごくわかる
ドメインオブジェクトの設計の基本は現実の業務の中で使われている具体的な言葉の単位で業務ロジックを整理することです
ドメインモデルの設計でありがちな失敗に、業務では実際に使っていない抽象的な言葉をクラス名として使ってしまうことがあります
そういう意味の広い抽象的な名前を使ったクラスは、具体的には何も説明していません。業務の現実の詳細を的確にとらえてはいないのです。
- ドメインモデルとデータモデルの違い
- ドメインモデル
- 年齢が業務の関心事であれば年齢クラスを作る
- 内部的には生年月日を持つ
- 計算するメソッドを持つ
- データモデル
- テーブル設計の役割の部分がデータモデルの設計ということかと勝手に納得した
- 全体的にドメインモデルをビジネスサイド（ドメインエキスパート）から知識を得てどう理解していくかの話だった
- 改善を続けながらドメインモデルを成長させる
- Chapter 5 / Chapter 6 / Chapter 7
- Chapter 3にあった3層(プレゼンテーション層/アプリケーション層/データソース層)をどう実装していくかの話
- DBアクセスやフロントの関心事をしっかり分離して実装しよう
- アプリケーション層のサービスクラスを作りながらドメインモデルを育てていこうという話だった
- そのあたりの具体的な方法が載っていた
- プレゼンテーション層のhtmlのクラス名までドメインが出ていくのは理解できつつもやりすぎなんじゃないかと感じてしまった
- Chapter8 アプリケーション間の連携
- マイクロサービス間のAPI連携や他社との連携が一番イメージ近そうだなと思った
- Chapter9 オブジェクト指向の開発プロセス
- V字モデル(と言っているがウォーターフォールモデルなのかな？)でのやり方にこの本であった開発の方法がどう合わせていけるのかという話
- ソースコードを第一級のドキュメントとして活用するは本当にそうでしかない
- Chapter10
積読(読みたい本)
人を動かす
リーダーのための！コーチングスキル
スタッフエンジニア
積読が積読のまま
まるで進まないので一旦止めてる
過去に読んだ本
arata.hatenadiary.com
arata.hatenadiary.com
arata.hatenadiary.com
おすすめ
www.amazon.co.jp
