Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。内容などについて話を聞いた。Pinterestでのあなた自身の役割を、特にKotlinの採用促進に関して、簡単に説明してください。UIチームのエンジニアです。Pinterestには数年前、勤務先の買収に伴って参加しました。その会社では数年間、Kotlinを広範囲に(そして中心的に!)使う自由がありました。Pinterestで働き始めても、その経験と熱意を自然と新しい仕事に向けるようになったのです。Pinterestに参加して数週間のうちに、当時私が取り組んでいた仕事(Androidのビデオサポート)にKotlinを試用することを許可してもらうことができました。この仕事や、それに関連して行った社内での宣伝活動によって、私たちのAndroidアプリの中でKotlinの使用が広がって、今年最大の成果である、PinterestのAndroid環境でKotlinを最優先する(Kotlin-first)という、新たな方針が生まれたのです。JVMバイトコードを生成するという意味で、KotlinはJavaから革新的に離れている訳ではありません。それが功を奏しているのが、Kotlinが本質的には、最高のプログラミングプラクティスをその言語に組み込んだ、Javaの1バージョンであるということです。間違ったことよりも、正しいことを行う方がずっと多いのです。これによって速度と信頼性に優れたコードを書くことが可能になり、Javaを使用する場合に必要とされていた作業の多くを排除できます。コーディングは文章と同じで、表現力に富んだ芸術様式ですから、自らの思考を明確かつ素早く、正確に表現できるツールがあることは満足のいく状況であり、エキサイティングに感じるだけの価値があります。これに業界をリードするツールと言語の相互運用性、そしてJetBrainsチームが提示する緻密で思想豊かな言語のリーダーシップの組み合わせとなれば、魅力を感じないはずがありません。Kotlinを採用する上で直面した最も大きな課題のひとつは、Kapt(Kotlinのアノテーションプロセッサ)に以前からある問題など、ビルド関係の問題でした。ビルド状態が正しく分離されていないために、ローカルでブランチを切り替える際に頻繁にビルドエラーが発生するだけでなく、CIビルド環境でもエラーが発生する場合があるのです。これらの問題のため、上級エンジニアの一部からは、Kotlinは止めるべきだという意見もありました。社内の誰かが修正できる類いのものではありません。このような問題は、Kaptや関連するビルドツールが改善されたことで解決されましたが、多くの開発者の心の中の、Kotlinはビルドが不安定だという、言語に対する意見に影響しています。問題のもうひとつの部分は、新しい技術を始めて使って開発するときに必然的に起こる盲点から来るものでした。これらの問題は社内で解決可能な問題でしたから、私たちは教育に集中することで取り組んできました。Studio内に情報を出力する方法のため、ビルド出力からこのエラーを見つけるのが難しかったのです。実際にコンパイル時のエラーを見つける方法を教えることで、このようなエラーを自分でナビゲートするために必要な知識を提供することができました。このタイプの問題を解決するため、Kotlinやビルドに関する質問用にいくつかのSlackチャンネルを用意して、どんな質問でも歓迎し、それに答えるというやり方にしました。Kaptのような新しいコンポーネントがどのように動作するのか、どのようなエラーが通知されるのか、どうやって解決策を探すためにまず何をすればよいのか、といったことは、移行の苦痛を緩和する上で大いに役立ちました。Pinterestでの私たちのポリシはKotlin優先(Kotlin-first)なのであって、Kotlinのみ(Kotlin-exclusive)ではありません。Kotlinが社内のAndroid開発における主要言語であり、PinterestのすべてのAndroid開発者がKotlinの読み書き方法を理解する必要があるということと、新たなコードはKotlinで記述しなければならない、ということなのです。変更の必要がないと思われる既存のJavaファイルについては、事前に変換しないように、特に呼びかけました。この背後には2つの論理があります。ひとつは、“壊れていないものは修正するな”という言葉に集約されます。動作しているものを変更すれば、その変更が既存の動作を損なう可能性があります。ファイルをKotlinに変換する作業に明確なROIや、その他の変更する理由がなければ(ある場合もあります!)、他の変更を実施することで同じようなリスクを想定しなければならない時が来るまで、運用中のコンポーネントはそのままにしておいた方がよいのです。ふたつめは、PinterestコードベースのすべてのファイルをKotlinに書き換えるには多くの時間を要するので、非常に大きな投資になるということです。さまざまな選択肢を考えた時、相当数の開発時間を費やす上で、最も価値のある方法であるとは思えませんでした。よいことではないのですが、私はどちらかというと、反抗的な性格なのです。人に指図されることが嫌いなので、KotlinとJavaのどちらを使うべきかを決める上では、Pinterestの開発者がそれぞれ自分で選ぶべきだと考えていました。Kotlinが優れたJava相互運用性を備えているという技術的観点から言えば、これは十分に可能なことですし、社内の他の人たちも同じ考えだったのですが、それができなかったのは人間性の問題でした。人は不確実性を嫌いますから、API設計やnull許容パターンといった会話がそれぞれのキャンプ(Javaチーム、Kotlinチーム)に頻繁に分かれるようになって、“我々と彼ら”というシナリオに陥ることが多いのです。Kotlinを社内で組織的に広めたことで、最終的には、大部分の開発者が新しい言語を積極的に試し、関心を持たない多くの開発者がオプトアウトするという、ひとつの壁にぶつかりました。十分な時間があれば、本質的な方向性が最終的にすべての開発者を変えることができたかも知れませんが、ロールアウトのスケジュール上の問題から、チームが分裂した状態が長く続くことになっています。Chuが(他のエンジニアリングリーダの協力の下で)Kotkin-firstという強い言語方針を展開するという決定を下したとき、選択肢が失われることに対してメンバが不満を持つのではないか、という懸念がありました。プロセスに関して健全な議論が行われた結果として、ポリシが実施された後、チームの結束力と幸福感は大きくジャンプアップしたように思います。この経験からPinterestが得た最大の教訓のひとつは、チームが分裂した状態にある時間を最小限に抑えるためには、調査とロールアウトの段階で明確かつ直接的なガイダンスを提供することが重要だ、ということです。チームとしては、徹底的にテストをして、ひとつの結論(完全に排除するか、完全にコミットするか)に素早く達することの価値を強く認識することができたと思っています。その他に学んだこととして大きなものは、Kotlin(特に早い段階)によってビルドが不安定になり、そこで発生した問題(おもにCIとKaptに関して)を解決する上で、監視と修正に相当なリソースを割り当てる必要があったことです。周到な調査を必要としたため、エンジニアの時間的投資がゼロではありませんでした。当初この作業に十分な人員を割り当てていなかったため、初期のビルド障害の調査には必要以上に時間を費やしてしまいました。この分野に専任のリソースをアサインした後は、こうしたビルドの問題に対しても、比較的短時間で適切なサポートができるようになりました。このオンコールエンジニアに対する初期投資には大きな効果があったので、今後のフレームワークのロールアウトでも試してみようと思っています。Daoや私の講演なども含めて)たくさんありますから、どのような学習スタイルでも、Javaからの移行を支援するようなコンテンツを簡単に見つけられると思います。Javaコードをコピー・アンド・ペーストするだけで、自動的にKotlinに変換する機能が提供されているのです。これを使えば、Javaのコンセプトがどのように新しい言語に変換されるのか、大まかなマッピングを得ることができます。Translateが言語翻訳の概要を知る上で役に立つのと同じような感覚です。エディタの提案が誤っている場合もありますが、たいていは非常に分かりやすいエラーメッセージが出ますので、StackOverflowで簡単に検索することができます。ひとつ重要なのはコードレビューです。ほとんどのプログラミング言語がそうであるように、Kotlinで同じタスクを達成する方法はたくさんあります。社内で言語の運用を始めた頃、私たちはKotlin専用のレビュアを用意して、言語を使い始めた人たちから来るプルリクエストを確認するようにしていました。基礎となるコードが技術的に適切であるかを評価することが目的ではなく、言語がどのように使われているか、ベストプラクティスや推奨スタイルガイドに沿っているか、といったことのみに注目していました。レビューを受ける側は提案を受け取り、レビューをする側は質問やコメントをするために、言語について深く考えることを求められました。PRを読んだ他のチームメンバが参照できるように、議論の内容はドキュメント化されています。2018での講演では、どのような話をしますか?そのトピックを選んだ理由も教えてください。今年のKotlinConの講演では、アプリケーションの不連続な状態を簡単かつ正確に定義する上で、Kotlinの言語機能がいかに有益か、という話をする予定です。私が特に熱意を持っているのは、データ構造の明確な定義についてです。プログラミングの領域なので、コードレビューやアーキテクチャの議論では見過ごされがちなのですが、それが原因で生じる未処理問題やバグの数は可は計り知れません。クリーンな部屋を清潔に保つのが簡単であるように、プロジェクトの初期に論理的なデータ構造の確立や維持に時間を費やすことは、コードがさまざまな使用フェーズに移行する際に、適切な作業を行なうことが簡単にできるようになります。これは開発者にとって開発速度上の勝利であり、ユーザにとっては安定性における勝利です。今日は私たちのために時間を頂いて、ありがとうございました。Kotlinに関して最も印象的なことのひとつは、この言語を採用して徹底的に利用するというアプローチを実行して、それを後悔したという開発者を知らない、ということです。Swiftに関する個人的な経験では、言語としては概ね人々の気に入られていたものの、ビルド時間や相互運用性や言語バージョンのマイグレーション問題といった理由から、移行に難色を示す人たちが多かったのです。私の経験から言うと、Kotlinに対する声高な批判の大部分は、実際には使っていない人からのものであって、広く使用している人たちからのものはほとんどありません。言語の採用に関して何ヶ月も議論を続けてきた人が、言語を転換した数週間後に私のデスクに来て、KotlinのおかげでAndroid用の開発にもう一度愛情を持てるようになった、と語ってくれたこともありました。別の開発者は、最初は言語の採用を嫌っていたのですが、現在ではレガシファイルのメンテナンスでJavaに戻らなければならないことに不満を言っています。乗り気でない開発者でさえ魅了するこの能力は、言語そのもの、それを取り巻くツール、その使用を推進するチームの存在を示す何よりの証拠なのです。PintetestでのKotlinに関する情報は、Pinterestのエンジニアリングブログで詳しく紹介されている。Javaホームページにアクセスすれば,Java関連の最新ニュースを確認することも可能だ。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。