プログラミングはダメ! またはそのようなもの

The Daily WTFに掲載されている記事「 Programming Sucks!Or At Least、It Ought To 」の翻訳に注目してください。 この出版物は、実際の過剰なプロフェッショナリズムがどのように効率を妨げるかについて述べており、初心者よりも経験豊富な開発者向けです。



プログラミングは楽しいものではありません。 これは退屈で退屈なレッスンであり、もちろん、特技はありません。 彼と一緒に何をするにしても、プログラミングは確かに「セクシー」ではありません。



私はあなたの考えを知っています。 それをブログに書いている人は誰でも、すぐにプログラマのライセンスを奪い、キーボードを取り除いて、CP / M、8インチフロッピーディスク、1200ボーモデムを備えたマイクロコンピューターに永久に配置する必要があります。



もちろん、私を含め、私たちの多くはコードを書くのが好きです。 しかし、私たちはそれを好きですか?



なぜコードを書いているのですか?



ソフトウェア開発者は、仕事と趣味の両方でスキルを使用できるユニークな職業です。 家計を調整するために急いで家に帰る可能性の低い会計士とは異なり、私たちの多くは、楽しみと楽しみのために楽しいコードをいじくり回しています。



しかし、この記事では、 訓練されていない特定のプログラマーと彼の仕事に焦点を当ててみましょう。 実際、範囲をさらに絞り込み、「退屈な」ソフトウェアの開発者についてのみ話しましょう。 「退屈」とは、請求書の処理、企業のフリートの使用の会計処理、経費報告書の作成などを意味します。これらはすべて内部使用専用であり、特定の企業に固有の膨大な要件があります。 繰り返しますが、「退屈な」ソフトウェアで生計を立てていない場合、この記事は完全にあなたに当てはまるわけではありません。



「退屈な」ソフトウェアと「セクシーな」ソフトウェアの境界線があいまいになることもありますが、「セクシーなプログラム」は、SVN、Google Maps、Visual Studio、Firefoxなど、毎日定期的に使用するものです。 実際、プログラマとしての私たちは退屈なソフトウェアを使用する必要はほとんどありません。



ただし、開発プロセスの観点からは、図は正反対です。 「セクシーなプログラム」を開発するために支払われるのはごく一部の人だけですが、私たちのほとんどは退屈なルーチンのプログラミングに夢中になっています。



鈍いソフトウェアの基本



退屈なソフトウェアを定義するために、「情報システム」という特別な用語があります。 また、情報システムの目的は会社ごとに異なりますが、特定の要件も同様ですが、概してそれらはすべて同じです。 現実の世界をモデル化するデータベース、データの変更方法を決定するルール、データベースを操作するためのインターフェイス、およびさまざまなレポートがあります。



これらの情報システムを作成する正式なプロセスは、60年代に初めて登場し、70年代から実質的に変更されていません( 現代の構造分析は依然として驚くほど現代的です)。 基本的に、問題を分析し、データフローのマップをコンパイルし、これらのフローを構造化し、データベースを作成し、データベースを操作するためのインターフェイスであるプログラムを作成します。



「緑色の目をした」端末の「シンクライアント」から、PCアプリケーションの形式の「シッククライアント」に切り替えました。 次に、Web上の「シンクライアント」に移動し、Windows Presentation Foundationのようなプラットフォームで目を瞬くと、「シッククライアント」の隣に再び現れます。 それがそうであっても、私たちのシステムは同じことを続けています:データの書き込み/読み取り。



情報システムの開発はそれほど変わっていません。 Visual Basic 3.0を使用するかxHTMLを使用するかは問題ではありません。原則はほぼ同じです。データベースはユーザーの目に最も快適で友好的な光で提示される必要があります。 このために必要な(そして常に必要であった)コードはかなり退屈です:

txtFirstName.DisplayWidth = 30;

txtFirstName.MaxCharLength = 50;

SetTextBoxValidator(txtFirstName, Validations.LettersOnly);

txtFirstName.Enabled = securityContext.CanEdit;

txtFirstName.Value = customerRecord.FirstName;







これらの5行のコードは、UIのいくつかのプロパティを設定するだけです。 一部のフィールドは2つの異なる場所からアクセスできる必要があるため、フィールドごと、エンティティごとにこれを繰り返し、さらに1.5を掛けます。 次に、UIから取得したデータの検証と保存に必要なすべてのコードを追加します。 数学が失敗しない場合、その結果、退屈で退屈なコードが大量に得られます。



開発者のジレンマ



「落胆」と「退屈」は、開発者にはあまりふさわしくない言葉です。 私たちは多くの場合、コンピューターサイエンス(情報技術)の専門家を抱えるアナリストです。 そして、フロントエンドとバックエンドを削減するために、行ごとにはるかに多くのことができます。 おそらく、スキルと能力を使用して作業を促進できます。



これが障害の場所です。 マイケルA.ジャクソンがプログラム設計の1975年の原則で述べたように、プログラマーはしばしば、仕事の複雑さとトリックに対する一般的に理解できるが破壊的な欲求に救いを見出します。 単なるプログラム以上のものを作成することから疎外された彼らは、このプログラムを非常に複雑にすることで対応し、彼らの専門的スキルにふさわしい挑戦となるのです。



35年前のこの観察結果は、The Daily WTFで確認されています。 ここで公開されている最も洗練されたコードとストーリーは、開発者の習熟への渇望によって生成されます 。 これらの願望は決して妄想や悪意の結果ではなく、本能的です。



ソフトコーディングについて書いたとき、ほとんどの記述されたコード、つまり最も特別なビジネス要件を実装する最も具体的なコードのように見えるスニペットを与えました。 彼はかなり退屈だ:

private void attachSupplementalDocuments()

{

if (stateCode == "AZ" || stateCode == "TX") {

//SR008-04X/I are always required in these states

attachDocument("SR008-04X");

attachDocument("SR008-04XI");

}



if (ledgerAmnt >= 500000) {

//Ledger of 500K or more requires AUTHLDG-1A

attachDocument("AUTHLDG-1A");

}



if (coInsuredCount >= 5 && orgStatusCode != "CORP") {

//Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A

attachDocument("AUTHCNS-1A");

}

}









この記事の多数のレビューの中で、コードを「複雑にする」方法を示す、かなり面白いフィードバックを提供するものもありました。 そして、残念ながら、これらの例は、私が対処しなければならない単純なビジネス要件の実装を完全に示しています。



他の読者は、考えられるすべての設計パターン、インターフェース、拡張機能、およびその他のクラスの束を含む、いくつかの深刻なリファクタリングの提案を表明しました。 当然のことながら、システムとその要件の一般的な理解は言うまでもなく、この架空のコードが属するモジュールを一見することなく、これらすべてが行われます。



ジェームス・テイラーという男が1人もいました。彼は実際、開発者がそこにあるビジネスルールについて手を汚すという提案に対して、 私を馬鹿と呼びました 。 どうやら、私たち全員が複雑なUIインターフェースを備えた優れたエキスパートシステムを構築し、エンドユーザーがすべての汚い仕事を行えるようにする必要があります。



もちろん、現実世界に住んでいる私たちは、そのような「エキスパートシステム」が妖精、ユニコーン、およびランダムデータのロスレス圧縮の国にのみ存在することを認識しています 。 しかし、私たちの多くが受け入れるべきもう1つの現実があります。アプリケーション開発は面倒であり、XMLやデザインパターンの量はそれを変えません。



受け入れるだけ



私たちが毎日書いているソフトウェアは、その目的や目的に関係なく、退屈なものであるという事実を受け入れるのは容易ではありません。 雑誌の購読管理。 医療費請求レポート。 不動産レジストリ管理。 これらは世界を変えるプログラムではありません。 実際、彼らは誰かの顔に笑顔を引き起こすことはほとんどありません。 実際には、彼らの真の目的は、特定の労働者の生産性を高めることです。



どんなに退屈に見えても、私たちの仕事は単に雇用主に利益をもたらすことであり、私たちに満足することではありません。 これがプロであることの意味です。



燃えるような目を持つ多くの弁護士が最初の刺激的な訴訟にしがみつくと確信していますが、そのような決定がクライアントにとって最善の解決策であるならば、すぐに後退します。 建築家は、 のような機会を得るのを夢見ていますが、プロジェクトで荷下ろしドックを備えた大きな倉庫の建設が必要な場合、これが彼らが図面に置く唯一のものです。 雇用主が支払いバウチャーを管理するためのソフトウェアを必要とする場合は、「リアルタイムUIテンプレートでスケーラブルで認識可能なプラグインに基づくシステム」や、私たちが納得する何か他のものの必要性ではなく、それを入手する必要があります。



ソフトウェア開発の再考



ひらめきのない平凡な開発者と仕事をするのは無意味ですが、他の極端な見当違いの熱狂は、何倍も悪いです。 いくつかのバグと、涙なしで維持するのが難しいコードは、間違った方向に動機付けられた開発者がもたらす壊滅的な結果と比較して衰退します。



プラットフォームのすべて(「 Rubyを試してみよう! 」)、アーキテクチャー(「 2つのレベルしかあり得ない 」を含む)、およびコードで直接使用される手法で終わる(「 アスペクト指向のフレームワークが必要です! 」)である-そしてしばしば-それは、ビジネスの本当のニーズよりも、新しいテクノロジーを学びたいという欲求によって決定されます。 間違ったプラットフォームを選択するか、間違った手法を発明すると、プロジェクトは必然的に破滅します。



自分と「競い合いたい」​​という願望の結果、複数のプロジェクトの死刑判決に署名した後、情報ビジネスシステムを開発する際に従うべきいくつかの重要なルールを学ばなければなりませんでした。



1.ビジネスを学ぶ。
このビジネスのためのソフトウェアを開発するとき、ビジネスの本質を理解することは絶対に必要ではないと考えるのはばかげています。 顧客の真のニーズを理解しなければ、本当に必要なものを提供することは不可能です。 彼らが「毎日の新しいデータベース」と言うとき、彼らは本当に毎日新しいデータベースを意味するわけではありません。



2.ビジネスの利益を提供します。
すべての職人は、最新の最も壮大で強力なツールを使用したいと考えていますが、それらが仕事に必要になることはめったにありません。 同様に、プラットフォーム/ライブラリ/言語を即座に更新することはほとんど不可能です。 「クラシックASP」で記述された10年前のコードは時代遅れではありません。同行するのはそれほど楽しくありません。



3.仕事以外で学ぶ。
自己啓発はあらゆる職業の主な原則ですが、これは「仕事の外」で、つまり情報システムの開発中には行わないでください。 代わりに、あなた自身、あなたのチーム、あるいはいくつかのオープンソースプロジェクトのためにアプリケーションを作成することで学びましょう。 説明: 「仕事以外」とは、仕事の過程でまったく学んではいけないという意味ではありません。 トレーニングは重要ですが、顧客向けの情報システムを開発する過程でトレーニングを処理しないでください。 独自のプロジェクトまたはチームプロジェクト用に保存します。



4.主にビジネスロジックをコーディングします。
手で書かれたコードの大部分がサブジェクト領域に固有のものではなく、アプリケーションの目標に関連していない場合、間違ったツールを使用しています。 システムにロギングのフレームワークが必要であると固く信じているなら、それを鳴らして顧客の承認を得てください。



5.退屈から逃げないでください。
O / Rマッパーやコードジェネレーターは、レコード、フィールド、バリデーターなどからあなたを救うことができません。 少なくとも2か所(フロントエンドとバックエンド)で手動で登録する必要があります。 そして、ベースから生成されたUIは、UIから生成されたベースと同じくらい悪いです。



6.どこでも満足を求めます。
楽しみの唯一の源が複雑なコードを書くことであるなら、あなたは決して満足のいくアプリケーション開発者にはなれません。 個人的には、エンドユーザーが生産性を向上させたり、組織に新たな機会を開いたりするのを支援したという考えに満足しています。



...そして何も助けなければ...



7.別の仕事を探します。
あなたはこの仕事でピークに達したかもしれません。 または、このタイプのプログラミングにうんざりしているのかもしれません。 それはそうかもしれませんが、退屈や情報システムを含まないプログラミングの機会がたくさんあります。 もちろん、 The Brilliant Paulaの豆のような傑作はIT企業の腸でしか生まれないので、競争ははるかに高くなります。



結局のところ、最高のプログラマーは、最も驚くほどエレガントで息をのむほど革新的なコードを書いた人ではありません。 本物のロックスターは、締め切りにプロジェクトを投入し割り当てられた予算よりも安く 、これがまさにビジネスに必要なものです。 そして、これらはまさに私たち全員が努力するべき人々です。



All Articles