達人プログラマー 熟達に向けたあなたの旅 第2版

https://gyazo.com/f5b2c9e683c0c3692500cb36350d4e35

序文

ループ不変表明

第1版のまえがきより

曖昧な顧客の要求を実現することについて

方法論のグル達

自分たちの製品なら奇跡を起こせると吹聴 → 営業？

プログラミング言語が最良であると主張 → 分かる

達人プログラマーになるためには？

第1章 達人の哲学

大きなコンテキスト

煮詰まったら席を離れる

2 猫がソースコードを食べちゃった

ドキュメント化

アラートを上げる

属人化のリスク

弁解の代わりに対策

分からないとき

とりあえず言語化する

Slackに投げる

3 ソフトウェアのエントロピー

Tip5 割れた窓を放置しておかないこと

途中でUnitTestを書かなくなるとか

コメントで書いておく

窓が割れていることい気づけない

直すことはできる

とにかく害を及ぼすなかれ

モジュール同士は疎結合

窓が最初に割られたことを知る術

Git

チケットシステム

プロジェクトに入ったばかりであれば気づけないかもしれない

6 あなたの知識ポートフォリオ

安く買い、高く買う

アーリーアダプターになるということ

ゴール

毎年少なくとも言語を1つ学習する

新たな言語を学ぶ→新たなパラダイムを学ぶということ？

月に1冊のペースで技術書を読む

技術書以外の書籍を読む

講習を受講する

近場のユーザーグループに参加する

異なった環境に慣れ親しんでみる

最先端にとどまり続ける

7 伝達しよう

言いたいことを知る

紙に書き殴る？

図を途中まで書いてやめてしまう

必ずしも書く必要はない？

タイミングを選ぶ

話すタイミングを狙ってたら一生タイミングは来ない？

「今言うことじゃないかもしれないけど」と前置きする

スタイルを選ぶ

第2章 達人のアプローチ

8 良い設計の本質

ETC: Easier To Change

9 DRY原則 二重化の過ち

10 直行性

設計

メールアドレスを識別子に使っても良いのかという問題

決定権が誰にあるのかによる？

一意に決まるからOK？

「値」の変更よりも「フォーマット」の変更ができるかどうか

ツールキットとライブラリ

トランザクション指向システム

Google Analytics?

Decoratorパターン

コーディング

関数型だとこの辺りの問題は解決する

テスト

テスト駆動開発

11 可逆性

フェデレーション

複数のインターネット サービス間のユーザ認証連携

12 曳光弾

曳光弾アプローチ = マイクロサービス?

マイクロサービスの方が適用対象が広い

開発チームなどのリソースにも適用される