ジャストは、プロジェクトの引き出されたXプロジェクトと呼ばれます。このプロジェクト、または遭遇した多くの問題が、また、問題の一部、または冬の尾根の収穫を解決するため、合計します。
タイトルが短期プロジェクトの概要を述べているが、実際には、このプロジェクトが短いではありませんが、それは3年程度続きました。私はこのプロジェクトに滞在だけ短い時間、短い、いわゆる。私は2年以上のプロジェクトを実行していた後、時間、外出先でのポイントがある6ヶ月で終了します。プロジェクトはメンテナンス期間に入った後、私は、私はプロジェクトを残して、4ヶ月以上歩き回ったので、
私は以下のとおりである目的を行ってきました：
それは（ほかの正常な発達出力とみなされるべきである後、私はプロジェクトのスケジュールに参加した時点で、制御されているので、これは、必須ではない）バグを開発し、維持1.簡単なヘルプ。
2.（プロジェクトの履歴上の問題、過去の比較的低品質と顧客満足度の多くを）プロジェクトが登場理解し、今の問題はまだあります、分析し、勧告を与えます。
3.連絡先とは、チームメンバーを理解し、必要に応じて積極的なインセンティブを与えます。
4.個人的に私のために、あなたはまた、彼らの元では利用できないいくつかのソフトスキルを学ぶことができます
さらに騒ぎがなければ、このコラム下記をご覧プロジェクトに遭遇したが、それはまた、問題の他のプロジェクトと同様に、いくつかの個人的な考えで発生する可能性があります。
1.不正確な文書の陳腐化の一部で、メンテナンスされていない、と見ることがない1
2.コードレビュー・プロセスの無効、校閲直接ポイントのマージ、または言及したコメントは無視されます。（MRと呼ばれる）いくつかのマージ要求が適切な校閲追加していない（例えばメンテナンス機能が他の人によって書かれたときのように、一般的には、作者の機能を追加する必要があります）
3.コピー＆ペーストは深刻であり、開発の一部は、独自のコードについては責任を負いませんと来貼り付けます。
4.コーディングスタイルは均一ではなく、チームは一見コードスタイルの重要性を認識していませんでした。
タスクの優先順位が頻繁に変更、あなたは同じタスクが人を変更するには、数回の日を割り当てることができ、毎日のタスクのリーダーを再スケジュールする必要があります。開発、タスクを実行するために、毎日3-4回を変更することがあります。
6.開発者がバグを発見した場合は、処理の流れを決定統一がなく、多くの場合、民間の通信では、人々はそれらを修正または原著作者が修正いずれかのことがわかりました。
7.プロジェクトは、複数のブランチがあるため、プロジェクトのアーキテクチャにより、ブランチを切り替えた後、スクリプト/コマンドのシリーズを必要と/（時々）の設定を調整し、大規模な維持する必要がなく、定期的な環境を台無しに環境全体を再デプロイする必要がありますしています再び。巨大なコスト。大規模なブランチを切り替え事業開発およびコードに精通した後、最も時間のかかる活動になります。
時々不満を示し、自信の欠如、欲望矛盾と現状のリード開発プロジェクトに使用される技術は、比較的古いものですので8は、いくつかの開発者が学ぶこと熱望しているが、私はあなたが学ぶ（指導・助言の欠如）できるかわかりません。
さて、問題の分析と私は考えることができるリスト溶液（もしあれば）、およびこれらの問題以下の問題リストの上には、いくつかのテーマにまとめることができます。
- ドキュメントの問題
実際には、この問題は簡単すぎると言うのは簡単です、それが困難であることは困難です。これは循環器系の問題、好循環または悪循環です。
いわゆる好循環、チームはこの情報を文書として記録し、チームに通知されます伝える、または使用するために繰り返すことには何の情報ニーズ、発見しました。また、それぞれが更新される情報ニーズを発見し、積極的に文書を更新しています。ご質問があるたびに、ドキュメントを検索するために行きます。問題を自己解決します。
逆に悪循環、情報は再利用かどうか、文書化、または情報の更新や古いドキュメントを検索ドキュメントを更新しないことになります。文書は、文書の文書時代遅れ不正確で、誰でも一見の内容を更新しないと、文書は、名前だけでドキュメントを参照するには、チームも失われた意識や習慣が存在する、無効になるため、時代遅れで不正確の最終文書、サイクルが続くので。
単純に、各文書は完璧を必要としませんが、情報を再利用することができたときに作成され、多くの人々が意識的に文書を書き、更新持っているように、よく知られている（チーム内の）文書の入り口には、そこにあります。
難しい部分になる、で、そうでない場合は、長期的な更新、完全に廃止された文書の多くは、書き換える必要があります。私たちはさまざまな習慣を形成しているためとあれば文書では、最初のプロモーションより中期プロジェクト、のような標準的な物事がはるかに困難再実行しますに付着することが含まれています。
ドキュメントは、問題を解決したい、予防は治療よりも優れています。予防には、より多くの人々が、文書作成や更新、および遵守する必要性に関わるように、プロジェクトの早い段階で開始されます。プロジェクトの後の段階であれば、単に手術とほぼ同じに変更するには、我々は、文書の変更に手元でより大きな決意と実行の必要性を仕事を下に置きたい、と衝撃が進行になります後に変更されている場合、実装は同じまま廃止された無効なドキュメントになります時間をかけて、ドキュメントでは、この時間は無駄な部分で変化すること。
- コードの品質
かかわらず、コードレビュー、コードスタイル、またはコピーして貼り付け、これらの問題は、コードの品質でゴール、を指します。コードの品質はまた、プロジェクトの品質に直接影響します。
コードの品質は一夜ではない正当な理由ではなく、またその人の責任です。この問題を解決するために、チーム全体が一緒にいくつかの時間を費やす必要があります。
その時点でプロジェクトによると、時間があまりないので、限られた知識と個人的な経験と組み合わせたフォローアッププロジェクトは、私の目標は、ちょうど右方向よりもコードの品質にしたい、どのくらいでどのくらい向上させることができます。
私は、これらは以下のものが含まやってしまいました。
コードの標準を開発し、チームが認識を受け入れることができ1.。Eslintは、補助コードが実行される仕様を導入し、CIのeslintプロセスに添加します
コードレビューの基準を開発する2。そして、日々のコードレビューのアイデアは、我々は基準を認識コードレビューを実行し、チームに広がっていきます。
3.ときに、新しいモジュールの手動操作を自動化し、ベース・クラスおよびノードスクリプトを達成するために、ロジックの隠された部分が繰り返され、共通の機能を実現する標準化法の数。また、これはチーム全体に拡張することができ、より良い実装方法を有することが判明したときに、コードの難しさを理解するために私たちを低減します。
4.いくつかの願いが、学び、共有体験を改善したり、ALTER同僚と前方にそれらをやる気にさせるしようとすることがわかりました。このプロジェクトは、古いのフレームワークを使用し、彼らは何かが一緒枠組みの外に学習することができることを見出しました。コンポーネントを設計するためにどのようにコードの読みやすさ、拡張性、デザインパターンは、開発プロセスなどを最適化する方法を、ご利用いただけます。
私は事をしませんでしたが、私はしませんでした最後の点は、非難の誰かの特定にあります。まず、これは個々の問題が、プロジェクト全体の問題ではありません。あなたは、誰かを責める感情的なリバウンドを持っている人を非難した場合、唯一の仕事の難しさを増すであろう、その後の推奨に変更されることはありません。
我々は他の人がターゲットに変更したい場合は、このプロセスの後、深くだけでも、目標を達成するための方法を通知し、そして最終的にはより多くの私たちの希望の目標を達成するための有望な、目標を教えていない、真実を理解しています。時々の人々が変更に喜んではありませんが、ちょうど行う方法がわからないので、私は方法がわからない状況下で、多くの人が変更にあきらめます、その後、非難する衝動はあまり意味はありません。
繰り返しますが、これは非常に長い時間継続中のプロジェクトで、我々はすべての彼らのさまざまな習慣でプロジェクトを開発する必要があり、これが唯一の紛争や対立につながる、太字や強力な変更のために他の人に尋ねていない事を促進を助長されていません。まず、チームを理解するための良い方法は、その後、徐々に状況の痛みに変更し、特定の方法に変更を与えるにチームを試してみましょう。
- タスクの割り当て方法
タスク割り当ての上記の問題は、ここでは繰り返しませんが、問題は、につながる可能性があると言うこと：
1.更新され、毎日のタスクの優先度と自発的な発展につながる可能日は、抑制されていることをタスクを割り当てる必要があります。割り当てられたタスクを完了するための日として、開発が自分でより多くのタスクを受け取ることができません。日々の変化の優先順位が原因なので、今日のバグはまた明日変更する必要がある場合は誰も知りません。そうでない場合には、上記に費やした時間の無駄です。
2.同じバグが頻繁に候補者を変更します。我々は、すべてではないすぐにできた後、コードを変更するバグを取得することを知っています。最初の研究。研究は、スイッチングブランチ、再生を含め、コードを読んで、プログラムにしたいです。このプロセスは、多くの場合、ショートコードよりも優れていると変更時間をテストされて書き換え。バグが時間をかけて、開発者に割り当てられ、他の誰かのためにアレンジされている場合は、その後の変化に良いバグの前に、それは、ほぼすべての時間が浪費され、研究段階に費やさではないが。これが標準であれば、チームは基本的に予測可能な非効率的です。
開発プロセスの奇妙な特徴の機能に割り当てられた3バグ。この方法は、さまざまな状況があり、スティックを殺すことはできません。
何のスケジュールの圧力が存在しない場合には、そうすることは、知識の共有の一種であるプロジェクトの将来のメンテナンスのリスクを減らすことができます。
B。コア開発者ならば、様々なパブリックメソッドとコンポーネントとして、より多くの可能性が完全な機能にあるこれらのもののバグが自分に割り当てられている場合、この時点で、1は公平ではない、そして第二に、より貢献引き起こし、仕事より、おそらく一般的なモチベーションの方法およびコンポーネントを達成するためにチームに対して。
スケジュールの圧力があった場合は機能が複雑で十分であれば、C。、それはコードを実装する方法、機能を使用する方法、ニーズを理解し、その上に時間がかかり、開発の機能に奇妙なバグを受けました。また、これは効率にある程度につながる高くありません。
解決したようではなく、一人、多くの場合、クライアントのスケジュールの圧力を持っているタスク割り当てを、解決することができます。彼は私の個人的な見解については、以下の言いました：
1.少し長いタスク有効時間の優先順位を作るようにしてください。この顧客対応の同僚は、良い交渉のスキルを持っています。利点は、開発がその日に割り当てられたタスクを完了すると、チームの効率性と熱意を、自分自身や自分の仕事に慣れて受け取る改善する機会を持っているということです。
2.ない短い変更は非本質的な研究に費やした廃現像剤を避けるために人を割り当てられたタスク、準備、時間の試行で。最終提出前のコードでは、多くのことを行うことができますので。それはまた次のポイントではなく、あまりにもカジュアルなスケジュールタスクに依存します。
3.バグやタスクは、公衆に基づいている場合、我々は一般的な処理タスク、ワークロードに応じて、各の、すなわち開発などをお勧めします、分布のバランスをとることを試みるが、それは単にタスクを扱う人少ない人で、続けています。非パブリック関数、のみ特定のページや機能モジュール場合は、機能を扱うに精通している開発者を聞かせすることをお勧めします。
- 開発ブランチの切り替えの問題
私はむしろ特別だと思った点は、普遍的ではありませんが、その後、反射に、この問題はまだいくつかの一般的なインスピレーションを得ることができることを、彼らはまだ話を続けます。
実際には、この問題は、開発環境と呼ばれることができます。プロジェクト我々は主要な各ブランチの切り替え後、再デプロイ、設定する必要がありますが、多くのことを実行し、さらに展開が失敗した場合、まだ失敗する可能性があり、展開を実行する場合、いくつかの大規模な支店を持っていて、実行、環境設定を再インストールする必要があります物事の別のたくさん。問題は、この問題と正常な発達を排除するために、大きな枝を開発するために切り替えた後に発生した場合、多くの場合、午前または午後はそう渡すことができ、数時間かかります。
私は直接、別の大規模なブランチで作業を行うために、環境が唯一の大枝に基づくことができることを、個別に設定可能な、時間をかけて投げる方法を思いついた、準備ができて各主要支店のための単一の開発環境であります別のオープンな開発環境。愚かな、しかし効果的なこの方法は、多くの時間を節約するために私を助けて。
私はあったが、問題は解決しますが、別の問題を反映しています。私は言葉を定義：この状態では、私はコードを開発するために必要な、「準備開発」、私は状態を表したい用語を、実行時の環境変数は、データは準備ができている、タスクを開発することができます。そして、あなたは、大規模なブランチを切り替えたい開発の準備の状態を達成する必要がある場合は、このプロジェクトは、コストが数分は幸運、不運数時間で、固定されていません。私はこの問題は、可能な限り低いが準備されなければならないとして、このプロジェクト全体のコストとは、無数の回繰り返されるので、スイッチのタスクや作業への新しいメンバー、旧メンバーのためのプロジェクトは、開発コストを達成することであると言いたいです。価値が高い価格が、このコストを削減します。そして、私たちのプロジェクトは、独自の特殊性を持っていませんが、このコストは、それを削減することができなくなり、本当にないのですか？私は答えは何だと思いません。私たちは、より多くの手動操作を自動的に行うことができるように、複数のスクリプト、コンフィギュレーション、コマンドへの統合のみコンパイルまたは展開コマンドすることができます。これは、手動操作の結果に問題の多くを軽減するだけでなく、エネルギー消費と中断する人の数を減らすことができます。
このプロジェクトでは、私はやって正確にどのように知りません。しかし、将来のプロジェクトでは、私の目標は、準備キーの開発に到達することです。つまり、ブランチを切り替えた後、それがゼロであるかのみスクリプトやコマンドを実行する必要が人件費の開発を作製しました。私はそれが大幅に開発効率を向上させることができると信じて。
----------------
多くの日中久しぶりの書き込みブログ、書き込みだけでなく、完成先延ばし。それはあなたの時間を取るか、自分のを記録することです。
他の人と訂正を見ても、ありがとうございました。
2019年11月9日