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

Question

Мой клиент мин не заботится об элегантном и хорошо структурированном коде. Я пишу приложения с нуля с минимальными сторонними инструментами. Я использую l2s, Recatcha, tinymce, lucene и структурную карту.

Я бы хотел как можно быстрее вывести клиентский продукт на рынок, пожертвовав элегантным кодом. Существуют ли какие-либо инструменты, которые позволят мне вывести продукт на рынок?

Answer 1

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

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

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

Answer 2

Хороший код для вас, а не для вашего клиента.

Я не думаю, что существует такая волшебная таблетка.

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

Answer 3

Предполагая, что добавление большего количества членов команды не вариант, вы можете:

1. работают дольше (кофе и пицца живут до тех пор, пока вы или проект не закончите)
2. отложить некоторые функции для версии 2.
3. качество жертвы.
4. с опозданием.

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

Answer 4

В основном у вас получается следующее:

http://www.scottsimmons.tv/blog/wp-content/uploads/good_2dcheap_2dfast.jpg

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

"Это не потому, что у вас 9 женщин, чтобы вырастить ребенка нужно всего один месяц. "

Answer 5

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

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

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

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

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

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

Так или иначе, чтобы ответить на ваш вопрос, инструменты проектирования, такие как инструменты рисования UML и т. Д., Вероятно, более полезны, чем инструменты кодирования

Answer 6

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

Answer 7

Я бы порекомендовал использовать инструмент непрерывной интеграции, такой как CruiseControl.NET или Hudson, и написать множество тестов JUnit (или эквивалент C #).

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

Тем не менее, я согласен с тем, что заявили другие, вы пишете элегантный код, чтобы вы (или ваши партнеры по команде) понимали его, а не так, чтобы ваш клиент был доволен.