Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2018/11/22)へのリンクコードレビューは、バグを見つけたり、他のチームメンバーからインプットを得たり、知識とオーナーシップを共有するのに最適な方法だ。最大の恩恵を受けるには、コードレビューを開発プロセスに統合して、レビューされていないコードが本番環境に投入されないようにしなくてはならない。レビューは、開発プロセスにおける解決を必要とする未解決問題を明らかにするのに役立つ。Fernandez氏がコードレビューについて語った。InfoQでは、このカンファレンスをQ&A、要約、記事で取り上げている。オープンソースプロジェクトの大多数は外部からのコントリビューションを全てレビューしており、多くの人がチームメンバーによるコントリビューションをレビューしている、とFernandez氏は語る。ほとんどの企業では、コードを本番環境に投入する前に、誰もそのコードを読んでいない。この事実が恐ろしくないなら、何が恐ろしいのかわからないよ、彼は主張する。Fernandez氏は、少なくとも作者以外の人の目でレビューされていなければ、どんなコードも本番環境に投入してはいけないという。理想的には、2、3人のレビュアーに本番環境に投入されるもの全て(些細な変更を除く)をチェックさせるのが望ましい。コードレビューがもたらすメリットは、バグを少なくして、チームスピリットを高めることだ。コードのオーナーシップの共有、知識の共有、メンターシップもサポートする、とFernandez氏は語る。コードレビューは自分を公正に保ってくれる。誰かが自分のコードをレビューするとわかっていれば、同じようにコードを書くことはないだろう、Fernandez氏は語る。InfoQでは、コードレビューの実際についてFernandez氏にインタビューした。あなたは講演で、コードレビューはソフトウェア開発で最も知られていないプララクティスの1つだと言いました。ほとんどの開発者は、コードレビューの大きな重要性、コードレビューをする理由、正しく実施するためのテクニック、それらがもたらす様々なメリットをわかっていません。時々一部のコードをレビューする人はいます。レビューが開発プロセスに深く浸透し、それにより潜在能力をフルに発揮できている組織を見つけるのは、非常に困難です。文献には数多くのテクニックが載っていますが、現場ではなかなか見れません。開発者はレビューをピラミッド型の監督のように考えがちです。技術リーダーがチームのコードをレビューし、一部のシニア技術リーダーが彼らをレビューし、といった具合です。この方法でやっているプロジェクトもあります。それでも、新米デベロッパーによるレビューには独自のメリットがあります。コードレビューに階級はありません。チームの最年長者だからといって、そのコードはレビュー不要というわけではありません。滅多にないことですが、コードに欠陥がなくても、レビューはメンターシップとコラボレーションの機会を与え、コードベースのコード理解度のばらつきを最小限に抑えてくれます。1つよくある誤解は、レビューはバグを減らすのに役立つだけであり、それを証明する確かなデータがあることです。このあと見るように、この他にも別のメリットをもたらしてくれます。別の質問で答えさせてください。そのことを保証できますか?オープンソースプロジェクトの大きな強みの1つは、まさに、コードがレビューされる頻度と激しさにあります。kernelの場合、変更はまず設計段階でレビューされ、それから初期の開発中、そして最後にサブシステムのメンテナーとその他利害関係者全員によってレビューされます。このプロセスにより、全ての変更が配布にふさわしいことを保証しています。実際、レビュープロセスは他の全ての開発プラクティスの土台として見ることができます。コードを個別に検査しない限り、全ての新機能にユニットテストやインテグレーションテストがあることを保証できません。オリジナルの作者以外の開発者が、全ての新機能に独自のテストがあること、またコーディング標準や読みやすさについて、手作業で確かめます。自動化ツールが役立つこともあります。テストで100%のコードカバレッジを要求するなら、TDDのようなテストプラクティスを実施してもよいでしょう。結局のところ、手作業による検査の代わりはありません。テストが妥当なものであり、テストすべきものを実際に検証していることを、誰かが確かめる必要があります。健全な報道局では、編集者のレビューなしに独自の意見を公表することは許されません。実際に、このQ&Aを書くプロセス自体、コードレビューに非常に似た気持ちを起こさせます。開発では、あるときは作者に、あるときは編集者になりますが、原則は同じです。最初のステップは、まず始めることです。あなたが適切だと思うやり方で、提案された変更をレビューしてみましょう。GitHubのpullリクエストやGitlabのmergeリクエストは、コードにコメントするのに最適なツールです。次のステップは、全てのチームで定期的にコードレビューを実施することです。メリットを最大限発揮するには、コードレビューを開発プロセスに統合する必要があります。どんなコードもコードベースにマージする前に、独立したレビュアーによる承認が必要になります。ポリシーが制定されました。変更は少なくとも、+1が2つ、-1なしのときのみマージされます。ワンライナーとパッチは+1が1つ、緊急の場合は全く精査せずにパスできます。これは非常にうまくいきました。全員が意思決定プロセスに参加していると感じ、やがて、触るのを恐れていた曖昧なコードはほとんどなくなりました。ルールは全体的なアイデアを維持しながら、より多くの(あるいは少ない)承認を要求するように調整しても構いません。誰でも変更を拒否することができ、コードを本番環境に投入するには同意を必要とします。コードウォークスルーの実施は、長い歴史のある素晴らしいプラクティスです。オリジナルの作者とレビュアーを集めて、変更を追いかけていきます。作者が自分のコードを説明するだけで何も学んでいないなら、あなたは間違っています。あなたは常に、早期にレビューし、頻繁にレビューしなくてはなりません。作者らが自分たちで何ヶ月も取り組んだためにプロジェクトが失敗するのを、私はいくつも見てきました。彼らはデリバリーできませんでした。コードレビューは、他のチームメンバーからインプットを得るのに最適な方法です。レビュアーの観点からは、指示を与えるのではなく、全てを質問にすることが重要です。「これをこう変えて」と言うのではなく、「なぜこれが必要なのですか?」と質問するとよいでしょう。すぐれたレビューを行うことはアートのようなものであり、それ自体、多くの相反する観点があります。あまりにも頻繁なpullリクエストは戦場やエゴ地雷をもたらします。正しい規律が必要です。間違ったレビュアー選びや、開発プロセスにおける遅すぎるpullリクエスト送信など、既知の落とし穴がたくさんあります。早く始めれば始めるほど、最終的により良いものが得られるでしょう。私の経験上、あなたは辛抱強く、自然に受け入れられるまで、独立したレビューという文化を組織に浸透させる必要があります。レビューは、開発プロセスにおける未解決の問題を明らかにするのに役立つのを考慮すべきです。プロセスで見つかった問題は通常、持病のようなものです。pullリクエストでエゴや序列が問題なら、おそらくそこに解決すべき確執があるためでしょう。最初に、コンピューティングにおける聖杯を言わせてください。バグが少なくなります。これが片付くと、メリットはさらに広がります。チームメンバーは、たとえ自分が書いたものでなくても、全てがどのように動くのか学びます。factor)が増加します(そしてリスクが減少します)。上記の直接の結果として、より多くの人が、すぐれたコードを知ります。バグが本番環境にデプロイされても、もう単独犯はいません。他の人もそれにサインしているためです。責任が小さくなるということは、もっと自信を持ってリスクのあることができることを意味します。お互いに助け合うことは、何かをともに達成していると感じさせます。彼らはチームなのですから。pullリクエストの時だけでなく、必要な時に助けを求めることも学ぶでしょう。彼らのコードをレビューするだけでなく、他人のコードをレビューさせることで、新米をメンタリングするのが非常に簡単になります。コードがレビューされるとわかっていると、手っ取り早い方法を取ることが少なくなります。これらの理由で十分でければ、ひとつ悪い瞬間があってもプロダクトやチームが破滅することはない、とわかることによる安心感について考えてください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。