遅延駆動型の開発

人はひどく怠zyな感染症です。 いいえ、もちろん、私はあなたのことを言っているのではありません！ さて何だ！ 私はそうです、自分自身について。 人類の約99％。 しかし、あなたについてではありません。 あなたは自分で決めます。 しかし、それらの99％は、まさにそのように起こりました-非常に怠け者です。 誰かがこれを否定し、誰かが我慢し、誰かが戦う。 しかし、個人的には、これは、たとえば2本の腕と2本の足など、私たちの種の不可欠な特徴であるように思えます。 翼やgがないと殺される可能性があります-しかし、あなたはそれが何であるかをうまく利用することを学ぶことができます。 だから怠lazです。 なぜ拒否するのですか？ 完全に使用する必要があります。 そして、ここでは、ITに関係があるので、これが私たちの職業にどのようにあるかを見てみましょう。


最初は、状況は重要ではありませんでした。 数十年前に使用されていたこれらのテクノロジーを見ると、それらはすべて人々に対して非常に要求が厳しいことがわかります。 30年前のコンピューターで最も驚いたのは、そのサイズや生産性の低さではな​​く、当時のプログラマーがいかに賢く、正確で、責任があり、有能であったかです。 パンチカードの余分な穴-埋め立て地での1日の作業。 マンハッタンプロジェクトの計算方法に関するファインマンの話を読んで、私はこれらの計算がまったく行われなかったことに驚きました。 今日、私にはそのような意志と責任を持つ人々を見つけることは非常に難しいと思われます。 レニはここに居ませんでした。 しかし、コンピューターはほとんどなく、エンジニアも比較的多かったので、そこにはまともなコンピューターがいました。

時間が経ちました。 ますます多くの人々がこの職業に参入し始めました。 どこから？ 私が最初に書いた99％のうち。 私たちの、怠け者の。 場合によっては、結果に対して遅延がすぐに機能しました。これにより、インターフェイスが単純化され、プロトコルが統一され、不要なものが破棄されました。 また、怠inessがプロジェクトの失敗につながった場合もあります。 何かを解決する必要がありました。 そして、ソフトウェア開発の方法論が現れ始めました。

喫煙室で耳にした会話から

-開発方法論は、「通常のプログラミング」よりも優れています！
-いいえ、方法論を「切り株の森の月で裸の夜にだけコードを書く」と呼ぶなら、これは「通常のプログラミング」よりも良くないからです

この分野でいくつもの異なるものが発明されました！ ここに、例えば、書かれたコードの正式な検証のアイデアがあります。 まあ、クール！ 作成したコードが完璧であることを数学的に証明します。 夢。 歌。 しかし、今日はどこで使用されていますか？ ローバーで？ ペースメーカーのソフトウェアに？ それだけですか？ 100万のうち1つのプロジェクトのどこかに。 まあ、なぜですか？ また、コードを書いた後、コンパイル、ローンチ、スモークテスト、テスターに​​よる検証が成功した後、コードの正確さの正式な証拠を得るために座って座るプログラマーを想像してみてください。 あなたは怠け者ではない人の多くを知っていますか？ 私は数百人の馴染みのあるプログラマーの一人です。 また、「数百人の知人」は、平均を大幅に上回る別の結果です。

さて、またはここに滝のアイデアがあります 。 いい考えだ。 しかし、それ自体もすでに生き延びていました。 理論家は言う：「現在の高いダイナミクスと急速に変化する要件に耐えない。」 うーん、ナンセンス。 問題は、「滝」の下で怠け者は何ヶ月も何年も隠れて何もしないということです。 まあ、そこに隠れることは良かったが、出口で-プロジェクトの失敗。 現代の「柔軟な」方法論は、「プログラマーにとって便利」であり、「現在の現実を満たしている」と宣伝しています。 またね スクラムは、怠け者を穴から非常に素早く取り出し、耳で引っ張って部屋の中央に置き、すべてのスポットライトをそれらに向けるだけです。 したがって、人気があります。

しかし、怠に関して、最も興味深いのはTDDです。 実際には、この記事を始めたところから来ています。すべての人は怠け者です。 しかし、TDDはこの怠さをなんとか工業規模で人類に奉仕することに成功しました。 ここを見て。

TDDなしでプログラムするとします。 すぐにコードを記述します。 たとえば、ある種の機能。 この場合、あなたは怠け者です。 関数の名前、引数の名前について本当に考えていないので、入力値をチェックするのを忘れるか、例外をキャッチしないかもしれません。 封印されたり、根本的な間違いを犯すことさえあります。 そして、これはすべて理解することができます-あなたは今、あなたの仕事の量を最小化しようとしています。 はい、明日はここでエラーが発生します。 または飛び出さないでください。 またはあなたと一緒に。 いずれにせよ、それはいつか後であり、それから我々は戦うでしょう。 そのような考えは弱められ、率直に書けるようになります。 さて、あなたは何ができますか？ 努力を最小限にします。

ここで、TDDを使用してプログラミングするとします。 テストを書くことから始めます。 この場合、もちろんあなたも怠け者です（しかし、何も変わっていません！）。 しかし、注意：量産コードを書くときではなく、テストを書くとき、あなたはもはや怠け者ではありません。 この場合、これが怠の表現です。

1. テストした機能を呼び出すための実際のコードがどのように機能するかにできるだけ似たテストを作成します。 それでは、コピーして貼り付けることができます。 まあ、またはドキュメントのように見えます。 これはすばらしいことです。必要なものを正確にテストし、時間を節約し、ドキュメントを受け取ります。
2. テストするクラス、メソッド、その引数の名前をどのようにしたいかについて考えます。 いいえ、このメソッドを書くときにこれについて考えているかもしれません。 しかし、私たちは覚えています-そこで、あなたはそれについて慎重に考え、何とか書くのが面倒になります。 しかし、テストを書くとき、あなたの怠inessの対象はテストです。 テストを単純でわかりやすいものにしようとします。つまり、呼び出されるメソッドの名前とそれらに渡される引数は、できるだけ単純で、明確で、それ以上ではないということです。 また、実際のコードはこれらのプロパティを自動的に継承します。
3. テストを書くときに怠け者になるのはとても簡単です。 通常、テストはそれほど大きくなく、コピー/貼り付けが非常に簡単で、2、3の文字を置き換えて、似ているがわずかに異なるものに変換します。 そして、別のものに。 しかし、これらすべてのテストをすでに作成しているので、どこに行くべきかはありません。何らかの方法で、それらを通過するコードを作成する必要があります。

道徳

怠azineはこれまでもこれからもそうです。 私たちはこのようにそれを取り、永遠にそれを取り除くことはできません。 しかし、この怠inessの方向を制御し、この怠inessを害にせず、利益をもたらすことができます。 正しく怠correctlyになるのを怠らないでください！