1,800円以上の注文で送料無料

達人プログラマー の商品レビュー

4.1

52件のお客様レビュー

  1. 5つ

    21

  2. 4つ

    16

  3. 3つ

    9

  4. 2つ

    1

  5. 1つ

    1

レビューを投稿

2021/10/03

プログラマーとしての心構えから、設計手法やプロジェクト管理まで幅広く書かれている。 ざっと読んだ感じ、信用してよさそうな文章で幅広く書かれていて好印象。新装版が出てるみたいなので、そっちを真面目に読んでみようと思う。 以下、心動かされたところ。 # 達人プログラマーになるた...

プログラマーとしての心構えから、設計手法やプロジェクト管理まで幅広く書かれている。 ざっと読んだ感じ、信用してよさそうな文章で幅広く書かれていて好印象。新装版が出てるみたいなので、そっちを真面目に読んでみようと思う。 以下、心動かされたところ。 # 達人プログラマーになるためには? - 新しい物好き - 研究好き - 批判的 - 現実的 - なんでも屋 # ゴール - 毎年少なくともの一つの言語を学習する - 毎四半期ごとに技術書籍を読む - 技術書籍以外の書籍を読む - 講習を受講する - ローカル・ユーザー・グループに参加する - 異なった環境に慣れ親しんで見る - 最先端にとどまり続ける - インターネットを使う # Cockburnのユースケース・テンプレート ## 特性情報 - 概要 - スコープ - レベル - 事前条件 - 正常終了時の条件 - 異常終了時の条件 - 一時アクター - トリガー ## 主要な正常時のシナリオ ## 補足 ## バリエーション ## 関連情報 - 優先順位 - パフォーマンス目標 - 頻度 - 上位ユースケース - 下位ユースケース - 一次アクターへの伝達経路 - 二次アクター - 二次アクターへの伝達経路 ## スケジュール ## 未解決の問題 # ヒント - あなたの仕事について考えること! - 割れた窓を放置しておかないこと - 変化の触媒たれ - 常にあなたの知識ポートフォリオに投資すること - 最終決定などというものは存在しない - プロトタイプの真の目的は学びにある - 一つのエディターを熟知すること - コードを生成するコードを作成すること - 早めにクラッシュさせること - 始めたことは終わらせること - サービスを使って設計を行うこと - 常に並列性を意識した設計を行うこと - 理解できないウィザードのコードを使わないこと - 要求は拾いあつめるものではなく、掘り起こすものである - テストが終わるまでコーディングは終わらない # 気になったことば - IBMにあったおなじみの企業モットーTHINK!

Posted byブクログ

2019/01/20

@torazuka さん、 @kompiro さんと MorningBee 全5回で読んだ。 読書会的なものに向いていると思う。 新人さんに送ったのはちょっと早かったかも、、、という気もしたりしなかったり。

Posted byブクログ

2019/01/17

意外に抽象的な内容だった。もっと具体的事例に沿ったものだと思っていた。 だが、本文中でも触れられているように、抽象は具象よりも寿命が長く、具象方法論は、その本来の目的という重要な要素が抜け落ちる危険性がある。 そういう意味では、良いバランスだと思う。 要求を契約としてコード定義...

意外に抽象的な内容だった。もっと具体的事例に沿ったものだと思っていた。 だが、本文中でも触れられているように、抽象は具象よりも寿命が長く、具象方法論は、その本来の目的という重要な要素が抜け落ちる危険性がある。 そういう意味では、良いバランスだと思う。 要求を契約としてコード定義し、実装を保証する、というのは、興味深かった。 だが、一読した限りでは、内容はコメントレベルと大差ないように思えた。 (コードと結びついていない?) 契約定義言語を調べて、具体的な内容を調べてみる。

Posted byブクログ

2018/11/12

この本一読せずしてプログラマーと名乗る無かれという感じの本。CODE COMPLETEもそうだが、こうした本質を踏まえずにプログラムしているということは恐ろしいことと感じなければならないだろう。 [private]・知識ポートフォリオに定期的に投資する。 ・DRY原則 ・直行性...

この本一読せずしてプログラマーと名乗る無かれという感じの本。CODE COMPLETEもそうだが、こうした本質を踏まえずにプログラムしているということは恐ろしいことと感じなければならないだろう。 [private]・知識ポートフォリオに定期的に投資する。 ・DRY原則 ・直行性を確保する。 ・曳光弾アプローチ ・仮定をドキュメント化する。 ・ソフトウェアは建築というよりガーデニング ・プロジェクトの用語集を作る ・自分が作成しているソフトウェアを使うことができますか? ・ドキュメントをコードと同等に扱う。 [/private]

Posted byブクログ

2018/10/23

アンドリューハントさんへ、この本書いてくれて、ありがとうございました。といいたくなるぐらいすばらしい本。この本は、私をソフトウエア開発のプロに導いてくれた。 DRY(Do not repeat yourself)プラクティスは特に参考になる。ソフト開発者必読の書といえる。

Posted byブクログ

2018/10/07

プログラミングで仕事をしていく人が読むべき本。 大学院とかで扱ってもいいんじゃないかと思う。 ただ、研究室や社会で揉まれていることが前提になります。 ある程度実務経験がないとピンとこないと思う。 基本的に性悪説で話が進みますが、計算機は命令した通りにしか動かなくて、バグを混入さ...

プログラミングで仕事をしていく人が読むべき本。 大学院とかで扱ってもいいんじゃないかと思う。 ただ、研究室や社会で揉まれていることが前提になります。 ある程度実務経験がないとピンとこないと思う。 基本的に性悪説で話が進みますが、計算機は命令した通りにしか動かなくて、バグを混入させるのは人間なので、間違ってはいません。(2:6:2の法則や働き蟻の法則も交えて欲しかった) キーは、自動化プロセスを作り、成熟させていくこと。 人の手は極力排除しないとだめです。 3章を読んでから、すぐにwindowsを捨てて数年ぶりにscreen+emacsに戻りますた。

Posted byブクログ

2018/03/16

プログラミングをする上での心構えがかかれた良書です。内容の古くなった部分もありますが、普遍的内容なので現在でも通用すると思います。

Posted byブクログ

2017/04/30

何というか書き方が独特で、役に立つ部分はポイントと書かれている一言に凝縮されていて、それ以外は無用っぽい。 この本に書かれている事は、分かってほしい人にはたぶん伝わらない。分かっている人にはたぶん伝わる。想像力が欠損しているタイプの人間には読んでも何も伝わらない。

Posted byブクログ

2017/03/09

今必要そうなところをざっと読み。SEとして必要な技術や心構えを説いた読み物。少々詩的な書き方だけどタメになった。

Posted byブクログ

2015/07/15

プログラマーとしての考え方、仕事の進め方、ノウハウ、ツールを通じて、プログラマーの哲学にふれる本。 byジョイマン

Posted byブクログ