「バス係数」を増やすには、優れたドキュメントとクリーンなコードを書く必要がありますか？
ソフトウェア開発会社の主な目標の1つは、自社の バス係数 を増やすことです。これは Googleが主催した講演 でも提唱されています。
つまり、明日バスに乗った場合でもプロジェクトを続行できるように、すべてをコーディングして文書化する必要があります。言い換えれば、自分と同じようなスキルを備えた別のプログラマに簡単に置き換えられるようにする必要があります。
置き換え可能であることは、開発者の利益に反することではありませんか？この本の中で 48の力の法則 規則11は、権力を得るために人々をあなたに依存させ続けるように努めるべきであり、それが金銭的報酬に変換されることを述べています。
6か月の一時停止後にプロジェクトを続行するためにいくつかのドキュメントが必要なシナリオとは別に、開発者とソフトウェア会社の間には明確な利益相反があるようです。
プログラマーとして、本当に優れたドキュメントと誰にとっても読みやすいコードを書くべきでしょうか。それとも、あなたが自分で理解できるようにコードとドキュメントを書いて、自分で理解できるようにすべきですか？
他の人が理解できないコードを書くことによってではなく、他の人よりも多くの経験と知識を集めることによって、かけがえのないものになるよう努めるべきです。前者の方法では、あなたが書いたコードを維持したり恐れたりするので、開発者は誰もが作業を避けようとします。後者の方法では、マネージャーがチームに参加したいと考えている、求められているチームメンバーになります。
私の経験では、きれいに文書化された（そしてできれば自己文書化した）コードを書くことは常に報われてきました。実際、私はほとんどすべての機会を利用して他の人を助け、教える（そして、彼らがより良いことを知ったときに彼らから学ぶ）とともに、私よりも能力の低い人に置き換えられる危険を感じたことはほとんどありませんでした。実際、これは通常、チーム全体の作業を改善し、問題をより早く解決するのに役立ちました。これは、すべてのマネージャーの夢です。そして、賢明なマネージャーは、優れたチームのメンバーを入れ替えたくありません。
組織や人々を非常に透過的に操作する場合は、愚かであったり、込み合ったりして他の選択肢を残さない方がよいでしょう。適切に実行されているソフトウェア開発ショップは、あいまいなコードと不足しているドキュメントを調べて、多くの損害を与える前に攻撃するだけです。それらがうまく実行されていない場合、または他の開発者に彼らのために働くようにさせることができない場合、なぜあなたは彼らと一緒に調停をしたいのですか？
PSグリーン氏もマキャベリも、当時の「ハードマン」になる人を称賛しようとする本を書いたことを除けば、実際にはあまり成果を上げていませんでした。一粒の塩で彼らのアドバイスを受けてください。
かけがえのない人は昇進できません。
あなたはかけがえのないものになりたくありません。あなたは人々にあなたに依存しているように感じさせたくありません、あなたは彼らにあなたに感謝してもらいたいのです。一般に、権力の法則の半分でも関係（専門家または個人）に適用する必要があると考える人々から遠く離れたいと思います。
これらのルールは、勝ち負けの状況をうまく確立する方法に関する一連の指示です。あなたが望むのは win-win の状況です。
人々が感じ始めるとすぐに、あなたは勝利-敗北状態の敗者側で彼らをプッシュしようとしています、彼らは反撃します。パートナーの全体的な成功に投資するのではなく、パートナーを敗北させるためにリソースを効果的に浪費しているため、勝ち負けの状況を確立しようとすると、多くの場合、負け負けの結果になります。
あなたがあなたの雇用主とこれを行う場合、彼らはあなたに措置を強制し、あなたの知識の独占を減らしようとします。ほとんどの場合、これらはあなたがどのようにあなたの仕事をしなければならないかについてのばかげたガイドラインであり、それによってあなたの仕事生活を生きている地獄に変えるでしょう。また、あなたはそれを修正できる唯一の人なので、何かが壊れたとき、彼らは夜の3時に電話します。レバレッジなどの状況を悪用しようとすると、裏目に出て問題が発生する可能性があります。
墓地には欠かせない男性がいっぱい。
-ゴール、チャールズド
だから、がらくたを切り、あなたの仕事を適切に行います。それ以外の場合は、あなたのために。あなたは貧しい魂である可能性が高いので、2年後にコードに変更を加える必要があります。
このサイトが引き付ける平均以上のプログラマーの数を考えると、否定的な反応はそれほど驚くことではありません。才能のある人々は一般に、この種の難読化によるセキュリティ戦略に頼る必要はありません。しかし、私はフォーチュン500の自動車サプライヤーで働いていましたが、才能のない少数の開発者が自分たちの領土を切り開いており、恐ろしい彼らが設計したインターフェース。
ある男の全体の仕事は、2つの完全に別個のサブシステムをブリッジするモジュールのコードを維持し、各システムのモジュールがUARTを介して通信できるようにすることでした。基本的には、シリアルプログラミング101でした。次のような一般的なインターフェイスを作成するだけではありません。
int sendData（int targetModule、void * data、size_t byteCount）; int recvData（int sourceModule、void * data、size_t maxBytes）;
彼は、1つのメッセージごとに別々のオペコードを作成し、2つの通信モジュールが互いに送信することを望んだ可能性があります。つまり、彼のモジュールはすべてのメッセージについて知る必要があり、メッセージが追加または変更されるたびに更新する必要がありました。不適切な親密さについて話します！
問題は、この男はすべてのオペコード/メッセージをきちんとリストしたWordドキュメントを保持し、必要に応じてそれを入念に更新したことです。それは彼の仕事全体になりました。週に数回、彼は彼に彼らの重要な道を歩かせるのに十分残念なことにすべての人々に新しい改訂を送ります。また、管理職が愛用しているのドキュメントを見て以来、これは「プロフェッショナル」と見なされていました。ちょっと私は自動車産業のために私を泣かせます。
私のポイントは、おそらくドキュメントを書くことが、実際にはprotect平凡なプログラマーである可能性があることだと思います。多くの場合、マネージャーは良いデザインと悪いデザインの違いを見分けることができず、多くの人は限られた情報で技術的な決定を迫られます。それは彼らにとって信じられないほどストレスになります。何十ものきちんとフォーマットされたテーブルを含むWord文書を見ると、とても快適になります。
置き換え可能であることは、開発者の利益に反することではありませんか？
私はあなたにそれを壊すのは嫌いですが、everyoneは置き換え可能です。確かに、場合によっては、あなたを置き換えることは少し難しいかもしれませんが（経験豊富で十分な才能がある場合）、不可能から光年です。
雇用主にとって本当に貴重な商品になるための方法（現在の雇用主だけでなく、any雇用主）は、簡単に実行できるコードを書く能力を実証することですコードを読んで（コードを操作するのに少し時間がかかる）だれかがコードを文書化します（誰もがコードを掘り下げることなく、システムの高レベルの概要を取得できます）。
実際、コードドキュメンテーションでgoodになることは、最近では困難なことなので、単独で他の人と区別するのに役立ちます。
クリーンで十分に文書化されたコードは、履歴書に含める価値もあります（少なくとも、その具体的な結果、つまり、「私のドキュメントにより、最小限の立ち上げと支援でn新しい開発者を投入することができました）」 、自分を「かけがえのないもの」にすることについて卑劣であることはそうではありません。
置き換え可能であることは、開発者の利益に反することではありませんか？
その開発者の興味が何であるかに依存します。あなたがキャリア全体の単一の仕事でそれを突き出したい人であるなら、無能を報い、良いお金を稼ぐ会社に完全に不可欠です、そうです、絶対に。
しかし、おそらく彼らがそのような人をあまりにも多く雇ったために、会社がクラッシュするとどうなりますか？次はどこへ行くの？ 15年間同じ仕事を続けた理由を尋ねられたらどうでしょうか。等々。
では、別の方法で見てみましょう。だれでも読み取ることができるコードを書く人になったことで、仕事を失った開発者は何人いますか。
それが起こる唯一の可能性は、会社が問題を抱えており、人々を冗長にした場合です。それが起こっている場合、あなたは外に出る方がいいです、そしてあなたは次のインタビューのために非常によく準備されます。さらに、あなたの良心は完全に無料になります-あなた自身の自己獲得のためにあなたが書いた不可解なコードを置き去りにすることはありません。
私はあなたがどんな人かはわかりませんが、それは私の利益のために役立ちます。
個人的には、自分の仕事を自動化できることが最大の強みだと思います。私が自分の要件に対して余剰になったとき、会社はどのように考える傾向があると思いますか？彼らは「わかりました、今すぐ彼を取り除く」と思いますか、それとも「なぜ彼を別の役割に移して、もう一度彼にさせないのか」と思いますか？
置き換え可能であることは、開発者の利益に反することではありませんか？
あなたは正しいですが、私は交換可能の意味を誤解していると思います。保守性のない混乱にすぐに変わることがある、文書化されていない多忙なコードを書く1000人の開発者を見つけることができました。
安定したプログラムだけでなく、クリーンなコード、有益なドキュメントも作成し、プロジェクトの継続性を保証する開発者は、かけがえのないだけでなく、pricelessです。
すでにいくつかの優れた答えがあるので、私は別の視点からこの質問に取り組みます。
他の人があなたのコードがどのように機能するかを学ぶのを防ぎながら、自分を「かけがえのないもの」にしようとすることによってささいなゲームをするとき何が起こるかを考えてください。会社が許容する限り、あなた自身の混乱を維持する同じ仕事にとどまります。そしてそれが最良のシナリオであり、最悪のシナリオは、あなたの会社の他のより才能があり、より倫理的なエンジニアとマネージャーがあなたの悪い慣行が会社に課している妨害を見て、彼らがそれについて何かをすることに決めたということです：あなたを解雇して書き直すことによってすべてをゼロから。完了しました。実際、これはかなり一般的なことです。
次に、適切なコードと適切なドキュメントを作成するとどうなるかを考えます。正常に動作するコンポーネントまたはシステムを作成します。しばらくすると、動作中にバグがスムーズに動作し、ほとんど確認する必要がなくなります。それを維持するために少しの努力が必要です。その後、より大きくより良いプロジェクトに進み、確実な勝利を収めることができます。人々はあなたが良い仕事をしたことを認め、あなたの意見を尊重し始めます。フードチェーンの上位に移動して、より有意義な決定を下したり、より重要でインパクトフルな作業を行ったり、より高いレベルでプロジェクトを管理したりすることができます。あなたのキャリアは向上し、あなたは昇進し、あなたはより多くのお金を稼ぎ、あなたは仲間からの認識と承認を得、あなたはあなたの実績にますます重要なプロジェクトの成功をますます加えます。
どのルートを選びますか？
単一障害点の場合は、クライアント（または雇用者）がおそらくあなたに取って代わろうとします。どのように重要であるかに関係なく、ソフトウェアを交換する方が維持するよりもコストがかからない点が常にあります。 ITが最も外部委託可能な職業の1つである理由があります。
一方、交換可能であることには、いくつかの貴重なメリットがあります。
- 休暇を取ることができる
- 通話中でない
- 新規および既存のプロジェクトを離れて作業する自由
簡単なドキュメントの作成に5分を費やさない場合は、1時間かけて読み直し、コードを使用する必要があるときに説明します。
さらに悪いことに、あなたは上司があなたが保守可能なコードを書いていないことを知ったので、新しい仕事を探すために何日も費やすことがあります。
優れたドキュメントは、最終的にはリファクタリング/進化によって時代遅れになり、それを最新に保つことは本当に時間がかかります。
クリーンなコード+ユニットテスト>優れたドキュメント
あなたの質問に対する答えは「はい」です。はい、良いドキュメントとクリーンなコードを書くべきです。意図的に別の方法で行うと整合性の欠如を示しますが、これはビジネスの世界でますます蔓延している一方で、どういうわけか突然「良い」ものではありません。
かけがえのない人はいません。自分がそうではないと考える状況を作り出す人々は、自分がそうではない困難な方法を見つけがちです。自分のために相互依存関係を作ることは、雇用者だけでなく、あなたをも制限するので逆効果です。
ソフトウェア開発会社の主な目標の1つは、バス係数を増やすことです。
誤った前提。ソフトウェア開発会社（とにかく私が働いていたすべての会社）の主な目標は、できる限り最高のソフトウェアを作り、お金を稼ぐことです。必ずしもこの順序ではありません。 「バス要因」を減らすことは、お金の損失を回避するための1つの方法にすぎません。
法律11人々をあなたに依存し続けることを学ぶ。
それはあなたにとってどういう意味ですか？
あなたは彼らがあなたの助けを借りてのみ前進することができるような方法で彼らを弱体化させたので、人々はあなたに依存して欲しいですか？それとも、あなたは賢く洞察力があり、信頼性があり、信頼でき、他の人がよりよく仕事をするのを助けることができるので、人々があなたに依存することを望みますか？あなたの助けを借りずに同僚の見栄えを悪くしたいですか、それとも同僚に見栄えを良くしてくれて感謝したいですか？
君に電話だ。
ゲームを根本的に誤解しました。ゲームは、あなたが以前に行ったのと同じ古いことを続け続けることではなく、他の誰もそれを取得しないので、あなたが書いたすべてのコードに対して責任があります。ゲームはプロジェクトを完了して次のプロジェクトに移り、不在時に他の誰かが簡単に理解して作業できるコードを残して、新しいことを実行してさまざまな責任を引き受けることができるようにします。あなたの前提は、学習したり改善したりする機会がなく、同じことを何度も繰り返して困っている場合にのみ機能します。
また、そのコードを頻繁に見る機会がない場合、意図的に難読化すると、6か月後にコードを理解するのが困難になることも指摘しておきます。
（生産コードを想定）
私は少し先に行く傾向があります。私はプログラムを「馬鹿な証拠」にすることについて書いてきましたが、常にそうであるとは限りません。私は他の人が見たり操作したりしない多くのコードを書きます（少なくとも、それは書かれているときの期待です）。 [〜＃〜] i [〜＃〜]その場合、自分を守ろうとしている馬鹿です。プログラムが問題を検出し、問題が非常に単純化されているため、エラーとその原因が明らかである場合、これは良いことです。真実は、実装の詳細はプログラムを作成するときに（それを時期尚早に実装している場合を除いて）明らかですが、それらは抽象化され、クライアントに対してエラー耐性がある必要があります（モジュールの場所が存在する場合でも）。その理由は、プログラムが非常に複雑になるからです。問題を分離できる場合もありますが、常にそうであるとは限りません。コンポーネントを非常に厳格でシンプル、十分にカプセル化され、ばかである証拠にしておけば、それらはうまく拡張する傾向があり、ほとんどの欠陥は出荷前に検出されます。再利用が簡単になり、プログラムを再利用する自信が増し、時間も短縮されます。また、作成する複雑なプログラムは、プログラムから離れて初めて複雑になります。 6か月でそれを読んだ場合、ばか証明バージョンと比較して、理解してデバッグするのに不合理な時間がかかることがあります。コンポーネントに重大な変更が導入された場合、それ以外の場合は長期間検出されない可能性があります。プログラムは複雑です。あなたはその現実から逃れることはできませんが、それをばかげた証拠にすることができます。したがって、ばか証明のアプローチは、あなたのソフトウェアがあなたの後輩やチームの新しい人たち（あなたと同じくらい良い/経験のある人だけでなく）によっても理解、再利用、または維持できることを意味します。置き換えは別の問題です：プログラムで作業するのが好きな人なら、良い仕事をしています-置き換えについて心配しないでください。確かに、理解できないプログラムがあなたの仕事を救うことができるシナリオを思い付くことができますが、他の人が使用して維持できる優れたプログラムを書くことは明らかに害が少ないです（他の人の反応を見てください）。私がばか証明ではない何かを書いているのを見つけたら、私はそれを修正しようとします。
6か月の一時停止後にプロジェクトを続行するためにいくつかのドキュメントが必要なシナリオとは別に、開発者とソフトウェア会社の間には明確な利益相反があるようです。
休止状態の実装に戻ったときに、何を考えていたのか本当にわかりません。 本当に経験があると、確立された方法論やアプローチをより信頼できるため、問題はより単純になります。ただし、これらの方法論は不変であると想定しています。ドキュメントがゆるいかもしれませんが、実装では防御的である必要があります（たとえば、このシナリオでNULLを渡すよりも知っている-その条件をテストします）。
プログラマーとして、本当に優れたドキュメントと誰にとっても読みやすいコードを書くべきでしょうか。それとも、あなたが自分で理解できるようにコードとドキュメントを書いて、自分で理解できるようにする必要がありますが、他の人が理解するのに苦労するかもしれません。
バスファクターアプローチよりも明確でエラー耐性の高い、ばか証明アプローチをお勧めします。プロジェクトの外部の誰かが簡単に理解できるように、プログラムとドキュメントを作成します。これもあなたにとって良いことです。そうすることはあなたの会社とチームへのあなたの価値を増加させます、彼らはあなたを置き換えるためにwantをしません。
私が書いた小さなコードを文書化し、他の人がそれを読むことができるようにするのではなく、[〜＃〜] i [〜＃〜]が3か月でそれを読むことができるようにします！メンテナンスを簡単にすることです。あなたが書いたコードを担当していて、後で発生するバグを修正できない場合は、それを十分に文書化しておく必要があります...できなければ、どのように置き換え可能かは重要ではありません。あなたの仕事をする！
私がやり取りする不運を経験したすべての「かけがえのない」コンピュータプロフェッショナルは、主に彼らが雇用者のリソースを人質にしようとしたために取り替えられました。私に報告する人々が彼らの時間は「無駄」な文書化に貴重であると私に言ったとき、私は彼らをできるだけ早く取り替えます。
見込みのある従業員が 48の力の法則 を倫理的または道徳的に許容できると見なすと、彼らなしでより良い結果が得られるようです。
あなたが本当にかけがえのないものになりたいのなら（あなたはすべての答えを読んだ後で再考したくなるかもしれません...）-なぜコードを文書化しないことでやめるのですか？
あなたが間違いなく読むべき保守不可能なコードを書く方法についての本当に素晴らしいガイドがあります http://thc.org/root/phun/unmaintain.html
楽しい！ （私は確かにそうしました...）