С чего начать программирование?

Question

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

• Точка входа
• Framework / Поддержка классов
• Классы сущностей
• Сначала самое простое
• Сначала самое сложное

Что вы предлагаете?

Answer 1

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

Answer 2

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

Answer 3

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

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

РЕДАКТИРОВАТЬ: На более абстрактном уровне, эта статья Пола Грэма дает хорошее представление о подходе к программированию в стиле Lisp, восходящем снизу вверх.

Answer 4

Я начинаю со своих структур данных (таблиц БД, XTD, словарей данных и т. Д.) Затем, как данные будут входить и выходить из указанных структур (уровень доступа к данным) Затем бизнес-объекты со связанной с ними логикой Наконец, пользовательский интерфейс и присоединение этих программных хуков к моей бизнес-логике

Answer 5

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

Answer 6

Re: Легко против Жесткого приоритета предмета:

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

http://www.businessballs.com/rocks.htm

Answer 7

Мне нравится начинать с черновой обработки интерфейса.

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

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

Answer 8

Это должно зависеть от того, что вы создаете. Я работаю над приложением для Windows Mobile и начал работать снизу вверх, работая над классами и различными абстракциями данных, а затем подключил все это вместе с графическим интерфейсом, и это был кошмар. Вы просто не можете показать людям (не разработчикам) код и убедить их, что вы сделали 40%, им нужно увидеть какой-то графический интерфейс. Если бы я мог вернуться, я бы сначала смоделировал GUI.

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

Кроме того, меня интересуют "самые простые" и "самые сложные" вещи, потому что я думаю, что естественная человеческая тенденция - думать, что простые вещи будут легче, чем они есть, и сложные вещи будут сложнее, чем они оказываются. !

Answer 9

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

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

РЕДАКТИРОВАТЬ: Если вы не знаете, как что-то будет работать на более высоком уровне, на котором вы работаете; затем создайте метод для вызова этого компонента более высокого уровня и перенесите работу на модули более низкого уровня. Для меня это чудесно упрощает мой код.

Answer 10

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

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

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

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

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

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

Теперь это вопрос предпочтений. Мне нравится прогресс, поэтому я начну с самой простой вещи - самой простой части приложения. Для меня это помогает кристаллизовать весь процесс на уровне кода, для меня - видеть части, встающие на свои места с относительно частой скоростью.

НО Я ВСЕГДА оставляю великолепный внешний интерфейс до последнего (или я заставляю кого-то другого делать это - что я бы предпочел). !!

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

Приветствия