私は小さなWeb開発会社で働いており、すべてのPHP/MySQL/etcを扱ってきました。しばらくの間。私は、成長に合わせてコラボレーションを容易にするために、プラクティスを改善することを検討しています。私が心に留めているいくつかのことは次のとおりです。
より経験豊富な開発者は、この分野で必要な最初のステップとして何を考えていますか?本をお勧めしますか?考慮すべきことの1つは、私たちの日常のタスクの大部分は、新しいプロジェクトではなく、メンテナンスとマイナーな機能の追加を伴い、チームのサイズは3〜5になるということです。
私はちょうど見つけました ソロ開発者から拡大するチームについての関連する質問 。
これがソース管理を意味し、それを実行していない場合は、今すぐ実行してください。待ってはいけません、これを読み終えさえしないでください。やれ。あなたがあなたのリリースに番号を付けるためのいくつかの派手なパンツスキームを考え出すことを意味するなら、シンプルが最善です。これを試して...
X.00 =互換性を損なう可能性がある、または料金を請求したいメジャーリリース。
0.X0 =物を壊さない新機能。無料アップデート。
0.0X =バグ修正。
繰り返しますが、シンプルにしてください。 1ページのA4で十分です。
ソース管理システムがこれを行います。開発者がチェックアウトを行うと、ディレクトリ構造が取得されます。 VCSはバックアップです。VCSがインストールされているマシンをバックアップしてください。 VCSにないものは重要ではなく、バックアップする必要はありません。
構築に時間を無駄にしないでください。ネット上の無料のツールで十分です。
さらにあなたが欲しい...
あなたがそこで見逃した大きなことは(あなたの時間の大部分が維持に費やされているので)ユニットテストだと思います。デフォルトでは、メンテナンスには既存のコードの変更が必要なため、単体テストは、それらの変更が他の何かを壊すかどうかを効果的に判断するのに役立ちます。
私がそこに見ないもう一つのことは、問題追跡システムです。繰り返しになりますが、多くのメンテナンス作業を行っている場合は、適切な問題追跡システムが不可欠です(ただし、すでにこれらのいずれかを使用している可能性があり、言及していません)。
以前のwebdevの仕事では、5人の開発者が働いていました。
redmine 問題追跡ソフトウェアを使用して新しいプロジェクトを維持および作成しました。バージョン管理システム(VCS)としてSubversionとMercurialをサポートしていました。タンデムで。したがって、プロジェクトが他のプロジェクトとは異なるVCSを使用することは禁止されていません。重要なのは、問題番号を追跡し、残りはredmineが行うことだけです。
コーディング標準は必然的に成長します。チームがマージの競合を起こし始めると、競合を回避するためにチーム間で基準を設定する傾向があります。それは良い学習体験です。
私は一般的なディレクトリ構造に戸惑っています。 Web開発者は通常、コンピューターをクリーンにワイプし、コンピューターをすばやく再セットアップするのが得意です。コンピューターの再セットアップで問題が発生した場合は、コードをチェックアウトしたときにプロジェクトが既にセットアップされているように、Web構成をバージョン管理する必要があります。
チャットは素晴らしいです
本当にコラボレーションする必要があるのは、IMOで、チャットやファイル転送、および問題追跡用のGoogleドキュメントのようなものだけです。 Skypeは、私がこれまで働いてきたすべての企業で最も便利なツールの1つであることがわかりました。
チャットは、すぐにブロックされない問題や懸念事項を、周りを待って別の会話が終了するのを待たずに知らせることができ、電子メールよりもすぐに見える傾向があるため、非常に貴重です。
また、スクラムのようなプロセスで私が気に入っているのは、ほぼ同じ時刻にチャットすることを除いて、毎日のスタンドアップです。会議室は待ちません。病気のときやケーブルマンを待っているときなど、自宅で仕事をする方が簡単です。同じことが何度も繰り返されるのを目にしたときに頻繁に発生する問題を文書化できるように、その記録を作成しておくことは価値があります。その毎日のチェックイン用に別の部屋を作成して、チャットでポップアップする傾向のある他のすべての日々の詳細を避けてください。
ツール/レガシーコードのトレーニング
他のことに無駄な時間を費やしたことはありません。誰かがなじみのないツールを持っている場合は、それらに精通してください。彼らに良い本を渡してください。 IDEなどで時折デバッグセッションを行うために、一緒に座ってもらいます。同様に、頻繁に保守または再利用しているコードについても同様です。新しい開発者を紹介し、質問などをするときに、それを文書化することを強調しますが、間違いなく人々と一緒に座ってレガシーコードについて話し合ってから、彼らに投げて、彼らが掘り下げることができるように、早い段階でたくさんのデバッグタスクを与えます機能を追加したり、その一部を再利用したりする前に、もう少し。
文書化のために選択したものは何でも、それに固執する
ドキュメントをすべて1つの場所に保管し、同じツールで作成し、同じ方法でアクセスすることは非常に重要です。あなたは将来、誰もが好きなことをどこでも、ただドキュメント化できるようにすることを支持していません。
チーム全体に関連プロジェクトの見積もりを行わせる
ルーキーがより経験豊富な意見を得るのは非常に価値があり、最終的には誰もがそれを上手にできるようになります。
つぼみのニップ構成の問題
私は、新しいマシンを構成するのに数日かかる可能性があるシナリオにありました。その言い訳はありません。 1つのビルド/ゴーストイメージですべての重要なツールと事前構成されたサーバーを取得し、新しいものが追加されても最新の状態に保ちます。開発者が自分のもののインストールを処理できると思い込まないでください。何年にもわたって追加したもののレイヤー数を忘れがちです。
バージョン管理を適切に使用する
私が遭遇した前述の構成の問題のいくつかは、主に別のチームが分岐に慣れていないために発生し、約30のXML構成ファイルを手動でやり直す必要がありました(もちろんどちらも発生しないはずです)。維持しているアプリのバージョンを更新するたびに、1か月ほど。まだVCSパワーユーザーでない場合は、1人になるか、1人を雇ってください。また、Maven、Ant、および古いバージョンのEclipseを15以上のXMLファイルに入れて互いに戦わせないでください。それは本当に醜いです。
可能な場合はいつでもツール/フレームワーク/ライブラリの最新バージョンに更新
いつのものが古くなるかわからないので、突然、新しい開発者が利用できなくなったものを追跡する必要があります。このようなものは、立ち上げ時間を短縮する可能性もありますが、通常、この問題は、必要なすべてのイメージを作成することで対処されます。回避するもう1つの問題は、一連のアップグレードをすべて1回で処理することを余儀なくされることです。