📖
「ソフトウェアエンジニアガイドブック」メモ
この記事は？
この記事はソフトウェアエンジニアガイドブックを読んだ際のメモとなります
第二部 有能なソフトウェア開発者
エントリーレベルのソフトウェア開発者に求められる一般的な期待値
| 領域 | 一般的な期待値 |
|---|---|
| 範囲 | 非常に狭い |
| 指導 | ある程度指導を受けながら作業する |
| 仕事をやり遂げる | 行き詰まったら助けを求める |
| 率先して取り組む | 必ずしも期待されず、どちらかと言えばおまけ |
| ソフトウェア開発 | チームのプラクティスに従う |
| ソフトウェアアーキテクチャー | チームのプラクティスに従う。設計についてのフィードバックを求める |
| エンジニアリング上のベストプラクティス | 既存のベストプラクティスに従う |
| 共同作業 | チーム内の別の開発者 |
| メンターによる指導 | メンターシップを求める |
| 学習 | 貪欲に学ぶ |
| 一般的な業界経験年数 | 0年〜5年 |
第七章 仕事をやり遂げる
- たとえ他のタスクを断ったり、会議を欠席したり、他の案件を後回しにすることになったとしても、担当している最重要プロジェクトは必ず完遂すべきだ
- 直面している行き詰まりを解消するための第一歩は、自身が行き詰まっているという状況を認識することだ
- 自分自身が行き詰まっていることに気づくには「有意義な進捗がない状態で30分（長くても1時間）続いたら、行き詰まっているのを認める」という経験則が使える
第八章 コーディング
- コードを書くことと読むことについては、どちらかに偏りすぎず、バランスを取らなければならない
- リーダビリティ（読んで理解できること）は、コードのあらゆる特徴の中で最重要なものの部類に入る
- ソフトウェア開発者としてコードを書く際には、どのような問題が起こりうるかを考え、エラー処理に十分な時間と労力をかけるべきだ
- 未知の状態やレスポンスに対しては、処理するのではなく、エラーを発生させるのが正しい対処法だ
第九章 ソフトウェア開発
第十章 生産的な開発者が使うツール
- PRを効果的に活用する方法
- なるべく小さなPRを目指す
- 「なぜ（Why）」と「何（What）」を要約する
- UIが変更された場合、画像を使う
- 対処済みエッジケースとそれ以外のエッジケースについて言及する
- 変更の対象外となるものを明確にする
- PRの概要に対するフィードバックを求める
- 信頼できるソフトウェアエンジニアに最速でなるための方法
- 何かを開発する：コードを書いて問題を解決し、そのコードを本番環境に出す
- フィードバックを得る：作成したソリューションは期待通りに機能しているか？意図した通りに動作し、副作用はないか？
Discussion