ソフトウェア開発、その評価、コスト管理、テストの問題について多くの本が書かれています。 技術マネージャーとして、成長中のプロジェクトで技術的負債を管理し続けるのに役立った実績のある実践を共有したいと思います。
適切な場所で柔軟性を維持します。
建物を設計する方法でソフトウェアを設計します。 建設中の何かがゆっくりと動き、何かが速く動きます。 家具や壁画などの一部のコンポーネントは、建物自体に直接関連していません。 壁が互いに位置する角度を変更することは非常に困難です。 優先順位を付ける必要があります。
プログラムで柔軟にできることとそうでないことを理解することは、現在の要件だけでなく、将来の要件にも当てはまります。 これが、ソフトウェアの作成が非常に難しい理由です。 技術製品を供給するだけでなく、未来を予測しようとしています。 そして、未来は暗闇に包まれており、常に時期尚早な最適化のリスクがあります。 どのコンポーネントが基本で、どのコンポーネントを簡単に変更できるかを選択する必要があります。
ソフトウェアという言葉（文字通り「ハード製品」-ハードウェアではなく「ソフト製品」）は、すべての柔軟性を意味するため、コンセプトの本質をゆがめます。 すべての柔軟性は、努力するのに理想的です。 ただし、真実は、非常に密接に関連するコンポーネントを持つより厳密なシステムを構築する方がはるかに簡単だということです。 たとえば、モノリシックアプリケーションでは、要素はマイクロサービスのセットよりも密接に関連していると言えます。 モノリシックアプリケーションの明らかな利点は、そのシンプルさです。 マイクロサービスベースのアプリケーション用に少なくとも1行のコードを書きたいですか？ 最初に、システム要素のデータ交換、調整、およびアクセシビリティの要件の膨大なリストを調べます。
これは、マイクロサービスがモジュール間の通信の問題を解決するという意味ではありません。 モジュールをネットワークに接続して、明確で定義済みのドメイン境界を構築できるようにしますが、接続自体は避けられません。
柔軟性は高価です。 将来、要件がどのように変化するかというアイデアで何かを作成した回数を数えることさえできません。それから、変更が必要なのは「固定」部品であり、柔軟なものは柔軟である必要はないことを発見しました。 最初は自分は不運だと思っていましたが、今では単に計画を間違えていることがわかりました。
ソフトウェアは、建物とは異なり、別の方法で廃止されます。 要件が変わらない場合、建物の場合のように、基礎は移動せず、崩壊し始めません。 ソフトウェアは摩耗しません。 ただし、その基盤は新しい要件の影響を受けます。 スタートアップが正しい選択をすることは非常に困難です。 彼らはクラウドサービスの助けを借りてこの問題を解決しようとしており、最初からスケーリングの可能性を築いています。 成長に伴うコストと速度の管理を最適化するには、多くの基本的な作業が必要です。 最新のクラウドソリューション、マイクロサービス管理メカニズムなどでも。
速度のリファクタリング
リファクタリングは、全体的な速度を向上させる最良の方法の1つです。 これはすでにたくさん言われています。 十分に大きなコードベースには、リファクタリングするものがあります。 主なことは、将来の簡素化と柔軟性が必要とされる適切な場所でリファクタリングすることです。 推測ゲームに似ていないため、新しい機能を導入する前にリファクタリングするのが正しいでしょう。
コードを書く前に、それを捨てなければならないことと調和してください
技術的な負債を減らす簡単な方法は、コードは一時的な実験にすぎないことを理解することです。 たとえば、別のコードブランチを作成し、実装可能なプロトタイプをすばやくスケッチすることにします。 この機能ですべてが正常に機能する場合でも、必要に応じて再度コードを記述し、古いコードを破棄する必要があります。 このようなプロトタイピングは特定のものであり、多くのリスクを伴います。チームの一部の人々は標準を下げる必要があります。 ただし、この方法では時間を節約できます。
テストの操作とコードの分析
テストは生き方であり、神聖な習慣です。 小さなプロジェクトであっても、テストはプロセス自体にかかる時間よりも多くの時間を節約します。 時々すぐに見ることができ、時には後で見ることもできます。
会社はコードレビューを行う必要があります。 テストをいくつ作成するか、リファクタリングできるかどうかは関係ありません。 他の人はあなたが逃した瞬間に気づくでしょう。 間違い バグ。 タイプミス。 はい、何でも。 多くの企業では、3組の目でコードの各行をチェックしています。これは一般的なルールだと思います。
テストとコードレビューの頻度は、障害が発生した場合にプロジェクトに生じる害に見合ったものにする必要があります。 ソースコードには、インターフェイスコードよりも徹底的な検証が必要です。 インスリンポンプの動作に関連するソフトウェアは、モバイルアプリケーションよりも真剣にテストする必要があります。 「速くして、分解する」というスローガンでインスリンポンプに取り組んでいるチームを想像できますか？ （Facebookのマントラとマーク・ザッカーバーグのモットーである「高速化と破壊」）。
ひどく機能している機能を殺す
私のエンジニアの友人であるノア・ソープはかつて私に言った：「私たちは毎日、コードのすべての行に支払います。」 コードが少なければ少ないほど、支払いは少なくなります。 プロジェクトで作業するとき、各機能がどのように機能するかが重要です。 定期的にチームを集めて、改善する機能と削除する機能を決定します。 これは、自分の好きな機能が機能しないことを自分に認めることがあることを意味します。
理想的な状況は次のとおりです。コードを記述する前でも機能が正しく動作しないことを理解しています。 最初の防衛線は、紙のプロトタイプとユーザーテストです。 ただし、常にプレッシャーがかかります。 この製品を使用して、決して実現する必要のないひどい機能を追加するように求める人々の声をいつでも聞くことができます。 または、追加できる可能性のある機能ですが、後で。 これは、製品管理と技術設計が出会う場所です。たとえ新しい機能を作成するのが一般的であっても、それでも料金を支払う必要があります。
依存関係を最小限に抑える
あなたも中毒のために支払う必要があります。 依存関係は内部および外部です。 内部のものは、ソフトウェアが依存するライブラリとフレームワークです。 外部-これらは、ソフトウェアが関連付けられているサービスです。 ライブラリは通常それらに関連付けられているため、サービスに二重に依存しています。
ライブラリをプロジェクトに追加すると、ライブラリ全体とその使用に対して料金が発生します。 したがって、各ライブラリ、各プラグインの必要性を正当化する必要があります。 最小でも。 それらはすぐに追加されます。 あなたがバランスの取れたアプローチを持っている場合、あなたはあなたがどれほど速く進歩するかに驚くでしょう。
これらのすべての方法は、会社の仕事の一般原則になり、その使用に適した環境が作成されれば、より簡単に適用できます。 プルリクエストリクエストで高レベルのコードレビューを維持します。 継続的インテグレーションを維持しながら、継続的にテストを続けます。 主な機能について毎月議論します。 「リファクタリング：既存のコードの設計の改善」など、適切なアプローチについて説明している紙の本を手元に置いておきます。 そしてそれらを読むことを忘れないでください！
何を構築しているのかを明確に理解することが重要です。 それは海岸、典型的な住宅またはガラス美術館の秘密の隠れ家でしょうか？ この質問に対する答えは、チーム全体で同じでなければなりません。 そのため、技術的な債務管理は、単に技術マネージャーや開発者の仕事ではありません。 これは一般的な作業です。 結局のところ、それは計画から始めて、製品開発プロセスのすべてのステップに影響します。
編集者から
トピックに関するNetologyコース：
- フルタイムプログラム「 デジタルプロダクトマネージャー 」：5か月のトレーニング、20名の有名なRunetエキスパート、100時間以上の練習。
- オンラインプログラム「 Profession Product Manager 」。
- オンラインプログラム「 柔軟な開発方法論：スクラム、カンバン、変更の実装 」;
- オンラインプログラム「 製品の作成：分析、開発、プロモーション 」。