私は1年半の間アプリ開発者として働いてきました（長くは知りません）し、最初の大きなプロジェクトを与えられました。

言うまでもなく、それは非常にスムーズに進まなかったので、プロジェクトに携わる上級プログラマーにアプローチ方法についてアドバイスを求めました。

彼は、私が目の前のタスクについて思い切って考えすぎていた、そしてデザインパターンを考えるのに時間をかけすぎてしまう前にこの規模のプロジェクトに取り組んだことがなかったからだと言った。彼の賢明な言葉で、彼は私に、「F * ck the future、build for now」と言った。

これは、プログラマーがこのようなプロジェクトに取り組む際に一般的にフォローする傾向ですか？たとえば、概念実証モデルの実行を求められた場合、できるだけ早く実行可能な例を破壊するのが一般的な傾向ですか？

編集：これがきっかけとなった議論を踏まえて、この状況は非常に極端であることに言及したいと思います：私たちがコントロールできない要因のために非常に厳しい期限があります（つまり、私たちが目指している市場は興味を失います「彼らに何かを見せないでください」と彼のアドバイスは、この特定のタスクに非常に効果的であることが証明されました。

救助隊に明らかな船長！

私はここでキャプテンオブボウンドになり、発見すべき中間点があると言います。

将来のために構築し、技術的な選択や悪いデザインに縛られるのを避けたいのです。しかし、シンプルなものを設計するために3か月を費やしたり、2年の寿命があり、フォローアッププロジェクトを行う可能性が低い、迅速で汚れたアプリの拡張ポイントを追加することは望ましくありません。

製品の成功を常に予測できるとは限らず、後で拡張する必要がある場合、区別を見つけるのは困難です。

今すぐビルド...

• プロジェクトは廃棄されます
• プロジェクトの寿命は短い
• プロジェクトには拡張子を付けないでください
• プロジェクトにはリスク影響値がありません（主に画像の観点から）

一般に、社内プロジェクトまたは顧客向けに構築されたものは今のところ開発する必要があります。まっすぐな要件を必ず設定し、必要に応じてそれらに関連付けて、必要なものとそうでないものを把握してください。「欲しいもの」に時間をかけすぎたくない。ただし、ブタのようなコードも使用しないでください。

一般的な問題は、後で必要になり、努力する価値がある場合に残します。

未来のために構築する...

• プロジェクトは公開されます
• プロジェクトは再利用されるコンポーネントです
• プロジェクトは他のプロジェクトの足がかりです
• プロジェクトには、機能強化されたフォローアッププロジェクトまたはサービスリリースが含まれます

あなたが何か公共のもののために構築している場合、またはそれが他のプロジェクトで再利用される場合、悪いデザインが戻ってくる可能性がはるかに高いので、それに注意を払う必要があります。しかし、常に保証されるわけではありません。

ガイドライン

できる限り次の原則に従うことをお勧めします。効率的で適応性のある製品を設計する立場に身を置く必要があります。

• それを知っているYAGNIを、
• キッス、
• かゆみをひっかきたいと感じて、追加を考えるときはいつでも書き留めてください。プロジェクトの要件を振り返り、追加が優先事項かどうかを自問してください。主要なビジネス価値を追加するかどうかを尋ねます。

私は個人的には考えすぎて過剰に設計する傾向があることを知っています。アイデアを書き留めておくと、追加機能が必要な場合によく考え直すことができます。多くの場合、答えは「いいえ」、または「後でクールになる」です。それらの最後のアイデアは危険です。なぜなら、それらは私の頭の後ろに留まるからです。

オーバーエンジニアリングをせずに、後からブロックせずにコーディングする最良の方法は、適切な最小限の設計に焦点を当てることです。後で拡張できるコンポーネントとして物事をうまく分解しますが、後でそれらをどのように拡張するかについては考えません。未来を予測することはできません。

単純なものを構築するだけです。

ディレンマタ

オーバーエンジニアリング

これは、プログラマーがこのようなプロジェクトに取り組む際に一般的にフォローする傾向ですか？

そうそう。これは既知のジレンマであり、製品に関心があることを示すだけです。そうしないと、それはもっと心配です。少ない方が常に真に多く、悪い方が常に真に優れているかどうかについては意見の相違があります。あなたはMITやニュージャージーのような男かもしれません。ここには簡単な答えはありません。

プロトタイピング/ Quick-n-Dirty / Less is More

実行可能な例をできるだけ早くマッシュアウトするのは典型的な傾向ですか？

これは一般的な慣行ですが、大多数のプロジェクトへのアプローチ方法ではありません。それでも、プロトタイピングは私の意見では良い傾向ですが、平均的なマイナス面があります。迅速で汚れたプロトタイプを実際の製品にプロモートしたり、管理上のプレッシャーや時間の制約の下で実際の製品のベースとして使用したりするのは魅力的です。それは、プロトタイプ作成が戻ってあなたを悩ませるときです。

プロトタイピングには明らかな利点がありますが、誤用や悪用の可能性も多くあります（結果として、前述の利点の正反対の多くがあります）。

プロトタイピングを使用する場合

プロトタイピングを使用するのに最適なプロジェクトのタイプに関するヒントがあります。

[...]プロトタイピングは、ユーザーと多くの対話を行うシステムで最も有益です。

[...]プロトタイピングは、オンラインシステムの分析と設計、特に画面ダイアログの使用がより明確になっているトランザクション処理で非常に効果的です。コンピューターとユーザーの相互作用が大きいほど、利益が大きくなります[...]

「これまでのラピッドプロトタイピングの最も生産的な用途の1つは、反復的なユーザー要件エンジニアリングとヒューマンコンピューターインターフェイス設計のためのツールとしてでした。」

一方：

バッチ処理やほとんどの計算を行うシステムなど、ユーザーの操作がほとんどないシステムでは、プロトタイピングのメリットはほとんどありません。場合によっては、システム機能を実行するために必要なコーディングが非常に集中的であり、プロトタイピングがもたらす潜在的な利益が小さすぎることがあります。

そして、周囲に緑色の怪物がいる場合は、プロトタイプを予算内に収まるようにしてください...

プログラミングを開始するとき、それは自分自身だけであっても、すべてが概念実証です。時間は重要な要素であるため、アイデアが迅速かつ汚れたものやプロトタイプを必要とする場合があります。開発者の間の大きな恐怖は、小さなアプリは本番環境で使用できる状態にあるか、永久に同じレートで機能を追加できると考えている関係者です。大規模なプロジェクトに取り組んでいると、そうではないことがわかります。

大規模なプロジェクトには通常、より複雑な要件があるため、複雑な設計を試して実装しようとする誘惑があります。あなたはそれらを読み、調査し、実装しようと多くの時間を費やすでしょう。これは大きな時間の浪費になる可能性がありますが、それはすべて学習と経験の獲得の一部です。特定のデザインをいつ使用するかを知ることは難しく、通常は経験が必要です。「this」プロジェクトで「that」を試してみましたが、機能しませんでしたが、「here」で機能するはずです。

あなたは多くの計画と計画を立てなければなりませんが、一度にすべてをやる必要はありません。最初からすべてを行う必要はありません。私は誰かがこのような最初の大規模なプロジェクトを作成することを望んでいます：

1. 少し設計し、話し合います。
2. 何かをするたくさんのコードを書く。
3. 問題を認識し、コーディングを停止します。
4. 設計に真剣に取り組み、勢いやコードモジョを失うことを心配せずに、プロジェクトマネージャーを無視します（あなたは彼/彼女に恩恵を与えています）。
5. プロジェクトを制御します。あなたの混乱を修正します。全員が計画を理解していることを確認してください。プロジェクトを管理します。

既存のコードベースでそれを実装する方法を本当に気にするような機能の1つにぶつかることがあります。これは「ただ機能させる」時間ではありません。「ハンマーの代わりにスツールをつかまなければならないこともある」と言ったボスがいました。彼は私の机で「考えている」と思ったので、これを教えてくれました。多くのボスとは異なり、彼は私がおかしいと思っていなかったので、もっとやりたいと思っていることを確認しました。天才。

最終的に、あなたのコードはデザインです。ドキュメント、図、会議、電子メール、ホワイトボードディスカッション、SOの質問、議論、議論、怒りの発作、コーヒーでの静かなチャットでサポートされています。コードを作成しようとすることだけを発見する欠陥があるため、これ以上デザインできず、より多くのデザイン時間を無駄にするリスクがあります。また、コードを多く書くほど、コードを書き出すことができない設計上の欠陥を引き起こす可能性が高くなります。再び便の時間。

プログラマは通常、将来を考えずに現在動作する何かを構築しますか？

はい。

彼らはそうすべきですか？

番号。

一見したところ、「未来について考える」ことは、KISSやYAGNIのような確立された設計原則に違反しているように思われます。

しかし、実際にはそうではありません。未来を考えるということは、シンプルで拡張可能で管理しやすいソフトウェアを設計することを意味します。これは、長期プロジェクトにとって特に重要です。時間の経過とともに新しい機能が必要になります。また、しっかりしたデザインを使用すると、新しいピースを簡単に追加できます。

完成したプロジェクトで作業するつもりがなくても、インテリジェントに開発する必要があります。それはあなたの仕事であり、少なくとも良い仕事がどのように行われたかを忘れないために、あなたはそれをうまくやるべきです。

アジャイル開発者は、「あなたはそれを必要としない（YAGNI）」という格言を持っています。将来機能するように設計を拡張するには、リファクタリングすることをお勧めします。

これの重要な側面は、設計時に製品の要件を念頭に置き、将来発生する可能性のある多数の要件に合わせて設計しないようにすることです。

2つまたは3つのイテレーションを先に考えることができる開発者に言わなければならないことがあります-彼らはクライアントまたはドメインをよく知っているので、彼らは高度な精度で将来のニーズを予測し、彼らのために構築することができますが、あなたやクライアントが必要としないものに時間をかけすぎないことが最善です。

これは、プログラマーがこのようなプロジェクトに取り組む際に一般的にフォローする傾向ですか？

あなたのメンターが意味したのは、最終的なソリューションでは必要とされないかもしれない追加の複雑さを構築するべきではないということだと思います。

アプリがこれを行うべきだと考えるのは非常に簡単であり、大規模な脇道になります。

デザインパターンに関しては、それらが目的を達成するための手段であることを覚えておく価値があります。経験上、特定のデザインパターンが以前の予感にもかかわらず収まらない場合は、コードのにおいを示している可能性があります。

たとえば、概念実証モデルの実行を求められた場合、できるだけ早く実行可能な例を破壊するのが一般的な傾向ですか？

プロジェクトが開始される前に、マイルストーンが何であるか、そしてそれらがすべてを少し見たい（垂直スライス）か、開発中の各部分のみを詳細に表示する（水平スライス）かを決める価値があります。初期設計の一部として、アプリ全体をストーリーボードする価値があるので、コードが書かれていなくても、ヘリコプターのビュー全体または特定の領域の詳細なダイビングを行うことができます。

彼は、私は目の前の仕事を思い切って考えすぎていて、このような大規模なプロジェクトに取り組んだことがなかったので、デザインパターンを考えることに時間をかけすぎていたと言いました。彼の賢明な言葉で、彼は私に、「F * ck the future、build for now」と言った。

それは他の開発者からのちょっとしたカウボーイの考え方だと思います。「今やる」だけのタフなオタクの現代版。これはスタートアップの間で人気のあるテーマになっており、Facebookの人々が「正しくやるよりもやる方が良い」というフレーズを始めたことに感謝していません。

魅力的です。勇気づけられ、開発者が何も過剰に設計しなかったために、期限内に予算内ですべての大きなプロジェクトを開始するときに、手を振ってコンソールの周りに立っている開発者のビジョンを提供します。

それは理想主義的なファンタジーであり、人生はこのようには機能しません。

愚か者は彼がただ「やる」ことができ、それを成し遂げることができると考えてプロジェクトに突入します。成功は、目に見えない課題に備える開発者に有利に働き、彼の職業を素晴らしい職人技のように扱います。

上級開発者は誰でも批判、非難、不満を言うことができます。

彼/彼女は、あなたがプロジェクトを「考えすぎている」とあなたに言います。最初に実際に「考える」ことを祝福します。他の人よりも優れた開発者になるための最初の一歩を踏み出しました。

これは、プログラマーがこのようなプロジェクトに取り組む際に一般的にフォローする傾向ですか？たとえば、概念実証モデルの実行を求められた場合、できるだけ早く実行可能な例を破壊するのが一般的な傾向ですか？

それがまさに概念実証です。人々が一歩後退してそれを見ることができるように、それは可能な限り迅速に何かをマッシュアウトする試みです。これは、間違い、誤った指示、無駄な時間/お金を防ぐために行われました。

概念実証にはさまざまな種類があります。完了時にゴミに捨てられるものを構築することも、プロジェクトの開始点を表すものを構築することもできます。それはすべて、必要なものと、コンセプトが最終製品にどれだけ近いかに依存します。

また、あなたのアイデアを実証する機会でもあります。予想外のレベルに物事を進めるプロトタイプを提示したことがあります。

デザインは通常オープンエンドであるため、適用が多すぎたり少なすぎたりするのは簡単すぎます。そして、プロジェクトが完了または破棄された後にのみ、正しい金額がわかります。それともそうではありません。

成功するための一般的なレシピはありませんが、極端を認識することを学ぶことができます。前もってすべてを完全に設計することは、些細なことを超えてほとんど機能しません。精製のためにコンポーネントを残して、それを実行できると感じているだけでも、問題を早期に発見する方法もあります。

あなたはどのように調べることがインクリメンタルあなたが慣れていない場合は動作します開発。成功する方法は通常、1つ以上のレベルで反復され、厳しいフィードバックを求め、いくつかのスケルトンで成長します。

計画を停止してコーディングを開始するためのアドバイスに耳を傾けるには、いくつかの正当な理由があります。

1. 開発者としてわずか18か月で、大学のGPAに関係なく、将来を十分に計画できるとは考えられません。これは、あなたの知らないことを知らないことがすべてであるため、明るくても経験の浅い開発者が把握するのは非常に難しいことです。古い手はあなたの視力のこの弱さを認識していたかもしれず、賢明にそれに入り込んで最善を尽くすように勧めました。

2. 若い開発者は、コーディングを開始する前に設計を完成させることに夢中になる可能性があります。彼らはコードを書くことへの恐怖をカバーしているかもしれません（パフォーマンスの不安）か、コーダーのブロックを持っているかもしれません（作家のブロックのように）。必要な作業成果物がないため、設計上は遅れています。若い開発者はおそらく、彼らが何かを「恐れている」という提案に怒って応答するでしょう。たぶん、プロジェクトの終わりに、彼らはそうだったことに気付くでしょう。心配しないでコーディングするというアドバイスは、コーダーのブロックの唯一の既知の治療法です。古い手が賢明にこのアドバイスを提供する場合があります。

3. 厳しいスケジュールの制約がある場合、プロジェクトを完了させる可能性は限られています。計画が長すぎると、計画がどれほど優れていても、それを時間内に実行できず、市場に出ることはありません。最初からハッキングを始めれば、幸運にも最初から正しくなるでしょう。製品を奇跡的に届けます。または、あなたはそれほど幸運ではなく、半焼きのスラグを配達しますが、それは時間通りに市場に出て、何かを学びます。または多分あなたは失敗します。しかし、計画を立てすぎたため、「おそらく失敗する」の方が「決して市場に出ない」よりも良い可能性があります。重要なことは、最初からチャンスが限られているため、ハッキングしても何も失われないということです。上司は、成功する可能性がほとんどないことを知っている場合があり、学習演習としてジュニアリソースを割り当てます。成功よりも失敗から学ぶ方が良い。「いつプロジェクト全体を手に入れることができますか？」

自分の欠点を確認するには、かなり内省的でエゴのない開発者が必要です。自分の弱点を見落とす言い訳をしないように、この他の部分を読む前にしばらく瞑想してください。

すべての開発者が分析、計画、および思考を必要とするその他のタスクに特に優れているわけではありません。考えは固くてむかつく。それは一種の精神的な汗を必要とします。モンスターの2つの缶でフロー状態に入るのと同じくらい楽しくはありません。考えたくない開発者は、計画が良いアイデアであるという概念に抵抗します。彼らは、事前の計画を必要としない開発手法を推奨しています。彼らは計画を強調しない会社やマネージャーが好きです。彼らは、計画しないことのコストが高くない仕事に引き寄せられます。彼らは一晩中コーディングセッションを大切にし、バグのためにビジネス全体がダウンしている顧客にそのホットフィックスを提供しています。

一部の開発者は、デモに十分な機能を取得することは、すべての状況下で完全に動作することを遅らせることができ、最初に「仕事をやり遂げる」ための称賛を受けながら、別の開発者にプッシュすることさえできることに気づきました。

すでにFacebookでブレイクするまでトレンドを見つけることができないマネージャーがいます。これらのマネージャーは、ディスカウントタイヤストアを管理する仕事を見つける代わりに、金曜日までにコードを実行する必要があるという問題を抱えています。APIを設計したり、アルゴリズムがスケーラブルであるかどうかをテストしたりする必要があることを聞きたくありません。これは、彼らにとっては単なるテクノロジージャンボです。顧客がファイルを転送するのを助けるためにperlスクリプトを書いていたときにソフトウェアについて理解していたので、彼らはコーディングを奨励します。（彼らの最初の営業職には「ソフトウェアエンジニア」という肩書きがありました。ソフトウェアがこれほど退屈でハードになると誰が知っていましたか？）

あなたのコードを見せてください

コードは訪問カードです。乱雑なコードを書いた場合、他の人にあなた自身について教えてくれますか？考えてみてください。オフィスで本当に悪いコードの断片を見つけるたびに、誰がそれを書いたのか、彼は大学をどのように通り抜けたのか、自分自身に尋ねます。

あなたはあなたがコーディングするものになりつつあります

あなたのコードは生涯のプログラムです。

悪いコードを書くプログラマは、ストリップクラブで踊るバレエダンサーのようです

一部の人々はストリップクラブでダンスを気にしません。しかし、彼らが高名なダンサーである場合、彼らは彼らのスキルを浪費しています。あなたが貧しいダンサーであるが、良い足を持っているなら、あなたは多くのためにストリップすることができます。

最後に、Gogolの小説「The Portrait」を読む必要があります。メインキャラクターのストーリーに注意する必要があります。あなたの友人はポートレートの男性に似ています。彼はあなたをお金でおびき寄せていますが、あなたはそれに対して高い代価を払います。