プログラマが知るべき97のこと

• 分別ある行動
• 関数型プログラミングを学ぶことの重要性
• ユーザが何をするかを観察する（あなたはユーザではない）
• コーディング規約を自動化する
• 美はシンプルさに宿る
• リファクタリングの際に注意すべきこと
• 共有は慎重に
• ボーイスカウト・ルール
• 他人よりまず自分を疑う
• ツールの選択は慎重に
• ドメインの言葉を使ったコード
• コードは設計である
• コードレイアウトの重要性
• コードレビュー
• コードの論理的検証
• コメントについてのコメント
• コードに書けないことのみをコメントにする
• 学び続ける姿勢
• 誰にとっての「利便性」か
• すばやくデプロイ、こまめにデプロイ
• 技術的例外とビジネス例外を明確に区別する
• １万時間の訓練
• ドメイン特化言語
• 変更を恐れない
• 見られて恥ずかしいデータは使わないこと
• 言語だけでなく文化も学ぶ
• 死ぬはずのプログラムを無理に生かしておいてはいけない
• 「魔法」に頼りすぎてはいけない
• DRY 原則
• そのコードに触れてはならない！
• 状態だけでなく「ふるまい」もカプセル化する
• 浮動小数点数は実数ではない
• オープンソースプロジェクトで夢を実現する
• API 設計の黄金律
• 超人の神話
• ハードワークは報われない
• バグレポートの使い方
• 余計なコードは決して書かない
• 最初が肝心
• プロセス間通信とアプリケーションの応答時間の関係
• 無駄な警告を排除する
• コマンドラインツールを使う
• プログラミング言語は複数習得すべき
• IDE を知る
• 限界を知る
• すべきことは常に明確に
• 大量のデータはデータベースで
• いろいろな言葉を学ぶ
• 見積りとは何か
• Hello, World から始めよう
• プロジェクト自信にしゃべらせる
• 「その場しのぎ」が長生きしてしまう
• 正しい使い方を簡単に、誤った使い方を困難に
• 見えないものを見えるように
• 並行処理に有効なメッセージパッシング
• 未来へのメッセージ
• ポリモーフィズムの利用機会を見逃さない
• テスト担当者はプログラマの友人
• バイナリは常に1つ
• 真実を語るのはコードのみ
• ビルドをおろそかにしない
• プリミティブ型よりドメイン固有の型を
• ユーザの操作ミスを防止する
• プロのプログラマとは？
• バージョン管理システムを有効に使う
• いったんコンピュータから離れてみる
• コードを読む
• 「人間」を知る
• 車輪の再発明の効用
• シングルトンパターンの誘惑に負けない
• パフォーマンスへの道は地雷コードで敷き詰められている
• シンプルさは捨てることによって得られる
• 単一責任原則
• 「イエス」から始める
• 面倒でも自動化できることは自動化する
• コード分析ツールを利用する
• 偶然の仕様ではなく本物の仕様のためのテストを書く
• テストは夜間と週末に
• テストのないソフトウェア開発はありえない
• 1人より2人
• エラーがエラーを相殺してしまう
• 他者への思いやりを意識したコーディング
• UNIX ツールを友にする
• 正しいアルゴリズムとデータ構造を学ぶ
• 冗長なログは眠りを妨げる
• WET なシステムはボトルネックが見つかりにくい
• プログラマとテスターが協力してできること
• コードは生涯サポートするつもりで書く
• 関数の「サイズ」を小さくする
• コードを見る人のためにテストを書く
• 良いプログラマになるためには
• 顧客の言葉はそのまま受け取らない
• エラーを無視するな
• リンカは魔法のプログラムではない
• ペアプログラミングと「フロー」
• テストは正確に、具体的に
• ステートに注目する
• 命を吹き込む魔法
• ロールプレイングゲーム
• ルーチンワークをフローのきっかけに
• プログラマが持つべき 3 つのスキル
• 快適な環境を追求する
• 見知らぬ人ともうまくやるには
• 不具合にテストを書いて立ち向かう
• 育ちのよいコード
• No と言えることの大事さ
• 名前重要

分別ある行動

• 技術的負債は 2 つに分けられる
  • 故意の技術的負債
    • 「正しくやる方法」と「手早くやる方法」の両方が見えてるときに、前者が良いとわかっていながら後者で妥協することで生まれるもの。
    • 後で直そう直そうとは思うものの、結局イテレーションが実際に始まってしまうとなおざりにされがち。
    • 次のイテレーションに返済作業を組み込めれば、負債の利息は最小化できる。
    • なんにせよ、負債のトラッキングはしながら開発しなければならない。
  • 不注意から発生する技術的負債

関数型プログラミングを学ぶことの重要性

• 良いところ
  • 参照透過性
  • 不変性
• パラダイムにとらわれず、良いところは他のパラダイムでやってるときも活かせるよね、って話。

ユーザが何をするかを観察する（あなたはユーザではない）

• 偽の合意効果
  • 他人も自分と同じ認識を持ち、同じ考えを持ち、同じ行動をするであろう、というバイアス。
• ユーザは基本的に、自分のやりたいことが実現できればいいのであって、一つその方法を見つけてしまえば、もっとよい方法を考えようとすることはない。
  • 見てすぐにわかる方法が 1 つ用意されていればそれで充分 UX は担保される。
  • それを提供するには、ユーザがどのような行動を取っているのか、どのような操作をしているのかを観察する必要がある。

コーディング規約を自動化する

• コードフォーマットを開発プロセスの中に埋め込んで、フォーマットせずに納品することが不可能にする。
• linter で違反コードのビルドは失敗させる。
• ツールの設定で、プロジェクト固有のアンチパターンも発見できるようにする。
• テストカバレッジの計測だけでなく、閾値判定も自動化し、違反していればビルドを失敗させる。

美はシンプルさに宿る

• アプリケーション全体がどれだけ複雑であっても、個々の部分を切り出してみるといたってシンプル。
• 関数がそれぞれ 5-10 行ほど。

リファクタリングの際に注意すべきこと

• まずは既存のコードとテストの洗い直し。
• 一から書き直したい気持ちは我慢する。
• インクリメンタルに変更する。
• イテレーション毎にテストを実行する。
• エゴレスに。
• 新技術を使いたい、だけではリファクタリングの価値はない。
  • 機能・保守性・生産性が上がるならやる価値あり。
• 人間はミスることを忘れない。

共有は慎重に

• いわゆる「正しい DRY」
• WET に見えても、実はコンテキストが違うから別々に書かれているだけの可能性を忘れないこと。

ボーイスカウト・ルール

• 来た時よりも美しく。

他人よりまず自分を疑う

• コンパイラ・OS・フレームワークが悪いなんてことはほぼなくて、お前の書いたコードがバグってるだけ、がほとんどの場合真実。

ツールの選択は慎重に

• 昨今ではスクラッチ開発なんてほとんどなくて、フレームワークや OSS を組み合わせて作る。
• そのとき、組み合わせるもの同士の相性を慎重に考慮すべき。
• ベンダロックインに気を付ける。

こうした問題を避けるために、まずは

• 必要最低限のツールだけ導入する。
• 特に、インフラ関連の低レベルプログラミングを避けることに注力する。

ドメインの言葉を使ったコード

if(portfolioIdsByTraderId.get(trader.getId())
   .containsKey(portfolio.getId())) {...}

if(trader.canView(portfolio)) {...}

後者のが圧倒的にわかりやすい。

まあ、OOP をちゃんとやれてればいいって話。

コードは設計である

私たちは、「コードを書くことは設計をすることである」ということ――機械的な作業などではなく、創造的な仕事なのだということ――を肝に銘じる必要があります。 それをよく考えれば、ソフトウェア開発がなぜ今、危機に陥っているのか、その理由がわかるでしょう。 何より危機に陥っているのは設計です。作る人間の能力を超えるほどの高度な製品、複雑な設計が求められていて、 しかも製品を早く市場に出せという圧力が強いような状況では、設計が不十分なまま製品が作られることがどうしても多くなるのです。

• 自動テストをしよう。
• 技術習得のために努力しよう。

コードレイアウトの重要性

• 目立たない部分を作る
  • 重要な部分とそうでない部分を区別できるような書き方をする。図地フレーミング。
• レイアウトに語らせる
• コンパクトにまとめる
  • シンタックスハイライトとか IDE の発達とかによって、コードを読むときの制約は「画面の大きさ」ぐらいになり、そこに注意をそそぐべき。

コードレビュー

• コードの質を上げ、欠落を減らすため。
• だけではなく、チーム全員に同じ知識を共有すること、全員が守るべきガイドラインを確立すること、なども目的の内。

コードの論理的検証

• 事前条件、事後条件、不変条件をはっきりさす。
• あとは不変性とか命名とか。よくあるやつ。

コメントについてのコメント

• ヘッダコメント（javadoc とか）には、コード本体をまったく読まなくても API を利用できるぐらいの情報を盛り込む。
• インラインコメントには、修正や拡張に役立つ情報を盛り込む。

コードに書けないことのみをコメントにする

• コードに「書いていないこと」ではなく、「書けないこと」のみ。
• つまり、書けるけど書いてない、は、書くようにしたらいいじゃん、という話。
  • たとえば、あるコードブロックが処理 A をやっている場合に、「処理 A を行う」とコメントするのではなく、「処理 A」という命名の関数に抽出するなど。

学び続ける姿勢

誰にとっての「利便性」か

• API を実装する際、実装しやすさではなく、利用側の利便性について考える方がよい。
• walk(true) が走ることを意味するのは分かりづらい。walk run という 2 つの API がある方がはるかにわかりやすい。
• 「部屋を片付けて、静かに宿題をやりなさい」という命令を一語で下すことはできないが、これを一語にまとめてしまおう、などとは考えない方がよい。
• Effective Java でも同じこと言われてた気がする。メソッドのシグニチャを注意深く設計する

すばやくデプロイ、こまめにデプロイ

技術的例外とビジネス例外を明確に区別する

• 題の通り。そもそもビジネス例外は例外じゃなくて戻り値に情報として含めればいいね。Haskell の Maybe とか

１万時間の訓練

ドメイン特化言語

• DSL は内部と外部にわけられる。
• 内部 DSL
  • 糖衣構文とかを駆使して、見かけ上の文法を自然言語に近づけたもの。Ruby とか Scala とか、構文自由度が高い言語が得意。逆に Java みたいなガチガチの奴は苦手。
• 外部 DSL
  • 技術的知識のない人でも読めるように、汎用プログラミング言語とは全く切り離された構文を持った DSL。
  • EBNF などの文法を定義するのが有効。
  • openArchitectureWare、ANTLR、SableCC、AndroMDA など、DSL のために作られた既存ツールを使うとよい。

変更を恐れない

見られて恥ずかしいデータは使わないこと

• 自分しか見ないと思っているモックデータ・テストデータ・ソースコードだとしても、なんかの拍子に人の目に触れる可能性がある。
• もし公になっても大丈夫な書きっぷりにしましょうね。

言語だけでなく文化も学ぶ

• Effective Java に書いてあった。

死ぬはずのプログラムを無理に生かしておいてはいけない

• 例外を、握りつぶすな。失敗したらハンドリングしろ。

「魔法」に頼りすぎてはいけない

• 自分の関わっていない仕事に関しては自動的に進んでタスクが片づけられている、いわば「魔法」でいとも簡単に進行しているように錯覚しがち。
• その「魔法」のようなものでなんとかしてくれている人がいなくなった途端に、「魔法」が解けてとんでもないことになる、ということは覚えておくべき。
• そういうときは誰かが「魔法」をかけなおさなければならない。

DRY 原則

• すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。
• 作業の重複も DRY にする。つまり、自動化する。
• ロジックの重複は抽象化で防ぐ。Abstract Factory pattern とか Factory Method pattern とか。
• 関連する原則
  • OAOO (Once and Only Once)
  • SRP
  • OCP
• 性能問題への対応として、WET を許さなければならない場合もある。が、そういった目下の問題がないのに DRY にしない理由はない。

そのコードに触れてはならない！

• 本番環境で作業するな。クローンするなり何なりしよう。

状態だけでなく「ふるまい」もカプセル化する

• 所謂貧血ドメインモデルを避けようという話。

浮動小数点数は実数ではない

• あたりまえ体操

オープンソースプロジェクトで夢を実現する

• オープンソースプロジェクトへの参加を通して自分の適性ややりたいことが見つかるかも。

API 設計の黄金律

API を提供するときは、API 自身のテストだけでなく、必ずその API を利用するコードのユニットテストも書く

API の利用者側がユニットテストをするときに、どういう困りごとが発生するかを事前に予知できる。

超人の神話

XYZ という例外が発生したのですが、何が問題なんでしょうか？

いや、知らねーよという話。

何も言わなくても、相手は「超人」なのだから、私の問題を理解して解決方法を提示してくれるだろう、などという期待は捨てるべき。

そうした「超人」に見えるほど優秀な人たちは、必要な情報が十分に与えられて、初めてその能力を存分に発揮するのだということを忘れないように。

ハードワークは報われない

• プログラマはしゃにむに働けばいいわけではない。仕事はさっさと終わらせて切り上げて、自己研鑽にこそ時間をかけるべき。

バグレポートの使い方

• バグを起票するときは以下の 3 つを必ず書く。
  • 再現方法と発生頻度
  • 本来あるべき仕様
  • 実際の挙動

余計なコードは決して書かない

• 余計なものの例
  • 面白そうだから書いたコード
  • YAGNI 違反のコード
  • 必要か迷ったけど仕様確認が面倒だったからとりあえず書いたコード
  • 議論してないし設計もされてないけどプログラマが勝手に要件を考えて書いたコード

最初が肝心

• 使われるソフトウェアは、導入が簡単。
  • 導入手順が少ないとか、簡単とか、素早く使えるようになるとか、チュートリアルが充実してるとか。

プロセス間通信とアプリケーションの応答時間の関係

• IPC が多ければ多いほど、性能の問題になりやすい。設計時点でこれを考慮しておくべき。

無駄な警告を排除する

• 警告が出たら、即座に潰す。警告に沿って修正したり、大した警告ではないと判断すれば抑制したり。
• ただ、警告のポリシーを変更するのは自分勝手にやるのではなく、チーム全体に問いかけて合意を得てから変更する。

コマンドラインツールを使う

• IDE や GUI だけ使っていると、裏で行われていることに対する理解が深まらない。
• CLI を積極的に使おう。そうすると、実は自動化できるじゃんみたいなことも見えてくるかも。

プログラミング言語は複数習得すべき

• 複数のパラダイムに触れることで、どのパラダイムにも活かせる可能性がある。

IDE を知る

• テキストエディタに比べて、 IDE は学習曲線が緩やか。
• ショートカットキーを使いこなす。

限界を知る

• 計算資源の限界を知る。時間・空間計算量の話。

すべきことは常に明確に

• いつのまにか手探りで作業していた、という状態に絶対に陥らないようにすること。
• 叩き台作って、ちょっと進めて、叩き台が無駄だったとわかったら躊躇なくそれを壊して、またやり直して……を繰り返す。

大量のデータはデータベースで

• 参照制約とか付けられるのでデータの整合性を守れる。
• ACID が守られる。
• オプティマイザがアルゴリズムを決定してくれるのでその辺を考える時間を節約できる。

いろいろな言葉を学ぶ

• 「他者の言葉を知ることは、新たな魂を持つこと」――カール大帝
• 自分の知らない業界に関しては、いろいろその業界での専門用語とかを知って概念を理解しなきゃいけないということ。
• 名前も知らないような概念は理解できないってところを見ると、ジョシュアツリーっぽいね。

見積りとは何か

• 見積り・ターゲット・コミットメントがまとめて「見積り」と呼ばれがち。
• 見積り: 何かしらに基づいて概算あるいは大まかな判断をすること。
• ターゲット: 実現したいビジネス上の目標を明文化したもの。
• コミットメント: 納期や品質などに関する約束。
• 見積りの主目的は、プロジェクトの結果を予測することではなく、プロジェクトのターゲットが現実的に達成可能か否かを判断できるようにすること。

Hello, World から始めよう

プロジェクト自信にしゃべらせる

• カバレッジとかテストの失敗とかの通知を自動化することで、プロジェクト自体が問題を人間に通知することができるようになる。

「その場しのぎ」が長生きしてしまう

• とはいえ、暫定ソリューションを全く作らないのは、それはそれで非現実的。
• そういうときは、暫定を修正し続けるようなことはやめてしまって、暫定ソリューションが不要になるように、より優れたソリューションを実装してしまえばいい。
• 自分に変えられることと自分には変えられないことを冷製に見極めて、変えられる範囲ではドラスティックに変更を加えていくことが大切。

正しい使い方を簡単に、誤った使い方を困難に

見えないものを見えるように

• ユニットテストを書くことで、テスト容易性がわかるようになる。
• ユニットテストを実行することで、動作が目に見えるようになり、堅牢性も確かめられる。
• プロジェクトボードを使うことで、タスクの進行度が目に見えるようになる。
• とにかく、見えないものは管理できないので見えるようにする。

並行処理に有効なメッセージパッシング

これはどうだろう……

未来へのメッセージ

• 難しいことをやるソースコードは難しくなって当然、という考えは誤り。
• 部分に分解して、わかりやすく・読みやすくすることはいくらでも可能。

ポリモーフィズムの利用機会を見逃さない

• Strategy pattern と Double Dispatch pattern を組み合わせて使うとか。

テスト担当者はプログラマの友人

• テスト担当者はバグを指摘してきてうるさいと感じるかもしれないが、まあまあ、落ち着いてもらって、品質を高めてくれる友人だと思おうよ、という話。

バイナリは常に1つ

• どの環境でも同じバイナリを利用するようにする
• 環境に関する情報もバージョン管理の対象に含める
• これによって、不確定要素が省かれてヒューマンエラーが抑制される。

真実を語るのはコードのみ

• 可読性高くしようね、という話。

ビルドをおろそかにしない

• ビルドプロセスを簡単にしておくことで、コーディング作業に割く時間を増やせる。

プリミティブ型よりドメイン固有の型を

• DDD の modeling の話ですね。

ユーザの操作ミスを防止する

• 誤ったフォーマットで入力できないように入力欄を設計する。
• undo 操作をユーザに提供しておくことで、ミスっても自分で戻せるようにしておく。
• undo 操作のログを取ることで、ユーザがどのようなミスを頻発するのか分析できるようにしておく。

プロのプログラマとは？

• 自分が責任を取るという態度、責任感。

バージョン管理システムを有効に使う

• 意味ある単位で commit する。大きい差分を一度に commit すべきでない。
• commit message をつけること。できれば理由も。
• ビルドを壊すような commit はしないこと。どのバージョンでも正常にビルドできるようにしておくのが望ましい。

いったんコンピュータから離れてみる

コードを読む

• 読んで、読みづらいならなんで読みづらいのか、読みやすいならなんで読みやすいのか、とにかく考えて自分のものにする。

「人間」を知る

• 哲学とか認知科学を知ると人間を知ることができて、仕事にも役立つよという話。

車輪の再発明の効用

• いつまでもブラックボックスに甘えてないで、自分で実装できる力をつけるのも悪くないよ、という話。

シングルトンパターンの誘惑に負けない

• 後からインスタンスを増やしたくなった時、困る。
• 結合度が上がる。単体テストをするときに、モックできなくて困る。
• immutability を損なう可能性がある。特に、マルチスレッド環境で危なくなる可能性がある。

パフォーマンスへの道は地雷コードで敷き詰められている

• これはパフォーマンス改善に限った話じゃない。
• とにかく、何か変更を加えようとしたとき、あるいはリファクタリングしようとしたときに、想像以上に結合度が高くて色々変えなきゃいけなくなる、という地雷が存在する。
• メトリクスツールを使うなどして、クラス間の依存を調べてメンテナンスすることが必要になってくる。

シンプルさは捨てることによって得られる

• あまりにも酷いコードは、爆破して新たに作った方がいいこともある。

単一責任原則

「イエス」から始める

面倒でも自動化できることは自動化する

コード分析ツールを利用する

偶然の仕様ではなく本物の仕様のためのテストを書く

• 偶然の仕様: 実装の都合でたまたまそうなっている、という箇所。テストは、こういった実装の詳細に依存すべきではない。
• 本物の仕様: ビジネスロジックとしてどうなっていなければならないか、という、問題解決の本質部分。
• 前者に対してテストを書いてしまうのは、ホワイトボックス脳になりすぎてるから。ちょうどいい塩梅を探すように心がける。

テストは夜間と週末に

• テスト実行には少なからず時間がかかる。特に、テストケースが多かったり、性能テストを行いたかったりする場合。
• こうしたものは、昼間に作業を中断して実行するのではなく、夜間や週末、作業に影響のない時間を使って行えるようにしておくべき。

テストのないソフトウェア開発はありえない

1人より2人

• ペアプロ、やろう！
• 特にリモート勤務が多い今、重要な気がする。

エラーがエラーを相殺してしまう

• あるバグの原因を調査するとき、2 つ以上の部品でバグってる可能性を忘れないこと。
• このケースなら絶対再現できるはずなのに、再現できない！とかいう場合は、起きたバグが別の場所で相殺されてないか？とか、無限の可能性を考慮する必要がある。

他者への思いやりを意識したコーディング

UNIX ツールを友にする

• IDE ばっかり使ってないで CLI も使おうね。こっちの方が汎用性高いからいろんなことできて便利だよ、という話。

正しいアルゴリズムとデータ構造を学ぶ

• 早すぎる最適化は確かに悪だが、何も考えてない動けばいいや的な実装が許されるわけではない。

冗長なログは眠りを妨げる

• 必要十分な内容をログには盛り込むようにしよう。本当に大切なやつが埋もれてしまうので。

WET なシステムはボトルネックが見つかりにくい

• プロファイラで見たときに、WET なシステムは、ボトルネックが複数個所に分散して見えるため、本質的には一つの大きいボトルネックであるにもかかわらず、分解されて埋もれてしまう場合がある。

プログラマとテスターが協力してできること

コードは生涯サポートするつもりで書く

関数の「サイズ」を小さくする

• 例えば、囲碁でアタリか否かを判定する関数を考える。

boolean atari(int libertyCount)
    libertyCount < 2

libertyCount が取り得る値は int の範囲と同値であるが、囲碁においては 4 方向のみ判定するため、高々 4 である。

つまり、本来取り得る状態数に比べて、プログラム上で取り得る状態数が大きすぎる。

LibertyCount = {0,1,2,3,4}
boolean atari(LibertyCount libertyCount)
    libertyCount == 1 || libertyCount == 2

のように、ドメイン固有の型を利用することによって、状態数を狭め、あり得ない状態を刈り込むことができる。

コードを見る人のためにテストを書く

• テストコードを見ることで仕様を理解できるようにしておく。
• 例えば、事前条件・事後条件など。

良いプログラマになるためには

• どんなに急かされていても、「とりあえず動く」だけのコードは書かない。
• わかりやすく、保守しやすく、正しく書く。
• 他人と協力する。
• ボーイスカウト・ルールを守る。
• 色々学ぶ。が、新しいことを試したい気持ちを我慢して、本当にベストなタイミングでのみ適用する。

顧客の言葉はそのまま受け取らない

• 言い間違えをしていたり、業務領域特有の言葉だったり、社内特有の言葉だったり、何かしらのバイアスがかかっている言い回しをしている可能性があるため。
• 絵や図で認識合わせを実施する。
• 別の言葉で説明し返して、合ってるか確認する。

エラーを無視するな

リンカは魔法のプログラムではない

• その結果できるものが複雑である場合は確かに往々にしてあり、調査が面倒、というだけで、リンカがやってる処理なんていたって簡単。らしい。

ペアプログラミングと「フロー」

• フロー状態の維持にペアプロが有効。

テストは正確に、具体的に

• 必要条件だけ確認するのではなく、十分性も確認すべき。

ステートに注目する

• 状態遷移図を書くとか。
• State pattern を学ぶとか。
• 「契約による設計」を学ぶとか。

命を吹き込む魔法

• プロダクトに名前を付けることでみんな愛着がわく、みたいな話。

ロールプレイングゲーム

• 仕事中は、「理想のプログラマを演じる」つもりで取り組む。
• 演じているだけなので、本来の自分と衝突しなくて済む。
• 「ショートコント、会社員」的な話だね。

ルーチンワークをフローのきっかけに

プログラマが持つべき 3 つのスキル

• コードを読むスキル
• テストをするスキル
• デバッグをするスキル
• これらをバランスよく鍛えるには、例えば OSS のバグ対応をやってみる、とかがある。

快適な環境を追求する

見知らぬ人ともうまくやるには

• 見知らぬ人とうまくやる一番のコツは、見知らぬことをしないこと。
• できちゃいけないことをできないように禁止する、のではなく、できていいことだけをできるように設定する、と考える。
• では、何ができていいことなのか？というのは難しい課題。
• だが、ブラックリスト的なやり方よりもホワイトリスト的なやり方の方が、格段に楽になるはず。

不具合にテストを書いて立ち向かう

育ちのよいコード

• repo の history を見て、各 commit の変更箇所が一か所にまとまっていればいるほど、育ちがいいコードと言える。
• が、特にリファクタリングなどでは変更箇所が散らばりがち。
• だから、リファクタリングと feature は別々の commit にしましょうね。

No と言えることの大事さ

名前重要

ホームへ戻る