Самое прискорбное дизайнерское или программное решение, которое вы приняли? [закрыто]


57

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

Я уверен, что это очень поможет другим программистам, помогая им не повторять эти решения.

Спасибо за обмен вашего опыта.


19
тратить слишком много времени на ТАК !! ;)
Mitch Wheat

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

1
Это, вероятно, должно быть сделано в вики сообщества (есть поле, когда вы редактируете сообщение).

3
Хотелось бы, чтобы был способ проголосовать, чтобы противостоять закрытию. Даунвот закрыть?
Кьевели

5
Что не так со всеми закрытыми избирателями? Так что, если это не CW, пусть спрашивающий получит несколько голосов за вопрос. Я искренне заинтересован в этой теме. Не позволяйте CW мешать хорошему субъективному вопросу. Sheesh, SO полон крикунов "CW THIS".
Сяз

Ответы:


73

Игнорируя ЯГНИ , снова и снова ...


22
Правда для большинства, но есть также люди, которые могут использовать немного меньше YAGNI. Ни одна из крайностей не является лучшим местом для жизни.
консоль 80х24,

56

«Сделаем это позже»
«Позже» никогда не наступит.


8
Позже никогда не приходит.

Это никогда не делает.

Было сказано: если у вас нет времени, чтобы сделать это прямо сейчас, с чего вы взяли, что у вас будет время исправить это позже?

4
Мы называем это «итерацией никогда»
NotMe,

10
Нет ничего более постоянного, чем временное решение.
dietbuddha

52

19
Мне нужно создать новый аккаунт, чтобы снова проголосовать за него ...
Kieveli

Да ... болезненные переживания ...
Эд С.

У меня только что был ужасный воспоминание
Нил Н

1
@ Джэй, в то время это казалось хорошей идеей.

6
Я не знаю, что это вообще значит, но звучит больно +1
The Disintegrator

44

Конфигурируемость в приложении хорошая. Слишком большая конфигурируемость - это кошмар для использования и обслуживания.


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

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

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

Это называется «spoftcoding», а не «hardcoding»
deadalnix

42

От одной из моих ошибок я узнал, что нормализация БД не должна проводиться вслепую. Вы можете, и в некоторых ситуациях вы ДОЛЖНЫ сгладить ваши столы.

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


5
Я не мог согласиться больше ... Я инженер-программист, и нам говорят, чтобы всегда нормализовать. Что за дерьмо. Это было только потому, что учителя не пытались работать с действительно сложными и зависимыми от производительности БД.

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

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

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

7
Но нормализация это весело! :) Я серьезно, мне нравится проектировать структуры данных. Я бы сказал, что хотя нормализованную схему легко нормализовать, обратное НЕ верно. Вы должны ЗНАТЬ правила, прежде чем нарушать их.

36

Использование одного char в базах данных для статусов и т. Д. Нет никакого смысла в этом, издержки использования более длинных char () или nvarchar2 () незначительны по сравнению с сетью и синтаксическим анализом, возникающим при любом вызове SQL, однако символы всегда заканчиваются довольно запутанный или истощающийся (не для статусов, а для других вещей). Гораздо лучше просто добавить версию, удобную для чтения человеком, а также иметь в вашей модели Java (в моем случае) перечисление с соответствующими значениями.

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


+1 У нас только что была встреча по этому вопросу. Мы пришли к такому же выводу.
APC

Что если ваш клиент работает с такими сокращениями и не хочет отказываться от них?

Для существующих систем вам необходимо быть совместимыми (я бы все-таки создал перечисление правильных значений Java с помощью метода <code> MyEnum fromChar (char c) </ code>). Для новых дизайнов, просто не ходи туда!

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

2
Почти так же плохо: использование типа BIT в MS SQL Server, прежде чем обнаружить, что он не может быть частью индекса.
Finnw

32

Не разрабатывать надлежащий уровень доступа к данным и иметь sql везде в моем коде, просто чтобы что-то «быстро» заработало и заработало. Позже, когда проект начал расширяться, а требования изменились, это стало кошмаром. Я не знал, что такое DAL в то время.

... рад, что я прошел через это, хотя я все еще вижу программистов с более чем 20-летним опытом работы.


16
Не могу вспомнить, где я это читал, но есть разница между 20-летним опытом, и один год опыта повторяется 19 раз.
CaffGeek

@Chad: Это было где-то в работах Джоэла Спольски.

+1: да И попробуйте рефакторинг всей этой логики, связанной с этим SQL ... Будь то встроенный, произвольный SQL или хранимые процессы. [Да, я не боюсь этой священной войны.]
Джим Г.

26

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

2 месяца сна по 3 часа в сутки научили меня, что ты просто не можешь этого сделать.


15
Так что хватит спать! о, подождите ... вы имеете в виду, что это не нормально ... ?? Хм, я должен
дать

Похоже, PM - вам нужно немного

21

Выбор Microsoft Foundation Classes (MFC) для написания Java IDE.


3
Owwww. Это сделало бы мой мозг больно.
Грег Д.

2
Это было не плохое решение в 1999 году. Тогда AWT был уродливым и медленным.
Finnw

finnw - ну, по крайней мере, это все еще уродливо!
Никлас Х

20

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

Результаты:

  • Более болезненно добавлять новые логи
  • Подробнее стоимость перевода
  • Журналы потом труднее читать

К сожалению.


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

1
Дай угадаю, твой американец? А если нет, вы говорите только по-английски? Используйте интернационализацию, где новые записи журнала на английском языке, если доступен другой язык, вы отображаете язык пользователя. СОВЕТ: здесь помогает использование кодов ошибок, так как это означает, что вы всегда можете просматривать / просматривать журналы независимо от языка.

2
@Jacob: я английский, но говорю только по-английски. Но это было для компании, где вся инженерная база находилась в Англии, поэтому наличие файлов журналов (предназначенных для диагностики, а не видимой для пользователя информации) на других языках было бы просто пустой тратой ресурсов. Я согласен, что использование кодов ошибок вместо текста позволяет перевод на лету - но это все же больше, чем просто использование одного языка для начала. Речь идет о сокращении работы путем определения того, где что-то, что звучит полезным, на самом деле не даст какой-либо существенной ценности.
Джон Скит

10
Я шведка Я должен был бы стать средневековым для любого, кто даже предлагает, чтобы код / ​​комментарии / журналы были в чем-то кроме английского. Английский - это язык, который используется для всего, кроме пользовательских интерфейсов. Все остальное просто затрудняет чтение и обсуждение кода. Использование родного языка нелепо, так как любая другая используемая вами фреймворк / библиотека написана на английском языке.
jgauffin

1
+1 Английский язык - это язык программирования. Чтобы перевести это, просто добавьте дополнительный слой, где вам нужно как можно меньше слоев и как можно больше ясности.


19

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


Если бы вопрос был: «Какое самое прискорбное дизайнерское или программное решение вы когда-либо видели?» в отличие от ошибок, которые мы сделали сами, я бы поставил «UML» в верхней части моего списка. Прямо под "реестром Windows".

2
UML хорошо обсуждать между членами команды, но когда дело доходит до дизайна, а затем воплощать его в соответствии с дизайном, он всегда заканчивается неудачей. Это какая-то мечта некоторых компаний, но на самом деле написание программного обеспечения определенно не работает таким образом. +1!
Deadalnix

17

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


15

Мое единственное худшее дизайнерское решение? Еще в 1980-х годах я работал над проектом, в котором у нас появилась блестящая идея создать своего рода шаблон для наших экранов ввода данных, который будет интерпретироваться во время выполнения. Неплохое решение: оно облегчает проектирование экранов ввода. По сути, просто создайте файл, похожий на экран ввода данных, с некоторыми специальными кодами, чтобы идентифицировать, что было меткой, а не тем, что было полем ввода, и определить, были ли поля ввода буквенными или числовыми. Затем я решил добавить еще несколько специальных кодов в эти файлы, чтобы определить, какие проверки должны быть выполнены. Затем я добавил больше кодов, чтобы разрешить условное построение экрана, поле X включалось только тогда, когда некоторые условия выполнялись, и т. Д. Затем я добавил больше кодов, чтобы выполнить простую обработку входных данных. И т. Д. В конце концов мы превратили наш экранный шаблон в новый язык программирования с выражениями, управляющими структурами и библиотекой ввода / вывода. А для чего? Мы проделали большую работу, чтобы заново изобрести Фортран. У нас была полка компиляторов для языков, которые были лучше разработаны и лучше протестированы. Если бы мы посвятили столько усилий созданию продуктов, в которых у нас действительно был некоторый опыт, эта компания могла бы по-прежнему существовать сегодня.


Это и смешно, и трагично :)

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

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

Я видел, как именно это было сделано ... в 2004 году! Вся бизнес-логика распределена примерно по пятнадцати таблицам конфигурации, и в качестве правильной меры добавлено несколько наполовину попыток динамических «языков» (см. Десятое правило Гринспуна)!

1
Разве вы не имеете в виду КОБОЛ, а не ФОРТРАН?
Finnw

15

Чрезмерное применение YAGNI (которое называется « Проектирование путем перечисления в ловушках объектно-ориентированной разработки» ) в среде, где любой разумный человек может сказать, что требования определенно изменятся. И меняются неоднократно.

Если вы (жестко) закодировали все точно в соответствии с текущими требованиями - в то же время избивая любого, кто говорит: «Разве это не может быть более общим?» с вашим молотком YAGNI - и тогда требования резко изменятся (но таким образом, который можно было бы разумно предвидеть), тогда это может быть разницей между 2-недельной адаптацией и 20-минутной.

ОБНОВЛЕНИЕ: Чтобы уточнить, вот вымышленный пример, который не слишком далек от того, что произошло. Переполнение стека было разработано для поддержки значков, но предположим, что сначала они могли думать только о четырех значках. Их всего четыре, такое небольшое количество, поэтому они жестко закодировали поддержку ровно четырех значков во всей логике сайта. В базе данных, в пользовательской информации, во всем коде дисплея. Потому что "Я не буду нуждаться" в каких-либо значках, о которых ты не можешь думать, верно? Предположим, что сайт начинает работать, и люди начинают предлагать новые значки. Каждый значокна добавление уходит до двух недель, потому что повсюду столько жестких настроек. Но все же «Я не буду нуждаться» в большем количестве значков, чем в сегодняшнем списке, поэтому никогда не будет никакого рефакторинга для поддержки общего набора значков. Разве такая общая коллекция заняла бы больше времени заранее? Не много, если есть.

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


1
Да и нет, можете ли вы предсказать, в каком направлении это изменится? У меня есть опыт болезненно сложных систем, которые оказались совершенно неадекватными для первого повторного использования, которые не вписывались в предсказанную универсальность ...
Бенджол

^ Да, я бы лучше имел дело с YAGNI, чем с этим дерьмом.

Так вы думаете, что должны были потратить 2 недели заранее?
Finnw

4
Этот пример вовсе не ЯГНИ. СУХОЙ является частью ЯГНИ, и без него вы не сможете оставаться в курсе изменений.

3
Стефан, пример показывает бойкое и неуместное злоупотребление ключевой фразой, которая была моей точкой зрения. DRY (с его вариантом OAOO) также является хорошим принципом, но совершенно отдельным: c2.com/cgi/wiki?OaooBalancesYagni . Тем не менее, я нигде не могу найти ничего, чтобы поддержать ваше утверждение, что «СУХОЙ является частью ЯГНИ». Горчица хорошо сочетается с хот-догами, но это не значит, что горчица является частью хот-догов. Если бы вы могли уточнить, возможно, со ссылками, возможно, я пойму.
консоль 80x24

15

Некомпетентные человеческие ресурсы

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


1
Я понимаю вашу боль :(

13

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


13

Использование служб интеграции SQL Server (SSIS).

Я не желаю этого моему злейшему врагу.

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

Это очень плохая ситуация, когда у вас меньше 48 часов, чтобы переписать свои пакеты служб SSIS в чистом коде .NET POCO или пропустить установленный срок.

Меня удивляет, что я смог переписать три пакета служб SSIS (на тестирование и разработку которых у меня ушло два месяца) в течение 12 часов в чистом коде .NET с помощью адаптеров OLEDB и адаптеров SQL.

Служба SSIS не распространяется и не будет запускать пакеты с клиентского компьютера, если на нем не установлена ​​лицензия SQL Server (в частности, DTSPipeline.dll). Это было бы здорово знать заранее. Теперь я вижу отказ от ответственности (мелким шрифтом) на MSDN. Это бесполезно, когда у вас есть пример кода по всему Интернету, использующий машинный код SQL-LICENSED. По сути, вам нужно создать веб-сервис, который будет взаимодействовать с вашим сервером SQL, чтобы программно запускать ваши пакеты служб SSIS. Вы не можете выполнить их из чистого кода .NET, если на исполняющей машине не установлена ​​лицензия SQL. Насколько это нереально? Действительно ли Microsoft ожидает, что SSIS будет использоваться с компьютеров, на которых требуется установка SQL-сервера? Какая полная трата двух месяцев.

Моя компания никогда больше не будет использовать SSIS из-за этой маленькой надписи.


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

+1: да Опыт разработки служб SSIS - это тоже кошмар. Вероятно, есть как минимум полдюжины лучших способов выполнить ETL.
Джим Г.


10

Добавив несколько «забавных» пасхальных яиц в код, который я написал, перед тем, как отправиться в отпуск на 2 недели. Я думал, что буду единственным человеком, который прочтет это, когда вернется, это заставит меня посмеяться и быть готовым перекодировать это.

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

Mmmmmm ...


1
ИМО, это "Хорошая работа, сэр!"

18
Совсем недавно моя команда высмеивала меня за сообщения трассировки, такие как «addin 'th'value (p) t'yer table!» Я сказал: «Послушайте, они заставили меня работать в Talk Like A Pirate Day, они заслуживают того, что получают.

3
Arr, ваши журналы искать keel'haulin!

10

Использование ASP.Net Themes, когда обычная старая CSS-папка работала бы хорошо.


Да, да!

1
Этот ответ может быть сокращен до «Использование ASP.NET»
finnw

Скины полезны для настройки CssClass по умолчанию.
мин

8

Быстрый путь к тому, чтобы заставить некоторый код работать, а не правильный путь (немного общий, но мы назовем это абстракцией и, следовательно, «правильным» ответом).


7

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

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

Итак, я дал им то, что они просили. По крайней мере, это работает , но база данных странно разработана:

  • Много ненужной нормализации. Одна запись, содержащая 5 или 10 полей, разбивается на 3 или 4 таблицы. Я могу с этим справиться, но лично я хотел бы, чтобы все поля 1: 1 были объединены в одну таблицу.

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

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

  • Первичные ключи содержат метаданные, например, если первичный ключ varchar оканчивается на «D», мы рассчитываем счета-фактуры, используя один набор значений, в противном случае мы рассчитываем его с другим набором. Было бы разумнее перенести эти метаданные в отдельный столбец или перетащить набор значений для расчета в другую таблицу.

  • Внешние ключи часто идут в более чем одну таблицу, так что внешний ключ, заканчивающийся на «M», может ссылаться на нашу таблицу учетных записей, в то время как внешний ключ, заканчивающийся на «A», может ссылаться на нашу таблицу автоматических учетных записей. Было бы проще разделить данные на две таблицы, MortageData и AutoInsuranceData.

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


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

7

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


+1: Да, я был там ... И как только я понял, что n00bs не будет обновляться, я начал планировать свой выход на более зеленые пастбища.
Джим Г.

И так я и сделал, просто ушел на пенсию в следующем месяце!
виноградные лозы

6

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

Когда мы представили наш проект для оценки, и один из преподавателей спросил неизбежного: «Если бы вам пришлось делать это снова, что бы вы сделали по-другому?» Я сразу понял ответ: «Я бы использовал исключения, вот для чего они здесь».


Аааа радости изобретать велосипед! :-) Забавно.

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

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

@jacob - Я согласен с вашим мнением, что исключения должны использоваться для вещей, которые вы можете предсказать (например, исключительные условия), но из того, что я видел (и не являюсь программистом Java), Java, похоже, использует исключения для всего под солнцем. Таким образом, использование исключений в коде Java может рассматриваться как противоречащее потоку языка.

6

Не мой выбор метода, но я создал XSLT для преобразования XML-файла на основе строк в HTML-отчет на основе столбцов.

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

В конце я заменил крошечный скрипт на C #, который сделал то же самое.


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

Ага. Заменено чье-то огромное дерево XSLT-файлов несколькими простыми функциями VB.NET. Очень приятно, особенно когда в XSLT было невозможно выполнить следующий запрос на изменение клиента.

Я обнаружил, что большинство программистов считают XSLT плохим выбором просто потому, что не понимают его. Это чрезвычайно полезно для небольшого набора проблем, гораздо более эффективно, чем многие другие решения. С другой стороны, он используется ЧАСТО слишком часто, и в основном НЕ в этом небольшом наборе проблем ...
AviD

6

пытаясь использовать все новые технологии (чтобы изучить новые технологии), хотя это даже не требуется ..


5

Я не потратил достаточно времени, чтобы оценить бизнес-модель. Я сделал то, что просил клиент, но через 6-12 месяцев мы оба пришли к выводу, что это следовало сделать по-другому.


4

Проектирование без спецификации.


3
Спецификации не всегда возможны

Должно быть «Внедрение решения без запроса клиента, если это то, что он хотел»; что обычно означает, что вы следовали спецификациям.
dietbuddha

3

Я реализовал подраздел приложения в соответствии с требованиями.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.