高品質のコードをどのように宣伝および奨励できますか？
私は4人のチームで小さなアウトソーシング会社のiOS開発者として働いています。私は、私と他の2人の開発者が入社する数年前に始まったプロジェクトに取り組んでいます。それ以前は、プロジェクトは主に一人で行われていました。
私がプロジェクトに取り組み始めたとき、それは完全な混乱でした。コードの繰り返しがたくさんありました。同じ500個のコードが20個の異なるファイルに対応していて、わずかな違いがあります。さらに、それは正確に整理されていませんでした：すべてのUI作成コードは、ロジックと共にビューコントローラーに混在しています。
あちこちでリファクタリングしたり、冗長なコードを削除したり、プロジェクトのファイル構造を改善したりするために、最善を尽くしました。以前の開発者はこれらすべてのことをあまり気にしていない、または経験がないように感じました。私が2、3か月間、かなり大きな機能について一人で作業していた時期がありました。この機能の性質上、アプリ全体で多くのコードに触れる必要があったため、いくつかの改善を試みました。
他の開発者がプロジェクトに参加したとき、私は彼らが異なるコーディングスタイル（時には完全に異なるスタイル）を使用し、プロパティアクセサーのような現代の言語機能を使用しないことに気づきました（これはObjective-の比較的新しいものです） C）。フレームワークの同様の機能を使用する代わりに独自の自転車を発明したり、他のプログラミング言語や概念をコードベースに転送したりすることもありました。悪い英語のために、メソッドや変数に適切に名前を付けることができないことがよくあります（Objective-Cは長い名前を付ける言語です）。
IDEがそうでなければ、インデントやフォーマットをまったく付けずにすべてのコードを書くと思います。
基本的に、私は彼らが書いたコードが嫌いです。フォーマットや構成が不適切で、プロジェクトの他の部分と根本的に異なる場合があります。彼らがスパゲッティを私の作品に加えると、非常に動揺します。それは私の仕事の気分や私の生産性に影響を与えます。
それは、彼らが学ぶことや気にしないことに煩わされることができないようにますます感じています：彼らは彼らから必要とされることをして家に帰るだけです。私は機会があったときにいくつかのヒントをあげようとしました（たとえば、彼らのPRにコメントしたり、GitHubでコミットしたりしました）。私はかつて、既存のコードの大部分のコーディングスタイルとフォーマットに従うことをうまく依頼しました（残念ながら、正式なコーディングスタイルドキュメントはありません）。しかし、それはうまくいきませんでした...
「悪い企業文化」や「経験の浅い卒業生」などに焦点を当てずにこの状況にどう対処し、実際に状況を改善し始めることができますか。
あなたが説教していることを教え、実践してください。
このことは重要です。あなたはそれが正しく行われないときの欠点を知っています。
今、課題は他人を説得することです。これは、単一の会話、会議、廊下の会話、ヒント、またはプルリクエスト内では行われません。
これには以下が必要です：
- これらの項目が重要であることを経営者が公に認める
- リンターは、人々が集まり、ハッシュ化し、スタイルに同意して、コンピューターにポリシングを行わせるようにします
- 完全に賛同し、他の人に教える意思がある開発者をリードする
- これらのアプローチを教えるための会議、デモ、昼食、学習など
- レビューで言及した品質アイテムで評価されている人々
- 文書化および公開された標準
- 多くのレビュアーがいるプルリクエスト
- コード品質が高くなるまでプルリクエストがマージされない
- 頻繁なコードのペアリング
- 複雑なPRのグループコードレビュー
Wordではそれが必要です
リーダーシップ
良い知らせは、これらすべての活動は一般に優れた慣行として認識されているため、それらを宣伝したり、経営陣から賛同を得たりするときは、成功の可能性が高く、正しいことを守ることができるはずです。しかし、経営陣はまだ買収しないかもしれませんが、それは別のトピックと質問です。
私は過去にSoftwareEngineering.SEでこの問題について多くのことを書いており、私自身も同様の状況でした。したがって、私はいくつかのヒントを与え、あなたの質問を読んだときに指摘したいくつかの問題を強調するようにします。
しかし、最初に、重要な側面について話しましょう。会社でのあなたの役割です。
あなたの役割
あなたは上司から物事を強化するための明示的な権限を持っているかもしれませんし、他の開発者があなたのordersを聞く必要がある階層内の場所も持っているかもしれません。または、あなたは同じ役割と同じ権限を持っている仲間の中にいるかもしれません、あなたの選択肢は...だけです...まあ... opinion。
どちらの場合も、重要なのは階層内での場所ではなく、次のとおりです。
他の開発者があなたをどう思うか。彼らがあなたを彼らに愚かなことを尋ねる迷惑な男として扱うならば、あなたは遠くに行きません。技術リーダーやプロジェクトマネージャーがチームにまったく影響を与えなかった多くのケースを見てきました。チームがそれらの「リーダー」には、彼らが行っている決定を行うために必要な技術的背景がないことを知っていた（または考えた）ためです。一方、実際に他の開発者が熟練していて経験豊富であることを知っているため、実際に仲間から聞いている開発者が何人かいます。
あなたのチームはどれほどしっかりしていて、彼らを動機づけているのかすべての開発者に毎月KLOCが支払われる会社を想像してみてください。同僚にとって、スタイルについて何か言えることはありますか？たぶんそうではありません。少ない給料で支払いたい人はまれだからです。一般に、これがチームではなく、同じプロジェクトに取り組んでいるグループだけの場合、何も改善することはできません。
それによっては、変更を加える価値があるかどうかを判断できます。声がなく、チームの結束がない場合は、別の仕事を探してください。才能のある尊敬される開発者として知られ、強いチーム感がある場合は、上司や他のチームからの敵意に直面しても、比較的簡単に改善することができます。
すべての場合において、チームに圧力をかけないことが不可欠です。動作withそれらではなく、againstそれらではありません。それらに命令を与えないでください、しかし彼らをゴールに向かって導きます。
さて、ヒント。
スタイル
私はかつて、既存のコードの大部分のコーディングスタイルとフォーマットに従うことをうまく依頼しました（残念ながら、正式なコーディングスタイルドキュメントはありません）。しかし、それはうまくいきませんでした...
もちろんそうではありませんでした。なぜなら、これは本来あるべきやり方ではないからです。
スタイルはboringです。
次のスタイルはboringです。
コーディングスタイルドキュメントの記述はboring（ そして、とんでもなく難しい ; 10年以上この言語を使用していない限り、実行しないでください）。
読み取りスタイルドキュメントはboringです。
スタイルの間違いについてコードを確認するのはboringです。
私のスタイルがあなたのスタイルよりも優れているとトローリングするのはエキサイティングで、特に、あるスタイルが他のスタイルよりも客観的な利点がない場合は特にそうです。真剣に、すべての正気な人は、
if (x)またはif(x)ではなく、if ( x )を書く正しい方法が私が書いた方法であることを知っています！
したがって：
スタイルのレビューをしないでください。これがスタイルチェッカーの仕事です。これらのかわいいアプリケーションには、頭脳に比べていくつかの利点があります。プロジェクト全体を数時間または数日ではなく数ミリ秒でチェックし、間違いを犯したり、スタイルエラーを見逃したりしません。
独自のスタイル標準を作成しないでください。とにかくあなたはそれを間違って行うでしょう、そしてあなたの同僚はあなたが悪い選択をしたことをあなたを荒らします。
開発者に2000スタイルのエラーの修正を強制しないでください。
コミット時にスタイルを自動的に適用します。スタイルに誤りがあるコードは、バージョン管理の対象にはなりません。
プロジェクトの最初からそれを行います。 既存のプロジェクトでスタイルコントロールを設定するのは困難から不可能です。
詳細については、 SE.SEに関する他の回答 の最初のセクションを参照してください。
また：
- 厳しすぎないでください。たとえば、
jslint準拠のコードの記述は非常に煩わしいので、絶対に必要な場合（またはチームのすべてのメンバーがそれを使用して満足している場合）にのみ行う必要があります。静的チェックツールについても同様です。たとえば、最大レベルでの.NETのコード分析は非常に抑圧的で憂鬱なものになる可能性がありますが、メリットはほとんどありません。一方、中程度のレベルの同じツールセットは非常に役立ちます。
コードレビュー
コードのレビュー時にスタイルを気にする必要がないので、ソースコードの拡張（修正）より興味深いことに集中できます。
コードレビューに対する反応は人によって異なります。それを機会と考える人もいます。他の人はそれを嫌います。たとえ彼らが正しいとしても、あなたが彼らに話すすべてを聞いて、メモを取り、議論しない人もいます。他の人たちはあらゆる点で議論しようとします。彼女の個性に応じてすべての開発者に対処する方法を見つけるのはあなた次第です。通常、次のことが役立ちます。
特に開発者がジュニアで、本当に悪いコードを書いているときは、コードレビューを秘密にしてください。
個人的なことは何もないことを示す：あなたはその人のスキルではなく、コードをレビューしています。
コードレビューの実際の目標を示します。目標は、開発者の悪さを示すことではありません。目標は、改善の機会を提供することです。
決して議論しないでください。あなたは説得するためではなく、専門知識を提供するためにここにいます。
レビューから何かを学ぶことができるのはレビュー対象者だけであると想定しないでください。コードを読んだり、理解できない部分について説明を求めたりすることで、ここでも学習できます。
コードレビューが完了したら、その人が実際にコードを改善していることを確認します。開発者が実際の会議が終了するとコードレビューが終了すると思ったケースがいくつかありました。彼らは去って新しい機能に戻り、あなたが共有したものを新しいコードにのみ適用しようとします。コードレビューのためのまともな追跡ツールがあると役立ちます。
会社での特定の役割や他の人と比較した専門知識に関係なく、コードもレビューの対象となる必要があることに注意してください。他人のコードをレビューするのはあなただけではありません。
私がテクニカルリーダーとして働いていた最近のプロジェクトで、私の同僚を含めて、お互いのコードのレビューを行うことが彼らの役割であることを同僚に説明するのに苦労しました。テクニカルリーダーのコードをレビューしようとしているインターンの恐れは、コードの最初の問題を見つけるとすぐに消えます。そして、誰が完璧なコードを書いているのでしょうか。
トレーニング
コードレビューは、プログラミングとソフトウェア設計のいくつかの側面を教えて学ぶ絶好の機会ですが、他の人はトレーニングを必要とします。
同僚を訓練することができるなら、それをしてください。経営陣がトレーニングの考えに敵対している場合は、非公式に行います。私はそのようなトレーニングセッションを非公式の会合の形で、または時には簡単な議論として、経営陣によって中断され、後で追跡されることもありました。
直接のトレーニングとは別に、McConnelのCode Completeなどの本を十分に理解していることを確認し、それらの本について同僚に説明してください。オープンソースプロジェクトのソースコードを読んでもらい、高品質のコードの具体的な例を挙げてもらいます。そして、明らかに、高品質のコードを自分で作成します。
人ではなく状況に焦点を当てる
「悪い企業文化」や「経験の浅い卒業生」などに焦点を当てずに、この状況にどう対処すればよいでしょうか。
それらの卒業生は目標を持っています：経験を積むこと、何かを学ぶこと、より熟練すること。毎年、彼らがくだらないコードを書き、プログラミングについて何も知らない場合、それはおそらくあなたのチームまたはあなたの会社が彼らにこの機会を与えていないためです。
チームに経験の浅い卒業生がいるという事実に焦点を合わせている場合、これは役に立ちません。代わりに、あなたが彼らのためにそして彼らと一緒に何ができるかに焦点を当てます。コードレビューとトレーニングは、状況を改善するための2つの手法です。
悪い企業文化は別の獣です。時々、それは変更することができます。時々、それはできません。すべての場合において、あなたはareこの会社の一部であり、会社の文化の一部であることに注意してください。あなたがそれを変更できず、遅かれ早かれそれが本質的に悪いことに気づいたら、あなたは去らなければならないでしょう。
正しい指標を取得する
現在、どの程度正確にコードを測定していますか？開発者ごとの1日あたりのコミット数を測定しますか？または、プログラマあたり月額KLOC？それともコードカバレッジ？または、見つかって修正されたバグの数は？または、回帰テストで検出された潜在的なバグの数は？または、継続的展開サーバーによって行われた復帰の数？
チームメンバーは測定された要素に作業を適応させているため、測定するものは重要です。例えば、私が数年前に働かなければならなかったある会社で、測定された唯一のものは、オフィスで過ごす時間でした。言うまでもありませんが、これはより良いコードを提供したり、よりスマートに動作したり、あるいは...まったく動作したりすることを奨励するものではありませんでした。
ポジティブおよびネガティブな補強を見つけ出し、測定された要素を長期にわたって調整することは、基本的にはチームメンバーに対するレバレッジです。適切に実行すると、単純な階層では達成できない結果を達成できます。
あなたを悩ませるものは、それらを測定可能にします。それらを測定し、結果を公開します。次に、他のチームメンバーと協力して結果を改善します。
たとえば、チームメンバーがクラス、クラスメンバー、変数の名前のスペルミスを多すぎると考えてみましょう。これは迷惑です。それをどのように測定できますか？パーサーを使用すると、コードからすべての単語を抽出し、スペルチェッカーを使用して、間違いやタイプミスを含む単語の比率（16.7％など）を特定できます。
次のステップは、目標比率についてチームと合意することです。次のスプリントでは15％、次のスプリントでは10％、6週間で5％、2か月で0％になる可能性があります。これらのメトリックはコミットごとに自動的に再計算され、オフィスの大画面に表示されます。
目標の比率を達成できない場合、チームはスペルミスの修正にさらに時間を費やすことを決定する場合があります。または、開発者ごとの比率を計算し、この情報を大画面に表示することをチームが検討するとよいでしょう。または、チームは目標が楽観的すぎると感じ、それを確認する必要がある場合があります。
目標の比率を達成したら、次のステップは、間違いやタイプミスが時間の経過とともに増加しないことを確認することです。そのために、スペルミスをチェックし、少なくとも1つのミスが見つかった場合にビルドを失敗させる追加のタスクをビルドに作成できます。この問題を解消したので、大画面を再利用して、新しい関連統計を表示できます。
結論
私はあなたの質問で言及されたすべての側面は、私が私の回答に含めたテクニックを通じて解決できると信じています：
他の開発者がプロジェクトに参加したとき、私は彼らが異なるコーディングスタイル（時には完全に異なるスタイル）を使用していることに気付きました
コミット時にstyleを自動的に適用する必要がありました。
プロパティアクセサーなどの最新の言語機能を使用しないことがよくあります（これはObjective-Cでは比較的新しい機能です）。
コードレビューとトレーニングの両方が、言語の知識を伝えるためにここにあります。
フレームワークの同様の機能を使用する代わりに、自分の自転車を発明することもある
コードレビューとトレーニングの両方が、フレームワークの知識を伝えるためにここにあります。
または、他のプログラミング言語または彼らが学んだパターンからの概念をコードベースに転送します。
これは素晴らしいことです。あなたは彼らから学ぶ機会のようです。
悪い英語のために、メソッドや変数に適切に名前を付けることができないことがよくあります
コードレビューも適切な命名に焦点を当てるべきです。一部のIDEにはスペルチェッカーもあります。
IDEがそうでなければ、インデントやフォーマットをまったく付けずにすべてのコードを書くと思います。
もちろんそうです。 Styleは退屈で自動化する必要があります。
基本的に、私は彼らが書いたコードが嫌いです。
コードレビューの部分を思い出してください。「目標は、開発者がどれほどひどいかを示すことではありません。目標は、改善の機会を提供することです。」
フォーマットや構成が不適切で、プロジェクトの他の部分と根本的に異なる場合があります。
自動スタイルチェック。
彼らがスパゲッティを私の作品に加えるとき、私は非常に動揺しています
待って、何？！作品ですか？！何だと思いますか？一部の人（6か月後のあなたを含む）は、あなたのコードを芸術品とは程遠いものと感じるかもしれません。その間、あなたの作品をアートとして、そしてtheirとしての作品をがらくたとして考えても誰も助けにはならないことを理解してください。あなたを含みます。
それは、彼らが学ぶことや気にしないことに煩わされることができないようにますます感じています：彼らは彼らから必要とされることをして家に帰るだけです。
もちろん、彼らは彼らに必要なことをします。覚えておいてください：人ではなくコンテキストとメトリックを正しく取得。コンテキストが、彼らがすることで最高になることを彼らから要求するならば、彼らはそれをします。コンテキストが1か月あたり可能な限り多くのKLOCを生成する必要がある場合は、それも行います。
あなたの質問は「あなたの会社を変えるかあなたの会社を変える」で答えられます。知らない人のために、これはあなたが会社に見たい変化をもたらすためにとどまり、戦うこと、またはあなたが働いている会社を変えることを意味します（すなわち、離れて他の場所で働く）。
2番目の部分は最も単純です。あなたは去って、あなたが働いている同じ価値観を共有する会社を見つけます。最初のことは、人々のためにそれほど単純ではありません。
あなたがする必要があるのは人を変えることです。それらが壊れていて、修正する必要があると思ってもうまくいきません。人々は感情的な存在です。これは個人的な戦争で簡単に退化する可能性があります。そう...
まず第一に、あなたは状況が現状のままである理由を見つける必要があります。みんなと話してください。探し出す。現在表示されているのは、何年にもわたって行われた決定の結果です（または適切なタイミングでいくつかの重要な決定を行わなかった可能性があります）。判断せず、結論にジャンプしないでください。
これは経験の浅い開発者が原因ですか？それは、経験豊富で高価な開発者ではなく、安い卒業生を雇ってコストを削減しようとする経営者が原因でしたか？これは、怠惰で悪意のある人々、または壊れたシステムによって打ち負かされた人々についてですか？それを機能させるために「何をしなければならないか」を行うように迫られている締め切りですか、それとも人々は単に時間を浪費していて、彼らが取り組んでいることをあまり気にしていないのですか？等.
このソフトウェア開発分野の問題は、人々が仕事で学ぶことです。彼らが安っぽい環境で働くなら、彼らは悪い習慣を身につけるでしょう。また、癖がつきやすく、揺れにくい。それから彼らはそれが彼らが知っているすべてであるので彼らはよりよく知りません。すべての開発者が、時間をかけて改善したり、改善を求めたりするために何をすべきかについて情熱を持っているわけではありません。他のさまざまな理由でこのビジネスに参加した人もいます。だから人々は彼らがどのようにあるのか理由を見つけてください。
次に管理があります。経営者は状況を認識していないのですか、それとも気にしていないのですか？探し出す。物事を改善したいのなら、絶対に経営陣のサポートが必要です。テストの作成、コードレビューの実施、チームとのホワイトボードでの適切なソリューションやペアプログラムの決定などについて話し合う必要があるため、突然構築に3か月かかった何かが4か月かかり始めた場合、経営陣が時差に気づくようにしてください。 3か月から4か月に変化するものは、簡単に観察および測定できます。強固なコードベース、保守可能な製品、優れた安定したアーキテクチャーを備えているため、より良い製品構造を実現するものは測定がそれほど簡単ではありません。ベストプラクティスが長期的にどれだけの時間を費やすかは、事前に測定することはできません。一方、1か月の遅延は簡単です。ですから、これについて管理サポートを受けてください。ハードセールをする準備をしなさい。
また、ビジネスのコンテキストを見てください。これはあなたの働き方に影響していますか？コードの品質やベストプラクティスを犠牲にするなど、何らかのコストで従わなければならない機会はありますか？
ちょっと視点を変えましょう。
彼らがスパゲッティを私の作品に加えると、非常に動揺します。それは私の仕事の気分や私の生産性に影響を与えます。
すみません...あなたの何？アート？私たちのほとんどが仲間からの評価のためにここにいることを知っています。あなたが良い開発者である場合にのみそれを得ることができますが、あなたのコードは絵画の隣の美術館に表示されていますか？それを見る人々に感情を引き起こさなければならないのでしょうか？喜びと至福の涙？はい、私は皮肉で、現実感を保つために言いたいので、意図的に誇張しています。コードに感情的に執着しないでください。
私はいつも、チームに、プロジェクトに、そして会社にバスの下に放り込んで、彼の「芸術」を皆に課すような男と一緒に働いていました。彼は「真実の保有者」であり、そして定義により、誰もが単に経験の浅い、盲目、学びたくない、気にしない、または単に愚かでした。その男にならないでください。ソフトウェア開発者としてのあなたの仕事は、優れたコード、テスト済みのコード、保守可能なコード、ビジネス価値を追加するコードを書くことであり、絶え間ない将来の変化の下でもそれを続けることができます。そして、すべてを予算と時間の制約の下で行わなければなりません。それがプロのソフトウェア開発者であることの意味です。あなたがアートギャラリーでない限り、アートはビジネスに悪いです。実用的であり、物事についてバランスのとれた見方を保つ。 " 私の同僚が書いた悪いコードを無視して、仕事に集中する方法 "は、問題のフレームを作成する方法のために、質問を閉じました。戻って全体を見てください。
「悪い企業文化」や「経験の浅い卒業生」などに焦点を当てずにこの状況にどう対処し、実際に状況を改善し始めることができますか。
TL; DR：状況を注意深く見て、事態がその状況になった理由を見つけてください。状況がそのようなものであることを受け入れ、そこからどのように改善できるかを確認してください。これについての皆の意見が何であるかを調べてください。あなたの戦いを選んでください。強制的な変更は機能しません。協力して変更を加えます。あなたは物事がいかに悪いかを指摘するのではなく、物事がどのように改善できるかを示すように努めるべきです。あなたがしたいことは長期的にはもっと良いことのためだと皆に納得させる。船に乗せてください。
そして、小さなステップでそれを行います。
あまりにも多くの変化を一度にもたらすと、人々は落胆し、あきらめるでしょう。変更には時間がかかります。あなたの会社を変えるか、あなたの会社を変えてください。幸運を！
コーディング標準を実装し、それらに固執する、設計パターン、ガイドラインとして使用できるコードスニペットライブラリなど。
コーディング基準は、スペースとタブのどちらを使用するか、どのデザインパターンを使用するか、命名規則などを決定することからさまざまです。これは、誰もが異なる方法でコーディングしても、長い道のりになります。
可能な場合は、コーディング標準とコードレビューを実装して、すべてのチェックインのレビューを開始します。小規模なチームでは、コードを前もって2倍または3倍費やすことで全体の開発時間を20倍または30倍節約できることを理解していない人にとっては難しい販売ですが、それは購入する価値があるもう1つのコンセプトです。で。
私は一度にすべてを実装しようとはせず、インデントだけでなく、標準を考え出せるように最善を尽くします。インデントだけでなく、コードで遭遇したことについて考えさせます彼らの生活をより簡単またはより困難にしました。
週に1度会議を開いて、その週に各人が何が良かったか、または何が悪かったかを確認することを検討してください。その週に、他の人がその週に最も役に立ったことを他の人がしたことを話す機会を提供することもできます。 。このようなアイデアについては、XP /アジャイルの本をご覧ください。少人数のチームであることは、これも大変なことです。
言語の問題について言及しました。これらの労働者がローカル（現場請負業者またはフルタイム採用のいずれか）である場合、それはそれほど大きな問題ではないはずですが、彼らがリモートで作業する海外請負業者である場合-私の個人的な経験ではこれは決してありません修正される場合は、経営陣が機能しないことが判明するまでそれを実行するか、会社を辞めることを検討してください。あなたが彼らの仕事に責任がある状況に陥らないでください、そして、チームの開発慣行を修正しようとする時間を無駄にしないでください。ほとんどの場合、あなたの仕事は進化して、コードを機能させるために100％の時間を費やすことになります。海外の請負業者の多くは素晴らしいプログラマーです。ちなみに、請負会社からあなたが説明した種類の才能をあなたに送ったケースについてのみ言及しています。
あなたが説明する症状は、team cohesionの欠如を強く示唆しています。
そのような状況では、コーディング標準、トレーニング、手順、またはツールは、品質を大幅に向上させることができる特効薬にはなりません。まず、チームスピリット、オープンで建設的なコミュニケーション、製品の共有所有権を開発する必要があります。
症状：
- 「彼らはただ必要なことをして家に帰る」：彼らがやる気を起こさせる音。彼らが到着したとき、彼らはもっと熱狂的でしたか？
- 「私たち」/「私」/「私」に対する「彼ら」：相互信頼の欠如？
- 「いくつかのヒントを挙げました：GitのPRにコメントしました」：建設的な意図にもかかわらず、批評の口調は攻撃的または傲慢であると誤解されることがあります。対面で話し合ってみませんか？
あなたは小さなチームです：この利点を利用してください！開始するいくつかのアイデア：
- 重要な決定をまとめて行います。意見の相違について公然と話し合う。 「ディスカッション」は、1つの視点を課すことではなく、共通の根拠を聞いて見つけようとすることです。
- あなたはコードの重要な部分をリファクタリングしたので、あなたは本当に強い所有権を持っています。彼らに買収を任せましょう。
- また、コードのフォーマットなどの非常にデリケートでありながら非常に主観的なトピックについては、標準に従って再フォーマットし、各チェックインを感じることなく再フォーマットする自動化されたプリティプリンターに義務を委託します。
今日の名言：
早く行きたいなら一人で行きなさい。遠くに行きたいなら一緒に行きましょう