Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Debt”と題して講演し、技術的負債のメタファがソフトウェア界に浸透したにも関わらず、いまだ大部分の組織が技術的負債の優先的な返済に苦慮している点を指摘した。講演では、“コードの複雑性とチャーン(churn)の‘ホットスポット’を特定するには”、“コンポーネントあるいはマイクロサービスの‘一時的結合’の調査などにより、現行システムのアーキテクチャの適合性を継続的に評価することのメリット”、“チーム間調整のコストは、バージョン管理システムのコードコミットに関連するソーシャルなメタデータの調査から得られる場合が多い”、といった話題が取り上げられた。Fowler氏の言葉を紹介することから始まった。“金融上の債務と同じように、技術的負債にも利息の支払が必要です。利息は、将来実施される開発に必要な労力という形で現れます。”これに関して、3つの主張が述べられた。技術的負債の金利はシステム開発に費やされた時間の関数であること。すべての技術的負債が同等に作られてはいないということ。技術的負債とコードを作成した組織との間に強い因果関係があることだ。List)’として提案した。金利が高いのはコードベースのどの部分か?アーキテクチャはシステムの進化をサポートしているか?チーム間の調整による生産性のボトルネックが存在するか?最も利息の高い技術的負債を持つコードは、“ホットスポット”分析で見つけることができる。これは大規模で複雑な、あるいはチャーン率の高いコードベースの領域を、視覚的に表現するために使用可能な手法だ。Climateなど、従来のツールで判断することができる。Maatなどのようなツールを使用して取得が可能だ。ホットスポット分析の結果の調査や解析には、MooseやCodeSceneなどの視覚化ツールや分析ツールが利用できる。Farm)”になぞらえて“すべてのコードは同等(equal)だが、一部のコードはさらに同等である”と言うTornhill氏は、一般的ないくつかの言語のコードベース中にあった高いチャーンが、長期的にみればコードのいくつかの領域に(対応する長期にわたって)局所化されるようになったことをグラフィカルに示してみせた。オープンソースの.NETプロジェクトであるcoreclrからファイルgc.cppを引用した説明では、このようなチャーンの局所性が関数/メソッドレベルだけではなく、クラス/ファイルのレベルでも成立することが確認できる。このセクションの結論として、技術的負債の利率を下げるためにはこれら‘ホットスポット’を優先的にリファクタリングするべきであり、その結果として、このようなコードに見られる複雑化の傾向も時間の経過とともに管理されるようになる、という点が示唆された。続いて、“アーキテクチャはシステムの進化をサポートしているか?”という疑問が検討された。システムにはそれぞれ、複雑性が管理不能なまでに増大し、コード修正が極端に難しくなる‘転換点’がある。複雑性を定常的に監視するとともに、転換点を特定して、適切な再設計やリファクタリングで防止することが必要だ。‘一時的結合’の分析は、2つ以上のコンポーネント(クラス、レイヤ、モジュール、マイクロサービス)が絶えず同時に更新されているかどうかを適切に確認する上で、極めて有効な手段となる。同時に更新されるというのは、コード自体の単純な分析からは分からないような、アーキテクチャ上の依存関係を暗示するものだからだ。‘マイクロサービスのショットガン戦略パターン’を特定し、回避しなければならない。アプリケーションへの機能追加や変更が、複数のサービスに対して協調的な変更を常に強いるような時には、アーキテクチャサービスの境界設定が適切でない可能性がある。講演の最後はソフトウェア開発のソーシャルな面にスポットが当てられて、開発者全体の潜在的な生産性とコードベース上での作業により、しばしば多くの‘プロセスロス’が存在することの指摘から始まった。チーム間の調整、あるいは‘責任の分散’は、VCSを使用して、異なるチームの開発者間でコミットのオーバーラップが発生しているコード領域を調査することで測定できる。計測し視覚化する手段として、Tornhill氏はこれを提案している。機能別チーム制の導入はチーム間の調整が必要なコード領域の拡大につながるため、コストが必要であると同時に、標準やスタイルの一貫的な提供の妨げになることも少なくない。技術的負債の増加を抑制するためには、“アーキテクチャと組織の調整”が強く求められる。講演の最後には、データを意識した設計、実装、リファクタリングの実施が強く推奨された。Scene”にもその考え方が反映されている。Debt”のスライド資料は、カンファレンスのWebサイトで見ることができる。Londonのウェブサイトでも確認できます。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。