Виберіть зусилля з розробки коду чи лінь у світі банку

Я два роки працював у чудовому інвестиційному банку.

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

При доставці у виробництво => нуль помилок, все сталося так, як очікувалося.

Але більшість розробників прийшли до мене з метою уточнити, що весь мій код занадто складний для розуміння читання. Я прислухався, наприклад: "зробіть кілька if і instanceof, забудьте про поліморфізм, щоб виправити помилки у надзвичайних ситуаціях дуже легко". Я не вважав за краще відповідати ......

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

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

Або навпаки, чи повинні вони засвоїти основні принципи ООС та найкращі практики, щоб адаптувати себе до мого коду?

мої керівники проектів сказали мені, що я дійсно не так і занадто ідеаліст для світу Банку.

GTFO!

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

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

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

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

Я б не працював у компанії, яка хоче запропонувати неоптимальні рішення. Я хочу вирізати своє ім’я в програмному забезпеченні. Я хочу пишатися цим. Я не пишу процедурні заяви мовами, заснованими на парадигмі ОО. Я вірю у високоякісне програмне забезпечення, і якщо компанія цього не зробить, я буду GTFO! Сподіваюся, у вас вистачає "ебать гроші".

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

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

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

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

Чи тобі взагалі спало на думку, що вони можуть мати рацію?

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

Цікаве слово, яке ви тут згадуєте, - «складне». Код, який можна охарактеризувати як складний, рідко можна також описати як особливо хороший.

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

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

Натяк на мене, що ви не підходите для більшості комерційних розробок програмного забезпечення, - це "Коли доставка у виробництво => нульові помилки". Навіть Наса не досягла цього з космічними човниками.

Єдине місце, де ви звертаєте увагу на деталі, а отже, і початкову вартість, ймовірно, є прийнятною - це системи критичного для життя рівня 1 - наприклад, Авіоніка / Аерокосмічний, Автомобільний, Військовий та Медичний.

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

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

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

У моїй компанії ми провели ряд семінарів на базі Clean Code Developer . Метою було створення форуму поза звичайним повсякденним бізнесом із його суворими та термінами та несправедливими компромісами, де розробники могли б дізнатися про принципи розробки програмного забезпечення (як ви вже згадували), методи програмування тощо та задуматися над своїми проектами та власна робота.

Також були обговорені приклади реального життя з реальних проектів. Відгуки учасників AFAIK були дуже позитивними. Однак важко виміряти фактичну вигоду.

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

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

Ще краще перейдіть до InfoQ і дивіться розмови Rich Hickey на "Simple Made Easy"

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

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

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

Ваш код може мати більш високу якість (недоказаний факт), але вони мають політику . (звичайно, як пекло факт)

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

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

(тоді знову ж таки, ваша компанія, ймовірно, не має внутрішньої політики щодо дизайну OO, але незграбний інженер-тренер COBOL, який намагатиметься виправити ваш код, виправить щось з повітря і, IMHO, у гіршому випадку, він ' у мене буде 40% шансу забити критичний удар)

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