2021年の私のお気に入りの新譜6選

アーキテクチャは、少数の集中化された人々の頭脳と口からトップダウンで伝えられる独り言である必要はありません。この記事では、分散型でエンパワーメントされた意思決定手法によって推進され、意思決定記録、諮問フォーラム、チーム主導の原則、テクノロジーレーダーという4つの学習と整合メカニズムによってサポートされる、アーキテクチャを行う別の方法について説明します。

商用統合ツールは既に20年ほど前から存在しますが、いつどのようにそれらを使用するかを記述する包括的なアーキテクチャ原則はほとんどありませんでした。この記事では、「購入」決定メカニズムが、そのようなツールの価値提案を誇張し、多くの場合、汎用言語よりも特定の統合ツールを使用することを義務付けることにつながっていることを主張します。そのようなツールは、統合を主にシステムの接続に関するものと見なす世界で繁栄しますが、デジタル組織は統合を主にデジタル機能の前にクリーンなインターフェースを置くこと、システムよりも機能を重視することとして再考している、と私は主張します。最後に、現代的な統合観の背後にある主要な原則の一部を列挙し、それらは汎用言語で最も効果的に管理され、商用統合ツールの主要な価値提案を戦術的な実装に関する懸念事項の簡素化に向けて再方向付けることを主張します。

私の旧友であるデイブ・ファーレイは、ソフトウェア開発に関するますます人気のあるYouTubeチャンネルを運営しています。それは良い素材であり、私の見解と非常によく合致しています。結局のところ、彼の経験は私の思考に大きな影響を与えています。私たちは、ソフトウェアエンジニアリングの現在の役割に関するさまざまなトピックについて話し合い、特に現在私がサポートしている3つの大規模なライティングプロジェクトであるデータメッシュ、分散システムのパターン、レガシー置換のパターンに焦点を当てています。

通常の規模のチーム内では、テクノロジーの種類ごとに代替案の選択肢を3つに制限します。これらは、現在の適切なデフォルト、トライアルとして実験しているもの、そして嫌いになってリタイアしたいものです。

優れた技術設計上の決定は、コンテキストに大きく依存します。共通の目標に向かって定期的に協力するチームは、定期的にコミュニケーションを取り、変更を迅速に交渉することができます。これらのチームは、強い力の整合性を示し、その強い力を利用する技術と設計上の決定を行うことができます。より大規模な組織では、ズームアウトすると、独立して働き、協力回数の少ないチームや部門間に弱い力がますます存在します。これらの強い力と弱い力の違いを認識することで、より良い意思決定を行い、各レベルに適切なガイダンスを提供し、より迅速に移動できるエンパワーされたチームを実現できます。

DevOps文化においてコンプライアンス要件を満たすために必要なセキュリティコントロールと監査機能を統合することにより、CI/CDパイプラインの自動化を活用できますが、組織の規模が拡大するにつれて独自の課題が生じます。選択した実装によって引き起こされる二次的な影響と意図しない結果を理解することが、効果的で安全でスケーラブルなソリューションを構築するための鍵となります。

シップ/ショー/アスクは、プルリクエストの機能と変更の継続的な配信機能を組み合わせたブランチ戦略です。変更は、シップ（レビューなしでメインラインにマージ）、ショー（レビューのためにプルリクエストを開くが、すぐにメインラインにマージ）、アスク（マージする前にプルリクエストを開いてディスカッションする）のいずれかに分類されます。

興味深いソフトウェアは、めったに孤立して存在しません。チームが記述するソフトウェアは通常、外部システムと対話する必要があります。これらは、ライブラリ、外部サービスへのリモート呼び出し、データベースとの対話、またはファイルとの対話です。通常、その外部システムには何らかの形式のAPIがありますが、そのAPIはソフトウェアのコンテキストからはぎこちなく見えることがよくあります。APIは異なる型を使用したり、奇妙な引数を要求したり、私たちのコンテキストでは意味をなさない方法でフィールドを組み合わせたりすることがあります。

ゲートウェイは、この外部システムに対応する単一ポイントとして機能します。システム内のコードはすべてゲートウェイのインターフェースと対話しますが、これはシステムが使用する用語で動作するように設計されています。次に、ゲートウェイは、この便利なAPIを外部システムが提供するAPIに変換します。

講演は、私のキャリアの柱の1つでした。世界中のソフトウェアイベントで基調講演を行いました。これらの講演の中には、YouTubeで数万回、数十万回も視聴されているものもあります。しかし、私は長い間講演を嫌っており、そのため講演から引退することにしました。

テストポートフォリオはピラミッド型にするべきか、ハニカム型にするべきかについて議論があります。この議論に対する私の2番目に大きな問題は、ユニットテストと統合テストの違いが人によってどのように認識されているかが不明確であるため、不透明になっていることです。

開発者生産性プラットフォームは、エンジニアリングチームの認知負荷を管理し、新機能の市場投入までの時間を短縮する方法としてますます認識されています。ただし、プラットフォーム戦略を成功裏に実行するために、組織が育成する必要がある基本的な能力があります。プラットフォームチームは、プラットフォームをソフトウェア製品として考え、ユーザーとの対話、信頼できる運用への注意、そして健全なチーム環境を必要としています。

ファセットを含む、Rでミュートスパゲティチャートをプロットする方法。

あるプロパティの履歴値にアクセスする必要があることがよくあります。しかし、この履歴自体を遡及的な更新に応じて変更する必要がある場合があります。バイテンポラル履歴は、時間を2つの次元として扱います。実際の履歴は、完全な情報の伝達を前提とした履歴がどうなるべきかを記録し、記録履歴は履歴に関する私たちの知識がどのように変化するかを記録します。

人々はコードレビューについて考えるとき、通常は開発チームのワークフローにおける明示的なステップについて考えます。プルリクエストで行われる統合前レビューは、現在、コードレビューの最も一般的なメカニズムであり、多くの人がプルリクエストを使用しないことはコードレビューを行うすべての機会を排除すると無意識に考えているほどです。コードレビューのこのような狭い見方は、多数の明示的なレビューメカニズムを無視するだけでなく、おそらく最も強力なコードレビュー手法であるチーム全体による継続的な洗練を無視しています。

プルリクエストは、githubによって普及したメカニズムであり、特にオープンソースプロジェクトのコンテキストにおいて、作業のマージを促進するために使用されます。貢献者は、中央リポジトリのフォーク（クローン）で自分の貢献に取り組みます。貢献が完了したら、プルリクエストを作成して、中央リポジトリの所有者に、作業がメインラインにマージする準備が整ったことを通知します。ツールは、リクエストを受け入れる前に貢献のコードレビューをサポートおよび推奨します。プルリクエストはソフトウェア開発で広く使用されるようになりましたが、批評家らは、継続的インテグレーションを妨げる統合摩擦の追加を懸念しています。

テクノロジーは常にスマートになり、より強力になっています。私はしばしば、これらのテクノロジーが導入されると、組織の生産性が向上するどころか低下することに気づきます。これは、テクノロジーが開発者の複雑さと認知的オーバーヘッドを増大させ、その有効性を低下させるためです。このシリーズの最初のこの記事では、開発者の有効性を最大限に高めるためのフレームワークを紹介します。研究を通じて、開発者が1日に200回行うマイクロフィードバックループを含む、主要な開発者フィードバックループを特定しました。これらは、開発者にとって迅速、シンプル、そして効果的であるように最適化する必要があります。いくつかの組織がこれらのフィードバックループを使用して、全体的な有効性と生産性を向上させた方法について調べます。

最近の出来事は、民主主義を蝕む嘘に対抗するための真剣な対策を講じる必要性を浮き彫りにしています。