特定のIDEに切り替えるという会社の注文は危険ですか？[閉まっている]

私は最近、急成長しているスタートアップに参加しました。過去3か月で、開発チームは4から12に成長しました。これまでは、開発者が作業に使用していたものについて非常に自由放任主義でした。実際、私が会社について最初に魅力的に感じたものの1つは、ほとんどのプログラマーがLinux、または彼らの努力に最も適していると感じたOSを使用したことです。

今では、議論なしに、皆がEclipseに切り替えることになっています。素晴らしいエディター。私はSublimeText2を好みますが、それは私の個人的な好みです。

明確にするために、私たちはBackboneを使用するJSチームであり、EclipseはBackboneコードの理解が得意ではありません。これは、/ good / IDE（PHP Storm）を使用するチームのメンバーは、多くのsearch-find-oh-wait-where-was-I-three-steps-agoのようなことを何度も実行する必要があることを意味します単にCtrlキーを押しながらクリックして戻る/進むのではなく、おそらく生産性を15％、楽しさを50％低下させます...

これは赤旗ですか？開発者（MS以外）が既に定着し、生産的である場合に使用するIDEまたはツールセットを伝えることは、気まぐれで不合理に制御しているようです。

「誰もがEclipseに切り替えるということで、議論なしに今や命令が下されました。」

これは本当の赤旗だと思います。あなたのチームは、ソフトウェア開発の専門家であり、決定の影響を受けるチームですが、この順序になった議論で言葉を言うことができませんでしたか？

先のとがった髪のボスが過剰に管理しているように聞こえます。意思決定者/チームは、その決定に関連する洞察を持っていますか？

意思決定者がそのような決定に対して十分な資格を持っていることを考えると、開発チームの意見を求めないことには少なくとも2つの欠点があります。

• チームは関与を感じません。チームを巻き込むことが管理の優先事項である必要があります。IDEのような中心的な問題についての私の意見が求められるほど評価されていない場所で、開発者として働きたいとは思いません。誰かの意見を求めてからそれを決定することはより悪いかもしれないことを認めましたが、その場合、私はその決定の確固たる理論的根拠を期待します。

• ただし、経験豊富な経営陣は、この特定のコードの開発では100％動作しません。興味深い洞察をまったく持っていない人はナイーブだと仮定します。もちろん、マネージャーが開発者が思いつくすべてを考えていたのかもしれませんが、知る唯一の方法は尋ねることです。

共通のプロジェクトで一緒に作業する場合、すべてのワークステーションでソフトウェアを編集/ビルド/デバッグするために使用できるすべてのツールがあり、開発の約90％を行うためのコアツールがチーム。あなたのチームが成長し、誰もが彼の個人的なお気に入りのツールセットを使用している場合、その目標を達成することは困難です-より多くの人々、より多くの意見。また、ツールの数が必要以上に増えないようにすると、管理作業も簡単になります。

もちろん、ある開発者が自分のお気に入りのエディターを使用することを主張する場合、チームのメインエディター（Eclipseの場合）でソースの外観や動作が異なることを確認できる限り、それは大丈夫かもしれません。 Bは、開発者Aのソースを編集する必要があります。開発者Bは、ソースを効果的に変更できるようにするために、Aの個人的なお気に入りのエディターを学習する必要はありません。ただし、2人が同じディスプレイの前で時々一緒に作業する（またはペアプログラミングを行う）必要がある場合、選択されたエディターが両方でよく知られている場合、物事はしばしば簡単になります。

ペアプログラミングのために、キーボードを使用するときに画面の前にいる両者が同じスキルを持っていると便利です。IDEでプロジェクトに特別な設定が必要な場合、すべての人に対して同じ方法で設定されることも知っておくと便利です。ツールが誰にとっても同じであれば、新しい開発者を開始するのは簡単です。

しかし、あなたがそれを最も効果的にしようとすることと比較すると、それは本当に価値がない

はい。経営陣は、自分よりも効率的なツールを判断するのが自分自身であると判断するのは少々危険です。

それ自体は危険ではありません。

時には経営陣が決定を下す必要があります。何かの標準化を必要とする問題は、そのカテゴリに分類される傾向があります。私はかつて、標準が数年間ドリフトすることを許可していたクライアントで働いていましたが、20以上の異なるSCMツールがありました。さまざまな開発チームによる独立した選択として始まったものが、組織全体でのコードのスキルとコラボレーションの共有を大幅に妨げる物流上の悪夢に変わりました。統合ビルドは..... er .....あまり統合されていません.....

さらに、すべての決定について全員に相談することは実用的でも必要でもありません。これを行う必要がある範囲は、組織の文化と決定の重要性/複雑さに依存します。通常は、以下の相談の少ないオプションのいずれかを使用します。

1. 賛否両論について十分な知識があり、幅広い協議を必要とするほど重要な決定ではない場合は、自分で決定してください。
2. いくつかの重要な個人（おそらく、決定を下すのに最も適した上級開発者）に相談してください。
3. 影響を受ける可能性のあるすべての人（メール、タウンホール会議、チーム会議）に意思決定をしているという事実を提起します。あなたが正しい決定であると思うが、新しい証拠が反対に現れた場合、あなたはこれを変更しても構わないと思っていると言ってください。重要な意見がある場合は、個々に前に出てくるように人々を招待する
4. サブチームを形成してオプションを確認し、決定を推奨するように人々を招待します。それが本当に密接な電話であり、答えがわからず、関係者を決定に引き入れたい場合、良い選択肢です。

開発者ツール（潜在的に論争の多い問題）のようなものについては、おそらく2に続けて3または4のいずれかを行います。つまり、この問題については個人的に話さない人もいますが、主要な人々が意思決定に貢献する機会を得ます。

間違った決定が行われたと強く感じた場合、本当の赤旗は周りにあるでしょう（間違った==それはあなたのお気に入りのツールが選ばれなかったのではなく、会社に害を及ぼします）。この問題を提起した場合、管理はどのように反応しますか：

• 優れた経営陣はあなたの議論に耳を傾けます。フィードバックに心から感謝し、新しい洞察を集めた場合には彼らの立場を再考してください。彼らはまだあなたに同意していないかもしれず、彼らの決定に固執するかもしれませんが、彼らはあなたが彼らと一緒にそれを提起したことを感謝し、あなたが彼らが彼らの決定に固執している理由を言うのを礼儀正しくします。彼らは将来そのような決定をする方法さえ変えるかもしれません、そして、あなたが良い点を作ったなら、「尋ねる賢い人々」のリストにあなたを含めるかもしれません。
• 悪い経営者は、「決定が下された」と言って、彼らが間違った決定をしたかもしれないという事実に直面することを避ける他のそのような戦術を言うでしょう。彼らはあなたを「トラブルメーカー」とみなすかもしれません。経営に対するあなたの信仰がそうであるように、会社も苦しんでいます。これは本当の赤旗です！できる限り出て行け！

mavenまたは類似のものを使用している場合、使用しているIDEは重要ではありません。依存するプラグインがある場合、Eclipseのような特定のIDEに関連付けられている場合があります。

最も生産性の高いIDEを選択できるはずです。しかし、すでに述べたように、標準IDEを使用することが理にかなっている場合があります。

「企業に義務付けられた」IDEをインストールしますが、ほとんどの作業は必要なIDEで実行します。ソースファイルの編集に使用されたIDEが誰にもわからないようです。

IDE対エディターの面では、ほとんどすべての言語で、エディターよりもはるかに多くのことができるため、IDE（IntelliJ）を強く好みます。ST2またはEmacsに戻すこともありますが、日々のコーディングでは、ST2 / Emacsの両方がどれほど気に入っていても、ほとんどの場合IDEが勝ちます。

私がこれまでに参加したすべてのチームには、Eclipse、Netbeans、IDEA、VIM、Emacs、Textmate、RubyMineなどのIDEとエディターが多数ありました。これは決して問題ではありませんでした。決して。

私にとって、これは本当に重要なことに関して、組織の高いレベルでの誤解を表しています。重要なのは、優秀なコーダーに必要なことをさせ、最も快適にするツールを使用させることです。IDEの均一性は、オブジェクトアーキテクチャ、ユニットテスト、アルゴリズムなどの重要な質問について行われる実際のコミュニケーションとはほとんど関係がありません。

次の人と同じIDEを持っているということは、同じショートカットを使用してコードを参照する方法と、コンパイル/構成の設定方法の両方を知っていることを意味します。実際のコードの問題について話すときには、どれも重要ではありません。

会社のその他の要因にもよりますが、住みやすいです。日々の作業には、いつでも好みのエディターを使用できます。そして多分あなたのグループは素晴らしい文化を作る他の素晴らしいことをやっています。しかし、義務付けられたIDEは大きなミスステップIMOです。私にとっては、あれば、私は会社に面接し、彼らは私がされたIDEを私に知らせ許可使用することを、私は自分の時間のために丁寧にそれらに感謝します。

では、私たちのRubyショップがあり、我々はそれが仕事をしていません知っているので、チームのほとんどが楽しんでIDE（ルビーマイン）を使用するように強く勧告だと私たちはお互いのショートカットなどを教えることができます

開発者は別のIDEを自由に使用できますが、選択する場合は、そのエディターで確かなスキルを持っている必要があります。プロジェクトをナビゲートしたり、カスタムFooEditでテキストを編集したりするのに苦労している人がいる場合、RubyMineはそうです。

プログラマが特定のIDEの専門家である場合は、それを使用する必要があります。IDEの専門家でない場合、おそらくプログラミング言語またはチーム内で非常に一般的な1つまたは2つがあり、おそらくそれらを学習するのは理にかなっています。

IDEでの標準化を余儀なくされることは、ひどい考えのように聞こえます。

企業が開発者に対して特定のエディターまたはソフトウェア全般を強制する理由を調べる必要があります。私の偏執的な（おそらく私が探している言葉ではない）部分は、開発者にインストールを求める日食に何らかの生産性追跡が追加される可能性があると考えています。ずっと妄想的（もう一度）考えたのは、このIDEに製品ビルドツールを追加するのに時間を費やしたため、全員が同じボタンを押してコードブランチをテストおよびビルドすれば、作業がはるかに容易になるということです。

とにかく私が言おうとしていることは、おそらく単なる官僚主義以上のものであり、開発者の頭をいじる方法です。

これは大きな赤旗です。どの会社にもそのような愚かなアイデアがいくつかありますが、他の危険信号が出続けている場合はそのままにしてください。

特に急速に成長しているチームの場合、いくつかの決定の背後にある動機が失われやすくなります。Eclipseに移行する動機は、ほとんどの開発者がIDEを構成するだけで多くの時間を浪費しているように思われ、会社に関する専門知識が限られているという事実だけかもしれません。

必要に応じてEclipseをセットアップする必要がありますが、お気に入りのエディターで作業を続けることを意味するために、Eclipseに移動するように命じます。（会社がEclipse内にクールなツールのデプロイを開始する場合、徐々にEclipseに移行する必要がある場合があります。）

レッドフラッグ：心配する前に、このような不合理な命令がさらにいくつかある場合、私は待つでしょう。

新興企業は一般的に、持続可能なビジネスモデルを把握するのに十分なほど俊敏性を維持しようとしています。お金の部分を把握すると、経営陣は事業を拡大するために動き出します。一般的に、エンジニアリングプロセスが強化されるにつれて、初期のハイテク従業員全員が退職し始めます。

ご存知のように、実際に実行するまで、コードが実際に何をするのかわかりません。チューリングは、コンピューティングの初期にそれを証明しました。これは、ソフトウェアの作成に関しては、生産性の有意義な尺度というものは存在しないことを意味します。ただし、経営陣が仕事をするためには、生産性が読みやすいものでなければなりません。コードを測定することはできないので（そして人々が試したコード行など）、彼らは見ることができるものを測定します。プログラマは、開発するソフトウェアよりも読みやすいです。典型的な管理チームは、これらのことを読みやすくするためにプログラマーを制御しようとします（実際の仕事をする代わりに：邪魔にならないようにします）。そして、彼らは間違ったものを測定するので、それはあまりうまくいきません。

そうは言っても、疎結合のチームとはまだ長い道のりを歩むことができます。Githubの開発チームには約50人の従業員がおり、ビジネス管理の教科書のすべての規則を破っています。彼らは大丈夫なようです。バグは（最終的に）修正されます。機能が追加されます。火が消えます。

大きな赤旗は、彼らがお金を稼ぐ方法を考えずに物事を拡大しようとしている場合です。その時点で、あなたはあなたの未確定のオプションと助成金のどれだけが本当に価値があるのだろうと思いました。

確かにこれは悪い考えです。チームは新しいツールの使用方法を学ぶ必要があるため、生産性が低下することは避けられません。その場合でも、彼らはすでにツールと同様に効果的ではありません完全に理解します。

私は自分でさまざまなツールを試してきたので、いつか「このエディタは<好みのツールとのバグ/相違点を挿入>」といらいらします。したがって、それは道徳的な欠点にもなります。

しかしもちろん、チーム全体に同じツールを使用させるプロもいます。構成、スクリプツ、プラグインなど、あらゆるものを共有します。多様なツールセットでは不可能です。

一方で…誰もが自分の好みのソフトウェアを使用した場合、その最後のビットは必要ありません。;）

SublimeText2で入力しながらEclipseを「使用」できます。

これは、プロジェクトにEclipseをインストールして構成し、Eclipseの速度を上げて、ペアプログラミングなどで使用する場合と同じように快適に使用できることを意味します。並列設定を維持するのに過度の時間がかからず、あなたが自分から切り離されない限り、誰がコミットしたコードを実際に入力するのに実際にどのエディターを使用したか気にしません標準開発環境。

Gitを使用していて、分岐がダウンしている場合、とにかくお互いのエディターを使用する必要はありません。彼が本当にあなたのツールセットを理解できない場合、ブランチをプッシュし、別の開発者にそれをプルさせて動作させることができます。すべての人に同じエディターを使用するように強制することは、スマートに見せたいが、実際に自分たちの操作方法を理解していないビジネスヘッドによる注文のように聞こえます。

管理の観点からこれについて考える場合、彼らがこれをしている理由は、法令順守のためです。会社は、使用するすべてのツールが合法的に使用されていることを保証する責任があり、開発中の製品を邪魔することもありません。（一部のエディターは個人使用は無料ですが、他の目的などは無料ではありません。）すべての開発者が使用する可能性のあるすべてのツールを監査するには、費用がかかる場合があります。スケジュールが厳しいプロジェクトでは、管理者は、プロジェクトの後半で法務担当者が指示する変更を最小限に抑えるためにどのツール/ライブラリーなどを使用するかについて慎重になります。

より高いセキュリティのプロジェクトでは、IDEが一時ファイルを保存する場所や、セッション間で保存される情報の懸念もあります。

それはすべて、Eclipseを推奨しなければならない理由に依存します。開発者が環境を設定するのに問題がある場合、誰もが物事を異なる方法で整理しているため、ストレートジャケットを推奨する理由があるかもしれません。しかし、誰もが自分が望むものを何でも使って幸せで生産性が高ければ、創造プロセスに深く関わっている何かに変更を加える理由はほとんどありません。

Eclipseはエディター以上のものです。お気に入りのエディターを使用してコードを編集し続け、ソース管理、デバッグ、および企業が義務付けているワークフローで使用するものをEclipseに依存することができます。

最後に、このレベルでプロセスを実施することは、会社が開発チームを拡大し、新しいチームメイトの生産性を向上させるために、ある程度の構造を整えることを望んでいることを示します。Rails（またはDjango）を「意見のある」フレームワークと考えるなら、新しいアプリケーションをより簡単に理解するのに役立つ構造を持っていることに気付くでしょう。

赤旗は、すべての開発者に単一のIDE /エディターが強制されるほどではありませんが、この決定、特にどのIDE /エディターを使用するかの決定はすべての開発者によって行われたわけではなく、おそらくそれら！？！

開発者がコンセンサスに達することは間違いありません。特に、少なくとも少なくともどのエディター/ IDEで決定を下すのに最適であるかは明らかです。準拠する正当な理由があるかもしれず、その決定は管理の好みを重視すべきですが、どのエディター/ IDEがすべての開発者の決定である必要がありました。

12人の開発者に投票してもらうのは簡単でしょう。確かにそれをするのに十分な時間がありました！結論はとにかく痛みを伴うものであり、最終的にはEclipseになってしまうかもしれませんが、その場合の要件を「レッドフラグ」とラベル付けすることは、さらに議論の余地があります。