メインフレームシステムは、世界のコンピューティングワークロードの多くを実行し続けていますが、増大するビジネスニーズをサポートするために新しい機能を追加することは困難な場合があります。さらに、拡張を遅くするアーキテクチャ上の課題は、それらを置き換えることも困難にしています。リスクを軽減するために、レガシーの置換に段階的なアプローチを使用し、レガシー機能を最新テクノロジーの実装で徐々に置き換える必要があります。この戦略では、メインフレームシステムに継ぎ目を導入する必要があります。これは、ロジックフローを新しいサービスに迂回させることができるポイントです。最近のプロジェクトでは、長年にわたって稼働しているメインフレームシステムにこれらの継ぎ目を導入するためのいくつかの手法を調査しました。

開発者の生産性を測定することは難しい課題です。開発サイクルタイムとスループットに焦点を当てた従来の指標には限界があり、他にどこに目を向けるべきかという明確な答えはありません。定性的な指標は、開発者自身から得られたデータを使用して、開発者の生産性を測定および理解するための強力な方法を提供します。組織は、システムからのデータではなく、人間からのデータを使用して開発者の生産性を測定することを優先する必要があります。

ペアプログラミングの利点は広く受け入れられていますが、ペアローテーションに関するアドバイスは依然として議論の的となっています。チームメイトはいつ、どのくらいの頻度でペアをローテーションすべきでしょうか？そして…毎日ペアをローテーションしたらどうなるでしょうか？私たちは、毎日のペアローテーションの演習を通じて3つのチームと協力しました。ペアリングの利点と課題、およびそれらを解決する方法をチームが反映するのに役立つ軽量な方法論を開発しました。当初の懸念は克服され、チームは頻繁なペアローテーションの利点を発見しました。ペアを頻繁に交換することで、ペアリングのメリットが大幅に向上することがわかりました。ここでは、私たちが開発した方法論、観察結果、参加チームメンバーが共有した一般的な懸念と洞察を共有します。

既存のソフトウェアシステムを置き換える必要に直面した場合、組織はしばしば中途半端な技術置換のサイクルに陥ります。私たちの経験から、レガシーソフトウェアの置換で望ましい結果を意図的に認識し、この置換を分割し、これらの部分を段階的に提供し、変化は不変の現実であると認識するように組織の文化を変えるという、このサイクルを打破できる一連のパターンを学びました。

コミュニケーション技術の向上により、リモートファーストスタイルで働くチームの数が増加しています。これは、Covid-19パンデミックによる強制的な隔離によって促進された傾向です。しかし、リモートで運営されるチームでも対面での集まりからメリットが得られ、数か月ごとに集まる必要があります。

LLMエンジニアリングには、プロンプト設計やプロンプトエンジニアリングだけではありません。この記事では、最近のプロジェクトでLLMアプリケーションのプロトタイプを迅速かつ確実に提供するのに役立ったエンジニアリングプラクティスを紹介します。LLMアプリケーションの自動テストおよび敵対的テスト、リファクタリング、LLMアプリケーションのアーキテクチャと責任あるAIに関する考慮事項に関する手法を共有します。

継続的インテグレーションは、チームの各メンバーが少なくとも毎日同僚の変更と合わせて変更をコードベースにマージするソフトウェア開発プラクティスです。これらの各インテグレーションは、自動ビルド（テストを含む）によって検証され、インテグレーションエラーをできるだけ早く検出します。チームは、このアプローチが配信の遅延リスクを軽減し、インテグレーションの労力を削減し、新機能による迅速な拡張のために健全なコードベースを育成するプラクティスを可能にすることに気づきます。

レガシーシステムを扱う場合、ソースコードを編集せずにシステムの動作を変更できる場所であるシームを特定して作成することが重要です。シームを見つけたら、それを使用して依存関係を解消してテストを簡素化し、可観測性を得るためのプローブを挿入し、レガシー置換の一部としてプログラムフローを新しいモジュールにリダイレクトできます。

2024年のお気に入りの新しい音楽コレクションの6つ