Как только у вас есть свой первый набор требований и дизайн, где вы начинаете программирование? (Предположим, что тесты будут записаны в том же порядке, но перед кодом).С чего начать программирование?
Что вы предлагаете?
Кажется, что каждый, кто отправил ответ на этот вопрос, называет другое место для начала. Широкая вариация в исходных точках является прекрасной иллюстрацией того, где вы должны действительно начало: везде ваш идеальной отправной точкой является.
У разных людей разные способы решения проблем. Часто успех проекта не зависит от первоначального подхода, который требуется принять. Потратьте время, чтобы подумать и попробовать разные области, чтобы сосредоточиться на первых и выяснить, что подходит вам.
EDIT: На более абстрактном уровне this article by Paul Graham предлагает хорошее представление о стиле Lisp, восходящем подходе к программированию.
Я работаю с самого низкого уровня в цепочке зависимостей до самого высокого уровня. Таким образом, у меня может быть что-то, чтобы скомпилировать и протестировать на ранней стадии, а затем я смогу опираться на него, когда я иду.
Я начинаю с моими структурами данных (таблицами БД, XTD, словарями данных и т.д.) Тогда как данные попадут в него и из него (слой доступа к данным) структур Затем Business Objects со связанной с ними логикой Наконец , Пользовательский интерфейс и прикрепление этих программных перехватчиков к моей бизнес-логике
Я хотел бы сначала написать и протестировать классы поддержки. Я нахожу, что, если я этого не сделаю, я заканчиваю писать слишком много кода перед компиляцией и тестированием. Кроме того, сначала их написать означает, что вы будете более склонны делать их полными абстракциями, а не полупеленными, которые слишком тесно связаны с используемым кодом. Если вы не написали код более высокого уровня при написании вспомогательных классов, вы избежите случайного введения круговых зависимостей.
При этом, когда я пишу классы поддержки, я, по крайней мере, уже написал фрагменты кода, которые показывают примеры того, как они должны использоваться в коде более высокого уровня.
Это должно зависеть от того, что вы создаете. Я работаю над мобильным приложением Windows и начал формировать нижнюю часть, работая над классами и различными абстракциями данных, а затем подключил все это вместе с gui, и это был кошмар. Вы просто не можете показать людям (не разработчикам) код и убедить их, что вы на 40% сделали, им нужно посмотреть какой-то графический интерфейс. Если бы я мог вернуться, я бы сначала высмеял GUI.
Но когда дело доходит до веб-сайтов, основанных на данных, я начинаю с данных исключительно потому, что веб-страницы, которые позволяют вам манипулировать ими, зависят от того, как будут выглядеть данные и как вы можете взаимодействовать с ними.
В стороне, меня интересуют «самые простые» и «самые трудные» вещи, потому что я считаю, что естественная человеческая тенденция состоит в том, чтобы думать, что легкие вещи будут легче, чем они есть, и тяжелые вещи будут сложнее, чем они оказываются быть!
Мне нравится начать с черновой настройки пользовательского интерфейса.
Это ускоряет обсуждение вопроса о том, как дизайн и требования были неправы (даже если все подписались на них) и экономит много потраченных усилий.
Это немного опасно, потому что большинство людей полагает, что пользовательский интерфейс является основной частью работы и не поймет, почему так долго заканчивается, когда экраны выглядят почти окончательно.
Я почти всегда начинаю с пользовательского интерфейса.Как только я точно знаю, что происходит и что происходит, мне легче организовать все остальное.
Зависит от приложения, но UI-first - это хороший способ убедиться, что вы не тратите много времени на написание кода, который вам не нужен. – erickson
+1: во многих приложениях все, что внизу, есть только для обслуживания пользовательского интерфейса. Создание пользовательского интерфейса сначала поможет прояснить требования к информационным моделям и слою данных. –
Я вроде как этот ответ. Я не упоминал об этом в моем, потому что в большинстве моих работ нет пользовательского интерфейса, но это хороший момент. –
Работая с программами для настольных компьютеров и командной строки, я обычно делаю то, что предложил Тед, и начинал с вершины (корня) цепочки зависимостей (дерева), чтобы иметь что-то, чтобы проверить и скомпилировать раньше. Затем я добавляю классы и сложность шаг за шагом (вверх) цепочку (дерево).
Работа с веб-приложений, которые я обычно принимают несколько иной подход:
Я согласен с общим консенсусом до сих пор, что вы начинаете с самого низкого уровня, слоя данных, своего приложения и строите оттуда. Для меня это имеет смысл, потому что бизнес-логика построена поверх слоя данных, а передний конец построен поверх бизнес-логики и т. Д.
Однако, просто учитывая еще одну вещь - ваш клиент. К сожалению, клиент должен видеть видимые изменения, чтобы знать, что вы что-то делаете. И вы будете удивлены тем, что даже технические менеджеры тоже попадают в этот образ мышления.
Итак, я стараюсь, чтобы на каждой итерации делались некоторые действия с пользовательским интерфейсом, поэтому в некотором смысле приложение построено в вертикальных линиях. То есть некоторые данные, некоторые бизнес-логики, некоторые пользовательские интерфейсы, показывают клиента. Повторение.
Если бы вы это сделали, они бы поняли, что вы почти закончили с самого начала, а затем стали очень нетерпеливыми, что вы все еще работали над этим несколько недель спустя. Вы не можете выиграть за проигрыш, чувак. –
Лично я думаю, что вы должны начать с модели домена. Это будет в значительной степени вытягиваться непосредственно из ваших требований и поможет вам определить, какие фрагменты вам понадобятся для создания. Модель вашего домена будет управлять вашей моделью данных, и требования будут сообщать вам, что нужно сделать для объектов домена.
Если возможно, я бы начал с пути через все приложение. Работайте щедро с заглушками. Это помогает прояснить общую архитектуру программы.
Когда это будет сделано, я настоятельно рекомендую работать над самой сложной частью. (Самая сложная часть - это наиболее рискованная часть, а также часть, в которой вы указали наименьшую информацию.)
Почему? Поскольку вам нужно время, чтобы найти всю эту недостающую информацию, и если вы не можете заставить эту часть работать, другие части были потрачены впустую.
Re: Easy против жесткого элемента старшинства:
я стараюсь делать то, что я думаю, что будет труднее пункты первой. Таким образом, если все пойдет не так, вы, скорее всего, получите и сможете дать предварительное уведомление. Кроме того, если окажется, что что-то недостижимо, вы не тратите время на кучу мелочей, которые были зависимы и больше не нужны.
Лучшее место для начала, имхо, это со схемой данных, а затем модель предметной области, а затем какой-либо бизнес-логики между моделью & интерфейс, а затем интерфейс.
В зависимости от используемой вами технологии и парадигмы развития она будет служить естественным расширением ваших бизнес-требований в мире кодирования, поскольку это должно в идеале представлять основную часть ваших требований.
Действительно, вам нужно учитывать, что вы строите, шаблон проектирования, который вы использовали для архитектования своего решения, используемые технологии и то, как они взаимосвязаны (или нет) и их зависимости.
Начните с части, которая является ограничивающим фактором - если вы не можете создать адекватную модель домена без схемы данных, тогда начните с схемы.
Если у вас есть достаточно интеллектуальная база данных (все таблицы, целостность и правила, встроенные в хранимые процедуры, которые выполняют всю проверку и проверку ошибок) с довольно неосведомленным средним уровнем (все, что он делает, это данные прохода вдоль), тогда основная часть работы и функциональность лежат в обратном направлении.
Если у вас довольно простая база данных (только таблицы и поля) и очень умный средний уровень (все проверки логики, проверки и проверки целостности здесь) ... основная часть функциональности находится в середине ...
Теперь это вопрос предпочтения. Мне нравится прогресс, поэтому я начинаю с «самой простой» вещи для создания - «самой простой» части приложения. Для меня это помогает кристаллизовать весь процесс на уровне кода для меня - видеть, что куски падают на место с относительно частыми темпами.
НО Я ВСЕГДА оставляю ослепительный интерфейс до последнего (или у меня есть кто-то другой, чтобы это сделать), который я бы предпочел). !!
Это такое же искусство, как и наука ... каждый проект отличается, если вы просто не повторяете образец с теми же технологиями и процессами - в этом случае, переложите его на науку и убедитесь, что вы отнимайте уроки от каждого проекта, чтобы вы могли составить более эффективный процесс в будущем.
Приветствия
Я хотел бы начать с написания основы, а затем позволить другие части падают вместе.
Например, я, как правило, пишу класс, который, как мне известно, понадобится, а затем подключайте его, когда у меня есть какая-то желаемая функциональность ... затем будет продолжаться до окружающих функций.
Мне нравится делать это таким образом, потому что, если он чувствует себя как поток сознательности, и когда что-то щелкает, это очень приятно.
Моя взять в качестве подмастерья программиста:
При разработке приложения Django я бы сначала определил модели, взломал несколько подходящих шаблонов, код просматривать функции и заканчивать работу над пользовательским интерфейсом. Все эти шаги неизбежно пересекаются немного (например, вносить изменения в классы модели во время просмотра кодировки), но это будет общая дорожная карта для меня.
Я предпочитаю начинать с более высоких (архитектурных) частей, так как они лучше определяют то, что вам особенно нужно на более низких уровнях. Если вы начинаете на более низких уровнях, вы обычно оказываетесь на уровне более высоких уровней, чтобы соответствовать тому, как вы решили, что более низкие уровни должны работать. Таким образом, по сути, вы делаете свою работу более сложной, начиная с более низких уровней, и ваш дизайн становится сложнее понять. Код приложения более высокого уровня - это часть, которую вы хотите легко понять, поэтому мне больше нужно начинать с нее и обеспечивать ее работу именно так, как вы этого хотите.
Обычно это означает, начиная с пользовательского интерфейса и добавляя функциональность по мере создания пользовательского интерфейса.
EDIT: Если вы не знаете, как что-то будет работать на более высоком уровне, над которым вы работаете; затем создайте метод для этой части более высокого уровня для вызова и выталкивания работы в модули нижнего уровня. Для меня это делает чудеса для упрощения моего кода.
Возможно, подумайте о том, чтобы превратить это в сообщество wiki –
Зачем нужна вики сообщества? Это совершенно правильный вопрос о программировании. – DeadHead
Да, это действительно так, но это вопрос, подобный опросу, который обычно должен быть вики. – gnovice