アート・オブ・アジャイルデベロップメント読書会 6.6 コーディング標準
===
###### tags: `アートオブアジャイルデベロップメント読書会`

[読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view)

# Discord開始位置

* [connpass募集ページ](https://agiledevs.connpass.com/event/221299/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [discord:2021/08/15](https://discord.com/channels/767540649418686486/774111081634332673/785112149344780289)

# 自己紹介

- ファシリ役
-
- 読み上げ役
-

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

[アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu)

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はアジャイル非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:30- | - | もくもくタイム（hackmd書き込み） | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:45 | 70分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:45-21:50 | 5分 | [miro](https://miro.com/welcomeonboard/OW54WlJIZ3pKQlBwbUtTc0p3d1Y3UlJOWWgycGx4S2ZLZGpyUGtVeXRCOG1HUUs3QnJVREwzY29LOTJnSU1UeXwzMDc0NDU3MzQ3NTg1MTI4OTMx)を使ってふりかえり | |
| 21:50-21:55 | 5分 | 次回開催日と読む範囲決めてクローズ | |

# 下に感想などを書いていって下さい。どんな些細なことでもOKです。

### 目安の時間

- 1トピックにつき10分を予定しています
- 盛り上がったら延長することもあります

## 疑問・参加者に聞いてみたいこと

- [角さん翻訳のXP白本](https://www.amazon.co.jp/%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-%E3%82%B1%E3%83%B3%E3%83%88-%E3%83%99%E3%83%83%E3%82%AF/dp/4274217620/ref=pd_lpo_1)だと、「コーディング標準」というプラクティスが無くなっているように見えます。理由をご存じの方がいらっしゃれば知りたい。（以下は書籍の目次抜粋）
**第7章 主要プラクティス**
- 7.1 全員同席（Sit Together）
- 7.2 チーム全体（Whole Team）
- 7.3 情報満載のワークスペース（Informative Workspace）
- 7.4 いきいきとした仕事（Energized Work）
- 7.5 ペアプログラミング（Pair Programming）
- 7.6 ストーリー（Stories）
- 7.7 週次サイクル（Weekly Cycle）
- 7.8 四半期サイクル（Quarterly Cycle）
- 7.9 ゆとり（Slack）
- 7.10 10 分ビルド（Ten-Minute Build）
- 7.11 継続的インテグレーション（Continuous Integration）
- 7.12 テストファーストプログラミング（Test-First Programming）
- 7.13 インクリメンタルな設計（Incremental Design）
- 7.14 それから……

**第9章 導出プラクティス**
- 9.1 本物の顧客参加（Real Customer Involvement）
- 9.2 インクリメンタルなデプロイ（Incremental Deployment）
- 9.3 チームの継続（Team Continuity）
- 9.4 チームの縮小（Shrinking Teams）
- 9.5 根本原因分析（Root-Cause Analysis）
- 9.6 コードの共有（Shared Code）
- 9.7 コードとテスト（Code and Tests）
- 9.8 単一のコードベース（Single Code Base）
- 9.9 デイリーデプロイ（Daily Deployment）
- 9.10 交渉によるスコープ契約（Negotiated Scope Contract）
- 9.11 利用都度課金（Pay-Per-Use）
- 9.12 結論
- ↑ この本のv2 でも無くなってしまってますね。残念
https://www.jamesshore.com/v2/books/aoad2
- https://www.jamesshore.com/v2/books/aoad2/alignment に記述があります:+1:
- P27に対比表があり、そこではXpの第1版にはあり第2版には対応しているものがないみたいですね
- みなさんのコーディング規約上手くいった例を聞いてみたいです:+1::+1:
- みなさんのコーディング規約上手くいかなかった例を聞いてみたいです:+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/876425292795768862)

- どの層に何を書くのか、というのもコーディング標準？:+1:
- Gateway層のInとOutはドメイン型にしておき、HttpとかDB接続とかっていう都合は出さない、とか

## 感想・気づき

- 99語整理
> In team software development, we create a collective work that is greater than any individual could create on his own. Arguing about style gets in the way.
When creating a coding standard, your most important achievement will be learning how to disagree constructively. To succeed, create the minimal set of standards you can live with. Focus on consistency and consensus over perfection. Remember that few decisions are irrevocable in agile development.
Assume your colleagues are professional and well-meaning. If they deviate from the standard, discuss reasons rather than placing blame. No coding standard can substitute for professional judgement.
> チームによるソフトウェア開発では、一人では作れないような大きな作品を作り上げることができます。スタイルについて議論することは、その妨げになります。
コーディングスタンダードを作成する際には、建設的な意見の出し方を学ぶことが最も重要な成果となります。成功するためには、自分が納得できる最小限の標準を作ることです。完璧さよりも、一貫性やコンセンサスを重視しましょう。アジャイル開発では、取り返しのつかない決定はほとんどないことを覚えておいてください。
同僚はプロであり、善意であると仮定する。もし彼らが標準から外れた場合、責任を負わせるのではなく、理由を話し合いましょう。どんなコーディングスタンダードも、プロの判断に代わるものではありません。
- コーディング標準を大事にしようという話だと思ったら、だいぶ違った。コーディング標準という例を使って、チーム合意の話をしてる印象を受けた。:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/876437129348128818)

### 6.6.1 書式より大事なもの

- 書式スタイルは現代だとLintとかIDEのFormetterを使うことで解決しそう
- というより、そこに議論を掛けたくない:+1::+1::+1::+1:
- 誰かが決めるより、第三者になるツール任せにするのが平和的解決になると思います。人が決めると、その後も「この場合は？」が出続けるので。
- 開発ツールにこだわりがある人が自分独自のツールにこだわり、その結果他の人がかけてる構文チェックなしで出してくると面倒。
- （githubを利用しているなら）github actionsで（変更があったファイルのみ）push/pull request時にformatterを実行させると一応縛れますが...
- そういえば、本の共同執筆も textlint に任せよう！っていう話を聞いたことあった。

- > ただし、コーディング標準をまとめるときは、フォーマットについて議論するという罠にはまらないでください。
- 見た目だけだと、shell で snake と camel 混ぜたのを渡された時とかあった。そのレベルなら、今後のルールだけ(Google式にしよう、など)決めて、全部揃え直すような対応しないのも良いと。
- ルールを決めても、破る人(気にしない人)は破り続けるので。
- 後半書いていましたが、破る人はなんで破るのかっていう問いかけは、いずれやってみると良いのかもしれませんね:+1:
- フォーマットは読みやすい、書く時に迷わないのが大事であって、それが達成できているなら良いと考えるのもひとつなのかもしれない。

- > オブジェクト間ではnull参照を渡さないということに合意した。
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/876439150444830780)
- コーディングというと、書き方のお作法的なものが中心だけど、こういったものもすごく大切。トランザクションの跨ぐ層はどこまで許容とか、APIのJSONレスポンスは必ずモデル->DTOに詰め変える(冗長に見えても)かどうかとか、場所によって考え方様々だった。:+1::+1::+1::+1::+1:

### 6.6.2 コーディング標準の作り方
- > コーディング標準を作るのは合意を得る練習になる
- この考えはしたことなかったな
- > 前向きに議論を唱える
- コーディング規約に限らず、めちゃくちゃ大事なこと。。:+1:
- その議論のために以下のものを決めるのめっちゃいいな:+1:
> 受け入れられる必要最小限の標準を作ろう
> 完全であることよりも、一貫性と意見の一致を重視しよう
- コーディング規約は重箱の隅を突くようなものを作りがちなので、これすごい大事だと思う・・・！:+1::+1::+1:
- コーディング標準ミーティングはやったことないが、気になるコードを見かけたときはふりかえりの場で議題に挙げて議論を時々やる
- ふりかえりの場で話していくと、その標準を考える理由とか含めた納得感とともに合意できそう。

- 都度気になったときにチームに確認していってるので、議論で決まったばかりの標準はフリップボードに書いておくってのはやったことなかった。大体その場の議論で決まったことをすぐコードに反映されるので
- 議論の経緯はたまに見直したくなるので、チケットのコメントなど何かしら残しておきたい派

- 親指投票はよくやる。手っ取り早くお気持ち表明できるし、その後どうしてそう投票したのかって深堀りするタイムになるので良い
- うまく言語化できてない懸念など切り捨てられることがあるので、合わなかったというケースもある

- > やがて、標準のいくつかは習慣になるだろう。もっと重要な問題のためのスペースを空けておくために、習慣になったものは消してしまおう。(p.141)
- 形式知が暗黙知に変わっていくの、なんとなく違和感と忌避感を覚えてしまう。オンボーディングプロセスなど、形式知として復活する機会があるのならいいのだろうか？ 誰もがその理由を忘れてしまって形骸化する危険性を懸念してしまう:+1:
- 頻繁にチームに人が出入りすることが可能であれば、都度言葉で説明することでチーム内で共有はできそうな感はありました
- わかる一方で、規約の総数を減らしてかないと多すぎて読むのしんどい問題もあり、悩ましい
- 消すという決断難しそうだなーとは思いました

### 6.6.3 意見の不一致に対処する

> すべての議論に勝つ必要はないということを悟ったときが、私のプログラミング人生の転機だった
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/876431042116980756)
- これはわかるなぁ。別に間違っていてもまた議題に上げて別の方法を考えればいい、という余裕はある
- この節の話、短いけどコーディング規約以上にめちゃくちゃ大事なことが書いてある。。
- 議論は一致しないけど、とりあえずやって答え合わせしよう！という姿勢になれるか！というのがアジャイルでめちゃくちゃ大事だと思う:+1::+1::+1::+1::+1::+1::+1:
- この章に関連した著者のブログも面白かったです。要約すると、「一貫性は大事だけど、どの一貫性かは大事ではない。揉めたなら折れてみよう。それは自身にとってどう転んでもいい」:+1::+1:
- https://www.jamesshore.com/v2/blog/2008/get-a-life
- 面白い！紹介ありがとうございます！

> アジャイル開発では取り消せないような決定はほとんどないということを思い出そう :+1::+1::+1::+1:
- めちゃくちゃいいこと書いてあるけど初見！！笑 最初にはどこの章に書いてあったんだろう？

### 6.6.4 標準を遵守する

- 節のタイトル通りの話というよりは、遵守できない場合の（チームの軋轢を出さない為の）疑義の投げ方を解説してくれている感じがする:+1:

> 　効果的なやり方というものはほとんどない。ソースコードがコーディング標準を遵守しているか自動的に チェックするツールを使っているチームもある。バージョン管理システムにチェックインするときにファイ ルの書式を再設定するようなプログラムを使っている人もいる。私はどちらのやり方も好きじゃない。後者は、プログラマの判断が信用できないと言っているようなものだし、前者は間違った警告が出ることが多いためだ。
- 人が指摘するより機械的に判断したほうが棘がなくてやりやすい経験則があります:+1::+1::+1::+1:

- この節の提案の仕方、大人すぎる・・・！こんなエンジニアばかりであればなんと平和な職場だろうか。すばらしいなー:+1:

### 6.6.5 質問
> 大規模な書式変更を適用するために、自動化ツールを使ってもいい。... 私はこうした作業を行う直前、直後でインテグレーションしておくのが好きだ。書式変更は他の変更箇所を分からなくしてしまうことが多いためだ。
- すごくわかる。普通のチケットのコミットと混ぜられて何をレビューすべきか混乱して無駄なやり取りが発生することがあり、別タスク(最低でも別コミット)にしてと要望を何度か出す羽目に...

### 6.6.7 使用上の注意

- 「標準で揉めて、やりたいことを見失うな！」がキーメッセージなんですね。

----

## ミニエチュードの質問
* ミニエチュードは、このプラクティスに対して気づきを得るための質問です
* 詳細はP76ページを参照してください
* 以下の質問に、回答を継ぎ足していってください

### (このプラクティスを使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- これまで経験したものとどう違うか？
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？

### (このプラクティスを使っているなら)
- 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- もし書かれているとおりに従うと、何が起こると思うか？
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)