本章は、この本の執筆に先だち作成した、目次提案用スレッドを掲載します。
あくまで途中経過ですし、今回のα版において、執筆できた項、まだできていない項、冗長なので不要になった項、欠落している項などがあります。しかしながら複数人で編集可能なhackmd.ioを利用して参加者みんなで記入した結果、目次だけでもかなりの分量となりました。α版ですから、まだ追記が必要です。ぜひあなたの知見をお寄せいただきたく、誰でも追記可能です。適宜加筆、あるいは項目を拾って本文執筆をぜひお願いします。
ただこの目次ですが、目次とはいえ、こういうことを考えたほうが良い、という道しるべにもなるかもしれませんし、これだったら書けるかも、という勧誘のきっかけになるかもしれませんので、こちらに掲載します。
興味をお持ちの方は、https://hackmd.io/KnQ710qLTHOlDlvE_ySIcw を合わせて覗いてみてください。 あるいは、親方までご連絡ください。
おもに著者の一人であるえるきち@erukitiさんががっつり修正・追記してくれてこの形になりました。β版ではこの目次をきちんと整理して、より網羅性の高いものに仕上げたいと思います。
目次の作成が大事だけど、構造化したいので、まずはこちらでみんなで書いてみませんか？な意図。
部、章、節、小節、本文のレベルで行きます。
それぞれのレベルで、この下に追記していってください。
また、本文は章レベルで書き始めてもらって構いません。下はあくまで案。みんなで調整してー
順番入れ替えはぜひやってください。三人寄れば文殊の知恵と申します。（誰が書いたかは問わない）。俺はこう思う、で移して構わないですが、書いてあるものを消すのはご注意ください。（下の「どこに入れるか悩むリスト」へ移すはOK。明らかに間違ってれば消すOK）
### まえがき
第1部 最初のやつ(作る前に押さえておくべきほんとに最小限のこと
■chap-appliction.md
# アプリケーションとは
## アプリケーションを作る流れの概要説明
## アプリケーションを作るには何が必要？
### プログラミング
### デザインツール
### ツクールとかHSPとか
### 書けるひといたらUnityとか
### アプリケーションを作る簡易ツール
#### [column] Excelだって立派なプラットフォーム
### 黒い端末
### テキストエディタ・IDE
### バージョン管理システム git
## ファイル
### テキストとバイナリ
### 文字コード
### 謎のフォーマット「ジェイソン」
## スネークケース、ハイフンケース、パスカルケース。キャメルケース
## case intensive / case sensitive
■chap-development-environment.md
# 開発環境を作る（ないと始まらん）
## 言語インストール
## Pythonの開発環境を作る
### Pythonのインストール
### Pythonの開発で必要なツールたち
## Node.jsの開発環境を作る
### anyenv + etc...
## Docker
### NVIDIA Docker
### Radeon Open Compute
## 開発手順書
### 自動で動く開発手順書
## フレームワークという誘惑
## 開発環境のインフラはどうつくる
### 本番とのスペック差
### コスト
### 本番じゃないと動かない機能という強敵
### Infrastructure as Code
開発のための環境が本番環境と違って、一部機能が動かないなどといったことはよくある話ですが、これは決して良いものではありません。個人のDockerでも開発環境でもステージング環境でも本番でも、何かしらのテクニック、たとえばダミーサーバーなどを作るなどして、同じように動くべきです。
## 自転車置き場の屋根の色議論の不毛
### 自動コードフォーマッタ
### Linter
## ロジックの話
どこから持ってくる？参考にする書籍とか古典的な手法とか？
ロジックはいつ決める？
----
第2部 能書きはええんや。作ってみよう
■chap-make-easy.md
# さくっと作る話（日常使いのスクリプトとか）
## ワンライナー
## ちょっとしたスクリプト
## botを作ってみようぜ
botは面白いテーマだし、読者も、抽象論ばかりだと飽きるから、1章独立でとって、
様々なbotの作り方で1章作ってもいいんでは？？？
## ツールを組み合わせる
#### [column] UNIX哲学
## Chrome Devtools
#### [column] Chrome系には3種類のブラウザがある
普段使いのChromeで開発すると不便なことになりやすいので、開発用に、Google Chrome Canary や Chromium も使うと便利というテクニック
■chap-handcopy.md
# 写経する
# 習作する
## お題があると良い
### 競技コーディングという頭のパズル
### お題サイト
（プログラミングの練習するならお題サイトを活用すると良い）
----
■chap-technique.md
# お勧めプログラミングテクニック
## まずは動くことを確認する
### バージョンが正しいことを確認する
#### [column] 問題があったらファイルを消す？リブートする？
## デバッグ
### printデバッグ
### assertion
### デバッガを活用する
### 二分探索式デバッグ法
## 小さなサンプルを作る
### スパイク
## 開発リズムの作り方
### Yak Shaving
#### [column] 同時に2つ以上のことをしない方がいい
## アルゴリズム
* アルゴリズム一つで速度の桁数は何桁も変わる（そもそも桁という単位ではないレベルで変わる）
* アルゴリズムを暗記する必要性はない
----
----
第3部 方法論（基本）
■chap-ui-design.md
# デザイン
## UI
#### [column] UI/UXいうなの話
## デザインはロジカルな作業である
## アクセシビリティ
----
■chap-coding.md
# コーディング
## 関数
## クラス
## 契約プログラミング
## 良いコード・悪いコード・普通のコード
### 名前がすべて
### 読みやすさとは
### DRY原則
### 間違ったDRY原則
### ソースコードコメントは最低限に
#### [column] ライオンさんは言いました
* コードはhow
* テストはwhat
* コミットメッセージはwhy
* ソースコードのコメントは why not
（だったかな）
## 文化圏
### パッケージングシステム
### ベターな書き方。よく使われる書き方
PythonだとPEPとか、RubyならRuby wayとか、そういう、
「界隈でよくあるやつ」
### 誤解を招くやり方、ネーミングを避けよう
----
■chap-testing.md
# 自動テスティング
## ユニットテスト
### テストで一番重要な要素「時間」
## テストモック
## 結合テスト・E2Eテスト
## スナップショットテスト
## 具象テスト（正しい呼び方ではないと思う）
### テストDBを用意して実際にSQL叩くあれ
### 本番データから、個人情報をマスキングして、ステージング環境やテスト環境にコピー
### 画像比較
## 画像認識型テスト (cygamesとかがやってるやつ)
## ランダムテスト
### Haskell Quickcheck
## TDD/BDD
#### [column] TDDという名の「設計論」
## テストファースト
## Power Assert
----
■chap-deploy.md
# デプロイ
## リリース作業どうする？
### CI
## 手順書を作る
## 自動でデプロイできるようにする
### CD
### 差し戻しはどうする？
## Blue/Green deploy
## コンテナという救世主
## ライブラリメンテナンス
----
ガチなやつ
■chap-requirements.md
# 要件
## 解決したいことはなに？
### 業務を改善する
#### 改善したい業務を知る
#### 開発をしないで解決できるかを考える
#### 改善するとインパクトのある業務を改善する
#### 改善したことで他の業務が発生していないかを考える
#### オレオレ改善になっていないかを考える
#### 機能が使われ続けていることを定期的に振り返る
### これまで出来なかったことをする
#### なぜ出来なかったのかを明確にする
#### 実現をすることが可能なのかを調査する
#### 出来た機能を使う人はどのような人なのかをはっきりとさせる。
## 作るのにはコストがかかる
## MVP（試すのに最低限のプロダクト）
### 仮説と検証サイクル
## UX
## サービスを作る
### 新規性は何？
### それが今まで無かった理由
## マネタイズどうする？
## 実は作らなくても解決できるなら、そもそも作らない
## ターゲットは誰？
### プラットフォームどうするの？
## ドメイン分析
### ビジネスロジック
### ユビキタス言語
## ユーザー目線にたつ
### ドッグフーディング（他のところにもあったな）
#### 利用を検討するときのことを考える
#### 利用をしているときのことを考える
#### 利用を終了したくなるときのことを考える
### ユーザーヒアリングをする
#### 実際のユーザーがいるなら会いに行く
#### 近くにいない場合は、アンケートを取る
#### 利用状況のデータから判断をする
* Web、Android、iOS、デスクトップ、組み込み…
■chap-team-development
# チーム開発
## 作業分担
### 分析・要件定義
### 設計
### 詳細設計・コーディング
### デザイン
### 音とかその他（雑でごめん）
## ステークホルダー・プロダクトオーナー
## 組織論
### コンウェイの法則（プログラムの構造は組織に類似する）
### 組織が定める手順
## 作法
### HRT
## Gitなど、共同開発ツールの話
■chap-software-design.md
# 設計論
## プログラミングは全工程が設計そのものである。どこまでいっても設計
## アプリ開発は、コストその他のバーター
## 技術的負債
### 循環的複雑度
### モジュール安定度
## 人類の知恵
### SOLID原則
### デザインパターン
* GoF
* PoEAA
* DSL
#### [column] パターンを暗記するな
### UML
## 境界線を引く
### モジュール
### コンポーネント
### サービス
### レイヤードアーキテクチャ
### モノリシック vs マイクロサービス
## 設計論は大体プログラミング言語に左右されてしまう話
### 手続き型
### OOP
### 関数型
## 型
### ダックタイピング
### 動的型付け言語にも型はある
### 型の魔術
### 型は安心感
## 抽象と具象
### 具象（詳細）の悪夢、昨日の常識は明日の非常識になる
### 詳細決定は、出来うる限り後に回せ
### 抽象化は、必ずしも共通項の括りだしとは限らない
#### [column] 式年遷宮
## スケールアウトとスケールアップ
----
# （どこにぶらさげる？） 開発期間
## 現代のアプリ開発で、1年単位は遅すぎる
# ライセンス・規約
## OSS・フリーソフトウェアのライセンス
## サービス規約
## 法律
### ヨーロッパのアレ
### 資金決済法
# アジャイル
## アジャイル宣言
## アジャイルの源流
### トヨタのKANBAN
### リーン
### エリヤフゴールドラッドのToC（制約条件理論）
## XP
## アジャイルプラクティス
#### [column] アジリティ
## 「アジャイルをやっています」
## よくある誤解
* ドキュメンテーションをサボる？
* 手順がない？
## それ以外の何か？
事前知識として欲しいものを列挙して。
SCRUMとか
----
エモなやつ
# モチベーション
## 作りたいから
### 再発明を恐れるな
#### [column] 今が最良の時代であり最後の時代である可能性
10年後、最後のプログラマが作ったものによって、人類が働く必要がなくなってるかもしれない
ここ数十年の科学進歩は過去数n年にも匹敵する話
だから作りたい気持ちがあるなら、今やらないと絶対に後悔するぞ？
## 新しい技術を試したい
## モチベーションを維持する方法
## モチベーションに頼らない方法
## エンジニアは言葉に厳密であれ
## 趣味で小さいものを作る(作りたい駆動)
### 作りたい駆動でちゃんと作る方法
## 趣味で大きいものを作る(チーム開発的な)
### チームでやるときに必要なもの
## なんのためにアプリ開発するのか?
### 作りたい駆動(中身は何でも良い)
### 不便を解消したい
## 開発メンバーの集め方
1人では難しいから仲間を集めたい…
## アーキテクチャ
### アーキテクチャが重要な理由
### どうやって選べばいいの？
## 実現方法
### やりたいことに対する言語、FW、ライブラリの選定方法
### ライブラリの選定ポイント(枯れてる?開発は活発?デファクトとは?)
## 見積
## モダンなコーディング、レガシーなコーディングって何？
## 開発体制(よい見出しが思いつかない…)
### 1人で
### ペアで
### モブで
これは設計でも使えるので場所が難しい。
両方に書いてもいい。設計と実装でやること違うし、両方に書きましょう。
## 続け方・モチベ維持(超読みたい)
### 新しい技術を学んで全部作り直したくなったとき
Javaで書いてたけどKotlinで書き直したい…とか
## CI/CDって最初からいるもの?
# 第5部 テスト・デバッグ
## TDDとかってこの辺で説明するの？
## テストの方法
## デバッグと一口に言っても…
# 第6部 リリース
## リリースとは
## 公開するだけじゃないよ
## リリースのお作法とアンチパターン
## 利用規約の作成方法
## 宣伝(もっと前の工程?)
# 第7部 運用
## バックアップ
## トラシュー
## エンハンス
## スケール
## 改修(のしやすさは設計?)
# どこに入れたらいいのかわからない話
#### GPL汚染って何？
#### オープンソースって使っていいの？
#### ブログのコードコピペしたらどうなる？
#### 【コラム】実際にプライベートでチーム開発しようとしたら失敗した話(FORTE)
----
# アプリケーション開発最速化理論
## 具象コードの研究と蓄積
## FigmaでUIコンポーネント素振り
----
# アプリ開発とセキュリティ
本章では、アプリ開発時に知っておくべき「セキュリティ」について説明します。
### セキュリティ対策を実行するタイミング
## 開発フェーズごとの「セキュリティ」
テスト（脆弱性診断）だけがセキュリティじゃない。
要件定義から運用まで、セキュリティの対象範囲は広い。
### セキュリティを考えるタイミング
* 要件定義・設計
* 実装
* テスト
* 運用
### 要件定義・設計
#### 危険は元から断つ
#### 言語・フレームワークの選定
#### プラットフォームの構成
#### Webシステム/Webアプリケーションセキュリティ要件書
### 実装
#### セキュアコーディングとは
#### セキュアコーディング規約のススメ
#### セキュアプログラミング講座
### テスト
#### 脆弱性診断
* 自動診断
* 手動診断
#### 誰が実施するのか
* 外部業者に依頼
* 脆弱性診断内製化
#### 外部業者に依頼する場合のコツ
* 診断対象選定
* 料金見積
* 診断前準備
* 診断中の作業
* 診断報告書の見方
* 報告会に臨む前に
* 脆弱性修正工数見積
#### 脆弱性診断内製化支援
* 脆弱性診断士スキルシート
* OWASPテスティングガイド
### 運用
#### 製品の更新
* プログラム言語
* フレームワーク
* CMS
#### セキュアなネットワーク構成
#### ファイアーウォール運用
#### 改竄検知
#### アクセス制御
#### [column] サイドチャネル攻撃
## 実際の開発ではどんなセキュリティを意識すればいいの？
### 機密性(1Confidentiality)
### 完全生(Integrity)
### 可用性(Availability)
### クラウドサービスにおけるセキュリティ注意事項
#### クラウドサービスへのアクセス管理
#### クラウドサービスはどこからでも、誰でもアクセスできる
#### 責任共有モデルと言う考え方
### サーバーレスアーキテクチャ・マイクロサービスアーキテクチャにおけるセキュリティ
#### サーバーレスアーキテクチャ・マイクロサービスアーキテクチャとは
#### サーバーレスアーキテクチャ・マイクロサービスアーキテクチャにおけるセキュリティ注意事項
### ソースコードレベルでのセキュリティ注意事項
#### プライベートリポジトリを利用する
#### 認証キーなどをハードコードしない
#### Webアプリケーションのコードは誰でも見ることができる
#### Gitの履歴は要注意！？
---
## 開発・実行環境はＰＣだけじゃない
### スマフォで始めるWebアプリケーション開発
### スマフォで動くIDE
### スマフォでサーバー管理
# 運営する
# 動作確認
## ドッグフーディング
## カオステスト
## 問題はなに？
### ワインバーグ的な話