Найбільш жалюгідне рішення щодо дизайну чи програмування, яке ви прийняли? [зачинено]

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

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

Дякуємо, що поділилися своїм досвідом.

Ігноруючи YAGNI , знову і знову ...

"Я зроблю це пізніше"
"Пізніше" ніколи не приходить.

C ++, множинне віртуальне спадкування у формі ромба . Ви отримуєте ідею.

Налаштування в додатку приємно. Занадто велика налаштованість - це кошмар, який потрібно використовувати та підтримувати.

З однієї з моїх помилок я дізнався, що нормалізацію БД не слід сліпо слідувати. Ви можете, а в деяких ситуаціях ОБОВ'ЯЗКОВО вирівняти столи.

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

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

Я думаю, це форма передчасної непотрібної та сліпої оптимізації. Як ніби використання одного чару врятує світ у ці дні. Крім букерів Y / N в базах даних, які не підтримують булеві / бітові.

Не розробляючи належного шару доступу до даних і не маючи sql скрізь у своєму коді, просто щоб отримати щось "швидке" та працює. Згодом, коли проект почав розширюватися, а вимоги змінилися, він став кошмаром. Я тоді не знав, що таке DAL.

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

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

2 місяці сну 3 години на ніч навчили мене просто не вміти.

Вибір класів Microsoft Foundation (MFC) для написання Java IDE.

Це було не моє рішення (я приєднався до компанії дещо пізніше), але десь, де я працював, i18n трохи надто далеко, включаючи переклад усіх їхніх журнальних повідомлень.

Результати:

• Більш болісно додати нові журнали
• Більше витрат на переклад
• Після цього журнали важче читати

На жаль

Повторне винахід колеса

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

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

Моє найгірше дизайнерське рішення? Ще в 1980-х роках я працював над проектом, де нам з’явилася яскрава ідея створити своєрідний шаблон для наших екранів введення даних, який би інтерпретувався під час виконання. Непогане рішення: це зробило вхідні екрани легкими для проектування. В основному просто створіть файл, що нагадує екран введення даних, з деякими спеціальними кодами, щоб визначити, що було міткою, а що полем для введення, та визначити, чи поля введення були альфа- чи чисельними. Тоді я вирішив додати до цих файлів ще кілька спеціальних кодів, щоб визначити, які перевірки слід виконати. Потім я додав більше кодів, щоб дозволити умовну побудову екрана, поле X включалося лише тоді, коли якась умова була істинною і т. Д. Потім я додав більше кодів, щоб зробити просту обробку входів. І т.д. Врешті-решт ми перетворили наш шаблон екрана на нову мову програмування, доповнену виразами, структурами управління та бібліотекою вводу-виводу. А для чого? Ми зробили багато робіт, щоб переосмислити FORTRAN. У нас була полиця з повною кількістю компіляторів для мов, які були краще розроблені та краще перевірені. Якби ми присвятили стільки зусиль, щоб створити продукцію там, де ми насправді мали певний досвід, ця компанія могла б працювати сьогодні.

Занадто ревне застосування YAGNI (яке називається Design by Enumeration в Підводні камені об'єктно-орієнтованого розвитку ) в середовищі, коли будь-яка розсудлива людина може сказати, що вимоги, безумовно, мають змінитися. І міняти повторно.

Якщо ви (важко) зашифрували все точно відповідно до сучасних вимог - при цьому побиваючи тих, хто каже, "чи не могло це бути більш загальним?" з вашим молотком YAGNI - і тоді вимоги різко змінюються (але таким чином, що можна було б обґрунтовано передбачити), то це може бути різницею між тим, що потрібно адаптуватися 2 тижні проти 20 хвилин.

ОНОВЛЕННЯ: Для уточнення, ось надуманий приклад, який не надто далеко від того, що сталося. Переповнення стека було розроблено для підтримки значків, але припустимо, що спочатку вони могли думати лише про чотири значки. Лише чотири, така невелика кількість, тому вони твердо кодували підтримку рівно чотирьох значків за всією логікою на сайті. У базі даних, в інформації про користувача, у всіх відображуваних кодах. Тому що "вам не знадобляться" будь-які значки, про які ви не можете придумати, правда? Припустимо, тоді сайт починає працювати, і люди починають пропонувати нові значки. Кожен знакпотрібно до двох тижнів, тому що існує стільки жорсткого кодування, щоб налаштувати всюди. Але все-таки "Я вам не знадобиться" більше значків, ніж сьогоднішній список, тому ніколи не існує рефакторингу для підтримки загальної колекції значків. Чи зайняла б така родова колекція більше часу? Не багато, якщо вони є.

YAGNI є цінним принципом, але його не слід (ab) використовувати для виправдання поганого дизайну та неналежного жорсткого кодування. Є рівновага, і, маючи досвід, я вважаю, що я наближаюся до цього.

Некомпетентні кадрові ресурси

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

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

Використання послуг інтеграції 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 через цю маленьку друковану «готчу».

Не визначаючи механізм / модель розгортання якомога раніше.

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

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

Мммммм ...

Використання ASP.Net Themes, коли просто звичайна папка CS «CSS» була б чудово.

Швидкий шлях до того, щоб якийсь код працював, а не правильний шлях (трохи загальне, але ми називаємо це абстракцією і, отже, «правильною» відповіддю).

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

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

Отже, я дав їм те, що вони попросили. Принаймні, це сорта працює , але база даних дивно розроблена:

• Багато зайвої нормалізації. Один запис, що містить 5 або 10 полів, розділений на 3 або 4 таблиці. Я можу з цим впоратися, але особисто мені хотілося б, щоб усі поля 1: 1 були виведені в одну таблицю.

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

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

• Первинні ключі містять метадані, так що якщо первинний ключ varchar закінчується на "D", ми обчислюємо рахунки-фактури, використовуючи один набір значень, інакше ми обчислюємо їх з іншим набором. Було б більше сенсу вивести ці метадані в окремий стовпчик або перетягнути набір значень для обчислення в іншу таблицю.

• Іноземні ключі часто переходять до декількох таблиць, так що зовнішній ключ, який закінчується на "M", може посилатися на нашу таблицю облікових записів, тоді як зовнішній ключ, що закінчується на "A", може посилатися на нашу таблицю автоматичних рахунків. Простіше було б розділити дані на дві таблиці, MortageData та AutoInsuranceData.

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

Дотримуючись старішої технології, тому що, здається, занадто багато клопоту, щоб ваші клієнти могли оновити до нової версії .NET Framework, але для створення програмного забезпечення фактично знадобиться більше часу на розробку, оскільки ви не можете використовувати деякі (економію часу) компоненти новіша версія рамки.

Ще в університеті я працював над своїм старшим дизайнерським проектом. Ми з іншим хлопцем писали веб-систему відстеження помилок. (Нічого новаційного, але ми обидва хотіли отримати досвід роботи в Інтернеті.) Ми зробили цю справу з сервлетами Java, і це спрацювало досить добре, але чомусь нерозумно, замість того, щоб вибрати винятки як наш механізм обробки помилок, ми вибрали використовувати коди помилок.

Коли ми презентували наш проект для оцінки, і один із викладачів запитав неминуче: "Якби ти мав це зробити ще раз, що б ти робив інакше?" Я негайно знав відповідь: "Я б використав винятки, саме для цього вони є".

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

Це працювало лише в IE, було повністю неможливо розшифрувати, як це працює. Кожен раз, коли нам потрібно було її розширювати, це було неможливо важким і займало віки.

Зрештою, я замінив крихітний сценарій C #, який зробив те саме.

намагаються використовувати всі нові технології (вивчати нові технології), хоча це навіть потрібно.

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

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

Я реалізував підрозділ програми відповідно до вимог.

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