「あまりにも多くを知る」ために立ち往生[閉鎖]

http://news.ycombinator.com/item?id=4037794での詳細な議論に注意してください。

私は比較的単純な開発タスクを持っていますが、それを攻撃しようとするたびに、深い思考でスパイラルになります-どうやって未来を広げることができますか、第2世代のクライアントは何を必要としますか？側面（例：パフォーマンス、承認...）、変更を許可するにはどのように設計するのが最善でしょうか...

私は少し前に、より若く、そしておそらくより熱心に自分を覚えています。そのとき、私だった「私」は、すべてについて考えたことはありませんでした-彼は先に進んで何かを書き、それを書き直し、それから書き直しました（そして再び...）。今日の「私」はもっとためらい、より慎重です。

今日は、コードを書くのが好きではないからではなく、実際に先に進んで自分でやるよりも、座って計画を立てたり、他の人に物事を行う方法を指示したりする方がずっと簡単だと思います。-しかし、キーボードに座るたびに、私はその同じ迷惑な場所にいるからです。

これは間違っていますか？これは自然な進化でしょうか、それとも私はわだちに追い込まれましたか？

公正な開示-過去に私は開発者でしたが、今日の私の肩書きは「システムアーキテクト」です。それが何を意味するのかを考えてみてください-しかし、それがタイトルです。

ワオ。正直なところ、この質問がそれほど多くの回答を生み出すとは思っていませんでした。まとめてみます。

理由：

1. 分析の麻痺/過剰なエンジニアリング/金メッキ/（他の「前もって考えすぎるとあなたを傷つける可能性がある」）。
2. 特定のタスクの経験が多すぎます。
3. 重要なことに集中しない。
4. 十分な経験（およびそれを実現）。

ソリューション（理由と一致しない）：

1. 最初にテストします。
2. コーディングを開始（楽しみのために+）
3. 1つは捨てます（+ 1つのAPIは捨てます）。
4. 時間の制約を設定します。
5. 綿毛をはがし、物を持ち続けます。
6. 柔軟なコードを作成します（「1つは捨てる」の反対です）。

皆さんに感謝します。ここでの主な利点は、私がこの経験をしているのは私だけではないことを認識することだったと思います。実際、私はすでにコーディングを開始しており、大きすぎるもののいくつかは自然に落ちています。

この質問は終了しているため、本日現在、ほとんどの投票で回答を受け入れます。いつ/変更された場合-私はフォローしようとします。

これらのことを考えることは間違いなく良いことですが、それがあなたの進歩を止めさせないでください。

本当にうまく機能する1つのアプローチ（特に反復開発の場合）は、単純なソリューションを実装し、後で必要に応じてリファクタリングすることです。これにより、コードが可能な限りシンプルに保たれ、過剰なエンジニアリングが回避されます。考えているパフォーマンスやアーキテクチャの変更のほとんどは、おそらくとにかく必要ではないので、公式に必要になるまでそれらを書くことはしないでください。たとえば、プロファイラーがパフォーマンスを改善する時間だと言ってくれるまで、パフォーマンスについて心配しないでください。

調整を支援するためにできることの1つは、コードを記述する前に何かについて考える時間に厳しい時間制限を設定することです。ほとんどの場合、少し考えて記述し、間違いを認識し、リファクタリングによって修正すれば、コードは良くなります。

ここにはバランスを取る必要があります。頭から先に飛び込んで結果を考えてはいけませんが、コードを過剰に設計しようとするべきでもありません。

ウィキペディアでは、ソフトウェアで「分析麻痺」と命名しています。レシピはアジャイル方法論に固執することです。アクティビティや個々のアクションには、プラクティスやポリシーを確立しようとするよりもはるかに価値があるという意味です。チームのすべての貢献者は、その人の能力が建築の理想にどれほど良くても悪くても、価値があります。アジャイルでは、個人、エゴが最初で、ポリシーが最後です。

私のお気に入りの答えは「アーキテクチャは動詞です」です。あなたやチームがどれほど不完全で非効率であろうと、思考を止め、演技を始めましょう。たぶん最初のアクションは不適切なポリシーを解体することです。

40年前、フレッド・ブルックスはこのことについて書きました。何も変わっていません........

これは間違っていますか？これは自然な進化でしょうか、それとも私はわだちに追い込まれましたか？

場合によります。これは、開発者の道に沿った一般的なステップになる傾向があります。

1. 一緒にがらくたを投げ始めて、それによってお尻に噛まれます
2. すべてから生き地獄のオーバーエンジニアリングを開始し、YAGNI
3. 簡単なものは一緒に平手打ちされ、難しい/変更される可能性のあるものには、作業/変更が簡単にできるように十分なエンジニアリングが与えられています。

あなたが数2にとどまる場合、それは唯一のわだちです。

私が常に心に留めておくべきことの1つは、「未来はかつてのようではない」ということです。

ある程度の経験を積むと、将来を予測できると信じがちになりますが、できません。将来のクライアント/ユーザー/何でも望む機能を想像することは簡単ですが、それは彼らがすぐにそれらを欲することを意味しません。また、競合する他の機能よりも欲しいという意味ではありません。そのため、今日の将来の計画に費やす時間を制限する必要があります。特に、将来的にのみ使用されるものを構築するために今日費やす時間を制限する必要があります。

私が尋ねる質問は、「この機能のサポートを今すぐ構築するよりも、この機能を後から構築する方がどれだけ難しいか」ということです。通常、答えは、将来の努力は、今やろうとするのとほぼ同じか、おそらく2倍になるということです。その場合、将来を予測することはできないので、現在構築していなくても問題はありません。回答が10倍以上になった場合、来年または2年以内にこれが必要になると人々が考える可能性について質問し始めます。それでも、広範な合意がない限り、将来的にその目標を達成するために、今日行っていることを取り消す必要がないことを確認することに自分自身を制限します。

たとえば、後でHibernateをデータアクセスとして使用しているという事実を抽出するのに多くの時間を費やしたいくつかのプロジェクトに取り組みました。（Hibernateで構築されたプロジェクトがHibernateの使用を停止するのを見たことがないので、そもそもそれは時間の無駄でしたが、それは脇に置いておきましょう。）また、データアクセスオブジェクトパターンも使用していました。最初から柔軟性を組み込むよりも、必要に応じてHibernateを変更し、同時に変更する柔軟性を組み込むのは難しくありませんでした。今そのような状況に直面して、私は本当にそれが必要になるまでその柔軟性を持つことを延期するでしょう。

大企業の戦略計画を立てているのでない限り、テクノロジーは急速に変化しているため、2、3年以上先のアーキテクチャの問題を考える価値はほとんどありません。あなたが今日構築することを考えている機能は、2、3年後にオープンソースで自由に利用可能になるかもしれません。ほぼ確実に、費用便益分析が変更されます。

あなたが今日必要としていることを誇りに思っており、次の変更がもたらすものが何であれ、数ヶ月で喜んで作業できるシステムを構築することに自分自身を制限してください。本当にそれがあなたができる最高です。

これは、最初のバージョンでは非現実的であり、ビジネスの観点からプロジェクトに損害を与える可能性のある、クレイジーで素晴らしいデザインを排除する私の個人的なプロセスです。

1. 震源地の特定：プロジェクトをホットドッグスタンドと考えてください。震源地はホットドッグになります。他のすべてのスパイス/ドレッシング/野菜をスタンドから取り出しても、ホットドッグを販売できます。ソフトウェアの主な目的は何ですか？他のすべての追加および/または付加価値を分離し、まず震源地に焦点を合わせます。
2. 「後でやるということは、より良いことを意味する」ということを繰り返し続けてください。それをうまく行い、その実際の使用法を考えると、同じ設計になりますが、ロードマップで優先順位が付けられます。
3. ・デカップリング・廃棄を減少させる：あなたは（時々これも削除機能することなく達成することができる）ことが可能とユニバーサル/それはのような単純な/不可欠/純粋作る持っているどのようなモジュール設計。それをさらに単純化できない場合は、それ自体で生き、目的を持つことができる要素の分離を開始します。最終的にそこにまだ脂肪が残っている場合、あなたはそれを切り落とすことができます。
4. 「プロダクションコード」から「ライブラリコード」を分離します。再利用できないコードは常に存在しますが、常にデザインにノイズが追加されます。このコードは、ビジネスルールを含むものです。一部のビジネスルールは、堅牢な設計よりも簡単かつ迅速に変更できることがあります（非常に重要です）。信頼できるコードを見つけ、顧客が将来変更または再実装する必要があるコードを見つけます。これらはできるだけ分離しておく必要があります。

ところで、ステップ0は「デザインに夢中になる」です。これは、システムからそれを取得するのに役立ち、多くの場合、新しい影響、隠れた要件、さらには新しい機能を見つけます。

Reworkから1と2を取りました。

テストを書きます。テストがすべてパスしたら、完了です。オーバーエンジニアリングの壮大なフェーズの前ではなく、まもなく確実になります。記述しているコードのテストスイートがあると、独立した偏りのないオブザーバーが、いつ停止できるかを教えてくれます。

あなたが若いとき、あなたはリスクを見ません（おそらく若い政治家が怖い理由です）が、あなたが年をとるにつれて、あなたの悪い経験はあらゆる機会であなたを麻痺させます（おそらく上級政治家が停滞している理由）。Occamのカミソリにガイドされたアプローチを採用します。必要性が最も少ないソリューションに進み、そこから進化します。

ソフトウェアを作成および設計する際に留意する必要があるのは、保守性と正確性の2つだけです。

正確性は短期的に最も重要であり、テストで簡単に証明できます。

保守性は、開発の後半で役立ちますが、特定するのは困難です。

私の現在の戦略は、まずモノリシックな概念実証を取得し、実行可能だと納得したら、UIをモデルから分離します（モデルがUIについて何も知らないようにする）。このステップを長く待ちすぎると、保守不能なものが得られます。分離したレイヤーから始めると、UIがモデルについて知る必要があることにこだわるので、始めたようには見えません。

このような状況で立ち往生したとき、仮想プログラムを使用して合理的に些細なことを行うエンドユーザーであると頑固に想像することが役立つことがわかりました。次に、これらのアクションをサポートするために必要なプログラムエントリポイントに焦点を当て、システムの他の側面をできるだけ無視するようにします。ここから、完成したシステムの機能の（小さな！）「希望リスト」を作成し、それを実装し始める非現実的なコードを書くことができます。その練習の後、私は通常開始され、システムの残りの部分がより明確になり始めます。それはすべてエントリポイントに関するものであり、すべてのソフトウェアの大部分のエントリポイントは、プログラムに対するエンドユーザーの初期アクションです。

あなたがしているタスクがあなたにとって簡単すぎることはシンドロームだと思います。

数年前の課題は、与えられたタスクを達成するコードを書くことでした。これがあなたの心を完全に引き付けたものでした。今、あなたの心（あなたの経験など）はより効果的に働いており、同じタスクを実行するには以前必要だったエネルギーの一部だけが必要です。これが、深い思考の渦巻きで終わる理由です。あなたの心は日常から身を守り、挑戦のために戦っています。

仕事の変更を検討すべきだと思います。たぶん、あなたは新しいプログラミング言語を学ぶべきです。

私は15年前に同じ問題を抱えていました。ソリューションを必要以上に複雑にする、完璧で再利用可能な汎用のコードを書きたかったのです。今日私はこれを金メッキと見ています。私を大いに助けたのは同僚のアドバイスでした：

• 機能を改善する可能性のあるアイデアがある場合は、より汎用的にしてください...このアイデアを別のテキストファイル「ideas.txt」に書き留めますが、今はこれを実装しないでください。
• 緊急のタスクを実装し続けます。
• 6か月後、「ideas.txt」を確認し、これらの変更のどれが実際にプロジェクトに利益をもたらすかを分析します。

これは単に分析による麻痺です。それは多くの分野の多くの人々に起こります。あなたはそれを突破することができます。

答えは-それだけで始めましょう;-)

私はフィットネスフォーラムに投稿し、多くの場合、人々はさまざまなルーチンについて投稿し、それらにぴったりの完璧なものを見つけようとします。したがって、トレーニングを開始し、作業を進めていくだけだと伝えます。あなたは強くなり、いくつかの強力なエクササイズを行い、その後、物事を微調整します。

大規模なプログラムがあり、脳が時間外に機能する場合-単純なケースのコードを最初に作成します。最初はプログラムを実行し、その後入力などを行う必要があります。
あなたの課題は、物事を簡単に更新し、後でリファクタリングすることですが、コードは手元のタスクを実行するために必要なものよりも複雑ではありません。

将来、新しい優先順位に合わせてコードをリファクタリングすることは問題ありません。すべてを事前に予測することはできませんので、試さないでください。

次のタスクのコード-のみ。コードはシンプルであり、必要に応じて簡単にリファクタリングできます。プログラムが機能することを確認してください。繰り返す。

エンドユーザーのユースケースシナリオを考えすぎて「スタック」しているため、APIを公開し、知らない人がそのAPIを利用することを期待する場合、ここで考慮すべきことがあります。APIが公開されたら、最初のリリースがどれほど悪いかを後で理解したとしても、それをサポートし続ける必要があります。または、あなたが知らないかもしれませんが、それに対して書いたために疎外するリスクがあるすべての人のコードを破る必要があります将来のために。

標準的な解決策は、ユーザーのニーズとAPIコンシューマーが何をしているのかを把握するまで、いつでもAPIが変更される可能性があるという規定で公開することです。

そのソリューションでは、あなた自身のソリューションだと思います。1つまたは2つのことを行う小さなことだけを書いてください。多分それはうまくいくかもしれません。

設計は実際に発見の旅であるため、開始したときにすべてを正しくすることはできません。これは最初に現れるものではなく、出現する最後のものです。

APIをすぐに設計することはできず、消費者に壊す必要はありません。その理由がわかります。同様に、ソフトウェアを書くことはできず、ソフトウェアをすべて捨てて新しいアプローチからやり直す必要はありません。

創造的でなく、生産的で、望ましくないものに偶然進化したという意味で、あなたが問題を抱えているとは思いません。私はあなたがあなたの状況に誤って適用している高い基準を持っていると思います-誰もが作ると考えることのよくある間違いです。

あなたが冷笑的なすべてを知って、すべてを終えて、それが本当にあなたの状況の反対のように聞こえない限り、経験はあなたに対して数えられません。

大きくなったときに心に留めておく画像がいくつかあります。1つはレゴで遊ぶことです。私はそれをまとめて、自由に分解します。私が作り始めたものは、私が作り上げるものではないかもしれません。私はサーフィンをしながら自分の頭に浮かぶ可能性を自分自身にアドバンテージし、しばしばインスピレーションの瞬間に目標をその場で完全に再現します。それが創造性です。

もう1つのイメージは、実際の科学を行うことを説明するアナロジーです。あなたはそこにいないかもしれない黒い猫のために暗い部屋で手探りしています。自分がその猫を見つけられなかったことを失敗として数えた場合にのみ、不安になります。黒猫を見つける他の方法はありません。それはそれらを見つける唯一のアクティビティです。それ以外のものは、あなたが探しているものをすでに持っている何らかの形です。

あまり知りません。あなたは十分に知りません！そして、あなたはごく最近に気づきました。

「正しい」ものはないため、設計の選択を「正しい」ものとして考えないでください。多くの「間違った」ものがありますが、トレードオフもあります（実行速度、コーディングを完了する時間）タスク、拡張性など）。よく考えて作成したコードには、さまざまな長所と短所があります。

目標は、現在および将来の使用と保守のコンテキストでこれらの長所と短所を理解することが、そもそもコードを書くよりも劇的に難しくないポイントに到達することです。

そのため、深い考えを避けないでください。しかし、この種のデザインの達人になるためには、単なる思考ではなく経験が必要であることを忘れないでください。特定の選択肢に自信が持てなくなるまで考え、それからあなたが望むものが最良のものであることを実装し、試してみて、それがどのように進んだかを学んでください。

コーディングを練習します。エクササイズを考え出すか、オンラインで見つけて、できるだけ早く正しく終了するようにしてください。スピードアップしたら、保守性やパフォーマンスなどの考慮事項を追加します。本番環境に入らないものをコーディングするのは爽快であり、コーディングの恐怖から抜け出すのに役立つかもしれないことに気付くでしょう。

10年前と同じように、暇なときにコーディングを行い、心配を減らして楽しもう。

チームマネージャーになって、10年前と同じ精神状態にある若い開発者を指揮しましょう。

いいえ、まだ十分ではありません。

次の簡単なルールなどで知識を深めてください。

• KISS：小さくシンプルにしましょう。
• ヤグニ：あなたはそれを必要としません。
• 悪い方が良い：悪いソリューションのいくつかは、実際には保守性の点で優れています。

オーバーエンジニアリングしないでください。リファクタリングスキルを備えて変更の準備をしますが、コードのすべての可能な変更をエンコードしないでください。時間が経つにつれて、クラスまたは関数が大きくなりすぎる場合は、変更してください。分割統治。インターフェイスを使用し、より多くの機能を使用します。分割が多すぎると感じた場合（つまり、なんとなく見栄えが良くなりましたが、読みにくくなりました）、最後の変更を取り消してください。

要約すると、コードの柔軟性を十分に高めますが、それ以上ではありません。代わりに、自分の柔軟性を高め、リファクタリングに関する本を購入してください。

2つのこと：

1. 多くを知るだけでは十分ではありません。何を実装する価値があるかについて意見が必要です。私は個人的に、TDDを悪いアーキテクチャを可能にする松葉杖と見なしています。これに関して私に反論する非常に多くの一般的な意見を考えると、おそらく間違っていますが、JavaScriptでTDDを実装するかどうかは、私が考えた問題ではありません。開発コミュニティで人気のある意見が、数年後に欠陥と見なされたのは初めてではありません。だからar慢な刺すことを学ぶ。少なくとも内部では。あなたは間違っているかもしれませんが、少なくとも、そうでないかもしれないものを考え直すよりも、あなたのために働くものにコミットしています。

2. マイクロから始めているようですね。マクロから始めます。まず、アプリで必要なことを行うために必要なツール。その部分は十分に簡単に来るはずです。次に、アーキテクチャ/インターフェースの問題から始めます。配管がどのように接続し、どのように接続するかは、実際にはスワイプして気まぐれに置き換えることができるすべてのものの上にある薄っぺらなビットである必要があります。同様に、物事がどのように行われるかの詳細について。適切にラッピングすると、これらは簡単に交換/編集できます。

しかし、攻撃しようとするたびに、私は深い思考の渦巻きになります

何も問題はありません。あなたはあなたのプロセスを改善する時であることに気づきました：この場合、あなたの思考プロセス。

多くの人々は、分析に迷い込んだり、他の方法で脇道に追い込まれたり、それに気付くことさえありません。気づいたので、思考プロセスを変更して順調に進めることができます。

これには多くの解決策がありますが、私が上で見た中で最良の解決策は時間制約を設定することです。開始する前に、分析と思考に専念する時間（1時間？）を決定します。タイマーを設定します。

次に、タイマーが切れたら、コーディングを開始します。物事について考え続ける時間が長すぎる場合は、ただちに決断してください。あなたがその瞬間に決定するものは何でも正しい決定です。後からいつでも変更や改善を行うことができます。

その上、私たちの環境は常に変化しています。多くの場合、新しい要件、新しいテクノロジー、新しいハードウェア、言語およびシステムの更新などを処理するためにコードを更新する必要があります。

はい、このコーディングの恐怖は私にとっても起こります。スタックオーバーフローに見舞われる。小規模アプリケーション向けの詳細なコーディング。しかし、外部委託プロジェクトの場合、時間の制約のために時間をあまり消費しません。また、新しいグループの人々と協力することで、これを乗り越えることができます。

あなたは無慈悲ではない

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

編集：この記事のポイントは、開発時に小さな詳細に注意を払うことですが、可能な限り最も効率的なソリューションを見つけて仕事を完了するために、冷酷な態度で単純または複雑なタスクにアプローチすると役立つことがわかりました。