Чи наказує компанія перейти на певну IDE червоним прапором? [зачинено]

Нещодавно я приєднався до швидко зростаючого стартапу. За останні 3 місяці команда розробників зросла з 4 до 12. До цих пір вони були дуже непростими щодо того, що розробники використовували для своєї роботи. Насправді одна з речей, яку я спочатку вважав привабливою для компанії, - це те, що більшість програмістів використовували Linux або будь-яку ОС, яку вони відчували, що найкраще відповідає їхнім зусиллям.

Тепер накази, без обговорення, зійшли, що всі повинні перейти на Eclipse. Прекрасний редактор. Я віддаю перевагу SublimeText2, але це лише мій особистий смак.

Просто для того, щоб було зрозуміло: ми є командою JS, яка використовує Backbone та Eclipse, просто не дуже добре розумієш код Backbone. Це означає, що тим, хто в команді, який використовує / good / IDE (PHP Storm), доведеться повертатися до багатьох видів пошуку-пошуку-о-чекай-де-був-я-три кроки тому замість просто клавіш Ctrl + клацання та використання назад / вперед - ймовірно, зменшення продуктивності, скажімо, на 15% і задоволення на 50% ...

Це червоний прапор? Здається, примхливий і необгрунтовано керує, щоб повідомити розробникам (не для MS), які IDE або набори інструментів використовувати, якщо вони вже влаштовані та продуктивні.

"Тепер накази, без обговорення , зійшли, що всі мають перейти на затемнення".

Я думаю, що це справжній червоний прапор. Ваша команда є експертом з розробки програмного забезпечення та тим, на кого це рішення вплине, і все-таки ви не отримали слова сказати в дискусії, в результаті якої був такий порядок?

Це звучить як надмірне управління кепськими волосами босами. Чи має людина / команда, яка приймає рішення, відповідну інформацію для цього рішення?

Зважаючи на те, що особи, які приймають рішення, є достатньо кваліфікованими для такого рішення, не запитуючи думку команди розробників, має як мінімум два недоліки:

• Команда не відчуває себе причетною. Залучення команди має бути пріоритетом для управління. Я не хотів би працювати девом десь там, де моя думка щодо таких центральних питань, як IDE, недостатньо оцінена, щоб навіть просити її. Зрозуміло, що попросити чиюсь думку, а потім прийняти рішення проти неї, може бути і гірше, але в такому випадку я очікую твердого обґрунтування цього рішення.

• Однак досвід управління не працює на 100% над розробкою цього конкретного коду. Якщо припустити, що люди, які взагалі не мають цікавого розуміння, було б наївно. Звичайно, може бути так, що менеджери подумали про все, що придумали дияволи, але єдиний спосіб знати - це запитати.

Доцільно, що коли ви працюєте разом над спільним проектом, на кожній робочій станції у вас є всі інструменти, доступні для редагування / збирання / налагодження програмного забезпечення, а основні інструменти для виконання близько 90% розробки відомі всім у команда. Цієї мети важче досягти, якщо ваша команда зростає і кожен використовує свій особистий улюблений набір інструментів - чим більше людей, тим більше думок. І адміністративна робота також стає легшою, якщо ви не дозволите зростати кількість інструментів більше, ніж потрібно.

Звичайно, якщо один розробник наполягає на використанні свого особистого улюбленого редактора, це може бути нормальним, якщо він може переконатися, що джерело не виглядає або поводиться по-іншому в головному редакторі команди (у вашому випадку Eclipse), тож якщо dev B повинен редагувати джерело розробника A, розробник B не повинен змушувати вчитися особистому улюбленому редактору A, щоб мати змогу ефективно змінювати джерело. Але будьте обережні, якщо обом доводиться час від часу працювати разом перед одним і тим же дисплеєм (або робити якесь парне програмування), справи часто простіше, якщо обраний редактор добре відомий обом.

Для парного програмування добре, якщо обидві сторони перед екраном мають однакові навички під час використання клавіатури. Приємно також знати, що якщо ваш проект має особливі потреби конфігурації в IDE, то він налаштований однаково для всіх. Почати нового розробника простіше, коли інструменти однакові для всіх.

Але якщо порівнювати це з просто намаганням бути найбільш ефективним, то насправді цього не варто

Так, це трохи червоний прапор, який керівництво вважає кращим суддею, з якими інструментами ви були б ефективнішими, ніж ви.

Це сам по собі не червоний прапор.

Іноді керівництву потрібно приймати рішення . Будь-які питання, які потребують стандартизації щодо чогось, зазвичай належать до цієї категорії. Я колись працював у клієнта, який дозволив нормам лежати протягом декількох років і у них було 20+ різних інструментів SCM. Те, що почалося як незалежний вибір різними командами розвитку, перетворилося на логічний кошмар, який сильно перешкоджав обміну навичками та співпраці над кодом по всій організації. Інтегрована збірка була ..... е ..... не дуже інтегрована .....

Крім того, не практично і не потрібно консультуватися з кожним для кожного рішення . Те, наскільки це потрібно зробити, залежить від культури організації та важливості / складності рішення. Зазвичай ви користуєтесь одним із таких менш важких варіантів консультацій:

1. Приймайте рішення самостійно, якщо ви маєте достатньо знань про плюси / мінуси, і це не досить важливе рішення, щоб вимагати широкої консультації.
2. Проконсультуйтеся з кількома ключовими особами (які, мабуть, будуть старшими розробниками, найбільш кваліфікованими для прийняття рішення).
3. Підкресліть той факт, що ви приймаєте рішення для всіх, хто може постраждати (електронна пошта, засідання ратуші, збори команди). Скажіть, що ви вважаєте правильним рішенням, але ви готові змінити це, якщо з'являться нові докази, що суперечать. Запропонуйте людям виступити окремо, якщо вони мають важливі погляди
4. Запропонуйте людям сформувати підгрупу, щоб переглянути варіанти та рекомендувати рішення. Хороший варіант, якщо це справді близький дзвінок, ви не знаєте відповіді, і хочете, щоб ті, хто бере участь, приймали рішення.

Щось таке, як інструмент для розробників (що є потенційним спірним питанням), я, мабуть, зробив би 2, а потім 3 або 4. Тобто обов'язково знайдуться люди, з якими я б не спілкувався особисто, але з іншого боку, більшість Ключові люди отримають шанс внести свій внесок у прийняття рішень.

Для мене справжній червоний прапор був би навколо, якщо ви сильно відчуєте, що було прийнято неправильне рішення (неправильне == це шкодить компанії, а не просто обраний ваш улюблений інструмент). Як реагує керівництво, коли ви порушуєте це питання:

• Хороше керівництво вислухає ваші аргументи, щиро дякує вам за відгуки та перегляне їхню позицію у випадку, якщо ви висунули нові відомості . Вони все ще можуть не погодитися з вами і, можливо, дотримуватимуться їх рішення, але вони оцінять, що ви підняли його з ними, і ви ввічливі сказати, чому вони дотримуються свого рішення. Вони можуть навіть змінити спосіб прийняття таких рішень у майбутньому, і якщо ви зробили хороші бали, можливо, ви включите вас до їх списку "розумних людей, щоб запитати".
• Погане управління отримає захисний характер, скажіть, що "рішення прийняте" та інші подібні тактики, щоб не стикатися з тим, що вони, можливо, прийняли неправильне рішення. Вони можуть сприймати вас як "порушника проблеми". Компанія страждає, як і ваша віра в управління. Це справжній червоний прапор! Вийди, поки зможеш!

Якщо ви використовуєте maven або щось подібне, це не має значення, який саме IDE ви використовуєте. Можуть бути випадки, коли один прив’язаний до конкретного IDE, як eclipse, якщо є плагіни, на які ви покладаєтесь.

Я думаю, ви повинні мати можливість вибрати свій власний IDE, IDE, у якому ви найбільш продуктивні. Однак, як я вже заявив, є випадки, коли є сенс використовувати стандартний IDE.

Я б встановив "корпоративний мандат" IDE, але все-таки робив би більшу частину своєї роботи в тому, що я хотів - IDE не так, як ніхто може сказати, що IDE використовувався для редагування вихідного файлу.

На IDE проти редактора перед ... для багатьох мов, я сильно вважаю за краще IDE (IntelliJ) , тому що це просто так набагато більше , він може зробити для вас , ніж редактор може. Є кілька речей, для яких я повертаюсь до ST2 або Emacs, але для щоденного кодування, незважаючи на те, як мені подобаються обидва ST2 / Emacs, IDE майже завжди виграє.

Кожна команда, у якій я коли-небудь був, мала безліч IDE та редакторів: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - це ніколи не було проблемою. Ніколи.

Для мене це говорить про непорозуміння на високому рівні організації щодо того, що насправді має значення. Найважливіше - дозволити хорошим кодерам робити те, що потрібно зробити, і використовувати інструменти, які роблять їх найбільш комфортними. Уніфікованість IDE має дуже мало спільного з реальною комунікацією, яка відбувається з важливих питань архітектури об'єктів, тестування блоків, алгоритмів тощо.

Наявність того ж IDE, що і наступний хлопець, означає, що ми обидва знаємо, як переглядати код за допомогою одних і тих же ярликів та як налаштована наша компіляція / конфігурація. Жоден з них не матиме значення, якщо говорити про реальні проблеми з кодом.

Подивіться, це зручно, залежно від інших факторів компанії. Ви завжди можете використовувати власний уподобаний редактор для щоденних речей. І, можливо, ваша група займається іншими чудовими справами, що створюють чудову культуру. Але мандатні ІДЕ - це величезна помилка ІМО. Для мене, якби я брав співбесіду з компанією, і вони повідомили мені, який IDE мені дозволяється використовувати, я б вдячно їм подякував за їх час.

У нашому магазині Ruby є наполеглива рекомендація використовувати IDE, яким користується більшість колективів (RubyMine), тому що ми знаємо, що це працює, і ми можемо навчити один одного ярликів і т.д.

Розробники можуть використовувати інший IDE, але ми вимагаємо, щоб вони мали міцні навички роботи в цьому редакторі, якщо вони захочуть. Якщо ми бачимо, що хтось бореться за навігацію по своєму проекту або редагує текст у власному спеціальному FooEdit, RubyMine для них це.

Якщо програміст є експертом у заданій IDE, вони повинні використовувати його. Якщо вони не є експертом у будь-якому IDE, напевно, є одна або дві, які є дуже поширеними для вашої мови програмування або для вашої команди, і, мабуть, має сенс вивчити це.

Змусити стандартизуватися на IDE звучить як жахлива ідея.

Слід вивчити причини, за якими компанія може змусити конкретного редактора чи програмного забезпечення взагалі щодо своїх розробників. Параноїдальна (можливо, не те слово, яку я шукаю) частина мене думає, що може бути якесь відстеження продуктивності, додане до затемнення, яке вони просять розробників встановити. Набагато меншою параноїдальною (знову ж таки) думкою було б те, що вони витратили час на додавання інструментів збирання продуктів до цього IDE, що полегшило б ситуацію, якби кожен натиснув одну і ту ж кнопку для тестування та створення своєї гілки коду.

У будь-якому разі, що я намагаюся сказати, це, мабуть, більше, ніж просто бюрократія, або метод возитися з керівниками розробників.

Це масивний червоний прапор. У кожної компанії є кілька таких дурних ідей, але якщо інші червоні прапори продовжують надходити, просто піти.

Мотивація, яка стоїть за деякими рішеннями, може легко загубитися - особливо це стосується команди, яка швидко зростає. Мотивацією переходу на Eclipse може бути лише той факт, що, здається, більшість розробників витрачає багато часу на налаштування IDE і що для вашої компанії є лише обмежений досвід.

Я б просто прийняв наказ про перехід до Eclipse, щоб означати, що вам слід встановити програму Eclipse у разі необхідності, але продовжуйте роботу в улюбленому редакторі. (Можливо, вам доведеться поступово переходити до Eclipse, якщо ваша компанія почне розгортати круті інструменти в межах Eclipse.)

Червоний прапор: Я б зачекав, якщо є ще кілька таких нераціональних наказів, перш ніж турбуватися.

Стартап, як правило, намагається залишатися спритним досить довго, щоб визначити стійку бізнес-модель. Після того, як він з'ясує грошову частину, керівництво рухається до масштабування бізнесу. Це, як правило, коли всі ранні технічні працівники починають відходити, оскільки інженерні процеси посилюються.

Як відомо, ви не знаєте, який код буде насправді робити, доки його не запустите. Тюрінг довів це в перші дні обчислень. Це означає, що не існує такого поняття, як будь-яка змістовна міра продуктивності, коли мова йде про написання програмного забезпечення. Однак, щоб керівництво виконувало свою роботу, продуктивність повинна бути розбірливою. Оскільки ви не можете виміряти код (а люди, наприклад, спробували - рядки коду, наприклад), вони вимірюють те, що вони можуть бачити. Програмісти більш розбірливі, ніж програмне забезпечення, яке вони розробляють. Типова управлінська команда намагається контролювати програмістів, щоб зробити ці речі зрозумілими для них (замість того, щоб робити їх справжню роботу: вилазити з дороги). А оскільки вони вимірюють неправильні речі, це працює не дуже добре.

Сказавши це, ви все ще можете пройти довгий шлях із слабко з'єднаною командою. Команда розробників Github нараховує близько 50 осіб, і вони порушують усі правила в підручниках з управління бізнесом. Вони, здається, роблять все добре. Помилки виправляються (зрештою). Особливості додаються. Пожежі гасять.

Великий червоний прапор - це якщо вони намагаються розширити масштаби, не придумавши, як заробити гроші. У цей момент вам належить замислитися, скільки варті ваші неоприбутковані варіанти та гранти дійсно варті.

Звичайно, це погана ідея. Неминуче команда стане менш продуктивною, оскільки їм доведеться навчитися використовувати нові інструменти. І навіть тоді вони не будуть настільки ефективними, як за допомогою інструментів, які вони вже рискують .

Оскільки я сам пробував різноманітні інструменти, у мене в певний момент завжди виникало відчуття "огонь, цей редактор мене дратує <вставити якусь помилку / відмінність від кращого інструменту>". Тож це буде і моральний недолік.

Але, звичайно, є і плюси, щоб ціла команда використовувала однакові інструменти. Обмін конфігураціями, скриптами, плагінами та всіма подібними матеріалами. Що було б неможливо при різноманітності наборів інструментів.

З іншого боку ... цей останній біт не був би необхідним, якби кожен користувався своїм програмним забезпеченням. ;)

Ви можете "використовувати" Eclipse під час введення в SublimeText2.

Це означає, що встановити та налаштувати Eclipse для ваших проектів та швидко працювати з ним, щоб ви однаково комфортно користувалися ним, якщо, скажімо, програмування пар. Ніхто не буде (або, принаймні, не повинен) дбати про те, який редактор ви насправді використовували для введення фрагменту коду, який ви здійснили, доки підтримка паралельної установки не займе зайвого часу, і ви не відключите себе від стандартне середовище розробки.

Якщо ви використовуєте Git і ваше розгалуження знижується, вам не потрібно використовувати редакторів один одного. Ви можете просто натиснути гілку і попросити іншого розробника, щоб він працював, якщо він справді не може розібратися з вашим набором інструментів. Примушувати всіх використовувати один і той же редактор звучить як замовлення керівника бізнесу, який хоче виглядати розумно, але насправді не розуміє, як ви працюєте.

Якщо ви думаєте про це з точки зору керівництва, то причина, по якій вони можуть це робити, - це дотримання законодавства. Компанія несе відповідальність за те, щоб кожен використовуваний інструмент використовувався легально, а також не обтяжував продукт, який розробляється. (Деякі редактори є безкоштовними для особистого користування, але не є безкоштовними для будь-яких інших цілей тощо). Аудит кожного інструменту, який може використовувати кожен розробник, може бути дорогим. Я бачив, що в проектах, де строкі строки, керівництво буде обережним щодо того, які інструменти / бібліотеки / тощо використовуються, щоб згодом мінімізувати зміни в проекті, якими керуються юристи.

У проектах з вищою безпекою також виникає занепокоєння тим, де IDE зберігають тимчасові файли та яка інформація зберігається між сеансами.

Все залежить від причин, яким вони повинні рекомендувати Eclipse. Якщо у розробників виникають проблеми з налаштуванням свого середовища, оскільки всі організовують речі по-різному, може бути причина рекомендувати прямий жакет. Якщо, однак, всі були щасливі та продуктивні, використовуючи все, що хотіли, мало підстав накладати зміни на щось так глибоко залучене у творчий процес.

Eclipse - це набагато більше, ніж редактор - ви можете продовжувати використовувати улюблений редактор для редагування свого коду та покладатися на Eclipse для керування джерелами, налагодження та всього іншого, для чого потрібен корпоративний порядок роботи.

Одне останнє - впровадження процесу на цьому рівні може означати, що компанія має намір розширити команду розробників і хоче мати певну структуру, щоб нові товариші по команді могли швидше отримати продуктивність. Якщо ви вважаєте, що Rails (або Django) є "впевненою" рамкою, ви зрозумієте, що структура допомагає зрозуміти нові програми легше.

Червоний прапор - це не стільки те, що один розробник IDE / примушується до кожного розробника, але те, що це рішення, і особливо рішення про використання IDE / редактора, не було прийнято всіма розробниками, і, можливо, ніхто з їх!?!

Звичайно, розробникам було б краще досягти консенсусу, тим більше, що вони, очевидно, найкраще кваліфіковані для прийняття рішення (принаймні, щодо того, який редактор / IDE). Можливо, є вагомі причини для відповідності, і це рішення повинно зважувати переваги управління, але який редактор / IDE повинен був бути рішенням усіх розробників.

Домогтися 12 розробників, щоб віддати кілька голосів, було б просто. Звичайно, для цього було достатньо часу! Висновок був би болючим для будь-якого випадку, і він, можливо, навіть закінчився "Затемненням" врешті-решт, але маркування вимоги "червоним прапором" у цьому випадку було б набагато більш дискусійним.