ブダペストでのCRAFT会議（4月23〜25日）に参加した印象とビデオレポート

わずか1か月前（4月23〜25日）、 CRAFTの開発者向けの会議がブダペストの栄光の街で開催されました。 運が良かったので、見たものや聞いたものについてレビューを書きました。

この会議は、企業費用でヨーロッパに行くことができるという事実ではなく、ダン・ノース、マイケル・フェザーズ、ブルース・エッケル、エリック・エヴァンス、グレッグ・ヤングなどの招待作家の選択によって引き付けられました。 ハブに彼女の言及がなかったことは奇妙です このカンファレンスは開発者向けのカンファレンスとして発表されたという事実にもかかわらず、それはテクノロジーに関するものではありませんでした。 特定の技術の使用に関するいくつかのレポートがありましたが、ほとんどのレポートは一般的な開発に関するものでした。

会議のモットーは、「Adapt！」という呼びかけです。 この考えは非常に多くのレポートで聞かれました。 したがって、主催者は参加者のパッケージにノートブックを提供しなかったのかもしれません。 =）同時に、彼らはペンを配り、周囲の店でノートを探す必要がありました。

カットシーンの下で、私にとって最も興味深いと思われた説明とビデオレポート。

動画を記事に直接挿入すると機能しなかったため、動画はリンクで表されます。 誰かがビデオ自体の挿入を手伝ってくれたら、感謝します。

私にとっては、最も有用で興味深いレポートのいくつかを強調し、残りを時系列に並べました。

最も有用なおよび/または興味深いレポート（表示することを強くお勧めします）

心配を止めて柔軟なスコープを愛することを学んだ方法（Gojko Adzic）

ビデオを報告する
会議全体のトーンを設定する非常に有益な最初のレポート。 主なアイデア：柔軟なアプローチは、変化する外部世界でのみ適用可能です。 外部の世界がシステムに対して静的である場合、スクラムはwaterSrumfallに縮退し、追加の利益なしでオーバーヘッドコストが発生します。 外の世界があまり知られていないか、急速に変化している場合は、適応できる必要があります。 例として、著者はスーパーバイクトラックでのデビュー中にドゥカティチームの経験を述べています。 危機的な状況では、迅速に適応する必要があるため、すべてが柔軟です。さもないと、生き残れません。

状況に適応する方法として、著者はユーザーストーリーを提供しています。

主なアイデア：ユーザーストーリーから、ロードマップを「 ロードマップ 」として意図した目的で作成および使用する必要があります。 著者は、彼が見たロードマップのほとんどが実際にロードマップではなくトンネルであったと言います 。 トンネルには、一方向のみの移動が含まれ、多くのパスオプションは含まれません。 例として、著者はカーナビゲーターを引用します。 現在の状況を説明する2つの主要な情報ブロックが表示されるため、地上での計画とオリエンテーションに最適です。

1. 次のターンまでの距離。
2. 次のターンの方向。

さらに、著者はTim Harfordの著書Adapt：Why Success Start Always Always With FailureからPalchinskyの原則に進みました： 原則に関する引用へのリンク。

著者は、ユーザーストーリーを使用して、顧客が実際に望んでいることを分析し、プロジェクトの現在の状況に適応する必要があることを示しています。 すべてのストーリーを実現しようとする必要はありません。それは、必要ではないか、非常に高価かもしれないからです。 代わりに、ユーザーストーリーを、プロジェクトの状況が変化したときに選択できる一連の選択肢（ロードマップ）として検討する必要があります。

彼は、「ユーザーストーリーを改善するための50の簡単なアイデア」という本を準備していると言いました。

建築戦争物語（ステファンティルコフ）

ビデオを報告する
「賢い人が愚かなことをするのはどういうことか」というカテゴリーからの報告。 あなたの行動を例と比較してみる価値はあります。 実際のプロジェクトでは、例はすべて重要です。 最後に、著者は「成功したプロジェクトでさえ働いていましたか？」という質問さえされました。 豊富な例と笑える興味深い点があるため、レポートは非​​常に簡単に見えます。

著者は、建築の失敗をからかいます-自分を含め、さまざまな時期にさまざまなプロジェクトで下された決定。 彼は、この決定がどのように生まれたのか、なぜアイデアがクールに見えたのか、なぜアイデアの具体化がひどいものになったのかについて話します。 彼が話すシステムのほとんどは、実際に使用されています。 著者は、そのような問題を回避するために行うことができないこと、またはその逆について簡潔な結論を下します。 いくつかの基本的な論文（すべてを書いたわけではありません-文脈がなければ明確になりません）：

1. キャッシュをキャッシュしないでください。
2. データにはコードの依存関係がない必要があります。
3. 狂気と戦ってください。

ジャックストーン：マスタリーへの旅（ダンノース）

ビデオを報告する -残念ながら、ビデオは約10分から始まります。 第1部では、さまざまな分野の専門家がスキルをどのように実践するかについて説明します。

Masteryへの旅行方法と、Masteryの一般的な内容に関するレポート。 物語は折り紙「Jackstone」の折り畳みに基づいており、著者はこれを15年まで追加できませんでした。

基本的な定義：習熟は文脈における機会です。 このレポートについて完全に語り直さずに何かを伝えることは困難です。 自分のスキルを向上させるトピックに興味があるすべての人に表示することをお勧めします。

ルートでのCAPの承認-ドメインモデル（Eric Evans）

ビデオを報告する
この報告書は私にとって最も期待されたものでした-DDDの3文字について直接聞きたかったのです。 しかし、驚くべきことに、この報告書は会議で最も退屈な報告書の1つであることが判明しました。 また、私はすでにこれについて多くのことを知っていて、報告書からほとんど聞いていないからかもしれません。 エヴァンスは、学術的な口調で、感情なしに話をしました。 聞くのは大変でしたが、その本質は非常に明確に伝わりました。

レポートの最初の部分は、集合体とそのルートを正しく区別することの重要性と、これが将来のシステムのパフォーマンスと存続可能性に与える影響について説明します。 このストーリーは、海上での貨物コンテナの配送と配送スケジュールの調整の例に基づいていました。 彼は、集合体とそのルートの選択に応じて、システムの動作がどのように変化し、それぞれの場合にどのようなレーキが得られるかを示しました。 キーポイント：システムに関する質問を正しく作成し、正規化と非正規化のバランスを取ります。

集合体の状態間の不一致は正常な現象であり、複雑なシステムに存在します。 したがって、このような不整合がシステム内に存在できる期間を管理する契約（SLA）に準拠する必要があります。

レポートの最後で、境界のあるコンテキストについて少し触れました。 コンテキスト間では、Enevtual Consistenceyを使用します。

年代順のちょうど良い興味深いレポート

リアクティブ化：イベント駆動型、スケーラブル、レジリエント、およびレスポンシブシステム（JonasBonér）

ビデオを報告する
リアクティブプログラミングとイベント指向開発の原則を紹介しています。 著者は、リアクティブプログラミングの主な問題は大きなエントリーしきい値であると言いますが、このしきい値を克服した後、アプローチは明白でシンプルになります。 キーポイント：

1. 常に弱いバインディングを使用します。
2. ロックがまったくないように設計する必要があります。
3. 最初に非同期相互作用を設計する必要があります。
4. アクターはメッセージングを通じてのみ通信します。
5. シェアードナッシングアーキテクチャの使用。
6. ロケーションの透明性。

敏ility性とソフトウェアアーキテクチャの本質（Simon Brown）

ビデオを報告する
無料では何も起こりません。 アーキテクチャソリューションに料金を支払う必要があるため、完全な抽象アーキテクチャはありません。 （システムのような）アーキテクチャの柔軟性は、常に相対的で時間に依存します。 したがって、常に探索して適応する必要があります。

さまざまな利害関係者のさまざまな関心のため、1つの普遍的な図を作成することは不可能です。 ダイアグラムのセットは、さまざまなスケールのマップのセットと見なされる必要があります。この場合、抽象化のセットは表記法のセットよりもはるかに重要です。 C4モデルを使用することが提案されています。

1. システムコンテキスト
2. コンテナ
3. 構成部品
4. クラス

コンポーネントで考え、クラスで実装する必要があります。 これらの2つの観点を区別することが重要です。 結論として、レポートの作成者からの重要なメッセージ： アーキテクチャを開発者に返してください！

優れた開発プロセスとは何ですか？ （ブルース・エッケル）

ビデオを報告する
一般的な開発プロセスの品質の収集元に関するレポート。 コード作成だけでなく、プロセス全体。 復venが50分の自由時間の場合、レポートを表示できます。 主な点は明らかであるにもかかわらず、それらはどこにも適用されず、結果が良くありません。 KOブロードキャスト：

1. リポジトリを使用したバージョン管理、テスト可能なすべてのテスト、およびテストを含む複数回行われるすべての自動化。
2. プロジェクトの全期間を通じたコミュニケーション、 誠実さ 、 透明性 。 まず、顧客の前に。
3. 最小の貴重な製品（最小の貴重な製品）でリリースします。 ただし、開発者にとってではなく、顧客にとって価値のある製品を作成する必要があります。 これに基づいて、特定の問題を解決する際に優先順位を構築する必要があります。
4. 継続的なバージョン更新のメカニズムとしての自動連続配信（Continuous Delivery）。 これにより、MVPの最初のバージョンをできるだけ早くリリースし、最も重要な機能をさらに洗練させることができます。
5. 間違いは避けられません。 彼らは学び、適応する必要があります（再び、「Adapt！」）。
6. BrainStormingはBrainWritingに置き換えられます。 BrainWritingでは、参加者は自分の意見を書面で書き、全員が集まって話し合います。 これはBrainStormingよりも優れています。なぜなら、最も騒々しい人だけでなく、誰もが話すことができるからです。
7. ほとんどの場合、最も理解されサポートされているソリューションが最良の選択です。
8. CodeReviewを行う必要があります。

マクドナルド、シックスシグマ、およびオフショアアウトソーシング：予想外の情報源（Chad Fowler）

ビデオを報告する
開発者になった元サックス奏者からの報告。 会議の2日目の紹介レポート。開発世界全体に関するものです。 開発のインスピレーションと勇気、ソフトウェアの品質、低品質のソリューションを生み出す開発者と顧客の見解と目標の矛盾について。

著者は、 シックスシグマに関するストーリーの誓約で開発プロセスについて言及しています。機能は顧客にとって重要であり、フォームは開発者にとって重要であるということです。 内部品質と外部品質の対立が常にあります。 ここでは、内部の品質が外部ではなく、常に決定するため、バランスを取る必要があります。 そして、この「常にではない」ことを識別できなければなりません。

ソフトウェアエンジニアリングの職人技を責任を持って最大化する（Theo Schlossnagle）

ビデオを報告する
ソフトウェアはダメ。 レポートの残りの部分は、この論文の説明と、そうである理由の検索です。 主な理由：

1. 高品質のソフトウェアの開発は非常に難しい作業です（実際には不可能です）。
2. エンジニアは「伝統」の影響を受けます。 ここでは慣例であり、機能するので、触れないでください。
3. 開発者は学術文献を読んでおらず、基礎も知りません。
4. 企業内のプロジェクトやプロジェクトでさえ、ベストプラクティスを共有していません。
5. エンジニアは完全に自律的に作業しますが（小規模なプロジェクトでは）、大規模なプロジェクトでは問題が発生します。
6. 多くの場合、リファクタリングするよりもゼロから記述する方が簡単ですが、ほとんどの場合リファクタリングすることを好みます。

ポリグロットデータ（グレッグヤング）

ビデオを報告する
従来の正規化されたデータベースに対するイベントソーシングアプローチの利点について報告します。 すべてのDBMSがひどい（すべてのデータベースがひどい！） しかし、それぞれが独自のユニークな方法で吸い込みます。 したがって、特定のタスクごとにこのタスクに適したツールを使用する必要があります。 状態の代わりにイベントのフローを保存すると、これが可能になります。 特定の論文を強調することに成功しませんでした。これは会議2日目の最後のレポートでしたが、レポートを見る価値はあります。

まあ、時間の価値がないレポート

テストに適した抽象化レベルを見つける（Gerard Meszaros）

ビデオを報告する
私にとって、このレポートは、キャプテンのエビデンスの啓示のカテゴリーからのものでした。自動テストを最も自律的にすることです。 テストでは、適切な抽象化レベルで機能の1つの粒子をテストする必要があります。 間違った抽象化レベルを選択した場合、UIの品質を評価するにはUIを調べる必要があるため、UIのテストの自動化は不可能です。

データ駆動型ソフトウェアエンジニアリング（Jevgeni Kabanov）

ビデオを報告する
奇妙なレポート。 開発者の生産性レポートの統計スライドセット

アジャイル世界のデータベースとスキーマ（Andrew Godwin）

ビデオを報告する
本当に柔軟なデータベースを作成する方法に関するレポートから、いくつかの神聖な知識を期待していましたが、すべてがつまらないものであることが判明しました。

1. PostgreSQLを使用するのは、スキーマを変更するときに最小限のダウンタイムとロックを与えるためです。
2. スキームは、トランザクションのフレームワーク内でのみ変更する必要があります。
3. まあ、彼は、ハイブリッド（型付き列のデータの一部、およびxmlまたはその他の形式のblobフィールドの残り）スキームを使用して、柔軟性と速度を最適化することを提案しています。