Влияние дизайна на время доставки приложения - PullRequest
1 голос
/ 02 апреля 2009

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

Ответы [ 5 ]

6 голосов
/ 02 апреля 2009

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

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

2 голосов
/ 02 апреля 2009

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

2 голосов
/ 02 апреля 2009

Этот подход действительно хорошо работает, только если вы работаете самостоятельно. Если вам нужно работать в команде людей, важно составить хороший план, чтобы все остальные знали, что, по вашему мнению, является конечной целью. Это не снижает креативность, а просто позволяет убедиться, что все находятся на одной странице, и уменьшает вероятность путаницы. Dilbert on agile

2 голосов
/ 02 апреля 2009

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

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

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

0 голосов
/ 01 мая 2009

Просто для того, чтобы добавить мысли к вашему сценарию с уравнениями, позвольте мне внести свой вклад в это немного ниже: я работаю в компании под названием YES INTERNATIONAL CORPORATION (www.yesintl.com.au). Иногда бывает, что разработчики разработал что-то раньше, так что в этом случае дизайн уже в уме. Например, в прошлом я разрабатывал решения для баз данных, что делает нас очень быстро развивающейся корпорацией по сравнению с конкурентами, когда я сажусь и начинаю разработку проекта. Больше опыта сделает тебя супер идеальным с течением времени ... Надеюсь, это поможет ... Энди

...