- 作者: 和田卓人,Kevlin Henney,夏目大
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/12/18
- メディア: 単行本（ソフトカバー）
- 購入: 58人 クリック: 2,107回
- この商品を含むブログ (350件) を見る
目次
- 分別のある行動
- 関数型プログラミングを学ぶことの重要性
- ユーザが何をするかを観察する（あなたはユーザではない）
- コーディング規約を自動化する
- 美はシンプルさに宿る
- リファクタリングの際に注意すべきこと
- 共有は慎重に
- ボーイスカウト・ルール
- 他人よりまず自分を疑う
- ツールの選択は慎重に
- ドメインの言葉を使ったコード
- コードは設計である
- コードレイアウトの重要性
- コードレビュー
- コードの論理的検証
- コメントについてのコメント
- コードに書けないことのみをコメントにする
- 学び続ける姿勢
- 誰にとっての「利便性」か
- すばやくデプロイ、こまめにデプロイ
- 技術的例外とビジネス例外を明確に区別する
- 1万時間の訓練
- ドメイン特化言語
- 変更を恐れない
- 見られて恥ずかしいデータは使わないこと
- 言語だけでなく文化も学ぶ
- 死ぬはずのプログラムを無理に生かしておいてはいけない
- 「魔法」に頼りすぎてはいけない
- DRY原則
- そのコードに触れてはならない！
- 状態だけでなく「ふるまい」もカプセル化する
- 浮動小数点数は実数ではない
- オープンソースプロジェクトで夢を実現する
- API設計の黄金律
- 超人の神話
- ハードワークは報われない
- バグレポートの使い方
- 余分なコードは決して書かない
- 最初が肝心
- プロセス間通信とアプリケーションの応答時間の関係
- 無駄な警告を排除する
- コマンドラインツールを使う
- プログラミング言語は複数習得すべき
- IDEを知る
- 限界を知る
- すべきことは常に明確に
- 大量のデータはデータベースで
- いろいろな言葉を学ぶ
- 見積りとは何か
- Hello, Worldから始めよう
- プロジェクト自身にしゃべらせる
- 「その場しのぎ」が長生きしてしまう
- 正しい使い方を簡単に、誤った使い方を困難に
- 見えないものを見えるように
- 並行処理に有効なメッセージパッシング
- 未来へのメッセージ
- ポリモーフィズムの利用機会を見逃さない
- テスト担当者はプログラマの友人
- バイナリは常に1つ
- 真実を語るはコードのみ
- ビルドをおろそかにしない
- プリミティブ型よりドメイン固有の型を
- ユーザの操作ミスを防止する
- プロのプログラマとは？
- バージョン管理システムを有効に使う
- いったんコンピュータから離れてみる
- コードを読む
- 「人間」を知る
- 車輪の再発明の効用
- シングルトンパターンの誘惑に負けない
- パフォーマンスへの道は地雷コードで敷き詰められている
- シンプルさは捨てることによって得られる
- 単一責任原則
- 「イエス」から始める
- 面倒でも自動化できることは自動化する
- コード分析ツールを利用する
- 偶然の仕様ではなく本物の仕様のためのテストを書く
- テストは夜間と週末に
- テストのないソフトウェア開発はあり得ない
- 1人より2人
- エラーがエラーを相殺してしまう
- 他者への思いやりを意識したコーディング
- UNIXツールを友にする
- 正しいアルゴリズムとデータ構造を選ぶ
- 冗長なログは眠りを妨げる
- WETなシステムはボトルネックが見つかりにくい
- プログラマとテスターが協力してできること
- コードは生涯サポートするつもりで書く
- 関数の「サイズ」を小さくする
- コードを見る人のためにテストを書く
- 良いプログラマになるには
- 顧客の言葉はそのまま受け取らない
- エラーを無視するな
- リンカは魔法のプログラムではない
- ペアプログラミングと「フロー」
- テストは正確に、具体的に
- ステートに注目する
- 命を吹き込む魔法
- ロールプレイングゲーム
- ルーチンワークをフローのきっかけに
- プログラマが持つべき3つのスキル
- 快適な環境を追求する
- 見知らぬ人ともうまくやるには
- 不具合にテストを書いて立ち向かう
- 育ちのよいコード
- Noといえることの大事さ
- 名前重要
感想
まとめと感想。個人の主観が入ってるので、注意。
分別のある行動
技術的負債は、先送りしていると負債は大きくなる。
返済計画を立てないと、返済しきれなくなって破産する。
付け加えるなら、資産も持つべきかな？
作ったコードは、たぶん負債だらけってわけじゃないと思うんだよね。
よく作られているコードは、資産と捉えて、増やす・維持する努力もやるべきだと思う。
関数型プログラミングを学ぶことの重要性
関数型プログラミングとオブジェクト指向は、相反する存在ではない。
注力しているものが違うだけ。
実際にやっていると分かるが、どうしても状態を持たなければいけないところが発生する。
使い分けができるようになっておく必要がある。
前までは、オブジェクト指向素晴らしいと言ってきて、今度は、関数型プログラミングが素晴らしいって世の流れは、かなり違和感を覚える。
結局は、使いどころを見抜く力が必要なのだよ。
ユーザが何をするかを観察する（あなたはユーザではない）
考え方や味方は、ユーザと開発者では違う。
同じだと思ってはいけない。
解決するには、観察するしかない。
コーディング規約を自動化する
規約が存在することで、コードの私物化を防止できる。
なるべく強制的・自動的に守らせる。
規約を作っても、忠実に守ってくれるとは限らない。
規約は、プロジェクトと一心同体。
プロジェクトで求められるものが変われば、規約も変わる。
見直すタイミングを考える必要がある。
だいたい規約作って終了の現場は多い。
維持するために覚えるのは、ものすごく辛い。
自社サービス作るのに１００％自社社員ならいいが、協力会社が入っているなら、規約のチェックは自動化しないとやってらんない。
美はシンプルさに宿る
シンプルなコードは、責務を最小化し、関連をすくなくし、テストしやすく、長期保守ができるようになる。
リファクタリングの際に注意すべきこと
リファクタリングは、必要なときに必ずする。
むやみやたらにやっても、確認で破綻する。
ご利用は計画的に！
リファクタする際の注意点
- 既存コードの良い点・悪い点を見定めてから実姉
- ゼロから作り直したい衝動を抑える
- 大幅な変更より、小さな変更をたくさんする
- デグレ確認必須
- エゴを入れない
- 新技術を使いたい衝動を抑える
- 人間はミスすることを忘れない
共有は慎重に
共有＝再利用
再利用させたい場合、目的や役割を考えてライブラリ化する。
共有したら情報漏えいのリスクも上がるしな！
ボーイスカウト・ルール
来たときよりも美しくする。
少しづつ改善する努力が、ソフトウェア開発には必要。
ただし、不要な修正は禁止しなければならない。
他人よりまず自分を疑う
コンパイラ・ＯＳは、いろんな人がチェックしているので、バグは少ない。
他者に原因がある前提で動くより、自分が作ったものにバグがある前提で探した方が、効率的。
これは、あるあるネタ。
だいたい他人を疑う前に、自分に否がないように論理武装してから挑まないとダメ！
自分に否がないと分かったら、他者を徹底的に痛めつけられない！
俺って結構クズ人間？
ツールの選択は慎重に
ツールに依存する＝ベンダロックイン状態になる。
ツールは必要最低限にしておき、分離可能なように設計する。
たまに、ツールのために設計している現場があるからな。。。
そう言った現場は、だいたい汎用性がなくて、顧客要求に対応できず、協力会社の教育にも時間がかかり、炎上する。
ドメインの言葉を使ったコード
データ構造は、時間の経過とともに複雑化していく。
ビジネスに合わせてコードを書かないと、変化したコードの内容は、すぐに分からなくなる。
ドメインとともに、コードも成長させる。
たまにあるのが、データ構造が永久に変更無いと思っているやつ。
そういうやつに限って、自動生成がどうこう言い出して、ドメインが成長してもコードが成長しないような環境を作り出す。
なんか、愚痴ばっかだな、俺。
コードは設計である
建築コストのゼロ化→早く設計したもの勝ちになる。
早く設計したはいいが、その妥当性は、素人に判断できない。
最終的な品質は、低下する。
ソフトウェア開発にも同じことが起きる。
優れた設計には、人間が必要。
その妥当性の確認作業は、人間にしかできない。
この考えはＡＩにも当てはまる気がする。
ＡＩでなんでもできるようになったって、それが妥当かどうかは、素人には分からない。
やっぱり、専門家が必要なんだと思う。
これからは、企業が優秀なエンジニアを持ってないと、ＡＩ時代が来たときに、出遅れる気がしないでもない。
作戦立案はＡＩにまかせて、その妥当性を吟味して意思決定するのが人間になりそう。
やっぱり、仕事へらないじゃん！
ＡＩだからこそ、最終的な意思決定が重要になりそうだ。
コードレイアウトの重要性
コーディング＜リーディング
リーディングを効率化しないと、時間がかかる。
既存コードを読んで、発想を真似るのはよくあるからね。（コピペはダメ！絶対！）
リーディングを効率化するためにも、見ただけで何をしているか分かる状態にしておく。
コードレビュー
コードレビューは、質を上げ、欠陥を減らす。
チーム知識の共有と規約の確率も含まれている。
やる際は、建設的であるべき。
辛辣な批判は避ける。
そうしないと、レビューがボトルネックになり、プロセスが瓦解することがある。
続けるには、レビューを楽しくする事が大事。
知的な話術で場を和ませるスキルが必要なのだ。
そのためにも、漫画やアニメ、映画に小説をよんで、面白い語録を身につけることは、仕事に役立つ気がしてきた。
コードの論理的検証
コードが正しいことを証明する＝事前条件・事後条件・不変条件を決めること。
ただし、難しい。
注意点
- gotoは避ける。
- 変更可能な変数は避け、スコープは狭くする。
- インデントを使って読みやすくする。
- 名前で機能が分かるようにする
- パラメータは減らす
- インタフェースの適用箇所は減らす。
コメントについてのコメント
コメントとは、有用なもの。
どういう目的で書いたのかを残す。
多く入れるのは、かえって分かりづらくする。
１行１コメントが許されるのは、教育目的まで。
たまに書かなすぎなやつもいる。
コードは万能ではないことを理解しておくことも必要。
コードに書けないことのみをコメントにする
書かなくても良いものを見極めることが重要。
コードに付加価値を加えないコメントは、ノイズでしかない。
書いてしまうのは、構造や宣言方法に欠陥がある。
なるべくコードに語らせて、コードに書けないことをコメント化する。
学び続ける姿勢
どこでも必要。
会社は当てにしないほうがいい。
自らの力で実施することが大切。
誰にとっての「利便性」か
作る側の利便性＜使う側の利便性
APIを作る時は、使うほうが自由にできることを増やす。
開発者の利便性は糞。
最終的に使われないと意味がない。
すばやくデプロイ、こまめにデプロイ
デプロイ作業後に顧客が利用するので、デプロイがスムーズにいかないのは、不信感を持たれる。
なるべく早く使えるようにして、不確定要素を減らす。
精神衛生的にもいい！
技術的例外とビジネス例外を明確に区別する
区別しないと、問題の切り分けが難しくなる。
なるべく切り分けできるように設計して、障害対応の初動を早くする。
たまに、例外がビジネス的な例外なのか分からない時がある。
例外禁止している現場は、だいたいビジネス例外とシステム例外を見分けられていない。
1万時間の訓練
１万時間経過したら、急にエキスパートになれるわけではない。
やっていく中で、徐々に専門知識がつく。
だけど訓練は、厳しくする必要がある。
楽なものでは意味ない。
温室育ちの花が、アスファルトで生きているハズがない。
才能あれど、常に厳しい環境に身を押して無いと、生存競争に勝てない。
続けることも大切だが、それと同じくらいに、厳しい環境に身を置いて、厳しい訓練をすることも大事。
だから、山ごもりって文化があるのだろう？
ドメイン特化言語
どの分野にも専門用語はある。
一度作れば、技術的な詳細はブラックボックス化し、一般の人にも使えるようになる。
警察とかは、ドメイン用語の宝庫。
デカとか、普通伝わらんやろ。
変更を恐れない
変更を恐れるのは、病気。
システムの健康を保つためにも、変更を恐れずに日々リファクタリングすることは、必須。
健康と同じ。
見られて恥ずかしいデータは使わないこと
恥ずかしいデータの露呈は、いつ発生するか分からない。
常に公になったときのことを考えて作業する。
プリキュア名をテストデータにしたら、いつかバレるから、慎重に！
これは、俺のことじゃないからね！
言語だけでなく文化も学ぶ
複数の言語を学ぶことは、新しい発想を得たり、デザインパターンの理解が深まる。
同じ問題に対して、違った解決方法を身につけることが大事。
多様性は大事！
自分が偏ってると思ったら、反対の言語を学んで見る。
死ぬはずのプログラムを無理に生かしておいてはいけない
例外を無理矢理処理するのは、後で首を締める。
適切な場所で、適切な処理をする。
例外をそもそも導入しないのは、糞野郎。
「魔法」に頼りすぎてはいけない
プログラミングしただけで、プログラミングは語れない。
素人に見えないだけで、データ構造・概念化など、重要な部分が隠れている。
関与してない箇所は、簡単に見えてしまう。
どんなことであれ、仕事している人は尊重する。
問題が起こると、簡単に見えていたことが、実はそうでなかったと気付く。
対応する必要があるので、簡単になったからと言って、対策を怠ってはいけない。
経営、カールと一緒。
なくなってから欲しても、もう手に入らないからね！
DRY原則
重複は無駄である。
作業の重複は、自動化で防ぐ。
ロジックの重複は、抽象化で防ぐ。
そのコードに触れてはならない！
システムを治すからといって、本番に直接修正してはいけない。
決められたプロセスを、権限を持った人がやらないと事故るだけ。
決められたプロセスを無視して実行すると、プロセス通りにやっていれば問題なかった問題を踏み抜いて、余計に時間がかかることが多い。
プロセスの見直しは定期的にするべきだが、急いでいるときほど、いつもやっている手順を重視する。
状態だけでなく「ふるまい」もカプセル化する
振る舞いがカプセル化できてないと、呼び出し元でif-elseが多くなる。
カプセル化することで、保守性が格段に上がる。
浮動小数点数は実数ではない
精度には限度がある。
金融で使うべきではない。
オープンソースプロジェクトで夢を実現する
OSSの参加
- 希望するものが作れる
- 個人の時間を削る必要がある
- 他人の問題解決手法を学べる
貢献方法
- ドキュメントを書く
- テストコードを書く
- コーディング
API設計の黄金律
APIは、公開したら修正するのは難しい。
APIを作る時は、利用する側のテストコードも書く。
テストの難しさを設計課題として捉える。
超人の神話
超人はいない。
ただ、問題解決能力が高いだけ。
超人神話を作るより、エキスパートを育てることに注力する。
超人作るのはいいけど、その人が居なくなるリスクがでかくなるから、企業は超人を作らないほうがいい。
均一なスキル保持者を量産すべき。
ハードワークは報われない
仕事は、短い時間で終わらせる。
長時間労働は、プロ意識の欠如。
効率化と日々の反省を忘れない。
バグレポートの使い方
バグレポートには、感情を入れない。
情報の入れ過ぎは、重複が増えてわかりづらくなる。
情報を増やしたい場合、入力欄を増やすことで対応できないか、一考する。
余分なコードは決して書かない
ない方がいいが、作ってしまう。
作る際に、本当に必要なのかよく考える。
最初が肝心
最初の導入で躓く＝もう使われないと思ったほうが良い。
意外と人間って、成功体験がないとすぐ諦めるんだぜ！
プロセス間通信とアプリケーションの応答時間の関係
応答が遅い場合、データ構造・アルゴリズムよりも、プロセス間の通信量に注目する。
無駄な警告を排除する
無意味な警告は、邪魔なだけでなく、必要な警告を隠す。
syslog見てみろ！
いらねぇログばっか出していると、障害解析が辛いんだよ！クソが！
コマンドラインツールを使う
IDEは、裏で何かをしている。
その何かをしることで、もっと効率的にできる。
プログラミング言語は複数習得すべき
１つしか習得してないと、問題の解法が限られる。
未知の問題に対応できないリスクがある。
IDEを知る
簡単に使えるけど、上達はしない。
限界を知る
リソースには限界がある。
どこが限界なのかをしることで、最適なやり方を知ることができる。
限界を決めるなとかいうやつがいるけど、許容限界を決めて、限界に達したら他の効率的なやり方を探したほうが、有意義だと思いますけどね。
経営もそうしているはずだろう？
すべきことは常に明確に
目標がないと、時間を浪費しがち。
やることに期限をきめるだけでも、効率的になる。
大量のデータはデータベースで
RDBMSで管理することで、大きなメリット享受できる。
いろいろな言葉を学ぶ
人との会話は大事。
チームで働くので、職人仕事より、人と協力して作業する。
見積りとは何か
見積もりとは、何かの価値・量・程度についての概算。
ある程度以上の精度は期待できない。
見積もり・目標・約束の認識が違うと炎上しやすい。
Hello, Worldから始めよう
物事をシンプルに考える。
ごめん、、、これ以上のことは読み取れなかったよ、パトラッシュ。。。
プロジェクト自身にしゃべらせる
CIを適用して、プロジェクトを自動監視する。
プロジェクトの状況を教えてくれるＡＩがあるといいかも。
個人的には、有名声優の声で、異常を教えてもらいたい！
「その場しのぎ」が長生きしてしまう
暫定対応は、意図せず発生してしまうが、放置しておくと後で修正が難しくなる。
修正するには、修正を暫定に加えず、新規で正当なものを作る。
正しい使い方を簡単に、誤った使い方を困難に
使いやすいインタフェースは、正しい使い方が自然とできる。
開発者の利便でＵＩを決めないようにする。
見えないものを見えるように
目に見えるものについては考えるが、見えないものは放置しがち。
ソフトウェア開発は、常に目に見える証拠を維持してないと、状況は把握できない。
並行処理に有効なメッセージパッシング
問題は、だいたい共有メモリ
解決するには、メッセージ交換でできないか検討してみる。
未来へのメッセージ
コードは時間が立つとわかりにくくなる。
未来の自分へのメッセージだと思ってコードを書く。
分かるぜ。３時間前の自分が回たコードを、自分で貶していると知った時の衝撃は、計り知れなかった。。。
ポリモーフィズムの利用機会を見逃さない
if-elseはバグの混入率が高い。
ポリモフィズムが適用できないか検討する。
テスト担当者はプログラマの友人
ＱＡ・ＱＣからの指摘は、恥だと思ってはいけない。
顧客の目に触れる前に見つかったことを喜ぶべき。
顧客の目に触れてからだと、仕事もらえなくなるからな！
バイナリは常に1つ
コナン君に影響されたのか？
環境も含めてバージョン管理するようにしないと、ビルドに振り回される。
真実を語るはコードのみ
コメントを書かないとわかりにくいコードは、コードを改めるべき。
実行されるのは、コードであってコメントではない。
わかりやすくするために、なるべく依存関係は減らす。
ビルドをおろそかにしない
理解が深まれば、ビルド労力・時間の減少になる。
プリミティブ型よりドメイン固有の型を
強い型付けは、問題の発声を防げることが多い。
ビジネスロジック固有のデータ構造を定義すれば、問題の防止が容易になる。
ユーザの操作ミスを防止する
ミスする側が悪いで話を終わらせるのは簡単。
ミスがでるのは、ユーザとソフトウェアの間に誤解が生じている。
ユーザがどう考えて解釈しているか、知ることが大切。
プロのプログラマとは？
やったことへの責任感の強さ。
最善の努力を尽くす姿勢を持つ。
キャリアに責任を持つ
自分の価値は自分で高める
コードに責任を持つ
バグの原因を特定するまで安易な対応はしない。
チームプレイヤーであることの自覚
チーム全体のアウトプットに責任を持つ。
チームのミスはカバーする。
バージョン管理システムを有効に使う
プロジェクトの構成要素は、すべてバージョン管理すべき。
バージョン管理することで、意図しない自己を防げる。
いったんコンピュータから離れてみる
論理的に考えて行き詰まるのは、視点を変える必要がある。
一旦休憩を入れてみる。
コードを読む
コードを書くよりも、リーディングの方が力がつく。
読む場合、何が読みやすいのか考えながら読む。
「人間」を知る
ユーザに分類された要件を求めるのは、無理がある。
理解した上で接しないと、苦労する。
車輪の再発明の効用
車輪の再発明はコストがかかる。
しかし、知識をつけるには、価値がある。
シングルトンパターンの誘惑に負けない
シングルトンの問題
- 暗黙的依存ができる
- 永続化される
- インスタンス削除のタイミングがない
シングルトンを使う際は、上記問題を考慮する必要がある。
パフォーマンスへの道は地雷コードで敷き詰められている
パフォーマンスは、複雑度と依存性の戦い。
事前にメトリクスを計測しておく必要がある。
シンプルさは捨てることによって得られる
リビジョンが上がっても、よくなることは少ない。
既存のコードの質が一定以下なら、捨てる覚悟を持つ。
捨ててシンプル化することを考える。
単一責任原則
同一の変更理由によって変わるものは、一箇所に集める。
「イエス」から始める
顧客要望は、肯定的な立場から受け止める。
そして、理由を追求する。
理由が明確になることで、ストーリーが生まれ、人を動かしやすくなる。
面倒でも自動化できることは自動化する
自動化できるものは、できるだけ自動化する。
コード分析ツールを利用する
品質向上は、テストだけではない。
コード解析を使って、テストで見つけにくいものを発見する。
偶然の仕様ではなく本物の仕様のためのテストを書く
細部に至るまでの厳密なテストは、テストコードと強結合になる。
細部に至るテストは、実装上そうなっただけで、偶然の私用に過ぎないものをテストしている可能性が高い。
やるなら、ブラックボックステストで、本来の要求をテストする。
テストは夜間と週末に
テストは、夜間と週末に実施して、リソースを効率的に使う。
テストのないソフトウェア開発はあり得ない
建築と違って、作った後にテストできる。
テストは、ソフトウェア開発固有の作業で、重要度が高い。
開発者は、責任を持ってテストを行う。
1人より2人
システム開発は、一人ではできない。
ペアプログラミングで得られる効果は大きい。
確信が持てないなら、実施してみる。
エラーがエラーを相殺してしまう
問題が相互作用で発生することがある。
問題が発生したら、曇りなき眼で、思い込みを捨てて、冷静に対応する。
他者への思いやりを意識したコーディング
ただ質の高いコードを書くだけではダメ。
他人へ影響を与えるコードを書く。
UNIXツールを友にする
拡張性が高く、効率的に使える。
正しいアルゴリズムとデータ構造を選ぶ
適切なアルゴリズムを選ぶことは、適切なデータ構造を選ぶこともセットでついてくる。
アルゴリズムを使えるシーンについて、理解を深めておかないと、失敗することがある。
冗長なログは眠りを妨げる
ログに不要なものがあると、問題が発生しているかも分からない。
必要最低限のものだけ出す。
WETなシステムはボトルネックが見つかりにくい
DRY原則に反しているもの＝WETシステム
保守性だけでなく、ボトルネックの発見も困難化するので、DRY原則は守る。
プログラマとテスターが協力してできること
設計が悪いと、テスト項目が多くなり、テスターの負荷が増える。
設計を改善するためにも、テスト項目を理解しておく必要がある。
テスターとプログラマーのチームワークを良くすることが、成功の鍵。
コードは生涯サポートするつもりで書く
コードを適当に書いてはいけない。
生涯サポートするくらいの気持ちで真剣に書く。
関数の「サイズ」を小さくする
問題領域はなるべく狭くする。
扱いやすくなるだけではなく、障害調査もしやすい。
コードを見る人のためにテストを書く
テストコードをただ書いているだけではダメ。
テスト対象を補完するようなテストコードを書く。
良いプログラマになるには
一朝一夕ではなれない。
努力を続けた人だけがなれる。
善意だけではなれない。
善意が役立っているか、確認して今後に活かす。
顧客の言葉はそのまま受け取らない
言っていることが正しいとは限らない。
意図を読み取ることが大切。
エラーを無視するな
エラーを放置しない。
放置すると、コードベースが不安定になり、バグを生みやすくなる。
リンカは魔法のプログラムではない
難しいことはしてないが、簡単なことが積み重なると、難問ができあがる。
ペアプログラミングと「フロー」
相手の方が格上：気後れせずに接する。
相手の方が格下：忍耐強く接する。
ペアプログラミングのメリットは、早期問題の抽出と新人育成。
テストは正確に、具体的に
テストは正確に書くだけでは不十分。
わかりやすくテストの目的が分かるようにする。
ステートに注目する
状態が処理に与える影響は大きい。
だから、状態には注目しておく。
命を吹き込む魔法
コードネームをつけると、当事者意識がまして、震源に取り組むようになる。
ロールプレイングゲーム
理想のプログラマを演じる。
仕事と割り切れば、できること。
ルーチンワークをフローのきっかけに
ルーチンワークは、無駄になっていることがある。
自動化して、他のことに集中する。
プログラマが持つべき3つのスキル
- コールドリーディング
- テスト
- デバッグ
スキルをあげるには、OSS開発か、師となるべきエンジニアを見つけるしかない。
快適な環境を追求する
環境を改善することで得られる時間は、投資した時間より多くの物が返ってくる。
コーディングで食っていくなら、環境改善は必須。
見知らぬ人ともうまくやるには
できないことは、できないまま。
できることは、できるようにしておく。
無駄な論争をせずに済む。
例えばユーザ情報の更新。
ＱＡテストで使うユーザのＩＤとパスワードを全員知っているせいで、意図せず変えてしまってテストで混乱するのは、避けないといけない。
あと、環境もね。知らない人から、ディスられるから、やれないことはやれないようにして置くのは、超絶大事！
俺がディスられたわけじゃないいだからね！
不具合にテストを書いて立ち向かう
不具合修正は、不具合再現コードを書いてから行う。
遠回りのようだが、一番合理的。
育ちのよいコード
成長するに連れて、まとまりの悪さがでる。
リファクタリングと機能追加のパッチを使い分けるようにして、まとまりの悪さを回避する。
Noといえることの大事さ
ソフトウェアの公開は、機能追加要望が増える。
そうすると、いらない機能が増えて使いにくくなってしまう。
だから、Ｎｏと言えることが大切
名前重要
設計の基本は、ネーミング。
ネーミングにはこだわる。
読了感想
本当はもっと早く読むつもりだったけど、結構先延ばしになっていた。
読書スピードが落ちているってのもあるかも知れない。
