最も愚か者が多い職業の XNUMX つは、プログラマーを管理するマネージャーです。 全員ではありませんが、自分自身がプログラマーではない人たちです。 本のメソッドを使えば効率を「上げられる」（あるいは「効率」を上げられる？）と考えている方。 同じ本をわざわざ読むまでもなく、このビデオはジプシーのようなものです。
コードを書いたことがない人。 プログラマーを題材にしたハリウッド映画が作られている人たち、つまり、コマンド ラインを使用して電子メールを見る人たちです。 指標と期限と自分の給料以外には興味がない人。
多数派の人たち。
しかし、彼らは別の理由で愚かです。 彼らは、どちらか一方を理解することなく、効率性、あるいは少なくとも効果性を求めています（さあ、マネージャー、グーグル先生、違いは何ですか）。 本質、結果を得るまでの過程、その過程で発生する損失、開発にかかるコストなどを大まかに理解せずに。 一言で言えば、プログラマーをブラックボックスであるかのように扱うことです。
彼らがプログラマーの経営陣と衝突した理由はまさにXNUMXつだ。誇大広告、金、市場、そして同じようなバカが集まっているからだ。 迷うところがある。
機械組立生産に誇大広告があれば、私たちはそこに走ります。 ステーションワゴンはダメだ。 XNUMX月に近所でクリスマスツリーを売っていた男性が休暇中のITマネージャーだったとしても、私は驚かないでしょう。
つまり、可能であれば、こいつらの首を撃ってください。 心配しないでください、彼らは仕事を見つけます。 彼らの誰も、自分自身がプログラマーになるまでは、まともな仕事をすることはありません。 なぜなら、彼は自分が制御するプロセスの本質、メカニズム、ロジックを理解していないからです。
さて、マネージャーについては十分です。 さて、プログラマ向けの本題です。 高品質のコードの書き方を学習して開発効率を高める方法。
効率を高めるには、品質を損なうことなく問題をより迅速に解決する必要があります。 問題をより迅速に解決するには、高品質のコードをすぐに作成できる必要があります。 そして「高品質」、「書ける」、「すぐに」。 比喩を使って説明しましょう。
高品質のコードを書くことは、外国語を正しく話すことに似ています。 言語を知らないときは、その言語で自分の考えをまとめるのに多くの時間を費やします。
急いで何かを言わなければならない場合、いくつかの単語に固執するだけで、しばしば正しい単語ではなくなり、動詞の時制や発音の悪さは言うまでもなく、冠詞や正しい語順も忘れてしまいます。
答えをまとめる時間がある場合は、辞書やオンライン翻訳を開き、自分の考えをまとめるのに多くの時間を費やす必要があります。 しかし、その感情は依然として不快なものです。答えを言うのに、それが正しいかどうかはわかりません。 コードも同様で、書かれているようで動作するようですが、品質が良いかどうかは謎です。
それは二重の時間の無駄であることがわかります。 答えを導き出すには時間がかかります。 また、この答えを定式化するには時間がかかりますが、それは決して少なくありません。
高品質のコードを書くスキルがあれば、翻訳に追加の時間を費やすことなく、頭の中で完成したらすぐに答えを組み立てることができます。
高品質のコードを書くスキルは、アーキテクチャを設計するときに役立ちます。 間違った選択肢、実現不可能な選択肢、またはお下がりの選択肢を頭の中で考慮しないだけです。
要約すると、高品質のコードを書くスキルは問題解決を大幅にスピードアップします。
しかし、それだけではありません。 フェルト ブーツ マネージャーのおかげで、問題が XNUMX つあります。高品質のコードを書く理由がないということです。 マネージャーはコードを見ませんし、クライアントもコードを見ません。 お互いにコードを見せ合うことはめったになく、指定されたコード「チェッカー」または定期的なリファクタリングがある一部のプロジェクトでのみ、たまにだけです。
ほとんどの場合、クソコードは本番環境かクライアントに送られることが判明しました。 くだらないコードを書いた人は、安定した神経接続を形成します。くだらないコードを書くことは可能であるだけでなく、それが必要でもあります。それは受け入れられ、彼らはそれに対価を支払いさえします。
その結果、高品質のコードを書くスキルはまったく伸びる余地がありません。 条件付従業員が書いたコードは誰にもチェックされません。 彼が普通にプログラミングを学ぶ唯一の理由は、内なる動機です。
しかし、この内的動機は、効率や生産性に関する計画や要件と矛盾します。 この矛盾は、高品質のコードを支持する方向では明らかに解決されていません。なぜなら、人々はくだらないコードについて批判さえしないからです。 そして、たとえそうであったとしても、計画を達成できなかったことに対して。
どうすればいいですか？ 私は、組み合わせることができる XNUMX つの道を考え、提案します。
XNUMX つ目は、社内の誰かにコードを見せることです。 受け身ではなく（要求されたときや強制されたとき）、積極的に（えーっと、おい、私のコードを見てください）。 ここで重要なことは、甘い鼻水を投稿しないこと、コードに対する批判を丁寧な形式で表現しようとすることではありません。 コードがクソなら、コードはクソだと言います。 もちろん説明と、それをより良くするための推奨事項も含まれています。
しかし、この道もまあまあです。 その適用可能性は、接触が発生したポイントによって異なります。 作業がすでに実稼働に入っていて、コードがクソであることが判明した場合、やり直しても意味がありません。 より正確には、その理由 - 指標も低下します。 マネージャーが押しかけてきて、効率性の要求を押しつけてくるでしょう。 そして、クソコードは間違いなくバグの形で戻ってくることを彼らに説明しようとさえしないでください。それはあなたにとって逆効果になります。 二度とこのようなことをしないと約束することしかできません。
作業がまだ納品されていない場合、または開始したばかりの場合、コード (またはそのプロジェクト、アイデア) にクソを注ぐことは、非常に実用的な意味を持つ可能性があります。その人は普通にそれを行うでしょう。
XNUMX 番目の方法は、最もクールな方法ですが、勤務時間外にオープンソース開発を行うことです。 目標は何ですか: 大勢のプログラマー、つまりプログラマーがあなたのコードを見て、それについて話すことです。 社内の誰もが時間がありません。 しかし、世界中のプログラマーはまだ何もすることがなく、アプリケーションの観点から有用なものを書けば、彼らは間違いなく内部を調べます。
私の意見では、主な秘訣は、コードの品質と結果を提供する速度との間に矛盾が生じることがないため、勤務時間外にコードを書くことです。 少なくとも XNUMX 年間の開発状況を書きます。 期限も、技術仕様も、お金も、上司もあなたにプレッシャーをかけることはありません。 完全な自由と創造性。
自由な創造性の中でのみ、優れたコードとは何かを理解し、感じ、言語とテクノロジーの美しさを知り、ビジネスタスクの魅力を感じることができます。 さて、あなたは高品質のコードを書くことを学びます。
確かに、そのためには個人的な時間を費やす必要があります。 他の開発と同じように。 それをコストとしてではなく、自分自身への投資として考えてください。
出所： habr.com