みなさんこんばんは！宮水です。
達人プログラマーを読み始めたので、週1ペースでブログに学んだことを残していきます。
- 作者:Andrew Hunt,David Thomas
- 出版社/メーカー: オーム社
- 発売日: 2016/10/20
- メディア: 単行本（ソフトカバー）
第2章 達人のアプローチ
二重化の過ち
「急がば回れ」という格言を思い出してください。今はほんの数秒を節約できるかもしれませんが、それはあとで何時間もの遅れに繋がる危険性を秘めているのです。
難しい問題に限らず、面倒がってよく考えられていない変数名を使ってしまったり、小分けせずに大きなcommitをしてしまったり...
毎日小さな怠慢と戦っています。でもあとで被害を被るのはいつも自分自身なので、細かいところも妥協せずにコードを書くぞ。
再利用しやすいようにしておくこと
これもしばしば選択を迫られます。
一見実践が難しそうな内容ですが、ちょっと面倒でもutilに切り出すとか多少長くなっても探しやすい変数名で書くようにするとか、いくらでも方法があることに最近気づきました。そして何より、毎日のように再利用しやすいコードを書いてくださった先輩に感謝しながらコードを参考にしています。「誰かが使うかもしれない」という観点大事。
直交性
直交しているシステムとは、2つ以上の物事で、片方を変更してももう片方に影響を与えないシステムのことです。
コードだけでなく、プロジェクトチームや設計、ツールやライブラリ、テスト、ドキュメントでもこの考え方を応用できるらしい。
可逆性
最終決定などというものはない
アプリケーションは日々変化していくので、どんな変化があっても柔軟に対応できるように分割できるように考えるべき。（感想が雑）
曳光弾
読めない。えいこうだん（曳光弾 - Wikipedia）と読むらしいです。
達人プログラマは、要件が曖昧なアプリに対しても骨格を組み上げて、フィードバックをもらい、作ろうとしているものの軌道修正を徐々に行っていくそうです。（すげぇ）
この話を読んで、受託時代のことを思い出しました。
経験が浅かった私は、要件が曖昧なプロジェクトに大変苦労したのを覚えています。
プロジェクトメンバーの誰も「アプリの全体像」はまだわからないし、どんなアプリが「良い」のかわからないのです（ネガティブな意味じゃなく、スタートアップにはありがちな話だと思います）。
酷いコードでしたが、作っていくうちに「ここは使いにくいよね」「この機能はあるとやっぱり便利だよね」ということがわかってきて、要望が明確になっていきました。それでも要件が決まっていないアプリケーションを作るのって大変ですよね。達人プログラマへの道はまだまだ遠い...
プロトタイプとポストイット
曳光弾形式の開発とは異なり、プロトタイプを制作するという手法もあります。
コーディングによるプロトタイピングを始める前には、関係者 全員 が 使い捨て の コード を 記述 する という 前提 を 理解 し て いる か どう か、 必ず確認してください。 プロトタイプ という 言葉の意味を知らない人にとっては、プロトタイプが外見上魅力的なものに映ってしまうのです。
その コード は 使い 捨てる もの で あり、 不完全 で、 完全 な かたち に する こと が でき ない、 という 事実 を 明確 に し て おか なけれ ば なら ない の です。
とりあえず動くものが見たかったら、コードを捨てることを前提でデザインだけ先に作るのも大ありですね...
先にモデルをかためて少しづつ作っていって、実装が積んだことがあります。次新規開発するときは、画面設計ちゃんと考えてからやる。
その こと が 正しく 伝え られ て い ない と、 プロトタイプ の 見た目 の 派手 さに 目 を 奪わ れ た プロジェクト の スポンサー や 管理者 が、 プロトタイプ（ や その 派生 版） を 元 に し て プロジェクト を 進め て いく よう 強要 する かも しれ ませ ん。 バルサ 材 と ダクト テープ で かっこいい 新車 の プロトタイプ を 作る こと は でき ます が、 それ が ラッシュアワー の 交通渋滞 の 真ん中 で 運転 できる 代物 では ない という 点 に 気付い て もらわ ない と いけ ない の です！
見積もり
要求を理解する、モデルを先に作る、見積もりを誤ったら反省する、など書いてありました。
今はの職場では案件が一個与えられたらそれをみんなで細かいISSUEにわけて、
実装の方針や不明点はチーム全員で考え、一緒に見積もりポイントをつけています。（パーフェクトすぎる）
別の現場では、ユーザーストーリーのISSUEの大きさと開発ISSUEの大きさが違いすぎて見積もりが全然うまくいっていませんでした。
この本に書いてあるみたいに、モデルの全体像を作ることができなかったし、その重要性をPMには理解してもらえなかった。
今思えば、開発ISSUEをエンジニアでちゃんと話し合ってPMに伝えるべきだったし、見積もり誤ったらどうして誤ったのが全員で考えるべきだったかも。いや、話し合いしたいって申し出てたのに話し合いにならなかったんだけどね！！（ただの文句）
まとめ
今回も読んでて今までの開発の反省点や、今後の開発の仕方をちょっと見つめ直すことができた💫
1on1で上司にこの本を読んでることを伝えたら、「定期的に読み返すほど毎回学びがある本」っておっしゃってて、まさにその通りだなと思いました。
ここまで読んでくださりありがとうございました！
