Шкідливі спокуси в програмуванні


97

Що цікаво, які спокуси програмування виявилися справді шкідливими у ваших проектах?

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

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

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

Які ваші демони програмування та як їх уникати?


19
Мені здається жартівливим, що ніхто не зміг відповісти на другу частину вашого питання - "[і] як ти їх уникаєш?".
Крейдж

3
Хтось зауважив, що це питання є головним питанням у СЕ весь день.
msarchet

+1 за "... витратити години на зміну макета інтерфейсу ..." Я занадто часто потрапляю в цю пастку.
7wp

Відповіді:


67

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

Оновлення:

Дивіться " Гріх №1 - передчасне узагальнення " для глибокого опису.


6
Я ненавиджу це, коли це роблять космонавти архітектури!
ozz

13
О, радість метафабрик::

+1 "Дослідження великих дизайнерів виявило, що всі вони хороші в очікуванні змін" (Code Complete 2). Добре вміти розповідати, які види змін можливі. Тоді ви можете вирішити, чи є щось, що можна отримати, вирішивши більш загальний випадок на початку - чи це заощадить час пізніше. Іноді це не варто, було б так само легко змінити код пізніше.
MarkJ


1
Це. Я покладаю провину на те, що створення гарного, узагальненого та повторно використовуваного коду дуже задовольняє, особливо якщо сама проблема не є дуже складною та / або є лише переробкою того, що ви робили раніше. Справа в суті, загальні операції з базою даних CRUD (користувальницький інтерфейс, реагування на дії користувача, щось з DB, thar).
Cthulhu

197

"Ми повернемося до цього і вирішимо це пізніше. Нам просто потрібно, щоб він працював зараз!"


16
Це абсолютний диявол.
alesplin

6
Я б дав вам +100 за це, якби міг. "Пізніше" НІКОЛИ НЕ БУДЕ. Робіть речі правильно з першого разу чи не зовсім.
quick_now

12
Хіба це не доповнення витрачених годин на рефакторинг поганого коду? Ми можемо розділити світ на програмістів, які "виправлять це пізніше", але не роблять цього, і програмістів, які намагаються виправити це в перший раз, а потім витрачати години на "рефакторинг поганого коду".

6
переформулюйте це слово "Ми повернемося та виправимо цю наступну ітерацію ", і це звучить набагато більш структуровано
Chris S

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

105

Кінцевий термін soooooo далеко, у мене більше ніж достатньо часу для цього, так чому б не витратити трохи часу на серфінг в Інтернеті?


72
замініть "web" на "programmers.stackexchange.com" :)
davidhaskins

1
Чи є ще щось в Інтернеті, яке варто прочитати? Я забув, що ще є!
Джеймс МакЛейд

3
aka 'Чорт ти, Minecraft'
Johnc

1
@david, це лише вихідна точка в Інтернеті - питання в тому, як далеко ви дістанетесь ...

Скажу, це вже не так дійсно через Agile.
vartec

103

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


13
Це називається швидким розвитком додатків; і це ніколи не працює в діловому середовищі. :)
Джон Крафт

12
Забавно, що для мене це навпаки - я просто не можу змусити себе писати викинутий код, навіть коли це саме те, що потрібно.
День

6
Я працюю у фінансах і RAD все ще сильно розвивається, особливо VBA / Excel. Хоча в цьому є хитрість, RAD не повинен означати неохайний.
Ян

5
І іноді додаток, який ви провели два роки, вдосконалюючи навички коду, тому що хтось вище вгору по сходах вирішив "ой, ми не можемо цього зробити" або іншу версію "неважливо".
ПСУ

12
Це. Я: "Це лише моя доказова концепція. Якщо вам це подобається, ми напишемо виробничу версію". Менеджер: "Ваша версія працює, давайте доставимо її!" Я: "Ну, це не стосується всього використання ca ... ви вже відправляли, чи не так?"

74
  1. Переробляючи частину коду за кілька днів до випуску.
  2. Інтернет: найбільше відволікання всіх.
  3. Нова технологія : Не можу відмовитися від нової технології.
  4. Оптимізувати: оптимізувати, оптимізувати. .. та інше Оптимізуйте
  5. Вдосконалення : ніколи не задовольнявся кодом.
  6. TODO: Не вистачає часу, які ніколи не будуть зроблені.
  7. Оцінка часу: багато прем'єр-міністрів не сприймають це як "оцінку". Вони приймають як факт.
  8. Обіцяння: Давати занадто багато обіцянок.

1
Колись працював над проектом, який мав 100 людей у ​​великій кімнаті, і лише 2 спільних ПК мали Інтернет. Продуктивність була дуже високою. Керівництво дало всім Інтернет і поцікавилося, чому випуск роботи зменшився вдвічі.
quick_now

2
Що стосується оцінки часу ... так багато менеджерів сприймають це як вихідну точку переговорів (як торг за ціну). Ті, хто сприймає це як факт, оману, але насправді вище середнього ...
dbkk

@quickly_now Виключення мережі, ймовірно, працює для мирських завдань, таких як введення даних або звичайні виправлення, де не потрібно нічого шукати. У багатьох звичайних речах (наприклад, пошук документів API / прикладного коду) Google є вашим другом - потрібно 5 разів більше часу, щоб зрозуміти це самостійно. Крім того, якщо люди не мотивовані і хочуть відволіктись, вони знайдуть способи.
dbkk

@dbkk - так, до певного моменту. Це було все в Ada, не було API, щоб шукати, це було на спеціалізованому обладнанні та національній безпеці. Введення в це середовище некласифікованих підключених до Інтернету машин було також кошмаром безпеки.
quick_now

55

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


6
Іноді існуючі рамки та бібліотеки позначаються Верботен великими червоними літерами ІТ-правом.
Крістофер Махан

22
І звичайно, протилежна спокуса: використовувати незнайомі рамки або бібліотеку і припускати, що вона зробить те, що потрібно, і все пройде гладко.
Carson63000

"Але для того, щоб писати, знадобиться лише тиждень, і наша рамка зробить саме те, що ми хочемо. Безкоштовна онлайн-версія, ймовірно, повна помилок"

2
@Christopher: Тоді це буде вагомим приводом для повторного втілення (або пошуку іншої бібліотеки з прийнятною ліцензією). Але занадто часто причиною поповнення є саме NIH…
стипендіати

@Carson: +1 :-)
Макке

48

Мої повторювані демони: передчасна оптимізація та переобладнання.

І я все ще не можу їх уникнути на 100% ...


10
+1 для переобладнання. Я колись написав цілу "конфігураційну рамку" з "адаптерами параметрів конфігурації" для файлів .ini, XML-файлів, таблиць баз даних та мережевих сокетів (адже всі хочуть розмістити веб-службу налаштування, правда?)
TMN

8
Передчасне перевиробництво?
Крістофер Махан

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


4
Це моє. Я покладаю провину на менеджмент, який дає мені вільні терміни управління / далекі майбутні терміни і не дає собі термінів для конкретних компонентів.
Cthulhu

46

Занадто оптимістичні оцінки

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

Зрештою, ваша кишка вже ймовірно занизька!


13
Коли вони запитують вас, чи дійсно це займе так довго, просто скажіть так, а потім сидіть мовчки, поки вони не відчують ніяковості ...
PeterAllenWebb

4
Колись мій професор коледжу сказав мені: "Вигадайте свою найкращу оцінку, а потім подвійно". Це працювало для мене поки що.
zzzzBov

2
Крім того, спробуйте підхід SMBC .
detly

4
Один із моїх старих начальників втричі оцінив розробників, потім домовився про подвійне використання з клієнтами. Клієнти думали, що вони уклали угоду, розробники отримали потрібний час, навіть якщо вони цього не знали. Безпрограшна!
DaveE

2
Планування на основі доказів може допомогти у цій проблемі: joelonsoftware.com/items/2007/10/26.html
Rei Miyasaka,

33

Використовувати технологію / інструмент / мову у своєму проекті виключно тому, що ви тільки що це засвоїли.

Щоб спробувати довести, наскільки ви хороший розробник.

Щоб вважати код, який ви написали, як ваш.


Якби я міг лише підсилити це кожен раз, коли робив це. На щастя, половина рішень виявилася досить непоганою. Половина ні.
День

Або той, якого ви ще зовсім не навчилися. Тільки не забудьте пристебнути шпори, тому що це буде довга їзда.
Еван Плейс


31

Найгірша спокуса:

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

Вгадайте, що, боляче. :)

йти до


11
"Виправлення шлюзу"
Марк С

4
Використання gotoзаяви призведе до нападу грабіжника.
Maxpm

1
@Maxpm: Гарне мислення! У комплекті.
Горан Йович

1
@ Марк C, що таке виправлення шлюзу? Мій gøøgle-fu недостатньо хороший.



23

Функція повзучість

Складіть план, дотримуйтесь його і розгорніть. А потім поверніться і додайте речі, про які люди просять.

Я бачив це знову і знову. Ви сідаєте, розробляєте дизайн і починаєте кодувати. Користувачі чують заплутану дурницю щодо того, що їх улюблена функція "відсутня", і вони починають лобіювати її. Ваш начальник вимагає, щоб ви додали його о 11-й годині, він зупиняє розгортання, він вносить помилки скрізь, і через 3 місяці, як тільки всі влаштуються, вас попросять видалити, тому що ніхто не може зрозуміти, чому ви ставите ця хитра ретро особливість в першу чергу! Не могли б ви сказати, що решта дизайну зробила це безглуздим?


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

20
  1. Додайте більше функцій

  2. Конкуренція має таку особливість. Отже, це обов'язково має функцію, отже, більше програмування, ніж аналіз стратегії, позиціонування тощо.

  3. У змагання НЕ є ця особливість. Отже, це відмінна особливість, отже, більше програмування, ніж аналізу стратегії, позиціонування тощо.

  4. Розв’язання бізнес-проблеми за допомогою більше програмування. наприклад, кращого досвіду в управлінні сервером linux, на якому розміщено ваш веб-сайт, неможливо отримати за допомогою програмування додаткових функцій. Іноді потрібно просто навчитися виправляти проблему, а не перекодувати всю справу в C # .Net

  5. Вирішення маркетингової проблеми з більшою кількістю програмування. наприклад, зловживаючи концепцією фіолетової корови Сет Годіна, що ви опосередковано вирішуєте маркетингову проблему, програмуючи додаткові функції у свій продукт, щоб зробити його "фіолетовою коровою". Іноді це просто мутант-чудовисько.

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

  7. Планування кодування, але ще не кодування, оскільки ви хочете "правильно його"

  8. Кодування брудної версії та обіцянка, що ви "зробите це краще пізніше", але ніколи не поверталися до "покращення"

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

Сповідь: Я особисто допустив помилки 1, 3, 7, 8. Я також зробив 2, 4, 5, 6, але часто обманював себе, що цього не робив.

Наразі я виправляю 9.

EDIT Не усвідомлював, що питання вимагає від нас рішення.

1) Додайте більше функцій Просто не робіть цього. Працюйте зі своїм бізнесом, маркетингом, засновниками, радниками тощо та зніміть заявку лише на одну річ.

Почитайте про твіттер, Групон тощо про те, як вони просто знімають речі до 1 речі, що призвело до їх успіху.

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

2) Конкурс має цю особливість. Отже, це обов'язкова особливість

Дивіться рішення 1

3) Конкурс НЕ має цієї функції. Отже, це відмінна риса

Дивіться рішення 1

4) Розв’язання бізнес-задачі за допомогою більше програмування.

Якщо вам потрібно найняти когось, щоб навчити вас, дати консультацію чи зробити це для вас, а потім документуйте, як він це зробив, щоб ви могли це зробити самостійно наступного разу. ПРОСТО ЗРОБИ ЦЕ!! Не переписуйте код, не пропускайте GO, не збирайте 200 доларів.

5) Розв’язання маркетингової проблеми з більшою кількістю програмування.

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

6) Розв’язання проблеми продуктивності за допомогою більше програмування

Зачекайте.

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

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

Помножте оцінку на годинну ставку.

Тепер перегляньте альтернативні рішення: передайте аутсорсинг, купіть рішення позачергово, не робіть нічого з цього приводу тощо

Виберіть найбільш економічне рішення.

Дотримуйтесь цього.

7) Планування кодування, але ще не кодування, оскільки ви хочете "правильно"

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

8) Кодування брудної версії та обіцянка, що ви «зробите це краще пізніше», але ніколи не поверталися до «покращення»

Налаштування файлової системи тикер в GTD. і агресивно стежити. Виконуйте всі обіцянки перед собою та іншими.

9) Не робити макет чи мапу сайту, тому що це "так клопітно".

Потратьте витратити 75 доларів на макет комп’ютерів balsamiq. Я знаю це, тому що я купив його 3 тижні тому. Це змусило мене переробити макети, тому що я відчуваю себе художником, архітектором та провидцем все в 1, хоча мій малюнок у реальному світі відстойний. Шрифт, використаний у balsamiq, підсвідомо нагадує вам, що це просто макет, а не встановлений у камені, який допомагає вам у RAD.

Кінець EDIT


+1 відповів на цю відповідь, але мені було важко прочитати. Я не дуже розумію контекст перших 9 пунктів. Ви б проти зауважити? Все-таки приємна робота.

@MattFenwick Привіт, дякую за ваш +1. Бали 1-5 зазвичай застосовуються в сценарії створення товару для продажу, хоча ви також можете застосовувати його до сценаріїв, коли ваша тенденція до пошуку найкращої відповіді призводить до широкого дослідження попереднього рівня техніки. Наприклад, у дослідженні.
Кім Стек

Бали 6-9 більше стосуються невротичних тенденцій програміста. Я десь прочитав (не можу його знайти), що дизайнер завжди підходив би до будь-якої проблеми з дизайнерським рішенням; маркетолог з маркетинговим рішенням; і програміст з рішенням коду. Так, жахливий "Коли у тебе золотий молоток, все, що ти бачиш, - синдром нігтів". Це особливо очевидно в пункті 6) Вирішення проблеми продуктивності за допомогою більшої кількості програмувань
Кім Стек

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

17

Пара пива допоможе мені краще і довше працювати.


11
Зачекайте ... ви маєте на увазі це не так? ( xkcd.com/323 )
Craige

4
@Craige: після 21-річного досвіду пиття та 20-річного досвіду роботи як професійного інженера-програміста я все ще працюю над частиною калібрування.
Адам Кросленд

4
@adam, тобі знадобився рік випити, щоб стати інженером?

17
Кодування під час пиття пива допоможе вам створити надзвичайно популярні соціальні мережі, які коштують мільярди за пару років. Це правда, я це бачив у фільмі.
janosrusiczki

1
@Kitsched: Так! Особливо, якщо у вас є чийсь раніше існуючий дизайн, щоб зірвати його.
Мейсон Уілер

16

"Так, я можу відтворити цей гігантський безлад 2000 спагеті рядків за один день ..."


13
Як варіант: "новий хлопець [який абсолютно нічого не знає про програмне забезпечення або структуру його коду] нічого не робить, він може це виправити". Бонусні бали, коли хлопець ніколи навіть не використовував мову, якою написаний код.
wildpeaks

16

"Я можу обійтись без тесту на це. Це занадто важко перевірити".

і це злий брат,

"Я повинен мати тест на це, незалежно від того, наскільки важко тест написати або зрозуміти".


2
Якщо тест важко написати, ви, можливо, не програмуєте його правильно :)
Мерлін Морган-Грем

2
@Merylyn Morgan-Graham, цілком правда. Але є деякі сфери, такі як паралельність, яку просто важче перевірити.
Уейн Конрад

1
@Merlyn: Якщо ви виявили, що ви пишете тренажер інструкцій, щоб ви могли змусити контекстний перемикач в потрібних місцях, то, ймовірно, ви зайшли занадто далеко в тестуванні на одночасність. :)
Zan Lynx

1
@Zan: Я погоджуюсь - у потрібний момент я би натиснув назад на розробники і спробував би змусити їх переробити код і дозволити мені вставити макети. Я працюю проти язиків високого рівня, де ми дивимось на Big-O, оптимізуємо вузькі місця, потрібно думати про одночасність здебільшого на цілісність даних, а не на швидкість, а також відправляємо (і часто жодну з цих, тому що це просто досить швидко з ящик).
Мерлін Морган-Грем

15

Прокрастинація та оптимістична оцінка завдань - це мої найбільші гріхи.

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


Пояснення ... Під "оптимістичною оцінкою завдань" ви маєте на увазі "синдром легкого лайна", правда? :)
Еван Плейс

@Evan Plaice - точно. На кшталт "о, це так тривіально", а потім гуглити кожну букву коду після того, як ви почали фактичне кодування.
Микита Барсуков

13

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


2
Так, c2.com/cgi/wiki?RewriteCodeFromScratch стверджує, що це одна з "Речей, яких ти ніколи не повинен робити".
Девід Кері

Робота над відкритим кодом допомагає цій тенденції. Я особисто дивився на патчі перед очима, а потім пішов уперед і написав власну реалізацію лише для того, щоб зрозуміти, що він майже ідентичний патчу (навіть після вдосконалення / рефакторингу мого коду). Смішно, як це працює.
Еван Плейс

10

Одне з масово шкідливих спокус, від якого я зазнав проекту, - це «Внутрішній ефект платформи». Це підхід, який архітектори, які вже давно пішли, виклали у своїй нескінченній мудрості, яка створила проект, який генерує близько 20 мільйонів доларів на рік, але коштує 60 мільйонів на оновлення та підтримку (очевидні цифри, очевидно, але це величина проблеми).


10

NIH - тут не винаходили

Мені справді важко дати справедливим шансам стороннім рішенням. Усі повинні бути скептично скептичними щодо сторонніх рішень, які не були розроблені під них, але мені важко бути на 100% об'єктивним.

Економія часу може бути настільки величезним , що навіть якщо в 9 разів з 10 , то рішення третьою стороною слід уникати, я повинен бути досить об'єктивним , щоб реалізувати той , який буде працювати.


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

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

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

@Newtopian чи має моє пояснення вище сенс, чому? Моя спроба спробувати досягти середини проста, бути більш об'єктивною при оцінці та пошуку сторонніх рішень.
Ніколь

9

Проектування, кодування та / або одиничне тестування щодо наданих "зразкових даних" замість аналізу копії фактичної бази даних клієнтів. Кінцевий термін був коротким, і вони продовжували говорити, що приходить, але цього ніколи не було. Коли його розгорнули, вибух був вражаючим. Дійсно, хто міг би очікувати, що клієнт матиме 3 батьківських клієнта.

Я ніколи більше не розпочну проект, доки не отримаю копію реальних даних.


Якщо товару ще немає, чи будуть якісь дані копіювати?
Свиш

Якщо немає даних, завжди є папір. Тут також допоможуть записи компанії.
спалений_рук

9

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

тісно пов'язані з

Фетиш плагіна


2
Мені завжди здається, що я можу знайти бібліотеку, яка "робить це". Моя проблема часто змушує їх працювати так, як рекламується. :(
Бен Л

Легко знайти бібліотеку - важко знайти бібліотеку, в яку вбудовані хороші одиничні тести
burnt_hand

8

Перфекціонізм вбиває; Мабуть, найбільша причина, що проекти не вдається.


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

Залежить, як ви визначаєте досконалість і на який рівень ви прагнете.
Свиш


7

Переписування замість рефакторингу.


Погодьтеся. Якщо ви готові взяти на себе необхідну кількість зусиль, необхідних для перезапису, майже ВЖЕ завжди краще переробляти. Ще триватиме більше часу, ніж ви думали, але ви робите рефакторинг поступово, правда? Ви можете зупинитися, перш ніж це буде "ідеально".
PeterAllenWebb

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

6

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


5

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

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


Я можу з цим погодитися в принципі, але я ніколи не бачив надмірної автоматизації на практиці. Все-таки це міг бути просто мій досвід.
PeterAllenWebb

4

Які ваші демони програмування?

Крім того, що згадували деякі інші.

Пріоритетність : Ігнорування спочатку пріоритетної роботи щодо проекту та робота над іншими речами проекту, адже вони цікавіші!

Як ти їх уникаєш?

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


3

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

Пізніше, після того як ви закінчили будувати проект, щоб відповідати компі ...

О, ось зміни клієнта, вони просто хочуть змінити кілька незначних речей *

(* основна функціональність зовсім інша)

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

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


2
Візьміть на себе політику, де ви не розпочинаєте розробку, поки не отримаєте підпис клієнта.
Бен Л

1
@Ben: Якби тільки це було під нашим контролем!
sevenseacat
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.