プログラミングの問題について最も不条理な神話は何ですか？

別の言い方をすれば...プログラミングに関して最も一般的でイライラする誤解は何ですか？

これは広範囲に及び長年の神話/誤解あなたが見つけるか、プログラマが/正しい払しょくするために懸命。

これが神話である理由を説明してください。

あなたはプログラマーだから、あなたは[人]のウイルスに感染したマシンを修正する方法を知っています。

私が就職活動をしているときに気が狂う一般的な人事：すべてのコーディングスキルは言語固有であり、コマンドセットを超えるソフトウェアエンジニアリングの専門知識はないという暗黙の仮定。Javaでの10年の経験とPerlでの5年の経験は、たとえばC＃を使用するプロジェクトではまったく役に立たないことを意味します。

「はい、学習曲線があります。しかし、私はこれよりも難しい移行を行いました。最初の月に80％を支払います。そうでない場合はその時間の終わりに… 、待ってください。HRmonkeyが私のアプリケーションを削除しただけなので、実際にはこの会話はありません。」

入力していない場合は、動作していません。

プログラマーが頭の中で物事を整理するには、ゾンビの空白の視線とコーヒーの散歩が不可欠だと思います。

より多くの人を投入するだけで、後のプロジェクトをスピードアップできます。

ライティングソフトウェアは簡単です。

時間と予算を超えて実行されるこれらすべてのプロジェクトを説明する方法はありますか？また、人々（政治家、メディアなど）はまだ驚いており、「小さなWebサイト」（または何でも）数千ドルの開発と費用（ポンド、ユーロ、[選択通貨の挿入]）

あいまいで絶えず変化する要件があるため、ソフトウェアが完成するのは驚くべきことだと思います！

私はそれがそれより少し複雑であることを知っています;）

アプリの複雑さは、UIの複雑さに直接比例します。この推論により、週末にGoogleまたはTwitterを構築できるはずです。

すべてのプログラマーは数学が得意です。:-)

コンピューターでハッキングする10代の子供は、ベテランのプログラマーと同等（または優れた）スキルを持っています。

私の14歳のneはコンピューターに慣れており、芝生を刈るために彼に10ドル/時間を支払っています。次のFaceBookを書くために6桁を支払う必要があるのはなぜですか？

そのリアルタイムは高速を意味します。

述べる「パケットがリアルタイムで処理する必要があります。」価値がなく、邪悪な双子は... 「Xはどれくらい速く起こる必要があるのか​​」と答えます。「リアルタイム」無価値よりもおそらく少ないです...愚かなのではなく無知を境に。

リアルタイムとは、簡単に言えば、関数Yは常にXの時間を要し、偏差があると重大なエラーを示すことを意味します。Xの期間は「リアルタイム」を定義せず、6マイクロ秒または6日間になる可能性があります。関数YがX時間を要すると判断できることは、「リアルタイム」を定義します。リアルタイムシステムは、この定義によって決定論的です。

だからノックオフ..

バグのあるコードの入力に時間を費やし、後でバグを見つけようとして後でコードを読むのではなく、最初に単純に正しく書いてみませんか？

:-) :-) :-) :-)

あなたが大学に行っていないなら、あなたは仕事に適していない

その時期尚早な最適化は、まったく最適化しないことを意味します。他のデータベース設計の問題よりも早期の最適化であるため、設計でパフォーマンス（データベースシステムにとって重要）を検討したい人は誰もいなかったため、私は恐ろしく悪いデータベースを見てきました。ゴミ、パフォーマンスキラーが知られている、あなたの最初の選択肢としてそれらを使用するのをやめます。

別の神話、データベースをリファクタリングするのは難しすぎる。いいえ。効果的に行うには、設計段階でリファクタリングを行う方法を検討する必要があります。ところで、その厄介なデザインベースのパフォーマンスの問題を修正するのを長く待つほど、修正するのが難しくなります。

もう1つの悪い神話、データベース設計はOOPの原則を反映する必要があります。いいえ、データベースは、OOP原則ではなくセットで動作するように設計されています。一部のOOP処理はひどいパフォーマンスの問題を引き起こしますが、他のOOP処理はデータベースの観点から見るとばかげています。

最後に、アプリケーションでデータの整合性を強化する必要があります。データベースはアプリケーションを超えて存続し、アプリケーションが置き換えられたときにルールを失い、複数のアプリケーションがそれらにアクセスするため、多くの場合、アプリケーションを通過しないものを修正するために直接クエリを実行する必要があります。良いデータを持つデータベースでデータの整合性を強制することを拒否するデータベースを見たことはありません。

絶対的なベストプラクティスの神話上のソースがあること。

逸脱を正当化することはできません。

何かをベストプラクティスと定義することを主張するドキュメントは、疑問視されることはありません。

マーケティングでは、多数の小さな機能を追加する方が、1つではなく重い機能を追加するよりも作業が少ないと考えているようです。これはおそらく、「タスク切り替えにはオーバーヘッドがない」という誤解のより具体的なケースです。

そのコメントコードは不要であるか、「良いコードにはコメントは必要ありません」。複雑なコードが何をしているのかを説明する必要がある場合があります。さらに、コードのセクションにコメントを付けると、読みやすくなります。

最悪の神話：長時間プログラミングをしているなら、あなたは簡単にプロジェクトマネージャーになれます。

そして、あなたが長い間プログラミングをしてきたなら、あなたはプロジェクトマネージャーになるべきだと。

プロジェクトでJava、C＃、C ++以外のものを使用する場合、それをサポートするプログラマは見つかりません。

Javaは、異なるクラスを持つC ++にすぎません。

Java は 遅いです。

おそらく私が見た中で最も危険なのは、すぐに受け入れられるため、コードをすばやく書くことができるということです。したがって、特定の言語でより速くコードを挿入できる[ここに機能を挿入する]ほど、言語は良くなりますです。

これは、コードを作成するよりもはるかに多くの作業がコードの維持に費やされるため、時期尚早な最適化の深刻な例です。これは、すばやく記述しやすいコードよりも、読みやすく、理解しやすく、デバッグしやすいコードを記述することがはるかに重要であることを意味します。読みやすいコードを容易にすることは、言語品質のはるかに有用な測定です。

製造のレッスンは、ソフトウェア開発プロセスに適用できます。

プログラマーとして、最新のハードウェアトレンド、オーバークロック、ケースMODなどに関するすべてを知っています。友人や親relativeは、ギアを購入するときに相談します。

プログラマーが行うのが非常に難しい/単純に不可能だと言うとき、HRは彼らが怠zyでやる気がないと思う

私のビジネスにはオープンソースプログラムが必要です。ダウンロードして、私の要件に合わせて調整することはできません。

会話の途中で、バイナリまたは数学記号を使用して直接プログラミングしていると実際に考えていることを理解するためだけにプログラムすることについて、複数の人に質問されました。

その神話を払拭したいかどうかはわかりません。

最大の誤解は、コードを読んで理解できるよりも、コードを簡単に書き留めることが重要だということです。

プログラミングは、組立ライン作業と同じです。特定の時間（同僚と一緒に）製品を開発し、最終的に出荷します。レンガの家を建てるのと同じです。

反論：プログラミングには、多くの創造性と計画が含まれています。それは芸術です。石工のように、プログラマーもレンガの形を作ることと大聖堂全体を計画することの違いを知っています。

プログラムをC ++に移植すると、自動的に実行速度が上がります。

ある種のビジュアルデザイナーを備えたプログラミング環境であれば、ビジネスユーザーがプログラムを「作成」でき、実際のプログラマは不要です。

OOPの再利用。プログラミングで販売されている最大の誤fallです。