Держать «код» подальше от дизайнеров?

Я строю довольно много проектов с моим другом, но мы всегда сталкиваемся с одной и той же ловушкой снова и снова. Я знаю, как писать PHP, Javascript и все такое (я также знаю CSS и HTML), поэтому я могу выполнять большую часть работы, когда дело доходит до создания реальной функциональности. Тем не менее, он не может, но он может сделать то, что я едва могу: дизайн сайтов.

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

1. Мы придумали особенность
2. Он строит дизайн интерфейса (где он должен быть размещен, как он будет выглядеть и т. Д.)
3. Он отправляет мне полный шаблон (экспорт HTML из Pinegrow)
4. Я смотрю на сделанные им изменения, а затем внедряю их на реальном сайте (так как несколько недель я использую CakePHP для него).
5. когда что-то работает не так, как задумано (как, например, это не сработало, как мы планировали по какой-то причине), я исправляю проблему на своей стороне, а затем отправляю ему шаблон обратно
6. промыть и повторить

Этот процесс, как можно себе представить, кропотливо медленный и неэффективный. Итак, мой вопрос: как мы можем сделать этот процесс более плавным? Я видел много вещей о том, что мы должны использовать React и использовать RESTful, а что нет, но мы хотим использовать CakePHP для этого. Могут ли некоторые люди рассказать мне об этом? Я долго искал это, но так и не нашел достойного решения для этого.

По сути, все, что может сделать мой партнер, - это дизайн сайта. Он не может использовать Docker (я использую Docker все время), PHP, Javascript и многое другое (он знает немного CSS, но в основном работает с WYSIWYGредактором), я готов изучить его ему, но он не интересно (поэтому я уважаю это). Я надеюсь, что кто-то здесь может помочь мне (и, возможно, другим, кто придет к этому вопросу позже) с этим, так как я думаю, что это довольно важная вещь.

Хотите освободить свой интерфейсный дизайнер от кода? Хотите ускорить интеграцию? Хотите использовать профессиональные методы, используемые на самых привлекательных веб-сайтах? Безусловно, лучший инструмент для этого:

Покрасить.

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

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

Бумага, ножницы и скотч.

Может быть, ручка, если вы чувствуете себя честолюбивым.

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

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

Вы можете подумать: «О, это хорошо, когда вы начинаете, но вы не используете это после разработки сайта». Не правда. Это работает так же хорошо на стабильных сайтах. Но сейчас большинство скриншотов с вашего собственного сайта.

Что, если ваш Front End Designer хочет использовать некоторые инструменты для генерации кода, чтобы сделать свои макеты? Хорошо, но не думайте ни на секунду, что вам придется использовать его «код». Что вы должны уважать, так это его решения о внешнем виде, потоке и представлении. То, что происходит за кулисами, чтобы это произошло, не является его областью знаний. Это ваше. Взять на себя ответственность за это.

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

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

Если код, который создает ваш Front End Designer, действительно стоит того, то вам нужно научиться интегрировать свой код с его. Для этого я настоятельно рекомендую вам изучить систему контроля версий . Изучите его настолько хорошо, что вы сможете научить своего дизайнера переднего плана, как его использовать.

Только после того, как вы оба сможете надежно использовать инструмент управления версиями, я рекомендую вам основывать свой план интеграции на слиянии кода. На этом этапе ваш друг заслуживает смены названия с Front End Designer на Front End Developer.

Теперь, даже если вы сделаете это, меня не удивит, если техника рисования на экране все же не окажется самым быстрым способом совместной работы для вас.

Может быть, вы просто не можете принять хаос всех этих изменений. Это создает слишком много работы. Ну, это называется программным обеспечением, потому что оно принимает изменения. В противном случае у нас был бы инженер-электрик, который сделал бы это на специализированной микросхеме. Возможно, вам понадобится обратиться к архитектуре, чтобы вывести свою логику поведения из пользовательского интерфейса, чтобы изменения пользовательского интерфейса не влияли на ваши основные бизнес-правила. Если вы ускорите работу своего Front End Designer, вы должны быть готовы идти в ногу с ними.

Единственная веская причина, заставляющая Front End Designer создавать код, это то, что вы устали и хотите их замедлить. Ну, я думаю, это не совсем "хорошая" причина.

С точки зрения инструментов, оптимальный рабочий процесс, который я вижу, это использование Sketch и Zeplin. Sketch - это простой дизайнерский инструмент. Эквивалентен Photoshop или InDesign, но оптимизирован для разработки приложений и веб-сайтов. Zeplin - это инструмент для обмена и утверждения проектов в Sketch (или Photoshop). Он может давать точные измерения пикселей и даже фрагменты кода для CSS или другого кода макета и экспортировать графические ресурсы. После того, как дизайн установлен, он передается разработчику. На этом этапе разработчик поднимает его и создает пользовательский интерфейс. Затем он может вернуться к дизайнеру для визуального контроля качества. Все, что он считает неправильным, должно быть зарегистрировано как ошибка, которая будет расставлена ​​по приоритетам и решена вами.

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

Это корень ваших проблем. Поток дизайна должен всегда происходить Designer to Developerи никогда не меняться. Изменения и изменения должны были быть сделаны дизайнером, а затем отправлены вам для внедрения на веб-сайте. Вы всегда можете сделать быстрые исправления самостоятельно, но постарайтесь признать, что эти быстрые исправления являются временными. Дизайнеру необходимо вернуться к своим проектам и найти правильное решение. Затем он передает вам изменения, и если они совпадают с вашими быстрыми исправлениями, тогда отлично, в противном случае вы обновляете их проекты.

Он отправляет мне полный шаблон (экспорт HTML из Pinegrow)

Не становитесь зависимым от получения HTML, с которым вы можете работать. Лучше, если вы внедрите технологию веб-сайта (Bootstrap, CSS, jQuery, React, PHP и т. Д. И т. Д. И т. Д.) Так, как вам это нужно. Затем вы воспроизводите его проекты, используя эти инструменты. Если HTML-код, который он дает вам, - это быстрый старт, то это здорово, но позже, по мере роста проекта, он будет бесполезен. Вам нужно будет внести изменения самостоятельно, потому что только вы понимаете свой движок шаблонов (например, представления CakePHP, шаблоны, плагины, компоненты и т. Д. И т. Д.)

Этот процесс, как можно себе представить, кропотливо медленный и неэффективный.

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

Дизайнер застрял в середине. С одной стороны, они должны удовлетворять потребности программиста, а с другой - удовлетворять потребности пользователя.

Итак, мой вопрос: как мы можем сделать этот процесс более плавным?

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

Я видел много вещей о том, что мы должны использовать React и использовать RESTful, а что нет, но мы хотим использовать CakePHP для этого.

CakePHP - одна из лучших платформ на планете (полное раскрытие, я в основной команде CakePHP).

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

CakePHP является хорошим внутренним сервером, если вам нужны API-интерфейсы RESTful.

React / Angular / Vue являются популярными и популярными интерфейсными фреймворками, но они существуют не очень давно. CakePHP, с другой стороны, существует уже более 13 лет. Моя точка зрения не критика. Дело в том, что эти библиотеки JavaScript имеют короткий срок годности. Через 5 лет мы все будем говорить о чем-то новом, но я подозреваю, что CakePHP все еще будет рядом.

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

Могут ли некоторые люди рассказать мне об этом?

Запросы на списки здесь не по теме. Сожалею.

РЕДАКТИРОВАТЬ :

Я пропустил часть о отслеживании изменений в дизайне.

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

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

Вам нужно разделить эти две вещи:

1. UX & UI design, некодирующая деятельность
2. Реализация, безусловно, кодирование

Дизайнер должен использовать творческие инструменты, такие как Marvel, которые предназначены только для дизайна. Дизайнер не должен заботиться о том, чтобы что-то делать с кодом, HTML, CSS и т. Д. Цвет, размеры, эстетика, взаимодействия, анимация - это все, на чем он должен сосредоточиться.

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

Чтобы ускорить выполнение задач, я рекомендую использовать минимальный инструмент, такой как Trello, и связывать / документировать все для каждой рабочей единицы.

Как мы можем сделать этот процесс более гладким?

Настаивайте на контроле версий

Ветвление программного обеспечения и параллельные вселенные

• Работать без кода не в управлении версиями. полная остановка. И я имею в виду забастовку, пока проект не все в VCS.
• Филиал формально, либерально, локально
  • Формально: ветвление для выпусков и подразделов выпусков, формальное исправление тестирования и т. Д. Разработка формального плана управления версиями, т.е. записывание его.
  • Либерально: Помимо официальной нумерации релизов, состоящей из 4 частей, ответвление, если ваша интуиция говорит вам, что это может быть хорошей идеей.
  • Локально: я держал личное репо с филиалами, никогда не предназначавшимися для командного потребления, потому что как команда мы сначала не разветвлялись, и у меня часто бывают эксперименты, исследования, на всякий случай и т. Д.

Инженер, черт возьми, из ваших промежуточных API

Преимущества:

• Стабильность - даже когда основной код развивается.
• Тестируемый код
• Повторное использование
• Командный инструмент коммуникации
• Это контракт. Обещание оказанных услуг (каламбур предназначен)
• Кодирование в области SOLID == счастливый программист обслуживания

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

Все и что-либо о бизнес-объектах должно быть в указанных BO. Даже тривиальные вещи, которые могут казаться наилучшими в пользовательском интерфейсе - даже один LOC. Такие мелочи, как добавление 2 пользовательских значений - вся связанная логика, включая проверку, должна быть в API бизнес-уровня. ИМО избыточность иногда в порядке. Для уменьшения избыточности могут быть небольшие, сфокусированные объекты бизнес-уровня, к которым пользовательский интерфейс имеет полный доступ.

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

Остерегайтесь рамок как костыль

В руках неквалифицированных, фреймворки и IDE не являются барьерами для монстров B-кино, которые они создают.

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

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

Это было бы неприемлемо практически в любой другой профессии.

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

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

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

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

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