Что лучше сделать сначала, разработать интерфейс или написать код? - PullRequest
6 голосов
/ 11 января 2011

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

Ответы [ 7 ]

14 голосов
/ 11 января 2011

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

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

2 голосов
/ 11 января 2011

Я думаю, что, говоря «проектирование интерфейса», вы подразумеваете графический интерфейс.Как учит PNL, вы будете лучше обрабатывать то, что уже видите, поэтому визуализация очень помогает при разработке нового проекта.Вот почему я начинаю проекты, следуя моей первой визуальной идее, рисуя макеты страниц, которые я точно знаю, как они будут функционировать, с ручкой и бумагой (я рад прочитать, что многие уважаемые коллеги также делают это).

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

Перед написанием кода я также проектирую БД, использование которой также делегируется методам более низкого уровня, используемым интерфейсными методами, которые я уже написал (90% проектов, над которыми я работал, был основан на БД), записывая каждыйМне приходит в голову мысль об атрибутах или дополнительных таблицах, которые могут лучше дополнить информацию, обрабатываемую приложением, или улучшить функциональность.

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

Я начинаю писать код как конечную задачу, ина данный момент работа сделана.Написание логики приложения с объясненным фоном позволяет мне думать и писать только на основном языке (ах), выбранном для реализации проекта, который обычно представляет собой PHP для обработки на стороне сервера и JavaScript для клиентского интерфейса.

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

Счастливого кодирования и счастливого нового года!:)

1 голос
/ 11 января 2011

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

Подумайте об этом логически - интерфейс / интерфейс - это причина, почемубаза данных и ваш код там, а не наоборот.

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

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

1 голос
/ 11 января 2011

Я думаю, что это общий пошаговый подход:

  • Узнайте, каковы требования.
  • Сделайте макет приложения и покажите его клиентам или коллегам.
  • Создание глобального технического дизайна.Перечислите технологии для использования и общий обзор компонентов, которые будут сделаны.
  • Затем начните кодирование или создайте более детальный дизайн.
1 голос
/ 11 января 2011

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

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

0 голосов
/ 11 января 2011

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

Это похоже на тестирование HTML-страницы.

0 голосов
/ 11 января 2011

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

Скажем, направление развития похоже на переход от центра лука к внешней части.

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