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

23

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

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

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

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

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

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

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

Mik378
источник
19
Трудно парить, как орел, когда работаешь с
индюшками
8
Измени свою организацию или измени свою организацию. - Мартин Фаулер
Дон Роби
9
@ Mik378 У вас могут быть проблемы со связью. Если вы документируете свой код так же неаккуратно, как вы написали этот вопрос (и чем больше ОО-ошибок, тем больше документации вам нужно, чтобы люди знали, что ITradeSettlementVisitorдолжен делать этот интерфейс), ваши коллеги вправе жаловаться. Одно дело писать красивый код, который вам нравится, совсем другое - структурировать и документировать его так, чтобы он был доступен и полезен для других.
Quant_Dev
2
@quant_dev: Я думаю, вы слишком много думаете о Mik378. Его вопрос не кажется мне плохо сформулированным; он просто не носитель языка. Мне не нравится многословность и чрезмерный дизайн в ОО, как вы, кажется, делаете, но ситуация, которую описывает Mik378, тоже звучит как колокол: я работал со слишком многими программистами, которые не могли понять простые вещи, такие как логические выражения (так что они напишите «if (exp) then True else False») ... Вполне вероятно, что такого рода люди также будут напуганы шаблонами проектирования, полиморфизмом и поэтому вернутся к простому старому процедурному коду.
Андрес Ф.
2
Я категорически не согласен с тем, что хранить код простым и легким в обслуживании для ваших коллег лениво, как указано в заголовке.

Ответы:

20

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

GTFO!

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

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

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

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

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

сокол
источник
4
+1 - Однажды мне пришло в голову, что такое GTFO ... ( urbandictionary.com/define.php?term=gtfo )
Reddog,
2
@Falcon Я полностью с тобой согласен, и мне приятно находить людей, разделяющих мою идею; и особенно когда вы говорите: «Рост нашей профессии в основном достигается благодаря работе с людьми, которые лучше вас и поощряют лучшие практики». Самым удивительным и настоящим разочарованием является то, что я - младший разработчик, и я не особо учился у старых. Спасибо за ваш ответ :)
Mik378
+1, я полностью согласен. Этот банк просто не выглядит как хорошая рабочая среда, и его проблемы кажутся непреодолимыми: плохие программисты, плохое управление. GTFO действительно!
Андрес Ф.
2
@ Mik378: Ваш нынешний работодатель не может в полной мере использовать ваши способности и, следовательно, не сможет заплатить вам то, что вы стоите. Лучшая организация сможет получить больше пользы от вас и сможет заплатить вам больше.
Кевин Клайн
+1, если бы мог дать вам больше голосов, вы бы получили 1000 от меня. Сам поработав в инвестиционном банке, я точно знаю, с чем имеет дело Mik378. Это питательная среда для токсического поведения, реагирования на полярность и эгомании. Не идеальная среда для продвижения технического совершенства.
Пустынная планета
18

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

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

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

Nicolas78
источник
Спасибо за ваш разработанный ответ. Я
записал
Я добавлю к этому простую проблему FizzBuzz. Напишите это на Java, а затем сделайте это снова в стиле TDD, внезапно становится нечитаемым, не так ли ;-).
Мартейн Вербург
@Martijn Verburg - Как вы думаете, TDD приводит к нечитаемому коду?
Дон Роби
@ Дон Роби - иногда да, особенно когда имеешь дело с чем-то вроде FizzBuzz на оригинальном языке
Мартин Вербург
+1 @ Nicolas78 «Кроме того, возможно переусердствовать в разработке ООП» - например, создание примитивных типов данных Объекты, такие как, например, int.
therobyouknow
16

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

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

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

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

temptar
источник
1
+1000 Согласен. Код для людей. Предостережение заключается в том, что другие кодеры должны быть в состоянии прочитать то, что пишет большинство кодеров. Любой, кто не понимает основ, должен совершенствоваться.
Iain Holder
3
+1 @tempar для "Вам вообще приходило в голову, что они могут быть правы?" и «Код, который может быть описан как сложный, редко может быть также описан как особенно хороший».
therobyouknow
2
-1: я не думаю, что они правы, просто немного старше, и я думаю, что более внимательное изучение вопроса делает это очевидным. Ключевая фраза из ОП - «избегать всевозможных повторяющихся кодов ...». Он пытается высушить код, но для этого требуется изощренность, которой явно не хватает его коллегам. Он также процитировал предложения своих коллег "просто добавить if ... instanceof". Это также говорит мне, что ОП находится на правильном пути, и его коллеги строят большой WTF.
Кевин Клайн
меня беспокоит то, что ООП «слишком сложный» может быть хорошей вещью, но он также может очень быстро усложниться. Я подозреваю, что Оригинальный Плакат, возможно, выпил классную помощь ООП и не понял, что это не всегда лучший способ кодирования, и что он может вводить много дополнительной сложности, где это не нужно.
Захария К
Похоже, у вашего коллеги нет своих тестов для будущего обслуживания. Вы можете обсудить это с менеджером проекта.
10

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

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

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

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

mattnz
источник
1
+1 @mattnz для «У вас есть выбор, адаптироваться или оставить.»
therobyouknow
2
Я не согласен - это банк . Им, как правило, нравится, что в их программном обеспечении нет ошибок, так как ошибки могут стать довольно дорогими. Также решения могут работать годами или десятилетиями.
2

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

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

jfrankcarr
источник
+1 @jfrankcarr за проницательное наблюдение «может быть дано ненужное задание» (форма конструктивного увольнения)
therobyouknow
2

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

Док Браун
источник
Я согласен, проблема в том, что они не хотят учиться, не хотят менять свой менталитет (я не гений в Java, но когда я не понимаю то, что большинство людей считают отличной вещью знаете, я приложу усилия, чтобы выучить это (книги, статьи в Интернете, переполнение стека и т. д.). Подводя итог, они не хотят испытывать головную боль с шаблонами (я говорю шаблон, но я мог бы сказать "превосходный" принцип программирования подробнее в общем), которые не приносят им гораздо больше денег ... Трудно сказать, но это так верно. Если бы только приложение работало хорошо => Я бы точно не писал эту тему.
Mik378
@ Mik378: вы много говорите о том, что "другие делают неправильно". Уверен, что все, что ты сделал, было правильно?
Док Браун
У полиморфизма @DocBrown есть явный недостаток, заключающийся в фрагментации логики по файлам, где простые экземпляры хранят ее в одном методе. Возможно, рабочие единицы слишком малы?
2

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

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

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

Роберт Петермейер
источник
Мне очень нравится эта идея.
Temptar
2

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

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

Захари К
источник
1

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

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

JeffO
источник
0

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

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

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

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

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

Zjr
источник
1
Лично я считаю, что настоящий очень хороший разработчик делает отличный код так же быстро, как грязный код. Я согласен с вами в отношении чрезвычайной ситуации ... но когда проект планируется в течение 4 месяцев, и разработчики даже не имеют общего представления о том, что они будут делать, как и если что-то уже существует в приложении, которое будет помочь им, я не мог принять это. Когда разработчик говорит: «Я знаю, что этот код ужасен, но я никогда не буду подвергать его рефакторингу, потому что я могу его сломать», это смешно. Они инженер или нет? Инженер должен рискнуть и сделать несколько действительно хороших юнит-тестов, чтобы быть уверенным
Mik378
1
Я бы согласился, если бы мы не разговаривали здесь с банками. Я всегда чувствую, что они отличаются от других программистов. Они также обычно старше. (В моем окружении, по крайней мере, как и везде, я делаю вывод) Их математика проста, но их точность нет.
ZJR
@ZJR Вы увлекаетесь здесь своими пророчествами о том, что OP делает тюремное заключение за использование OO. Большинство банковских кодов не подлежат такой проверке.
Quant_Dev
0

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

therobyouknow
источник