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

免責事項：表明された意見は私自身のものであり、雇用主の意見や意見を表明するものではありません。 私は小さな会社で働いており、開発者はほとんどいませんが、QA / Testは1人、マネージャーは1人です。1.5年前にこの会社に入社しました。3人の上級開発者は8年以上の経験があります。 これらは私がチームリーダーについて行った観察です。（私をすべての面で彼らと比較して経験の少ない新鮮な人と考えています） 1対1で議論することも、後輩の提案を検討することもありません（受け入れるかどうかにかかわらず、少なくとも意見を検討する必要があることに同意します）。 シニアチームリーダーとして、彼らはコードベースを新しいテクノロジーでリファクタリングすることを試みることができます（新しいテクノロジーを展開する要因が可能であり、他の開発者やインフラストラクチャも準備ができています）が、これらのチームリーダーは、それらは最新ではありません。（私が言っている理由は、現在のプログラミングの傾向がわからない、*（modernizr、ブートストラップなどの人気のあるオープンソースプロジェクトなど）。 私たちのコードベースでは10000行以上が繰り返されているので、私は彼らにについて話しましたDRY: Don't Repeat yourself。彼らの回答は、「これは魅力的な記事ですが、実際には機能しません」でした。私たちは、100％DRYにしない場合、少なくともインターフェイスを使用できると伝えましたが、それも考慮されていませんでした。*（リファクタリングの準備ができていない場合、以前のコードベースに触れることなく、新機能用のインターフェイスを追加できます） すべての上級開発者は、パッチのメンテナンスとホットフィックスを行います。残りの時間はエンターテインメントサイトに費やすだけです。彼らは仕事を終えて喜んでいます。 新しい技術の導入は悪いですか？*（実現可能性の要素を含むことができます）。 マネージャーはまた、私が話していることについてあまり心配していません。 ジュニアは、チームリーダーから多くのことを学ぶことができると期待しています。*（彼らに助けを求めたり、上級コーディングを求めたりするのではなく）。 私の質問は： 私が提案している変更について私はあまりにも積極的ですか？ 8年以上の経験を持つシニア開発者のリーダーには何を期待すべきですか？ 会社から学び、経験を積むことを期待するのは間違っていますか？ 更新： 彼らが乾いたと感じるのは非現実的です：彼らはOOPの概念に関与したくないからです。彼らはタスクを繰り返すことに満足しています。 私が提案している新しい技術： CSS、JS、SPriteイメージの縮小の使用 インターフェースおよび.netフレームワーク4、ジェネリックなど多くの使用方法。 modernizr、knockout js、レスポンシブ用のブートストラップなどのクライアント側ライブラリ、

44 self-improvement  teamwork  junior-programmer  team-leader 

コードで作業するとき、チームメートと同じ課題の多くに直面します。また、有用な関数とクラスをいくつか作成しました。良好なコミュニケーションがあれば、誰かがまとめた素晴らしいことを聞くことができます。6か月後に必要になったときにそれを覚えて、その関数を呼び出して時間を節約できます。覚えていない場合、またはまったく知らない場合は、おそらく車輪を再発明します。 これらの種類のものを文書化する特定の慣行はありますか？どのようにしてそれらを見つけやすくしますか？ チームにそのようなドキュメントがない場合、ホイールがすでに存在するかどうかをどのように確認しますか？ 編集： これまでのところ、答えの1つを除くすべてが理想的な状況を扱っているので、これらのソリューションを要約します。ドキュメントとコミュニケーション。wiki、スタンドアップミーティングなどはすべて素晴らしいものですが、ドキュメントを作成し、ミーティングに参加し、メモを取り、すべてを覚える時間（およびスキル）を持つプログラマーに依存しています。 これまでで最も人気のある回答（Calebの回答）は、文書化や会議ができないプログラマーが使用できる唯一の回答であり、プログラミングを1つだけ行います。プログラミングはプログラマーが行うことであり、もちろん、優れたプログラマーはドキュメント、ユニットテストなどを作成できますが、それに直面しましょう-私たちのほとんどはプログラミングよりもドキュメントを好みます。彼の解決策は、プログラマが再利用可能なコードを認識し、それを独自のクラスまたはリポジトリなどに引き出し、それが分離されているという事実によって、それが見つけやすくなり、それを使用するための学習曲線を容易にすることです... 。そして、これはプログラミングによって達成されました。 ある意味では、このように見えます。3つの関数を書いたばかりで、他の誰かがそれらについて知っておく必要があると思います。私はそれらを文書化し、書き、会議で発表することができます-私はできますが、それは私の強さではありません-または....私はそれらをクラスに抽出し、それをうまく命名し、それらをブラックボックス、および他のクラスファイルが行く場所に貼り付けます。その後、それを発表する短いメールは簡単です。他の開発者はコードをスキャンして、完全に理解していないコードで使用されている分離された関数よりもよく理解できます。そのコンテキストは削除されます。 これは、適切な名前のメソッドを備えた適切な名前のクラスファイルのセットを持つことは、優れたプログラミングによって達成される優れたソリューションであることを意味するため、これが気に入っています。会議を必要とせず、詳細な文書の必要性を和らげます。 この流れに他にもアイデアはありますか？

43 documentation  teamwork  team  code-reuse 

現在、当社は、ほとんどの場合、Ruby on Rails WebサーバーとJavaのキオスクシステムからC / C ++の組み込みデバイス（標準Webブラウザーのインターフェースを含む）までのさまざまなRESTクライアントで構成されるアプリケーションを開発しています。チームを拡大する必要があり、優秀なシニアプログラマを見つけることができなかったため、会社とともに成長するジュニアプログラマのトレーニングに力を入れることにしました。 すでにRubyとRailsの本をいくつか提供し、いくつかのおもちゃプログラムを作成するように依頼しましたが、現在のWebプログラミングの学習曲線がいかに急勾配であるかを理解しています。 15年前にプログラミングを始めたとき、DelphiとSource Safeのみを使用し、使用可能なソフトウェアを最初から作成することができました。どちらもシンプルなツールであり、環境の内部構造を掘り下げるのは簡単でした。ゆっくりとサードパーティのフレームワークの使用を開始し、CVS、SVN、そして最終的にGitに切り替えて、HTTP、JavaScript、CSS、RESTなどの今日のWebを構成する要素を学びました。今日、長年の経験の後でも、 Delphiについて過去に行ったようにRuby on Railsが内部でどのように機能するかについても重要であり、私にとって重要なことは、基本的な学習ブロックを使用しているツールに接続できることです。 私が雇っているプログラマーは、チームと統合して使用可能なものを作成するのに長い時間がかかるようです。なぜなら、単一のフレームワーク（レール）を使用することを学ぶことはたくさんあるからです：Ruby、HTML、CSS、JavaScript、 REST、テストケース、データベースアクセス（フレームワーク内に魔法のように構築されたSQLを使用！）、MVC、3つの異なるパッケージマネージャー（Ubuntuに最適、Rubyにgemとbundler）、ssh、git、Apache、Phusion Passengerのデプロイなど ジュニアプログラマーと直接やり取りする必要があるのは初めてなので、私は迷っています。非常に多くの選択肢がある場合に、Web開発の今日のベストプラクティスについてジュニアプログラマーを訓練する最良の方法は何ですか？

39 web-development  teamwork  ruby-on-rails  training  junior-programmer 

私は最近、ジュニア開発者として始めました。チームで最も経験の浅い人の1人であると同時に、私は女性でもあります。男性が支配的な環境で働くことには、あらゆる種類の課題が伴います。私は自分の仕事に対して不当な教訓的な批判をしすぎているように感じるので、最近問題を抱えています。最近の出来事の例を挙げましょう。 チームリーダーは忙しくて、私が作ったいくつかのブランチをプッシュすることができなかったため、週末まで彼らに連絡しませんでした。私は自分のメールをチェックしましたが、実際には作業を行うつもりはありませんでした。変数名に基づいて2つのブランチが拒否され、エラーメッセージがわかりやすくなり、いくつかの値が構成ファイルに移動しました。 これに基づいてブランチを拒否することは有用ではないと思います。週末に多くの人が働いていましたが、私が働くとは言いませんでした。事実上、変更を行って再送信する時間がなかったため、一部の人はおそらくブロックされました。私たちは非常に時間に敏感なプロジェクトに取り組んでおり、クライアントにとって透過的なものに基づいてコードを完全に拒否することは役に立たないと思われます。私は間違っているかもしれませんが、時間があればパッチタイプのコミットでこの種のことを処理する必要があるようです。 今、私はいくつかの環境ではこれが標準であることがわかります。しかし、批判は平等に分配されているようには見えず、それが私の次の問題につながるものです。これらの問題のほとんどの原因は、私が誰か他の人が書いたコードベースにいて、最小限の侵入を試みているという事実によるものでした。ファイルの他の場所で使用されている変数名を模倣していました。私がこれを述べたとき、私は「他人を真似しないで、正しいことをしてください」と率直に言われました。これはおそらく私が言われたかもしれない最も有用なものです。すでにチェックインされているコードが受け入れられない場合、何が正しいか、何が間違っているかをどのように伝えるのですか？混乱の原因が基礎となるコードに由来するものであった場合、私はそうは思わない 私はこの状況で本当に選び抜かれ、イライラしていると感じています。期待される標準に従うことについてはずっと良くなったし、たとえば、以前は行方不明だったエラーチェックを追加するためにコードの一部をリファクタリングするとき、私はそうしなかったと言われただけでイライラするエラーを十分に冗長にします（これに基づいてブランチは拒否されました）。そもそも追加したことがない場合はどうなりますか？それがとても間違っていた場合、どのようにして最初にコードに入りましたか？だからこそ、私はあまりにもひたむきだと感じています。私は常にこの既存の問題のあるコードにぶつかって、模倣したりリファクタリングしたりしています。私がそれを模倣するとき、それは「間違っている」。そして、それをリファクタリングするなら、私は十分なことをしないことを恐れる（そして、私がずっと行くなら、バグを導入するなど）。繰り返しますが、これがこのような問題である場合、コードがコードベースにどのように侵入するかわかりませんが、 とにかく、どうすればこれに対処できますか？私は女性だとトップで言ったことを覚えておいてください、そして、これらの人は他の人のコードをレビューしているとき、通常は礼儀について心配する必要はないと確信しています、そしてそれは私に生産性を低下させています。私はそれについて上司に話したら、彼は私が環境などを扱うことができないと思うだろうと心配しています。

39 code-quality  self-improvement  teamwork  code-reviews 

私は小さなチームで働いており、別の小さなチームと一緒に大規模な新しいプロジェクトに取り組み始めます。他のチームは現在、長年取り組んでいるレガシーシステムで作業しています。 マネージャーは、私のチームの開発者が、レガシーシステムで作業している開発者を置き換えるために、数か月ごとに交代することを決定しました。そうすれば、他のチームは新しいプロジェクトに取り組み、新しいシステムをよりよく理解できるようになります。 2〜3か月ごとにプロジェクトから開発者を交代することの利点と欠点（ある場合）を知りたい。 これは「主任開発者を交代させるのは良い考えなのか悪い考えなのか」と似た質問であることを知っています。、しかしその質問は主任開発者に焦点を当てています。この質問は、プロジェクト全体でチーム全体をローテーションすることに関するものです（新しいプロジェクトの技術リーダーはローテーションされる場合とされない場合があります。まだわかりません）。

38 project-management  teamwork  team 

私は質問（チームのコードカウボーイ）を見つけましたが、それは私が抱えている問題よりも「Ninja Coder」に関連していました。 「カウボーイコーダー」の純粋に生きた例であるチームメンバーがいます。人を変えることはできないことを理解していますが、彼が「カウボーイコーダー」のように振る舞うのをやめる方法ですか？ 彼はチームの意見を聞くことを拒否し、最近、コードレビュー、ユニットテスト、実装の詳細の共有などを停止しました。 はい、彼は高速に「コーディング」しますが、彼のコードは単なるバグ生成プログラムです。他のチームメンバーと私は「バグ修正フェーズ」にあり、バグの80％は彼のコードに起因しています。私は彼のバグを修正したくありません。そして、経営陣は盲目であるか、これを見たくないか、多分彼らは彼の「スピード」を好む。 私（彼の上司ではなく、年齢の若い同僚として）がそれについて何かできる方法はありますか？ このカウボーイコーダーを武装解除するにはどうすればよいですか？ 私はこのプロジェクトを本当に気にかけている最後の人だと感じています。

37 development-environment  teamwork  communication  cowboy-coding 

残念ながら、レガシーの理由でドキュメントがほとんどないソフトウェアチームのシニアメンバーとして、新入社員を快適にするためにできることは何ですか？ 私は、特定の欠陥/機能要求についての人とのデバッグセッションを計画しており、コードベースに精通させています。ただし、コードベースは実に大きく、この方法で人に公開できるのは一定量のコードだけです。 新規採用者が最近の卒業生または経験豊富な専門家である場合のいずれかの場合の提案を探しています。

36 teamwork  knowledge-transfer 

チームでは、ソース管理としてGitを使用しています。ほとんど独立しているが重複するコード領域がいくつかあります。最近、ソース管理を使用するためのワークフローとアプローチについて議論してきました。機能ブランチワークフローの使用を促進するときに出てくる不満の1つは、人々がしばしば複雑なマージ競合に遭遇し、それが誤って解決されることです。複雑なことで、私は「解決方法については明らかではない」という意味です。これを踏まえて、「プルリベース」ベースのワークフローなど、他のワークフローがより積極的に使用されています。 機能分岐アプローチの支持者として、私は実際に苦情を受け取っていません。はい、ローカルの機能ブランチをマスターまたはどこからでも最新の状態に維持する必要がありますが、それが唯一の本当の問題です。マージが常に複雑で、二次的な影響がある場合、それはGitの問題ではなく、チームワークの問題であると考えています。 これを考えるのは正しいですか？複雑なマージの競合は、良いものか悪いものかの兆候ですか？

35 version-control  git  teamwork 

私は3人の開発者がいる小さな開発グループで働いています。私たちは大まかに管理されており、チームには構造がありません。指定されたチームリーダーは存在せず、マネージャーはかなり人手がありません。シニア開発者は4年間会社に在籍しており、その間にシステムのセットアップと実行の維持に多大な貢献をしました。彼は非常に優れた開発者ではありませんが、優れたカウボーイコーダーであり、私が決してできない方法でネットワークを理解しています。彼は年長であり、私たちの仕事よりも自分の仕事に優れていると感じているため、「主任開発者」と「システムアーキテクト」の役割を果たしました。 私の問題は、彼がいつも辞めると脅していることです。昨日彼は私に、6週間後に401kの権利確定プログラムでさらにレベルを上げ、その後退職することを通知しました。私が彼に理由を尋ねたとき、彼は私たちのマネージャー（男性）とチーム（私であるチーム）が彼を「非難する」からだと言った。彼は、自分の年功序列に基づいて開発マネージャーになったことに「ふさわしい」と感じています。私はバグ/問題追跡ソフトウェアのようなものを押し続け、仕事が得意なので、彼は私を好きではありません。 彼が辞めると脅した最後の時、私は彼を真剣に受け止め、彼が去る周辺で私の仕事を計画し始めました。それから彼は考えを変えて、私がやっていることは彼の責任だと言った。彼は私と彼の気性を失い、緊張はしばらくの間本当に高かった。 以下は、私がこの状況にアプローチしたさまざまな方法の一部です。 彼が求めていることをしてください。これは緊張を軽減しますが、その後何も行われず、ユーザーは動揺します。 コントロールを取り、物事を成し遂げます：これはユーザーを幸せに保ちますが、それから彼は私に怒り、シャットダウンします。彼は私が自分でそれをするために入らなければならないシステムへのアクセスを私に与えません。 上級管理職との緊密な連携：彼は上級管理職に敬意を払っていません。彼らは彼が会社を辞めることを望まないので、彼らは彼を甘やかしています。 まだ前進していないオプションの1つは、会社を辞めることです。1年はまだそこにいませんが、辞めるという考えは好きではありません。全体として、仕事は私のポジションのほとんどの要件を満たしています。 アイデア？提案？会話？検討していないオプションはありますか？ 更新5/11/2012： 私は最終的に去ることに決めました。それは良い決断でした。元の投稿と今では良くなったが、それでも私は良い開発者であるとは思っていませんでした。私は彼の知識を尊敬していますが、彼と一緒に仕事をする必要がなくなってうれしいです。

35 teamwork  management 

継続的な統合に関連するオーバーヘッドがあります。たとえば、セットアップ、再トレーニング、認識アクティビティ、データの問題であることが判明した「バグ」を修正するための停止、懸念事項のプログラミングスタイルの強制などです。 継続的インテグレーションは、どの時点でそれ自体に費用がかかりますか？ 編集：これらは私の発見でした セットアップは、VSSまたはTFSから読み取り、Nantを備えたCruiseControl.Netでした。 失敗のいくつかの理由を以下に示しますが、これらはセットアップとは関係ありません。 調査コスト：赤信号の原因がコード、データ品質、またはインフラストラクチャの問題（ネットワークの問題、ソース管理からのタイムアウトの読み取り、サードパーティサーバーなど）の真の論理的不整合によるものかどうかの調査にかかった時間ダウンなど） インフラストラクチャに対する政治的コスト：テスト実行の各メソッドに対して「インフラストラクチャ」チェックを実行することを検討しました。ビルドサーバーを交換する以外、タイムアウトの解決策はありませんでした。赤テープが邪魔になり、サーバーの交換はありませんでした。 単体テストの修正コスト：データ品質の問題が原因の赤信号は、誤って記述された単体テストの指標になる可能性があります。そのため、データに依存する単体テストは書き直され、不良データによる赤信号の可能性を減らしました。多くの場合、ユニットテストを正確に実行できるように、必要なデータがテスト環境に挿入されました。データをより堅牢にすると、このデータに依存している場合、テストはより堅牢になります。もちろん、これはうまくいきました！ カバレッジコスト、つまり、既存のコードの単体テストの記述：単体テストカバレッジの問題がありました。単体テストのないメソッドが何千もありました。そのため、それらを作成するにはかなりの工数が必要になります。これはビジネスケースを提供するには難しすぎるため、今後、新しいパブリックメソッドにはユニットテストを使用することにしました。単体テストを行わなかったものは、「潜在的に赤外線」と呼ばれました。ここで重要な点は、静的メソッドは、特定の静的メソッドがどのように失敗したかを一意に判断する方法の重要なポイントであったということです。 オーダーメイドのリリースのコスト：Nantスクリプトはこれまでのところのみです。たとえば、EPiServer、CMS、またはUI指向のデータベース展開用のCMS依存ビルドにはあまり役立ちません。 これらは、1時間ごとのテスト実行と夜間のQAビルドのためにビルドサーバーで発生した問題の種類です。ビルドマスターはリリース時にこれらのタスクを手動で実行できるため、特にワンマンバンドと小さなビルドでこれらが不要であることを楽しませます。したがって、シングルステップビルドは、私の経験ではCIの使用を正当化するものではありません。より複雑なマルチステップビルドについてはどうですか？これらは、特にNantスクリプトなしでは、構築するのが面倒です。したがって、作成したとしても、これらはもはや成功しませんでした。赤信号の問題を修正するコストは、利益を上回りました。最終的に、開発者は興味を失い、赤信号の妥当性を疑問視しました。 公平に試してみましたが、CIは高価であり、単に仕事を終わらせるのではなく、周辺で多くの作業をしていると思います。アラームシステムを導入および保守するよりも、大規模なプロジェクトを大量に作成しない経験豊富な開発者を採用する方が、費用対効果が高くなります。 これらの開発者が去っても、これは事実です。優れた開発者が辞めるかどうかは問題ではありません。彼が従うプロセスにより、要件仕様、設計仕様を記述し、コーディングガイドラインに準拠し、コードが読みやすくなるようにコメントすることが保証されます。これはすべて見直されます。これが発生していない場合、彼のチームリーダーは仕事をしていません。これは、マネージャーなどが引き受ける必要があります。 CIが機能するためには、単体テストを作成し、完全なカバレッジを維持し、大規模なシステムの機能するインフラストラクチャを確保するだけでは不十分です。 結論：リリース前にできるだけ多くのバグを修正することがビジネスの観点からも望ましいかどうか疑問に思うかもしれません。CIには、顧客がUATで特定できる少数のバグをキャプチャするための多くの作業が含まれます。または、保証期間が期限切れになった場合、クライアントサービス契約の一部として会社が修正の支払いを受けることができます。

34 teamwork  continuous-integration 

私の質問をする前に、状況を説明しなければなりません。 私は会社でジュニアソフトウェアエンジニアとして働いています。私の開発を終えてコミットしたいとき、先輩の一人はいつも私を止めます。 彼はいつも彼がそれをレビューするのを待って欲しい。通常、彼はいくつかのバグを見つけて、いくつかの最適化を行うため、これは問題ありません。 ただし、期限までにコードをコミットする必要があります。終わったら彼に電話して、終わったと言います。彼は通常遅れる。私のコードも遅れています。 私の質問は、どうすればいいですか？レビューを待つ必要がありますか？ 編集：質問への追加。もう1つ問題があります。 コーディングするときは自由になりたいです。開発の自由に対する信頼をどのようにして得ることができますか？ いくつかの説明： これについて彼と話しました。しかし、それは助けにはなりませんでした。既に課題追跡を使用していますが、レビューのタスクはありません。開発タスクとテストタスクのみがあります。

32 teamwork  code-reviews  estimation  project-planning 

私たちのプロジェクトヘッドは、天才的なソフトウェアアーキテクトであり、一般的には穏やかで思いやりのある人であり、自然のオタクであり、声で繊細です。しかし、時々、私たち（私のチームメイトと私）は意見が異なります-特にソフトウェアアーキテクチャの問題、システム設計の問題、UIの問題など、リーダーと。 意見の違いをいつ、どのように（もしあれば）表現すべきですか？

31 teamwork 

私は最近、厳しい状況に陥っています。ほぼ8か月間、プログラミング仲間とのゲームに取り組んでいます。私たちは両方とも昨年の8月頃にプログラミングの初心者としてスタートしました。彼は2年目のCS学生であり、私は業界のITサポート技術者であり、多数の書籍とオンラインサブスクリプションを持つ独学のプログラマーです。 私が常に見てきた問題は、コードの塊を書き出すと、多くの場合、一緒に少しハッキングされ、多くの失敗があり、それが私たちの新しいコンセプトである場合、素朴なソリューションでいっぱいです。これは問題ありません。学習中です。最初のパスまたは2回目のパスで、両方のコードが少しハッキングされることを期待しています。問題は、ハッキングされたこれらの動作を実際に修正およびリファクタリングするときに発生します。 私のパートナーは、動作を開始した瞬間にエラーを見ることを露骨に拒否して、彼の新鮮な一緒に行動を保持します。構造の一部からほぼ完璧を主張して、コメントがあり、適切な名前のメソッドとフィールドがあっても、使用することさえできません。どんなに一生懸命努力しても、動作を完全に破壊することなく、それ以上の変更や動作の拡張を妨げる明白な欠陥を彼に見せることはできません。それらはすべて同じクラスに属する可能性があります。ハッキングされたソリューションは、常にハッキングされたままであり、設計が十分に検討されていないため、最初に考案およびテストされたときの設計はそのままです。 新しいコードを自分で作成するのと同じくらい多くの時間をベビーシッターに費やしています。私のパートナーは今夜それを失い、ベンチマーク、一般的な慣行、反論できない証拠に関係なく、彼のコードは彼が最初に作った方法のままであることを明らかにしました。あなたが何かをすることを避けたい理由について本全体が書かれていたとしても、彼はそれが単なる誰かの意見であると主張する彼らの妥当性を認めることを拒否するでしょう。 私は私たちのプロジェクトに強い関心を持っていますが、パートナーと一緒に仕事を続けられるかどうかはわかりません。私には3つの選択肢があります。 コンパイルの時点を過ぎて機能するコードベースを気にするのをやめ、かろうじてリンプしている動作を維持および解析しようとすることに対処します。物事が真剣に壊れ始めたら、彼はそれを見て、根本的に欠陥のあるデザインにただ絆創膏をかける以上のことをしようとするでしょう。 他のはるかに有能な個人によって10年前に見つけられた問題についての無限の議論を続けてください。 このプロジェクトでのプログラミングを停止し、コードの10,000行近くを放棄し、設計に時間を費やす無数の時間を費やして、自分で新しいプロジェクトを見つけてみてください。 この人とこのプロジェクトを続ける価値があるかどうかを判断するには、どのようなアプローチを取ることができますか？または、どの要因が私の決定に影響を与えるべきですか？私たちは多くのコードを書きましたが、必要がない限りこれをあきらめたくありません。

30 code-quality  refactoring  teamwork  maintenance 

私は3〜4人のジュニア開発者のチームを率いています。私の仕事は、コードを書くことに加えて、後輩に監督と指導を提供することです。 しかし、私は開発者が自分の仕事で自律性をどれほど大切にしているのかを完全に理解しており、自分の考えやアルゴリズムをスプーンで提供することによって彼らの本質的な動機を破壊したくありません。私は彼らに彼ら自身の方法で問題を探求し、彼ら自身でそれについて考え、彼らが本当に乗り越えられない問題に直面しているときだけ私に来てほしい。 彼らが私に来たとき、時にはアルゴリズムが十分に堅牢ではないため、問題を解決するために完全に異なるアルゴリズムを提案する必要があります（私はシニアであり、私は彼らよりも多くを見てきました）。もちろん、私は彼らの感情を傷つけないようにこれを素敵な方法で説明し、私の解決策が彼らのものよりもはるかに優れていることを優しく概説します。 それでも、彼らは私の提案を受け入れたがらない場合があります。その理由の1つは、独自のアルゴリズムに多大な投資をしているからです。どこにも行きません。しかし、私の心の奥深くでは、私のアルゴリズムが彼らのアルゴリズムよりもはるかに優れていることをよく知っているので、採用するだけです。 彼らが私の提案を採用しなかった場合、どうすればよいですか？彼らに自分の道をたどるように頼むべきなのか、それとも彼らに何度も頭を壁に叩きつけて、彼らが私に戻ってくるのを待つべきなのか？前者を実行すると独裁者になりますが、後者を実行すると貴重な開発時間がかかり、バグ修正コストが発生します。私は本当にここでジレンマに陥っています。

30 management  teamwork  team-leader 

私は同僚に単体テスト（およびテスト全般）の概念を紹介したいと思います。現在、テストはまったく行われておらず、実際にUIを介してタスクを実行して目的の結果を確認することにより、テストが行​​われています。ご想像のとおり、コードは正確な実装と非常に緊密に結合されています。クラス内にあり、システム全体で再利用されるコードがメソッド間でコピーおよび貼り付けされることさえあります。 要件が変更されたため、以前に書いたモジュールを修正するように依頼されましたが、それはかなり疎結合です（希望するほど多くはありませんが、他の多くの概念を導入することなく取得できます）。修正されたコードに単体テストのスイートを含めて、期待どおりに機能することを「証明」し、テストの仕組みを実証することにしました。コードの一部はすでに記述されているため、真のTDDをフォローしていませんが、作成する必要がある新しいコードについては、TDDの概念に従うことを望んでいます。 今、どうしてコードを書くのに1日か2日以上かかるのかと聞かれるのは避けられないだろう、なぜなら私がやり取りすることの一部はすでにシステムに存在しているからだ））でコードをチェックすると、この「テスト」プロジェクトとは何かを尋ねられます。テストの基本を説明することはできますが、他の人が理解する方法で実際の利点を説明することはできません（テストは自分でアプリを実行する必要があると考えているためです。 " か否か）。彼らは疎結合の概念を理解していません（疎結合されたものは何もないという事実から明らかです。私が書いたコード以外のインターフェースすらありません）。それを利益として使用しようとすると、おそらく「ハァッ」を得るでしょう。ある種の見た目であり、既存のいくつかのモジュールを作り直さずに、おそらく「プログラミング」ではなく時間の浪費と見なされるIoCコンテナを導入することなく、やりたいほどゆるくすることはできません。 誰も私がこのコードを指す方法についての提案を持っていますか？私のものが悪いことを除いて）またはそれは時間の無駄のように見えることなく、実際の価値を追加しませんか？

30 testing  unit-testing  teamwork