шаги проекта в дизайне/программировании веб-приложения
Вы можете использовать простое регулярное выражение:
function isInt(value) {
var er = /^-?[0-9]+$/;
return er.test(value);
}
4 ответа
Хорошо, вы создали отличную спецификацию. Теперь пришло время расширить это «описание» до функциональных макетов пользовательского интерфейса.
Почему?
Спецификация говорит, что приложение «должно» делать. Об этом можно даже очень подробно рассказать. Но полные пользовательские интерфейсы говорят именно то, что приложение «действительно делает». В конце концов, действительно ли пользователи заботятся о том, что находится под капотом?
По нашему опыту, мы обнаруживаем, что проекты, в которых пользовательский интерфейс разработан и доработан (например, действительный HTML) ДО того, как будет применена функциональность , объединяются несколько раз быстрее и более эффективно, чем другие.
- Спецификация может содержать только небольшой процент от актуальных деталей с которыми вы сталкиваетесь при реализации
- Функциональный пользовательский интерфейс может охватывать почти все фактические детали , с которыми вы сталкиваетесь при реализации приложения, за долю времени, затрачиваемого на его фактическую работу.
Как только клиент / заинтересованная сторона доволен пользовательским интерфейсом, это быстрый путь к подключению функциональности.
А функциональный пользовательский интерфейс - это непростая задача. Может быть, даже 20-40% работы можно было бы потратить на это.
-
Все, как говорится, не тратьте время на то, чтобы все было красиво - просто сосредоточьтесь на удобных интерфейсах . График может прийти позже и сделать его красивым, пока вы заняты тем, чтобы он работал.
Ответ: все из указанное выше . (например, HTML / CSS, серверная часть, база данных, клиентские сценарии и т. д.)
Однако , только минимально возможное количество каждого из требуемых элементов для того, чтобы простейшая отдельная функция действительно работала.
Судя по вашему вопросу, похоже, вы никогда раньше не делали веб-приложение. Это нормально, и ваш вопрос хороший, поскольку я помню, что мое первое веб-приложение показалось мне довольно пугающим.
Чтобы начать использовать эту передовую практику, я рекомендую короткие / сжатые итерации, где каждая итерация дает законченный рабочий код.
Вот простое описание этого процесса, исходя из моего опыта:
- Прекратите работать над своей функциональной спецификацией - отложите ее и оставьте - это важная работа.
- Выберите 1 функцию ... сделайте ее самой простой функцией в вашей спецификации, как сейчас.
- я предполагаю: отобразить простейшую возможную версию вашей домашней страницы
- Начните работать над всем, что нужно, чтобы ваша сверхпростая домашняя страница действительно работала.
- Чтобы эта 1 страница работала, вы собираетесь чтобы узнать немного о каждой части вашего стека - кроме, возможно, базы данных, это нормально, вы можете заняться этим в более поздней итерации.
- Выберите инструменты в своем стеке ... Вы выполнили несколько простых функций, скажем, 3, например, просмотрите вашу функциональную спецификацию и посмотрите, нуждается ли она в обновлении на основе того, что вы узнали, выполняя первые 3 функции.
- Просмотрите свой код по первым 3 функциям, вы узнать что-нибудь с тех пор, как вы начали? Есть ли причина для рефакторинга или очистки? Если да, сделайте 1 проход при очистке / рефакторинге.
- Как только вы будете довольны своими 3 простыми функциями, вернитесь к своей спецификации и выберите другую функцию и / или добавьте больше сложности к существующей функции.
Каждая Цикл, описанный выше, является итерацией, делайте их краткими и всегда заканчивайте рабочим кодом, который вы потенциально можете отправить, если вашему приложению требуется только эта небольшая функция.
Я не изобретал описанный выше процесс, он называется Scrum. Хотя вы не
Два наиболее популярных варианта - это разработка через домен и разработка через тестирование. Грубо говоря ...
В разработке, управляемой доменом, вы должны начать с отображения логической организации процесса разработки в модель, которую можно использовать для программирования.
В разработке через тестирование вы должны начать с написания модульных тестов которые соответствуют конкретным вариантам использования. Затем вы постепенно добавляете функциональность по мере наложения вариантов использования, в конечном итоге удовлетворяя все требования. Энтузиастам TDD нравится этот подход, потому что их менталитет состоит в том, чтобы кодировать только то, что необходимо для достижения текущей цели, и в конечном итоге у вас будет лучшая кодовая база.
Надеюсь, это даст вам два разных пути, на которые можно взглянуть, удачи.
Ответ: Зависит .
Зависит от того, нужно ли вам, чтобы ваш клиент подписал внешний вид перед началом работы; это зависит от того, были ли макеты частью этого внешнего вида. Это зависит от того, как скоро вам нужно предоставить прототип перед вашим клиентом для тестирования.
Независимо от того, над чем вы начинаете работать, Это зависит от вашей конкретной ситуации.
Если вы сторонник Domain Driven Design , то у вас будет конкретная отправная точка. Если вы сторонник Разработка через тестирование , то у вас также есть конкретная отправная точка. Фактически, независимо от вашей религии в программном обеспечении , у вас, вероятно, есть отправная точка.
Здесь ' Мой ответ: Начните там, где вы можете получить максимальную отдачу от вложенных средств . Если много данных, я начинаю с него, так как все зависит от этого.