Скільки свободи повинен мати програміст у виборі мови та рамки?

Я почав працювати в компанії, орієнтованій насамперед на C #. У нас є кілька людей, яким подобається Java і JRuby, але більшість програмістів тут люблять C #. Мене взяли на роботу, тому що я маю великий досвід створення веб-додатків і тому, що я схиляюся до новіших технологій, таких як JRuby на Rails або nodejs.

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

Чи не було б сенсу використовувати фреймворк, який я вже дуже добре знаю (Rails), а не mvc4? Обґрунтуванням рішення було те, що технічний ведучий не знає Jruby / rails і не було б можливості повторно використовувати код.

Протистояння аргументів:

• Він не буде робити внесок у код і, чесно кажучи, не потрібен у
  цьому проекті. Таким чином, це не має значення, знає він JRuby / рейки чи ні.

• Насправді ми можемо повторно використовувати код, оскільки у нас є багато додатків Java, з яких JRuby може витягувати код і навпаки. Насправді він виділив деякі ресурси для перетворення Java-бібліотеки в C #, а не просто запустив бібліотеку Java в додатку JRuby on Rails. Все тому, що йому не подобається Java або JRuby

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

У який момент слід дозволити розробнику вибирати свої інструменти? Це залежить від компанії? Моя компанія смокче чи це вважається нормальним? Чи існують більш зелені пасовища? Я дивлюся на це неправильно?

Я б сказав, що вам потрібно поговорити з керівником команди і сказати щось на кшталт:

Я знаю, що ви, хлопці, .NET магазин, але мене насправді найняли на майстерність Java / JRubyRails. Я можу створити цю нову програму за X час, використовуючи ті інструменти, які я вже знаю. Я міг би вивчити C # / mvc4 так, як ви хочете, але це займе >> X кількість часу. Що ти хочеш?

У зв'язку з цим виникає питання про «навичках ви-were- (імовірно) -hired через» проти «навички ви-потреба-зараз» , а також показує , що ви готові , щоб дізнатися нові навички, але він буде приймати довше розробляти нову програму, оскільки ви новачок у цьому наборі інструментів. І ви дійсно хочете , щоб показати , що ви готові освоїти нові навички. Не бути відкритим для вивчення нових навичок - це хороший спосіб забезпечити закінчення своєї роботи, коли ваші навички більше не потрібні.

Щодо вашого запитання в кінці:

У який момент слід дозволити розробнику вибирати свої інструменти? Це залежить від компанії? Моя компанія смокче чи це вважається нормальним? Чи існують більш зелені пасовища? Я дивлюся на це неправильно?

Зазвичай це залежить від компанії. Якщо компанія купує засоби MS та стандартизує все на платформі VisualStudio та .NET, це може стати дуже незручним, якщо один розробник наполягає на використанні Linux та C. Це нормально. Винятки можуть існувати там, коли компанія менш метушлива щодо редакторів, наприклад, дозволяти розробникам вибирати Vi проти Emacs, доки результат буде однаковим. Я знаю, що деякі компанії навіть дозволяють розробникам вибирати Windows проти Linux, але мова, якою вони працюють, має дуже гарну підтримку та час виконання для обох ОС.

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

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

У який момент слід дозволити розробнику вибирати свої інструменти?

Коли вони не впливають на вашу команду.

Я дивлюся на це неправильно?

Абсолютно.

Так, у вас короткий термін. Так, ви можете зробити це швидше в Rails. Але компанії в цілому потрібно розгорнути та підтримувати додаток. Якщо компанія має стабільну кількість хороших розробників C #, то, ймовірно, буде дешевше (і вийде краща якість) мати додаток C # для обслуговування.

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

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

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

2. ASP.NET MVC дуже схожий на Ruby on Rails, багато в чому.

3. Ти не будеш з темпом равлики назавжди. Якщо ви вже знаєте ROR, ASP.NET MVC стане для вас шилом. Хитрість - це вивчення C #.

Аргументи для перебування в Java / JRuby

Швидше за все, ваш начальник хоче, щоб ви виробляли. Вони найняли вас, щоб ви могли додати вартість компанії. Переконайтеся в тому, що вони розуміють , що, змушуючи вас використовувати рамки , які ви не знайомі з їх буде заподіяти вам:

1. Створюйте результати повільніше
2. Створіть код нижчої якості

Навіть найкращі програмісти вимагають часу на розминку новими мовами / рамками.

Аргументи для вивчення MVC4 та C #

Вивчення нових мов - це добре. Інвестувати у свої навички програміста є лише ризиком, якщо мова / платформа, на якій ви вивчаєтесь, зникне найближчим часом, і якщо Microsoft зациклюється, я не думаю, що це проблема. У обох C # і MVC були останні оновлення, покращуючи їх обоє, з ще більшими оновленнями в конвеєрі.

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

Суть

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

У який момент слід дозволити розробнику вибирати свої інструменти?

Коли зазначений розробник є ведучим програмного забезпечення.

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

До речі, ця фраза

з акцентом на те, щоб зробити багато речей, зроблених за короткий проміжок часу

є причиною більшої печії та хаосу в галузі програмного забезпечення, ніж майже нічого іншого.

Зауважу, що ви не кажете, що вас наймали як програміста JRuby або Java.

Ось чому ви сказали, що вас прийняли на роботу: "[B] тому що у мене є великий досвід створення веб-додатків і тому, що я схиляюся до нових технологій, таких як JRuby на Rails або nodejs."

Іншими словами, їм подобається ваш веб-досвід та ваша бажання вивчати нові технології.

Тепер вони просять використовувати ваш веб-досвід та вивчити нову технологію.

Тож питання полягає в тому, чи збираєтесь ви це робити, чи ні?

Найбільші витрати на програмне забезпечення - саме на його обслуговування

Я читав, що найбільші витрати (80%) - на підтримку програмного забезпечення. Первісна розробка складає лише 20% від загальної вартості розробки.

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

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

Рішення: Парне програмування

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

Стаття у Вікіпедії на тему "Парне програмування": http://en.wikipedia.org/wiki/Pair_programming

Багато компаній просто вважають за краще дотримуватися того, що вони завжди робили, або того, що є "безпечним". Існує причина, що Java і PHP все ще дуже популярні. На даний момент пошук "COBOL" на веб-сайті zaista.com повертає 2144 списків ... що дійсно повинно говорити само за себе. Промисловість не дбає про хороший код, вона дбає про код, який може доїти якомога довше (це не означає, що C # погано, насправді це не так).

Подумайте про це: код вас переживе. Є хороший шанс, що хтось інший буде підтримувати ваш код, а C # - безпечніша ставка, ніж Node.js та Rails. Мене не здивувало б, якби через 5 чи 6 років кількість програмістів Ruby зменшилася вдвічі, зрештою, це сталося з Perl та будь-якою іншою мовою, яку в якийсь момент вважали веб-мовою "it". Javascript, ймовірно, не зникне, але ми вже починаємо бачити, що він використовується як свого роду ASM (або навіть C) Інтернету - проміжна мова, яку інші мови можуть скласти, щоб написання коду на стороні сервера могло дуже добре застаріли.

Моя головна проблема, що розробники вибирають, як реалізувати свої цілі, - це те, що вони, як правило, припускають лише те, що вони будуть редагувати код. Подивіться на це так, через 12 місяців вони можуть потребувати змін; ви недоступні (залишили компанію або дуже зайняті іншим завданням), і інший розробник повинен змінити ваш код. Якщо це C # магазин, то використання їх набору інструментів - це хороша робота в команді. Нові технології слід досліджувати та впроваджувати, але лише тоді, коли ведучий вважає, що настав час, оскільки вони прицілюються до багатьох цілей, а не до однієї.

Переверніть, будь ласка. Уявіть, що ви найняли розробника Ruby, і вони наполягають на впровадженні своєї роботи в Asp.net/MVC.

Що б ви їм сказали? Це наш стек, чоловіче. Навчіться жити з цим.

Золоте правило, ось, хто має золото, робить правила.

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

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

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

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

Ба. Усі помиляються.

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

А тепер про важливу пораду. Якщо ви продовжуєте відточувати свої спеціальності, а також урізноманітнюєте свій досвід в інших сферах, з часом ви опинитесь у тому місці, де ви зможете знайти нову роботу в будь-який час року менш ніж за два тижні у будь-якому великому місті, роблячи речі, які є в основному цікаві принаймні половину часу. Коли ви опинитесь у цьому місці, не змиріться з цими роботами, де вони говорять, що хочуть цього, а другий день вони роблять ТО, не сподіваючись на відшкодування, передбачуване у довгостроковому майбутньому. Просто ввічливо поясніть і вибачтесь, але ні, ви насправді не хотіли цього робити і сказали стільки ж на своєму інтерв'ю, а потім! @ # $ Ing киньте і рухайтеся далі, коли пройде пару тижнів, і вони неминуче нічого не зробили, щоб пристосувати той факт, що вони неправильно представили вам свою позицію і відмовляються визнати це.

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

Звичайно, те, що не має сенсу, полягає в тому, що вони б диверсифікувалися за допомогою Dev Rails / JS / UI-диска і мали лише робити MVC-програми. Але поки що. Можливо, вам доведеться забрати його та сплатити внесок. І як я вже сказав у коментарях, MVC насправді не так вже й погано. Дійсно поганий вибір, враховуючи всі варіанти, але, безумовно, не найгірший. Це досить просто, не кидає 10 000 шарів абстракції поверх усього, що відбувається насправді, і не стає таким закрученим на стороні клієнта, що ви б проклинали імена відповідальних інженерів з MS, якщо когось може турбувати щоб навчитися їх.

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

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

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

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

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

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

Що ви виберете, саме вам належить, але я б запропонував вам спробувати вивчити нові технології. Це не зашкодить, обіцяю.

Я припускаю, що ви були чесними напередодні інтерв'ю про відсутність знань C #, тому що якби ви цього не зробили, ви могли б опинитися в дуже нестабільному становищі з юридичної точки зору.

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

Природно, є крива навчання. Якщо роботодавець найняв вас, то вони повинні бути впевнені у ваших здібностях дотримуватися цієї кривої в розумний проміжок часу (знову ж таки, припускаючи, що ви були чесними вперед щодо того, що не знаєте C #). Мова C # значно запозичує Java, а загалом, більшість мов програмування на основі класу принципово досить схожі (ви згадали node.js, який будується на версії ECMAScript, що є мовою на основі прототипу, тому ви, очевидно, зручні для інших парадигм програмування.

Хороші програмісти повинні, крім гнучкості, прагнути вивчати нові речі. У розробці програмного забезпечення ви, як правило, або навчаєтесь, або стаєте неактуальними.

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

Вам потрібно бути готовим прийняти рано чи пізно, що ви працюєте в магазині C #, і тому вам потрібно мати C # під поясом.

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

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

Сподіваємось, ваш спосіб використання MVC4 (якщо припустити, що всі інші там не роблять це цілком правильно) у більш стильному Ruby-стилі зачепить і відірве всіх від менталітету веб-форм.