後で修正することはありません - チームを流砂から引きずり出す方法

テスターから始まるスタートアップはありません。

それから 2 年後、そのスタートアップは、ビッグバンですべてを書き直さない限り、これまでで最大の顧客のために新機能をリリースすることはできません。これを何度も見るのは苦痛です。

ソフトウェアの衛生的な品質を維持するための簡単な方法があるため、このような状況に陥ることはありません。

まず、恐れを受け入れてください。エンジニアは勇敢な人々であり、懸念があることをすぐに認めることはありません。しかし、私たちはそうした懸念を認め、共有するのが早ければ早いほど、それに直面する準備が整います。

今日のソフトウェア構築方法

私たちはとても急いでいるので、いつも遅れます。テストする時間はありません。単体テストの時間はありません。リファクタリングする時間はありません。

まあ、私たちがエンジニアリング チームとして自分自身を妨害し続けている間は、それを正しく行うための十分な時間はありません。

どれくらいの時間がかかるか尋ねられますが、単体テスト、手動テスト、さらには API テストとリファクタリングを見積もりから除外し続けています。

したがって、次のようなソフトウェアを構築します。

• 速くて汚い

• 速くない、まだ汚れている

• テストされた迅速で楽しい斜めのパス

• それ以外はすべて、エッジ ケースと見なされます。 (エッジケースのようなものはありません。)

  
  

クイックやダーティにノーと言い、高速で安定したソフトウェアを構築する勇気のある人はほとんどいません。

見積もりから除外する必要があるのは、品質ではなく範囲です。

あなたが取り組んでいるそのコンポーネントの品質について何を知っていますか?

• 壊れやすいことはわかっていますが、非常に壊れやすいため、触れたくありません。

• あなたはこれをずっと前にやったことがあり、ほとんど触れていないので、うまくいくはずです。

• あなたはそれが壊れやすいことを知りません。

• テストはなく、実際にどれほど壊れやすいかをテストして公開する人もいません。

  
  

この汚いソフトウェアを毎日扱って満足していますか?

仕事の質が良くないことを知りながら、日々の仕事の質を妥協することに満足していますか? 「掃除する時間がない」と対処し、それでも汚れていて、掃除しないと先に進めないので遅れます。

あなたが次の就職の面接にいると想像してみてください。現在の仕事で自慢できることは何ですか?プレッシャーの下でパフォーマンスを発揮し、深夜の修正を行うことができますか?彼らはそれであなたを愛しますが、なぜあなたがそれについて何もしなかったのかとあなたに尋ねるでしょう.多分それはあなたの仕事ではありませんでした。

これらの決定を下すのは、チーム リーダーとエンジニアリング マネージャーでした。もしそれがあなた次第だったら、あなたは何かをしたでしょう。コードをリファクタリングする必要があること、レトロごとに技術部門の時間を計画する必要があることを伝えましたが、誰も耳を傾けませんでした。

まあ、何だと思いますか-許可は必要ありません。仕事の質はあなた次第です。くだらないコードを書くよう強制することはできません。時間的プレッシャーは短期的な言い訳です。迅速で汚い解決策はプロジェクト全体を遅らせ、最初に正しく行う場合よりも多くの費用がかかります。

後で修正することはありません

その違いを喜んで作りますか？

次に、これが何をすべきかです：規律を取得します。申し訳ありませんが、それ以外の方法はありません。そして、それはすべてのレベルにあるべきです。

より高品質なコードを構築するための最初のステップは何ですか?

ロギングとアラートの実装

ロギングとアラートのためのツールはたくさんあります。これが最初に行うことです。ソフトウェアがクラッシュしているのに、あなたはまったく気づいていません。

例外アラートからチケットを簡単に作成し、それらを「既知」としてマークするか、報告されたらグループ化できるソリューションを見つけてください。

アラートを監視して報告するためのチーム ルーチンを構築する

つまらないと思われる場合は、質問させてください。勤務時間中、ゾーンの奥深くにいますか?すべての会議と重いプログラミング作業の後、集中力を少し和らげる必要があります。そうですね、アラート チャネルをブラウジングする方が、他のチャネルをブラウジングするよりもはるかに優れています。

「チケットを報告する」ボタンまたは「既知としてマークする」ボタンをクリックするだけです。興味をそそられたら、おそらく 1 つまたは 2 つの問題を解決するでしょう。

ここに最大の議論があります。いくつかは修正できますが、誰かが確認する必要があるテストを作成していて、デプロイする必要があり、これによりチームに予定外の作業がさらに発生します。

首相は、私たちが優先度の高い項目に取り組んでいるのではなく、金メッキの小さなアラートに取り組んでいると怒鳴るでしょう.

その中にすべての「M」の役割を持つチームは、それについて同意します。

経験則を公開する - 「小さくてリスクが低いように見え、他に進行中の作業がまったくない場合は、それを実行して修正してください。スプリントごとに「範囲外」に修正された 1 つまたは 2 つの小さなアラートを処理できます。 、計画されたものと一緒に。」

それだけです、非常に簡単です。

ログとアラートのクリーニングを 1 つずつ開始する

不定期の修正に加えて、クリーンアップを適切に計画してください。計画とは、重大度や優先度に関係なく、問題を修正するために毎日/毎週の時間を割り当てることを意味することに注意してください。最初の 5 つを修正するよりも、優先度の評価に多くの時間を費やすことになります。

開発者ごとに 1 つのアラートがあることを確認するか、ほとんどの時間モブをしている場合は、アラートに毎日のタイムスロットを設定します。私は朝一番にそれをします。

繰り返しますが、これは新しい機能ではなく、重要な優先事項に時間を浪費しているように見えるかもしれませんが、これらの隠れた問題のために、重要な優先事項はすでに遅れています.あなたはすでに遅れています！

空の Try-Catch ステートメントをすべて削除して、クラッシュさせましょう!

アラートとログは多くの情報を公開しますが、非表示にしたものをログに記録することはできません。だから、カーペットの下であなたの問題を一掃するのをやめてください.

2 年前にクラッシュしたものと、今日ではまったく異なる理由がわかりませんでした。クラッシュさせて、修正します。おそらく同じようにクラッシュすることはないか、クラッシュすることさえないので、いずれにせよ、コードはそれらがなくてもより良い形になります。

今すぐ単体テストを書き始める

私は真剣です。あなたは今、いくつかのコードに取り組んでいます。そうすれば、単体テストを書くことを妨げるものは何もありません。

ああなるほど！単体テストの準備が整ったインフラストラクチャはありませんね。来て！とにかく、その志望機能を遅らせるつもりです。

単体テスト フレームワークと CI をセットアップしてテストを実行するのに 1 日以上かかることはありません。早くやれよ。

バグ修正のために TDD を開始する

「何が問題なのか、どのように修正するのかわかりません。まだ存在しないコードのテストを書くことはできません。」

親愛なる開発者の皆様、テストの目的は仮説を確認することです。これは、ソフトウェアのテストだけでなく、テスト全般に当てはまります。したがって、テストを作成する必要があるのはコードではありません。期待される動作と結果が必要です。

さて、ユーザー ストーリーが曖昧で不明確で、ユーザー ストーリーに対してテストを書き始める準備ができていない場合は、これに対する解決策もありますが、その前に、バグに対してテスト ファーストのコードを書き始めます。

「期待される結果」と呼ばれるバグの説明のコンポーネントがあり、再現する手順はテスト ケースです。したがって、テストケースはすでに目の前にあります。ここで、修正のコーディングを開始する前に、最初にコーディングします。

テスト駆動開発とは、正しくやったということではなく、正しい仕事をしたことを検証するテストを書くことです。単体テストは、それが正しく行われたかどうかを検証します。

カバレッジ ロードマップを描く

テストの自動化と技術的負債は、同様の悲劇的な運命をたどります。「すべてをカバーすることはできず、すべてをクリーンアップすることもできません。オーバーヘッドが多すぎます。そのための時間がありません」という理由で、開始されることはありません。

聞いてください: すべてを自動化する必要はありません!

ただし、ミッション クリティカルな要素 (優先度の高いユース ケース、重要なインフラストラクチャ、およびコア機能) は確実に自動化する必要があります。好きなように呼んでも構いませんが、ビジネスはコードとインフラストラクチャの 20% に依存しており、顧客は機能の 20% を使用しています。

あなたは私がこれでどこに行くのか分かります。

これらの機能の自動テストを今すぐ書き始める必要さえありません。最初に行う必要があるのは、それらに優先順位を付けることです。

高レベルおよび低レベルのアーキテクチャ図の前でチームとして集まります。ありませんよね？それとも、2年半前に撮ったホワイトボードの写真ですか？知っている。

はい、半日かけて最新の状態にする必要があります。幸いなことに、便利なツールが用意されているので、手動でメンテナンスする必要はありません。いくつかの調査を行います。

結局のところ、あなたは R&D チームですよね!?

完全なカバレッジを目指すのではなく、低リスクで高い信頼性を目指す

最新のアーキテクチャとインフラストラクチャを図解するときは、次のすべての場所にメモや円を追加するか、太字にするか赤く塗りつぶします。

• ビジネスとソフトウェアにとってミッション クリティカル

• 必死にリファクタリングが必要です。そうしないと、他のミッションクリティカルな機能を常に延期し続けることになります。

• 数日後にまた壊れてしまうので、絶えず壊して時間をかけて修理してもほとんど無駄です。

図面の準備ができたら、チームと一緒に座って、これらすべての丸で囲まれたコンポーネントのテストが必要なものについてブレインストーミングを行います。

• 「これは多すぎる！これをすべてカバーするには、他のすべての作業を停止する必要があります」というわなに陥らないでください。これらすべてを一度にカバーする必要はありません。しかし、計画が必要です。次に、別のボードを開いて、テストの目標を書き始めます。例:

  
  

  • すべての fetch-data API リクエストの成功と失敗をカバーして、不正なリクエストを送信していないことを確認し、失敗した場合はベンダーが原因で失敗したことを確認します。

    
    

  • ミッション クリティカルなユーザー ジャーニーの概要を説明します。ユニットに分解します。単体テストを記述します。テスト ピラミッドが発明されたとき、ユニットはメソッドではなくコンポーネントを意味していたため、メソッドやクラスではなく機能をカバーしていました。

    
    

  • 渋滞を特定し、渋滞を解消する方法を決定します。

    
    

  • 正しく行うように計画してください。あなたの素早い汚いコードは、汚いテストで汚いままです。

私は意図的にカバレッジ マップを使用し、テスト ピラミッドを使用しませんでした。この段階では、手動または自動のテストが実施されていないと、ピラミッドの準備ができていないからです。

多くのチームは、最初に 96% の単体テスト カバレッジを達成してから、統合テストなどに移行するという間違った印象を持っています。最新の単体テスト カバレッジの問題は、機能ではなく、メソッドとクラスをテストすることです。

さらに多くのチームが UI 自動化から始めていますが、これも同様に間違っています。

それは実際にあなたができる最悪のことであり、失敗する運命にあります.

したがって、ピラミッドの最上部または最下部から開始するのではなく、代わりにリスク マップを作成してください。

一部の機能は大規模な統合テストが必要な場合があり、他の機能は大規模な UI テストが必要な場合があります。次の部分は、実際にはすべてが依存するコア機能である可能性があり (別の危険信号ですが)、上から下まで完全にカバーする必要があります。

または、データ収集サービスであり、たとえば API のパフォーマンスに集中する必要があります。

厳しいテストが必要なソフトウェアのホットスポットのマップを作成します。

次に、そのテストを自動化する方法を考えてください。

流砂では先に進めず、そこから抜け出せるのは自分だけ

まとめましょう - テストがなく、コードの状態が悪く、時間がありません。 「時間がない」という理由で妥協し続けます。あなたは完全に満足しているわけではありません。あるいは、少なくともあなたはかなり無知です。

彼らが満足しなければ、あなたは次の会社に移ります。

ええと、昨年は状況が大きく変わりましたよね!?雇用され続けるには、優れた開発者である必要があります。企業は、貢献度に関係なく人を捨てる可能性があることを学びました。

それでも、企業が維持するために全力を尽くすエンジニアがいます。それらの 1 つになるには、変化を推進し、ビジネスがあなたのような人々に依存していることを常に証明する必要があります。

誰もが粗末なソフトウェアを書くことができますが、本当に優れたソフトウェアは、優れたソフトウェアを喜んで書くだけでなく、他の人に刺激を与え、コード品質の文化を広めます。

流砂では先に進めず、抜け出せるのは自分だけです。