エンコーダーが海外で何をどのように考えているかを知りたいと常に思っていましたか？ 技術的思考と基本的なプロセスはロシアの開発者に似ているべきだと仮定するのは論理的です。 カットの下で、私たちの旅行を「地元の旅行」と比較する機会。 英語でうまくやっているなら、オリジナルの出版物と著者自身は
ここで見つけることができ
ます 。
Webアプリケーション開発は、若くてほとんど研究されていない活動です。 コードを生成およびコンパイルするためのツールは広く利用可能であり、比較的長い間使用されており、常にプログラマーの手元にあります。 アイデアは（これがトレンドです）コマンドラインから起動される1つまたは2つのツールを使用し、作業の一部を実行する機能から開始することです。
Gitは、考えられるコードマージの問題を解決する方法を提供します。 また、任意の複雑な分岐およびタグ付けスキームのサポートがあります。 多くの人は、これらの機能を常に使用することが望ましいと考えています。
これは誤りです。 現在の作業のプロセスですでに有効になっている手順から開始し、開発中に行われたものとは反対の方向に進む必要があります。
ページングされたMVP（最小限の実行可能製品）を作成したとしても、最終的に、現在のビジネスで
は、ソフトウェアコストのほとんどは開発コストではなく運用コストです。
運用アクティビティの観点から、実際に非常にうまく機能する例を示します。コードは、実稼働環境で小さなフラグメント（コードの単位）でデプロイする必要があります。 このような断片のサイズは、数百行ではなく数十行で測定する必要があると思います。 このようなアプローチを基礎として、比較的単純な変更制御を実行するだけでよいことがわかります。
開発したコードのミスを回避する最後のチャンスは、実行する直前です。そのため、多くの開発チームは、標準の（現状の）コードレビュー（コードレビュー）を実施することをお勧めします。 これは間違いではありませんが、努力の効果は高くありません。
数百行のコードをチェックするのは大変な作業です。 作業時間とプロセスに没頭するための多大な投資が必要です。 通常、大きな変更の表示は「lgtm」ラベルを付けることで終わります（「これは悪いことではないと思います」）。 強力な開発文化を持つチームでさえ、コードチェックを行っており、スペースの魔女探しになります。
数百行のエラーをスキャンすることは、効率的で簡単なプロセスです。 すべての問題を防ぐわけではなく、新しい問題も作成しません。 このプロセスは、可能性と実用性の合理的なバランスを表しています。
修正された大きなフラグメントを展開すると、経験豊富な開発者でさえも恐ろしくなります。 そしてその理由は、単純な関係の本能的な理解です。
何らかの確率でコードのすべての行に、操作中にポップアップする検出されないエラーがあります。 コード実行のプロセスは、この確率の値に影響を与える可能性がありますが、ゼロに減らすことはできません。 変更された大きなフラグメントには多くの行が含まれているため、実際のデータと実際のトラフィックを使用すると、障害が発生する可能性が高くなります。 オンラインシステムでは、コードを転送してパフォーマンスを確認する必要があります。
本番環境のすべての問題を防ぐことができません。 とにかく発生します。 そして、小さな変更をプッシュしたときにそれが起こるようにします。
プロダクションの多くの重大なバグは
、展開時に明らかになります。 最大ページの新しいデータベースクエリにインデックスがない場合、ほとんどの場合、すぐに警告が表示されます。 エラーが最新バージョンのコードにあると想定するのは理にかなっています。
別のケースでは、しばらくの間存在していた小さなが有害な問題を排除します。 この問題を解決するために必要な重要な情報は、最初に発生したとき、およびその瞬間以降に行われた変更の分析で取得できます。
説明した両方のシナリオで、デバッガーは変更されたコードフラグメントを処理します。 そのようなフラグメントのエラーの検出はコード検証に似ていますが、強引に実行されるチェックはさらに悪いことです。 したがって、実稼働環境でのトラブルシューティングの期間は、変更するフラグメントのサイズに比例する傾向があります。
予防手段としてのコード検証の有効性は、人的要因を制限します。 リリースの問題は避けられず、リリースされるコードの量に比例します。 デバッグに必要な時間は、（特に）デバッグされるコード量の関数です。
以下は、道順の簡単なリストです。 しかし、それらを真剣に考えれば、興味深い結論を導き出すことができます。
•
コード分岐は不活性であり、これは悪いです。 支部で働くことを気にしない、それが彼らを助けるなら、そして彼らがそうすることを自信を持って言うことさえできないなら、人々に言います。 すべてのコードをマージしてデプロイするよりもブランチのサイズを2倍にする方が簡単であり、開発者は常にこのトラップに陥ります。
•
ソースコードの簡単な操作 -
これは正常です。 GitHubブランチは非常にPRですが、
git diff | gist -optdiffは、数十行のコード
に関してもうまく機能します。
•
精巧なgitリリースの儀式は必要ありません 。 リリースをタグ付けするようなセレモニーは、リリースを1日に何度もリリースすると時間の無駄に思えます。
•
あなたの本当の問題は、リリースの頻繁なリリースです 。 パブリケーションの頻度を同時に増やすことができる場合を除き、リリースされるコードの量を制限すると、進行が遅くなる可能性があります。 これを行うのはそれほど簡単ではありませんが、同時にツールの武器は、
この問題を解決するために研ぎ澄まされた資金に引き寄せられ始めます。
これは完全なリストではありません。 日常の運用アクティビティから始めて、反対方向、つまりコード開発の方向に進むと、開発プロセス全体を批判的に反映することができます。 そして、それは恩恵を受けるだけです。