Что лучше сделать сначала, разработать интерфейс или написать код?
в проекте с одним человеком (веб-страницы или настольные приложения), где вы являетесь дизайнером и разработчиком, что лучше сделать в первую очередь, разработать или написать код?
7 ответов
по интерфейсу я предполагаю, что вы имеете в виду пользовательский интерфейс, в отличие от API. Я всегда разрабатываю интерфейс первым. Когда я кодирую, я ленив - я делаю все, что нужно, с наименьшими усилиями. Это приводит к интерфейсам, которые не имеют никакого смысла только потому, что это был самый простой (или самый чистый) способ сделать это в коде. Но прежде чем вы напишете код, вы беспристрастны и будете принимать лучшие решения о том, каким будет хороший интерфейс.
-- Они все равно будут плохие решения. Вы можете думать, что знаете, что кажется естественным, но это не так. Проверьте это на людях! Следите за тем, что они делают, как они пытаются использовать ваше программное обеспечение, задавайте им вопросы и адаптируйтесь соответственно. Если вы делаете это часто,то не имеет значения, если вы сначала разрабатываете или код. Это способ сделать первоклассный продукт.Я думаю, что, говоря о "проектирование интерфейса" вы имеете в виду графический интерфейс.
Как учит PNL, вы будете обрабатывать лучшие вещи, которые вы уже видите, поэтому визуализация помогает много в дизайне нового проекта.
Вот почему я начинаю проекты, следуя своей первой визуальной идее, рисуя макеты страниц, которые я точно знаю, как они будут функционировать, с ручкой и бумагой (я рад прочитать, что многие уважаемые коллеги также делают это).
Это позволяет мне концептуализировать сущности приложений (которые, вероятно, являются классами) и функциональные возможности (которые могут быть непосредственно переведены в методы).
На этом этапе я пишу программный интерфейс, который для меня является самой важной частью приложения как при запуске с нуля, так и для будущей переделки.
Обычно это не совсем новый стиль программирования, так как многие программисты имеют свои предпочтительные шаблоны и синтаксис и код для повторного использования или приводятся к некоторым решениям в рамках / среде, которую они надо работать, но в любом случае я считаю это ключевой задачей.
перед написанием кода я также разрабатываю БД, использование которых также делегируется методам более низкого уровня, используемым интерфейсными методами, которые я уже написал (90% проектов, над которыми я работал, были DB-dased), откладывая каждую идею, приходит мне на ум об атрибутах или побочных таблицах, которые могут лучше завершить информацию, обрабатываемую приложением или улучшить функциональные возможности.
когда у меня есть время, я также делаю некоторые таблицы и диаграммы с использованием Excel, определяющие все задачи CRUD для каждой таблицы (очевидно, не каждая таблица может нуждаться во всех задачах CRUD).
Это позволяет мне писать в несколько раз также общие SQL-запросы, что также уменьшает работу написания кода, избегая переключать внимание на другие диалекты SQL.
Я начинаю писать код в качестве конечной задачи, и на этом этапе работа выполняется.
Написание логики приложения с объясненным фоном позволяет мне только думать и напишите на основном языке(языках), выбранном для реализации проекта, которым обычно является PHP для обработки на стороне сервера и JavaScript для клиентского GUI.
я экспериментировал с Правдой фразы, которую часто говорил один мастер: хорошая работа-это 90% планирования, 10% выполнения.
Я глубоко согласен: когда хорошее планирование сделано, остальное просто упаковывает все части.
счастливого кодирования и счастливого Нового года! :)
с точки зрения здравого смысла я бы сказал, что макет дизайна (думаю, ручка и бумага) лучше всего начать. Определите, что вы хотите, чтобы программа / сайт делал и как он должен выглядеть, не вдаваясь в подробности. Если у вас есть четкая цель с самого начала относительно функций и дизайна на меньшем порядке реализации проекта, это не должно быть такой большой проблемой.
однако я должен сказать, что я всегда делаю код перед дизайном, и я редко создаю макеты проектов. И я никогда не следую за тобой. мой собственный совет.
Это, я думаю, общий шаг за шагом подход:
- узнайте, каковы требования.
- сделать макет приложения и показать его клиентам или коллегам.
- создать глобальный технический дизайн. Перечислите технологии для использования и обзор высокого уровня компонентов, которые будут сделаны.
- затем начните кодирование или сделайте более подробный дизайн.
Я обычно делаю все каркасы экранов сначала, затем диаграмму базы данных, затем код, а затем я делаю интерфейс.
подумайте об этом логически-интерфейс / интерфейс является причиной того, почему база данных и ваш код есть, а не наоборот.
Я вижу, что так много людей тратят слишком много времени на архитектуру и дизайн баз данных, в то время как интерфейс игнорируется.
конечному пользователю все равно, как выглядит ваша база данных, что код вы пишите или сколько слоев у вас.
обычно я разрабатываю проект на бумаге (или с помощью инструментов диаграмм), затем пишу основную часть и, наконец, пользовательский интерфейс. GUI является последней. Таким образом, вы можете сделать тесты сначала с логической частью программы и только потом с презентационной частью.
предположим, что направление развития похоже на движение от центра луковицы к внешней части.
Я предлагаю вам сделать синюю печать вашего пользовательского интерфейса, а затем одновременно выполнить кодирование и интерфейс. Это будет лучше, так как вы можете получить выход мгновенно, если хотите, и можете его изменить.
Это похоже на тестирование HTML-страниц.