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

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

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

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

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

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

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

Обновить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я просто сделаю перерыв и посмотрю на stackoverflow.com;)

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

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

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

Забывание этого кода является последним средством решения проблемы .

Характеристика ползучести

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плагин Фетиш

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

Ну, иногда программирование сводит меня с ума.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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