クリエイティブコーディングの何が悪いのですか？
私は見ていた ボブ・ロス 今夜、いくつかの「幸せな木」を描きました。そして、最近、コードについて私にストレスを与えているものを理解しました。
こことStack Overflowの人々のコミュニティは、不完全さの気配を拒否するようです。私の目標は、自分のスキルを向上させることによって、立派な（したがって保守可能で機能的な）コードを書くことです。しかし、私は独創的にコードを書いています。
「クリエイティブにコーディングする」とはどういう意味かを説明しましょう。
- プロジェクトの最初のステップは、多くの場合、座ってコードを打ち消すことです。より大きなものについては、私はあちこちで少し計画を立てますが、ほとんどの場合私はただ飛び込みます。
- プロジェクトで他の作品を作成している他の人と一緒に作業しているのでない限り、私は自分のクラスの図を作成しません。それでも、それが私が最初に行うことではありません。私は通常、巨大なプロジェクトに取り組んでいないし、ビジュアルがあまり役に立たない。
- 私が書くコードの最初のラウンドは何度も書き直され、テスト、簡素化、やり直し、そして元のハックを再利用可能で論理的で効率的なものに変換します。
このプロセスの間、私は常に掃除をしています。未使用のコードを削除し、明白でないものはコメントします。私は常にテストしています。
私のプロセスは、プロの開発者コミュニティで許容できる範囲に反するようであり、その理由を理解したいと思います。
悪いコードについての最も厄介なのは、誰かが元従業員の混乱で立ち往生していることであり、修正するのに多くの時間とお金がかかることです。私が理解していること。私が理解していないのは、最終結果が最初からすべてを計画した場合に得られる結果と同様であることを考えると、私のプロセスがどのように間違っているかです。 （または、少なくとも、それが私が見つけたものです。）
この問題に対する私の不安は最近非常にひどく、私が取り組んでいる特定の問題を解決するためのすべての方法についてすべてがわかるまで、コーディングをやめました。言い換えれば、私はほとんどコーディングを完全に停止しました。
この件についてのあなたの意見が何であれ、あなたの意見を心から感謝します。
編集：回答ありがとうございます。それぞれから何かを学びました。あなたはすべて最も役に立ちました。
Code-test-refactor-repeatには何の問題もありません。プロトタイピングしていることを人々に伝えてください。
一方、大規模なプロジェクトの場合、設計に前もって考えておくと、oh-crap-now-whatループの時間を大幅に節約できることがわかります。
追伸：作図技法は、視覚的な思考スキルを習得するのに役立ちます。視覚的思考スキルは、図を見ているだけの人でも貴重です。
私は常に、視覚的に表現されたUML化されたデザインパターンのコードよりも、明確で読みやすくシンプルなコードを好んでいます。クラス/インターフェイスには、「ItemVisitor」（？！）デザインパターン、OOテクニック、その他すべてはルールを形式化することです。そのルールは常識に基づいています。
その形式化なしで作業することは不可能であり（自分のプロジェクトで単独で作業しない限り）、形式化し過ぎるとプロジェクトのコストが増加します。他人のコードを理解する必要性を決して無視しないでください。最良のコードは最も単純なコードです。
コードを書き直すことをためらわないでください。これに対してX票（X> = 10）を取得しますが、太字にします：コードの再利用性は最も重要ではありません。
コーディングを開始する前にする必要がありますユースケースを検討してくださいそのコードを実装します。ソフトウェアを使用するためであり、開発するためではありません。 使いやすさ、有用性は2つの最も重要なターゲットであり、誰がそのソフトウェアを使用するかは関係ありません-プロジェクトの依存部分の別の開発者、またはエンドユーザー。
私もほとんど同じです。他の人々が彼らのために働いた事柄についてあなたに言うのを聞いてください、しかし、それに何か道徳的な命令があったかのように、あなたが「すべき」ことをあなたに言う人を無視してください。あなたのために働く何かを見つけたら、それを使ってください。つまり、最終的には何が重要かということですね。あなたがそこにたどり着くまでにたどった道を本当に気にしているのは誰か
覚えておいてください：人々は異なるです。それはいい。あなたを好きにしようとする人の言うことに耳を傾けないでください。他の人にあなたを好きにさせようとする衝動に抵抗してください。
あなたはそうです：
- 最善のアプローチを見つけるためにいろいろ試してみる（実験、インクリメンタルデザイン）
- コードを書き直してクリーンにする（リファクタリング）
- 常にテストを書く（テスト駆動開発）
あなたがやっていることは素晴らしいです！それはあなたが完全にそれを正しくやっているように見えます（アジャイル）プログラミング本。これには明らかに他にもありますが、あなたは値を釘付けにしています。コードを追加している間は、デザインをリファクタリングして改善することを忘れないでください [〜＃〜] bduf [〜＃〜] の必要はありません。
一度に1つの小さな機能に焦点を当て、各機能の完了後にリリースすることを検討しましたか？これは、苦労している分析上の問題から解放され、雇用主に真の進歩を示すのに役立つ場合があります。
また、あなたが話している「専門能力開発コミュニティ」が何であるかはわかりませんが、もしそうなら、彼らに象牙の塔に戻って戻ってあなたの仕事を続けることができるように伝えます！
ブラッド、あなたは一人じゃない。私はあなたが説明するのとまったく同じ方法で作業する非常に優れたプログラマーを知っています。 :)
コードをクリーンアップし、効率的で読みやすくする方法を知っている場合は、クリーンで効率的なコードを事前に作成する方法についても理解しているはずです。
さらに、事前に完全に計画することはできません。微妙な問題を発見するための最短ルートは、多くの場合、コードを実行して見過ごされていた詳細を理解することです。
私はあなたが完全にうまくやっていると思います、そしてあなたが記述するプログラミングスタイルは完全に有効だと思います。
よく知られているMIT book "Structure and Interpretation of Computer Programs"（通称 "SICP"と呼ばれる）のまえがきからの引用から、Alan J. Perlisからの引用で上記の回答を完了する価値があると思います：
すべてのコンピュータープログラムは、現実または精神的なプロセスのモデルであり、心の中で孵化しています。これらのプロセスは、人間の経験と思考から生じるもので、数が多く、詳細が複雑で、いつでも部分的にしか理解されていません。それらは、私たちのコンピュータプログラムによってめったに私たちの永続的な満足にモデル化されません。したがって、私たちのプログラムは注意深く手作りされたシンボルの個別のコレクション、インターロック機能のモザイクですが、それらは継続的に進化します。モデルの認識が深まり、拡大し、一般化して、モデルが最終的にさらに別のモデル内の準安定な場所に到達するまで、それらを変更します。私たちは奮闘しています。」
グッド・クレバーとバッド・クレバーがあります。
良い賢い-賢いコード行と非賢い選択肢の行の間の高い比率。 20000を書く手間を省く20行のコードは、非常に優れています。 Good Cleverは、自分の作業を節約することです。
悪い賢さ-書かれたコードの行と保存されたコードの行の比率が低い。 5行のコードを書く手間を省く賢いコードの1行は、Bad Cleverです。悪い賢さは、「構文オナニー」についてです。
注意：Bad Cleverが「Bad Clever」と呼ばれることはほとんどありません。多くの場合、「美しい」、「エレガント」、「簡潔」、または「簡潔」というエイリアスで移動します。
私はあなたがあなたのワークフローを説明する方法で自分自身を確実に認識することができます。グループ環境で作業を始めたとき、ほとんどすべてのものを変更する必要がありました。
私が今から約8か月間携わってきた仕事は、単一のプロジェクトで開発者チームで働いたときの私の最初の経験です。今まで、文字通り私のキャリア全体は、チームワークに伴うすべてのものを扱う必要がなかった一匹狼のコーダーでした。私がグループで働いていたとしても、それは常にかなりばかげた仕事でした-私のプロジェクトはMINEでした、または私のセクションはMINEでした、などです。真に協調的なチーム作業環境。
ここで私が気づいた主なことは次のとおりです。あなたがやっていることが血に染まっていない場合は、おそらく同僚の次の頭痛を書いているでしょう。ここで目にする「プロセス指向の」騒動のほとんどは、私たちの多くが頭痛の種の同僚になっているという事実に関係しています。そして、ほとんどのソフトウェアプロセス管理理論は、その頭痛の最小化に関係しています。
つまり、事前に合意した計画を立てるなどです。これらは、チームに参加して同期することです。あなたがチームであれば、あなたはすでに自分と同期しているので、それは本当に必要ではありません。
クリエイティブアートフォームとしてのアプローチには何の問題もありません。個人的な利益のために開発を行っている場合、そしてあなたがやっていることはあなたのために機能し、あなたが楽しいと思うことは、おそらく製品自体と同じくらい最終的な結果と同じくらい重要です。
プロフェッショナルな作業環境では、プロジェクトの時間スケールが短い場合（おそらく2〜3週間以内）、そのアプローチはラピッドプロトタイピングと呼ばれ、前のタスクに非常に適しています。
ただし、より長いプロジェクトでは、自分で作業している場合でも、そのようなアプローチはおそらく雇用主にとって高価な贅沢です。事前のアーキテクチャ設計にプロジェクト予算の数日間を費やし、その後、管理者が仕様を変更することを決定した場合にアーキテクチャをテストします。あなたのキャリアの中で。
2つの視点：
誰も絵を維持する必要はありません。
ボブ・ロス・ペイントの絵を見たことがある人なら誰でも、絵には構造があることを知っています。ボブロスから1つのレッスンを受ける場合は、事前に計画を立てて体系的に作業することで、プロセスがスムーズになり、シンプルに見えるようになります。
コーディングもほぼ同じです。私はただ書き始め、パターンが出現するのを見て、リファクタリングします。あなたはそのように自分自身を隅に描くことができます、いつ座って問題を考えるかを知る必要がありますが、時にはそれを突き刺して本当に理解する問題を理解するだけです。
しかし、私はこれについて興味があります：
こことStack Overflowの人々のコミュニティは、不完全さの気配を拒否するようです。 [..]私のプロセスは、プロの開発者コミュニティで受け入れられるものの粒度に反するようです。その理由を理解したいと思います。
Stack Overflowの誰かknowあなたのプロセスはどうですか？ 「拒否」とはどういう意味ですか？当然のことながら、プログラミングコミュニティに投稿されたコードは批評的に検討されます。しかし、誰かがコードを改善できる領域を見つけたら、それは良いことですよね？
うまくいけば、Stackframeに質問を投稿するときは、コードをクリーンアップして、読者への敬意を払わずに、可能な限り最も単純な形式にそれを削減しようとします（他の人に提示できるようにしようとするだけで、あなた自身の問題を解決することがあります）。フィードバックが良い場合。 知っているが悪いコードを投稿していて、あなたが知っているなぜそれを投稿する前に悪い場合、人々がそれを個人的に受け取らないでください通知それは悪いことです。
私もあなたのアプローチを使います。オーバーエンジニアリングのリスクを減らすので、私にとってはうまくいきます。
私が頻繁に行うことは、おそらく可能な限り最小限のコードで問題を解決することです。これは通常、明らかに不必要な依存関係やその他の設計上の問題につながります。次に、作業コードを美しいコードにリファクタリングします。
たとえば、さまざまなモジュール間の依存関係を減らしてインターフェースを簡潔にし、どのデータをどこに保持するかを考え、すべてのモジュールが他のモジュールの非常に最小限の抽象化のみに依存するようにします。どちらのモジュールがどの責任を持つべきかという最終決定は延期できます。抽象化は延期します。
問題を個別の責任、個別の抽象化に分離することにあまりにも多くの考えを入れるのはよくありません。それはあなたがあなたが作った抽象に合うようにあなたの実装を曲げることをあなたに強います。希望する結果が得られ、保守が可能であれば、コードは機能します。適切なコードで実装できれば、設計は機能します。コードが機能しない場合は、コードを変更します。エルゴ、デザインが機能しない場合は、それも変更する必要があります。実装すると、デザインが機能するかどうかを確認できます。
したがって、簡単なスケッチを念頭に置いておけば、それを実現する前のデザインとして十分です。再設計、抽象化、リファクタリング 必要に応じて 。
プログラミングが上手になるとしたら、少なくとも楽しいこともあるはずです。それは創造的であることを意味します。
確かに、グループでプログラミングする場合、「道徳的」な理由ではなく、実際に適用する場合に、従うべき最低限の標準があります。
それ以外では、境界を調べてそこに何が見つかるかを確認するのは面白くて楽しいです。アセンブリ言語でMiniの作業をしているときに、1つの命令で1つから別のものに切り替えることができるコルーチンを作成できることを発見しました。次に、2ステップ前、1ステップ後などのセルフコルーチンを作成する方法を見つけました。それは役に立ちましたか。疑わしい。それはポイントではありません。
Edsger Dijkstraの話を聞いたら、プログラミングの創造性について話しました。彼は、学生がn + mビットWordのnビット回転を行う方法を見つけた方法に言及しました。それは3ビットスワップで行われました。最初にnビットを交換し、次にmビットを交換し、次にn + mビット全体を交換します。有用？いいえ。賢い？はい。
自分の正しい心の中で誰もしないだろうことを自由に試してみるのは良いことです。
これは「1つのサイズではすべてに収まらない」場合です。あなたは自分が携わっているプロジェクトのためにあなたのスタイルをうまく作り上げました、それで誰がそれについて議論するのですか？ただし、ここおよびSO=で読んでいる批評家は、より大きなプロジェクト、またはチームメンバー間の複雑な調整を必要とするプロジェクトに取り組んでいる可能性があります。
複数の開発者間の協力を含む大規模なプロジェクトに関与したことがある場合、開発スタイルが問題になる可能性があります。スケジュールを立てたり、進捗状況を追跡したりするのは難しく、プログラマ同士が自分の仕事の内容を知ることに依存する仕事の計画を立てる方法はありません。
大規模なプロジェクトがあなたのプロジェクトに似た開発スタイルを採用したときに何が起こるかを確認するには、 コードの夢 を読んでみてください。
あなたの方法が間違っていないことは十分に保証されますが、私に個人的な経験を追加させてください。私はあなたの方法から始めましたが、その間、私は前もって一般的な構造の少なくとも一部を計画することの利点を学びました、そしてこれにはいくつかの理由があります：
最大の余分な点は、少し作業すると、どのコードを再利用できるかを簡単に確認できることです。私はよく、コードの一部を書いています。このコードは、書いているときに、画面の横にある一般的なスキームの別の部分（私が読めるスタイルで紙に描かれている）に突然役立つと思われます。
スキームがあると、コードだけでなくスキームもリファクタリングできます。時々、スキームの他の部分にも突然役立つように見えるクラスを書くのに忙しいことがあります。その結果、プロジェクトが実行されるときにスキームが単純になります
そのスキームを、関数/メソッドの必要な入力と所定の出力、およびクラスで使用可能なスロットで更新するたびに。これは、ビットを再利用する場合に速くなります。正確に何が出入りするかを確認するために毎回コードを調べる必要はありません。コメントに含まれている場合でも、コメントを取得するために参照する必要があります
だから、実際には私もあなたの方法を使います。私はただ始めて、試して、リファクタリングして、もう一度試して、別のビットを変更するなどしていますが、私のサイクルにはスキームも含まれています。そして、それが終わったら、そのコードで機能する次の情報を追加します。
心に留めておいてください、これは私が一人で取り組むプロジェクトのためのものです。同じコードでより多くの人と作業する場合、事前の計画はロジックだけでなく、不可欠です。しかし、あなたはすでにそれを知っていると思います。
そして、他の人が言ったように、これはmyの方法であり、あなたの走行距離は異なる場合があります。