Я узнал в школе так же, как и везде, что хорошая методология разработки требует концепции и дизайна, прежде чем писать код правильно.
Это не новая информация даже для начинающего программиста. Однако мне интересно, хороший ли это совет, потому что с тех пор, как я начал разрабатывать на нескольких языках программирования, мне так и не удалось спроектировать и задумать все с самого начала.
Я имею в виду, я всегда плавил дизайн, концепцию и программирование. Я худший разработчик в мире, или идея, которую мы учим в школе, - просто старая бессмысленная религиозная догма?
Как мы можем даже придумать и спроектировать то, что никогда не испытывали и не программировали раньше? Разве это не смешно? Разве программирование не руководит концепцией и дизайном?
Ответы:
Я думаю, что ответ должен быть: планируйте как можно больше, но не более того.
Мало кто высказался бы против достоинств планирования, но споры в основном упускают из виду важный аспект. Планирование работает только в том случае, если у вас есть умение составить хороший план, этот навык, как правило, приходит с опытом. Если у вас нет большого опыта, у какого-либо плана, который вы составляете, скорее всего, возникнут значительные проблемы, это означает, что для того, чтобы сделать продукт, который не является полной катастрофой, план должен быть серьезно пересмотрен во время разработки, если план подробный, то это, вероятно, лишит законной силы многие детали, или, что еще хуже, вы постараетесь свести корректировки к минимуму, чтобы иметь возможность следовать плану.
Некоторые вещи, безусловно, требуют планирования, и если у вас нет навыков для создания необходимого уровня плана, то единственный способ продвинуться вперед, который я могу себе представить, - это создание прототипов, написание кода просто для получения опыта с задачей, необходимой для составления адекватного плана. ,
Независимо от того, готовы ли вы написать производственный код, как только вы достигнете максимального уровня планирования, вам ничего не останется, кроме программирования. Возможно, это будет катастрофа, но это хороший учебный опыт, и вы будете гораздо лучше подготовлены для составления пересмотренного плана.
источник
Это абсолютно верно. Чем больше и сложнее требование, тем оно вернее.
Для небольшого консольного приложения для вычисления последовательности Фибоначчи вам может потребоваться не более нескольких минут, чтобы подумать о том, как структурировать алгоритм и пользовательский интерфейс (который, да, может быть просто stdin и stdout).
Но как насчет торговой платформы в реальном времени, которая должна выполнять миллионы транзакций в секунду, распределенных по всему миру, и для этого требуется 99,9999 часов безотказной работы и 100% корректности? Не могли бы вы просто начать это кодировать?
Есть много других вариантов между этими двумя крайностями.
Взгляните на проект Эйлера . Решите некоторые проблемы в представленной последовательности. Вы обнаружите, что для того, чтобы решить некоторые проблемы в разумные сроки, вам нужно подумать, прежде чем переходить к коду.
Если вам не нужно время, чтобы подумать и спроектировать свою программу, прежде чем начинать кодировать, вы либо работаете над банальными вещами, либо упускаете что-то большее.
Никто не делает ничего, кроме самых тривиальных проблем. Опять же, чем крупнее и сложнее проект, тем более правдивым является то, что в дизайне будут ошибки, пропущенные вещи и т. Д.
Искусство заключается в том, чтобы сначала проектировать на высоком уровне, чтобы увидеть, подходят ли крупные элементы. Затем получите список приоритетов - начните сначала работать с наиболее важной инфраструктурой. Затем мы идем и разбиваем большие части на более мелкие, убедившись, что каждая большая часть состоит из частей, которые имеют смысл.
Это требует времени и усилий - и может быть не полным или не совсем правильным в начале.
Но именно поэтому он называется программным, а не аппаратным . Он податлив и может быть изменен.
источник
Это верно.
И есть твоя проблема.
Для большинства нетривиальных проблем вам нужно подумать, чтобы понять, как все будет работать - как все будет сочетаться. Как это ни парадоксально, но для большинства нетривиальных задач вы не сможете спланировать все . Слишком много неизвестного для вас, слишком много изменений, которые произойдут во время разработки. Agile приобрел силу, которую он имеет, потому что он принимает эту вторую половину сделки: люди не всезнающие, и перемены постоянны.
Так что это , конечно , правда , что вам нужно сделать дизайн раньше времени, но это также верно , что это невозможно только разработать загодя.
источник
Вы обязательно должны иметь некоторый дизайн перед написанием кода.
Причина довольно проста - если у вас нет дизайна, вы не знаете, что делаете .
Вы обязательно должны иметь некоторый код, прежде чем дизайн будет окончательным.
Причина довольно проста - дизайн изменится, а разработка его частей откроет вопросы, возможности и проблемы, которые трудно предвидеть, не начав работать над решением.
Разработка итеративна.
Независимо от того, по плану или нет, понимает ли команда это или нет, каждый программный проект выполняется итеративно - часть работы завершается, а затем оценивается, и оценка приводит к изменениям в выполнении остальной части работы.
Попробуйте более одного подхода.
Требуются практика и опыт, чтобы знать, как наилучшим образом сбалансировать предварительный дизайн с созданием кода. Это навык, который почти никто не освоил, и каждый проект будет иметь разные идеалы (подумайте о разработке небольшого инструмента для вашего собственного использования по сравнению с командой, создающей большой продукт с одним выпуском, например, крупную видеоигру).
источник
В прошлом я проектировал и наблюдал, как другие проектировали несколько систем, и я видел, как этот процесс разворачивается разными способами, но я нахожу общим то, что первоначальная архитектура должна, по крайней мере, планировать существование большинства основных функций.
Например, я видел систему управления HVAC, которая не имела понятия о зданиях, полах, помещениях и т. Д., Которые были бы дооснащены ими, и результат был таким же безобразным, как и они. Или мобильное музыкальное устройство, созданное из компонентов, лучше подходящих для ваших (не умных) карманных часов. Излишне говорить, что конечные продукты в любом случае не были фаворитами клиентов.
Когда вы говорите «концепция», это только один шаг от «идеи», и концепция может быть очень размытой. Бизнес обычно заботится о концепциях. Клиенты, как правило, заботятся о UX - концепции, воплощенной в жизнь таким простым и приятным в использовании способом, которая приносит определенную ценность благодаря его использованию.
Вы должны сделать «концепцию» перед любым программированием, я не могу представить, чтобы я открыл Visual Studio (или вашу IDE по своему выбору) и случайно написал код, чтобы увидеть, куда он идет.
Вы не можете сделать полный дизайн (и не должны) перед кодированием, но у вас должен быть приблизительный эскиз того, каким будет рабочий процесс пользователя.
UX-дизайн и кодирование довольно часто сочетаются друг с другом, и вам, вероятно, придется использовать какой-то подход Agile для любых проектов, кроме самых маленьких, чтобы включить этот факт в подход к работе. Так что не думайте, что вы худший из программистов, если вы не могли увидеть все это сразу - никто не может, и люди, которые думают, что могут, являются теми, кто просто игнорирует достаточно проблемы, чтобы они могли утверждать, что у них есть полное картина.
Один пример, чтобы положить размер на что-то большое. Концепция: «Создать визуальный облачный инструмент, который позволит предприятиям интегрировать свои программные платформы». Это звучит великолепно, и можно начать писать маркетинговые материалы и продавать их еще до того, как они появятся. Вы должны иметь это до кодирования.
Предварительное проектирование: «иметь формы и стрелки, как в Visio для описания логики; иметь подключаемые модули для подключения к различным платформам (SAP, SF, базы данных ...); иметь консоль мониторинга, где можно искать данные, проходящие через система; иметь способ визуального описания данных и преобразования одного формата в другой ". Еще один замечательный маркетинговый шарик. Это также дает вам некоторые идеи о том, что важно, должен иметь такой грубый набросок, прежде чем кодировать тоже.
Дизайн / код: «У вас должен быть HTML-дизайнер, размещенный в браузере, с такими-то и такими-то функциями; закодировать бэкэнд в Java, чтобы он мог работать на любом существующем сервере; определить структуры данных и UX для запроса или изменения их по мере необходимости; план аварийного восстановления, ошибки составление отчетов, ведение журнала аудита; контроль версий плана; планирование контроля доступа; .... "- чем тоньше список, тем более нереально предвидеть все это.
... однако следует по крайней мере знать, как все может выглядеть примерно так, или ваш конечный продукт может оказаться действительно бесполезным, что в итоге убьет потрясающую концепцию, скажем, вашему визуальному дизайнеру требуется 40 ". экран для отображения любого реального рабочего процесса, или нет способа поиска в журналах, кроме точного совпадения строк, ограниченного одним из 20 полей в журнале и т. д. и т. д. Нет хорошего способа предотвратить это, кроме выполнения вашей реализации - некоторые преуспеют, другие потерпят неудачу.
источник
Я всегда выделяю время следующим образом:
Дизайн: не только визуальный, но и концептуальный. Разделите его на части, визуально и по логике. Ищите общие черты, которые повторно используются и являются образцом дизайна сами по себе.
Разработка: Как только вы узнаете свои части, закодируйте их. Затем вы интегрируете их.
Тестирование: не только тестирование того, что код был интегрирован и написан правильно, неизменно будут обнаружены идеи и извлеченные уроки, и это создаст новые способы взаимодействия, новые возможности будут задуманы и желаны. Остерегайтесь ползучести области.
В дополнение к этим аспектам, имейте в виду, что проект также имеет 3 этапа поверх этих этапов.
Я обнаружил, что чем лучше вы выполняете фазу проектирования, тем меньше минимизация дополнительных попыток. Вместо того, чтобы заново делать все это, у вас может быть только подсистема, которая будет переработана.
Я разработчик программного обеспечения и менеджер по разработке программного обеспечения для внутренних, внешних и оффшорных проектов разработки.
источник
Здесь есть фундаментальное неверное предположение. Вы никогда не сможете придумать хороший дизайн без написания кода (школа никогда не научит вас этому). Тем не менее, школа права, что вы не получите хороший код без дизайна.
Решение:
Отбросив весь код является не дополнительным шагом в этом процессе, но для небольших проектов формально написания дизайна может быть. Для больших проектов вы, скорее всего, повторите шаг « выбросить весь код » - хотя, если у вас достаточно модульности, это может относиться только к части кодовой базы.
Слишком много проектов придерживаются унаследованного кода, потому что не хотят его менять - или потому что он слишком сложный, потому что он никогда не был разработан, чтобы его выбрасывать. Признание того факта, что ваша первая попытка окажется неудачной, сделает вашу жизнь намного лучше.
источник
Концепция - это ключевой дизайн, который всегда можно изменить. Программирование должно соответствовать требованиям полностью продуманного приложения.
1-й, какой смысл, 2-й, как к нему нужно обращаться, 3-й, кто пользователь, 4-й план, полный объем работы SOW, определите в конкретных терминах все это приложение. и как каждая добавленная вами функция будет работать.
Прежде чем делать выбор в отношении архитектуры вашего веб-приложения, спланируйте и продумайте его полностью.
затем выберите лучший стек
Я разработчик LAMP
поэтому я склонен сужать вопрос к тому, что php framework я буду использовать. и сценарии переднего конца мне нужно будет заставить его делать все, что мне нужно, чтобы он делал идеальным способом
чтобы добавить это, научитесь использовать фреймворки MVC, ZEND и CAKEPHP - лучшие фреймворки быстрой разработки (PHP)
источник