Вредные соблазны в программировании


97

Просто любопытно, какие соблазны в программировании оказались действительно вредными в ваших проектах?

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

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

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

Каковы ваши демоны программирования, и как вы их избегаете?


19
Я нахожу смешным, что никто не смог ответить на вторую часть вашего вопроса - «[и] как вы их избегаете?».
Крейг,

3
Кто-нибудь заметил, что это был главный вопрос на SE весь день.
msarchet

+1 за "... тратить часы на изменение макета интерфейса ..." Я слишком часто попадаю в эту ловушку.
7

Ответы:


67

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

Обновить:

См. « Грех № 1 - преждевременное обобщение » для более подробного описания.


6
Я ненавижу, когда это делают астронавты архитектуры!
Оз

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

+1 «Исследование великих дизайнеров показало, что все они были хороши в ожидании перемен» (Code Complete 2). Хорошо, когда можно сказать, какие изменения возможны. Затем вы можете решить, стоит ли что-то приобретать, решив более общий случай на раннем этапе - сэкономит ли это время позже. Иногда это не стоит того, чтобы потом было так же легко изменить код.
MarkJ


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

197

«Мы вернемся к этому и исправим это позже. Нам просто нужно, чтобы это работало сейчас!»


16
Это абсолютный дьявол.
alesplin

6
Я бы дал тебе +100 за это, если бы мог. «Позже» НИКОГДА НЕ ПРОИСХОДИТ. Делай вещи правильно с первого раза или не делай вообще.
quick_now

12
не является ли это дополнительным расходом часов на рефакторинг плохого кода? Мы можем разделить мир на программистов, которые «исправят это позже», но не сделают этого, и на программистов, которые пытаются сделать все правильно с первого раза, а затем тратят часы на «рефакторинг плохого кода».

6
перефразируйте это как «Мы ​​вернемся и исправим эту следующую итерацию », и это звучит гораздо более структурированно
Chris S

4
Вы должны сделать это. Если вы потратите все свое время на то, чтобы сделать его идеальным, оно никогда не отправится. Завершите проект, затем отполируйте его.
Zan Lynx

105

Крайний срок оооочень далеко, у меня есть более чем достаточно времени, чтобы сделать это, так почему бы не потратить немного времени на серфинг в Интернете?


72
замените «web» на «programmers.stackexchange.com» :)
davidhaskins

1
Есть ли что-нибудь еще в Интернете, что стоит прочитать? Я забыл, что было что-то еще!
Джеймс Маклеод

3
aka 'Черт возьми, Minecraft'
johnc

1
@ Давид, это только отправная точка в Интернете - вопрос в том, как далеко вы продвинулись ...

Я бы сказал, что из-за Agile это уже не так.
vartec

103

«Это просто отбрасываемый код для проверки концепции. Как только он им понравится, я действительно сделаю это хорошо».


13
Это называется быстрой разработкой приложений; и это никогда не работает в деловой среде. :)
Джон Крафт

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

6
Я работаю в сфере финансов, и RAD продолжает развиваться, особенно в VBA / Excel. Хотя есть ловкость, RAD не обязательно означает небрежный.
Ян

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

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

74
  1. Рефакторинг части кода за несколько дней до релиза.
  2. Интернет: самое большое отвлечение из всех.
  3. Новые технологии : не могу держать руки подальше от новых технологий.
  4. Оптимизировать: оптимизировать, оптимизировать. .. и более оптимизировать
  5. Совершенство : никогда не был доволен кодом.
  6. ТОДО: Нехватка времени, что никогда не будет сделано.
  7. Оценка времени: многие PM не воспринимают это как «оценку». Они принимают как факт.
  8. Обещания: давать слишком много обещаний.

1
Когда-то работал над проектом, в котором было 100 человек в большой комнате, и только на двух общих компьютерах был интернет. Производительность была очень высокой. Руководство дало всем доступ в интернет и удивлялось, почему объем работы сократился вдвое
quick_now

2
Что касается оценки времени ... очень многие менеджеры считают ее отправной точкой в ​​переговорах (например, переговоры о цене). Те, кто воспринимают это как ошибочный факт, но на самом деле выше среднего ...
dbkk

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

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

55

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


6
Иногда существующие структуры и библиотеки помечаются Verboten большими красными буквами IT Legal.
Кристофер Махан

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

«но на это уйдет всего неделя, и наш фреймворк будет делать именно то, что мы хотим, бесплатный онлайн, вероятно, полон ошибок»

2
@Christopher: Тогда это будет хорошей причиной для переопределения (или поиска другой библиотеки с приемлемой лицензией). Но слишком часто причиной повторной реализации является просто NIH ...
Донал Феллоуз

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

48

Мои текущие демоны: преждевременная оптимизация и перегрузка.

И я до сих пор не могу избежать их на 100% ...


10
+1 за переподготовку. Однажды я написал целую «инфраструктуру конфигурации» с «адаптерами параметров конфигурации» для файлов .ini, файлов XML, таблиц базы данных и сетевых сокетов (потому что каждый хочет разместить веб-службу конфигурации, верно?)
TMN

8
Преждевременная чрезмерная инженерия?
Кристофер Махан

@ Крис "преждевременный перерабатывающий" тоже относится. Это упоминалось и в других ответах . Я знаю, это одно из моих изгнаний.
Мэтью Шарли

Как насчет преждевременной чрезмерной оптимизации
мегаинжиниринга

4
Это мое. Я возлагаю вину на управление, предоставляя мне свободные сроки правления и далекое будущее и не ограничивая себя конкретными компонентами.
Ктулху

46

Чрезмерно оптимистичные оценки

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

В конце концов, ваша кишка, вероятно, уже слишком низкая!


13
Когда они спрашивают вас, действительно ли это займет так много времени, просто скажите «да», а затем сидите в тишине, пока они не почувствуют неловкость ...
PeterAllenWebb

4
Мой профессор колледжа однажды сказал мне: «Выясни свою лучшую оценку, а затем удвой ее». Пока это работает для меня.
zzzzBov

2
Или попробуйте подход SMBC .
детально

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

2
Планирование на основе фактических данных может помочь в решении
Рей Миясака

33

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

Чтобы попытаться доказать, насколько вы хороший разработчик.

Считать код, который вы написали, своим.


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

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


31

Самый худший соблазн:

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

Угадай что, это действительно больно. :)

перейти к


11
«Исправления шлюза»
Марк C

4
Использование gotoоператора приведет к атаке хищника.
Макс. Вечера

1
@Maxpm: Хорошее мышление! В комплекте.
Горан Йович

1
@ Марк C, что такое исправление шлюза? Мой Гёглефу недостаточно хорош.



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.

РЕДАКТИРОВАТЬ Не понял, вопрос требует от нас, чтобы найти решения.

1) Добавить больше возможностей Просто не делайте этого. Работайте со своим бизнесом, маркетингом, учредителями, консультантами и т. Д. И разберите ваше приложение только на 1 вещь.

Читайте о Твиттере, Groupon и т. Д. О том, как они просто сокращают количество вещей до одного, что привело к их успеху.

Если вы думаете, что это работает, только если вы хотите строить большие компании, подумайте еще раз. Ctrl + F для этой строки «Чем больше функций я добавляю в программное обеспечение, тем хуже оно продается. (Это, само собой разумеется, крайне не интуитивно понятно большинству разработчиков программного обеспечения.)» В этой ссылке

2) Конкурс имеет эту особенность. Так что это должна быть особенность

Смотрите решение 1

3) Конкурс не имеет этой функции. Так что это отличительная особенность

Смотрите решение 1

4) Решение бизнес-задач с большим количеством программирования.

Если вам нужно нанять кого-то, чтобы он научил вас, дал консультацию или сделал это для вас, а затем задокументируйте, как он это сделал, чтобы вы могли сделать это самостоятельно в следующий раз. ПРОСТО СДЕЛАЙ ЭТО!! Не переписывайте код, не проходите GO, не собирайте $ 200.

5) Решение маркетинговой проблемы с большим количеством программирования.

Если люди не понимают, что вы продаете, это проблема маркетинга. Вернитесь к решению 1 и поверните.

6) Решение проблемы производительности с большим количеством программирования

Подождите.

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

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

Умножьте свою оценку на вашу почасовую ставку.

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

Выберите наиболее экономически эффективное решение.

Придерживаться его.

7) Планирование кодировать, но еще не кодировать, потому что вы хотите «сделать это правильно»

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

8) Кодирование грязной версии и обещание, что вы «улучшите это позже», но никогда не возвращались, чтобы «сделать это лучше»

Настройте файловую систему Tickler в GTD. и настойчиво следить за Выполните все обещания для себя и других.

9) Не делать макет или карту сайта, потому что это "так хлопотно".

Потратьте 75 долларов США на настольную версию бальзамического макета. Я знаю это, потому что я купил это 3 недели назад. Это заставило меня переделать мои макеты, потому что я чувствую себя художником, архитектором и провидцем все в одном, хотя мой рисунок в реальном мире - отстой. Шрифт, используемый в balsamiq, подсознательно напоминает вам, что это просто макет, а не каменный, который помогает вам в RAD.

Конец РЕДАКТИРОВАТЬ


+1 ответил (а) на этот вопрос, но мне было трудно его прочитать. Я не очень понимаю контекст первых 9 пунктов. Не могли бы вы уточнить? Тем не менее, хорошая работа.

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

Пункты 6-9 относятся больше к невротическим тенденциям программиста. Я где-то читал (не могу найти), что дизайнер всегда подходил к любой проблеме с дизайнерским решением; маркетолог с маркетинговым решением; и программист с решением кода. Да, страшное «Когда у тебя золотой молот, все, что ты видишь - это синдром гвоздей». Это особенно очевидно в пункте 6) Решение проблемы производительности с большим количеством программирования
Ким Стэкс

@MattFenwick извините, если вы запутались с моим именем. Я изменил свой никнейм после написания этого ответа. Я вижу, что ваш опыт больше связан с исследованиями. Мой ответ во многом основан на моем опыте разработки решений для продажи. Но я уверен, что есть определенные сходства между моей работой и вашей, так как мы оба занимаемся программированием.
Ким Стеки

17

Несколько сортов пива помогут мне работать лучше и дольше.


11
Подожди ... ты имеешь в виду, что нет? ( xkcd.com/323 )
Крейг,

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

4
@adam, тебе потребовался год выпить, чтобы стать инженером?

17
Кодирование во время питья пива помогает вам создавать невероятно популярные социальные сети, которые будут стоить миллиарды через пару лет. Это правда, я видел это в кино.
Janosrusiczki

1
@ Китчед: Да! Особенно, если у вас есть чей-то уже существующий дизайн, чтобы сорваться.
Мейсон Уилер

16

«Да, я могу изменить этот гигантский беспорядок 2000 спагетти линий в один день ...»


13
В качестве альтернативы: «новый парень [который абсолютно ничего не знает о программном обеспечении или структуре его кода] ничего не делает, он может это исправить». Бонусные очки, когда парень даже не использовал язык, на котором написан код.
wildpeaks

16

«Я могу обойтись без теста для этого. Это слишком сложно проверить».

и это злой брат,

«У меня должен быть тест для этого, независимо от того, насколько сложен тест, чтобы написать или понять».


2
Если тест трудно написать, возможно, вы не программируете его правильно :)
Мерлин Морган-Грэм,

2
@ Мерилин Морган-Грэм, совершенно верно. Но есть некоторые области, такие как параллелизм, которые просто сложнее проверить.
Уэйн Конрад

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

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

15

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

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


Уточнение ... Под «оптимистической оценкой задачи» вы подразумеваете «синдром легкого дерьма», верно? :)
Эван Плейс

@ Эван Плейс - точно. Как «о, это так тривиально», а затем поискать каждую букву вашего кода после того, как вы начали реальное кодирование.
Никита Барсуков

13

«Намного« проще » переопределить функциональность с нуля, чем понимать существующий код».


2
Да, c2.com/cgi/wiki?RewriteCodeFromScratch утверждает, что это одна из вещей, которые вы никогда не должны делать.
Дэвид Кэри

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

10

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


10

NIH - не изобретено здесь

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

Экономия времени может быть настолько огромным , что даже если в 9 раз из 10 , то решение третьей стороной следует избегать, я должен быть достаточно объективным , чтобы реализовать тот , который будет работать.


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

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

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

@Newtopian имеет смысл мое объяснение выше, почему? Моя попытка достичь середины проста, чтобы быть более объективным при оценке и поиске сторонних решений.
Николь

9

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

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


Если продукта еще нет, будут ли данные для копирования?
Свиш

Если нет данных, всегда есть бумага. Здесь также помогут записи компании.
burnt_hand

9

Существует должен быть библиотека , которая делает это где - то синдром.

тесно связаны с

Плагин Фетиш


2
Мне всегда кажется, что я могу найти библиотеку, которая "делает это". Моя проблема часто заставляет их работать так, как рекламируется. :(
Бен Л

Легко найти библиотеку - Трудно найти библиотеку, в которой есть хорошие модульные тесты
burnt_hand

8

Перфекционизм убивает; вероятно, главная причина, почему проекты не увенчались успехом.


Я предполагаю, что это правда, но я никогда не участвовал в проекте, который потерпел неудачу или даже опоздал по этой причине.
PeterAllenWebb

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


7

Переписывание вместо рефакторинга.


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

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

6

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


5

Автоматизация всего на то, что на обслуживание инструментов уходит больше времени, чем на реальную работу.

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


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

4

Какие у тебя демоны программирования?

Помимо того, что некоторые другие упомянули.

Расстановка приоритетов : игнорирование высокоприоритетной работы над проектом и работа над другими вещами в проекте, потому что они интереснее!

Как вы их избегаете?

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


3

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

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

О, вот ревизии клиента, они просто хотят изменить несколько незначительных вещей *

(* основные функции совершенно разные)

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

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


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

1
@Ben: Если бы только это было под нашим контролем!
Seseseacat
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.