本を書きました
『現場で役立つシステム設計の原則』
7月5日に発売になったこの本ですが、いろいろな方に書評を書いていただいけました。
ありがたいことです。こういうフィードバックは、うれしいし、とっても勉強になります。
私が自分でブックマークした範囲ですが、みなさんの書評を紹介させていただきます。
「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ
ブックマーク:543佐藤さんのこの書評は、大きな反響があったみたいですね。おかげさまで、本の売れ行きがぐんと伸びました(笑)。
本の全体の構成や話の流れを俯瞰的に、かつ要点を押さえた内容を、図をうまく使いながら紹介していただきました。
まえがきかなにかに「本書の構成」として書いてしかるべき内容ですね。もし第2版を書く機会(?)があれば、この内容をぜひ参考にさせていただいて「本書の構成」を追加させてもらおうと思っています。
私以上に、オブジェクト指向を熱く語っていただいので、オブジェクト指向アレルギー(?)の方には刺激が強すぎるかも(笑)。
「現場で役立つシステム設計の原則」の目次流し - 日々常々
ブックマーク:100irofさんのこの書評は、章ごとの要約をうまくまとめていただいた印象です。
この段階では「目次流し」なので、きっとじっくり読んだ後に、するどい突っ込み満載のブログが公開されるものと、期待しています(笑)。
@irofさん、@haljikさん, @yukieenさんたちが中心になって、大阪でこの本の読書会をやっていただいているようなので、そちらからのフィードバックも期待したい。機会があれば、読書会におじゃまさせてもらいたいなと考えています。
現場で役立つシステム設計の原則 - ひしだまの変更履歴
ブックマーク:93ひしだまさんが公開されているJavaの技術情報には、いつもほんとうにお世話になっているので、書評を書いていただいた時は、うれしい驚きでした。
ご指摘いただいた内容はとても参考になりました。性能面は、この本では意識的に触れないようにしたのですが、やはり、現場での実践的な原則として、そういう点まで含めた説明にすべきだったのかもしれません。
Web APIでの日付の扱いについては説明不足でした。
考え方としては、アプリケーションレベルでは、基本的には日時は、LocalDate/LocalTimeを使っているので、それをWeb API の日付の扱いでも同じようにする、という発想です。もちろん、「現地」を特定できる情報が対になることが前提なんですが、そこらへんは、完全に言葉足らず。
業務アプリケーションでの日付の扱いは、いろいろな考えることが多いので、java.timeパッケージの、LocalDate/LocalTime , OffsetDateTime, ZonedDateTime, Instant の使い分けの話も含めて、このブログでいちど、私の考えていることをまとめてみたいと思います。
書評『現場で役立つシステム設計の原則』 - まっつんの日記
ブックマーク:90まっつんさんのこの書評は、とにかく早いんでびっくりしました。発売が7月5日なのに、なんと、6月30日に公開していただきました。発売に先行していくつかの書店で試験販売したものをご購入いただいたようです。
まっつんさんとは、ネット上でも何度か意見交換とかさせていただいていて、私の設計の考え方に共感いただけている部分が多いのかなと思いました。
まっつんさんのお仕事がら「教育コンテンツ」としての評価をいただけたことは、とてもうれしかったです。
「Java入門レベルはクリアしているけど、現場での設計には、まだまだ悩みが多い」という人たちに参考になれば、と思って書いた本なので。
「現場で役立つシステム設計の原則」を読んでみたよ - runaround’s diary
ブックマーク:78run-aroundさんから、付箋がびっしりとついたこの本の写真がtwitterで流れたのを見た時は、ほんとうにうれしかったです。自分の書いた本を、興味をもって読んでいただけていることが実感できた瞬間でした。
書いていただいた内容も、ご自身の経験と照らし合わせながらの具体的な感想で、とても興味深く読ませていただきました。
ほんとうにうれしいフィードバックでした。
>>2017/8/16 追記
【書評】現場で役立つシステム設計の原則 - システム開発で思うところ
ブックマーク:63vermeerさんは、細かい点までほんとうに丁寧に読んでいらっしゃるなあ、というのが率直な印象です。そして、vermeerさん自身のご意見の記述が具体的で、とても参考になります。私の過去のスライドとの差異までご指摘いただいたのは、正直驚きました。スライドのほうも丁寧に見ていただけてるようで、うれしい限りです。
ご指摘された箇所の図は、処理の流れのイメージとしてこっちのほうがわかりやすいと思って、ドメインモデルへの矢印を、アプリケーション層だけに絞ってみました。
契約による設計は、本の説明が中途半端というか、わかりにくかったですね。改良の余地が大いにありです。
if文でブロック(ブレース括弧 {})を使っていない点は、レビュー段階から、いろいろな人から指摘されています。
これは、説明不足なんですが、if文でブロックは使わないほうが良いと思って、そうしています。
どういうことかというと、if文のブロックは必ずメソッドに抽出して、次のような一行記述にすることを徹底するという考え方です。
if( condition ) statement ; // 改行せずに一行で書く
condition は、isValid() などのメソッド。statement も return errorResult() などのメソッド。
else句は原則使わないようにしているので、ほとんどのif文は、このような一行形式で記述でき、実際にやってみて、わかりやすく、変更が安全になることに手ごたえを感じている書き方です。
「集中できる時間は『息を止められている時間』」というのは、その通りですね。個人的には、ボイラープレートコードは読みたくないので、メソッドに抽出するというひと手間をかけてでも隠したい派です。
>>ここまで追記
そのほかにも、いろいろな方に書評を書いていただいています。
みなさん、ほんとうにありがとうございます。
「現場で役立つシステム設計の原則」を読んでいる - 三流プログラマが脱三流するために書くブログ
『現場で役立つシステム設計の原則』という本に対して思うこと - Toy と帽子と ADP BE
『現場で役立つシステム設計の原則』を読んだ - SE(たぶん)の雑感記
「現場で役立つシステム設計の原則」を読んだ - TSUGULOG
「現場で役立つシステム設計の原則」を読み終わりました - シュンツのつまづき日記
『現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法』(増田亨)の感想(2レビュー) - ブクログ
技術評論社
コメント:Amazonでも、たくさんの人にレビューを書いていただけました。 |