はじめに
セールで半額になっていて、コースの内容見て面白そうだなと思って買ってみました。
思いのほか参考になる部分が多々あったのでまとめます。
気になる方はぜひ講座買ってみてください。
ピーコックアンダーソンのプログラマ仕事の流儀
内容
全部書くわけにはいかないので参考になったとこだけ抜粋します。
1.時間の流儀
- ファーストチェス理論
- 「ファーストチェス理論」という、チェスの名人が「5秒で考えた打ち手」と「30分で考えた打ち手」のうち、86%は同じ打ち手であったことが実証されたことから導かれた理論のお話です。
- 悩んで100％を目指すよりはとにかく早く75点とか80点とかを目指しましょうというお話。
- 2割の時間で8割造り、8割の時間で精度を高める
- 50時間で完成させるべき仕事がある場合は10時間で8割方できている状態にしないとなかなか上手くいかない。後の40時間で精度を高めていく。これが逆だと工数を超過しかねない。
- この考え方は見積にも応用が可能。仮に集中して頑張ってある程度動くプログラムを作るのに16時間(2日)かかる気がするのであればその5倍の80時間(10日)位を見積工数になる。
2.デスクトップはゴミ箱だけにする
- デスクトップは整理しよう
- デスクトップがゴチャゴチャしてる人がよくいるけど基本整理しましょう。
- 特性ごとにフォルダを分ける。
| フォルダ名 | 説明 |
|---|---|
| project | 作業中のフォルダを入れる |
| archive | 完了したフォルダを入れる |
| format | よく使う手元に置いておきたいやつ(申請書・報告書等) |
| shortcut | 共有ファイルやよく使うショートカット等 |
3.保守の流儀
- ソース憎んで人を憎まず
- 昔のコードは質も低くレベルも低い。時代的にもそんなものなので馬鹿にしたり嘆いていても始まらない。 なのでリファクタリングやアーキテクチャを学びどうアプローチを仕掛けていくか学ぶしかない。
- 大がかりな改修があるときに直したいところも直す。テストも一緒にしっかりやる。
- ソフトウェアにメスを入れる勇気も必要→リーダーの仕事。リーダーが責任を持つ。バグってクレームが出ても責任を負うぜって気持ちでやるしかない。
- テストするために実装がある
- 設計は実装のためにあり、実装はテストのためにあり、テストは運用のためにある。
- 実装してからどうやってテストしようはおかしな話。(ウッ。。てなりました。笑)
- テストのことを考えて実装しないといけない。ロジックもそうだけどインフラ的な話も。負荷や限界値は設計段階で決める。
- これがないとテストできないっていうものは、それがなくても動くようにプログラミングする。仮想で何か作ってそこと通信して検証できるような造りにする。
4.質問の流儀
- 相手の頭の中をセットアップしてから話す
- 質問する前にこういうことを話します。という概要を話さないと相手は理解できない。相手は全く違う仕事をしている。その温度差を感じること。
- 質問した人には結果を必ず報告する
- 質問に答えた人も100％大丈夫だとは思ってない。多分これでいいと思うよって感じで答えてる。
- なので実践してみてできたら結果を報告すること。そうすることで答えた人も再認識できる。
- Aさんに聞いて分からないと言われ、Bさんに聞いて教えてもらって出来た場合、Bさんには当然報告する。この時Aさんにも報告・共有すること。結果が分かったのに教えないって、それはやめましょうよ。
- 質問するときは私心を捨てる
- あの人忙しいかなとか、嫌な顔されるかなかそういう思いは捨てましょう。
- どうやって捨てるか。これは仕事なんだと、質問が仕事なんです。
- あなたは仕事として質問するし相手は仕事として質問に答える。
さいごに
講座の内容を振り返りながら、共感したことや参考になったとこを超ざっくり簡単にまとめました。
コース全体も1時間ちょっとしかなく、明日から取り入れられそうな考え方も多いので気になる方はぜひリンクから飛んで見てみてください。
余談ですが、ピーコックアンダーソンの講座セールになってたのでまとめて買っちゃいました。
デザインパターンはいつか全部まとめて欲しいなとは思っていたのでこのタイミングで買えてよかったです。
オブジェクト指向の理解が深まったら勉強してみようと思います。
