Выберите дизайн кода или лень в мире банка

Я работал два года в отличном инвестиционном банке.

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

Когда поставка в производство => ноль ошибок, все произошло так, как ожидалось.

Но большинство разработчиков пришли ко мне, чтобы уточнить, что весь мой код слишком сложен для чтения. Я, например, слушал: «сделай несколько if и instanceof, забудь о полиморфизме, чтобы было очень легко исправить аварийные ошибки производства». Я не предпочел ответить ......

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

Что бы вы мне посоветовали? Должен ли я сохранить желание действительно хорошего кода или адаптировать меня к большинству разработчиков, которые, я повторяю, действительно не интересны с помощью дизайнерского кода, который, по моему мнению, является всей прелестью нашей работы для разработчиков.

Или наоборот, должны ли они изучать основные принципы ОО и лучшие практики для адаптации к моему коду?

мои менеджеры проектов сказали мне, что я на самом деле ошибаюсь и слишком идеалистичен для мира Банка.

GTFO!

Время уходить и жалеть их. Почему ты должен ебать? Вы знаете, что это будет стоить им денег в долгосрочной перспективе с их некомпетентным персоналом. Это не игра технического обсуждения. Это о политике. Пусть они обучат других разработчиков или GTFO! Если вам не хватает политического веса, тогда GTFO! Поиск компании с лучшими практиками.

Единственная причина остаться там - адекватная компенсация за ваши головные боли. Так что им лучше платить намного выше среднего или GTFO! Я сомневаюсь, что вы можете расти как разработчик программного обеспечения. Рост нашей профессии в основном достигается благодаря работе с людьми, которые лучше вас и поощряют лучшие практики. И чем лучше вы, тем выше ваша рыночная стоимость для заботящихся компаний.

Да, я знаю, что это не один из моих обычных ответов, но на самом деле, если вы не можете играть в политическую игру в этой компании, GTFO.

Что бы вы мне посоветовали? Должен ли я сохранить желание действительно хорошего кода или адаптировать меня к большинству разработчиков, которые, я повторяю, действительно не интересны с помощью дизайнерского кода, который, по моему мнению, является всей прелестью нашей работы для разработчиков.

Я бы не работал в компании, которая хочет, чтобы я предлагал неоптимальные решения. Я хочу вырезать свое имя в программном обеспечении. Я хочу гордиться этим. Я не пишу процедурные приложения на языках, основанных на парадигме ОО. Я верю в высококачественное программное обеспечение, и если компания этого не сделает, я буду GTFO! Надеюсь, вы получили достаточно "ебать свои деньги".

Трудное место. Я думаю, что вы можете идти двумя путями параллельно, отстаивая свою точку зрения и демонстрируя желание идти на компромисс:

• Это о деньгах. На самом деле, как и любая другая разработка, но, поскольку вы делаете упор на банковскую среду, это должно работать еще лучше;). Покажите им, что ваш стиль экономит деньги. Найдите пример того, как изменение требований может быть сделано действительно легко благодаря вашему дизайну. Попробуйте найти кусок другого кода (вы должны убедиться, что вы не слишком агрессивны здесь, но эй, речь идет о сравнении стилей кода), который скоро может сломаться, и покажите им, как вам не нужно заботиться о таких проблемах, потому что ваш код лучше с самого начала.

• Это о деньгах. Что если ваш стиль кодирования на самом деле стоит денег? Вполне возможно, если другие люди тратят больше времени на то, чтобы понять ваш код, чем на то, что сохраняется при правильном дизайне. Вы можете делать правильные вещи технически и все же не вносить позитивный вклад в командные усилия. Также возможно переусердствовать в ООП-дизайне. Я с вами на стороне «хороший дизайн - это красиво», но я пытаюсь донести до вас здесь свою точку зрения и то, как они могут быть правы с их точки зрения. Параллельно с предыдущим пунктом попробуйте найти место, где вы перестарались. Это дает вам некоторое пространство для маневра: вы можете сказать, хорошо, я могу быть немного более прагматичным здесь и там, но посмотрите, есть также места, где этот код действительно лучше.

Но большинство разработчиков пришли ко мне, чтобы уточнить, что весь мой код слишком сложен для чтения

Тебе вообще приходило в голову, что они могут быть правы?

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

Интересное слово, которое вы упоминаете здесь, «сложное». Код, который может быть описан как сложный, редко может быть также описан как особенно хороший.

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

Многие программисты хотят быть мастерами прошлого, к сожалению, коммерция диктует, что это не может происходить постоянно. У вас есть выбор, адаптировать или оставить. Есть компании, которые хотят мастеров, но их намного больше, чем тех, которые хотят продукты, которые в основном работают, дешево и сейчас.

Мне подсказывает, что вы не подходите для большинства коммерческих разработок программного обеспечения: «Когда поставка в производство => ноль ошибок». Даже НАСА не достигла этого с помощью космических кораблей.

Единственные места, где вы обращаете внимание на детали и, следовательно, на первоначальную стоимость, скорее всего, будут приемлемыми, это жизненно важные системы уровня 1 - например, авионика / авиакосмическая, автомобильная, военная и медицинская.

Проблема в том, что вы работаете не в том месте. Похоже, вы очень академический склонный программист. Вы не добьетесь успеха в среде, в которой находитесь, и вполне вероятно, что придет какое-то оправдание, чтобы избавиться от вас и вашего «слишком сложного» кода. Вам могут давать нежелательные задания и / или плохие оценки производительности, например, до тех пор, пока вы не уйдете по собственному желанию или у них не будет достаточного количества задних листов бумаги, чтобы уволить вас.

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

Прежде чем принимать такие радикальные меры, как смена вашего работодателя, я постараюсь улучшить вашу собственную способность объяснять непрограммистам, например вам, руководителям, почему ваш способ кодирования лучше для компании и экономит им время и деньги. Кроме того, убедитесь, что вы не применили шаблоны проектирования только ради шаблонов проектирования. Вы уверены, что также следовали правилам KISS и YAGNI? (Хорошо, стратегия и полиморфизм - это не ракетостроение, дайте коллегам некоторое время на адаптацию и объясните им, почему вы выбрали этот подход.)

В моей компании мы провели серию семинаров на основе Clean Code Developer . Цель состояла в том, чтобы создать форум вне обычного повседневного бизнеса с его беспокойными и крайними сроками и грязными компромиссами, где разработчики могли бы узнать о принципах разработки программного обеспечения (как вы упомянули), методах программирования и т. Д. И подумать о своих проектах и их собственная работа.

Были также обсуждены примеры из реальных проектов. Отзывы участников были очень положительными. Однако трудно измерить реальную выгоду.

Участие в этих семинарах было частично на время, спонсируемое компанией, частично на свободное время участников. Вы не достигнете тех коллег, которые не заботятся об обучении и просто хотят сделать свою работу и уйти домой, но для любого другого, кто интересуется его собственной работой, это может быть интересно.

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

А еще лучше - зайдите в InfoQ и посмотрите выступление Рича Хикки на тему «Просто сделано легко»

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

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

Чрезвычайные ситуации случаются. Ты не идеален и своими руками будут портить код в какой - то момент. Это, если вы никогда не будете отдыхать, что, как подтвердит ваш лечащий врач, вредно для вашего здоровья. И приводит к увеличению шансов испускания плохого кода.

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

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

Вы, сокамерники, были бы рады услышать, как вы бродите по поводу отсутствия любопытства ваших бывших коллег.

(с другой стороны, ваша компания, вероятно, не имеет внутренних политик в отношении ОО-дизайна, но неуклюжий, обученный на COBOL инженер, который попытается исправить ваш код, придумает что-то из ничего, и, ИМХО, в худшем случае, он ' у вас будет 40% шанс получить критический удар)

Постарайтесь помнить, что программирование рассматривается некоторыми как средство достижения цели, а не ради самого себя. Подумайте обо всех продуктах и ​​услугах, которые вы используете: вы тратите много времени на обдумывание элегантного кода? Или вы просто цените их, поскольку они просто работают? Найдите сферу деятельности или сферу деятельности, которой вы увлечены, затем найдите организацию с этим и предложите им решения, которые включают программирование, но не только это. Проблемы могут быть блестяще решены разными способами.