会社は特定のIDE=フラグに切り替えるように注文していますか？
私は最近急速に成長しているスタートアップに参加しました。過去3か月間で、開発チームは4名から12名に成長しました。これまで、開発チームは開発者が仕事をするために何をしていたかについて非常に laissez-faire でした。実際、私が最初にこの会社の魅力を感じたのは、ほとんどのプログラマーがLinux、または彼らの努力に最も適していると感じたOSを使用したことです。
今、議論なしに、誰もがEclipseに切り替えることになるという命令が出てきました。素晴らしいエディター。私はSublimeText2を好みますが、それは私の個人的な好みにすぎません。
明確にするために：私たちはバックボーンを使用するJSチームであり、Eclipseはバックボーンコードの理解が得意ではありません。これは、/ good/IDE（PHP Storm）を使用するチームのメンバーは、多くの検索を実行する必要があることを意味します。 -ctrl +クリックして戻る/進むだけでなく、3つのステップ-前のようなもの-おそらく生産性が15％減少し、楽しみが50％減少します...
これは赤旗ですか？開発者（MS以外）に、すでに定着していて生産的である場合に使用するIDEまたはツールセット）を伝えることは、気まぐれで不当に制御しているようです。
「今や、議論のない注文が降りてきて、誰もがEclipseに切り替えることになっています。」
thisは本当の赤旗だと思います。あなたのチームはソフトウェア開発の専門家であり、決定の影響を受けるチームですが、この注文の原因となったディスカッションでWordを言うことができませんでしたか？
先のとがった髪のボスによる過剰な管理のように聞こえます。意思決定者/チームは、その決定に関連する洞察を持っていますか？
意思決定者がそのような決定を行うのに十分な資格がある場合、開発チームの意見を求めないことには少なくとも2つの欠点があります。
チームは関与を感じていません。チームの関与は管理の優先事項である必要があります。 IDEなどの中心的な問題についての私の意見が求められるほど十分に評価されていないどこかで開発者として働きたくないさらに悪いことですが、その場合、その決定には確かな根拠が必要です。
ただし、経験豊富な経営陣は、この特定のコードの開発では100％機能しません。まったく興味深い洞察力を持っていない人々がナイーブであると仮定します。もちろん、それはマネージャが開発者が思いついたすべてのことを考えていたからかもしれませんが、知る唯一の方法は尋ねることです。
共通のプロジェクトで一緒に作業する場合、すべてのワークステーションでソフトウェアの編集/ビルド/デバッグに使用できるすべてのツールがあり、開発の約90％を実行するためのコアツールが、チーム。チームが成長し、誰もが彼の個人的なお気に入りのツールセットを使用する場合、その目標を達成することは困難です。より多くの人々、より多くの意見。また、必要以上にツールの数を増やすことができなければ、管理作業も簡単になります。
もちろん、開発者が自分のお気に入りのエディターを使用するように主張する場合、チームのメインエディター（あなたの場合はEclipse）でソースの外観や動作が異なっていないことを確認できれば問題ありません。 Bは開発者Aのソースを編集する必要があります。開発者Bは、ソースを効果的に変更できるように、Aの個人的なお気に入りのエディターを学ぶことを強制されるべきではありません。ただし、同じディスプレイの前で2人が時々一緒に作業する必要がある場合（またはペアプログラミングを行う場合）、選択したエディターが両方でよく知られていると、作業が簡単になることがよくあります。
ペアプログラミングでは、キーボードを使用するときに、画面の前にいる両方の当事者が同じスキルを持っているといいですね。また、プロジェクトでIDEに特別な構成が必要な場合は、誰でも同じように構成できることも知っておくと便利です。誰もが同じツールを使用すると、新しい開発者を始めるのが簡単になります。
しかし、これを最も効果的なものにしようと比較すると、それだけの価値はありません。
はい。経営陣は、自分よりもどのツールを使用する方が効率的かを判断するのに優れていると考えるのは少し危険です。
それ自体は危険信号ではありません。
時々経営陣は決定を下す必要がある。何かの標準化が必要な問題は、そのカテゴリに分類される傾向があります。私はかつて、標準を数年間ドリフトさせ、20以上の異なるSCMツールを持っていたクライアントで働いていました。異なる開発チームによる独立した選択から始まったものは、組織全体でのスキルの共有とコードのコラボレーションを大幅に妨げるロジスティックスの悪夢に変わりました。統合ビルドは..... er .....あまり統合されていなかった.....
さらに、それはすべての決定について全員に相談することは実用的でも必要もありませんです。これを実行する必要がある範囲は、組織の文化と決定の重要性/複雑さによって異なります。通常、次のような相談が少ないオプションのいずれかを選択します。
- 長所/短所について十分な知識があり、幅広い相談を必要とするほど重要な決定ではない場合は、自分で決定してください。
- 数人の主要な人物（おそらく、決定を下すのに最も適した上級開発者となるでしょう）に相談してください。
- 影響を受ける可能性のあるすべての人（メール、市庁舎の会議、チームの会議）に決定を下していることを伝えます。あなたが正しい決定は何であると思うかを言いますが、反対に新しい証拠が出てきた場合、あなたはこれを喜んで変更します。重要な見解がある場合は、個別に前に進むように招待する
- オプションを確認し、決定を推奨するサブチームを形成するように人々を招待します。それが本当に緊密な電話であり、答えがわからない場合は適切なオプションであり、関係者を決定に引き込んでもらいたい。
開発ツールのようなもの（これは潜在的に論争の的となる問題です）の場合、おそらく2の後に3または4を続けます。つまり、問題について個人的に話さない個人がいるはずですが、一方で重要な人々の意思決定に貢献する機会を得るでしょう。
私にとって本物の赤い旗は、間違った決定が下されたと強く感じた場合に発生します（間違った==は、お気に入りのツールが選択されないだけでなく、会社に害を及ぼします）。この問題が発生した場合、経営陣はどのように反応しますか：
- 良い経営陣はあなたの議論に耳を傾けます。フィードバックに心から感謝し、あなたが新しい洞察を生み出したイベントでの彼らの立場を再考します。彼らはまだあなたに同意せず、彼らの決定に固執するかもしれませんが、彼らはあなたが彼らと一緒にそれを提起したことを感謝し、なぜ彼らが彼らの決定に固執していると言う礼儀をします。彼らは将来的にそのような決定をする方法を変えるかもしれません、そしてあなたが良い点を作ったならばあなたが彼らに「尋ねる賢い人々」のリストにあなたを含めるかもしれません。
- 悪い経営者は防御的になります。「決定が下された」と言って、彼らが間違った決定をしたかもしれないという事実に直面することを避けるためのそのような戦術を言います。彼らはあなたを「トラブルメーカー」として見るかもしれません。経営に対するあなたの信仰がそうであるように、会社も苦しみます。これは本当の赤旗です！できるうちに出なさい！
Mavenまたは類似のものを使用している場合、どのIDEを使用しているかは問題ではありません。特定のIDEに関連付けられている場合があります。 Eclipseのように、依存しているプラグインがある場合。
IDEあなたは最も生産性が高いです。しかし、すでに述べたように、標準のIDEを使用することが理にかなっている場合があります。
私がこれまで関わってきたすべてのチームには、IDEと編集者：Eclipse、Netbeans、IDEA、VIM、Emacs、Textmate、RubyMineなど）の多様性がありました-これは決して問題ではありませんでした。
私にとってこれは、組織の高レベルで本当に重要なことについての誤解を物語っています。重要なのは、優れたコーダーに必要なことを実行させ、最も快適なツールを使用させることです。 IDE均一性は、オブジェクトアーキテクチャ、ユニットテスト、アルゴリズムなどの本質的な質問について行われる実際のコミュニケーションとはほとんど関係がありません。
同じIDEが次の人と同じであるということは、同じショートカットでコードを参照する方法と、コンパイル/構成がどのように設定されているかを両方とも知っていることを意味します。実際のコードの問題について。
見て、それは会社の他の要因に応じて住みやすいです。日常の作業には、いつでも独自のエディターを使用できます。そして、あなたのグループは素晴らしい文化を生み出す他の素晴らしいことをしているのかもしれません。しかし、必須のIDEは大きな失敗のIMOです。私にとって、もし[〜＃〜] i [〜＃〜]が会社にインタビューしていて、IDE私は許可されている使用するには、彼らの時間を丁寧に感謝します。
「企業に義務付けられた」IDEがインストールされていますが、それでも私の仕事の大部分は何でも行いますIDE IDEがソースファイルの編集に使用されたものを教えてください。
IDE vs. editor front ......ほとんどすべての言語で、私はstronglyを好むIDE（IntelliJ）があるためエディターよりもはるかに多くのことができます。ST2またはEmacsに戻したいことがいくつかありますが、日常のコーディングでは、両方のST2/Emacsがどれほど好きでも、IDEほぼ常に勝ちます。
our Ruby shop では、IDEチームのほとんどが楽しんでいる（RubyMine）を使用することを強く推奨しています。仕事をし、私たちはお互いにショートカットなどを教えることができます.
開発者は別のIDEを自由に使用できますが、選択する場合は、そのエディターでの確かなスキルが必要です。カスタムFooEditでプロジェクトをナビゲートしたりテキストを編集したりするのに苦労している人を見かけたら、RubyMineはそうです。
プログラマーが特定のIDEの専門家である場合は、それを使用する必要があります。彼らがどのIDEの専門家でもない場合、プログラミング言語またはチーム内で非常に一般的なものはおそらく1つまたは2つあり、それを学ぶことはおそらく理にかなっています。
IDEで標準化を余儀なくされることは恐ろしい考えのように聞こえます。
これは大規模な赤旗です。どの会社にもこのような愚かなアイデアがいくつかありますが、他の赤信号が続く場合はそのままにしてください。
一部の決定の背後にある動機が失われるのは簡単です-特に急速に成長しているチームでは。 Eclipseに移行する動機は、ほとんどの開発者がIDEを構成するだけで多くの時間を浪費しているようであり、会社の専門知識が限られていることです。
必要に応じてEclipseをセットアップし、お気に入りのエディターで作業を続けるために、Eclipseに移動するように指示します。 （会社がEclipse内に優れたツールのデプロイを開始した場合、段階的にEclipseに移行する必要があるかもしれません。）
レッドフラグ：そのような不合理な命令がいくつかある場合は、心配する前に待機します。
会社が特定のエディターやソフトウェアを開発者に一般的に強制する理由を検討する必要があります。私の偏執的な（私が探しているWordではないかもしれません）部分は、開発者にインストールを要求しているEclipseにある種の生産性追跡が追加されている可能性があると考えています。パラノイアが少ない（もう一度）と思うのは、これに製品ビルドツールを追加することに時間を費やしたことですIDEこれにより、誰もが同じボタンを押してコードブランチをテストおよびビルドした場合に、はるかに簡単になります。 。
とにかく私が言おうとしているのは、おそらく単なる官僚制以上のもの、または開発者の頭をいじる方法です。
確かにこれは悪い考えです。新しいツールの使い方を学ぶ必要があるため、チームの生産性が低下することは避けられません。そしてそれでも、彼らはすでに彼らが持っているツールほど効果的ではありませんgrok。
自分でいろいろなツールを試してみたので、いつか「ああ、このエディタは、<バグ/優先するツールとの相違点を挿入>」という煩わしさを感じていました。したがって、これは道徳的な欠点にもなります。
しかしもちろん、チーム全体で同じツールを使用するというプロもいます。設定、スクリプト、プラグインなどのすべてのものを共有します。これは、さまざまなツールセットでは不可能です。
一方で、誰もが自分の好みのソフトウェアを使用していれば、最後のビットは必要ありません。 ;）
スタートアップは一般的に、持続可能なビジネスモデルを理解するのに十分な長さの俊敏性を維持しようとしています。それがお金の部分を見つけたら、経営陣はビジネスを拡大するために動きます。一般的に、エンジニアリングプロセスが厳しくなり、初期の技術系従業員全員が辞任し始めます。
ご存知のように、実行するまで実際にどのようなコードが実行されるのかはわかりません。チューリングは、コンピューティングの初期の頃にそれを証明しました。つまり、ソフトウェアの作成に関しては、生産性を測定する意味のあるものは存在しません。しかし、経営者がその仕事をするためには、生産性が読みやすくなければなりません。あなたはコードを測定することができないので（そして人々は試しました-例えばコード行）、彼らは彼らが見ることができるものを測定します。プログラマーは、開発したソフトウェアより読みやすいです。典型的な管理チームは、これらのことを読みやすくするためにプログラマーを制御しようとします（実際の仕事をする代わりに、邪魔にならないようにします）。また、間違ったものを測定するため、うまく機能しません。
そうは言っても、疎結合のチームを使用すれば、長い道のりを進むことができます。 Githubの開発チームには約50人のスタッフがいて、ビジネス管理の教科書のすべてのルールを破っています。彼らは大丈夫そうです。バグは修正されます（最終的には）。機能が追加されます。火が消える。
彼らがお金を稼ぐ方法を理解することなく物事をスケールアップしようとしている場合、大きな赤い旗は何ですか。その時点で、あなたはあなたの権利が与えられていないオプションと助成金のどれだけが本当に価値があるのか不思議に思うようになりました。
Gitを使用していて、ブランチがダウンしている場合でも、お互いのエディターを使用する必要はありません。ツールセットを本当に理解できない場合は、ブランチをプッシュし、別の開発者にプルして動作させることができます。誰もが同じエディタを使用するように強制することは、見栄えを良くしたいが、実際の操作方法を理解していないビジネスヘッドからの注文のように聞こえます。
管理の観点からこれについて考えるならば、彼らがこれをしているかもしれない理由は、法令遵守のためです。同社は、使用されるすべてのツールが合法的に使用されていることを保証する責任があり、開発中の製品を妨げることもありません。 （一部のエディターは個人での使用は無料ですが、その他の目的で無料ではありません。）すべての開発者が使用する可能性のあるすべてのツールを監査するには、費用がかかる場合があります。スケジュールが厳しいプロジェクトでは、法務担当者から指示されたプロジェクトの後半の変更を最小限に抑えるために、どのツール/ライブラリなどを使用するかについて経営陣が慎重になることがわかりました。
セキュリティの高いプロジェクトでは、IDEが一時ファイルを保存する場所や、セッション間でどの情報を保存するかも懸念されます。
それはすべて、Eclipseを推奨する必要がある理由に依存します。誰もが異なる方法で構成しているために、開発者が環境のセットアップに問題を抱えている場合、ストレートジャケットを推奨する理由があるかもしれません。しかし、誰もが望むものをすべて使用して幸せで生産的であった場合、クリエイティブプロセスに深く関与している何かに変更を課す理由はほとんどありません。
Eclipseは単なるエディターではありません。コードの編集にはお気に入りのエディターを使い続け、ソース管理、デバッグ、その他企業が義務付けたワークフローで必要なものは何でもEclipseに頼ることができます。
最後にもう1つ、このレベルでのプロセスの実施は、会社が開発チームを拡張する意向であり、新しいチームメイトがより早く生産性を上げることができるように、ある程度の構造を用意したいと考えていることを示している可能性があります。 Rails（またはDjango））を「意見のある」フレームワークと考えると、構造を持つことで、新しいアプリケーションをより簡単に理解できるようになります。
赤い旗は、単一のIDE /エディターがすべての開発者に強制されているほどではありませんが、この決定、特にどのIDE /エディターを使用するかの決定は、すべての開発者によって行われたわけではなく、おそらくどれもそれら！？！
確かに、開発者がコンセンサスに達するのが最善です。特に、少なくともどのエディター/ IDEで決定を下すのに最も適しているかは明らかです。準拠する十分な理由があり、その決定は管理の好みを考慮に入れるべきですが、どのエディター/ IDEがすべての開発者の決定であるはずです。
12人の開発者に投票してもらうのは簡単です。確かにそれをするのに十分な時間がありました！結論はとにかく苦痛で最終的にはEclipseになることさえあったかもしれませんが、その場合の要件を「レッドフラグ」としてラベル付けすることははるかに議論の余地があります。
SublimeText2を入力しながらEclipseを「使用」できます。
つまり、プロジェクトにEclipseをインストールして構成し、それに慣れることで、たとえばペアプログラミングの場合にも同じように快適に使用できるようになります。並列セットアップを維持するのに過度の時間がかからず、自分自身をコードから切り離さない限り、コミットしたコードの一部を実際に入力するのにどのエディターを使用するかは誰も気にしません（または少なくともすべきではありません）。標準開発環境。