オリジナル記事の翻訳。

Facebookがコードを開発する方法

Facebookの仕組みに魅了されています。 これは非常にユニークな社会であり、簡単に再作成することはできません（そして、彼らの方法は、たとえ試みたとしても、すべての企業に有効ではありません）。 これらは、会社がソフトウェア製品を開発およびリリースする方法について、多くのFacebookの友人との会話から蓄積されたメモです。

これらの観察結果を収集してから6か月以上が経過しましたが、今でもFacebookはソフトウェア開発方法を常に改善していると確信しています。 したがって、これらのメモはおそらく少し時代遅れです。 また、開発者が推進するFacebookの文化が注目を集めているようです。 だから今、私はこれらのメモをリリースすることをより快適に感じています...内部からFacebookのこのアイデアをまとめるのを助けてくれた多くの人々に感謝します！ また、訂正して編集したエプリーとフライフロッグの人々にも感謝します。

UPD ：翻訳は、読まれて息をのむようなカラフルな文学作品ではありません。 したがって、可能であれば、英語で原本を読んでください。


注：

• 2010年6月現在、同社は約2,000人の従業員で構成されており、10か月前には1,100人の従業員で構成されていました。 1年足らずでスタッフがほぼ2倍になりました！
• 最大のチームは、それぞれ約400〜500人の専門家と運用部門です。 両チームは州全体のほぼ50％を占めています。
• マネージャー数とスペシャリスト数の比率は、約1：7または1:10です。
• すべてのスペシャリストはトレーニングセンターで4〜6週間のトレーニングを受け、そこでエラーを修正（バグ修正）し、シニア/フルタイムのスペシャリストによる講義を聞くことでFacebookシステムを学習します。 各トレーニングクラスの約10％の人々はこれ以上先に進まず、会社からの推薦で辞めます。
• トレーニングセンターの後、すべての専門家が最新のデータベースにアクセスできます（標準講義「大きな責任には大きな責任が伴う」、およびユーザーの個人データの開示などの「発射可能な犯罪」の明確なリストが含まれます）。
• [編集 thx fryfrog]「社内の誰もが思い浮かぶような恐ろしいことをしないようにする非常に優れたセキュリティ対策もあります。 あなたの周りの人々は、スピードを上げて問題を解決しようとする機会があります。 しかし、それでも助けが必要な人に「なる」場合、この事実は理由とともに記録され、慎重に検討されます。 もちろん、ここの本当の道から外れることは許されません。」
• スペシャリストは、Facebookコードの任意の部分を変更して、必要に応じてコミットできます。
• 開発者主導の文化。 「製品マネージャーはここでは本質的に価値がない」と専門家からの引用。 スペシャリストは、開発プロセス自体の仕様を変更し、作業プロジェクトの順序を変更し、いつでも新しいアイデアを導入できます。
• 毎月のチーム間会議では、進捗状況を報告するのはスペシャリストのみです。 マーケティング部門と管理部門はこれらの会議に参加していますが、率直すぎる場合は、「前回の会議で製品の発言が多すぎた」と経営陣に報告します。 彼らは、スペシャリストが開発をオープンに所有し、開発したプロジェクトの主要なコミュニケーションリンクになることを本当に望んでいます。
• プロジェクトへのリソースの割り当ては完全に任意です。
  
  • PMは専門家のグループを集め、興奮を味わう機会を与えようとして、自分のアイデアについて話し合います。
  • 専門家は、作業を開始するために、どのアイデアがより興味深いと思うかを決定します。
  • スペシャリストはマネージャーとコミュニケーションをとり、「ここでこれら5つのことを1週間やりたい」と言います。
  • 技術 ディレクターは通常、専門家の好みを彼らの裁量に任せます。時々、彼らは最初の場所で特定の仕事をするように頼まれるかもしれません。
  • スペシャリストが開発全体を管理します-フロントエンドのJavaScript、バックエンドのデータベースコード、およびその間のすべて。 彼らがデザイナーの助けを得たい場合（専門デザイナーのスタッフは限られています）、彼らは彼らのプロジェクトを引き受けるのに十分なほどデザイナーに興味を抱かざるを得ません。 同じことが建築家にも当てはまります。 しかし、ほとんどの場合、専門家はすべてのニーズに対処することが期待されています。
  
  
• 食べられた卵は通常、その実装から1週間以内に明確になり、たとえばネバダ州のユーザーの1％など、選択したユーザーでさらにテストするというアイデアに値しますか。
• 一般的に、専門家はインフラストラクチャ、スケーラビリティ、および「難しい問題」に取り組むことを好みます。これは最も権威のある分野です。 フロントエンドプロジェクトとユーザーインターフェイスに熱心に取り組んでいる専門家を観察することは困難な場合があります。 これは、ユーザーが直接触れるものを誰もが開発したい他の消費者市場で見ることができるものの反対であり、指で特定の部分をつついて「やった」と言うことができます。 Facebookでは、ニュースフィードアルゴリズム、ターゲット広告アルゴリズム、memcacheの最適化などのサーバー側は、専門家が取り組みたい一流のプロジェクトです。
• いくつかの優先度の高い機能（ニュースフィードなど）に影響するコミットは、マージする前にコードチェックに合格します（約Per。“マージ”）。 ニュースフィードは非常に重要であるため、Zuckerberg自身がその変更を調べますが、これは例外的なケースです。
• [訂正-thx epriest]「すべての変更のコードの検証は必須です（1人以上の専門家による）。 「この段落では、Zuckが各変更を個人的に見ないことを単に説明していると思います。」
• [Thx fryfrogの修正]「すべての変更は少なくとも1人のユーザーによって表示されます。システムは、あなたが頼まなくても、誰でもコードを取得して表示できるようになっています。 そうしないと、未検証のコードに意図的に悪意のあるコードが導入される可能性があります。
• 専門家は、テスト、バグの修正、およびリリース後の作業のサポートを担当します。 いくつかの単体テストと統合テストのフレームワークが利用可能ですが、それらは時々のみ使用されます。
• [Thx fryfrogの修正]「もちろん、公式グループではなく、QAを持っていることも付け加えたいと思います。 オフィスにいる、またはVPN経由で接続している各従業員は、次の計算のためにキューにあるすべての変更を含むバージョンのサイトを使用します。 このバージョンは絶えず更新されており、通常は全世界が表示される1〜12時間前です。 すべての従業員は、見つかったバグを報告することを強くお勧めします。これはすべて非常にうまく機能します。
• re：QAまたは自動化された単体テストの欠如に驚いた-「ほとんどの専門家はエラーのないコードを書くことができます。 これは、ほとんどの企業で行う理由がないと彼らが考えるものです。QA部門がある場合、単にすべてを投げて間違いを見つけるのは簡単です。」[これは主観的な意見であり、他社の標準的な開発慣行に見られます]。
• [Thx epriest fix]「プッシュブロッキングテストを含む自動化されたテストがあり、リリースを投稿する前に完了する必要があります。 「ほとんどの専門家はエラーのないコードを書くことができる」というフレーズは絶対に信じていません。これが開発の基本原則の1つとして合理的であると私たちは信じています。」
• 日時：PMの影響/制御の欠如に驚いた-マネージャーは多くの独立性と自由を持っています。 独立の鍵は、CTOとの本当に良い関係を築くことです。 愚かなアイデアを提供しないように、技術に精通している必要があります。 さらに、許可を求める必要も、ロードマップ/バックログのチェックに合格する必要もありません。 「私のプロダクトディレクターは、ロードマップにあるすべてのことすら知りません。」 したがって、いくつかのPMがいますが、彼らはすべて、個人的な関心を持って、会社の本当に重要な分野に対して大きな責任があると感じています。
• デフォルトでは、すべてのコードコミットは毎週のリリース（火曜日）にパッケージ化されます。
• さらに努力すれば、変更を同じ日に投稿できます。
• 火曜日のリリースでは、前週にリリース候補者のためにコードをコミットしたすべての専門家が参加する必要があり、アップロードする必要があります。
• リリースが始まる前に、スペシャリストは特別なIRCチャンネルに「レイアウトの呼び出し」のために出席する必要があります。そうでない場合、専門家は公開の「恥」で罰せられます。
• 運用チームがリリースを開始し、徐々にサーバーに展開します。
  
  • Facebookには約60,000台のサーバーがあります。
  • 新しいリリースを展開するための9つの同心円レベルがあります。
  • [Thx epriest fix]「計算の9つの段階は同心ではありません。 同心円状の3つのステップがあります（p1 =内部リリース、p2 =小さな外部リリース、p3 =完全な外部リリース）。 残りの6つのステージは、内部ツール、ビデオダウンロードサーバーなどの補助レベルです。
  • 最小レベルは6サーバーです。
  • たとえば、毎週火曜日のリリースは6台のサーバー（レベル1）に展開され、運用担当者のチームがこれらの6台のサーバーを監視し、次のレベルに展開する前に正しく動作することを確認します。
  • リリースに問題がある場合（エラーが発生するなど）、計算はキャンセルされます。 失敗したコミットを行ったスペシャリストは、エラーを修正するために呼び出されます。 その後、計算は最初から始まります。
  • したがって、リリースは何度もレベルを通過できます：1-2-3修正。 1に戻る。1-2-3-4-5-修正。 1に戻る。1-2-3-4-5-6-7-8-9。
  
  
• 運用チームは本当によく準備され、団結しており、彼らのビジネスを大事にしています。 サーバーメトリックは、エラー、負荷メトリック、およびメモリ使用量のレポートだけではありません。カスタムメトリックも含まれます。 たとえば、新しいリリースでFacebookを使用するユーザーの割合が変更された場合、運用チームはこれを数字で確認するため、リリースを停止して問題を見つけることができます。
• リリースの計算中、運用チームは、IRCに基づいたページングを使用します。これにより、注意が必要な場合、Facebook、電子メール、IRC、IM、SMSを介してエンジニアに情報を送信できます。 運用主義者のメッセージを無視することは、公共の「恥」につながります。
• コードがレベル9に変更され、安定するとすぐに、毎週のタブが完了したと見なされます。
• 機能が週単位の計算に間に合って開発されていない場合、これはそれほど重要ではありません（ハード外部依存関係が含まれていない場合）-機能は完了時に単純に完全に実装されます。
• svn-blammed苦情を受け取ったとき、公共の恥またはプロジェクトの遅延が多すぎると、専門家が解雇される可能性があります。 「これは非常に効果的な文化です。」 非生産的であるか、非常に才能のない人々は、本当に自分自身を危険にさらします。 マネージャーは、文字通り、採用後6か月以内に不採算になり、「うまくいきませんでした。あなたはこの文化に十分に適していない」と言います。 一般に、これは会社のどのレベルにも当てはまります。CレベルやVPレベルで雇われた人でさえ、非常に生産的でなければすぐに解雇されました。
• [訂正、thx epriest]「エラーを探すために人々は呼び出されません。 変更がリリースに含まれるように要求した場合にのみ呼び出されますが、何か問題が発生した場合に変更をサポートするためではありません（そして、置き換える人が見つからなかった場合）。
• [修正、thx epriest]「苦情のため、あなたは解雇されません（翻訳者注：私はsvn-blameを意味します）。 私たちはこの点で非常にconめています。そして、ほとんどの主要な専門家は私を含めて少なくとも一つの恐ろしいことを説明しました。 私の知る限り、この種の間違いを犯したことで解雇された人はいません。」
• [訂正、thx fryfrog]「この記事で引用されているエラーのために解雇される人も誰も知りません。 誤ってサイトをドロップした人を知っています。 彼らは問題の原因を修正するために懸命に働き、誰もがそれから学びます。 私の意見では、公共の恥は解雇される恐れよりもはるかに効果的です。」

Facebookの開発文化が時間とともにどのように進化するか、特に何千人もの従業員への会社の拡大に伴ってこの文化がどのように拡大し続けるかを見るのは非常に興味深いでしょう。
どう思いますか？ 「開発者主導の文化」はあなたの会社で機能しますか？

オリジナル記事

翻訳に誤りや誤りがある場合は、個人で書いてください、私は修正を行います。