投稿元:
レビューを見る
印象に残ったチャプター
・美はシンプルさに宿る
言葉の通り、常にこのようにありたい。
・コードレイアウトの重要性
「目立たない部分を作る。レイアウトに語らせる。」はノイズを除去し、可読性を向上させる。
・名前重要
言葉の通り重要だと納得。良いネーミング→設計8割完了。
投稿元:
レビューを見る
この本で一番印象に残った言葉がなんであったかといえば、最後のページでまつもとゆきひろ氏の書いた「名前重要」だと思う。
これは決して単に「ネーミングセンス」があればいいと言っているのではない。
プログラムを書く上で自分が何を作っていて、そのプログラムはどんな動作をして、どう組み込まれるのか、関連する項目は何かなどが明確になっていれば自ずと正しい名前はつけられるということだ。
そして変数名、関数名、プロジェクト名(もしかしたら会社名も?)など正しくネーミングできなかったものは大抵うまくいかないらしい。
それくらい「名前重要」なのだ。
理論的に理解できる部分もあるがきっとセンスに頼る部分もあるかもしれない。
でもこの世のうちの最高のプログラマーの1人が言うのだから、頭にいれておいて損のない言葉だと思う。
投稿元:
レビューを見る
【当書籍を読む前に】
当書籍を知るきっかけとなったのは
私が参画しているプロジェクトのITアーキテクトメンバーからの紹介によるものである。
その紹介者は、私より経験年数が2年若いのだが
プログラミングにおいては、私よりも知識が深く
プログラムについての理解も早い。
しかし、作成したプログラムの外部環境(業務、環境)には
まったく興味がなく、大変残念に思っていた。
(そういった意味では、彼はコーダーに近い、と言わざるを得ない)
そういった彼が、どのような理想を求めているのかを
彼自身が紹介した書籍から読み取ってみたいと思う。
【読み終わって】
海外で活躍しているプログラマのコラムが97個
日本人の有名なプログラマのコラムが10個
と、結構なボリュームのある書籍だった。
ただ、各コラムが比較的ショートで
移動時間や休憩の合間にサッと読めたので
読むことが苦になることはなかった。
内容としては、日本での「コーダー」や「プログラマ」とは
少し異なり、システムの外部環境を意識したコラムや
テストや保守に関する理想を語っているコラムが複数あるので
ぜひ、若手SE(要件定義者)にもお勧めできる。
(当然、私自身も含まれるが・・・)
ただ、比較的経験の浅いプログラマにはお勧めできない。
理由としては、各著者のコラムがお互いに真逆のことを語っていたり
優先すべき事項が、各著者で異なっているので
当書籍により混乱を招きかねないためだ。
感覚的にだが、ある程度プロジェクト開発の経験があり
デスマーチの中で、「こうあるべき」と自分の中で軸が成形されていくであろう
3年目以降のプログラマが、自分の軸を磨き上げる手段として
是非、お勧めしたい書籍である。
私も、この書籍は定期的に目を通そうと思う。
投稿元:
レビューを見る
ほー、なるほどね!というエッセイ集。
寄稿者紹介を見て(業界著名人に)、意外とC/C++使い(?)が多いのに感動。
投稿元:
レビューを見る
ソフトウェア開発をおこなう人であれば、誰もが読んでおくべき本。
読み終わってまた時間がたったら、書かれていることが実践できているかどうかを見直すのが良いと思う。
私も、来年また読み直そうと思う。
その時には、書かれていることが「当たり前」になっているようにしたい。
※おまけ※
今、TDDが広がり続けている背景もあるのだと思うけれども、テスト関連などについての話が比較的多いように思える。
投稿元:
レビューを見る
著名なプログラマの方々がプログラミングの極意を伝授する本。
日本版は10人の日本人の追加項目があるので、
ただしくは、「プログラマが知るべき107のこと」になります。
表情に興味深いものから、興味のそそらないことまで、
多種多様で、やはりプログラミングってのは一筋縄ではいかないと感じる。
ただ、書いてあることで既に実践できていることもあり、自信につながる。
**以下、ささったこと**
・モジュールをチェックインする時はチェックアウトする時より美しくする(ボーイスカウト方式)
・コードは出来るだけシンプルに
・変数のスコープは小さく
・関数のパラメータはMAX4つ
・関数の24行制限は有効
・セクションを入れ子にする時は関数化
・書くのに苦労したコードは読むのに苦労する⇒コメント大事
・将来必要になるかもしれないは、YAGNI(You Ain't Gona Need It.:それ
は多分必要ない)に反するので書くべきではない。
・コードはシンプルなものであるべきです。変数や関数、宣言といった構成要素はできる限り減らすべきです。残るべきは、アルゴリズムを完成させ、必要な演算を全て処理する為の、必要最小限の要素だけです。
・気持ちの持ち方、取り組む態度を変えるには、いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く
・イエスからはじめる
・人間は、他の人間がいるお陰で、人間になっている
・コードは、他のコードがあるお陰でコードになっている
・コードネームをつける。
・名前は重要であり、関数の名前がピンと来れば最小化できている証拠です。
投稿元:
レビューを見る
「初めて一人でマジ開発」挑戦中の今この時期に見つけて行き帰りの電車で読んだので、ダイレクトに糧になった。職人的な開発屋を極めたいのか、コーディネーター的なSEを目指したいのか、(←今の理解)考えるきっかけにもなっている。
・セクションが見開き程度の長さで読みやすい
・あっと思い出してまたページを開いたりしそう
投稿元:
レビューを見る
書名から「き97のこ」の部分をとりだして、「97きのこ本」という愛称がついています。
そのルールに基づくなら姉妹本の『ソフトウェアアーキテクトが知るべき97のこと』も「97きのこ本」になるのですが、こちらは特にそのようには呼ばれてはいないようです。
原著の73人のプログラマによる97本のエッセイに加えて、日本人プログラマ8人(小飼弾、関将俊、舘野祐一、まつもとゆきひろ、宮川達彦、森田創、吉岡弘隆、和田卓人)による書き下ろしの10本のエッセイが追加され合計107本のエッセイ集になっています。
エッセイ1本は2ページのものが中心なので電車の中などでも気軽に読むことができます。
テストを話題にしたものも、タイトルだけでも、8本あります(本書中にある分類では14本になっていました)。
テスト担当者はプログラマの友人
偶然の仕様ではなく本物の仕様のためのテストを書く
テストは夜間と週末に
テストのないソフトウェア開発はあり得ない
プログラマとテスターが協力してできること
コードを見る人のためにテストを書く
テストは正確に、具体的に
不具合にテストを書いて立ち向かう
全体的にそれぞれのプログラマ達の経験からのアドバイスが多く好感が持てます。
★★★
本書を読んで初めて知った言葉に「フロー」いうものがあります。
次の文章は、『95 ペアプログラミングと「フロー」』の出だしです。
何かに完全に没頭している時──夢中で何かをしていて、時間が経つのも忘れてしまっているとき──それはきっと人間にとって幸せな状態です。その状態は「フロー状態」と呼ばれます。
「フロー状態」にすっと入っていけること、また、「フロー状態」を維持できることができたら品質や生産性は格段に上がると思います。
自分自身の事を振り返っても、会社でテストツールのプログラムを書いていたときは、誰もいないときか、みんなが帰った夜中に書いていました。
本、論文、原稿、プレゼン資料を作るときにも、10時間のうち、8時間は題材を考えていたり、資料を集めていたり、テキストエディタに目次と構成をタブで作っていたりして、実際に書くのは2時間というパターンが多いです。その集中して何かをしている時が「フロー状態」なんだろうなと思います。
ソフトウェアの見積りが難しいのも「フロー状態」の自分で工数を見積もってしまうからかなぁと思いました。
ところで、私の場合、「フロー状態」に入るために、
・ 甘いコーヒーを飲み、チョコレートを食べる
・ 机の上を片付ける
・ メールを読み、返信し尽くす
という儀式が必要です。こういった儀式を集めたら面白かもしれませんね。
投稿元:
レビューを見る
一流のプログラマーたちが、書名のようなテーマで自説を開陳したエッセイ集。 肩肘張らず、楽しみに読めばよいと思う。 役にたつもの、なるほどというもの、時々自分の抱えている問題に関係する、はっとすることも書いてある。 気が向いた時にページをめくると、何かその時々の発見があるかも知れない。「日本人プログラマによる知っておくべき10このこと」が翻訳時に加えられている。
私が初読時に付箋を貼ったのは以下の記事。 06「リファクタリングの際に注意すべきこと」、34「API設計の黄金律」、37「バグレポートの使い方」、67「コードを読む」、68「人間を知る」、69「車輪の再発明の効用」、70「シングルトンパターンの誘惑に負けない」、73「単一責任原則」、84「正しいアルゴリズムとデータ構造を選ぶ」、89「関数のサイズを小さくする」、90「コードを見る人のためにテストを書く」。 共同で書き始めたC++コードの設計を考えていた頃だった。
投稿元:
レビューを見る
「◯◯が知るべき97のこと」の第二弾。一つ一つが短くて読みやすいんだけれども、奥深いストーリーになっている。
全部が全部納得出来るかというとそうではないんだけれども、今は納得できなくても将来的に納得出来るようになるんだろうなと思う。それだけの含蓄を含んでいるような気がする。
さて、現実に目を向けてみよう。向けてみると、この本に書かれているとは違うことが現実に起きている。それが、自分の行動に起因するのか周りが奏させているのか考えるのは野暮で、一つ一つでいいから変えていく。
難しいよなぁ。そう一朝一夕で出来ることじゃないよなぁ。でもなぁ、徐々にでいいので自分のできる範囲から変えていこう。
投稿元:
レビューを見る
プログラマだけでなく、日本の企業で言うところのSEにも読んでもらいたい1冊。
1話で2,3頁なので、通勤時間などのちょっとした時間に読める。
投稿元:
レビューを見る
プレゼンに思わず引用したくなるような琴線に触れるすてきな言葉が詰まった本。また間を置いて自分のお気に入りの節を読み返したい。
投稿元:
レビューを見る
・技術的負債を残すな。早めに返済せよ。
・ユーザーの身になってシステム構築をする。
・コーディング規約は自動化する。
・シンプルに。美しく。
・リファクタリングの重要性。
・機能の共有は慎重に。コンテキストを意識する。
・他人よりまず自分を疑う。
・ドメインの言葉を使ったコード(canView、isAdminなど)
・レビューは楽しく。辛辣な批判は絶対に避ける。
・コードに書けないことをコメントする。whatじゃなくwhy。
・常に自分よりレベルの高い人と仕事をする。
・技術的例外とビジネス例外を分ける。
・変更を恐れない。
・見られて恥ずかしいデータは使わない。
・DRY原則
・ハードワークは報われない。
・余分なコードは決して書かない。
・警告はエラーと同等にみなす。
・複数のプログラミング言語を学ぶ。
・自分の書いたコードに責任を持つ。
・他人のコードを読む。
・自動化できることは自動化する。
・ペアプログラミングのすすめ。
・他社へのおもいやりを考慮したコード。
・コードは生涯サポートするつもりで書く。
・プロジェクトにコードネームをつけよう。
・理想の人を演じきれ!仕事だろ!
・フロー状態を作る。
・コードを読むスキル。テストをするスキル。デバッグをするスキル。
・快適な環境を追求する。
・名前の重要性を意識する。
投稿元:
レビューを見る
今更読了.時間が少しあったので.
エッセイ形式でソフトウェア開発時に注意しておくべきことなどを羅列したもの.頭から読み始めるのではなく,好きなところから読むことができるのでサクサクと読み進めることができるかも.
内容がソフトウェア開発の話が中心なだけに,プログラミングを習い始めた大学生にはあまり向かない内容かもしれない.ベンチャー企業などでアルバイトをしてコードを書くようになってから読んだほうがいいかも.チーム開発の手法が多い印象だった.
後,よく引用が出ているので,併せて読むといいかもしれません.特によく出てきた「達人プログラマー」は良書ですので併せて御一読ください.
投稿元:
レビューを見る
ひとりひとりの文章が、長すぎず短すぎずで
とても読みやすかった。
色々な意見、色々な考えに触れることができて、
読んでいて楽しいうえに、ためになる。