記事ディレクトリ
記事ディレクトリ
ガイド
最近、友人が、自分が参加したモジュールのコードが非常に混沌としていると愚痴をこぼしました。繰り返し機能するパブリック コンポーネントや、標準外のコード、その他の問題があったため、モジュール全体をリファクタリングしたいという衝動にかられ、思考が呼び起こされました。 。
よくある問題
チームメンバーのレベルがバラバラ、コード調整のための要件変更が頻繁に起こる、管理や開発仕様がしっかりしていないなど、チームで開発を行っている友人も同じような問題に遭遇したことがあると思います。全体のコード構造、繰り返し作成など ホイールなど 私の考えでは、これらの結果は多くの場合「割れ窓効果」の概念で説明できますが、モジュールの主な責任者がチームとモジュール コード内で適切な管理役割を果たすことができれば、このような状況は効果的に回避できます。
1. 割れ窓効果とは何ですか
割れた窓は、長期間修復されずに放置されると、徐々に建物の住人に放棄感、つまり管理者が建物のことを気にかけていないという感覚を与えることになります。その後、別の窓が割れ、人々がポイ捨てをし、落書きが始まり、深刻な建物の損傷が始まりました。比較的短期間で、建物は所有者の修復意欲を超えて損傷し、放棄された感覚が現実になりました。
2. 実際のチーム開発状況分析と組み合わせる
たとえば、開発プロセス中に開発者がコード仕様を合理的に遵守しない場合、作成された非標準コードは建物の割れた窓のようなものになります。担当者がこのウィンドウにパッチを当てて調整しないと、開発者は規定を守らず、どんどん勝手に落書きをしたりするカジュアルな状態になってしまいます。プロジェクト全体の規格外コードなどの問題が徐々に積み重なり、構造的なダメージが生じ始め、最終的には断念感が現実のものとなる。その中で、モジュールリーダーは重要な役割を果たします。
3. 友人からの提案
この点に関して、私は経験豊富な友人にも相談し、チーム開発におけるモジュール コードの品質管理についての見解をいくつか教えてくれました。
**バックグラウンド開発の友人: **モジュールには、主な責任者であり、モジュール全体を管理および制御できる人が必要です。要件の度重なる変更によってコードが変更される最も根本的な理由は、要件の本筋が明確になっていないことです。チームメンバーのレベルが不均一であるのは通常の現象であり、合理的な人員配置によって解決できます。多くの企業では、メインラインで必要な機能はベテランに引き継ぎ、新人はメインラインに影響を与えない業務機能の多くを担当することになります。
設計段階は非常に重要です。担当者は定期的にコード品質のスポットチェックを実施します。
**フロントエンド開発の友人: **コミュニケーションは非常に重要です。コミュニケーションの時間をケチらないでください。チームとして、すべてのコミュニケーションは意味があり、必要です。開発ログを記録します。日々の開発内容を記録し、修正のアイデアや理由を明確に書きます。将来的に他の人がコードを引き継ぐのに便利です。これにより、将来変更を加える際に影響を受ける領域を迅速に特定して明確にすることができ、引き継ぎ時の情報の損失や欠落を回避し、開発の繰り返しを回避し、コードの再利用を向上させることもできます。
担当者が必要であり、この担当者はこれらのタスクを適切に実行する必要があります。たとえば、チームにとって役に立たないいくつかの悪いコードは、インターンがすぐにチームに溶け込めるように、時間内に修正する必要があります。
4. まとめ
共通点は、何よりも担当者が管理的な役割を果たすことが重要であり、それが「割れ窓効果」において管理部門が果たすべき重要な役割でもあると考えている。チーム開発は開発効率を向上させますが、コードの品質管理の難易度も高くなります。合理的かつ効果的な管理により、建物は良好な構造を維持することができます。チームコードの品質管理に他に良い方法がある場合は、ぜひコメントして一緒に議論してください。