5

この質問への答えは、jira や fogbugz のような標準的なバグ追跡ソフトウェアである可能性がありますが、誰かが私が説明しているより良いシステムを知っていることを願っています。

私の最近のプロジェクトでは、実際にコーディング セクションを開始できるようになるまでに、多くの奇抜なセットアップが必要です。例えば:

  • SSH を開始する前に、一連の複雑な社内コマンドを実行します。
  • 外部呼び出しを行うサードパーティのクラスに社内プロキシ オプションが設定されていることを確認する - また、これらの設定が本番環境にインストールされたときに設定されないようにする
  • pear パッケージをインストールする前に、プロキシが設定されていることを確認します。
  • その他の同様のことで、主に内部の IT セキュリティに関係し、モジュールやパッケージで動作するようにします。

個人的には、これらのことのどれも大したことではありません。私が行った正確なコマンドと追加について、自分自身に広範なメモを書きましたが、現在、それらは一般的なテキスト ドキュメントにあり、どこで何が行われたかを正確に思い出すのは難しいでしょう。私が必要としているのは、はるか先のことです。また、すぐに新しいスタッフが何人か入りますが、プログラミング環境のセットアップをより簡単に行えるようにしています。

私が言ったように、それらは正確には「プログラミングの癖」ではなく、プログラミングが本格的に始まる前に起こる絶え間ないいじりです。私自身と将来の世代の正気のために、これらのことを文書化する最善の方法について何か考えはありますか?

4

4 に答える 4

7

このような指示をホストするためにウィキを使用します。情報にアクセスするための共通の場所を誰もが簡単に知ってもらい、手順で状況が変わった場合に情報を最新の状態に保つことができます。

自動化できる部分がある場合、それは良い考えですが、誰かが繰り返さなければならない非標準のセットアップが必要な場合は、開発環境のセットアップ用のページを常に作成します。

于 2010-05-01T02:56:34.933 に答える
6

これらの各タスクをある種のスクリプト (bash、python、applescript、autohotkey など、タスクに適したもの) にカプセル化します。

次に、それらを呼び出すためのさまざまなメタスクリプトを作成します。例: "set_up_everything.bash"。

要するに、やるべきことをすべて書き留めるのに時間を費やすのではなく、やらなければならないことをすべて実行するスクリプト/プログラムを書くことに時間を費やしてください。

スクリプトがきれいに書かれていれば、(他のプログラムと同様に) ドキュメントの究極の形にもなります。

編集:

あなたの質問を読み直すと、これは新しいチームメンバーが最新の状態になるのを支援することについてのあなたのポイントにも強く対処しています:彼らにスクリプトを実行させてください! また、(環境の違いなどにより) スクリプトが機能しない場合でも、実行する必要があるアクションとコマンドを正確に順を追って説明しています。

于 2010-05-01T00:01:16.683 に答える
2

これを自動化するスクリプトを作成します。これに費やした時間は、何度でも元が取れます。日々の時間を節約し、新しい開発者を参加させる時間を節約できます。

これらのツールのコードベースとは別の「bin」プロジェクトが必要になる場合があります。簡単なタスクから始めて、すべてのピースを埋めていきます。SSH は、適切なトークン ペアを使用して安全にスクリプト化できます。カピストラーノやシェフなどのツールは非常に人気があります。このアプローチは、一度に 1 つの小さなピースを処理することであり、目標 (おそらく達成できないかもしれませんが) は完全な自動化です。

数年前、これはクレイジーな話のように聞こえたでしょう。しかし最近では、すべてのプロジェクトをいじることなくチェックアウトして実行することができます。(副作用は、継続的インテグレーションのセットアップが簡単なことです。) AWS からサーバーをプロビジョニングし、インストールと OS、必要なすべてのツール、github からアプリをチェックアウトしてデプロイする単一のボタンを持つことさえ可能です。先日やったばかりです!信仰を持っている!

于 2010-05-06T06:42:18.427 に答える
1

プランA:制御可能な適切なテスト環境を設定することにより、外部システムへの依存を排除​​します。これには、ダミーデータベース、モックSOAPサーバー(SoapUI Mockservices)などのセットアップが含まれる場合があります。これらのモック/ダミー/スタブサービスで制御できるすべての外部をブラックボックスとして扱うことができるようになるようにしてください。 、最小限の再構成(たとえば、.iniファイルの交換など)。
理想的には、必要なデータベースや実行可能ファイルなどを含むディレクトリzipファイルなどのドロップイン環境の「アプライアンス」になります。おそらくフラッシュドライブ上。

いいえ、私もそのようなユートピア的な環境で生活し、働いていません!しかし、これは、私が想像しているように、それがどのように行われるべきかということです。

プランB:上記を実行できないと仮定すると、「ライブ」ネットワークやサーバーなどの外部に対するテストで立ち往生しています。つまり、データベースクエリは、他の誰かのテストデータベースサーバーに対して実行され、前回のテスト時と同じデータが含まれていることを期待します。したがって、外部環境が前回と同じであることを確認するために実行できる最小限のテストセットを用意する必要があります。昨日、先月、昨年かもしれません。HRテストデータベースから従業員レコードを取得する必要があるとします。では、接続、ログイン、レコードのクエリを実行し、結果セットを「最後の既知の正常な」結果セットと比較できることを確認するテストアプリを用意します。今、あなたは行ってもいいです。それほど遠くない場合は、それを実行してください(ログイン、エンドポイント、ホスト名、プロキシを修正し、アカウントを設定したり、ドライバーをアップグレードしたりします。)システムの残りの部分のコーディング/テスト/デモについて心配する前に。これにより多くの時間が節約され、nothignが機能するために、3日後にあきらめて終了する新しい開発者の減少を防ぐことができます。

更新:そして、何をするにしても、バージョン管理にチェックインして、戻ったり、比較したりできるようにします。

于 2010-05-05T15:39:10.820 に答える