ご存知のように、私たちのJelasticプロジェクトは開発者の生活を楽にするために作成されました。そしてもちろん、私たちは常に彼らの願いに耳を傾け、彼らの心理学、思考、その他の側面を研究します。 以下に、大手コンピュータージャーナリストの1人であるNeil McAlisterによる記事を公開します。これは、以前にInfoWorldと英語のブログで公開されたものです。
記事の一部の条項は物議をかもしているように思えるかもしれませんが（たとえば、ロシアとウクライナでの開発とある意味で「オフショア」です）、すべてが非常に興味深いものです。
開発者のような開発されたロジックを持つそのような合理的な人々でさえ、神話を信じていることがわかります。 何人かのプログラマーは、すべてにもかかわらず信じたいことを信じています。
たとえば、古典的な誤解は、開発者を追加することでプロジェクト開発をスピードアップできるというものです。 フレデリックブルックは、1975年に彼の著書Mythical Man-Monthでこの神話を払拭しました。
ブルックは、既に十分に開発されたプロジェクトに開発者を追加してもプロセスがスピードアップしないと考えていました。 それどころか、開発プロセスがさらに遅くなります。 実際、これは、ソフトウェアプロジェクトの管理に関する一般に受け入れられている多くの概念を反証しています。
もちろん、今日のブルックスの例の中には時代遅れのように見えるものもありますが、一般的な考え方は依然として重要です。 彼の議論は非常に説得力があります。 37年後、神話的思考がプログラマーの間で普及し続けています。 引き続き同じ間違いを犯します。
以下に、プログラミングの神話の例をいくつか示します。その多くは、古い誤解に由来しています。
神話＃1：オフショアソフトウェア開発
今日、正気な人は、「オフショア」戦略なしで主要なソフトウェアプロジェクトを立ち上げることを考えないでしょう。 すべての主要なソフトウェアベンダーがこれを行っており、さらに、シリコンバレーの投資家はこのアプローチを主張しています。 すべてが非常に論理的に聞こえます。より少ないお金でより多くの開発者を使用できます。 そのため、プロジェクトを早期に完了し、保存することもできます。
しかし、ちょっと！ これは、Mythical Man-Monthの誤fallの典型的な例です。 私たちはすでに、より多くの人々を、そして遠隔地でさえもそれを悪化させるだけであることを知っています。
ブルックスによると、「ソフトウェア開発に人を加えると、3つの方向で全体的な労力が増加します。崩壊、新しい人の訓練、コミュニケーションの追加です。」
新しいリモートスタッフをトレーニングするために必要な努力は、国内の開発者と同じであると仮定します（危険な仮定）。 コミュニケーションの問題をアウトソーシングすることのほうがはるかに大きい。 言語、文化、タイムゾーンはオーバーヘッドのみを追加します。 さらに、リモート開発チームは多くの場合、スタッフの離職率が高くなるため、時間の経過とともにコミュニケーションが改善されることはほとんどありません。
アウトソーシングは魔法ではありません。 実際、この主題に関して明確な結論を引き出すことは困難です。 この無料のランチは、最終的に予想よりも高くつく可能性があります。
神話その2：優秀な開発者は数日間働いています。
よく知られているステレオタイプ：プログラマーは昼夜を問わず「コーディング」し、ピザとエネルギーは彼らの親友であり、週末に働き、ほとんど家にいません。
もちろん、これには多くの真実があります。
医学研究によると、プログラマーは「睡眠不足」の職業の中で5位にいます。 特にゲーム業界では、長時間労働は珍しくありません。
しかし、そうではないはずです。 このアプローチが生産性を向上させないという証拠はたくさんあります。 実際、それは善よりも害をもたらします。
ほとんどの場合、ソフトウェアプロジェクトは、開発プロセス中に発生した不正確な期限、不明確な段階、または追加のタスクのために立ち上げが遅れます。 小さな遅延が追加されるため、プログラマは追加モードで作業することを余儀なくされますが、彼らの努力はもはや達成できない目標の達成に費やされます。 プロジェクトの立ち上げはさらに遅れ、チームの士気は失われます。
一部の開発者は、「最後まで」作業に満足していますが、ほとんどの人は、すべての人々と同じように、家族、友人、そして私生活を持っています。 彼らは18.00にオフィスを出て喜んでいるでしょう。 したがって、コーダーが残業することを奨励する代わりに、遅れる理由とその修正方法に焦点を合わせた方がよいでしょう。 午前中に無料のピザを食べるよりもはるかに感謝します。
神話＃3：クールな開発者は他の開発者よりも10倍生産的
優秀な開発者を見つけるのは非常に困難ですが、優れたコーダーは伝説、または少なくとも地元レベルの伝説です。
おとぎ話を信じているなら、彼らはどこかで、平均的なプログラマーよりも桁違いに生産的な経験豊富なハッカーがいると言っています。
当然、これらの伝説的な「コードデミゴッド」を見つけるために、リクルーターと採用マネージャーは殺されます。 しかし、ほとんどの場合、彼らはビッグフットのようにとらえどころのないままです。 おそらくそれらは単に存在しません。
ほとんどの開発者はその中間にいます。 チームに非常に生産的なエンコーダーがある場合、他の開発者は非常に弱い可能性があります。
さらに、ブルックの研究は、出力コードがパフォーマンスの完全な推定値を提供しないことを証明しています。 最高の最高の人でさえ、作業週のコーディングとデバッグの約50％しか費やしていません。
スーパー開発者を待つのは悪い戦略です。 互いに補完する中規模のエンコーダーのスーパーチームを作成することをお勧めします。 だから、あなたはもっと多くの才能を持っているでしょう。
神話＃4：最新のツールはより良い結果を提供します。
ソフトウェアはテクノロジービジネスであり、テクノロジーはすべての問題を解決できると信じたいと思っています。 新しいプログラミング言語、フレームワーク、または開発環境がコストを削減し、市場投入までの時間を短縮し、コードの品質を改善した場合、それは素晴らしいことです。
多くの企業は、競合他社を回避するために、非伝統的な言語を使用しようとしました。 Yammerソーシャルネットワークの最初のバージョンはScalaで記述されています。 TwitterはRuby on Railsアプリケーションとして始まりました。 RedditとYahooストアは両方ともLispを使用して構築されました。
残念ながら、これらの実験のほとんどは短命です。 Yammerは、Scalaが通常の機能を提供できなかったときにJavaに切り替えました。 TwitterはRubyからScalaに、そして部分的にJavaに切り替えました。 Redditは、Phytonでコードを書き直しました。 Yahoo StoreはC ++およびPerlに移行しました。
これは、ツールの選択が重要ではないという意味ではありません。 特に、スケーラビリティがパフォーマンスと同じくらい重要なサーバー環境で。
しかし、私たちが見るように、多くの企業はよりファッショナブルなソリューションから従来のソリューションに移行しました。
たとえば、1970年にアメリカでAdaが開発されたとき、主な目標はいわゆるプログラミング革命でしたが、それは悲しいことです。 今日では、せいぜいニッチなツールです。
もちろん、これは新しいプログラミング言語の発明者の誰も止めません、そして、これは正常です。 だまされてはいけません。 高品質のソフトウェアを作成することが目標である場合、俊敏性、柔軟性、創意工夫、およびスキルは、2つの方法でテクノロジーを打ち負かします。 したがって、成熟した楽器を選択しても害はありません。
神話5：コードをチェックする目が多いほど、バグが少ない
オープンソース開発者には、「十分な数の目で、すべてのエラーが表面にある」という格言があります。 これはLinusの法則と呼ばれることもありますが、オープンソース運動の創始者の一人であるエリック・C・レイモンドは本当にそれを思いつきました。
開発者はコードを見て、必要に応じて欠陥を見つけて修正できるため、オープンソースにはプロプライエタリなソフトウェアよりも自然な利点があるという考えです。
悲しいかな、これは希望的観測です。 今日のほとんどのオープンソースプロジェクトには、参加者よりもはるかに多くのユーザーがいます。 多くのユーザーはソースコードを見ることさえしません。つまり、ほとんどのプロジェクトの目数は誇張されています。 さらに、エラーを見つけることは、それらを除去することを意味しません。
2009年に実施されたある調査では、多くの個々の開発者によって修正されたコードファイルには、プログラミングチームが取り組んだものよりもはるかに多くのエラーが含まれていることが示されました。 ご存じのように、「7人の乳母には目が見えない子供がいます。」
神話＃6：クールな開発者はコードを最大限に最適化する
プロのレーシングチームの仕事は、自分の車を誰よりも早くゴールに導くことです。 マシン自体は非常に重要ですが、それは鉄だけであり、ドライバーとメカニックの骨の折れる作業が必要です。 これはコンピューターコードにも当てはまると思いますか？ 残念ながら、アルゴリズムから最大のパフォーマンスを得るには、手動の最適化が常に最良の方法とは限りません。 実際、今日では非常にまれです。
1つの問題は、自分のコードが実際にどのように機能するかについてのプログラマーの仮定がしばしば誤っていることです。 高水準言語はプログラマーを機器から保護します。 その結果、コード作成者は、多くの場合役に立たず、プロジェクトに有害でさえあるような方法でコードを最適化しようとする場合があります。
たとえば、ビット演算を使用して2つの変数の値を交換するXORスワップアルゴリズムを考えてみましょう。 以前は効果的でした。 しかし、最新の高性能プロセッサは、パイプラインを使用して複数の命令を同時に実行することで生産性を向上させます。 今日、この方法でコードを最適化しようとすると、本当に遅くなります。
マルチコアプロセッサも問題を複雑にします。 それらを使用するには、マルチスレッドコードを記述する必要があります。 並列処理を正しく行うのは困難です。 1つのスレッドを高速化する最適化により、他のスレッドが誤って中断される可能性があります。 スレッドが多いほど、最適化のためのプログラムが難しくなります。 プロシージャを最適化できるからといって、それを実行する必要があるという意味ではありません。 ほとんどのプログラムは、起動時間の90％をコードのわずか10％の処理に費やしています。
多くの場合、ツールを信頼するだけです。 不要な手動最適化に時間を無駄にしないでください。コードの効率に注意することをお勧めします。
神話＃7：良いコードは「エレガントな」コード
ほとんどのエンジニアと同様に、プログラマーは問題に対する単純なまたは「エレガントな」ソリューションについて話すのが好きです。 問題は、これがコードを判断する良い方法ではないということです。
これらの用語はどういう意味ですか？ シンプルまたは「エレガント」なソリューションはありますか？ この「エレガントな」コードは効率的に機能しているのでしょうか、それとも最小行数を使用するコードですか？
ある意味では、プログラミング問題に対する最も「エレガントな」解決策を探すことは、別の種類の時期尚早な最適化です。
良いコードはそれほど単純でもエレガントでもないかもしれません。 最高のコードが機能し、うまく機能し、バグもありません。 なぜもっと頼むのですか？