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

私はバベル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 

私は自分自身をスーパースター開発者とは呼びませんが、比較的経験豊富な開発者です。私はコードの品質を高いレベルに保ち、コーディングスタイルを常に改善し、コードを効率的で読みやすく、一貫性のあるものにするよう努めています。また、品質と速度の両方のバランスが必要であることも理解しています。 これを達成するために、ピアレビューの概念をチームに導入しました。github pull-requestでのマージの2つの親指。素晴らしい-しかし、私の意見では、せきをせずに。 同じ同僚からのピアレビューコメントがよく見られます- 後にスペースを追加すると良いでしょう <INSERT SOMETHING HERE> メソッド間の不要な余分な行 docblock内のコメントの最後で完全停止を使用する必要があります。 今、私の観点から-レビュー担当者はコードの美学を表面的に見ており-実際にコードレビューを行っていません。化粧品のコードレビューは、ar慢/エリートのメンタリティとして私に伝わります。内容はありませんが、レビュアーが技術的に正しいため、あまり議論することはできません。上記の種類のレビューはもっと少なく、次のようなレビューをもっと見たいです。 循環的な複雑さを減らすには... 早く終了し、if / elseを避ける DBクエリをリポジトリに抽象化します このロジックは実際にはここには属していません 繰り返してはいけません-抽象と再利用 Xメソッドの引数として渡された場合はどうなりYますか？ これの単体テストはどこにありますか？ 私は、化粧品の種類のレビューを与えるのは常に同じ種類の人々であり、私の意見では「品質と論理に基づく」ピアレビューを与えるのは同じ種類の人々であると思います。 ピアレビューの正しいアプローチは（もしあれば）何ですか。そして、同じ人が基本的にコードをスキミングして、実際のコードの欠陥ではなくスペルミスや美的欠陥を探すことにイライラするのは正しいですか？ 私が正しい場合-化粧品の修正を提案することとのバランスで、同僚に実際にコードの欠陥を探すように奨励するにはどうすればよいですか？ 私が間違っている場合-私を啓発してください。実際に優れたコードレビューを構成するものについて、経験則はありますか？コードレビューとは何かという点を見逃していませんか？ 私の観点から言うと、コードレビューはコードの責任を共有することです。ロジック、読みやすさ、機能性をアドレッシング/チェックせずに、コードを評価するのは気が進まないでしょう。また、誰かがdoc-blockの完全な停止を省略したことに気付いたとしても、コードの強固な部分のマージをブロックすることはありません。 コードを確認するとき、500 Locあたり15〜45分かかります。これらの浅いレビューが実行しているレビューの深さであれば、これまで10分以上かかることは想像できません。さらに、浅いレビュアーからの評価はどれくらいの価値がありますか？確かに、これはすべての親指の重さが等しくないことを意味し、2パスのレビュープロセスが必要になる可能性があります。深いレビューのための1つの親指と「研磨」のための2番目の親指？

27 code-quality  code-reviews  leadership 

私は中規模企業のソフトウェアエンジニアです。TeamCityで実行されるかなり堅牢なテストプラットフォームがあります。すべてのチェックインで単体テストを実行し、毎日の単体テスト/ BVTを実行します。 問題は、大量の単体テストが失敗していることです。 ユニットテストが絶えず壊れていて、メンテナンスされていない場合、かなり頻繁にユニットテストの無意味さを引き出します。変更によってリグレッションが発生したかどうかを確認できないと、単体テストプラットフォームの価値のほとんどが失われます。 良い習慣の文化を作り出す種を植えたいです。壊れたときにテストを修正し、それらを価値あるものとみなし、他の作業とともにテストの修正を優先します。 私は賄ber（焼き菓子！）を試みましたが、単純に尋ねて、チームリーダーに話しました。誰もがそれは良いアイデアだと言いますが、私はそれについて何かをしている唯一の人であると思います。 他の人にテストの修正を奨励し、スプリント内でのテスト修正の優先順位付けを開始する最良の方法は何ですか？ これを尋ねる主観的な方法がなければ、どんなヒントでも喜んで受け入れます。

22 testing  unit-testing  tdd  culture  leadership 

SCRUMミーティングで、製品チームは、モバイルアプリで使用されるAPIの機能について議論していました。私たちは、画面がどのように見えるべきか、そしてどのキー要素を含むべきか（「レイアウト」）を示すモックアップを用意しました。 これと製品所有者との議論に基づいて、API応答のプロトタイプ（HAL + JSON）を作成しました。それは非常にシンプルで、HALに準拠したJSONであり、モックアップにあるものを表すことしかできませんでした。ビジネスマンは頻繁にアイデアを変更する傾向があるため、私は将来のアイデアに影響されることはなく、ミニマルなアプローチを取ることにしました。私の提案はチームによって却下され、7対1に投票されました。 チームは、レイアウトをより柔軟に配置できる、より複雑で非セマンティックな抽象json構造を使用することにしました。そのアプローチの欠点は、設計上、nullおよび空のプロパティを持つ可能性のある一連の均一なオブジェクトになってしまったことです。彼らはまた、A / Bテストを可能にすると良いと思っていましたが、そのような要件がなかったため、予測に基づいていました。 ほとんどの場合、スプリントの一部ではなく、モックアップで言及されていないことについて議論していました。説明された問題は、「将来のマーケティングがどうなるか...」、「ビジネスが私たちに望むならどうなるか...」でした。 私と製品所有者は経験豊富なプログラマーであり、過去にこの種の問題を見てきました。YAGNIとKISSの原則に従うよう努めています。チームの他のメンバーは少し経験が浅く、これらの原則を知っていますが、理解していないようです。 チーム全体が私たちにとってより重要であり、私たちはそれほど重要ではない何かをめぐって戦いたくなかったので、私たちは彼らの解決策に同意しました。しかし、そのようなことが今後のより複雑な議論の先例になり得るのではないかと心配していますか？そのような行動に対処する方法は？チームリーダーとして、私がもっとうまくできることはありますか？ 製品は初期段階のMVPであることに言及する価値があります。

13 design  scrum  team  leadership 

私は非常に奇妙な位置にいるように見えます。私は特定のプロジェクトの役職で「チームリード」を務めています。役職はソフトウェアエンジニアです。私のチームには4人の開発者がいて、そのうちの1人は別のプロジェクトで同様の役割を果たしていますが、現在は私のものが優先されているので、彼は私のものに取り組んでいます。また、2人のテスターがいます。そのうちの1人はマネージャーです。チームの別のメンバーは、完全に無関係な部門の一部である「顧客担当者」です。また、私は私のすぐ上にいるマネージャーを持っています。私のチームの一部であるテストのマネージャーの上にもいると思います。 私は自分の役割が正確に数回ある理由を明確にしようとしました。権限がある場合でも、どこから始めてどこで終わるかを把握するのは困難でした。私が現在取り組んでいる答えは、私がチームの「技術的なリーダー」であるということです。これは、製品コード自体に関係するアーキテクチャ、設計、およびプロセス/コーディング標準に関する技術的な決定について、私の権限を持っていることを意味するようです。 今日、何かが起こり、私がチームのメンバーの1人に委任したコードの結果が、Scrum Show-It-All-Offミーティングで会社の他のメンバーに示されました。顧客の代表者が披露します。今日私は本当に異議を唱えたことを披露し、何が起こったかについて発言したいかどうか誰も私に尋ねたことがありませんでした。要するに、ユーザーが次の方法でレポートに値を表示する機能を提供するために（「doc」単位、設計単位、丸めではなく丸め）、各順列のアクセスフィールドを提供しました。したがって、値は、丸められたドキュメント単位、丸められたデザイン単位、丸められていないドキュメント単位、丸められていないデザイン単位になります。ユーザーが処理したい各レコードには多くの値があり、各レコードはこの方法で並べ替えられます。 本当に嫌いです。 これを示した人々は、レポートに使用するAPIがExcelへのデータのエクスポートなどの処理と同じであることを確認したいと考えています。残念ながら、今、私たちは本当に、本当に悪いと思う方向にこの勢いを獲得しています。 次回の会議で少し動揺しましたが、これを行った2人に「なぜこの決定に関与しなかったのですか？」と尋ねました。これは今後も発生し続ける問題であり、私が率いるチームに参加して、私が参加したいかどうかを尋ねるのは難しいようです。時々私はしないで、彼らが思いついたものは何でもいいと思う。他の回は。人々が私に尋ねない限り、私の意見を必要とする何かが起こっていることを知ることさえ難しく、彼らは私にその機会を与えません。 残念なことに、私の権限は、「次回、私と話をせずに外出して自分でこのようなことをするとき、あなたは懲らしめられます」と人々に伝えることにまでは及びません。それは「PR」の問題であり、私の権限の範囲内ではないことは明らかです。私は他の誰かが喜んでいる場合、私はその種のがらくたに対処する必要はありませんので、実際には私で結構です。 しかし、今日、私のマネージャーは皆の前で（そういうことをするのも部分的には私のせいだと思う）、私はすべての決定に関与することはできず、委任する必要があると言った。 もちろん私は正しいと思う....私はいつもそうだ。私がBSだと思うことは言いません。この問題についてアプローチして、もっと良いアイデアがあるかどうかを尋ねるべきだったと思う。これは、実際には新しい機能の最初の段階であるため、現在提供する1つの値を決定することであり、必要に応じて将来さらにアクセスを提供するためのオプションについて議論することです。現在の実装を承認したり推奨したりすることは一度もなかったし、それが日の目を見るとは思わなかった。 問題は、私は不合理な人ですか？ 私たち二人はそれについて話し、私たち二人とも「ボールを落とした」ことに同意し、私たちは同じページにいるようです。月曜日の朝...チームで私の役割が明確になるようにしようとしています。そうすれば、デザインやタスクの変更が必要になる時期を判断することができます。私は提案を受け、同意するか、もっと深く見る必要があると判断します。それから、彼らが私に来ることができることを彼らが知っていることを確認するために私が取り組むことができるいくつかの他のビットがあります。

12 design  leadership 

約3か月前に、私たちの主要なWeb開発者およびデザイナー（同じ人物）が会社を辞めました。緑の牧草地が退職の理由でした。彼らに良いと私は言う。私の問題は、彼の部門が完全に文書化されていなかったことです。リードを離れてからの状況は厳しく、私たちが新しいプロジェクトを引用するために使用する理論的な知識と、彼が去ったために失った既存の製品の技術/実装に関する知識の両方がたくさんあります。私の通常の役割は、製品マネージャー（私たちの製品自体）およびプロジェクトベースのコンサルティング業務のビジネスアナリストです。私は過去1年間、自分でコーディングすることを学び、前進し続けるために努力しました。私のラップトップを開発マシンとしてセットアップするタスクを引き受けて、より簡単な機能リクエストのいくつかを実装し、私たちのチケットシステムに送信されるいくつかの簡単なバグを修正することを期待しています。しかし、新しいWindowsマシンを使用して、本番用アプリとシームレスに動作するように構成する方法は誰にもわかりません。 私は上司に、去った開発者とまだ連絡を取り、新しい開発者、ソフトウェアのインストール、必要なパッケージ、プロダクションアプリケーションサーバーにデプロイするプロセスなどを文書化して作成するプロセスを依頼するよう依頼しました。これは存在し、コンピュータを機能開発マシンとして機能させるために、私はホイールを回転させています。しかし、彼女はそのようなプロセスが存在する必要性を理解していないようです。どうやら、去ったものを交換した新しい開発者は、私たちの環境用に事前構成されたマシンを使用していたため、新しい開発者でさえ、別の開発者を追加すると新しいマシンをセットアップできませんでした。 私の質問は2つの部分です： 私たちの開発エコシステムの一部である新しいコンピューターを搭載して構成するプロセスが存在するはずであると想定するのは間違っていますか？ 私はひどい赤ちゃんですが、プロセスを理解して自分でドキュメントを作成する必要がありますか？

9 development-process  team-leader  leadership