人生は終わりますが、プログラムは死ぬ必要はありません。
プログラムの書き方に関する一連のツイートの後、このトピックについて詳しく説明するように頼まれました。 7つのルールすべてを明確に守ることができるプロジェクトはめったにありません。 私自身はしばしば成功しません。 しかし、従うルールが多ければ多いほど、プログラムの寿命は長くなります。 各シンボルは、エコシステム全体に何かを追加します。エンジニアとしての私たちの仕事は、エコシステムをきれいに整頓することです。
良いコードを発行すると何が得られますか？ 学習への人生の権利アプローチは、「より速く移動し、あなたの道のすべてを壊す」と呼ばれていませんか？いいえ。 コードを書くことを学ぶことはスキルであり、誰でも利用できます。 良いコードを書くことを学ぶことは芸術です。 努力、時間、決意が必要です。
死後、さらに多くのSEGFAULTを世界に送りたいですか？ システム管理者に、コードのせいで壊れるシステムを修正してもらいたいですか？ あなたのプロジェクトマネージャーは、あなたの仕事がユーザーを激怒させたエンジニアとしてあなたを覚えているでしょうか？
すぐに前進しても何も問題はありませんが、ある時点で、低品質のコードがあなたを遠くに連れて行かないことを認識する必要があります。
あなたが医者に行くとき、彼はあなたに何が起こったかを理解するために最初にあなたに多くの質問をします。 彼は診断を下す前に薬を処方しません。 同様に、コードに何か問題があるかどうかを把握することも重要です。
1.ローリング更新には多くの時間と労力がかかりますか？
2.小さな更新でもシステムはクラッシュしますか？
3.プロダクション用に壊れたコードを展開したことがありますか。これはユーザーからの苦情の後でのみ知られるようになりましたか？
4.システムがクラッシュしたときに何をする必要があるか正確に知っていますか？ バックアップを取得してそれらから回復する方法は？
5.プログラム自体を書くよりも、環境の変更、同じコマンドの再実行、いくつかのユーティリティの実行により多くの時間を費やしていますか？
はいと答えた場合、この記事はあなたのためです。 読むが、むしろ二度読む。
1.モジュールに分割する
人間の脳は複雑なデバイスであり、 どのプロセッサよりも複雑ですが 、複雑な問題の解決には対応していません。 すぐに13 * 35を掛けることは難しいとしましょう。 しかし、これらの操作を単純な操作、35 * 10 + 30 * 3 + 5 * 3 = 455に分割すると、計算は単純化されます。 タスクを単純で独立したものに分割して、答えを見つけます。
だから、プログラムです。 プログラムをいくつかの部分、ファイル、ディレクトリに分割します。 プロジェクト。 すべての依存関係を1か所に出力し、MVC原則またはそのバリアントを使用します。 このようなコードは読みやすく、デバッグも簡単です。 ほとんどの場合、デバッグは数千行のファイルではなく、数行のコードにつながります。 1つのモジュールの更新をローリングしても、システムの残りの部分は破損しません。
2.テスト
ふ、テスト。 Brrrrrr！
テストはプログラミングの一部ではないと教えられてきたため、このような反応は自然です。 C ++でパターンを学習しますが、テスト方法は学習しません。 これが問題です。 一部の人は、テストがプログラム自体の前に上書きされていると信じています。
テストを書いても、テストを書いても構いません。 英雄的である必要はありません。簡単なものから始めて（print（add（1、1）== 2））、次に言語のテストフレームワークに進みます。
次に、プログラムの複雑さを理解し始め、モジュールに分割することを学びます。モジュールは個別にテストできます。 テストを使用すると、7つのルールのうち2つをすでに満たしていることがわかります。
3.継続的な統合
テストは、さまざまな環境（たとえば、Pythonのさまざまなバージョン）で正常に完了する必要があります。 また、各変更後にテストを実行する必要があります。 コマンドラインから手動で行う代わりに、継続的統合のためのプラットフォームを作成する方が便利で高速です。
継続的インテグレーション （NI）は、コードを1日に数回リポジトリに統合する開発手法です。 毎回自動的にチェックされるため、問題を早期に追跡できます。
私のプロジェクトでは、 TravisCIとDrone.ioを使用しています。 コードに新しい追加を行うと、プラットフォームがテストをビルドして実行します。
4.自動化
大規模なプロジェクトには、常に多数のマイナーなサポートタスクがあります。 一部の人々は、チームでテキストを作成し、そこからコピーします。 しかし、 bashスクリプト （および/またはPython）を学ぶ方が簡単です。 スクリプトを使用して自動化する必要があるタスクを次に示します。
-README.mdを他の形式に変換する
-自動テスト（テストサーバーとデータの作成、一時ファイルの削除などを含む）
-開発サーバーへのコードのアップロード
-本番環境でのプログラムの配置
-依存関係の自動更新
5.冗長性
git-scm.comで最初に表示されるもの：
Gitは、小規模プロジェクトと非常に大規模なプロジェクトの両方で、高速かつ効率的に動作するように設計された無料の分散オープンソースバージョン管理システムです。
分散。 これはキーワードです。 githubでのみホストしている場合は、自分でピンチしてください。 それは単一障害点だからです。 プッシュ操作中にgithubがクラッシュしたり、ファイルを破損した場合、開発プロセスは停止します。
Bitbucketにログインし、リポジトリで次の操作を実行します。
# rename origin remote git remote rename origin github # add the gitlab remote (for the love of everything that's holy, use ssh) git remote add bitbucket <remote link for bitbucket> # push existing code to new remote git push -u bitbucket —all # let's magic git config -e # add this in the file [remote “origin”] url = git@github.com:username/reponame.git url = <remote link for bitbucket>
これで、コードをアップロードすると、GithubとBitbucketの両方で変更が行われます。 いつ壊れるかわからない。 また、バックアップがあると便利です。 これが私にとってどのように機能するかです：
-すべてのコードはDropboxのCodebaseディレクトリにあります。 自動同期。
-ほとんどすべてのコードはGithubにあります
-最も重要なコードは2つのプライベートミラーに存在します-1つは学校、もう1つはAWSにあります
世界が終わった場合にのみ、コードを失います。
6コミット
これはおなじみのはずです。 ストーリーを見てみると、次のようなものが表示されます。
「モジュールのバグを修正」
本当に？！？！
修正した？ 間違いは何ですか？ どのモジュールで？
多くの人は、バージョン管理システムをバックアップと見なし、履歴を保持する方法とは見なしていません。 そのようなメッセージの話は役に立たない。 このコミットの1週間後に、プロジェクトに新しいバグが導入されたため、何かを返すことにしたとします。 ただし、アクションの説明がないため、すべての変更を表示する必要があります。 これを防ぐために、バージョン管理システムが作成されました。
負担をかけないように、次のクラッチを使用します。
-各コミットには意味があります。 バグ修正、新しい機能の追加、既存の削除？
-コミットごとに1つの変更のみ
-コミットメッセージに問題番号を含める
-変更の説明を含めます。 現在のプロジェクトのルールに依存しますが、通常、エラーの原因、修正方法、テスト方法について言及します。
-意味のあるメッセージを書く：
リンクを収集しやすくするために、ヘッダーに新しいフォームを追加しました。 クローズド＃3
の代わりに
すべてを削除しました。
7.計画
以前のすべてのルールに従い、プログラミングの神のように感じても、とにかく何かが起こる可能性があります。 最悪の場合の計画を立ててください。 トラフィックが記録を破った場合はどうなりますか？ システムがクラッシュした場合、どこからバックアップを取得しますか？ サーバーが故障した場合、誰が夜に電話する必要がありますか？
考え直しますが、無理をしないでください。 可能なすべてを自動化します。 次に、すべてを詳細に文書化します。 あなたのコードを受け取った人も計画に従うことができるように。 計画を立てることは、よりスマートに見えることを意味するだけでなく、本当にスマートになることも意味します。
これらは、良いプログラムを決定するルールです。 納得していない場合は、2つの質問に答えてください。
1.初心者が既存のコードを簡単に理解できるようになると期待していますか？
2.コードのリファクタリングは簡単かつ迅速ですか？
そうでない場合は、再度読み直してください。 保存して、チームと共有します。
これらのルールは、最初は明白に見えるかもしれません。 そうです。 不正なコードは常に作成されており、最終的には死にます。 あなたのプログラムはあなたの遺産です。 どのくらい続くかを自分で決めてください。
幸せなプログラミング。