Как вы определяете, что если вы делаете что-то правильно, вам это мешает?

Question

У меня ужасная привычка, на самом деле то, с чем я борюсь прямо сейчас, когда я думаю о лучшем способе сделать что-то - либо рефакторинг, либо что-то, что было бы ОЧЕНЬ НАСТОЛЬКО ОХЛАЖДАЮЩИМ КУЛЕРОМ, или таким лучшим UX, я просто должен это сделать. Даже когда это будет стоить мне времени, и я нахожусь во временном кризисе. Я никогда не знаю, когда сказать: «Нет, для этого нет времени, я могу сделать это позже».

Есть ли линия, которую вы рисуете?

Как и сейчас, мне нужен способ отображения журнальных статей, находящихся в базе данных. Самый простой способ - создать новую страницу .aspx и просто передать идентификатор статьи. УДИВИТЕЛЬНЫЙ способ - это jquery fade в модале, который будет отображать статью. По крайней мере, я так думаю. Не будучи гуру, мне понадобилось бы больше времени, чтобы написать. На следующей неделе у нас нет времени на лишнее дерьмо. Однако я просто не могу заставить себя сделать это простым способом.

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

Answer 1

Сначала я бы пошел быстрым маршрутом.

Напишите страницу ASPX, которая показывает статью, основанную на ID, или даже более прохладную и более SEO-дружественную, слаг Вы сможете уложиться в срок. Тогда я бы начал с удивительного пути jQuery.

Бонус к этому заключается в том, что у вас будет запасной вариант на случай, если у пользователя отключен JavaScript.

Answer 2

Вы говорите о "золотом покрытии". Это очень распространенная и хорошо известная проблема для разработчиков программного обеспечения.

От славного основателя самого StackOverflow:

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

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

Редактировать: Ссылка на другие "классические ошибки" здесь .

Answer 3

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

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

Answer 4

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

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

Мой другой совет: не пытайтесь использовать оба варианта. Если вы создаете базовую версию, придерживайтесь ее и двигайтесь дальше. Если вы попытаетесь сделать и то, и другое, вы действительно напрасно тратите время.

Answer 5

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

Answer 6

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

Answer 7

Подобные вещи абсолютно убивали меня!

Вот мой совет:

• Сделай это простым способом (aspx с параметр id)
• Напишите небольшое доказательство концепция показать клиенту

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

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

Answer 8

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

Если вы делаете что-то как можно более высокого качества, но никогда не выпускаете его, это не «правильный путь». С другой стороны, если вы пишете дерьмо, но получаете его очень быстро, это тоже не «правильный путь». Чтобы сделать что-то «правильным путем», вы должны сбалансировать эти два.

Экономическая фраза, которая приходит на ум: «Качество, цена или скорость производства, выбери два».

Answer 9

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

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

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

Если у вас заканчивается время, если вы занимаетесь Agile, запишите остатки в виде историй и передайте их менеджеру проекта или клиенту.

Answer 10

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

Вы в основном описываете крип характеристики. http://en.wikipedia.org/wiki/Featuritis

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