世界一流エンジニアの思考法

世界一流エンジニアの思考法を読んだ。

「アジャイルサムライ」「リーダブルコード」「リーン」「エッセンシャル思考」「失敗の科学」「プログラマー脳」「ヘルシープログラマー」などの本を1冊にまとめたような本。一部「ん？ホンマか？」となる部分もあったが、読んでおいて損はない。

ざっくりまとめ

• ひとつの事実を見つけ、仮説をたて、検証する
  • 試行錯誤ではなく最短距離を行くために手を動かす前に考えようという内容
• 理解とは、人に説明できること、いつでも即座に取り出して使えること、応用が効くこと
  • 理解するためにも習得に時間がかかる基礎が重要
• 成功しようがしまいが、まずやって、フィードバックをもらって、早く間違いを修正する
  • Fail Fast の精神
• 得た学びのシェアがバリューであり、会社にとっての財産
• コードを理解するためには極力読まず、インターフェースと構造を理解する
  • 全部読んでいては脳に負荷がかかるので、インターフェースや構造だけに注目する
  • 読んだ人がどう感じるかを常に意識する
• コミュニケーションは意図的に情報量を減らす
  • 全部を共有せず要点のみ、他は聞かれてから答えればいい
  • そのため質問しやすい環境が重要
• クイックコールを頻繁に行う
  • テキストベースではなく、気軽に通話を繋いで質問する
• マネージャ（ボス）の役割は開発者がブロックされる要素を除去する
• ブログを書くのは理解するために重要
• 瞑想（マインドフルネス）、ディスプレイから離れる、しっかり寝る
  • 脳の酷使をやめる
• 運動しよう
  • 毎日30分有酸素運動
  • 運動は最優先に行う
• 日本のSNSにおける批判文化は日本にとって致命的な足かせ

実装前にデザインドキュメントを書く

## Scope
このデザインドキュメントの範囲を書く

## Background
なぜこのプロポーザルを行っているかという背景を書く

## Problem Statement
解決したい問題を書く

## Proposal
どういうデザインにするか、またその選択肢を選んだ理由をロジカルに書く
分量は2〜10ページぐらいの簡潔なものにする

p.42より

「変数名どうしよう」とか「いったんこの部分リファクタしたほうがよさそう」といったノイズが思考の邪魔をする。 あと、考えながら実装すると設計がどんどんいびつになっていくのは体感としてあって、継ぎ足しでつくる秘伝のタレみたいになりがちなので、デザインドキュメントを書くのは良いかもしれない。