本ページはアフィリエイトプログラムによる収益を得ています
Amazon.co.jp ・本 (384ページ) / ISBN・EAN: 9784274226298
作品紹介・あらすじ
より良いプログラマになるための実践的アプローチ
本書は、Andrew Hunt and David Thomas、 The Pragmatic Programmer 20th Anniversary Edition (Addison Wesley、 2019)の日本語版です。
本書は、より効率的、そしてより生産的なプログラマーになりたいと願うソフトウェア開発者に向けて、アジャイルソフトウェア開発手法の先駆者として知られる二人により執筆されました。経験を積み、生産性を高め、ソフトウェア開発の全体をより良く理解するための、実践的なアプローチが解説されています。
先見性と普遍性に富んだ本書は、入門者には手引きとなり、ベテランでも読み直すたびに得るものがある、座右の一冊です。
感想・レビュー・書評
-
詳細をみるコメント0件をすべて表示
-
第一版は図書館で借りて★★★★★だけど未購入だった。第二版は購入。内容が現代的になっている。相変わらず名著であり、プログラミングを志す若者にはぜひ読んで欲しい。オッサンであっても自己流でプログラミングを身につけた人はスキルを棚卸しする役に立つはずだ。
ただ、本を読んで欲しい人こそなぜか自分で発明した独自技術にコダワリ、大体できている人が本談義をするというのが実情。最初は概念的な記述が始まるが、設計・実用面での普遍的なアドバイスも豊富だ。
原理・原則に始まり、設計、コーディング、テスト、開発プロセスなどの幅広い話題を取り扱う。
コードはElixirやRubyが多いが、それらを知らなくても、丁寧に読解すれば、筆者らが伝えたいことは理解できる。 -
伝説の名著が改版されたのでまた買って読んでいる。私は仮にもプログラマとして10年くらいやっているので、想像も付かないような内容というのはほとんど出てこない。口の悪い人なら当たり前のことばかりが書いてあると言うかもしれない。出てくる項目はほとんどすべて、「わかる、そういうことあるよね、、、」となるようなことばかりだ。
しかし、ここに書いてあることをすべて暗記して常に述べられるようにするというのは簡単なことではない。「言われれば思い出す」ような教訓がいつでも手に取れる状態で良くまとまっていれば、それは拠り所として常に私たちを助けてくれることだろう。 -
初版は読んでいますが、大分昔なのと色々変わっていそうなので改めて読了。
人によってはストイック感はあると思いますが、大事にしたい習慣や考え方が詰まっていると感じます。
ITエンジニア的には繰り返し読みたい一冊です。 -
重厚な内容だった。
プログラム書いたりする仕事をしているが、達人にはまだまだ遠いなぁと。
後半のアジャイルな開発は「アジャイルサムライ」にも書いていたことだったのでふんふんと思いながら読みました。
バージョン管理、リファクタリング、テスト駆動開発は徐々にできつつあるのかなぁ、、、
達人プログラマーになるためには?
1.アーリーアダプター/新しい物好き
2.研究好き
3.批判的
4.現実的
5.何でも屋
あなたはどれが当てはまりますか?
→私は2,5辺りかな
自分のpcにコーヒーをぶちまけたとき、新しいpcの設定を自分の使っていたpcの設定と同じ状態にするには、どれだけ時間がかかるか
→バージョン管理をする意味がここにもある。
-
プログラマ向けの自己啓発本。昔から、本のタイトルは聞いたことがあって気になってはいたのだけど、ようやく読んだ。
もっと早くこの本を手にしておけば、もうちょっとマシな開発ができてきたのだろうなと思う。
DRY原則がこの本で誕生したというのは聞いたことあったけど、ラバーダック・デバッグもこの本からだったのか。
割れ窓理論とかまさにそうだよね。自分もつい、割れた窓のようなコードを書いてしまったことがあり、その後に若いプログラマに保守を任せることがあったのけどいい書き方になってなかったりした。
それをコードレビューしても、元がよくない書き方なので指摘するのに躊躇したり。
ETC原則という言葉は初めて知った。「Easier To Change」の略で、変更をしやすくするという意味らしい。この考え方は、確かに大事だよなと思う。
初めて知ったと書いたけど、この言葉は第2版で作られた原則だろうと思う。検索しても、第2版が発売してからの記事しか見つからなかった。
DRY原則は、自分もコードの重複をしないようにするという意味だと数年前まで勘違いしてしまっていた。そうじゃないんだよね。
コードの重複をしないようにと考えてコードを書いてしまったせいで、かなり煩雑なコードになってしまったので、本当に悔やまれる。
知識はプレインテキストに保存するというのは、AIでコーディングしてもらうこともある今には特に重要だろうなと思う。ついつい、Excelで書いてしまったりするけど、プレイテキストのほうが検索もしやすいしね。
今後はもっとMarkdownで文章を書くようにしていきたい。Mermaidとかも、書けるようになりたい。
JavaScriptにパイプライン演算子(|>)を追加するという議論が進んでいるという話は初めて知った。
ただ、この本が発売されて5年たつけど、いまだ議論中らしい。結局、追加されないような気もする。
継承の代わりに、「インターフェースとプロトコル」「委譲」「mixinとtrait」を使うほうがいいとのこと。ついつい継承は便利だから使ってしまいがちだけど、確かに結合度があがってしまうしね。気を付けたい。
テストコードについて、著者の一人は今は書いてないというコラムが面白かった。テストコードを書き続けた結果、テストコードを書かなくても、テストコードが書きやすいコードを書けるようになったからということらしい。
そろばんに慣れたら、なくても計算できるようになったみたいなイメージに近いのかも(少し違うか?)。
後、「ココナツでは解決できない」という話も面白かった。飛行機を見ても、ココナツで同じものは作れないという話なのだけど、確かにそれはあるよなと。
この本でいいたいのは、他の企業でやっているやり方を見様見真似で行ってもうまくいかないということだと思うのだけど、既存のソフトウェアと同じようなソフトウェアを作ろうとする時にもあてはまるよなと思った。
仕様が分からない、説明者があるわけでもない、別会社が作ったプログラムを真似して、プログラムを作ることになったことがあるのだけど、どういう概念で作られているのか全く分からず、かなり苦労した思い出。まあ、今となっては要件定義自体をもっとちゃんとすべきだったとは思うのだけど。 -
エンジニア2年目の私にとって、腹落ちするまで理解できる内容が少なかったので1年ごとに読み返してみようと思う。振り返りの意味も込めて。
第1章〜2章までの内容は非常に参考になった。
第1章冒頭の「目の前の問題を考えるだけでなく、常にその問題をより大きなコンテキストで捉え、常にものごとの大局を見据えようとする」は今の自分にとって刺さるフレーズだった。
仕事の目的、背景、制約条件を理解することで、システムのあるべきを容易に判断できるようになる。
度々目の前の課題に一生懸命になったとき、悩んだとき、これを思い出すことが重要である。 -
1章・2章の内容だけでも読んでみると良いかと
ネットに転がる要約記事を見てビビッと来たら手にとってみて -
達人プログラマー(第2版)
David Thomas氏, Andrew Hunt氏による、プログラマーが熟達(達人)に至るための実践的アプローチをまとめた著書です。
初版から20年経ち、内容を現在に合わせブラッシュアップし、第2版として出版されました。
非常に評判の高い本です。
【本書で学べること・考えること】
- より効率的、生産的なプログラマーになるための実践的なアプローチ
- 哲学(心構え・考え方・習慣)
- ソフトウェア開発のセオリー
- ツール
- デバッグ
- プログラミングを進め方
- 分離・継承・設定の注意点
- 並行性
- コーディング時の注意点(アルゴリズム・リファクタリング・テスト)
- プロジェクト開始前の注意点(要求・協働・アジャイル)
- プロジェクトの進め方
読んでみての感想です。
ソフトウェア開発に携わる人は、是非、一読して欲しい本です。
ソフトウェア開発全般についてベテランの知見・アドバイスを得られます。
読む人のレベルに合わせ、読むたびに気付きがありそうです。
唯一残念なのは、各項目の見出しが独特の凝った表現のため、直感的にわかりにくい点のみです。
名前は大事ですね。 -
ITエンジニア本大賞より (https://www.shoeisha.co.jp/campaign/award)
-
-
良質なエンジニアを定義し、見極める事ができる本。全てを完璧に実践する事は不可能だが、年に1回は読み返し達人プログラマーを志していきたい。チームで議論する時等に今のアクションをユーモアと共に言語化できる気がする。
「調べたこと」
- 無秩序 (ムチツジョ):物事が整理されておらず、乱雑で、統制が取れていない様子
「メモ」
- 「割れた窓」:悪い設計、誤った意思決定、質の悪いコード。ネガティブな考えは伝染性がある様。
- 「早起きした鳥は虫にありつける」:早く行動を起こす人ほど、仕事や勉強などで有利になる
- 迷惑(annoy):アンニュイ、つまり退屈
- DRY原則:知識や意図の二重化についての原則。異なった場所に同じことを表現するという問題を避けるための原則。 -
開発者たるものさまざまなTipsが散りばめられている。色々な設計技術書などの重複があり、振り返りもできた気がする。しかし、和訳故の分かりずらい例が多々あり、そこは日本人向けに変えて欲しいところ。
-
名著なので、「これに書いてあるのだからやりましょう」と提案を通す後ろ盾になる。
-
素晴らしい本。システム開発を生業とする人は絶対に読むべき名著。新人ではなく、ベテランやある程度の経験者に読んでほしい。
ソフトウェア開発は建築というよりもガーデニングに近い。
という言葉は刺さった。
DRY原則
デメテルの法則
カーゴカルトアジャイル
も大切。
-
プログラマーは、自らの仕事環境を最適化しようとする性質を持つ。
それは、プログラマーという職業が、限られた手段の中で世界の最適化を追求するものだからである。本書では、こうした最適化を探求してしまう人間が何を考えているのかが述べられている。
多くの人は、自らのスループットを向上させたいと考えているはずだ。本書はプログラマー向けに書かれているが、すべてのプロフェッショナルを志す人にとって有益な一冊である。
-
読むのは前半だけでいいと思います。
5章からは5年、10年以上の経験者が好みで読むレベルで翻訳らしく不思議な言葉が沢山出てきます。
7章のリファクタリングとかは理解できました。 -
特に1章の哲学が良かった。
自分が使う技術への関心は最近強くなってたので肯定された感覚を持った。なんだか嬉しい。
あとは対人コミュニケーションに関しても言及していたのが良かった。達人はコードが書けるだけでなくコミュニケーションもピカイチ。周りにいる達人と思ってる人も同様なので納得。
2章も良かった。達人が書くコードは変更が容易で、それを実現する要素が載っている。ただ方法論は少ないので、それは別書籍で補いたい。
3章以降は少々読みづらかったが、一気読みしたせいか集中力書いたのもある。逐一眺められれば。 -
読了日:2024/01/05
新卒一年目のエンジニアには難しい。
文章を読むことはできても、理解できたとは到底思えない。
一方で、先輩エンジニアがアドバイスしてくれることが散りばめられていた。
実務経験を積んでもう一度読みたい。 -
翻訳本特有の読みづらさとひたすら文字の説明による分かりづらさで自分には合わなかった。
書いてある内容も他の本やネット情報からも仕入れられるものなのでこの本でコーディングの原則などを学ぶより他のコードサンプルや図や絵で説明しているものを見た方が理解が早いと思う。 -
まずはユーザーのために、設計はどこまで犠牲に?
村上雅章の作品
本棚登録 :
感想 :
