Как бороться с ужасными решениями по дизайну [дублировать]

    

У этого вопроса уже есть ответ:

    

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

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

Например, рассмотрим две таблицы: автомобиль и свойство:

Автомобильные записи:

  • Камри
  • Volvo
  • Mercedes

Записи свойств:

  • Запасная шина
  • Спутниковое радио
  • Поддержка Ipod
  • Стандартный

Вместо представления таблицы CarProperties, чтобы представить это, он сделал атрибут «Свойство» в таблице автомобилей, данные которого выглядят как «1,3,7,13,19,25»,

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

Наш руководитель проекта ориентирован на предоставление продукта как можно скорее и очень сильную личность. Предложив ему в этот момент, что мы потратим некоторое время, чтобы это сделать, его убьет.

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

Взгляд на динамику:
Я могу быть сильной личностью, если не буду себя измерять. Другой консультант не сильная личность, плохой коммуникатор, довольно упрямый и думает, что он лучше всех. Менеджер проекта - чрезвычайно сильная личность, которая сегодня сосредоточена на выпуске завтрашнего продукта. Полнофункциональный разработчик очень просрочен и прост в обращении, очень эффективный коммуникатор, но это тот, кто примет плохой дизайн, если это означает, что он не качает лодку.

Кодовые обзоры или что-либо еще, что занимает «время», не может быть и речи - ни один из наших PM не будет продан никому.

28 голосов | спросил splatto 12 Maypm11 2011, 19:31:27

13 ответов


41

Из моего опыта

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

Не вложено

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

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

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

Вы не должны были извиниться

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

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

Если вы действительно хотите что-то сделать, чтобы почувствовать себя лучше

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

ответил Jarrod Roberson 12 Maypm11 2011, 19:42:38
15

Лучше всего создать союзника в полном объеме разработчика. Поговорите с ним о недостатках дизайна и посмотрите, согласен ли он. Если вы можете заставить его увидеть проблемы, присущие текущему проекту, вы можете убедить его пойти с вашими методами в следующем проекте.

Это один из способов повлиять на ситуацию, не причинив серьезного побочного ущерба.

надеюсь, что это поможет!

ответил 12 Maypm11 2011, 19:39:44
9

Во-первых, вы, вероятно, не должны были извиняться - это просто заставляет его чувствовать себя «более рыжим». Критика является неотъемлемой частью любого проекта (вообще, а не только для кодирования). Во-вторых, вы можете сбить быстрый тестовый пример, чтобы продемонстрировать, насколько быстрее будет подходящий способ соединения таблиц, и спросить его, как, используя его списки запятой, вы могли бы выбрать все автомобили, которые поставлялись с поддержкой iPod?

ответил Grim... 12 Maypm11 2011, 19:35:57
5

Сначала вы правы, это очень плохой дизайн. Никогда не приносите извинения за профессионально несогласные, аплодируйте только за плохое поведение с вашей стороны (кричать имена и т. Д.), А не профессиональные разногласия. Он должен вам извиниться за то, что он не соглашается на признание профессором своего мнения.

Теперь, если кто-то сказал мне об этом, он, как я бы представил свой аргумент, если он не был убежден в первоначальном. Запустите таблицу быстрого тестирования с 10 000 000 записей с идентификатором в одном столбце и списком с пронумерованными запятыми в другой и второй поисковой таблицей, в которой номера относятся к идентификатору и описанию. Затем создайте правильную нормированную структуру. Теперь сделайте то же самое в правильном реляционном дизайне. Не забудьте создать подходящие индексы. Теперь напишите код, чтобы найти все идентификаторы в таблице 1, которые имеют значение test3 (которое будет равным 3 в списке делимых, но вам нужно сделать соединение с таблицей поиска, чтобы это знать) с плохо спроектированной структурой. Вы пишете код, используя стандартизованную структуру. Сравните код, время, необходимое для написания кода и времени, необходимого для запуска кода. Мы с вами знаем, что будет короче и займет меньше времени, чтобы писать и работать лучше. Покажите результаты премьер-министру и докажите ему, что плохой дизайн заставляет проект работать медленнее и будет хуже работать, когда он будет развернут. Если это не убедит его, тогда ничего не будет, и вам нужно найти лучший контракт как можно скорее, потому что этот проект имеет 0% -ный шанс на успех.

ответил HLGEM 12 Maypm11 2011, 20:40:26
5

Когда я был консультантом, мое правило заключалось в том, что когда я не соглашался с техническим решением, я бы сказал им, почему (с поддержкой аргументов) точно ONCE. Если они не захотят принять мое предложение, неважно, я не буду его поддерживать.

ответил 12 Maypm11 2011, 20:46:06
5

Это домашнее животное ... Исходя из правильности решения, было принято решение, что вам не нравится - каждый из нас будет заниматься 100-ю из них в нашей карьере. Вы, кажется, отказываетесь принять его и отстаете от спины людей, играя в глупые игры, чтобы изменить его. Такое поведение подрывает рабочие отношения не только между вами и другой стороной, но, поскольку вы заставляете людей принимать участие в непростой войне, все другие отношения в офисе. Ваше поведение незрелое и разрушительное. Ваша работа (что вам нужно сделать) - это обеспечить успех проекта. Уничтожение командных отношений будет делать это в 1000 раз быстрее, чем одно плохое дизайнерское решение.

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

Итак, каковы ваши варианты: a) Растите и будьте профессиональны, b) уволяйтесь или c) уходите в отставку. Если вы не можете сделать a), пожалуйста, сделайте c), прежде чем уничтожить проект.

ответил mattnz 13 Mayam11 2011, 08:00:33
4

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

Удостоверьтесь, что он не может его найти!

ответил Grim... 12 Maypm11 2011, 19:45:00
2

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

ответил JustinDoesWork 12 Maypm11 2011, 19:37:03
2

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

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

ответил 12 Maypm11 2011, 21:37:13
0

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

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

Здесь действительно проблема общения. Или вы спорили с ним таким образом, что он чувствовал себя атакованным, или он очень упрям ​​и не может получить критику.

ответил barjak 12 Maypm11 2011, 21:12:41
0

TBH его дизайн невелик, но на самом деле не так уж плохо. Нормализация всего может привести к множеству таблиц, которые трудно отслеживать. Сериализация атрибутов в строке упрощает сохранение и загрузку объектов. Вы видите похожие объекты, где объекты сериализуются в xml и сохраняются в столбце blob.

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

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

ответил Richard 12 Maypm11 2011, 23:31:43
0

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

ответил Matthew Lund 13 Mayam11 2011, 03:03:07
-3

Собственно, он вполне может быть прав. То, что он сделал, - это то, что я бы назвал «встраиванием» отношений.

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

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

Как его дизайн лучше, несколько причин: - Из-за inlining, его чтение будет массово лучше, чем ваше. (Не нужно будет читать индекс таблицы отношений) - Когда вы добавляете и удаляете свойства для автомобиля, расположение строки для отношений может быть фрагментировано во всей таблице отношений. Опять же, повлияйте на время чтения, если вы с нетерпением получите свойства.

ответил InformedA 6 J0000006Europe/Moscow 2014, 11:09:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132