「バスファクター」を向上させるために、適切なドキュメントとクリーンなコードを作成する必要がありますか？

ソフトウェア開発会社の主な目標の1つは、バスファクターを増やすことです。これは、Googleが主催した講演でも支持されています。

つまり、明日バスで走り去ってもプロジェクトが継続できるように、すべてをコーディングして文書化する必要があります。言い換えれば、あなたはあなたと同じようなスキルセットを持つ他のプログラマーに簡単に交換できるようにするべきです。

交換可能であることは、開発者の利益に反するものではありませんか？この本では、48の権力法則11 で、権力を得るために人々をあなたに依存させ続け、それが金銭的な報酬に変換されるようにすべきであると述べています。

6か月の一時停止後もプロジェクトを続行するために自分用のドキュメントが必要なシナリオとは別に、開発者とソフトウェア会社の間には明確な利害の対立があるようです。

プログラマーとして、本当に素晴らしいドキュメントと誰でも簡単に読めるコードを書くべきでしょうか。または、それが仕事をし、あなた自身がそれを理解できる方法でコードとドキュメントを書くべきですが、他の人はそれを理解するのに苦労するかもしれませんか？

誰も理解していないコードを書くのではなく、他の人よりも多くの経験と知識を集めて、かけがえのないものになるように努力する必要があります。前者の方法は、あなたが書いたコードを維持することを恐れ、嫌悪するので、誰もが一緒に作業することを避けようとする開発者になります。後者の方法では、マネージャーがチームに所属したいチームメンバーになります。

私の経験では、きれいに文書化された（できれば自己文書化された）コードを書くことは常に成果を上げてきました。実際、私は他の人を助けたり教えたりするためにほぼすべての機会を利用しました（そして、彼らがより良い何かを知ったときに彼らから学ぶこともあります）。実際、これは通常、チーム全体の作業を改善し、問題をより迅速に解決するのに役立ちました。これは、すべてのマネージャーの夢​​です。

あなたが組織や人々をとても透明に操るなら、彼らは愚かであるか、他の選択肢を残さないジャムの方が良いでしょう。よく実行されているソフトウェア開発ショップは、あいまいなコードと欠落しているドキュメントを確認し、大きな損害を与える前に単にあなたを解雇します。彼らがうまく走っていない、または他の開発者を彼らに働かせることができない場合、なぜあなたは彼らと一緒に罪を犯したいのですか？

PSグリーン氏もマキャヴェリ氏も、当時の「ハードマン」をmenめようとする本を書くことを別にして、実際に多くのことを成し遂げたわけではありません。一粒の塩で彼らのアドバイスをしてください。

かけがえのない場合、昇進することはできません。

かけがえのないようにしたくない。あなたは人々にあなたに依存していると感じさせたくない、あなたは彼らにあなたに感謝してほしい。一般に、権力の法則の半分でさえ関係（専門的または個人的）に適用されるべきであると信じる人々から遠く離れたいと思うでしょう。
これらのルールは、勝ち負け状況をうまく確立する方法に関する指示セットです。あなたが望むのは、双方に有利な状況です。
人々が感じ始めるとすぐに、あなたは彼らを勝ち負けの状況の負け側に押しやろうとします、彼らは反撃します。パートナーを負けた状態にするためのリソースを無駄に使用しているため、勝ち負けの状況を確立しようとすると、負け負けの結果になることがよくあります。

雇用主とこれを行う場合、彼らはあなたに知識の独占を減らすためにあなたに措置を強制しようとします。ほとんどの場合、これらはあなたがあなたの仕事をしなければならない方法に関するばかげたガイドラインであり、それによってあなたの仕事の生活を生き地獄に変えます。また、彼らは何かが壊れた夜の3時にあなたに電話します。あなたがそれを修正できる唯一の人だからです。レバレッジなどの状況を悪用しようとすると、逆効果になり、より多くのトラブルを引き起こす可能性があります。

墓地には欠かせない男性がたくさんいます。
-シャルル・ド・ゴール

だから、がらくたを切って、あなたの仕事をきちんとしてください。もしあなたが他の何かのためでなければ、あなたのために、あなたは貧しい魂である可能性が高いので、2年後にコードにいくつかの変更を加えなければなりません。

このサイトが魅力的な平均以上のプログラマーの数を考えると、否定的な反応は驚くにはあたらない。一般に、才能のある人々は、こうした種類のセキュリティによる難読化の戦術に頼る必要はありません。しかし、私は、彼らは熱心のドキュメントの大量作成することによって守られて自分自身のために少し領地外に刻まれていたいくつかのそれほど有能な開発者、とのフォーチュン500の自動車部品メーカーで働いていた恐ろしい彼らは設計されていたインターフェイスを。

ある男の仕事は、2つの完全に独立したサブシステムをブリッジするモジュールのコードを維持し、各システム上のモジュールがUARTを介して通信できるようにすることでした。基本的に、シリアルプログラミング101でした。次のような一般的なインターフェイスを作成するだけではありません。

  int sendData（int targetModule、void * data、size_t byteCount）;
  int recvData（int sourceModule、void * data、size_t maxBytes）;

彼は、2つの通信モジュールが互いに送信する可能性のあるすべてのメッセージごとに個別のオペコードを作成しました。つまり、彼のモジュールはすべてのメッセージについて知る必要があり、メッセージが追加または変更されるたびに更新する必要がありました。不適切な親密さについて話してください！

実は、この男はWordのドキュメントにすべてのオペコード/メッセージをきちんとリストし続け、必要に応じて熱心に更新しました。それが彼の仕事になりました。週に数回、彼はすべての人々に新しい改訂版を送り、不幸にも彼を彼らのクリティカルパスに乗せました。そして、経営陣はドキュメントを見るのが大好きだったので、これは「プロフェッショナル」と見なされていました。ちょっと、自動車産業を泣かせてくれます。

私のポイントは、ドキュメンテーションを書くことは、実際には、平凡なプログラマーを保護できることです。多くの場合、マネージャーは良いデザインと悪いデザインの違いを見分けることができず、多くの人は限られた情報で技術的な判断を迫られます。彼らにとって非常にストレスが多い。何十もの表がきちんとフォーマットされたWord文書を見ると、たとえそれが基本的に悪い考えであっても、非常に安心できます。

交換可能であることは、開発者の利益に反しませんか？

私はあなたにそれを破るのは嫌いですが、誰もが交換可能です。確かに、時々（あなたが経験豊富で十分に明るい場合）あなたを置き換えることはわずかな挑戦かもしれませんが、それは不可能から光年です。

雇用主（現在の雇用主だけでなく、あらゆる雇用主）にとって真に価値のある商品になる方法は、コードを読んでいる人（コードで作業するための時間を少し増やす）が簡単に理解できるコードを書く能力を実証することですコード（コードを掘り下げることなく、誰でもシステムの高レベルの概要を取得できます）。

実際、コードのドキュメンテーションが得意であることは、最近では困難な品質であるため、それだけで他のユーザーとの差別化に役立ちます。

クリーンで十分に文書化されたコードは、履歴書を作成する価値があります（少なくとも、具体的な結果、つまり「nドキュメントのおかげで最小限の立ち上げと支援で新しい開発者を導入できました」）自分にとって「かけがえのない」ものではありません。

交換可能であることは、開発者の利益に反しませんか？

その開発者の興味に依存します。あなたがあなたのキャリア全体のために単一の仕事でそれを突き出したい人であれば、無能に報い、良いお金を稼ぐ会社に完全に不可欠です。

しかし、おそらく彼らがそんなに多くの人を雇ったために、会社が倒産するとどうなりますか？次はどこに行きますか？15年間同じ仕事にとどまった理由を聞かれたらどうしますか？等々。

今度は別の方法で見てみましょう：誰でも読むことができるコードを書く人になることで仕事を失った開発者は何人いますか？

そのようなことが起こる唯一の可能性は、会社が問題を抱えており、人を冗長にしている場合です。それが起こっている場合は、外に出た方が良いでしょう、そしてあなたは今後のインタビューに非常によく準備されます。さらに、あなたの良心は完全に自由になります-あなたはあなた自身の自己利益のために書いた不可解なコードを残さないでしょう。

私はあなたがどんな人なのかわかりませんが、それは私の興味に役立ちます。

個人的には、私の最大の強みの1つは自分の仕事を自動化することだと思います。私は自分の要求に対して黒字になったとき、会社はどう思いますか？彼らは「大丈夫、今すぐ彼を追い払う」と思っているのか、それとも「なぜ彼を別の役割に移して、もう一度やらせないのか」と思っているのか？

交換可能であることは、開発者の利益に反しませんか？

あなたは正しいですが、私はあなたが交換可能の意味を誤解したと思います。文書化されていない多忙なコードを書いている1000人の開発者を見つけることができました。

安定したプログラムだけでなく、クリーンなコード、有益なドキュメントを作成し、プロジェクトの継続性を確保する開発者は、かけがえのないだけでなく、貴重です。

すでにいくつかの優れた答えがありますので、この質問を別の観点から扱います。

自分が「かけがえのない」ものにしようとすることで、ささいなゲームをプレイするときに何が起こるかを考えてください。会社があなたを許容している限り、あなたはあなた自身の混乱を維持する同じ仕事にとどまります。そして、それが最良のシナリオです。最悪のシナリオは、あなたの会社の他のより才能があり、より倫理的なエンジニアとマネージャーがあなたの貧しい慣行が会社に課している障害を見て、彼らがあなたを解雇することによってそれについて何かをすることを決定することですすべてゼロから。終わった。実際、それはよくあることです。

ここで、適切なコードと適切なドキュメントを作成するとどうなるかを検討してください。うまく機能するコンポーネントまたはシステムを作成します。動作中にしばらく動作した後、バグはスムーズに機能し、ほとんど調べる必要はありません。それを維持するために少しの努力が必要です。その後、より大きくより良いプロジェクトに進むことができます。人々はあなたが良い仕事をしたことを認め、あなたの意見を尊重し始めます。フードチェーン内で上に移動してより意味のある決定を下したり、より重要で影響力のある作業を行ったり、より高いレベルでプロジェクトを管理したりできます。あなたのキャリアは向上し、昇進し、あなたはより多くのお金を稼ぎ、あなたの仲間からの認識と承認を得、あなたの実績にますます重要なプロジェクトの成功を追加します。

どのルートを好むでしょうか？

あなたが単一障害点である場合、クライアント（または雇用主）はおそらくあなたを交換しようとします。どれほど重要に見えても、ソフトウェアを維持するよりもソフトウェアを交換する方が費用がかからない点が常にあります。ITが最もアウトソーシング可能な職業の1つである理由があります。

一方、交換可能であると、いくつかの貴重なメリットが得られます。

• 休暇を取ることができる
• 電話中でない
• 新しく終了するプロジェクトを離れて作業する自由

簡単なドキュメントを5分間作成しないと、コードを使用する必要があるときに1時間かけて読み直して説明することになります。

さらに悪いのは、上司が保守可能なコードを書いていないことがわかったため、新しい仕事を探すのに何日も費やすことです。

優れたドキュメントは、最終的にリファクタリング/進化によって廃止され、最新の状態に保つことは本当に時間がかかります。

クリーンコード+単体テスト>優れたドキュメント

あなたの質問に対する答えは「はい」です。はい、良いドキュメントときれいなコードを書く必要があります。そうでないと故意に行うことは整合性の欠如を示しますが、それはビジネスの世界でますます普及しているものの、どういうわけか突然「良い」ことではありません。

かけがえのない人はいません。自分がそうであると思う状況を作り出している人々は、そうでない困難な方法を見つける傾向があります。自分のために共依存関係を作ることは、雇用主だけでなくあなたも制限するため、逆効果です。

ソフトウェア開発会社の主な目標の1つは、バスファクターを増やすことです。

誤った前提。ソフトウェア開発会社（とにかく私が働いたことのある会社）の主な目標は、できる限り最高のソフトウェアを生産し、必ずしもその順序でお金を稼ぐことではありません。「バス要因」を減らすことは、お金を失うことを避けるための1つの方法にすぎません。

法律11人々があなたに依存し続けることを学ぶ。

それはあなたにとって何を意味しますか？

あなたは彼らがあなたの助けによってのみ前進することができるような方法で彼らを弱体化させたので、人々があなたに依存することを望みますか？または、あなたは賢く、洞察力があり、信頼でき、信頼でき、他の人も仕事をより良くするのを助けることができるので、人々があなたに依存することを望みますか？同僚の助けを借りずに同僚の見栄えを悪くしたいですか、同僚の見栄えを良くしてくれたことに感謝したいですか？

君に電話だ。

（量産コードを想定）

私はもう少し先に行く傾向があります。私はプログラムを「馬鹿な証拠」にすることについて書きましたが、私は常にそれを修飾しません：他の人が見ても働かないであろう多くのコードを書きます（少なくとも、それが書かれたときの期待です）。私その場合、私は自分を守ろうとしているバカです。プログラムが問題を検出するのは良いことであり、問​​題が非常に単純化されているため、エラーとその原因があることは明らかです。真実は、プログラムを書くとき（プログラムを時期尚早に実装しない限り）実装の詳細は明らかですが、クライアントに対して抽象化され、エラー耐性がある必要があります（モジュールの局所性が存在する場合でも）。その理由は、プログラムが非常に複雑になるからです。問題を分離できる場合もありますが、常にではありません。コンポーネントを非常に厳しく、シンプルで、十分にカプセル化され、馬鹿な証拠にすると、それらはうまくスケールする傾向があり、出荷前にほとんどの欠陥が検出されます。再利用が簡単で、プログラムを再利用するのに自信があり、時間を節約できます。あなたが書くこれらの複雑なプログラムは、プログラムからしばらく離れてから（あなたにとってさえ）より複雑になります。6か月で読むと、馬鹿な証拠バージョンと比較して、理解してデバッグするのに途方もない時間がかかることがあります。コンポーネントに重大な変更が導入されると、それ以外の場合は長期間検出されない可能性があります。プログラムは複雑です。その現実から逃れることはできませんが、それを馬鹿な証拠にすることはできます。したがって、ばかを証明するアプローチは、あなたのソフトウェアをあなたのジュニアやチームの新しい人でも理解、再利用、または保守できることを意味します（あなたと同じくらい良い/経験のある人だけでなく）。交換は別の懸念事項です。人々があなたのプログラムで作業するのが好きなら、あなたは良い仕事をしている-しないでください 交換の心配はありません。もちろん、理解できないプログラムがあなたの仕事を救うことができるシナリオを思いつくことができますが、他の人が使用して維持できる良いプログラムを書くことは、明らかにより小さな悪です（他の人の結果を見てください）。馬鹿な証拠ではない何かを書いていることに気付いたら、それを修正しようとします。

6か月の一時停止後もプロジェクトを続行するために自分用のドキュメントが必要なシナリオとは別に、開発者とソフトウェア会社の間には明確な利害の対立があるようです。

休眠状態の実装を再検討するときに、何を考えていたのか、本当にわかりません。あなたがされている場合、実際に経験し、その後、問題はあなたが使用して確立した方法論やアプローチにもっと頼ることができますので、簡単です。ただし、これらの方法論は不変であることも前提としています。ドキュメントが緩い場合でも、実装を守る必要があります（たとえば、このシナリオでNULLを渡すよりもよく知っている-その条件をテストします）。

プログラマーとして、本当に素晴らしいドキュメントと誰でも簡単に読めるコードを書くべきでしょうか。または、それが仕事をし、あなた自身がそれを理解できる方法でコードとドキュメントを書くべきですが、他の人はそれを理解するのに苦労するかもしれませんか？

私は、バカ防止アプローチをお勧めします。これは、バスファクターアプローチよりも明確でエラー耐性があります。プロジェクトの外部の誰かが簡単に理解できるようにプログラムとドキュメントを書いてください。あなたにとっても良いことです。そうすることはあなたの会社とチームにとってあなたの価値を高めるでしょう、彼らはあなたに取って代わることを望みません。

あなたは基本的にゲームを誤解しています。ゲームは、あなたが以前にやったことと同じ古いことをし続けることではなく、誰もそれを手に入れないので、あなたが書いたすべてのコードに対して責任を負います。ゲームはプロジェクトを完了して次のプロジェクトに移り、他の誰かが簡単に理解して作業できるコードを残して、新しいことをしてより多くの異なる責任を引き受けることができるようにします。あなたの前提は、あなたが学習したり改善したりする機会なしに同じことを何度もやり続けることに満足している場合にのみ機能します。

また、そのコードを頻繁に見る機会がない場合、意図的に難読化すると、6か月でコードを理解するのが困難になることも指摘しておきます。

私が書いた小さなコードを文書化します。他の人が読めるようにするためではなく、3か月後に読めるようにするためです！メンテナンスを簡単にすることです。あなたが書いたコードに責任があり、後で表示されるバグを修正できない場合、それを適切に文書化する必要があります...それができない場合、あなたがどのように交換可能であるかはかなり無関係ですあなたの仕事をする！

多くの場合、雇用主のリソースを人質にしようとしていたため、やり取りの不幸を経験した「かけがえのない」コンピュータープロフェッショナルはすべて交代しました。私に報告する人たちに、自分の時間は文書を「無駄にする」価値があると言われたら、できるだけ早く交換します。

将来の従業員が48の力の法則を倫理的または道徳的に受け入れられると考えるなら、それなしであなたはより良いと思われるでしょう。

本当にかけがえのないものにしたい場合（すべての答えを読んだ後に再考したいかもしれません...）-なぜコードを文書化しないで停止しますか？

間違いなく読むべきメンテナンス不可能なコードの書き方については本当に素晴らしいガイドがあります：http : //thc.org/root/phun/unmaintain.html

楽しい！（私は間違いなく...）