JDDは、コード作成よりも言い訳を事前に考えて、数多くのバグを養成できる開発方法論だ。
JDDは以下の重要な価値観に従う。
我々は
- 他人が使う技術より、自分のものを
- CleanなコードよりはTrickyなものを
- バグFixよりは言い訳を
- 面倒よりは気楽を
価値があると思う。この言葉、左側のものは面倒で、右側のものは便利であるため、より高い価値を持つということだ。
JDDを実践するためには休むことなく険しい道（どう）だが、着実に努力しなければならない。 重要なことは、関連するカッコいい用語を言い出しながら、実際の問題に対する答えを回避することだ。着実な練習が必要だ。
JDDの基礎となる心構えを常に心に留めよう。
眠ったり...いや、真のリーダーは部下をいじめません。
- 誰かがPRをしたこと自体が見事。
LGTM（Looks Good To Me）。
- 誰かがPRを飛ばすと自動的にLGTMを飛ばすCI/CDを活用しよう
- 同僚にはビジネスロジックの重要性を、企画者には開発の難しさを逆説しよう。
その間にman/monthだけを軸内させる。
誰が何と言ったら、「プロジェクト管理」と言おう。
- 昔のやり方にこだわりましょう。
誰が何と言ったら、「ビジネス中心の開発」と言おう
- メンテナンス性は考えないようにしましょう。
誰が何と言ったら、「MVP（Minimum Viable Product）」と言おう
防御的プログラミングはエンジニアの基本的な素養だ。
- 防御的プログラミングをしよう。
コードを書くことで防御しないで、あなたに入ってくるタスクを防御しよう。
- 作業量が多いか？
ただ、特定のテストケースだけ回れるように書いて、残りは「高度化」作業でやると言おう。
「高度化」作業の前に離職しよう。
- 「実装の可能性」とはいうのは他人ではなく結局コードを書く俺が決めることだ。
気楽に企画者にそれは実装不可能だと言おう。
よく働くふりをしながら楽な生活をするために実績重心に行動しなければならない。
並行性は難しく、実績が目立たない。
- マルチスレッド環境での可変変数の使用によるエラーは時々発生する。
時々発生することに比べて使用はとても楽。
誰が何と言えばそんなことないと言えば良い。
- やむを得ずマルチスレッドタスクが渡されたら、プログラミング言語を愚痴ってこのタスクがなんで難しいのか説明しよう。
ああ、この言語はActorモデルが貧弱で...
CSP（Communicating Sequential Processes）実装体がないので...
STM（Software Transactional Memory）がサポートしていないので...
悪口を言うほど締め切り期間が延びる。
- 非同期フロー内で同期関数を密かに書いてもよい。
後でボトルネックを探すタスク+非同期に改善する追加タスク工数まで一緒に貰える。
我々の本分を忘れないようにしよう。
- コメントは絶対に作成しないことにしよう。
誰が何て言ってもクリーンコードを言い出しましょう。もちろんそうだとしてもコードがreadableではない。
- 我々はエンジニアだ。
どんな理由があっても文書作成は禁物。
誰かが何か言ったら「コードがすなわち文書」。
- 履歴は必要ない。
既往は咎めず。
- 引き付きのための文書は必要ない。
誰が何と言えば俺のコードは読めばすぐ理解できるよと言おう。
未練なく脱出しよう。
- GPTの発展速度はすごい。
文書が要る人がしたらもうすぐAIが全部作ってくれるよって言おう。
単語からもう目眩がする。
- Disagree and Never Commit
- 複数人で同時に同じコードを作成しないといけなければ何とかして分けて作業した後マージしようとしよう。
相手も一つのタスクを一緒にくっついて作業するなんて考えてない。
- ブランチのマージ（Merge）中conflictが起こりそうな時点で休みを取るのは必須だ。
- ブランチのマージ（Merge）中conflictが起きたらoursを覚えろ。
俺のブランチが優先だ。
相手が修正した内容を考慮する必要はない。
- ペアーコーディングは意外と大丈夫だ。
自分がコードを書く時は頭をちょっと空かして良くて、他の人がコードを書く時は打ち間違いくらいだけ見つけてあげれば十分だ。
一番のメリットは書かれたコードに対して責任が減るってことだ。
- どんな作業か別に知らせたくなければコミットメッセージは`chore: trivial`としましょう。変態じゃなければこんなコミットを読もうとする人はいないだろう。
- PRをマージ（Merge）する時はSquash mergeを最大限活用して作業中に入った自分がしたバカなことを隠そう。
誰が何と言えば「コミットログを簡略に維持するため」と言おう。
- コミットを分ける時はタスクや機能単位ではなく自分が一気に直した分を基準にしよう。
どうせマージされたら全てSquashされてちゃんと見えない。
- PR Descriptionはタスク管理ツールのtaskリンクだけissueとして入れてあげよう。
もちろんリンクを辿っても説明みたいなもんってないです。
- チーム開発にコミュニケーションスキルは必須だ。
「領域展開口だけの人」で相手を混乱させてPRに自分の怠惰が討論履歴として残らないように対話を誘導しよう。
- 承諾より容赦が簡単だ。
何とか早くマージ（Merge）しないといけない。
- 同僚のコードでエラーや打ち間違い、簡単なミス（重複したへん、チームコードルール、Lintなど）を見つけても共有するな。
同僚があなたが和を守ってることをほのかに気づかせよう。
同僚も自分のミスに目を閉じてくれるはずです。
- コミット（Commit）数が少ないほどコードに天才性が表す。
コミット数が多いって言うのはその間何も考えずコードを書いたってことだ。
コードを修正する度にgit resetコマンドを適切に活用してmasterブランチにforce pushしましょう。コミット履歴には自分だけ残る。
つまり、天才性を独りで占めることができる。
- 分からない技術を勉強しないようにしよう。
同僚が整理した文書だけさりげなく読んでみよう。
結局技術を使わないといけない場合は同僚の時間を奪って一緒にやってほしいって言おう。
誰か何て言えば「チームワーク」と言おう。
- コードレビュー（Code Review）はしないようにしよう。
自分のコードが議論の余地も無く正解。
誰かレビューを頼むとミスのフリをしてマージ(Merge）しなきゃいけない。
- pushを間違った時はreset --hardを愛用しよう。
誰が何て言えばrevertはコミット履歴が汚くなるって言おう。
- PRは非効率的だ。
すぐmasterブランチにマージしよう。
- repository rule設定は開発を遅くする主犯だ。
全ての権限をOnにしとこ。
- サーバーの全てのportはOnにしとこ。
誰かが脆弱だと言ったらIPブラックリストを管理すると答えよう。
- CICDが失敗してもマージしよう。
- API keyは publicに載せても問題ない。
どうせ誰も見ない。
世界は０と1から成り立ってると言える。だから何をするだろうが自分がするのは「プログラミング」ってわけだ。
(下記はto be continue...)
モダンは現在だ。つまり今自分が使ってる技術がすなわちモダンな技術だ。
- 例外処理をしないようにしよう。
誰が何て言えば「Let it crash戦略」だと言おう。
- 言語のFeatureを最大限使わないようにしよう。
誰が何て言えばメンテナンスのため誰でも理解できるように書いたと言い張ったら良い。
- 言語のFeatureを最大限活用しよう。
誰が何て言えばモダンプログラミングだと言えば良い。
- 依存性が複雑になっていたら、「パターン」だと言おう。
- チェーイニング（Chaining）が一つでもあれば、Fluent API スタイル
- チェイニングが一つもなければ、ディミーター法則
- 関数だけ呼び出す関数があれば、ミニー言語でDSLを実装したと言おう
- データを渡す関数があれば、Data-Driven Progirammingだと言おう
- 関数のパラーメーターが多くすぎると？
誰が何て言えばより「純粋」に書いたと言おう
- ラムダ関数だけで構成しよう。誰が何て言えば高階関数関数型プログラミングと言おう。
- パターンを全く使わないようにしよう。
誰が何て言えば「単純性の原則」だと言おう。
- Map-Reduce-Filterみたいな高階関数は一切使わないようにしよう。
誰が何て言えばこれも同じく単純性の原則だと言おう。
Keep it simple, Stupid!
- アノテーションみたいなmeta dataを数十個はつけよう。
誰が何て言えばメタプログラミング記法だと言おう。
- OOP(Object-Oriented Programming)で開発する人々の間ではFPパターン（Functional Programming)を積極的に活用しよう。
ライブラリまで使うとさらに良い。
Maybeクラスを作るのは基本中基本。
誰が何て言えば「これが最近のスタイルです」
- FPで開発する人々の間ではOOPパターンと可変変数を積極的に活用しよう。
誰が何て言えば「FPは実用的ではない」
- 俺のコードより長いと冗長（verbose）、俺のコードより短いと難解（esoteric）
- コールバックヘルを読んでこれ何って言われたらCPS(Continuation Passing Style）だと答えよう。
- 全てのif文は三項演算子で書こう。誰がなんていえば、「あ、ifは文で三項は式ですからね」
- リストコンプリヘンション、オプショナルチェイニング、リアクティブなどを使って誇りを持って言いましょう「モナディックに解決したと」、
それは何と聞かれたら「モナドの呪いのせいで説明が難しい」まで言うのまでやらないと。
- 二つ以上実行されるサービスがあればMSA（Micro-Service Architecture）だ。
テストを回してくれるスクリプトだけ別にあってもMSAだ。
そこに言語が違うとpolyglotまでしたと言える。
俺の言語が優越だ。
- 言語論争には言ったもん勝ちの文章がある「言語は道具だ」
- TypeScript、 CoffeeScript, ClojureScriptなどJSのスーパーセットは一切使わないようにしよう。
誰が何て言えばJSはそもそもそう設計された言語でそれが根本だと言いましょう。
- 何個かの言語はわざわざ自分が文句を言う必要がない。
wtfjs / golang.sucksなど他の人の文句を引用しよう。
どのように設計しても回るには回る。
- クラス、インターフェース、イーナム、メンバーなど構造設計に対してこうだこうだ言っても、ADT(Algebraic Data Type)合型がどうだ掛型がどうだ
- クラスの機能があまりにも少ないと、「あ、それはレコードで書こうとしました。」
- 継承が合成より楽だ。
誰がなんて言えばOOP(Object-Oriented Programming)には当たり前に継承を使うのがあってると言えば良い。
- nullは10億ドルの価値がある。
何でも曖昧だったらnullを返そう。
- ObjectやAnyはポリモーフィズムの極義だ。
何でも曖昧だったらObjectタイプを返そう、Objectタイプを返す関数でnullをリ返すようにするのがベスト
正直テストコードを書くのは面白くない
- テストコードを全く作成しないようにしよう。
誰がなんて言えばreplでテストが終わったと言おう。
- テストがどの場合は成功してどの場合は失敗したら、「attribute基盤テスト」を作成したからそうだと言おう。
- テストコードがなくても、コードがちゃんと動作するってことを自分でちゃんと説明できると言おう。
誰かがテストコードを求めるなら「俺のコードは複雑すぎてテストができない」と言おう
- テストが失敗したら、テストを削除しよう
CPU性能は自分の実力と違って日々発展する。
- DTO/VO変換は使わないようにしよう。
誰がなんて言えばパーフォマンス最適化だと言おう
- DTO/VOはもちろん何のModelも作らない。
みんなMap(Dictionary） data structureを使おう。
誰がなんて言えばData Oriented Programmingだと言おう。
もちろんValidationみたいなものはしない。
- DBはその時必要なフィールドを追加しよう。
正規化とか規則は考えもしないようにしよう。
誰がなんて言えばこれも同じくパーフォマンス最適化
- パターンとかアーキテクチャーは使わないようにしよう。
クラスにも分けるな。
Nのfor文とif文で順次的に書こう。
誰がなんて言えばこれは本当にパーフォマンス最適化だと言おう。
- パーフォマンス最適化はどんな状況でも禁物、誰がなんて言えば最近は「コンパイラー」に任せるのがトレンドだと言おう。
俺が楽になるためにはタスクを最大限自動化しないといけない。
どうせ誰かはそのタスクを担うはず。
これはつまり、それをやる人が自分じゃなければ自動化（Human Automation）を達成したってことだ。
バックエンドはモダンビズネスの核心だ。変なとこに力使うな
- それはフロントエンドがすべきだと言おう。
- それは元々バックエンドがフロントエンドより忙しいと言おう。
- それはDBAがすべきだと言おう。
- それはDevOpsエンジニアがすべきだと言おう。
- それは企画チームでまず企画すべきだと言おう。
- それは運営チームにまず確認をもらうべきだと言おう。
- それはChatGPTにまず確認をもらうべきだと言おう。
フロントエンドはユーザーが向かい合う初印象だ。変なとこに力使うな
- それはバックエンドがすべきだと言おう。
- それは元々フロントエンドがバックエンドより忙しいと言おう。
- それはアプリエンジニアがすべきだと言おう。
- それはパブリッシャーがすべきだと言おう。
- それはデザイナーがすべきだと言おう。
- それはユーザーがすべきだと言おう。
- それはバグじゃなくてイースターエッグって言おう。
- それはデザインが元々そうだと言おう。
DBMSエンジニアを信じろ
- N+1問題が自動で解決できないこの世界がおかしいのだ。エンジニアは気にしなくても良い。
- fetch join + paging問題が自動的に解決できないこの世界がおかしいのだ。エンジニアは気にしなくても良い。
- slow query問題が自動的に解決できないこの世界がおかしいのだ。エンジニアは気にしなくても良い。
- SQL / ORMなどで頑張ってQueryするよりただ全てを持ってきてmap/reduce/filterを使う方が楽だ。
- 正規化はやる必要なくテーブル一つで十分だ。誰が何て言えばjoin費用を節約したと言おう。
最近の機械は適当に教えても自ら良く学ぶ。
- データ一つが大事な時点でValidation setに取ってあげるデータなんてない。全部学習に入れよう。
- 過学習は起きたら寧ろ良い。誰かが突っ込んだら「実験環境ではパーフォマンスが良かったんですけど。」って言おう。
- パーフォマンスが低すぎたらデータが足りないからだと言おう。
- モデルが大きすぎるとDeepLearningって元々そういうものだと言おう。
- モデルが小さすぎるとモデル最適化の結果だと言おう。最適化の副作用によりパーフォマンスが少し落ちる可能性もあるっていうことも添えて言えばさらに良い。
- training時間が長すぎると言われたら、もっと良いGPUを使えば良いって言いながらNVIDIA DGX A100みたいなものを見せてあげよう。
- inference時間が長すぎると言われたら、もっと良いGPUを使えば良いって言いながらNVIDIA V100みたいなものを見せてあげよう。
- ProductizationはDevOps、MLOpsエンジニアの役割だ。モデルリサーチは気にするな。
- Seed値の固定を避けよう。これでパーフォマンスが思ったより出なくてもRandomnessのせいにして時間を稼げる。
ITサービス企画者はサービスの企画及びロードマップ＋協議を主導してプロジェクトを管理する。全部エンジニアに任せれば良い。
- それはエンジニア側ですべきだと言おう。
- それはエンジニアの実力が足りないからだと言おう。
- 間違った企画を立ててもそれはエンジニアが何とか頑張って作れば良いと言おう。
- 企画が変更されてもそれはエンジニアが何とか頑張って作れば良いと言おう。
- 自分の日程は大切だが全体の日程は興味ない。俺だけ残業しなければ良い。
- 普通にPPTを早く作ってエンジニアとデザイナーにタスクを頼んで、説明してあげて逃げれば良い。以降の質問は忙しいって言って最大限避けて休みを取ろう。
- 上からこの案で進めないといけないって決めたって言おう。
- 上から結果物を見て文句言ったらエンジニアたちのパーフォマンスが出ないって言おう。
この文書...正直もうやりすぎたな...
- その日学んだ技術はその日会社のプロジェクトに適用しよう。誰がなんて言えばその日学んだ技術を自慢すれば良い。
- 技術スタックを学ぶのではなく、その技術スタックのデメリットだけ勉強しよう。誰かがその技術スタックに関して聞いたら、デメリットを言い出そう
- dockerみたいな仮想化が少しでも入ったものは使うな。誰が何て言えばネイティブ環境での確認が必要だと言おう
- 簡単な機能だけ書いて一生懸命やってるフリをしてサボろう。誰がなんていえば「�ゆとり」を持って
驚くと思うけど結構たくさん参考した
- Canadian Mind Products
- アジャイル宣言
- プリンシプル オブ プログラミング: 3年目までに身につけたい一生役立つ101の原理原則
- Seven concurrency models in seven weeks
- 폴리글랏 프로그래밍
- Clean Code
- Clean Architecture
- The Joy of Clojure
- Programming Scalar
- FSharp Fun and Profitブログ
- Rovert C Martinブログ
- Martin Fowlerブログ
- wtfjs / golang suck
- Effective Programming: More Than Writing Code
- Data Oriented Programming
- Amazon, 2016 Letter to Shareholders
- その他いつか一回は読んだことある本多数
- Namuwiki
もっと良いくちばし方法を知っていればPRを投げてください。
JDDは何の制約もないです。 ただ、責任も取りません。