У який момент ви б кинули деякі свої принципи розробки програмного забезпечення заради більших грошей?

Я хотів би винести це питання туди, щоб цікаво побачити, де знаходиться середовище.

Я зізнаюся, що в останні 12 місяців я підбирав TDD і багато Agile цінностей у розробці програмного забезпечення. Я був настільки переповнений тим, наскільки кращою стала моя розробка програмного забезпечення, що я ніколи не відмовився б від принципу. Поки… мені не запропонували контрактну роль, яка подвоїла мою оплату додому за рік.

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

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

Подвоїти гроші, повернутися до RAD? Або йдіть і шукайте когось, що робить Agile, і ніколи не озирайтеся назад ...

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

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

Оновлення

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

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

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

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

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

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

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

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

Люди на вашій останній роботі вже знали про TDD, SOLID тощо. Це чудово. Я впевнений, що вам сподобалось працювати там і багато чого навчились. Тепер у вас є можливість навчити цим поняттям (одночасно роблячи великі гроші). На моєму досвіді, навчити когось іншого поняття завжди допомагало мені навчитися його ще більш детально. Будьте терплячими до них і продовжуйте просовувати свої концепції одна за одною. Коли вас засмутить, йдіть додому і порахуйте свої гроші. Або шукайте підтримки в SE.

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

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

• Працювати з цим треба весело
• Це повинно бути корисним для розвитку вашої компетентності (не впевнений, що це правильний спосіб сформулювати це)
• Це повинно добре платити

Коли я читаю ваше запитання, цей проект задовольняє лише останні критерії.

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

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

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

Ніколи.

Життя занадто коротке (особливо, коли дорослішаєш), щоб робити речі, які ти будеш ненавидіти.

Звичайно, це ускладнює зміну роботи, і місця для роботи менше.

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

Коротше кажучи, методологія розвитку не є частиною вас. Це не релігіон і це не ти хто. Це інструмент. Робіть те, що вам кажуть, як вам кажуть і робіть зайві гроші. Тисячі систем були розроблені і працюють сьогодні без TDD, Code Smell і т. Д. Через кілька років ніхто не дізнається, що означають ці терміни, оскільки методології приходять і ходять частіше, ніж міський автобус. Працюйте, як вам кажуть, і берете гроші, що це цінується в будь-який час і весь час :)

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

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

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

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

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

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

Якби я не міг цього зробити, то не знаю, чи хотів би я там працювати.

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