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


101

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

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

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


24
Mythbustersがこれらのいくつかを引き受けたいと思っています。
スポンジ

8
MythbuggersのYouTubeチャンネルをお探しですか?:-)
タマラWijsman

1
Ooooh、MythBustersおよび競合状態!ミーサ好き!

@TomWijそのような名前のウェブサイトを持っていることは素晴らしいことです!
ジュニアM

回答:


272

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


34
車のアナロジー/脱出条項:「私はメカニックではなくレーシングドライバーです。」
ピーターボートン

15
このコミックは関連性があります:theoatmeal.com/comics/computers
lunixbochs


21
@Tim彼女は友人のパーティーに応えるために彼女をボランティア開始、調理することができるかどうか
スティーブンA. Loweの

19
どうすればいいのかわからないわけではない...マシンを修理するのに何時間も無駄にしたくないというのは、とにかく2週間で壊れるからだ。
ChaosPandion

267

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

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


91
HRサルの+ INF。
さびた

67
私はHRの人にC#の方法を知っていたので、私を職に落としてもらいましたが、彼はdotNetでコーディングできる人を探していました。
burnt_hand

11
@burnt_hand:ええ、私はdotNetを知っています。ExcelとInternet Explorerも知っています。今すぐ契約できますか?
アランプラム

JavaとC#の間で構文、構造、SDLCなどに大きな重複があることに同意しますが、インタビューでかなりトリッキーなC#テストを行った場合、どのように対処しますか?
JBRウィルキンソン

2
@Kyralessa-プログラミング言語の基本的な誤りを犯さないように、コンピューターの基礎となる理論とコンピューターの機能について十分に知っていると思います。ドキュメントを読むことができます。ただし、エンジニアリングスキルが限られている/ will /の言語固有の雇用者が行うことは、プログラムの構造、設計、正確性、スケーラビリティ、信頼性、および保守性に基本的なエラーを生じさせることです。その間にソフトウェアの品質が低いためにすべての顧客を失っていない場合(プロジェクトが実際にどこにでもあると仮定して)。
flamingpenguin

261

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

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


9
ページアップ、ページダウン...ページアップ、ページダウン...
アドルフニンニク

139
私はタイプするのにお金を払っていない、考えるのにお金を払っている。ボーナスとしてタイピングを提供します。
ケビンレイティ


11
これが、スクリーングラバーとウェブカメラで「作業時間」の記録を提供するオンラインフリーランス市場をあまり考えていない理由です。WTF?あなたが私の引用が良いと思うなら、なぜあなたが私が請求している時間に私がすることを正確に気にするのですか?
アランプラム

10
「コーディングにもっと時間があれば、書く行が少なくなります。」-阿部リンカーンの引用で離陸します。
ジェフ

158

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


28
ああ、The Mythical Man Monthから。en.wikipedia.org/wiki/The_Mythical_Man-Month
spong

2
実際に、ええと、できます。-1(ええ、神話のキャリアを見よ!)
P Shved

63
「1か月で9人の女性を部屋に入れて赤ちゃんを作ることはできません」というカラフルな言葉を使用します。
ウォルター

10
先週、プロジェクトの経験のない4人を追加して、非現実的なスケジュールを「支援」しました。プロジェクトからの今週のレポートは、上位の管理者リストにつながります。「スケジュールのずれ原因:新しいチームメンバーの学習曲線による効率の低下」および「回復計画:機会のある場所にさらに人を追加し続ける」。信じられない。
AShelly

7
@ウォルター、しかし、あなたは9ヶ月で9人の赤ちゃんと7年で小さなリーグの野球チームを持つことができます。
Huperniketes

132

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

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

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

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


11
そして、これは彼らが開発を安価なオフショアの代替品にしようとするときです。後になって、さらに高価になったことがわかりました。そして、開発チームと顧客の間の物理的な分離とコミュニケーションの課題のために、彼らが本当に必要としていたものが少なくなりました。
7 wp

1
これはマネージャーだけでなくプログラマー自身の問題でもあります。本当の問題は、コードを積極的に書くことに費やされていない時間が見逃されることが多いことです(おそらく、LOC =生産性定量化の神話が広まっているため)。
アランプラム

3
要件が変わったということではなく、彼らが望んでいたと思ったことではありません。
ジェフ

1
プログラミングを「単なる「if」ステートメントの束」として却下する人がいました。OK、多分それは...その場合には、詩は、映画制作等、「シーンのちょうど束」である...「言葉のちょうど束」です
JoelFan

2
私は、プログラミングのビットが仕事の簡単な部分だと思ったタイプのマネージャーのために働いてきました。いいえ、彼はプログラミングの経験がありませんでした。
キャプテンセンシブル

114

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


2
これは本当です、私は単一の週末にわたってTwitterとGoogleを構築することができました。複雑なのは彼らのソフトウェアではありません。Googleにとっては、検索アルゴリズム(コードライブラリまたはデータベースドライバーに匹敵)であり、Twitter(過去1.5年まで)は非常にシンプルで、スケーラビリティとデータベースの問題のみが複雑でした。より複雑になったため(より多くの従業員が必要)、さらに複雑なUIとより多くのUIがあります。
orokusaki

3
Joel Spolskyのブログで読んだと思いますが、言及された記事では、バックエンドの進捗に関連してGUIの進捗としてのみ表示されています。そうすれば、ほとんどのプログラムが見た目以上のもので構成されていることを理解するのがあまりにも愚かな先のとがった髪の男に現実的な進歩の見積もりを与えることができます。
エヴァンプライス

3
1+以前のボスにSharePoint関連プロジェクト(多言語アドオン)のデモを行い、複雑なバックエンドコードの作成に何時間も費やしたことがありました。最終結果はUIであまり行われなかったため、上司はプロジェクトであまり行われていないと信じるようになりました。それは私を怒らせた。彼は、SharePointの奇妙な点やテキスト置換ロジックを回避しようとして何時間もキーボードに座っていたわけではありませんでした。
ジェイソンエヴァンス

1
あなたのようにいくつかの、巨大なほとんど-不可能な要求を言葉で表現されたときに嫌いではありません「あなたがするボタンを追加することができます...」
JoelFan

私はここ数年何をしてきたのだろうか。私がフルタイムで取り組んだプロジェクトはすべて、すぐに終了するはずでした。UIがまったくなかったからです。:-)
バートヴァンインゲンシェナウ

95

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


コメント者:コメントは明確な説明を求めるためのものであり、詳細な議論のためのものではありません。解決策がある場合は、答えを残してください。ソリューションが既に投稿されている場合は、投票してください。他の人とこの質問について話し合いたい場合は、チャットを使用してください。詳細については、FAQを参照してください

数学の能力は、プログラミングスキルと何らかの関係があると思います。
ディエゴ

@Diego:これは必ずしもすべてのプログラマーが数学が得意であることを意味しませんが。
オメガ

95

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

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


5
彼らはおそらく自分たちの環境にいます。つまり、自分自身の基準に合わせて自分自身で働いています。彼らがコミュニケーションしなければならないチームに彼らを置き、それは彼らが苦しむところです。
アドルフニンニク

36
反対の質問は、「あなたの家を建てるために彼に何を支払うでしょうか?」です。

7
資格はないがきちんとしたコードを書いている子供は、いつでもミスター・スパゲッティに勝つことができます。
ザズ

13
私はそのためにハリウッドを非難
MAK

6
私が始めたとき、私は自分で教えて大学で習ったことは始まりに過ぎないと期待し、より良いプログラマーとより知識のある開発者である経験豊富な人々と一緒に仕事をし、学びましたそれらからたくさん。そうでなければ、経験から教えられました。それは絶対に重要ですが、スキルと情熱
ピーターボートン

69

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

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

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

だからノックオフ..


real-time = near-time
ブライアンチャンドリー

4
私はいつも、リアルタイムとは、あなたが必要としているように起こっていることは何でも起こっていることを意味し、所要時間の参照ではないと考えていました。
burnt_hand

14
これはおそらく、間違った名前の概念が混乱の原因となるケースの1つにすぎません。
JohnFx

2
@JohnFxええと。概念にはコンテキストが必要です。
さびた

2
@Richard:実際、iTunesは何かを再生する前に常に数分かかります。ああ、それはあなたが意図したものではありませんか?
コンフィギュレー

69

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

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


34
率直に言って、それは良い質問です。コードを適切なものにする最も簡単な時期は、コードを初めて作成するときです。
DJClayworth

10
アプリの設定に設定があります:<add Key = "Bugs" Value = "true" />
burnt_hand

1
@DJClayworth-常に機能するとは限りません。場合によっては、問題が非常に大きく、不明確であるか、または単純に困難であるため、最初に「正しい」状態に近づけることも期待できないほどです。このような場合、数日/数週間/数か月を費やして設計と再設計を最初から正しくしようとするよりも、まったく間違っていない「最初のカット」を書く方がよいでしょう。
スティーブンC

これは、素人向けの「なぜTDDをやっていないのですか?」公平を期すと、現実世界の開発にとって単純すぎる場合、これは非常に良い質問です。
ダン・レイ

1
@Stephen C:はい、しかし、それを機能させるために、ほとんど完全に正しいのではなく、ほとんど正しくすることと、ほとんど何でも左右に行うことには違いがあります。これはあなたが言ったことではないことは知っていますが、それでも言う必要があると思います。
n1ckp

65

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


27
また、学位を持っているプログラマーは、持っていないプログラマーよりも優れており、それに応じて支払われるべきです。同じことはおそらく年齢主義や性差別にも当てはまります。この種のナンセンスは私を苛立たせます-良いコードを書く方法を知らなければ、あなたがどこに行って何をしたかについてあまり気にすることができませんでした。これは、プログラマー/オタク文化(スキル==権限)が企業文化(ランク==権限)と衝突する別のケースかもしれません。
アランプラム

1
それでも、大学で教えている人たちは、チームを組んだときの学生の動作を観察することで、プログラマーやプロジェクトの行動を一般化できると考えているようです。ACMのコミュニケーションは、1年に4〜6件の記事に適しています。
MIA

1
@Billy大学の卒業証書はジャックを意味しますが、大学の卒業証書はすべてをあなたに与えてくれます。両方とも学校に行き、どちらも間違いなく他の生徒よりも優れていますが、社会学的な違いがあります
-Tarka

4
@ビリー:カナダでは、大学が学位を授与し、大学が卒業証書を授与します。大学は、「実践的なものを学ぶ学校」に似ています。米国のコミュニティカレッジと通常のカレッジ/大学を比較してください。ここでは、通常2年間の専門的な応用プログラムがあります。大学から学士号(修士号など)を取得することはできません。基本的には、大学でソフトウェアの書き方を学び、大学でコンピューターサイエンスを学びます。大学の学位は、雇用においてはるかに強い優先権を与えられています。
アダムリア

4
大学は、少なくとも一つの重要なことを教える:考え方を。これは非常に重要ですが、それを知らない人は...まあ、それを知りません。

61

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

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

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

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


特に、データベースの整合性チェックに関するコメントについては+1。
フランクシェラー

+1特に最後の段落。私はそのドラムを複数回叩きました。
バイナリウォーリア

5
最初の段落の+1。早すぎる最適化はすべての悪の根源です。血まみれの理由で悪いコードを書くのはさらに悪いことです。
コンフィギュレー

3
「OOPによってはパフォーマンスの問題がひどくなり、データベースの観点から見るとばかげているだけです」-どちらを言うことができますか?私はOOPについては知っていますが、データベースについてはあまり知りません。そして、各サイドから他のサイドまでアイデアをどれだけ伝えることができるか興味があります。
トムアンダーソン

@HLGEM @Tomが疑問に思っている例にも興味があります...-
アーマン

53

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

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

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


1
あなたの管理職よりも良いチームメンバー...
ビル

5
そのドキュメントを私に転送できますか?
AShelly

1
完全に同意する。Pythonコードでタブとスペースを混在させる場合、誰が気にしますか?
ザズ

4
@Josh-タブの位置がどこにあるかについて異なる考えを持つツールチェーンを使用してソースコードを表示する必要がある人。
スティーブンC

1
「ベストプラクティス」を「これを正当化できない」と解釈します。私は確かにそのように自分で使用しています。
トムアンダーソン

51

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


12
そして、マーケティングのさらに楽しいことは、どの機能が簡単で、どの機能がほとんど不可能であるかをまったく知らないことです。
デロバート

4
@derobertまさに、私はしばしば、より思いやりのあるマーケティング関係者の何人かが、実装するのが非常に難しいと思った簡単な/簡単な機能について質問することさえ実際には恐れているという経験をしました。私はずっとoftenly反対を経験するものの:ここでXのバッチが「簡単」の特徴だ我々はすでに顧客に販売した、それは昨日で行わ取得してください....
Giel

50

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


14
@DisgruntledGoad-それは本当です。この「神話」の誤解は、モノリシックな紛らわしいコードを「良い」と考えるプログラマーが多すぎるという事実に由来しています。if user.is_logged_in: print('Welcome')コメントは不要です。
orokusaki

3
@orokusakiすべてのアルゴリズムがそれほど単純なわけではありません。
ジュークヴァンデルマース

25
@orokusakiは、「良いコードにはコメントが不要」と「単純なコードにはコメントが不要」と勘違いしています。良いコードは必ずしも単純ではありません。
不機嫌なヤギ

3
@Jouke van der Mass:もちろんです。しかし、アルゴリズムがどれほど複雑であっても、アルゴリズムを簡単に表現することは目標です。つまり、優れたコードは、複雑なアルゴリズム、ルール、最適化を、シンプルで明確に理解できる方法で表現します。単純なことを表現することは、比較的簡単です。複雑なものを表現することは、単にスキルのあるところです。
flamingpenguin

2
@orokuskai:良いコードは簡単です。それがしていることは複雑かもしれませんが、私の意見では、コードの単純さ(優雅さ)が良いことです!もちろん、コードは他にも多くのことを行いますが、ゴミのコードは多くのお金を稼ぐことができます。しかし、私の目標は複雑な状況でも簡単なコードを書くことです。
flamingpenguin

50

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

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


3
さらに悪いことに、プログラミングプロジェクトを一度もプログラミングまたは管理したことがない場合は、数冊の本を読んで、魔法のようにソフトウェアを実現できます。前のPMと一緒にその道を進んだので、私が住んでいる限りそれを繰り返すことを気にしません。
エヴァンプライス

4
さらに悪いことに、チームの優れたプログラマーはすべて、レポートの作成よりもコードの作成を好むため、平凡なプログラマーをProject Managerに昇格させる必要があります。考えは、彼は「技術的に十分」だろうということです。事実、彼はチームと上位管理者の間の偽情報フィルターになります。
AShelly

2
また、もしあなたが最高のプログラマーなら、あなたは明らかにプロジェクトマネージャーになり、その時点から実際のプログラミングを自分でやめるべきです!いいえ、ありがとうございましたが、私はまだ昇給します。注:リードプログラマーになるなどの話ではなく、十分な能力のないレベルに全員を昇進させるのは賢明な考えだと思うマネージャーの話です。
アランプラム

1
ピーター原則としても知られています。en.wikipedia.org/wiki/Peter_Principle
Spoike

よく言った
マイケルイースター

50

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


私はそれについて聞いたことがありませんでしたが、それは有効です。もちろん、あいまいな言語を使用すると、それは起こります。
マニエロ

5
@bigown、「あいまい」?どれくらいあいまいですか?TCLは不明瞭ですか?ハスケル?パスカル(Delphi)?Python?私はそれらが不明瞭ではないと思います。多くの人は自分がそうだと思っており、「深刻な」開発では非常に狭い言語セット(C ++、C#、Java)のみが許可されています。
P

5
@bigown:ああ、あなたはCOBOLのようなあいまいさを意味しますか?:p
AnonJr

2
私はかつてLinuxでObjective-Cコードを実行している小さな会社で働いていました。CEO-エンジニアではないが技術的な知識はあったが、ObjCプログラマーがいるとか、他の誰かがそれを使用しているとは信じられなかった。実際、優秀な開発者を雇うのに問題はなかった。

4
私はまったく逆のことが正しいという議論を読みました:あいまい(または少なくとも商業的に重要ではない)で、クールで、楽しく、面白い(その文脈ではPythonとRubyを意味する)言語には、仕事よりも多くのプログラマがいます。さらに、彼らはすべて、クールで楽しく、興味深い言語に興味がある人なので、賢くなければなりません。したがって、実際には、Pythonで作業するということは、Javaで作業する場合よりも、賢明なプログラマーを雇う方が簡単だということです。私はそれを信じるかどうかわからないが、少なくとも正統派のアイデアと同じくらいもっともらしい!
トムアンダーソン

42

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


57
+1かつてインタビュアーに「C ++とJavaの違いは何ですか?」と聞かれました。そこで、いくつかの違いをリストしました。ネイティブコンパイラとJVM、ANSI標準とプロプライエタリ、ガベージコレクション、クラスローダなど。彼は学生ではなく、エンジニアリングマネージャーでした。
ビルカーウィン

11
@Bill、私の応答は、「それでは、なぜまったく異なる名前でそれらを参照するのですか?」
ジェシーC.スライサー

2
@Bill、あなたはテストに失敗し、採用されましたか?

20
私の応答は「さようなら」でしょう。
Foole

6
@Foole System.exit(1)を意味しませんか?
バリーブラウン

33

Java 遅いです。


18
しかし、公正を期すために、それがあることを使わなかった...
ダン・ディプロ

70
それはまだ....
フォスコ

16
コーヒーはどのように遅くなりますか?
さびた

6
@Rusty Decaf?。
ジョーフィリップス

29
「ノック、ノック。」—「だれがいますか」— 非常に長い一時停止…「Java」(stackoverflow.com/questions/234075/…の提供)
RegDwight

33

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

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


14
これはまさに、私が働いている会社の製品の1つに起こったことです。急いだ開発は見事でした。製品は大丈夫、開発者は経営陣から高く評価されました。その後、別のジュニア開発者が「小さな」バグを修正するように依頼され、コードを理解しようとした1週間後、あきらめて、シニアからのガイダンスを求めました。そして右のこの時間-アッパー管理は最終的にそれがジャンクの山だったし、最初から再コード化する必要が同意した後、2年間の大きな問題としてある受け入れることを拒否
Sk93

4
テクニカルマネージャーの間では、スキルの高い開発者はスキルのない開発者よりも生産性が10倍高いというよく知られた神話があります。この神話の直接的な結果は、コードを迅速に作成できる開発者であれば、バグが多いか、保守が難しいかに関係なく、称賛とプロモーションを得るということです。
rtperson

3
あなたはNEED強力な言語を。Paul Grahamsの言語の議論と、tiを使用して何ができるかを参照してください

4
@Thorbjørn:私はその記事を読みましたが、Paul Grahamはそれを間違っています。彼はLispの擁護者なので、彼は事実を利己的な議論にねじり、Lispを良く見せます。ひねりをあまり必要としないので、たぶん意識的でさえないかもしれません。彼が記事の終わりに向かって指摘するように、読みやすさと簡潔さの間には多くの重複があります。しかし、彼が描く結論は、現実世界のソフトウェア開発の状態とは完全に同期していません。はい、強力な言語が必要ですが、彼は間違った基準で力を測定しているので、彼が言うことを信じることは有害です。
メイソンウィーラー

3
@rtperson:生産性が10倍になる可能性があるというのは神話ではありません。速く終わる人は必然的に生産的です。
デビッドソーンリー

31

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


6
レッスンに依存します。私がマットレス工場で働いていたとき、私たちはタスク切り替えが私たちの生産にとって有害で​​あることを知りました。私たちは時間ではなく、作られたマットレスの数によって支払われたので、ちょっと重要です...そして、同じ理由の多くのためにここでも適用されるレッスン。
-AnonJr

これは、ほとんどがハードウェアを製造している場所で働くとき、非常に根強い神話です。私たちは私たちのソフトウェアに合わせてジャンプしてフープハードウェア「部分」と同じモデルに「構築」は驚くべきものだ...
AShelly

5
つまり、製造ソフトウェアは簡単です。コピーを作成するのは簡単で、何百万ものコピーを作成するのにそれほど費用はかかりません。これにより、人々は製造部分を完全に無視し、設計プロセスに製造を適用しようとします。
デビッドソーンリー

この、経済学が考えるこの研究は特に人々のための100
クーゲル

1
誰もがJack Reevesを読む必要があります:developerdotstar.com/mag/articles/reeves_design_main.html-これは、ソースコードが製品ではなく設計であるという考えの起源(または少なくとも初期の強力なステートメント)です。プログラマーは、工場の機械工ではなく、製図室のデザイナーのようなものであり、プログラミングの管理は、製造ではなく他の種類のエンジニアリング設計の管理のようなものでなければなりません。
トムアンダーソン

31

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


5
私は高校時代にこれらの事柄のいくつかを常に把握していましたが、最近はそれらが一般に私がしていることとは無関係であり、きちんとしたものはあるものの、自分のことを知っている人にお金を払い、好きなことをやる(つまり、コードを書く)。別の「コンピューターに良い」誤解かもしれません。
アランプラム

2
+1、またはわずかに1つ外れた接線-プログラマーであるあなたは、製造工場からリリースされる前に、製造工場から出荷された最新の範囲を超える超大型の水冷式300 LEDファンが回転しているためです。本当じゃない!それはまともな高速マシンで、黒い非常に安価なケースです。それ以上は気にしないでください!
外科コーダー

笑い、家に神の全能のゲーミングリグを持っている職場のPMアシスタントがいます。常に開発エリアにロールオーバーして、(製品A)または(製品B)を買うべきかどうかを尋ねます。 - (。彼が実際にどの)もすべて、4chanの上でたむろ開発チームを前提としてため息
ocodo

+1ワード。これはスポットです。私はソフトウェア開発者であり、誰かのインターネットを何度も設定するように頼まれてきましたが、基本的には試行錯誤とGoogle検索だけです。誰かに好意を与えた後、完全に無関係な何かが壊れて、それがあなたのせいであるとき、私はそれが最も好きです。
アンシュースラー

30

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


2
管理も含める
プラシャム

あなたがノーと言うとき、彼らはあなたが単に働くのが難しい人だと思います。
キャプテンセンシブル

+100、そしてそれが十分な「モチベーション」で、彼らはあなたの答えを変えることができます。または、別の(経験の浅い)開発者に行き、意図的に詳細の半分を省略して、彼に「はい」と言わせて、開発の途中で終わり、警告した正確な問題にぶつかるようにします。
ワイルドピーク

28

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


2
+1。ああ、はい、私たちがする必要があることは、すでにオープンソースでなければなりません。
sharptooth

7
多くの時間はあります...少なくともWeb開発には当てはまります。
WalterJ89

@ WalterJ89:そこにあるかもしれませんが、だからといってそれを使うのが良いという意味ではありません。オープンソースが自動的に良いコードを意味するわけではありません。
アランプラム

true ..しかし、Wordpress、Drupal、jQueryの場合は、eコマースのように無料ではない領域がありますが、多くの場合、ウェブは非常にオープンであり、オープンソースコミュニティは、独自のヘルプデスク以上のものです。
WalterJ89

7
反対も神話です。FOSSを使用してビジネスニーズを満たすことができないこと。
ターミナル

27

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

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


6
ほとんどの人がプログラミングが本当に何であるかさえ知らないのは助けにはなりません...彼らはそれがソフトウェアを作成しているという漠然とした考えを持っています...しかし彼らは本当にソフトウェアが何であるか明確な考えを持っていません...
Spudd86

7
「編み物のレシピを書く」。祖母はそれを理解する傾向があります。

Cでプログラムを作成し、Assemblyで最もパフォーマンスが重要な部分をやり直す人々を知っています。
ザズ

1
@Josh-パフォーマンスの問題がない限り、それは時間の無駄のようです。
JohnFx

1
@oosterwal-アセンブリはバイナリではなく、数学記号も使用しません。
JohnFx

26

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


5
* v(int)(void)++
ラスティ

1
@Rusty:構文的に正確である必要さえないのであれば、もっと悪い例が思い浮かびます。

4
ああ、はい、...コード「だけ書く」
Paddyslacker

24

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

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


6
組立ライン作業との違いについては同意しますが、多くの点で、家を建てることと大差ないと思います。
ビリーONeal

24

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


別の低レベル言語に拡張します。プログラマーが何をしているのかわからない場合は、反対の結果になる可能性があります。
マニエロ

2
別の一般的なバリアントは、クライアント/サーバーアーキテクチャへの切り替えです。「SQLにアップグレードすると、アプリがはるかに高速になります!」必ずしも。
JohnFx

はい、それは何回も全く逆です。SQLの種類のデータベースはACIDであるか、それとほぼ同じです。最悪の場合、SQLテクニックについての誤った考え方がパフォーマンスに悪影響を与える可能性があります。
マニエロ

6
Python / Perl / Ruby / etcで書かれたもののためのC ++ / Cへの移植。C / C ++:Pで書かれたもののasmへの移植。あなたは何をASMに移植するのだろうか?それをハードウェアに設計しますか?
MAK

1
@MAK -チェックアウトen.wikipedia.org/wiki/Handel-Cを
flamingpenguin

21

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


9
ああ、はい。ある会社がプログラマを冗長化する新しいオーサリングツールを作成し、それを採用するすべての人が先に進み、実際にそれを使用するために高額な<オーサリングツール>スペシャリストを雇うことは常に楽しいことです。適切な事例:Joomla!そしてそのすべてのナンセンス。
アランプラム

HA HA HA HA HA HAAA HA +1 :)
ビリーONeal

コボルはすでにそれを試みました:)
カーラ

20

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


1
まあ。HP XL WESMは、Symbol WS5100とほぼ85%同じです(OEMが進行中です)。監視コードと構成コードのその割合をコピーして貼り付けて、バグが2倍になるようにするか、最初から書き直して40倍の時間がかかり、5倍になるようにしたいですか?または、$ projectを高速化するためのいくつかの魔法の万能薬の1つであると考えている愚かな管理に圧迫されていますか?

1
小規模での再利用は40年以上前に解決されました。大規模での再利用は困難であり、私見ではまだ解決されていません。Robert Glass がソフトウェアエンジニアリングの事実と
誤fall
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.