プロのプログラマーではない、または決してプロではない人が、より読みやすく使いやすいコードを書くのを支援する[クローズ]

私はエルビスであり、アインシュタインになることを一生懸命学ぼうとしています。私はモートで働いています。

このクレイジーなバカは何を言っているんだ！？！？（最初の数段落だけを読む必要があります）

あなたがそのリンクを読む気にならないなら、基本的に、私はプロのプログラマーであり、私のボスはそうです（これは恐ろしく正確です）：

コンピューターサイエンスの学位はないが、OfficeとVBAに精通しており、通常は同僚の間で共有される生産性アプリケーションを記述するプロの基幹業務プログラマー

とは言うものの、私の仕事の大部分は、彼の丸石で結ばれたコードを取得し、生産準備を整えることです。しかし、非常に貧弱なスタイルとカーゴカルティズムがこれを難しくしています。これは、彼がプログラミングの本を読むことを嫌がり、コードをリファクタリングするのを手伝ってくれるという事実によってさらに悪化します。

プロのプログラマーではない人を助けるための戦略は他にもありますか？プロのプログラマーが私にとって使いやすく解釈しやすいコードを今後書くことはありませんか？

いくつかのコメントであなたの回答を見ているとき、あなたが経験していることが非常に一般的であることに気付いているかどうかはわかりません。特に、専門家（科学者と呼んでみましょう）がどのように手元の問題に合わせてアルゴリズムを組み込み、調整します。

科学者に文句を言い、彼らが変わることを期待するのではなく、科学者が「コードの品質」にあまり気を配ることを期待すべきではないことを理解してください。他のソフトウェア開発者に「コード品質」を気にするのは難しいことです。もちろん、主な関心がプログラミングではなくドメインにある人は言うまでもありません。

ここからどこに進むかは、「科学者」が自分の研究を理解する能力に自信を持っているかどうかに大きく依存します。あなたが彼らのコードを理解でき、あなたが物事を修正するときにそれを台無しにしないという彼らの自信があれば、通常は問題はありません。彼らはあなたの専門知識に依存します。

ただし、科学者がコードの変更を望まない場合は、自信をまだ「得ていない」可能性が高いです。その場合は、科学者の修正に集中するのではなく、自分で「修正する」ことに集中する必要があります。それが私が意味することは、彼らの自信を得るための手段を講じることです。おそらくこれを行う最も簡単な方法は次のとおりです。

テストプロセスの一部として：

1. アルゴリズムを理解しやすいもの（図、PDL、数学表記など）に変え始めます
2. アルゴリズムを理解することを学ぶ。
3. 必ずエッジケースを特定してください。
4. 単純化された「代替」表現が正しいかどうかを科学者に尋ねる
5. そして、あなたが発見した問題を最も重要に特定します。そして、「非難」とは言わずに、「アルゴリズムを見ていて、XYZがこれを行うはずなのか、そうするべきなのか気づいた」といったようなことを言います。この弾丸ほど自信が得られるものはありません。

バグの発見を開始し、それらの関心領域に関心を示した場合、少なくとも「プロフェッショナル」になるようにコードを修正し始める可能性が非常に高くなります。多くの場合、彼らはもはやプロトタイプをコーディングする必要性さえ感じないでしょう。彼らはあなたが彼らに教えたそれらの「代替」記法の1つで何かを書くだけで（彼らはそれを理解しなくても）、彼らはあなたがそれらの意味を知っているだろうという自信を持っています。

どういうわけか、私の最初の試みは、科学者がどのようにあなたを助けるために「コミュニケーション」をより良く助けることができるかについていくつかの提案を提供することです。しかし、あなたはそれを試したようです。ですから、あなたがコントロールできる唯一のステップはあなたがすることです。自信をつければ、ほとんどの場合、ドメインの専門家はコードを他の人に渡すので安心し、コードの記述に関わる細かい部分を心配する必要はありません。彼らはむしろアルゴリズムの改善に焦点を合わせていました。

時々、あなたができることは提案を提供し、それを後にすることです。たとえあなたが100％正しいとしても、上司や先輩が既に拒否したことややりたくないことを強調し続けると、あなたは感動しません。実際、これはあなたが提案者であろうと提案者であろうと関係を損なうでしょう。仕事を楽にするためにできることだけに集中してください。

あなたが言うように彼が本当に「プロのプログラマーではない、プロのプログラマーになることは決してない」とき、そしてあなたの仕事の大部分が本当に「彼の石畳のコードを取り、生産準備を整える」とき、それはあなたのように聞こえます彼がプログラミングをあなたに任せて、プロジェクトの管理部分に集中するとき、2人のチームはより生産的です。

ただし、これはあなたが正しいことを前提としています。私たちプログラマーは、他の人によって書かれたコードを、私たち自身よりもずっと軽視する傾向があります。この先入観は敗北するのが本当に難しく、同僚を過小評価することにつながります。「カーゴカルトプログラミング」と考えるものは、彼の観点から「実証済みのベストプラクティス」であり、「オブジェクト指向パターンのエレガントな適用」と考えるものは、彼にとって「不必要なオーバーエンジニアリング」かもしれません。話のあなたの側しかわからないので、私にはわかりにくいです。

他の人々のコードに対する軽disは、プログラミングスタイルが異なるほど強くなります。その場合、1つのプロジェクトに異なるプログラミングスタイルを混在させると保守が非常に難しくなるため、それは肯定的な本能です。

両方がもう一方のスタイルを真似できない場合、明確な責任を定義できます。1人がアプリケーションの一部を担当し、もう1人を他の担当者にします。両方のモジュール間で明確なインターフェースを一緒に定義しますが、内部実装は担当者に任せます。彼にコードのバグをもっと認識させるために、彼のためにユニットテストを書いて、一緒に指定したインターフェース契約に従って彼のコードが明らかに動作しないことを指摘することができます。

明確なコード所有権を確立することにより、さまざまなスタイルのより良い共存を実現できます。また、両方の人が自分のコードのバグを修正する責任がある場合は、お互いのコードを頻繁にナビゲートする必要はありません。

自問する必要があります。ここでの最終目標は何ですか？1.上司を助けるために？2.会社を支援するために？3.自分を助けるために？そして、上記のすべてに答える前に、速度を落としてください。答えはそれに依存するため、最初のタスクは主な目的を明確に定義することです。

目標が次の場合：

1. 上司を助けますか？それを放棄。彼はそれを求めているようには見えません。「彼は自分のコードが悪いことを知っているが、それは彼が必要とすることをする」と言った。それでは、議論の終わり。上司が現在の状況に不満を抱かない限り、彼は変わらず、彼を助ける努力をhelpしみません。将来のある時点で、彼が現状の「痛みを感じている」場合、あなたが信頼できるメンターとしての地位を確立し、彼がどこに助けを求めればよいかを願っています。

2. あなたの会社を助けますか？現在の状況は収益を脅かしていますか？締め切りは危険にさらされていますか？上級管理職は熱を増していますか？そうでない場合は、それを放棄します。（これは、基本的に、ジミー・ホッファが元の投稿へのコメントで述べたポイントです。）しかし、現在の状況が実際にあなたの部門/会社にとって容認できないリスクを表している場合、プロセスの変更が必要です。その場合は、座って別の輪郭を描くことをお勧めします分業。ここで重要なのは、上司のコードのリファクタリングに費やす時間は、新しいコードの作成に費やす方が良いことを説明することです。自分ですべてを書く時間はないと言いますが、それは私が提案していることではありません。それぞれの強みを最大化する方法を理解する必要があります。彼をモートと考えるのをやめ、優れたドメイン知識を持つジュニア開発者と考えてください。それは業界で非常に一般的な作業の取り決めであり、その中で成功する方法を学ぶのはあなただろう。たとえば、ことを確認して、彼がいることを知っているあなたは彼の専門知識がどのように不可欠な知っている（多くの場合、この手順を繰り返します）、そしてその後、市場に彼の知識を得るためのより迅速なパスとして、次の戦略（または類似のもの）を謙虚に提案します。 -すべての要件とアーキテクチャ。（c）前のステップで合意したインフラストラクチャを構築しながら、彼が出発してプロトタイプを構築し、すべてのアルゴリズム決定を実行できるようにします。（d）彼がそれを検証するためのテストを構築している間に、彼のアルゴリズムをあなたの構造に実装します。（e）ピアプログラミング環境でV＆Vを一緒に実施します。（たとえば、「このテストは失敗しました。なぜですか？アルゴリズムの論理エラーまたはコーディングの間違い？」;ここで繰り返します）。

3. 助けて？ここで正直に言ってください。自分の仕事を楽しんでいないと不平を言っているだけなら、上記の＃2について考えるのにもっと時間をかける必要があることをお勧めします。会社を気にせず、仕事を楽しんでいない場合は、履歴書の配布を開始してください。会社を気にかけているのに仕事を楽しんでいない場合は、両方のアカウントで＃2に焦点を当てる必要があります。しかし、その場合、あなたの情熱があなたの仕事の自己中心的な欲求不満からだけでなく、チームを支援したいという願望から純粋に生じていることが誰にでも明らかである場合にのみ、「win-win」です。

私はこの議論に何かを追加するかどうかはShowMessage('Hello');わかりませんが、同じ行がより多くのコードを持っていることを見つけるために、アクセス違反が行でまたは類似している同様のシナリオで働いていました右、

次の2つの基本的なオプションがあると思います。

1. コードを実行します。コードが正常に機能し、実行する必要がある場合は、上司がコードの修正を特に求めていない限り、そのままにしておきます。それはまた、あなたのコードがより良く見えることを彼に理解させ、仕事をあなたに任せるかもしれません（Dunkの答えでも指摘されているように）。
2. コードをプロフェッショナルにしようと固く決心しているなら、彼が使用できるライブラリ/フレームワークを構築してください。よく修正するエラー/戦略にパターンがある場合、それらをいくつかのライブラリファイルにまとめて、「会社のベースライブラリ」として彼に渡すことができます。共通インターフェース。