クリエイティブコーディングの何がそんなに悪いのですか？[閉まっている]

ボブ・ロスが今夜「ハッピー・ツリー」をペイントするのを見ていましたが、最近、自分のコードについて何が私にストレスを与えているのかがわかりました。

こことStack Overflowの人々のコミュニティは、不完全さのあらゆる気まぐれを拒否しているようです。私の目標は、スキルを向上させることにより、立派な（したがって、保守可能で機能する）コードを書くことです。それでも、私は創造的にコーディングしています。

「創造的にコーディングする」ことの意味を説明しましょう。

• プロジェクトの最初のステップは、多くの場合、座ってコードを打ち消すことです。より大きなものについては、あちこちで少し計画を立てていますが、ほとんどの場合は飛び込みます。
• プロジェクトで他のピースを作成している他の人と一緒に作業している場合を除き、クラスを図に示していません。それでも、それは確かに私が最初にすることではありません。私は通常、大規模なプロジェクトに取り組んでおらず、ビジュアルが非常に便利だとは思いません。
• 私が書いた最初のコードは、何度も何度も書き直され、元のハックをテスト、簡素化、やり直し、再利用可能、論理的、効率的なものに変換します。

このプロセスの間、私はいつも掃除しています。未使用のコードを削除し、明らかでないものはコメントします。私は常にテストしています。

私のプロセスは、プロの開発者コミュニティで受け入れられるものの粒に反するようであり、その理由を理解したいと思います。

悪いコードに関する不満のほとんどは、誰かが元従業員の混乱に巻き込まれていることであり、修正するには多くの時間とお金がかかったことです。私が理解していること。最終結果が最初からすべてを計画することで得られるものに似ていることを考えると、私のプロセスが間違っていることは理解できません。（少なくとも、それは私が見つけたものです。）

この問題に対する私の不安は最近非常にひどく、私が取り組んでいる特定の問題を解決するためのすべての方法についてすべてがわかるまでコーディングをやめました。言い換えれば、私はほとんどコーディングを完全にやめました。

問題についてのあなたの意見がどうであれ、私はあなたの意見に心から感謝します。

編集： 回答ありがとうございます。私はそれらのそれぞれから何かを学びました。あなたはすべて最も役に立ちました。

code-test-refactor-repeatに問題はありません。プロトタイプを作成している人に伝えてください。

一方、より大規模なプロジェクトの場合、事前に設計に与えられたいくつかの考えが、おおまかな今のループで多くの時間を節約することに気付くでしょう！

PS：ダイアグラムテクニックは、視覚的な思考スキルを習得するのに役立ちます。これは、ダイアグラムを見た人が誰もいなくても貴重です。

クラス/インターフェイスに「ItemVisitor」（?!）などのパターン名が含まれる、視覚的に表示されるUMLでデザインされたコードよりも、明確で読みやすいシンプルなコードを常に好みます。デザインパターン、オブジェクト指向技術、その他すべては、ルールを形式化することです。そのルールは常識に基づいています。

その形式化なしで作業することは不可能であり（自分のプロジェクトで単独で作業しない限り）、形式化が過剰であるとプロジェクトのコストが増加します。あなたのコードを理解する他者のニーズを決して無視しないでください。最良のコードは最も単純なものです。

コードを書き直すことをNeverしないでください。このためにXダウン票（X> = 10）を取得しますが、大胆にしましょう。コードの再利用性は最も重要なことではありません。

コーディングを開始する前に、コードが実装するユースケースを検討する必要があります。ソフトウェアが使用されるためであり、開発されないためです。ユーザビリティ、有用性は2つの最も重要なターゲットであり、誰がそのソフトウェアを使用するかは関係ありません-プロジェクトの依存部分の別の開発者、またはエンドユーザーです。

私もほぼ同じです。他の人が彼らのために働いた事についてあなたに話すとき耳を傾けますが、それに対して何らかの道徳的な命令があったかのようにあなたが「すべき」ことをあなたに話す人を無視してください。自分に合ったものを見つけたら、一緒に行きましょう。つまり、最終結果は重要なことですよね？誰があなたがそこにたどり着く道を本当に気にかけますか？

覚えておいてください：人々は異なっています。それはいいことだ。あなたを彼らのようにしようとする人々の話を聞いてはいけません。あなたのような他の人々を作る衝動に抵抗してください。

あなたはそうです：

1. 最適なアプローチを見つけるために物を試す（実験、段階的設計）
2. コードを書き直してきれいにする（リファクタリング）
3. テストを絶えず書く（テスト駆動開発）

あなたがしていることは素晴らしいです！特に自分でそれを理解し、（アジャイル）プログラミングの本からそれを学んでいない場合、あなたはそれを完全に正しくしているように見えます。これには明らかにもっと多くのことがありますが、値は決まっています。コードを追加しているときにデザインをリファクタリングおよび改善することを忘れないでください。BDUFは必要ありません。

一度に1つの小さな機能に集中し、各機能が完了した後にリリースすることを検討しましたか？これは、苦労している分析の問題から抜け出すのに役立ち、雇用主に真の進歩を示します。

また、あなたが話している「プロフェッショナル開発コミュニティ」はわかりませんが、もしあなたなら、彼らの象牙の塔に戻って、あなたがあなたの仕事に取り組めるように言うでしょう！

ブラッド、あなたは一人じゃない。あなたが説明したのとまったく同じように働く非常に優秀なプログラマーを知っています。:)

コードをクリーンアップし、それを効率的で読みやすいものにする方法を知っていれば、クリーンで効率的なコードを前もって書く方法の感覚を確かに身につけたことになります。

さらに、事前に完全に計画することはできません。微妙な点を発見するための最短ルートは、多くの場合、コードを実行し、見落とされた詳細を理解することです。

あなたは完全にうまくやっていると思うし、あなたが説明するプログラミングスタイルは完全に有効だと思う。

よく知られているMIT著書「Structure and Interpretation of Computer Programs」（一般に「SICP」と呼ばれている）の序文から、Alan J. Perlisからの引用で上記の回答を完了する価値があると思います。

すべてのコンピュータープログラムは、心の中でmental化した、実際のプロセスまたは精神的なプロセスのモデルです。人間の経験と思考から生じるこれらのプロセスは、数が膨大で、詳細が複雑で、いつでも部分的にしか理解されていません。これらは、コンピュータープログラムによってめったに満足することなくモデル化されています。したがって、プログラムは慎重に手作りされたシンボルの個別のコレクション、インターロック機能のモザイクですが、絶えず進化します。モデルの認識が深まり、拡大し、一般化してモデルが最終的にさらに別のモデル内の準安定な場所に達するまで、それらを変更します私たちは苦労しています。」

良い賢さと悪い賢いがあります。

賢い-巧妙なコード行と非賢い代替案の行の比率が高い。20000の記述からあなたを救う20行のコードは非常に賢いです。賢いのは、自分の仕事を節約することです。

悪賢い-書き込まれたコード行と保存されたコード行の比率が低い。5行のコードを記述する手間を省く1行の巧妙なコードが、Bad Cleverです。悪い賢いのは、「構文的マスターベーション」です。

ただ注意してください：Bad Cleverは「Bad Clever」と呼ばれることはほとんどありません。多くの場合、エイリアス「beautiful」、「elegant」、「concise」、または「簡潔」の下に移動します。

あなたがあなたのワークフローを説明する方法で私は間違いなく自分自身を認識することができます。グループ環境で仕事を始めたとき、ほとんどすべてのものが変更する必要がありました。

約8か月間働いた仕事は、開発者チームで1つのプロジェクトに取り組んだ初めての経験です。これまで、文字通り私のキャリア全体は、チームワークに伴うすべてに対処する必要のない孤独なコーダーとしてでした。私がグループで働いていたときでさえ、それは常にかなりサイロ化された仕事でした-私はプロジェクトがMINEであったか、そのセクションがMINEでした、などです。真に協調的なチーム作業環境。

私が気づいた主なことは次のとおりです。あなたが何をしているのかが明らかでないなら、おそらく同僚の次の頭痛を書いているでしょう。ここで見られる「プロセス指向」の大騒ぎの多くは、私たちの多くが頭痛の種である同僚であるという事実に関係しています。そして、ほとんどのソフトウェアプロセス管理理論は、その頭痛を最小限に抑えることに関係しています。

そのため、合意済みの計画を事前に計画することなどが必要です。それらは、チームを参加させて同期させることです。あなたがチームである場合、あなたはすでにあなた自身と同期しています、そしてそれは本当に必要ではありません。

創造的な芸術形態としてのアプローチには何も問題はありません。あなたが個人的な利益のために開発していて、あなたがしていることはあなたのために働いており、あなたが楽しいと思うことは、おそらく製品自体と同様に最終結果と同じくらい重要です。

プロの作業環境では、プロジェクトのタイムスケールが短く、おそらく2〜3週間以下であれば、アプローチはラピッドプロトタイピングと呼ばれ、今後のタスクに非常に適しています。

ただし、長いプロジェクトでは、自分で作業している場合でも、そのようなアプローチは雇用主にとっておそらく高価な贅沢です。事前のアーキテクチャ設計に数日間のプロジェクト予算を費やし、管理者が仕様を変更することを管理者が決定した場合にアーキテクチャをテストします...あなたのキャリアの中で。

2つの視点：

1. 誰も絵を維持する必要はありません。

2. ボブ・ロスが絵を描くのを見たことがある人なら誰でも、絵には構造があることを知っています。Bob Rossから1つのレッスンを取り除こうとする場合、前もって計画し、組織化された方法で作業すると、プロセスがスムーズに進み、シンプルに見えるようになります。

ほぼ同じ方法でコーディングします。書き始めて、パターンが出現するのを見て、リファクタリングします。そのようにして自分を隅に追いやることができます。いつ座って問題を考えるかを知る必要がありますが、時には問題を本当に理解するためにそれを突き刺すだけです。

しかし、私はこれに興味があります：

こことStack Overflowの人々のコミュニティは、不完全さのあらゆる気まぐれを拒否しているようです。[..]私のプロセスは、プロの開発者コミュニティで受け入れられるものの粒度に反するようであり、その理由を理解したいと思います。

Stack Overflowの誰もがあなたのプロセスをどのように知っていますか？「拒否」とはどういう意味ですか？当然、プログラミングコミュニティに投稿されたコードは批判的に検討されます。しかし、誰かがあなたのコードを改善できる領域を見つけたら、それは良いことだけですよね？

うまくいけば、Stackframeに質問を投稿するときに、読者を尊重して、コードをクリーンアップし、可能な限り単純な形式に減らすことを試みます（他の人に提示できるようにするだけで、自分の問題を解決することもあります）。フィードバックが良い場合。悪いとわかっているコードを投稿し、投稿する前にそれが悪い理由を知っている場合、人々がそれが悪いことに気付いた場合、個人的にそれを受け取るべきではありません。

私もあなたのアプローチを使用します。オーバーエンジニアリングのリスクを減らすため、私にとってはうまく機能します。

私が非常に頻繁に行うことは、おそらく最小限のコードで問題を解決することです。これは通常、明らかに不要な依存関係やその他の設計上の問題につながります。次に、作業コードを美しいコードにリファクタリングします。
たとえば、さまざまなモジュール間の依存関係を減らしてインターフェイスを簡潔にし、すべてのモジュールが他のモジュールの非常に最小限の抽象化にのみ依存するまで、どのデータをどこに保持するかを検討します。あなたは言うことができる、私は最終的な決定を延期し、どのモジュールがどの責任を負うべきか。抽象化を延期します。
問題を別個の責任に、別個の抽象化に分離することにあまりにも多くの考えを入れることは良くありません。それはあなたが行った抽象化に合うように実装を曲げることを強制します。必要な結果が得られ、保守可能である場合、コードは機能します。適切なコードを使用して設計を実装できれば、設計は機能します。コードが機能しない場合は、変更します。エルゴ、デザインが機能しない場合は、同様に変更する必要があります。一度実装すると、設計が機能するかどうかを確認できます。

したがって、シンプルなスケッチを念頭に置いておくだけで、デザインを完成させることができます。必要に応じて、再設計、抽象化、リファクタリングします。

あなたがプログラミングが得意であるなら、少なくとも時々それは楽しくなければならないと思います。それは創造的であることを意味します。

確かにグループでプログラミングするときは、「道徳的な」理由ではなく、適用される実用的な理由のために、従うべき少なくとも最小限の標準があります。

それ以外では、境界を調べて、そこに何が見つかるかを調べるのは、面白くて楽しいです。アセンブリ言語でMiniを使用していたときに、1つの命令で一方から他方に切り替えることができるコルーチンを作成できることを発見しました。それから私は、2歩先へ、1歩先へと進むことができるセルフコルーチンを作成する方法を見つけました。それは役に立ちましたか？疑わしい。それはポイントではありません。

Edsger Dijkstraによる、プログラミングの創造性についての講演を聞いたことがあります。彼は、学生がn + mビットの単語のnビット回転を行う方法を見つけた方法に言及しました。3ビットスワップで行われました。最初にnビットを交換してから、mビットを交換してから、n + mビット全体を交換します。有用？賢い？はい。

彼らの正しい心の誰もしないようなことを気軽に試してみるのは良いことです。

これは、「1つのサイズがすべてに適合しない」場合です。あなたはこれまで行ってきたプロジェクトで自分のスタイルを機能させましたが、だれがそれについて議論するのでしょうか？ただし、ここやSOで読んでいる批評家は、より大きなプロジェクトや、チームメンバー間の複雑な調整が必要なプロジェクトに取り組んでいる可能性があります。

複数の開発者間の協力を伴う大規模なプロジェクトに関与したことがある場合、開発スタイルが問題になる可能性があります。スケジュールを立てるのは難しく、進捗を追跡するのは難しく、仲間のプログラマーが自分の仕事の内容を知ることに依存する仕事の一部を計画する方法はありません。

大規模なプロジェクトがあなたの開発スタイルに似た開発スタイルを採用したときに何が起こるかを確認するために、Dreaming in Codeを読むことに興味があるかもしれません。

あなたの方法が間違っていないことを十分に保証しますが、個人的な経験を追加します。私はあなたのやり方から始めましたが、その間に、少なくとも一般的な構造の少なくとも一部を計画することの利点を学びました。これにはいくつかの理由があります。

• 最大の余分な点は、少し回避すれば、どのコードを再利用できるかを簡単に確認できることです。私はしばしば、コードを書いている間に、画面の横にぶら下がっている一般的なスキームの別の部分に役立つように思われます（紙に書かれているのは私だけが読むことができるスタイルです）。

• スキームを使用すると、コードだけでなくスキームもリファクタリングできます。ときどき、スキームの他の部分にも突然役立つクラスを書くのに忙しくなります。その結果、プロジェクトを実行するとスキームがより簡単になります

• 関数/メソッドの必要な入力と指定された出力、およびクラスで使用可能なスロットを使用して、そのスキームを更新するたびに。これはビットを再利用するためにより速くなります。正確に何が出入りするかをチェックするために毎回コードに飛び込む必要はありません。コメント内にある場合でも、コメントを取得するために参照する必要があります

だから実際には、私もあなたの方法を使用します。始めて、試して、リファクタリングして、もう一度試して、別のビットを変更するなどしていますが、私のサイクルにはスキームも含まれています。そして、それが完了したら、そのコードで機能する次の情報を追加します。

心に留めておいてください、これは私が一人で取り組んでいるプロジェクトのためです。同じコードでより多くの人と作業する場合、今後の計画はロジックだけでなく、不可欠です。しかし、あなたはすでにそれを知っていると思います。

そして、他の人が言ったように：これは私の やり方です、あなたの走行距離は異なる場合があります。