ストリートコーダー (Sedat Kapanoglu)

書籍情報

• 著者:Sedat Kapanoglu(著), 高田新山(訳), 秋勇紀 (訳), 水野貴明 (監訳)
• 発行日:2025-02-26
• ISBN:9784798073453
• URL:https://www.shuwasystem.co.jp/book/9784798073453.html

書籍目次

• まえがき
• 謝辞
• 本書について
• 著者について
• 日本語版のためのまえがき
• 監訳者まえがき
• 訳者まえがき
• Chapter 1 現場へ
  • 1.1 現場で大事なこと
  • 1.2 ストリートコーダーとは？
  • 1.3 優れたストリートコーダー
    • 1.3.1 探究心がある
    • 1.3.2 結果主義であること
    • 1.3.3 高いスループットを実現する
    • 1.3.4 複雑さと曖昧さを受け入れる
  • 1.4 現代のソフトウェア開発における問題
    • 1.4.1 技術が多すぎる問題
    • 1.4.2 パラダイムの上を滑空する
    • 1.4.3 テクノロジーのブラックボックス
    • 1.4.4 オーバーヘッドの過小評価問題
    • 1.4.5 自分の仕事ではないという考え方
    • 1.4.6 つまらないことは素晴らしいこと
  • 1.5 本書で取り扱わないこと
  • 1.6 本書のテーマ
  • まとめ
• Chapter 2 実践理論
  • 2.1 アルゴリズムの短期集中講座
    • 2.1.1 Big-Oは、よいに越したことはない
  • 2.2 データ構造の中身
    • 2.2.1 文字列
    • 2.2.2 配列
    • 2.2.3 リスト
    • 2.2.4 リンクリスト
    • 2.2.5 キュー
    • 2.2.6 辞書
    • 2.2.7 ハッシュセット
    • 2.2.8 スタック
    • 2.2.9 コールスタック
  • 2.3 なぜ型が重要なのか？
    • 2.3.1 型を重視する
    • 2.3.2 妥当性の証明
    • 2.3.3 むやみにフレームワークを使わず、賢く使う
    • 2.3.4 タイプを活用してタイポを防ぐ
    • 2.3.5 null許容型と非許容型
    • 2.3.6 コストなしのパフォーマンス改善
    • 2.3.7 参照型 vs 値型
  • まとめ
• Chapter 3 役に立つアンチパターン
  • 3.1 壊れてないなら、壊してみろ
    • 3.1.1 コードの硬直性に対処する
    • 3.1.2 素早く行動し破壊せよ
    • 3.1.3 境界を守ることの重要性
    • 3.1.4 共通機能の分離
    • 3.1.5 Webページの例
    • 3.1.6 負債を残さない
  • 3.2 一からコードを書き直せ
    • 3.2.1 消して書き直す
  • 3.3 壊れていなくても修正する
    • 3.3.1 未来に向かって突き進む
    • 3.3.2 清潔さは読みやすさの次
  • 3.4 重複せよ
    • 3.4.1 再利用かコピーか？
  • 3.5 自前主義
  • 3.6 継承を使わない
  • 3.7 クラスを使用しない
    • 3.7.1 列挙型は最強！
    • 3.7.2 構造体最高！
  • 3.8 バッドコードを書いてみよう！
    • 3.8.1 if/elseを避ける
    • 3.8.2 gotoを使う
    • 3.9 コードコメントを書かない
    • 3.9.1 適切な名前を選ぶ
    • 3.9.2 関数を活用する
  • まとめ
• Chapter 4 おいしいテスト
  • 4.1 テストの種類
    • 4.1.1 手動テスト
    • 4.1.2 自動テスト
    • 4.1.3 危険な行為：本番環境でのテスト
    • 4.1.4 適切なテスト方法の選択
  • 4.2 不安をなくし、テストを愛する方法
  • 4.3 TDDなどの頭字語を使わない
  • 4.4 自身のためにもテストを書こう
  • 4.5 テスト対象の決定
    • 4.5.1 境界を大事にする
    • 4.5.2 コードカバレッジ
  • 4.6 テストを書かない
    • 4.6.1 コードを書かない
    • 4.6.2 全てのテストを書かない
  • 4.7 コンパイラにコードをテストさせる
    • 4.7.1 nullチェックの排除
    • 4.7.2 範囲チェックの排除
    • 4.7.3 有効な値チェックの排除
  • 4.8 テストの命名
  • まとめ
• Chapter 5 やりがいのあるリファクタリング
  • 5.1 なぜリファクタリングをするのか？
  • 5.2 アーキテクチャの変更
    • 5.2.1 コンポーネントの特定
    • 5.2.2 作業とリスクの見積もり
    • 5.2.3 偉業
    • 5.2.4 リファクタリングを簡単にするためのリファクタリング
    • 5.2.5 最終段階
  • 5.3 信頼のおけるリファクタリング
  • 5.4 リファクタリングすべきでない場合
  • まとめ
• Chapter 6 セキュリティを精査する
  • 6.1 ハッカーの上を行く
  • 6.2 脅威モデリング
    • 6.2.1 ポケットサイズの脅威モデル
  • 6.3 安全なWebアプリを書く
    • 6.3.1 セキュリティを考慮した設計
    • 6.3.2 隠蔽によるセキュリティの有効性
    • 6.3.3 セキュリティメカニズムを自作しない
    • 6.3.4 SQLインジェクション攻撃
    • 6.3.5 クロスサイトスクリプティング
    • 6.3.6 クロスサイトリクエストフォージェリ（CSRF）
  • 6.4 先に洪水を招いた者訳注17 206
    • 6.4.1 CAPTCHAを使用しない
    • 6.4.2 CAPTCHAの代替手段
    • 6.4.3 キャッシュを実装しない
  • 6.5 シークレットの保管
    • 6.5.1 ソースコードでのシークレットの保管
  • まとめ
• Chapter 7 能動的な最適化
  • 7.1 正しい問題を解決する
    • 7.1.1 シンプルなベンチマーク
    • 7.1.2 パフォーマンス vs 応答性
  • 7.2 遅さの解剖学
  • 7.3 トップから始める
    • 7.3.1 ネストされたループ
    • 7.3.2 文字列指向プログラミング
    • 7.3.3 「2b || !2b」を評価する
  • 7.4 ボトルネックの解消
    • 7.4.1 データを詰め込まない
    • 7.4.2 近場で買い物を済ませる
    • 7.4.3 依存関係のある処理を分離する
    • 7.4.4 予測可能にする
    • 7.4.5 SIMD
  • 7.5 I/Oにおける1と0 244
    • 7.5.1 I/Oをより速くする
    • 7.5.2 I/Oをブロックしない
    • 7.5.3 古の方法
    • 7.5.4 モダンなasync/await
    • 7.5.5 非同期I/Oの落とし穴
  • 7.6 奥の手としてキャッシュを使う
  • まとめ
• Chapter 8 好まれるスケーラビリティ
  • 8.1 ロックを使わない
    • 8.1.1 ダブルチェックロッキング
  • 8.2 不整合を受け入れる
    • 8.2.1 恐るべきNOLOCK
  • 8.3 データベースコネクションのキャッシュを避ける
    • 8.3.1 ORMを使うと？
  • 8.4 スレッドを使わない
    • 8.4.1 非同期コードの落とし穴
    • 8.4.2 非同期によるマルチスレッド化
  • 8.5 モノリスを尊重せよ
  • まとめ
• Chapter 9 バグとともに生きる
  • 9.1 バグを修正しない
  • 9.2 エラー恐怖症
    • 9.2.1 例外の嘘偽りのない真実
    • 9.2.2 例外をcatchしない
    • 9.2.3 例外からの回復力
    • 9.2.4 トランザクション抜きでの回復力
    • 9.2.5 例外 vs エラー
  • 9.3 デバッグをしない
    • 9.3.1 printf()デバッグ
    • 9.3.2 ダンプの海へ
    • 9.3.3 ラバーダックデバッグ上級編
  • まとめ
• 訳者あとがき