Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。宇宙計画とソフトウェア開発の類似点について論じた。InfoQはOlsen氏にインタビューして,期限に間に合わせるためにすべてを同時に実行する方法の問題点,失敗や成功から学ぶということ,ソフトウェア開発において些細なことがいかに命取りになるか,複雑な作業において各詳細に集中して対処するにはどうすればよいか,といった話を聞いた。“すべてが変わる”というフレーズがよく使われるのは,よくご存知だと思いますが,実際に何かが変わったという話を聞くことはめったにありません。すべてが変わったなど聞いたこともありません。あの日曜日の午後に人類が月面に着陸したことで,少なくとも私にとっては,すべてが変わりました。私の人生の進むべき方向が,大人になった時にやりたいことが分かったのです。それは私だけではありませんでした。その日を境に人生が変わったという,たくさんの人たちに会ったのです。私は長い間,不幸にしてその場に居合わせなかった人たちに,私の経験を理解してもらおうと努力してきました。それがうまくいった唯一の方法が,その強烈な瞬間瞬間を,私と一緒に追体験してもらうことだったのです。そこで今回の講演,という訳です。宇宙計画では,期限に間に合わせるために,すべてを同時に行うという方法を取りました。ApolloプロジェクトにおけるNASAの状況は,不可能に近いプロジェクトを考えられない期間で完了しなければならない,というものでした。タイムラインは,“ステップ1の上にステップ2を配置する”ようなプロセスを論理的に許していません。そのため,彼らが最終的に採用したのは,必要なことのリストを作ってそれを全部同時に実行し,最後に組み上げるという単純な方法でした。組み合わせた時に正しく動作しないコンポーネントがあるのは目に見えていますし,同じ問題が他でも起きていることが分からないので,同じ対策を何度も行うことになるからです。全体的な設計変更を行えば,作業の手戻りも膨大になります。Apolloプロジェクトの異常さを最も顕著に表しているのは,母船の背面に搭載された巨大なエンジンです。このロケットエンジンはもともと,母船が月面から離れる時のために設計されたものでした。ところが,プロジェクト全体のデザインが固まっていく中で,母船とは別に,専用の着陸船が用意されることになったのです。結果として母船には,巨大なロケットエンジンは必要なくなったのですが,すでにそのように設計されていたため,そのまま残しておく方が簡単だったのです。残念なことに,このような“先に全部作っておいて,後で統合する”というテクニックを使用しているソフトウェア開発を目にすることが非常に多いのです。いつも笑ってくれます。異常な目標と非常識な開発期間にあります。ソフトウェアプロジェクトを管理していて,不可能な目標と非常識な期限を決めたとしても,そうですね,チームにもよりますが,それをやってのけることがあるかも知れません。無理ですが,あり得ないこともないでしょう。成功か失敗かに関係なく,不可能な目標と非常識な期限は,無駄な労力やチームの燃え尽き感,不完全な設計など,さまざまな形で代償となって現れるのです。航空宇宙技術に対する印象として一般的なのは,顕在的と潜在的の両面での,失敗に対する執拗かつ系統的な研究です。旅客機や宇宙船では,その一部に問題があった場合のための,体系的な質問セットが用意されています。“どうしてもっと早く分からなかったのか?”,あるいは“他の機体ではどの程度起きているのか?”,“この問題は,より一般的な問題のひとつの例なのか?”という質問も当然あります。航空宇宙技術のエンジニアたちは例外にも,すなわちダメージには直結しなくても,通常起きてはならないものにも,常に注意を払っています。彼らは障害に対して非常に注意深く,データ駆動かつ統計的なアプローチを取ることが多いのです。ログサービスが落ちたんだろう,問題を修正して,そのことは忘れよう。“どうやったら,こんなことが起こせるんだ?!!”と言うのは,ソフトウェア障害に対する反応として理解はできますが,生産的ではありません。壊れていなければ修正するな,というように。異常が起きる以外,システムは故障していないのですが,そのシステムは必死にあなたの気を引こうとしている,いまにも倒れそうなのを告げようとしているのです。ソフトウェアシステムは多数の部品で構成された複雑な機械である,と見ることができます。収集し,そのデータに基づいたシステム理解の構築を考えなくてはならないのは自明なことです。成功していること,うまくいっていることからは,どのように学べばよいのでしょう?あなた自身の見解と,それがソフトウェア業界で十分に行われているかを教えてください。私がソフトウェア業界で何度も目にした問題は,成功したプロジェクトから学んだことを,あまりにも一般化しているという点です。プロジェクトは明確な目標,熱意を持ったユーザ,確かな技術,柔軟な思考,優れたドキュメントを持って開始されます。そこでよく口にされるのが,“プロジェクトはうまくいった,設計資料もよくできている!”,あるいは,“私たちは毎日1時間,ユーザとミーティングしている。そこであがった要件はすべて実現した”,“要件はすべて理解した”,といったこと,まさに魔法の弾丸ですね!問題なのは,複雑なソフトウェアシステムには,正しく実現しなければならない機能が数百万もあることです。成功したのならそれは素晴らしい,その成功の根本要因をぜひ特定してください。注意して欲しいのは,要因(causes)は複数形である,ということです。ソフトウェア開発で重要なのは,全体の構造が適切であることです。システムとして全体設計の正しさが不可欠なのは当然ですが,いくら設計がよくても,実装が貧弱であっては大して役に立ちませんまたは実装がいくら優秀でも,バグがたくさんあるようなシステムでは,誰も喜んでくれないでしょう。多くのソフトウェアシステムが,“マイナー”なバグでその価値を損ねているのは間違いありません。講演の中で理解してもらいたかったのは,月ロケットや,おそらくは中規模の企業システムのように複雑なものを構築する場合,失敗は避けられないということです。ソフトウェア開発者は,さまざまな問題解決を試みて日々を過ごしています。彼らは夜や週末にも,問題を正しく処理するための方法を探しているのです。過去半世紀にわたるプログラミングの歴史から私たちが学んだのは,不良率を下げることはできても,ゼロにするのは不可能だということです。私たちは,障害が発生することを前提として,その障害に対処可能なように私たちのシステムを,組織を,私たち自身を構築する必要があるのです。この機能,このサービス,このシステムを,現実的に可能な限り信頼できるものにするために,できる限りの努力をするというのが正しい姿勢です。その上で,問題が発生した場合に何をすべきか,ということに取り組んでください。option)”というものがありますが,失敗が確実なものである大規模ソフトウェアシステムの開発に関しては,それは正しくありません。問題はただひとつ,あなたとあなたのシステムが,失敗に対する準備ができているかどうかなのです。Berlinカンファレンスの状況をお伝えする予定だ。Londonで行った以前のバージョンの講演を見ることができる。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。