Ускорение веб-разработки

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

Необходимо знать основы - прежде чем перейти к HAML, вы должны знать свой HTML, чтобы знать, что вы абстрагируете. Прежде чем перейти к jQuery, найдите время, чтобы изучить основы JavaScript - вам не нужно быть профессионалом, но когда вам нужно сложить несколько чисел, вы должны , а не искать плагин. Хорошо понимать, как стилизовать вещи с помощью CSS. Чтобы стать компетентным разработчиком пользовательского веб-интерфейса, нужно многому научиться по темам и технологиям.

Тем не менее, для разработки с нуля Rails довольно хорош. Выберите jQuery. И не выбирайте платформу, которая скрывает, как на самом деле работает Интернет.

Я использую стек .NET около 5 лет, стек ASP.NET MVC около 3 месяцев и старый ASP около 4 лет.

Ключ к работе со сложностью смягчает его. В своем коде всегда абстрагируйте сложность до разумного уровня. Например, чтобы разместить заказ, нужно выполнить 10 шагов. В этом случае на более высоком уровне у вас будет метод SubmitOrder; под ним может быть 10 вызовов методов для вставки соответствующих записей, работы с инвентарем и т. д. На каждом из этих «бизнес-уровней» вы можете просто решать эти бизнес-проблемы, и даже ниже этих уровней вы будете иметь дело с данными и механическими деталями. Преимущество всех этих уровней состоит в том, что вы заставляете каждый уровень обрабатывать часть работы, и по мере того, как вы подходите ближе к пользовательскому интерфейсу, у вас появляется «интерфейс».

Ответ на этот вопрос зависит от того, работаете ли вы в одиночку или руководите группой.

Если вы возглавляете группу, вам нужно разделить обязанности следующим образом:

• Дизайнеры - эти люди должны владеть созданием графических макетов и создание / поддержка CSS. Они должны владеть CSS в качестве ответственности, чтобы они не знали, что нельзя создавать возмутительные графические макеты, которые нельзя создать как веб-страницу без значительного раздувания кода.

• Разметка - Эти люди должны владеть разработкой HTML, доступностью, семантикой, требованиями RDFa, и любой другой аспект, связанный со структурой данных внешнего интерфейса.

• UIT - Эти люди должны владеть JavaScript, требования к эффективности, требования к управлению контентом, внутренние процессы и интерфейсные инструменты / управление процессами и, как правило, собственные передовые практики для всего видимого клиентом кода.

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

• QA - Эти люди тестируют все бизнес-требования к конечному продукту в среде сертификации. Если обнаружены ошибки, ошибку / заявку следует обновить и переназначить. Работа не будет завершена до тех пор, пока QA не будет признана действительной.

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

• Менеджер проекта - Этот человек обеспечивает непрерывное продвижение проекта и выполнение основных этапов в соответствии с установленными сроками. Именно этот человек, а не владелец бизнеса, должен вмешиваться в технологический процесс, чтобы все было сделано. Это лицо должно действовать независимо от владельца бизнеса и не должно служить инструментом для бизнеса. Руководитель проекта не должен владеть или рекомендовать изменения требований к техническому персоналу. Если необходимо внести изменения в требования, это односторонний процесс от технологии через менеджера проекта к владельцу бизнеса.

• Процесс разработки должен быть следующим:

  1) Дизайнеры создают графический макет, а затем переназначают заявка на ошибку / проект передается владельцу проекта.

  2) После утверждения бизнесом заявка должна быть передана специалистам по разметке или отклонена обратно в дизайн с конкретными запросами на изменение.

  3) Разметка записывает HTML и контент. Любые требования к приложению или базе данных должны быть определены бизнесом до начала проекта, а группа разметки должна написать код для всех возможных сценариев. Структура контента должна полностью отражать организацию контента на визуальной разметке, без учета представления. Тикет нужно переназначить обратно в Дизайн для создания CSS.

  4) Дизайн пишет CSS для добавления презентации в соответствии с созданным графическим макетом. Команда разработчиков должна иметь доступ к разметке HTML для добавления атрибутов класса по мере необходимости, но не должна иметь права вносить какие-либо другие изменения. Билет должен быть назначен приложениям для выполнения всех требований на стороне сервера.

  5) Приложения должны создавать все необходимые требования для доступа к базе данных. Билет следует переназначить для UIT, если предыдущие требования удовлетворительны, или переназначить обратно в Markup для изменений / дополнений.

  6) UIT должен быть последним шагом для написания взаимодействий JavaScript, необходимых для пользовательского интерфейса и требований AJAX. UIT также должен подтвердить ранее выполненную разметку на соответствие стандартам, эффективность и передовой опыт. UIT должен быстро отклонить проект, если работа окажется менее приемлемой. Если требуется дополнительная работа с приложениями, переназначьте их приложениям, в противном случае перенаправьте билет QA.

  7) QA - это последняя остановка технологии. Эти люди проверяют бизнес-требования и функциональные требования к конечному продукту. Проект не может быть запущен в производство без одобрения QA. Если бизнес-требование не выполняется, QA не должен подписывать контракт. После подписания QA заявка должна быть передана владельцу бизнеса.

  8) Владелец бизнеса просматривает проект и определяет, выполнены ли все требования. Если требуются изменения / дополнения, их можно отправить прямо сейчас. Изменения / дополнения НЕ ДОЛЖНЫ быть представлены раньше, потому что частые изменения задерживают выполнение всех проектов. Владелец бизнеса несет ответственность за полноту и конкретность своих первоначальных требований. Если требования не проверены на полноту, это вина владельца бизнеса, и изменения могут быть внесены на этом этапе. Именно из-за этой ответственности и других связанных с ней деловых обязанностей владелец бизнеса заслуживает того, чтобы ему платили больше за меньшее участие.

Это наиболее эффективный способ выполнения работы. Разделение обязанностей чрезвычайно важно, и чрезвычайно важно соблюдение процесса. Если эти две вещи терпят неудачу, весь процесс терпит неудачу, и бизнес несет значительно увеличенные затраты на разработку.

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

Я использую пользовательский интерфейс дизайнеров.Они отлично подходят для таких вещей.

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

Мои компании в основном занимаются разработкой .NET, и мы успешно использовали шаблоны «сетевых уровней» для уровня доступа к данным. Шаблоны загружаются в генератор кода CodeSmith и указываются в базе данных. Конечный результат - это все, о чем вы только можете подумать. Он сгенерирует ваш DAL, веб-сервис, библиотеку пользовательского интерфейса winforms, библиотеку веб-интерфейса, образец веб-сайта и инструмент администрирования и многое другое. Отличный инструмент для экономии времени на разработку. Проверьте это.

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

Чтобы ускорить получение HTML-страницы, которая выглядит как вы хотите:

Во-первых, определитесь с дизайном и нарисуйте то, как вы хотите, чтобы он выглядел, используя графическую программу (если у вас есть дизайнер пользовательского интерфейса, они делают этот шаг). Затем напишите статический HTML и CSS, который соответствует тому, что вы я нарисовал. Как только это будет сделано, напишите код, который выводит HTML, который соответствует выбранному вами формату.

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