とあるプログラマーの技術ブログ

Books

読んだ本のレビュー

books

【読書記録】アジャイルソフトウェア開発の奥義(4) ソフトウェアを腐敗させないためのSOLID原則 S

前回の記事 引き続きボブおじさんの名著を読み直している。 第7章 アジャイル設計とは? ソフトウェアの仕様は常に代わり続けるもので、仕様変更に耐えられず設計が劣化していくなら、それは自分たちの設計やプラクティスに問題があるのだとボブおじさんは言う。 ソフトウェアが腐敗し始めた兆候として以下の7つが挙げられている。 硬さもろさ移植性のなさ扱いにくさ不必要な複雑さ不必要な繰り返し不透明さ ソフトウェアの腐敗を防ぐために、アジャイル開発者はクリーンな設計を保つ努力をしなければならない。「アジャイルな設計とは何か?」について以下のように締めくくられている。 アジャイルな設計とは「プロセス(流れ)」や「…
2021-02-19
books

【読書記録】アジャイルソフトウェア開発の奥義 (3) 写経したい第6章

ボブおじさんの名著『アジャイルソフトウェアの奥義』を読み返しながら感想などをつらつらと書き連ねる、その3。 【読書記録】アジャイルソフトウェア開発の奥義 (1)【読書記録】アジャイルソフトウェア開発の奥義 (2) 第5章 リファクタリング エラトステネスの篩というアルゴリズムを使って素数を作るプログラムを題材に、少しずつリファクタリングしていく様子を実演する章。 リファクタリングは食後のキッチンを片付けるようなものだ。最初は後片付けをしなければ、それだけ食事時間は短くて済む。しかし、片付けておかないと、翌日の食事の用意をするときにもっと時間がかかってしまう。『アジャイルソフトウェア開発の奥義』…
2021-02-07
books

【読書記録】アジャイルソフトウェア開発の奥義 (2)

ボブおじさんの名著『アジャイルソフトウェアの奥義』を読み返しながら感想などをつらつらと書き連ねるシリーズ2回目。 第3章 プラニング この章では、XP(エクストリームプラニング)のプラクティスのひとつ「計画ゲーム」について説明されている。特筆すべき点はないので割愛。 第4章 テスティング テストコードを書くこと、テスト駆動で開発を行うことの重要さが説かれている。 つまり、テストを最初に書くという行為は、設計上の判断をふるいにかける行為でもあるのだ。『アジャイルソフトウェア開発の奥義』(第4章, p. 35) プログラムが解決しようとしている領域において、どの概念が他の概念より重要なのか、重要な…
2021-02-06
books

【読書記録】アジャイルソフトウェア開発の奥義 (1)

ボブおじさんことロバート・C・マーチンによる名著の第2版。長らく積ん読状態だったが、少しずつ読み進めながら感想などつらつらと書いていこうと思う。 https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9-%E7%AC%AC2%E7%89%88-%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%…
2021-02-03
books

Bookレビュー:Test-Driven React

https://www.amazon.co.jp/dp/B07VB5SFZ5/ 本の概要 タイトルのとおり、テスト駆動でReactアプリケーションを開発していく方法を学べる本。紙の本だと170ページとのことで、分量はそれほどでもない。ただ、チュートリアル形式の本なので、実際に手を動かしながら読んでいくのがよい。そうすると少し時間がかかる。 簡単なテストケースからスタートして段階的にコンポーネントを作成しながらReactについての説明もされるが、ある程度の知識(公式のドキュメントやチュートリアルを読み、簡単なReactアプリケーションを作成できるレベル)はあった方がよいと思われる。とくに5章のH…
2021-01-24
books

『React Explained』の感想 – React初学者にお薦めのチュートリアル本 –

『React Explained: Your Step-by-Step Guide to React』を読了した。 Manningから今秋出版予定の『React Hooks in Action』のアーリーアクセス版を読む前に旧来のReactをきちんと復習しておこうと思い、Kindle版で購入。 本書の特長 紙版で303ページと比較的コンパクト。2019年3月出版なので、情報は比較的新しい(ただしHooksは本書では取り扱わない)。演習問題やチュートリアルを手を動かしながら進めていく形式。 本書の構成 第1部(1章〜3章)は、Reactを学ぶための前提となるJavaScriptの知識が簡単に説明…
2020-06-07
books

チーム・ジャーニー 第09話の感想

第09話は「塹壕の中のプロダクトチーム」。社長命令により3つのプロダクトが統合されることになり、太秦がその開発リーダーに指名される。POもそれぞれのプロダクトにいて、とりまとめるシニアPOなるものがいて、この混合チームをどう取りまとめてプロダクト開発を推進していくのだろうか。 複数チームの運営を難しくする要因は「情報流通の不全」であるとして、情報流通のための境界設計をどうすべきかについて解説編で述べられており、 全体のミッション戦略チームミッション について、それぞれどのような情報流通の設計をすべきかが示されている。 現在関わってるプロジェクトだと、チームをまたがった情報流通ってちゃんとできて…
2020-03-30
books

チーム・ジャーニー 第08話の感想

第08話「一人の人間のようなチーム」 第07話で仮説キャンバスづくりに失敗した太秦のチームは、機能しない状態が続く。そんな中、自分たちが作っているツールでプロダクトバックログを管理してみるという試み(ドッグフーディング)が功を奏する。 仮説キャンバスが書けなかったのは、プロダクトがどうあるべきかの仮説すら持てていなかったのが原因だったのだ。自分たちがユーザーとして使いたくなるようなプロダクトを作る、というチームの共通の目標を立てることで、チームとして再出発することができるのだった。 解説では、「3つの問い」に再度向き合うことについて述べられている。チームとしてスタートした段階では個人のWhyか…
2020-03-22

チーム・ジャーニー 第07話の感想

第07話「チームの共通理解を深める」。 頼りの蔵屋敷さんが別のチームに行ってしまったり、経営陣からのプレッシャーの押され無理な要求を出した挙げ句、スプリント中止権限を発動してしまうPOの砂子さん。この状況を打破するためには? 開発チーム、PO、ステークホルダー間の分断を埋めるために、仮設キャンバスを一緒につくるようなプロセス、場作りが有効だと説明されている。その際、開発者とPOでは持っている知識や経験、ものの見方が違うから、解像度を揃えて取り組む必要がある。 僕の今のチームではPOの役割が独立してなくて兼任していたりするので、チーム vs. POという分断はないのだけれど、チームの外側のステー…
2020-03-21
books

チーム・ジャーニー 第06話の感想

第06話は「分散チームへの適応」。 改めてスクラムに取り組み直し、軌道に乗り始めた太秦のチームだったが、また想定外の状況が発生する。リモートワークやパートタイムの開発者がチームに加わり、スクラムイベントを回せなくなってしまう。崩壊しそうなチームを集めたミーティングの場で、蔵屋敷さんは言う。 新しいメンバーが増えて、活動上の制約が現れた。状況はすでに変わっている。今までどおりを維持しようとするのは、適応とは呼ばない。『チーム・ジャーニー』p.99 そして、スクラムイベントを昼の部と夜の部に分けてしまおうという突拍子もない提案がなされる。 解説編では、「分断」による様々な問題と、それを乗り越えるた…
2020-03-17