最もバカが多い仕事の一つは、プログラマーマネージャーの仕事です。全員ではありませんが、プログラマーではなかった人たちです。本の手法を使えば効率を「上げる」（あるいは「効率」を上げる？）ことが可能だと考えている人。この本をわざわざ読む必要もなく、結局はジプシーのビデオがあるのです。
コードを書いたことがない人。プログラマーに関するハリウッド映画が作られる人々、つまり、コマンドラインを使用して電子メールを見る人々です。指標、期限、自分の給料以外には何も興味がない人。
大多数を占める人々。
しかし、彼らが馬鹿なのは別の理由がある。彼らは効率、または少なくとも効果（マネージャーさん、その違いを Google で検索してください）を望んでいますが、どちらも理解していません。本質を全く理解せずに、結果を得るまでのプロセス、その過程で生じる損失、開発にかかるコスト。つまり、プログラマーと一緒に仕事をするのは、ブラックボックスと一緒に仕事をするようなものです。
プログラマーたちが経営陣に群がった理由はただ一つ、誇大宣伝、金、市場、そして同じようなバカが集まっているからだ。迷ってしまう場所もあります。
機械組立生産に人気が出れば、人々はそこに駆け込むでしょう。ステーションワゴンはダメだ。 12 月に近所でクリスマス ツリーを売っている人が休暇中の IT マネージャーだとしても、私は驚かないでしょう。
つまり、可能であれば、この人たちを追い出してください。心配しないでください。彼らは仕事を見つけるでしょう。彼ら自身がプログラマーになるまでは、まともなことは何もできないでしょう。なぜなら、彼は自分が制御しているプロセスの本質、メカニズム、またはロジックを理解していないからです。
さて、マネージャーについてはこれで十分です。さて、本題に入ります。プログラマー向けです。質の高いコードの書き方を学ぶことで開発効率を向上させる方法。
効率を高めるには、品質を落とさずに問題をより早く解決する必要があります。問題をより早く解決するには、すぐに高品質のコードを書ける必要があります。そして「品質」、「文章」、「即時」。比喩を使って説明しましょう。
質の高いコードを書くのは、外国語を正しく話すことに似ています。言語を知らない場合、その言語で自分の考えをまとめるのに多くの時間を費やすことになります。
緊急に何かを言う必要がある場合、いくつかの単語を付け加えるだけで、多くの場合は間違った単語が使われ、冠詞や正しい語順、動詞の時制や間違った発音は言うまでもなく忘れられてしまいます。
答えをまとめる時間がある場合は、辞書やオンライン翻訳を開いて、考えをまとめるのに多くの時間を費やす必要があります。しかし、答えを言ってもそれが正しいかどうか分からないので、気持ちはやはり不快なものになります。コードでも同じです。書いたようで、動作しているように見えますが、それが良質であるかどうかは誰にもわかりません。
これにより、時間の損失が 2 倍になります。答えを出すのには時間がかかります。この答えをまとめるのにも時間がかかります。そして、その時間はそれほど短くはありません。
高品質なコードを書くスキルがあれば、翻訳に余分な時間を費やすことなく、頭の中でコードが成熟したらすぐに答えをまとめることができます。
質の高いコードを書くスキルは、アーキテクチャの設計に役立ちます。間違った、非現実的な、または不器用な選択肢を頭の中で考えることはなくなるでしょう。
要約すると、高品質のコードを書くスキルによって、問題解決のスピードが大幅に上がります。
しかし、それだけではありません。フェルトブーツ マネージャーのおかげで、問題が 1 つ発生しました。それは、高品質のコードを書く理由がないことです。マネージャーはコードを見ませんし、クライアントもコードを見ません。私たちはお互いにコードを見せ合うことはほとんどなく、割り当てられたコード「チェッカー」や定期的なリファクタリングがあるプロジェクトでのみ、たまに見ます。
ほとんどの場合、質の悪いコードが本番環境やクライアントに渡されることがわかります。ひどいコードを書いた人は、安定した神経接続を開発します。ひどいコードを書くことは可能であるだけでなく、必要であり、受け入れられ、さらには報酬が支払われます。
その結果、高品質なコードを書くスキルがまったく伸びる機会がなくなります。架空の従業員が書いたコードは誰にもチェックされません。彼が適切にプログラミングを学ぶ唯一の理由は、内的動機です。
しかし、この内的動機は、効率性と生産性に対する計画や要件と矛盾します。この矛盾は、明らかに高品質のコードによって解決されるわけではありません。なぜなら、ひどいコードを書いたからといって叱られることすらないからです。そして、計画を達成できなかった場合も当然です。
何をするか？私は組み合わせることができる 2 つのパスを提案します。
1 つ目は、社内の誰かにコードを見せること。受動的（求められたとき/強制されたとき）ではなく、能動的（ねえ、私のコードを見てください）です。ここで重要なことは、甘い言葉を並べ立てたり、コードに対する批判を丁寧な形で表現しようとしたりしないことです。コードがひどい場合は、「コードはひどい」と言います。もちろん、説明と、改善方法に関するアドバイスも付いています。
しかし、この道もまあまあです。適用性は接触が発生した時点によって異なります。作業がすでに本番環境に入っていて、コードがひどいことが判明した場合、やり直す意味はありません。もっと正確に言えば、理由はありません。指標も低下します。マネージャーが急いでやって来て、効率性に対する要求であなたを圧倒するでしょう。そして、ひどいコードは必ずバグの形で戻ってくることを彼らに説明しようとさえしないでください。それはあなたを悩ませるために戻ってくるでしょう。二度とそんなことをしないと誓うことしかできません。
作業がまだ提出されていない場合、または開始したばかりの場合は、コード (またはそのプロジェクト、アイデア) に酷評されることは非常に実際的な意味を持つ可能性があります。つまり、その人はそれを適切に実行するでしょう。
2 つ目の方法、最もクールな方法は、空き時間にオープンソース開発を行うことです。目標は次のとおりです。多数のプログラマー、具体的にはプログラマーがあなたのコードを見てコメントすることです。社内では誰も時間がありません。しかし、世界中のプログラマーはとにかく他にやることがないし、応用的な観点から役立つものを書けば、彼らは必ず中身を見てくれるでしょう。
私の意見では、主な秘訣は、勤務時間外にコードを書くことです。コードの品質と結果の速度の間に矛盾が生じなくなるためです。独自の開発を書くには少なくとも 1 年かかります。締め切り、技術仕様、お金、上司からのプレッシャーを受けることはありません。完全な自由と創造性。
自由な創造性があって初めて、クールなコードとは何かを理解し、感じ、プログラミング言語とテクノロジーの素晴らしさを知り、ビジネスタスクの魅力を体験することができます。そうですね、質の高いコードの書き方を学ぶことになります。
確かに、これにはあなた自身の時間をいくらか必要とします。実際のところ、他の開発も同様です。これを出費としてではなく、自分への投資として考えてください。
出所： habr.com
