タグ付けされた質問 「teamwork」

最新の「WTF」の動きの1つで、上司はバグ追跡テンプレートに「Person To Blame」フィールドを追加すると、説明責任が増えると判断しました（ただし、機能/ストーリーにバグを結び付ける方法は既にあります）。これは士気を下げ、指さしを高め、バグが前代未聞になったとして報告された機能の欠落/誤解を説明しないだろうという私の主張。 私が使用できるこの実践に対する他の強力な議論は何ですか？このトピックについて、チームやボスと共有できる文章はありますか？

695 teamwork  bug-report 

弊社ではこれを行っていませんが、友人の一人が、プロジェクトマネージャーがすべての開発者に、製品がQAに移行する直前に意図的なバグを追加するように依頼したと言います。これがどのように機能するかです： 製品がQAに移行する直前に、開発チームはコードのランダムな場所に意図的なバグを追加します。これらのバグが最終製品に付属していないことを確認するために、元の動作中のコードを適切にバックアップします。 テスターに​​もこのことが通知されます。バグが存在し、それらを見つけられないことは無能の兆候と見なされる可能性があることを知っているため、彼らは一生懸命テストします。 バグ（意図的またはその他）が見つかった場合、それらは開発チームが修正するために報告されます。開発チームは、製品が第2レベルのQAに移行する直前に、コードの関連セクションに別の意図的なバグを追加します。プロジェクトマネージャーは、テスターは開発者のように考えるべきであり、変更が行われたセクションに新しいバグがあることを期待すべきだと言います。 まあ、これはそれがどのように行くかです。彼らは、このアプローチには次の利点があると言っています。 テスターは常につま先を向いており、狂ったようにテストします。これは、開発者が修正できるように、隠れた（意図しない）バグを見つけるのにも役立ちます。 テスターはバグをフィードします。バグを見つけられないと、彼らの士気に影響します。ですから、彼らに見つけやすいものを与えることは彼らの士気を助けるでしょう。 これらの意図的なバグの1つが最終製品に同梱されるシナリオを無視する場合、このアプローチの採用を検討する前に考慮すべきその他の欠点は何ですか？ いくつかの説明： ソース管理で元のコードを適切にバックアップします。 テスターが意図的なバグを見つけると、開発チームはそれを無視します。テスターが意図しない（元の）バグを見つけた場合、開発チームは最初に意図的なバグが原因かどうかを確認します。つまり、開発チームは最初に元の作業コードでそれを再現しようとし、可能な場合は修正しようとします。 QAと開発チームの関係の問題を無視してください。私は、ワークプレイスではなくプログラマーにこの質問を具体的に尋ねました。QAと開発チームの間には良好な関係があり、勤務時間後には一緒にパーティーを行うことを考慮してください。プロジェクトマネージャーは、両方のチーム（Godsend）をサポートする準備が常にできている、素晴らしく、年配の紳士です。

267 testing  teamwork  debugging  bug 

私のチームメンバーの1人は、自分のコードでコメントを作成することを常に避けています。 彼のコードは自己文書化されておらず、他のプログラマーは彼のコードを理解するのに苦労しています。 私は彼に彼のコードをコメントするように何度も頼んだが、彼はただ言い訳をするか、または彼が後でそれをすることを主張する。彼の懸念は、コメントの追加に時間がかかりすぎてプロジェクトが遅れることです。 彼に彼のコードを適切に文書化するよう説得するために、どのような議論を彼に提示できますか？ そのメモでは、コードのコメントに焦点を当てるのは間違っていますか、これは対処すべき大きな問題を示していますか？

183 teamwork  team  comments 

たとえば、JSにはデフォルト値を取得するための一般的なスニペットがあります。 function f(x) { x = x || 'default_value'; } この種のスニペットは、私のチームのすべてのメンバーが簡単に理解することはできず、JSレベルは低いです。 このトリックを使用しないほうがいいですか？JS開発者によると、コードはピアでは読みにくくなりますが、次のコードより読みやすくなります。 function f(x) { if (!x) { x = 'default_value'; } } 確かに、このトリックを使用して同僚がそれを見ると、彼らは何かを学ぶことができます。しかし、多くの場合、彼らはこれを「賢くしようとしている」と見なしています。 チームメイトのレベルが私より低い場合、コードのレベルを下げる必要がありますか？

156 teamwork  communication  skills 

私はバベルES6でコーディングしている上級フロントエンド開発者です。アプリの一部はAPI呼び出しを行い、API呼び出しから返されるデータモデルに基づいて、特定のフォームに入力する必要があります。 これらのフォームは二重リンクリストに格納されます（バックエンドがデータの一部が無効であると言った場合、ユーザーを混乱させた1ページにすばやく戻し、ターゲットを元に戻すことができます。リスト。） とにかく、ページを追加するために使用される関数の束があり、私はあまりにも賢いのだろうかと思っています。これは基本的な概要にすぎません-実際のアルゴリズムは非常に複雑で、さまざまなページやページタイプがありますが、例を挙げて説明します。 これが、初心者のプログラマーが処理する方法です。 export const addPages = (apiData) => { let pagesList = new PagesList(); if(apiData.pages.foo){ pagesList.add('foo', apiData.pages.foo){ } if (apiData.pages.arrayOfBars){ let bars = apiData.pages.arrayOfBars; bars.forEach((bar) => { pagesList.add(bar.name, bar.data); }) } if (apiData.pages.customBazes) { let bazes = apiData.pages.customBazes; bazes.forEach((baz) => { pagesList.add(customBazParser(baz)); }) } return pagesList; } さて、よりテストしやすくするために、これらのifステートメントをすべて取り、それらを分離し、スタンドアロンの機能にした後、それらをマップします。 …

133 coding-style  functional-programming  teamwork  senior-developer  leadership 

私は職場で奇妙な状況にあります。私の同僚が私や他の同僚にコードの作業を依頼することがよくあります。 私は彼を助けたいと思っていますが、些細なスニペットのこの絶え間ない要求は私の考えを中断し、時々集中するのを難しくします。 さらに、私は、この要求は怠lazよりも能力の欠如によって生成されるという印象を持っています（...）。実際、彼はよく答えを知っているふりをします。私が問題を解決するとき、彼は通常「確かに」、「はい、それは私が考えたもの」のようなことを言い、私の答えは価値がないという印象を与えます。 この恥ずかしい状況をどのように解決できますか？ 他の同僚の前で彼の知識の欠如をもっとはっきりと示すべきです（「できるなら自分でやってください」など）。 彼はすべての質問を1つにまとめる必要があると思います。そうすれば、私は彼に私の時間の一部を与え、彼はすべて自分のことで自分の仕事に取り組むことができます。 チーム内に階層はありません。どちらもほぼ5年というほぼ同じ年配者です。些細な質問はしばしば無視されるので、同じ理由で私は経営陣に報告できないと思います。 私は他の2人のメンバーと話し合い、彼らは私に同意します。実際、彼はよく同僚を介してサイクリングすることを尋ねます。

113 productivity  self-improvement  teamwork 

私は比較的新しいデベロッパーで、大学の新人です。大学在学中およびその後の求職中に、ユニットテスト、ロギング、データベースの正規化、アジャイル開発（一般的なアジャイルコンセプト）、コーディングスタイルに欠けている多くの「最新の」ソフトウェア開発方法があることに気付きました。ガイド、リファクタリング、コードレビュー、標準化されたドキュメント化方法（または要件）などもありません。 全体として、これが問題だとは思いませんでした。私は私の最初の仕事がこれらすべてのアイデアを受け入れ、仕事で私にそれらを教えることを期待していました。それから私は大企業で私の最初の仕事（フルスタックWeb開発）を得ました、そして、私は我々がこれらのことのどれもしないことに気付きました。実際、チームで最も経験の浅い私は、「最新の」プログラミング技術でチームをスピードアップさせようと試みている先駆者です。 最初にロギングソフトウェア（log4J）から始めましたが、すぐに独自のスタイルガイドの作成に移り、それをGoogleスタイルガイドのために放棄しました。 Springの採用-しかし、ユニットテストもなかったことに気付きましたが、私はすでにSpringを学習していました...そしてご覧のように、特に通常の開発作業と組み合わせると、圧倒的に速くなります。さらに、これらの方法論の中で「専門家」になって、他の誰かに教えるのに十分な「専門家」になるのは難しいです。 今日のソフトウェア開発の世界では「期待される」と思われるこれらのテクニックのうち、自分とチームの両方を圧倒することなく、それらを新しいプレーヤーとしてチームに統合するにはどうすればよいですか。 どうすればチームに影響力を与えてアジャイルになれますか？関連していますが、私はここの質問者のようなアジャイル開発者ではなく、アジャイルよりもはるかに広範な方法論のセットを探しています。

106 agile  teamwork 

この質問の残りの半分：東洋のプログラマーは西欧のプログラマーをどのように見ていますか？ 世界の東部（インド/中国/フィリピン）は、主に西部の世界（アメリカとヨーロッパ）にアウトソーシングサービスを提供しています。 オフショアチームと仕事をした経験はありますか？はいの場合、どうでしたか？ 東洋のプログラマーに関する一般的なアイデアや意見はありますか（例：彼らは協力しているか、時間通りに納品しているか、質の高い仕事をしているのか）。これらは何に基づいていますか？

101 teamwork 

「特定の方法で使用しなければならない」クラスを書いています（すべてのクラスが...する必要があると思います）。 たとえば、fooManagerクラスを作成します。これには、などへの呼び出しが必要Initialize(string,string)です。そして、例をさらに進めるために、そのThisHappenedアクションをリッスンしなければクラスは役に立たないでしょう。 私のポイントは、書いているクラスにはメソッド呼び出しが必要だということです。しかし、これらのメソッドを呼び出さなければ、コンパイルは正常に終了し、空の新しいFooManagerが作成されます。ある時点で、クラスとその動作に応じて、機能しないか、クラッシュする可能性があります。私のクラスを実装するプログラマーは明らかに内部を見て、「ああ、Initializeを呼び出さなかった！」と気付くでしょう。 しかし、私はそれが好きではありません。私が理想的に望んでいるのは、メソッドが呼び出されなかった場合にコンパイルしないコードです。それは単に不可能だと思います。または、すぐに表示され、明確になるもの。 私がここで持っている現在のアプローチに悩まされているのは次のとおりです。 クラスにプライベートブール値を追加し、クラスが初期化されている場合は必要なすべての場所を確認します。そうでない場合は、「クラスが初期化されていません.Initialize(string,string)。本当に呼び出していますか？」という例外をスローします。 私はそのアプローチで少し大丈夫ですが、多くのコードがコンパイルされ、最終的にはエンドユーザーには不要になります。 また、Initiliaze呼び出すだけのメソッドよりも多くのメソッドがあると、コードがさらに増えることがあります。パブリックメソッド/アクションが多すぎないようにクラスを維持しようとしていますが、それは問題を解決するものではなく、単に合理的なものにするだけです。 私がここで探しているのは： 私のアプローチは正しいですか？ より良いものはありますか？ 皆さんは何をしますか/アドバイスしますか？ 非問題を解決しようとしていますか？同僚から、使用する前にクラスをチェックするのはプログラマーだと言われました。私は敬意を持って同意しませんが、それは別の問題です。 簡単に言えば、そのクラスが後で、または他の人によって再利用されたときに、呼び出しを実装することを決して忘れない方法を見つけようとしています。 明確化： ここで多くの質問を明確にするために： 私は間違いなくクラスの初期化の部分について話しているだけでなく、それは一生です。同僚がメソッドを2回呼び出さないようにし、Yの前にXを呼び出すようにします。Assertsのアイデアは本当に気に入りましたが、Assertsが常に可能であるとは限らないので、他のアイデアを混ぜる必要があると確信しています。 私はC＃言語を使用しています！どうして私はそれを言及しなかったのですか？！私はXamarin環境にいて、PCL、iOS、Android、およびWindowsプロジェクトを含むソリューションで通常6〜9個のプロジェクトを使用してモバイルアプリを構築しています。私は約1年半（学校と仕事を合わせて）開発者でした。そのため、時々ばかげた声明や質問があります。ここではおそらくすべては無関係ですが、情報が多すぎることは必ずしも悪いことではありません。 プラットフォームの制限と依存関係注入の使用のため、コンストラクターに必須のすべてを常に配置できるわけではありません。Interfaces以外のパラメーターはテーブル外にあります。または、私の知識が十分でない可能性があります。ほとんどの場合、初期化の問題ではありませんが、 彼がそのイベントに登録したことを確認するにはどうすればよいですか？ 彼が「ある時点でプロセスを停止する」ことを忘れなかったことをどのように確認できますか ここで、私は広告取得クラスを覚えています。広告が表示されるビューが表示されている限り、クラスは毎分新しい広告を取得します。そのクラスは、Adを表示できる場所に構築するときにビューを必要とします。これは明らかにパラメーターに入れることができます。ただし、ビューが消えたら、StopFetching（）を呼び出す必要があります。そうしないと、クラスは、そこにさえないビューの広告を取得し続けますが、それは悪いことです。 また、このクラスには、たとえば「AdClicked」など、リッスンする必要があるイベントがあります。聞いていない場合はすべて正常に動作しますが、タップが登録されていない場合、そこでの分析の追跡が失われます。ただし、広告は引き続き機能するため、ユーザーと開発者には違いが見られず、アナリティクスのデータは間違っています。それは避ける必要がありますが、開発者がtaoイベントに登録する必要があることを開発者がどのように知ることができるかわかりません。しかし、これは単純化された例ですが、アイデアは「彼が利用可能な公開アクションを使用することを確認する」ことであり、当然のことです！

96 programming-practices  teamwork  class-design  implementations 

チームの管理について質問がありました。現在、私はコーディング工場からリモートで作業しているジュニア開発者を扱っています。その男は批判に対して寛容であり、学ぶことをいとわないが、どれだけのものをプッシュすべきか疑問を抱いた。 現在、何かがまっすぐで明白な場合、グッドプラクティスの違反です。SRP、Godオブジェクト、メソッドまたは変数の意味のない名前の違反など。私は彼が修正しなければならないことを指摘し、それが間違っている理由を説明しようとします。 私の質問は次のとおりです。間違った言語の変数名（以前のチームがスペイン語と英語を混ぜて、それを修正しようとしています）のようなコーディングスタイルのマイナーな違反がある場合、またはいくつかのマイナーな構造上の問題がある場合、私は手放します空き時間があるか、問題のあるクラスを変更する必要があります。これはチームの士気に良いと感じているので、初心者には些細なことのように見えるかもしれませんが、コードを常に押し戻そうとはしていません。何かをする方法を学ぶことから。 男を教えることと絶え間ない批判で彼を焼き払わないことの間のバランスをどのように取るのですか？後輩にとっては、目が効いているものをやり直すように言ったらイライラするかもしれません。

95 code-quality  teamwork  team-leader 

私たちは約5年間生産されている大型製品に取り組んでいます。コードベースは動作しています。あまりよくありませんが、機能しています。新機能は実稼働環境に投入され、小さなQAでテストされます。バグは修正されています。しかし、私以外の誰もユニットテストを書いていません。この特別なバグ（テストケース）が二度と発生しないことを保証するために、単体テストを記述してバグを「追跡」する力を使用する人はいません。 私は経営陣と話しました。開発者と話しました。会社全体の全員と話をしました。みんな言う：「そう、もっとユニットテストを書かなければならない！」それは約一年前でした。それ以来、コミット前のコードレビュー（Gerrit）と継続的インテグレーション（Jenkins）の導入を強制しています。 ユニットテストについていくつかの会議を開催し、ユニットテストを書くことの利点も示しました。しかし、誰も興味がないようです。 Q1：同僚に単体テストを書くように動機付けるにはどうすればよいですか？ Q2：個人コードの品質基準を遵守する意欲を維持するにはどうすればよいですか？（時にはイライラすることがあります！） PS：いくつかのイライラする事実（1年で到達）： 単体テスト：1693 合計「サンプル単体テスト」：約50 完了：1521 編集：私はあまりにも期待していますか？その最初の職場であり、ベストを尽くそうとしています。 編集2：すべての答えに基づいて、私は自分のために小さなチェックリストを作成しました。私はプライベートで2人の開発者と話をしました。 そのうちの1人は、テラスティンが言ったように、彼がユニットテストに本当に不快であると私に言った。彼は「もっとプロフェッショナルになりたい」と言ったが、キックスタートが必要だ。彼はまた、すべての開発者とのユニットテスト会議（約9〜11日）は良かったと言いましたが、あまりにも混雑していました。えー 批評家もいますが、それから学びます。（tdd kataミーティングに関する以下の回答を参照してください！） もう1人は、単体テストの作成には興味がないと言いました。彼は自分の仕事が給料に十分であると考えています。彼はそれ以上の努力をしたくありません。私は全く言葉を失いました。典型的な9-5「労働者」。 来週は他の開発者と話をします。 素晴らしい回答（これまでのところ）とサポートに感謝します。ほんとうにありがとう！私は多くを学びました、ありがとうございました！

92 unit-testing  development-process  teamwork  communication 

この質問の残り半分：西側のプログラマーは東側のプログラマーをどのように見ていますか？ 東のプログラマが西のプログラマをどのように見ているかを見るのも同じくらい興味深く、重要だと思います。 世界の東部（インド/中国/フィリピン）は、主に西側の世界（米国およびヨーロッパ）にアウトソーシングサービスを提供していると見られています。 オフショアチームの一員として働いた経験はありますか？はいの場合、どうでしたか？ 西洋のプログラマーに関する一般的なアイデアや意見はありますか（例：彼らは協力しているか、時間通りに納品しているか、質の高い仕事をしているのか？）

89 teamwork  culture 

私は優れたプログラマーです。私はいつもプログラムが大好きです。そして、私はプログラミングについて多くのことを学び、私をより良いプログラマーにしたいと思っています。私は1年間プログラミングを学び、現在はほぼ2年間プログラマーとして働いています。要するに、私はほぼ3年のプログラミング経験があります。 私たちのチームは5人のプログラマで構成されており、うち4人は新しく、1人は3年以上の経験があります。私たちはもう1年近くプログラムに取り組んでおり、コードをレビューする人は誰もいませんでした。コードのレビューは一度も行ったことがなく、まったく新しいので、きれいなコードがどのようなものかはわかりません。プログラマーは自分で学ぶと思う？ 徹底的なテストなしで、プログラムにプログラムを展開しました。現在はタイトであり、コードを変更する前にまず承認とコードレビューが必要です。初めて、誰かが私のコードをレビューし、彼はそれが混乱だと言います。 私はとても悲しくて傷つきます。プログラミングが大好きで、そのようなことを言わせると本当に痛いです。私は本当に自分自身を改善したいです。しかし、私は映画のような天才プログラマーではないようです。もっと良くする方法についてアドバイスをいただけますか？コードを批判する何かを経験したことがありますか？それらのイベントで何をしますか。

86 teamwork  code-reviews  maintenance 

私は新しいプロジェクトに取り組んでいます。プロジェクトは次のように機能します。エンドユーザーはリンクを使用してwebappにアクセスし、ネットワークに複数のシステムを追加して、その特定のシステムの詳細を管理できます。私の部分には、フロントエンドとWebサーバーが含まれます。これは、Pythonで行われます。私のpythonは、実際には完全にcおよびc ++で実行される別のプロジェクトと通信します。c / c ++プロジェクトは、すべての機能を実行するメインアプリです。私のpythonはそれにユーザーリクエストを送信し、それに対するレスポンスをユーザーに表示します。 私は自分の仕事に非常に精通しており、まもなく終了します。それはそれで多くの仕事ではないので。そして、私は仕事が大好きな人です。私はほとんどの時間をオフィスで過ごし、眠くなるまで家に帰りません。 c / c ++アプリは、5年以上の経験があり、私よりもずっと速く仕事をすることができる別の同僚によって管理されていますが、彼は決してそれを行いません。彼はそれをしたくないかもしれません。私のpythonが通信したり、間違った値を返したりすると、彼のアプリは頻繁にクラッシュします。バグだらけです。私のアプリはそれに依存しているため、作成に苦労しています。バグを修正する代わりに、彼は私の仕事を遅くするように頼みます。彼はマネージャーに私の仕事には多くの時間が必要だと言うように頼みます。彼は私にマネージャーをだますように頼み、私に彼のようにゆっくりと働かせることさえしている。 プロジェクトミーティング中に、マネージャーがバグについて彼に尋ねると、彼はすべてを修正し、それがうまくいくと言います。彼は私の同僚なので、マネージャーには何も言えませんでした。私たちはマネージャーではなく同僚とほとんどの時間を過ごすので、明らかにマネージャーよりも同僚と良い関係を築く必要があります。 マネージャーが彼に理由を尋ねると、彼はマネージャーに彼について不平を言ったと思うかもしれないので、私はこれについてマネージャーに何も伝えることができません。そして彼は会議で嘘をつき続けます。そして、彼はバグをゆっくり修正するので、私の作業も遅くなります。今、私は私のアプリのフロントエンド部分に取り組み、その間に彼がプロジェクトを安定させることができるようにそれを仕上げることを考えました。今、彼はマネージャーに、私のフロントエンド部分には多くの作業が必要であり、プロジェクトを下にドラッグできるようにするために、より多くの時間を必要とすることを伝えるよう求めています。悲しいことに、実際のマネージャーは米国に行っているため、一時的なマネージャーがいて、この男はプロジェクトについてあまり知らないので、c、c ++は彼をだます。 誰が私にこれに対処する方法を提案できますか？私はプロジェクトをすぐに終わらせたかった。彼との良好な関係を維持することによって、どうすれば彼を働かせることができますか コメントへの応答： 彼が本当に故意に会社を誤解させている場合は、経営陣に報告する必要があります。 私はこの会社に新しく、他の男は長年そこにいました。そして、同僚について知り始めたばかりです。私が直接行って彼に苦情を申し立てた場合、他の同僚と良い関係を築くことができるとは思いません。彼でさえ、彼らを惑わす力を持っています。私は彼が悪い男だとは言っていません、彼は仕事をすることができますが、彼はそれをしていません。 あなたの会社にはどんな種類のバグ追跡システムもありませんか？ ここには、実際のバグ追跡システムはありません。会社はできるだけ早くプロジェクトを終了させ、QAに提供しようとします。そして、QAによって報告されたバグを修正します。 企業が従業員にストック/オプションまたは何らかの所有権を与える必要があるのはこのためです。そうすれば、文字通り「あなたは私に金銭的成長を犠牲にしている...お金をもうけたくないですか？」と文字通り伝えることができます。 会社にはストックオプションがあり、2500株を与えてくれました。ほとんどが彼も持っていたでしょう。 年功序列には疑いの余地があります。最初に彼に話しかけ、問題を理解する必要があります。彼は彼の深さから外れているかもしれません、あなたは彼を助けることができるかもしれません、あなたが気づいていない変数が簡単にあるかもしれません。今では難しいかもしれませんが、銃を跳ぶことで状況を簡単に悪化させることができます。 彼のアプリは一度に複数のリクエストを処理していなかったため、キューを使用して、自分に送信したリクエストを処理していました。私も彼に私のアイデアのいくつかを提案しました。彼はすでにこれらのアイデアを持っている、そしてそれらを実行するだろうと言った。彼の説明は、「すべてを行うには一定の時間が必要であり、これは完了するのに2年を必要とする可能性のあるプロジェクトであり、2か月で完了するように求められます」。このバグのため、最初の数週間はコーディングに苦労していました。しかし今、彼はそれを修正しました。しかし、彼はユーザーリクエストに単一のキューを使用しており、一度に1つのリクエストを処理するため、アプリの速度が低下しています。 この間ずっとQAは何をしていますか？プロジェクトのステータスを報告/確認しないのはなぜですか？ マネージャーは、QAにいつ提出するかを決定する人です。現在のところ、QAにはまだ提供されていません。彼は今月末までにそれを与えるべきだと言った。

85 teamwork 

私のチームメイトの1人はITショップのすべての取引のジャックであり、私は彼の洞察を尊重しています。 ただし、彼は時々頭を使わずに私のコードをレビューします（彼はチームリーダーの2番目の指揮官なので、それは予想されています）。そのため、時々、彼は最終目標を完了する前に私の変更をレビューし、すぐに変更を加えます。 また、3か月以上前のコードの一部に不要な改善を加えた場合もあります。 これにはいくつかの理由があります。 間違いを修正する機会が常に与えられるとは限らない 彼は、彼が混乱しているときに私が何を達成しようとしていたかを尋ねる時間をとっていないので、テストや変更に影響を与える可能性があります 彼のコードが読めるとは限らない 期限は問題ではなく、彼の現在のワークロードは、コードの変更を確認する以外に私のプロジェクトでの作業を必要としません。 とにかく、私は過去に彼が私のコードの所有権を取得できるように変更したい何かを私の仕事で見た場合、私に投稿してくださいと言いました（多分私は「欠点」と言うべきでした）、彼は応答しませんでした。 彼に私に彼の変化を説明するように頼むとき、私は攻撃的になるかもしれないと恐れています。 彼は自分を守る静かな人ですが、彼の行動は続きます。私たちはチームであるため、私は彼にコードの変更を禁止したくありません（できませんでしたが）。 説明を追加： 1つの開発ブランチを共有しています。重要な作業を失うリスクがあるため、すべての変更が1つのタスクを完了するまで待機しません。したがって、変更を確実にビルドし、何も壊さないようにします。 私の懸念は、チームメイトが彼の変更の背後にある理由や目的を説明していないことです。私は彼が私の祝福を必要とするべきではないと思うが、私たちがアプローチに同意しない場合、私たちが長所と短所を議論し、両方が何が起こっているかを理解したら決定を下すことが最善だと思った。 これはチームリーダーとはまだ話し合っていません。必要でない限り、経営陣が関与することなく個人的な意見の不一致を解決したいからです。私の懸念は私たちの仕事に対する脅威というよりも個人的な問題のように思われたので、チームリーダーを煩わせないことにしました。私は、コードレビュープロセスのアイデアに取り組んでいます。これは、私のペットの気持ちをすべて気にすることなく、より組織的なコードレビューのメリットを促進するためです。

71 refactoring  teamwork  communication  code-ownership