GitHubは、日本時間10月30日未明に開幕したイベント「GitHub Universe'24」で、自然言語による指示だけで、パーソナライズされた小規模なアプリケーション（Micro-App）をすぐに生成できる「GitHub Spark」の テクニカルプレビューを発表しました 。
［速報］GitHub、自然言語による指示だけでアプリケーションを生成する「GitHub Spark」テクニカルプレビュー公開 － Publickey
ユーザーがプログラマであれば、コードを参照してカスタマイズすることも可能だと説明されています。
［速報］GitHub、自然言語による指示だけでアプリケーションを生成する「GitHub Spark」テクニカルプレビュー公開 － Publickey
GitHub Sparkはプログラマ向けのサービスではなく、「10億人が開発者になるための支援を行う」という同社が掲げるビジョンを実現するためのサービスという位置づけとなっています。
［速報］GitHub、自然言語による指示だけでアプリケーションを生成する「GitHub Spark」テクニカルプレビュー公開 － Publickey
⇧ AIの生成したソースコードについてカスタマイズや不具合修正をするにあたり、ソースコードをレビューする必要が出てくるのであれば、エンジニアの負担は増えそうね...
リファクタリングとかにより工数が取られないかが懸念されますな...
アーキテクチャ意思決定記録（ADR：Architecture Decision Record）とは
職場の方に連携いただき、「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」というものの存在を知ったのですが、What's ADR ?
ADR process
An architectural decision record (ADR) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re planning to build. Each ADR describes the architectural decision, its context, and its consequences. ADRs have states and therefore follow a lifecycle. For an example of an ADR, see the appendix.
⇧ なるほど、「要件定義」で漏れがちな、背景などを考慮した形で、方針決定、実現に至るまでの軌跡を記録していく感じということですかね。
ADR contents
When the team identifies a need for an ADR, a team member starts to write the ADR based on a projectwide template. (See the ADR GitHub organization for example templates.) The template simplifies ADR creation and ensures that the ADR captures all the relevant information.
⇧ 何やら「テンプレート」があるという話なのだけど、
⇧ これといって定まってない感じなんかね？
う～む、「AWS（Amazon Web Services）」のドキュメントに記載のあった、
『When the team identifies a need for an ADR, a team member starts to write the ADR based on a projectwide template. (See the ADR GitHub organization for example templates.) 』
は、どの「テンプレート」を使えとも明示して無さそうなので、どれを使うかの選定から始める必要がありますと。
⇧ 上記の記載によると、「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」について、最低限、
- title
- status
- context
- decision
- consequences
の5つについての記載は必要そう。
『A “lightweight” ADR consists of title, status, context, decision, and consequences (according to @mtnygard).』のリンクのページを確認したところ、
⇧とありますと。
整理すると、
| No | 項目 | 内容 | |
|---|---|---|---|
| 原文 | |||
| 日本語 | |||
| 1 | Title | - | |
| ADRのタイトル？取扱う課題の粒度に合ったものになるか？ | |||
| 2 | Status | What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.? | |
| ADRの進捗の状態は何か。draftとかもありそう。 | |||
| 3 | Context | What is the issue that we're seeing that is motivating this decision or change? | |
| 現状、問題となっていることは何か。 | |||
| 4 | Decision | What is the change that we're proposing and/or doing? | |
| 課題。問題に対するアプローチは何か。 | |||
| 5 | Consequences | What becomes easier or more difficult to do because of this change? | |
| 結果。課題を解決したことによる状況の変化は何か。 | |||
⇧ というようなことになるんかね？
GitHubのブログによると、
ADRs are not the most common within open source codebases, but have gained more popularity since ~2017 within long-lived, “evolutionary” codebases like those in more enterprise-y settings.
https://github.blog/engineering/architecture-optimization/why-write-adrs/
⇧ 2017年頃から「エンタープライズ」界隈においても「人口に膾炙する」ようになったということみたい。
自分は、不勉強で知らなかったのだけど。
で、「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」を作成することで、どんな嬉しいことがあるのか？
アーキテクチャ決定レコードの概要
ADR は、より信頼性の高いアプリケーションとサービスの実行にも役立ちます。問題が発生した際に、現在の状態の把握と、トラブルシューティングを容易にします。また、ADR は、将来の意思決定の選択とデプロイをサポートする一連のエンジニアリング上の決定も作成します。
https://cloud.google.com/architecture/architecture-decision-records?hl=ja
⇧ とのこと。
ただ、「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」を作るのは良いのだけど、これといった、「テンプレート（雛型）」が定まっていないのが辛いところですな...
ドキュメントのフォーマットが定まっていないと、
なお、工程の名称は、事業者によって呼び方が異なります。同じ名称でも、事業者によって捉え方が異なることがあるため、注意が必要です。工程の捉え方を間違えていると、適切な時期に求めたレベルの成果物ができていなかった、というようなことが発生します。
⇧ 上記のようなことが、また繰り広げられていくような気がしますけども...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
