コードを恐れないでください

こんにちは。



私が一緒に仕事をした多くのプロジェクト、大規模なプロジェクトは、レガシーになり、ひげを解きほぐし、その結果、開発は非常に困難になりました。変更を加えるのが非常に難しいために、プロジェクトが終了したばかりの場合がありました。今日は、プロジェクトでの私の経験と、なぜ私がこれらすべてをあなたに書いているのかについてお話します。もちろん、すべてが非常に主観的です。



そこで、水をかき集めて船が沈むのを防ぎたいという船乗りのように働き、試してみましたが、プロジェクトの質は着実に低下しており、いくつかの理由がありました。



あなたはそれらを簡単に認識するでしょう、彼らは普通の患者です、私はあなたにそれらについて思い出させます：

1. アーキテクチャが不十分で、新しいソリューションを実装するのは困難です
2. コーディングエラー
3. 自動テストはありません

その結果、最初の1〜2年間のプロジェクトの開発結果によると、レガシー、くだらないコード、秘密の通路のある絡み合ったトンネル、「私が知らない方法で機能する」ペトログリフの混合物が得られます。



私はこれほど詳しくは説明しません。これはリファクタリングの第1のトピックなので、私が行った結論に直結します。

開発された製品は集合的な専門知識です

チームに1人のメガ開発者がいて、本当に興奮していてうまく機能している場合、チームは常に間違いを犯し、常にプロジェクトを引き下げるため、彼だけではクリーンアップできません。



もちろん、現在のチームにリファクタリングタスクを与えることを試みることができます。そうすれば、それを溶接した人は自分の作業結果をやり直し、同じことを、おそらく最初よりも少し良くするでしょう。



したがって、チームのアップグレードなしで根本的な品質のアップグレードを期待するべきではありません。



これは悪循環の第1位です。チームの専門知識は十分ではありませんが、リファクタリングが始まります。注意して、それを書いたのと同じポゾンがそれを行います。



あるいは、レビューを実施してこれらのエラーをクリーンアップする優れたリードを置くこともできますが（彼はそれをやろうとしますが）、最終的には、うまく機能しない人にとっては頭痛の種になり、開発者の交代、または彼らが去る、そして再び開発者に取って代わります。



それはプロジェクトの一種の自然な選択になるでしょう。

人々はコードを変更することを恐れています

ようこそ、これはプログラマーのための心理学セッションです。



プログラマーはコードを変更することを本当に恐れており、理解することができます。

1. テストが不十分かどうか
2. コードがどのように機能するかは明確ではありません
3. 日付は
4. リソースなし
5. 管理者は理解しません（通常ですが、管理者が火事になっている場合は、すべてがうまくいきます）

その結果、プロジェクトを下にドラッグする古い紛らわしいレガシーコードは「触れない方が良い」と認識され、その結果、この「触れない」は永遠に続き、さらに悪いことに、特定の方法でコードを書くことを余儀なくされ、他の技術的な問題を引き起こします。次に、プロジェクトをプルダウンします。



私たちはプロジェクト、くだらないコード、チームの恐れを取り、それを時間で乗算します、そして私たちは莫大な技術的負債を手に入れます、それは立ち上がって、チームがプロジェクトを通常のように素早く動かして開発することを許しません。



プロジェクトは崩壊し始め、締め切りは中断され、新機能はプロジェクトにとって非常に高価になり、開発者は神経質になり始め、いくつかの休暇、新しいものを見つけるのが難しくなります、あなたはアイデアを得る...



だから、これは問題＃1、コードとリスクの恐れだと思います。



経験から、技術的な負債を残した場合、これは潜在的な爆弾、または少なくともレーキであることがわかっています。それらを100、1000のままにしておくと、地雷原ができて、そこに行く（プロジェクトを開発する）だけでなく、這うこともできません。



したがって、プロジェクト開発の平均速度を節約し、品質を低下させない唯一の方法は、上限のおかげで、品質に注意を払い、リファクタリングすることです。



評議会の発砲、誰もがそれについて知っていますが、実際には上記のリストはどこにも行きませんでした、それであなたは崩壊しているプロジェクトを手に入れるので、それを取り、それをリファクタリングすることはできません、そしてなぜですか？



テストがないため、コードがどのように機能するかは明確ではありません。その結果、車の図面と組み立てを変更する代わりに、VasyaとPetyaがグラインダーを取り、Solarisを鋸で挽き、Tavriaに戻しましたが、うまくいきません。どうして？-ああ、でもその影響/動作/タスクについて知らなかったので



はい、テストなしでリファクタリングしてから安定化できますが、多くのユーザースクリプトや必要なコード実行スクリプトが失われたり、安定化に非常に長い時間がかかる場合があります。



したがって、もう1つの悪循環-コードをそのままにしておくことはできませんが、大きなリスクがあるため、いわばリファクタリングすることもできません。



Legacyは必要ないことがわかりましたが、それを取り除くことは恐ろしくて危険です。そのため、チームは、後でプロジェクトのさらに危険な解決策を得るために、Legacyを「最も危険性の低いオプション」として残すことがよくあります。

テストが鍵です

リファクタリングのロックを解除して安全にするためには、最初にすべてのケースをテストでカバーする必要があります。次に、SolarisをカットしてTavriaに組み立てると、溶接が停止し、「こんにちは、Solarisが必要です。ここで混乱しました」と表示されます。



テストにより、リファクタリング中のミスを回避できます。安全を確保するために、リスクが機能して問題が発生することを非常に恐れることなく、必要に応じてプロジェクトをカットできます。



したがって、次のチェーンが得られます。

テスト->リファクタリング->さようならひげとレガシー



シンプルで美しいように聞こえますが、実際にはテストはほとんどありません。または、まったく発生しません。通常どおり、これにはいくつかの理由があります。

1. 開発者は、テストを別のトピックと見なし、評価に投資せず、開発とは別に作成します。プロジェクト管理者がそう考えて、期限に間に合うようにテストを削減したい場合、さらに困難になります。
2. テストは時間であり、プロジェクトを今すぐ引き渡す必要があります。テストを作成する時間はありません（理論的には、これはポイント番号1と同じです）
3. プロジェクト/コンポーネントは単純ですが、なぜテストがあり、すべてが非常に単純でそこで機能するのですか？
4. 最初にコードを記述し、次にテストでカバーします。しかし、いいえ、私たちはそれを理解できませんでした、プロジェクトは静止していませんでした、時間がありませんでした。したがって、このタスクは永遠にブラックボックスにあります。

実際には何百万もの理由がありますが、実際には、リファクタリングがブロックされ、その結果、品質が向上しません。



したがって、テストは重要なタスクであり、テストがなければ、プロジェクトの長期的な高品質の開発は不可能ではないにしても非常に困難になります。

ヒューストン、どうする？

私がこの記事を書いているのは、誰もがそれを理解しているわけではなく、少なくともそれを読んでテストやリファクタリングを書きたいと思う人がいるからです。つまり、私がこの記事を書いたのには理由があります。



したがって、誰もが宿題を持っています-不十分に書かれたモジュール、コンポーネント、何かを取り、そこでリファクタリングしたいものを見つけ、このモジュールまたはコンポーネントのテストを書いて、リファクタリングします。



その結果、テストは次のとおりであることがわかります。

1. コードを学ぶ方法。単に読むよりもはるかに効率的かもしれません。
2. 安定
3. 古いコードは実際にリファクタリングでき、プロジェクトの品質を向上させることができます

私はすべてを一気に、非常に主観的に書きました、そして多分私は間違っています、これは私の経験です。たぶん私はそのようなプロジェクトに出くわしただけなのかもしれませんが、それでも情報は役に立ちます。それを読んで考えているのであれば、これも良いことです。



皆さんに良いコード、テスト、そして品質の向上を願っています-それが私たちが雇われている理由です、うまく働きましょう。



PS必要に応じて、コメントにリファクタリングの経験を書いてください。誰もが興味を持つでしょう。