【Break Production Less】Codecovのプレリリース・フォーカスの紹介
テストプラクティスとツールの改善を支援しようとするソリューションは、世の中にたくさんあります。 しかし私たちは、高品質なソフトウェアは、テストがいかにうまく行われているかに限らないと考えています。 そのため、私たちはコードカバレッジの枠を超え、バンドル分析、テスト分析、AIを活用したコードレビューを備えた初のプレリリースプラットフォームの基盤を構築しています。 JavaScriptバンドル分析 バンドルサイズが重要なのは、アプリケーションのパフォーマンス、帯域幅の使用量、ロード時間に直接影響するからです。 バンドルが大きいとロード時間が長くなり、パフォーマンスが低下し、ユーザーエクスペリエンスが低下します。私たちは、開発者がこのような課題に立ち向かえるよう、JavaScript バンドル解析を展開しています。 私たちのBundle Analysisは、Rollup、Vite、Webpackと連携し、エンドユーザーに影響を与える前に問題を診断するのに役立ちます。 今すぐ Bundle Analysis を試して、GitHub issue で感想を聞かせてください。 バンドル解析はすべてのCodecovユーザーが無料で利用でき、ほとんど設定なしで動作します。 テスト分析 欠陥のあるテストや、CIの実行に時間がかかるテストは、デプロイ失敗のリスクを高め、新機能を迅速にデリバリー（リリース）することを難しくします。 そこで、テストの実行時間や失敗率のデータを提供し、不安定なテストを特定する Test Analytics を紹介します。 テストの失敗に関する洞察を GitHub 内で直接提供することで、コードの行をスクロールすることなく、テストに欠陥がある箇所や失敗している箇所を確認することができます。これによって、問題の発見と対処がより速くできるようになります。😏 Codecov PR Commentでテストの失敗情報を取得するには、テスト結果をJUnit XMLファイルとして生成し、そのファイルをCodecovにアップロードするだけです。 Test Analyticsを使い始めるには、こちらのドキュメントをご覧ください。 テスト失敗レポートは現在稼働中ですが、私たちはテスト管理プロセスを改善し、コードレビューのサイクルをスピードアップするために、Flaky Test Detectionを積極的に開発しています。 テストの失敗や欠陥のあるテストについてどう思いますか？ GitHub issue でご意見をお聞かせください。 AIによるコードレビュー機能 コードレビューで最悪なのは、自分のPRを誰かにレビューしてもらうことです。 ああ、他のチームの誰かにあなたの変更をレビューしてもらう必要があるなら、幸運を祈ります。 もしあなたがPRを開いた瞬間に、誰かもしくは何かがレビューしてくれたらいいと思いませんか？ Codecovの新しいAIコードレビュー機能は、まさにそれを可能にします。 明らかなミスを特定し、開発者がコード変更のより複雑で重要な側面にコードレビューを集中できるようにする、物知りな友人のようなものだと考えてください。 これは、レビューの迅速化、承認の迅速化、顧客への機能提供の迅速化、そして「最新の変更をレビューしてもらえますか」というメッセージの減少を意味します。 まとめ Sentryはおそらく本番環境であなたのコードを監視していると思いますが、デプロイする前にはギャップがあります。 そこで、SentryのCodecovチームは、コードカバレッジだけでなく、リリース前のすべてにフォーカスを移すことで、そのギャップを埋めようとしています。 これはほんの始まりに過ぎません。私たちが境界を押し広げ、一度に1行のコードでソフトウェア開発の未来を形作り続けるように、私たちに加わってください。 いつものように、あなたのご意見をお聞かせください。 また、Codecovを初めてお使いになる方は、今すぐ無料でお試しいただくか、デモ利用のお申し込みをください。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
FastCo.が選ぶ2022年最も革新的な企業の一つで、プラットフォームの安定性を最優先する
フィットネス業界では、ずいぶん前に「スマート」な機器をビジネスモデルに取り入れていました。 最近では、ユーザー体験の高さで差別化をはかり、競い合っています。 安定性と品質は、プロダクトの成功に不可欠です。 これはトナール社の開発者たちにとっての最重要課題でした。 「ユーザー数は多いのですが、バグを報告するユーザーは比較的少ないです。私たちは非常に安定した製品を持っており、目標はそれを維持することです。- トナール社、モバイルソフトウェアエンジニアリングシニアマネージャー、マックス・ラピデス氏」 トナール社は、ニューヨークマガジンのベストスマートホームトレーニングソリューション2022年にランクインしています。 また、メンズヘルスでも、ベストコネクテッドケーブルマシン2022にランクインしています。 トナール社は、スマートホームトレーナーの業界水準を定めており、その標準を維持するために、開発者たちは製品がユーザーの期待に応えられるように、今までとは違うアプローチをとっています。 彼らは、製品の問題を減らすだけでなく、完全に無くすことに注力しています。 「エラーやクラッシュを減らそうという意識は持っていません。なぜなら、私たちは、システムがクラッシュすることを想定しておらず、システムはクラッシュしないと想定しています。」 バグのないUXを実現するワークフロー 当たり前ですが、システムエラーはどのシステムにも存在します。しかし、そのエラーがユーザーに影響を与えることを防がなければなりません。 そのためには、パフォーマンスモニタリングと自動エラーレポートを開発作業に取り込む必要があります。 マックスのチームは、Debug Symbolを使用して、エラーログをデバッグの段階で活用することでこれを実現しました。 そして、スタックトレースからSentryが提供する追加のデータコンテキストを使用しています。 例えば、このスタックトレースだけでは、必要なコンテキストデータがあまり得られないため、デバッグには使えません。 しかし、マックスのチームがデバッグ用のシンボルをSentryにアップロードすると、シンボル化されたスタックトレースができてしまいます。 「Sentryがなければ、これらのデバッグ用シンボルファイルを収集する必要があります。Sentryは、App Store Connectや CIシステムからのアップロードから自動的に収集します。これにより、不明瞭で難解なデータを人間が読めるものに変換することができるようになります。」 トナール社がスムーズなUXを維持するもう一つの方法は、Sentryにパンくずリストを設定することです。 これにより、問題を調査している開発者たちは、エラーにつながったユーザーのアクションを時系列で確認することができます。また、問題を再現し、迅速に解決するために必要なすべてのコンテキストも確認することができます。 「これらのユーザーイベントは、デバッグに役立つアプリ内のユーザーのアクションの流れを表していることに気づきました。そこで、現在ではこれらのユーザーイベントもパンくずリストとしてSentryに送信しています。 これにより、Sentryを起動したまま、問題が発生する前のユーザーの行動を正確に把握できるようになりました。」 例えば、新機能のエッジケースのテストでQAエンジニアが、UIの問題を見つけることがあります。 Sentryは、ユーザーがエラーに至るまでに行ったHTTPリクエストや、ユーザーが行ったナビゲーションなど、その問題に関するリアルタイムのデータを表示してくれます。 また、Sentryは担当チーム、Flutterのバージョン、ビルド番号などの詳細なコンテキストデータも提供してくれます。 これにより、対処可能なバグレポートを提出することが簡単になります。 バグレポートには、問題を再現し、最終的に解決する方法について、十分な情報が詳細に含まれています。 コードを “即断即決で “修正することなどありえない トナール社は、2019年から続いている2週間のスプリントとデプロイの徹底した周期に従っています。しかも、そのペースは2019年から変わっていないそうです。 規則的で予測できるリリースは、安定して高性能なユーザー体験を提供するための高い基準をチームに課すことになります。しかし、モバイルでは、その場でコードを修正することは、あまり現実的ではありません。 「AndroidとiOSの両プラットフォームに対応したアプリを再構築する必要があります。そして、24時間から48時間かけてレビューを行い、Google PlayとApp Storeの両方にリリースすることができます。その後、ユーザーの端末で自動的にアップデートされるのを待ちます。重要な機能を追加する場合は、さらに3日ほどかかることもあります」 そのため、マックスのチームはデプロイ前の約一週間、QAでビルドを確認し、リリース用のダッシュボードで監視するようにしています。 リリースは個々のビルド番号で標準化されており、QAを通過すると、チームは最新のビルド番号を「ゴールドマスター」と宣言します。 これで本番リリースの準備が整います。 「Sentryで重大な問題が確認された場合、通常48時間以内に修正することが可能です。しかし、目標はこうした問題が本番環境で発生しないことです。」 トナールのチームは、プラットフォームの安定性、復旧力、ユーザー体験に重点を置いています。マックスのチームは、開発能力とSentryのカスタムソリューションを組み合わせているため、以下のようなことができるようになります。 詳細なコンテキストデータを含むエラーを積極的に監視します。 プラットフォームの安定性とUXに直接影響を与えるエラーを簡単に優先順位付けすることができます。 品質を犠牲にすることなく、きっちりとリリーススケジュールを維持します。 アプリ内のユーザー行動を分析し、解決までの時間を短縮します。 ユーザーに高いパフォーマンスのUXを提供することで、他社よりも優位になります。 「Sentryは、私たちがプラットフォームの安定性を維持するのに役立ちます。 Sentryは、ユーザーたちに直接影響を与えるようなコードをリリースするのを防いでくれます。私たちにとって良い日とは、クラッシュがないときです…それが毎日ならいいですが」 Sentryは、アプリケーションコードの健全性を監視するために不可欠です。エラートラッキングからパフォーマンスモニタリングまで、開発者は、フロントエンドからバックエンドまで、アプリケーションをより明確に把握し、より迅速に解決し、継続的に学習することができます。 […]
Pythonのテストを数百の環境で高速に実行する方法
長文を読む気分ではない方は、ここからDjangoCon 2022で行われた講演（英語）を見ることができます。 Sentryの信念のひとつに「すべての開発者のために」というものがあります。 すべての開発者をサポートしたいと思っています。しかし、すべての開発者が最新の技術や広く採用されている技術スタックを使っているわけではありません。そのため、古いバージョンのライブラリやフレームワークもサポートするように心がけて取り組んでいます。 当社のSentry SDK for Pythonでは、次のことをサポートしています。 約20種類のWebフレームワーク Python2.7を引き続きサポートします（！） Python 3.5から3.11まで対応しています 古いバージョンのフレームワークをサポートしています。(例：8年前のDjango 1.8をサポートしています） SDKが正しく動作することを確認するために、テストスイートには約450の自動テストが用意されており、SDKに変更を加わるたびに実行されます。 7つのPythonのバージョンと約20のフレームワークをサポートしているため、それぞれのフレームワークのバージョンが2～9になると、テストを実行する環境は400を超えます。 テスト用スタック テストスイートはpytestを使用して実行されます。 テスト実行前に、Flake8とblackを使ってソースコードのリントとフォーマットを行い、mypyを使って型チェックを行っています。 Toxは、さまざまな環境でテストスイートを実行するためのツールです。 ローカルマシンの異なる環境でテストスイートを実行するために、古き良きmakeを使用しています。そして最後に、GitHub ActionsをCIとして使用し、すべてのプルリクエストに対してすべての環境でテストスイートを実行できるようにしています。 スローテスト 私たちのテストセットアップは何年も前に作成され、時間の経過とともに多くのテストが追加されました。 しかし、テストセットアップ自体をリファクタリングする時間がありませんでした。そのため、テストスイートを実行するのに約40分も時間がかかっていました。 このようなテストスイートは、苦痛でしかありません。 SDKの新しいバージョンをリリースする際には、リリースごとにテストスイートを実行するため、テストが完了するのに最大で1時間もかかることもありました。 これは由々しき事態です。そこで私たちは、テストスイートの改善に取り組みました。 テストスイートを高速化する すべてのテストをリファクタリングすることなく、より速くテストを実行する方法について、いくつか考えました。どのようなことをしたのかをご紹介します。 フレームワークごとにテストスイートを分割 テスト実行にかかる時間を大幅に短縮 開発者の生産性を向上 考えた結果、テストそのものではなく、テストの実行方法を変えようという結論に至りました。 まず、テストスイートを改善するのに着目したのは次のことです。それはいままでそれぞれのプルリクエストで、すべての環境でテストスイートを実行するGiHub Actionsランナー1つでToxを起動し、1つずつ実行していました。 これは、テストを実行する上で最も遅い方法であり、1回の実行に38〜42分はかかります。 アイデア1：toxでテストスイートを並列に実行する Toxのコマンドラインには、–parallel autoオプションがあり、利用可能なCPUコアの数だけテストスイートを並列実行することができます。 これにより、すでにテストの実行時間は劇的に改善されました。 今まで40分かかっていたテストが、25分程度になったのです。しかし、これではまだ「速い」とは言えません。 GitHub ActionsのランナーはCPUコアを2つしか持っておらず、使用できるCPUコア数には限界がありました。 アイデア2：GitHub Actionsを使ったテストスイートの並列実行 GitHub ActionsのランナーのCPUを増やすことはできませんが、GitHub Actionsのランナーを増やすことは可能です（大きなマシンを購入しない場合）。 そこで、テストを実行するすべての環境に対してGithub Actionsの設定yamlファイルを作成するスクリプトを作成しました。 アイデアとしては、このようなものでした。 しかし、GitHub Actionsの同時実行できるワークフローにも制限があることがわかりました。 私たちはGitHub […]
Sentryでもっと早くトリアージし、安らかな睡眠を
開発者にとって、トリアージする月の1週間は、しばしば憂鬱でした。 トリアージとは、バグが報告されるたびに、手作業でログを分析し、関係するスタックトレースがあることを期待し、そして記憶を頼りに適切なチームへ連絡することでした。 トリアージをする開発者は、バグを適切なチームに連絡する必要があります。また、バグを調査するのに必要な情報を併せて報告する必要があります。 十分な情報がない場合、開発者はプロダクトを作成するよりも多くの時間をデバッグに費やすことになります。 現在、Sentryは400万人以上の開発者のトリアージとコンテキスト収集作業を最適化してくれます。しかし私たちは、さらに課題解決までの時間と課題解決率を向上するように努めています。 課題解決率および解決までの時間の改善 課題のトリアージは、4つのフェーズに分けることができます。 検知 通知 アサインメント 解決 ユーザーからのフィードバックやインタビューに基づく、通知やアサインメントの改善は、より良い結果をもたらすと考えました。 具体的な改善点として、以下の2点に着目しました。 サジェストでアサインメントの改善 関係ない通知によるノイズ低減 アサインメントの改善とアラートノイズの低減 簡単に課題を特定し、適切なチームや開発者にアサインすることができるようになります。 各課題について、担当者はSentry組織内のメンバーまたはチーム内で、最も詳しい情報を持っています。 Sentryは、3つのシグナルに基づいて、課題をサジェストします。 サスペクト（疑わしい）コミット – Sentryは、問題が起きたコードを最近変更した開発者を特定します。 所有権ルール – Sentryは、イシューのタグやコードなどに基づいて、適切にSentryチーム/メンバーを見つけるためのルールを評価します。 コードオーナー – SentryはGitHub/GitLabのCODEOWNERSファイルを解析し、コードに基づいて、イシューに適切なSentryチーム/メンバーを設定してくれます。 お客様からのフィードバックを目にして、ユーザーが確実かつ迅速に課題をアサイン、解決するのに役立っていることを知りました。 そして、より多くのユーザーがサジェストアサインを利用できるように、ここ数ヶ月で様々な機能を追加しました。 Git Blameを使ったサスペクトコミットについて サスペクトコミットは、Sentryでは問題の原因となっているファイルを最後に変更した人を表示するだけでした。 しかし、Git Blame API連携することで、Sentryは特定のコード行を変更した人、および問題の原因となったコードのプルリクエストを特定することができるようになりました。 また、イシューを自動的にコミット作成者にアサインすることができるようになりました。 この機能は、GitHubまたはGitLab連携を利用すれば、誰でも利用できます。 組織でこの機能を有効にする詳しい方法は、以下をお読みください。 コードマッピングを自動で設定 怪しいコミットを見つけるために、Sentryはエラーの原因となるファイルとリポジトリ内のソースコードファイルを結びつける必要があります。 しかし、これを正しく設定するのはなかなか難しく、ユーザーがこの設定を怠っていることに気づきました。 そのため、SentryのGitHub連携を利用するユーザーのために、この設定を自動化するようにしました。 Sentryは、Python、JavaScript、Node、Rubyなどのプラットフォームのソースコードと、エラーの原因となるコードを自動的にマッピングしてくれます。 この自動化されたセットアップにより、Sentryはさらに多くの怪しいコミットを見つけてくれるようになります。 不要なSentry通知を減らす Sentryでは、新しいプロジェクトを作成すると、デフォルトのイシューアラートルールが作成されます。 しかし、このルールはアサインできる人がいないイシューに対して、同じプロジェクトで作業しているチームメンバーに対して、通知を行う可能性があることに気づきました。 このアラートルールを使うことで、そのプロジェクトの全メンバーに迷惑をかけることなく、チームに通知できるように変更しました。 より良い結果を出すために ここでは、ユーザーがどのように問題解決をするか、その過程を紹介します。 Sentryはイシュー担当候補者がいる場合、アラートルールに従って、適切な開発者、チーム、Slackチャンネルに通知することができます。 これにより、開発者に不要な通知を減らし、チームにとって重要なイシューに集中してもらうことができます。 この利点は、イシューの担当候補者が増えれば増えるほど大きくなります。 さらに、Sentryがデフォルトのイシューアラートルールを変更したことで、問題を迅速にトリアージする能力を維持しながら、全体で不要な通知を33%削減することができました。 […]
フルスタックの可視化で遅さの根本原因を探る
ユーザーにとって素晴らしいアプリは、処理パフォーマンスが高いです。 しかし、ページロードに10秒かかるアプリは決して良いとはいえません。ユーザーは安定しかつ高速なアプリケーションを望んでます。Sentryは、コードのどこに異常があるのか通知します。 それだけでなく何が遅いのか、どう修正すればいいのかを詳細に出力します。 パフォーマンスモニタリングを最大限に活用 パフォーマンスモニタリングでは、複雑なケースが多々あります。 その理由のひとつは、開発者のエコシステムが複雑であるということです。私たち開発者は、一つのプロジェクトでアプリケーション全体を構築することはありません。 つまり、あるプロジェクトでの速度低下が、別のプロジェクトでのパフォーマンスのボトルネックになる可能性があるというわけです。 私たちのプロジェクトのエコシステムが複雑になると、スタック全体を監視する必要が生じます。 そこでSentryを使うと、速度低下を修正する方法についてのヒントを得ることができます。また、Sentryを使えば、原因となっているコードを特定することもできます。 例えば、フロントエンドのリクエストからバックエンドの遅いAPIコールまでのトレースを追うことが非常に簡単になります。 サービス間チャッター 一般的に、フロントエンド（クライアント）側はバックエンド側と通信します。 バックエンドは、DBサーバーやサードパーティサービスと連携します。 Eコマース会社を例に考えてみましょう。このストアのフロントエンドは、Webサイトとモバイルアプリを保持しています。どちらもAPI Gatewayを介して、情報をインベントリーサービスにルーティングします。そして、最終的に決済サービスに情報を転送します。 クライアント（フロントエンド）から始まり、決済サービスまでのトレース内の各トランザクションは、連鎖的に影響を与える可能性のある呼び出しの連なりと言えます。 しかし、すべてのサービスやプロジェクトにテレメトリー（処理の監視データ、計測データのこと）がなければ、開発チームはエンドツーエンドのトレースを完全に可視化することはできません。 以下のケースを考えてみましょう。 例えば、Webのメトリクスが良好であるとします。Web開発チームは満足しています。 しかし、インベントリーサービスやチェックアウトフローの処理に長い時間がかかっている可能性が出てきました。 このとき、何が問題なのか、どこに原因があるのか特定できず、チーム内で混乱が生じるリスクが発生します。 原因を特定するには、各サービスがどのように通信しているかを理解する必要があります。 あるサービスが他のサービスの応答を待っていると仮定します。 であれば、アプリケーションのパフォーマンスはもちろん低下します。 すると、ユーザーはページロードに長い時間待たされることになります。 …このように、Sentryを使用するとフロントエンドとバックエンドを横断的に分析することが可能になります。あるプロジェクトの操作が、別のプロジェクトの操作をどのように遅くしているかを見ることができます。 プロジェクト横断的な視認性 さて、それらの機能はどのように動作するのでしょうか。 SentryのSDKは、お客様のコードの変更を監視し、スループット、Apdex、User Misery、トランザクション期間などのメトリクスを測定します。 複数のシステムに渡って、エラーの影響度合いを表示することができます。 また、Sentryはトランザクションとスパンからなる分散トレーシングを取得します。 これらのトランザクションとスパンは、個々のサービスと、それらのサービス内の個々のオペレーションを測定します。 トランザクションは、ある操作をサポートするために呼び出されるサービスの単一のインスタンスを表します。 測定・追跡したい（例：ページロード、ページナビゲーション、APIコール、非同期タスク）個々のオペレーションはスパンと呼ばれます。パフォーマンスの悪いスパンは、レイテンシーに影響を与える可能性があります。 その結果、UX（ユーザーエクスペリエンス）が低下したり、スループットに問題が生じたりする可能性があります。 これはアクセスがピーク時に達した時、サイトに悪影響を及ぼすリスクがあります。 Sentryの分散トレース機能により、あるプロジェクトの遅いスパンが、他のプロジェクトのトランザクションをどのように妨げているかを確認することができます。 分散トレースでは、コードのどこで、何が遅いかを教えてくれます。 また確認に手間のかかるサードパーティの依存関係も特定することができます。 分散トレースは、Trace ViewとTrace Navigatorのバックボーンとなっています。 トレースビューとトレースナビゲータは、プロジェクト間でスパンがどのように相互作用しているかを示すミニマップを出力します。 遅いものを見つける さて、先ほどのEコマースの例に話を戻します。 フロントエンドはReactで構築され、バックエンドはPythonのFlaskフレームワークを使うことがわかりました。 ある日、商品ページの読み込みが遅いことに気づきます。 SentryのPerformanceタブに行くと、/productsページのp50が7秒以上になっていることがわかります（一目でわかります！）。 ページの読み込み時間が遅いのは、実際に開発中のReactプロジェクトにあります。 しかし、その原因は一体どこにあるのでしょうか？ それでは、実際に探してみましょう。 1. Transaction Summary […]
Sentryでクラウドサービスに関するコンテキストを増やす方法
Sentryを使用してSentryを構築している、とあるSentry社員がいました。 彼は、ある課題に関する特定のサービスが、当社のクラウド環境のどこでホストされているかを知りたいと考えていました。 これをきっかけにSentryでは、Python SDKに新しいクラウドデータ収集機能を作成し、Sentry社員だけでなく誰でも利用できるようにしました。 この機能の目的は、クラウドでホストされているサービスから問題が発生したときに、そのサービスに関する特定の情報を調べることで、根本原因を突き止め、より速く修正し、製品版のリリースを可能にすることです。 Python SDKは、AWS EC2およびGCP GCEのリージョンとホスティング環境に関する基本情報を取得するようになりました。 これによって、クラウドホスティングの設定に関連する問題や複雑さを迅速に特定することができるようになり、作業時間を大幅に減らすことができます。 この新しいコンテキストは、クラウド技術のベテランであろうと、未経験者であろうと、クラウドに分散されたサービスについて十分な情報に基づいた意思決定をするために必要な情報を提供します。 ぜひ実際に使っていただき、GitHubのディスカッションで感想を聞かせてください。 どのようにこれをリリースしたのか、舞台裏をご紹介しましょう。 私たちは、OpenTelemetry SDKsからインスピレーションを得ました。OTelは、テレメトリーデータとSDKを含むツールのなかで、誰でも使える標準的なものとして有名です。 やはり、意見や感想をもらうことは私たちSentry開発者としても学びになります。私たちのOTelの開発業務についてもっと知りたい方は、最近のブログ記事をご覧ください。 または、ぜひここでご意見をください！ IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
【モバイル開発】未来は宣言型にある
モバイル開発のエコシステムは常に非常に多様であると言えます。（デスクトップ）ウェブ開発のエコシステムよりも多様だと言えるでしょう。日々、ウェブ開発者向けのフレームワークやツールは増えているようですが、その多くはJavaScriptの上に構築されています。 その多くは、互いに似たようなパターンを実装しています。一方、モバイルのエコシステムには、コアとなる複数の言語セットがあり、そのためモバイル向けのツールやフレームワークの違いを識別するのは非常に簡単です。 モバイルのネイティブプラットフォームの代表格といえば、ネイティブのAndroidとiOSの2つがあります。 どちらも最近興味深いイノベーションがありました。近年Jetpack ComposeとSwiftUIの導入がありました。 ネイティブアプリの開発は、React NativeやFlutterアプリの開発と非常によく似ています。React NativeもFlutterも、最初から宣言型アプローチをとっています。 AndroidとiOSも現在、宣言型のアプローチを採用しています。 モバイル開発の未来は、宣言型であると言えるでしょう。 ちょっとした歴史 React NativeやFlutterは常に宣言型のアプローチをとってきましたが、AndroidとiOSは当初はそうではありませんでした AndroidはViewを活用していました（今もそうですが）。ViewはXMLファイルです。 Button、TextView、LinearLayoutなどのウィジェットを使ってユーザーインターフェイスを定義します。開発者はこれらのウィジェットにIDを割り当てます。これらのIDは、Javaファイルの中でウィジェットを参照するために使用されます。 ファイルでは、機能と動作を開発します。以下は、Viewファイルの例です： このようにウィジェットのリファレンスを作成することになります。 iOSには、Auto Layout、UIAppearance、Objective-Cの@property宣言、KVCコレクション演算子、Combineといった宣言型の機能がありました。 しかし、それでもある程度の命令型のコードを書く必要がありました。 例えば、iOSにはStoryboardsがありました（今もあります）。Storyboardsは、私たちがUIを構築するために使うグラフィカルなツールですが、実際にはXMLファイルです。しかし、開発者はXMLのコード自体にはほとんど触れません。ここでは、StoryboardsでUI要素を追加し、参照とアクションを作成する方法を紹介します。 宣言型に移行する 記憶を呼び覚ますと、命令型アプローチとは、目的のUIを実現するまでのステップバイステップの指示を出すことです。宣言的アプローチとは、最終的なUIがどのような状態になるかを記述することです。 Androidの新しいJetpack ComposeはKotlinで書かれています。 これはマークアップ言語であるXMLとは対照的なプログラミング言語です。 先ほどのXML Viewの例は、Jetpack Composeではこのようになります。 ご覧のように、このアプローチでUIを構築すると、必要なコードはかなり少なくなります。プログラミング言語を使えば、ウィジェットへの参照を作成し、そのウィジェットにロジックを取り付ける代わりに、変数とコールバックを直接使用することができます。値に変化があれば再構成（リレンダリング）が行われるため、UIは常に最新の状態に保たれます。 iOSのSwiftUIはほとんど同じで、Jetpack Composeの代わりにSwiftで構築されています。先ほどのStoryboardの例は、SwiftUIではこのようになります。 ここでもコード量がぐっと減ります。ここはプログラミング言語なので、Buttonのラベルを直接定義することができます。 参照を作成することなく、onClickコールバックを提供することができます。 命令型UIKitで作業しているときに、問題が見つかりました。ViewをView階層に追加する前に、Viewの制約を有効にする必要があります。 subview.leadingAnchor.constraint(…)の行とview.addSubview(view)の行を入れ替えるとエラーにならずに動作します。最初にこのエラーに遭遇したとき、何が起こっているのか理解するのに時間がかかりました。 理解しやすくなるまで、さらに何度かこのエラーを発生させてみました。しかし、新しい宣言的アプローチでは、この問題に遭遇することはないでしょう。 AndroidとiOSにおけるこの宣言型へのシフトは、より良い開発者体験とより速い開発への大きな一歩となります。プログラミング言語を使ってUIを宣言型で定義することで、AndroidやiOSの開発者が抱える多くの苦悩を解決することができます。 ここでは、宣言型アプローチの利点を紹介します。 テーマ設定が簡単になり、より動的になります。 ステートマネジメントは自然に感じられ、新しい宣言的アプローチにおいて重要な役割を果たします。 コンポジションアプローチでは、要素をネストすることでUIを構成することができます ダイナミックレイアウトや条件付きレンダリングが簡単にできるようになりました。 なぜでしょうか？それは制御構造や分岐ロジックを持つプログラミング言語を使ってUIを構築しているからです XMLを介するよりもSwift/Kotlinのコードを介した方がgrepがしやすくなります。 プログラミング言語の他の部分に適用されるのと同じツールを使って、より体系的にコードを再構築することができます。 PRのコード差の方がわかりやすくなります。 UI要素は、マークアップ言語とは対照的に、実際のデータ構造（関数、クラス、構造体）で構築されています。 そのため、Viewのユニットテストも行うことができます。 もちろん、気にかけるべき欠点は常にいくつか存在します。 SwiftUIとJetpack Composeはまだ生まれて数年しか経っていません。 ドキュメントの不足、コミュニティの小ささ、いくつかのパフォーマンスの問題（例えばAndroidの遅延カラム）などの欠点があり、また以前のフレームワークからのすべてのコンポーネントがサポートされているわけではありません。 より複雑なUIを構築しようとすると、制限があります。SwiftUIとJetpack Composeの両方は、まだ進化し、改善されています。 […]