Тримати «код» подалі від дизайнерів?

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

Але кожен раз, коли ми стикаємося з проблемою, оскільки він не знає, як написати код, це, як правило, трохи уповільнює наш розвиток. На даний момент це наш робочий процес:

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

Цей процес, як можна було собі уявити, кропітко повільний і неефективний. Отже, моє запитання полягає в тому, як ми можемо зробити цей процес більш плавним? Я бачив багато речей про те, що ми повинні використовувати React і використовувати RESTful, а що ні, але ми хочемо використовувати CakePHP для цього. Чи можуть деякі люди направляти мене до корисних ресурсів про це? Я шукав це вже деякий час, але ніколи не прийшов до гідного рішення для цього.

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

Хочете звільнити дизайнера Front End від коду? Хочете прискорити інтеграцію? Хочете скористатися професійними методами, якими користуються найрізкіші веб-сайти? На сьогодні найкращим інструментом для цього є:

Фарба.

Так фарба. Ну якась програма малювання все одно. Дозвольте йому робити знімки екрана вашого сайту, переміщувати речі та додавати речі, які він знайде в іншому місці. Це дозволить йому працювати зі швидкістю своїх ідей і звільнить вас згинати код у будь-якій формі, яка найкраще підходить вам, надаючи йому те, що йому потрібно.

Якщо це все ще занадто повільно, скажімо, оскільки клієнт знаходиться в кімнаті з вами обома, я рекомендую значно досконаліший набір інструментів:

Папір, ножиці та стрічка.

Можливо, ручка, якщо ви відчуваєте себе честолюбним.

Я використовував цю техніку, щоб успішно приймати рішення з теми, стилю, змісту та основних особливостей веб-сайту за столом у хлібі Panera з замовником, перш ніж хтось зрозумів, що ми їмо.

Це зробить його швидким, звільнить вас від його "коду", і це насправді найпотужніший спосіб розробити інтерфейс користувача. Він може почати робити тести на зручність, перш ніж ви напишете рядок коду.

Ви можете думати, "о, це добре, коли ви починаєте роботу, але ви не користуєтесь цим, коли сайт розробляється". Неправда. Він працює так само добре на стабільних сайтах. Але зараз більшість знімків екрана надходять із вашого власного сайту.

Що робити, якщо дизайнер Front End хоче використовувати деякі інструменти для генерації коду, щоб зробити свої макети? Чудово, але не думайте ні на секунду, що вам доведеться використовувати його "код". Що вам потрібно поважати - це його рішення щодо вигляду, потоку та подання. Те, що відбувається за завісою, щоб це зробити, - це не його сфера знань. Це твоє. Візьміть на себе відповідальність за це.

Просто поважайте його роботу достатньо, щоб, коли ви закінчите, покажете йому, як це вийшло. Нехай він вибирає все, що зазнав би користувач. Будьте готові потрапити до нових ідей.

Це ітеративний розвиток. Не роби багато, перш ніж просити. Робіть якнайменше. Запитуйте як можна частіше. Покладіть іграшки на свій стіл, щоб розважати його, поки ви реалізуєте його останню ідею, щоб він міг переглянути її, як тільки завантажиться. Продовжуйте так, поки не настане час зустрітися з замовником.

Якщо код, створений дизайнером Front End, насправді вартий клопоту, то вам потрібно навчитися інтегрувати код з його. Для цього я наполегливо рекомендую вам вивчити контроль над джерелами . Вивчіть це так добре, що ви можете навчити свого дизайнера Front End як його використовувати.

Лише коли ви обидва зможете надійно використовувати інструмент управління джерелом, я не рекомендую базувати свій план інтеграції на коді злиття. У цей момент ваш друг заслужив би змінити назву з Front End Designer на Front End Developer.

Тепер, навіть якщо ви це зробите, це не здивувало б мене, якщо техніка малювання екрану на екрані все ще не виявиться найшвидшим способом співпраці для вас двох.

Можливо, ви просто не можете прийняти хаос усіх цих змін. Це створює занадто багато роботи. Добре це називається програмним забезпеченням, оскільки воно приймає зміни. Інакше ми мали би інженера-електрика зробити це на спеціалізованому чіпі. Можливо, вам потрібно буде досягти контакту, щоб вивести свою логіку поведінки з інтерфейсу користувача, щоб зміни інтерфейсу не впливали на ваші основні правила бізнесу. Якщо ви пришвидшите дизайнер Front End, вам потрібно бути готовим не відставати від них.

Єдина вагома причина змусити дизайнера Front End створити код - це тому, що ви втомилися і хочете їх уповільнити. Ну, мабуть, це насправді не "хороша" причина.

Що стосується інструментів, то оптимальний робочий процес, який я бачив, - це використання Sketch та Zeplin. Ескіз - це прямий інструмент дизайну. Еквівалентний Photoshop або InDesign, але оптимізований для розробки програм та веб-сайтів. Zeplin - це інструмент для спільного використання та затвердження дизайну в Sketch (або Photoshop). Він може дати точні вимірювання пікселів і навіть фрагменти коду для CSS або іншого коду макета та експортувати графічні активи. Після встановлення дизайну він передається розробнику. У цей момент розробник підбирає його і створює інтерфейс користувача. Тоді він може повернутися до дизайнера для візуального забезпечення якості. Все, що він виявить не так у цьому, має бути просто зареєстровано як помилка, яку слід визначити пріоритетною та вирішеною вами.

коли щось не виходить за призначенням (наприклад, це не вийшло так, як ми планували чомусь), я виправляю проблему на моєму боці, а потім надсилаю йому шаблон назад

Ось корінь ваших неприємностей. Потік дизайну завжди повинен бути Designer to Developerі не змінюватись назад. Перегляди та зміни повинні бути внесені дизайнером, а потім надіслані вам для впровадження на веб-сайті. Ви завжди можете самостійно робити виправлення, але спробуйте визнати, що ці швидкі виправлення є лише тимчасовими. Дизайнеру потрібно повернутися до своїх проектів і придумати правильне рішення. Потім він підштовхує зміни до вас, і якщо це станеться так само, як ваше швидке виправлення, то чудово, інакше ви оновлюєте його дизайн.

Він надсилає мені повний шаблон (експорт HTML з Pinegrow)

Не захоплюйтесь отриманням HTML, з яким можна працювати. Краще, якщо ви реалізуєте технологію веб-сайту (Bootstrap, CSS, jQuery, React, PHP, тощо. Тощо. Тощо) так, як вам це потрібно. Потім ви відтворюєте його проекти за допомогою цих інструментів. Якщо HTML, який він вам дає, це швидкий старт, то чудовий, але згодом, коли проект зростає, він не принесе користі. Вам потрібно буде внести зміни самостійно, тому що ви лише розумієте свій механізм шаблонів (наприклад, перегляди, шаблони, шаблони, додатки, компоненти та ін. Тощо) CakePHP.)

Цей процес, як можна було собі уявити, кропітко повільний і неефективний.

Це завжди було так. Дизайнери - це не програмісти. Вони витрачають свій час, щоб з’ясувати, що найкраще підходить для користувача, а іноді вони роблять помилки. Вони не розуміють таких понять, як компоненти, рамки тощо. Як програміст, ви повинні поговорити зі своїм дизайнером і поділитися тим, як я реалізую те, що ви проектуєте .

Дизайнер застряг посередині. З одного боку вони повинні задовольняти потреби програміста, а з іншого - задовольняти потреби користувача.

Отже, моє запитання полягає в тому, як ми можемо зробити цей процес більш плавним?

Я виявив, що фізично сидіти поруч із дизайнером та програмуванням там справді допомагає спілкуванню. Якщо ви двоє працюєте віддалено, тримайте час роботи на обличчі кілька днів. Це дійсно допомагає прискорити роботу.

Я бачив багато інформації про те, що ми повинні використовувати React і використовувати RESTful, а що ні, але ми хочемо використовувати CakePHP для цього.

CakePHP - одна з найкращих рамок на планеті (повне розкриття інформації, я в основній команді CakePHP).

Торт - це структура розвитку кроликів, де функції розроблені для швидкого створення веб-сайтів. Я знаю, що це звучить як крок продажів, але саме це класифікується. Існує багато інших рамок, які класифікуються як кролики. Java буде прикладом структури, яка є більш підприємливою, ніж кроляча. Якби ви використовували цю мову, я б запропонував змінити. Оскільки ви використовуєте CakePHP. Я б заперечив, що ти повинен залишатися з цим.

CakePHP створює хороший бек-сервер, якщо вам потрібні RESTful API.

React / Angular / Vue - всі популярні та популярні фронтальні рамки, але вони існують не дуже довго. З іншого боку, CakePHP існує вже 13 років. Моя думка - це не критика. Справа в тому, що ці бібліотеки JavaScript мають короткий термін зберігання. Через 5 років ми всі поговоримо про щось нове, але я підозрюю, що CakePHP все ще буде навколо.

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

Чи можуть деякі люди направляти мене до корисних ресурсів про це?

Запити на списки тут поза темою. Вибачте.

Редагувати :

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

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

Йому це має бути відносно легко, і це дозволить вам мати місце для коментування зазначених змін. Наприклад; він може подати запит на поновлення оновлення сховища, де ви виконуєте огляд змін до їх об’єднання.

Вам потрібно відокремити ці дві речі:

1. Дизайн UX та UI, не кодуюча діяльність
2. Впровадження, безумовно, кодування діяльність

Дизайнеру слід використовувати творчі інструменти типу Marvel, які призначені саме для дизайну. Дизайнерові не слід турбуватися робити що-небудь з кодом, HTML, CSS і т. Д. Кольори, розміри, естетика, взаємодія, анімація - все, на чому слід зосередитися.

Програміст повинен отримати активи та макет (із взаємодією та анімацією) і повинен це зробити завдяки програмуванню програмного забезпечення. Сюди ввійшли також HTML та CSS. Програміст також може використовувати генераторні інструменти на своїй стороні.

Для прискорення виконання завдань я рекомендую використовувати мінімальний інструмент на зразок Trello та посилати / документувати все для кожного робочого блоку.

як ми можемо зробити цей процес більш плавним?

Наполягайте на контролі версій

Розгалуження програмного забезпечення та паралельні всесвіти

• Працюйте над жодним кодом, не в контролі версій. повна зупинка. І я маю на увазі продовжувати страйкувати, поки проект не буде в VCS.
• Відділення формально, ліберально, локально
  • Формально: розгалуження для релізів та підрозділів випусків, виправлення формального тестування тощо. Розробіть офіційний план контролю версій, тобто запишіть його.
  • Ліберально: Поза 4-х частинною офіційною нумерацією випуску, відділіться, якщо ваша кишка каже вам, що це може бути хорошою ідеєю.
  • Місцево: я тримав персональну репо з гілками, які ніколи не були призначені для споживання командою, тому що ми, як команда, ми спочатку не розгалужувались, і у мене часто проводяться експерименти, розвідки, про всяк випадок тощо.

Інженер вийшов з вашого проміжного програмного забезпечення

Переваги:

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

Це питання запитання, не кажіть, застосований нав'язливо, нав'язливо. Якщо інтерфейс користувача маніпулює властивістю одного бізнес-шару, це неправильно.

Все і все, що стосується об'єктів бізнесу, повинно бути в зазначених БО. Навіть тривіальні речі, які можуть здатися найкращими в інтерфейсі користувача - навіть один LOC. Хвилина, як додавання двох значень, що надаються користувачем - вся асоційована логіка, включаючи перевірку, повинна бути в API бізнес-рівня. Звільнення від IMO іноді гаразд. Щоб пом'якшити надмірність, можливо, є невеликі, зосереджені об'єкти бізнес-рівня, до яких користувальницький інтерфейс має повний доступ.

Все, і все, що потрібен інтерфейс користувача від бізнес-об’єктів, має бути API'ed. Наприклад, є явні методи, які передають свої аргументи (аргументи) обробникам подій.

Остерігайтеся каркасів як милиці

У руках некваліфікованих кадрів та IDE не є перешкодами для монстрів B-кіно, які вони створюють.

З такими рамками, як React, ви можете сказати, що це все на стороні клієнта, що немає зворотнього бізнес-логічного шару. Ключова ідея тут - роз'єднання того, що бачить користувач, від того, що робить програма. Це можливо. Це не лише справа фізичного сервера та браузера користувачів.

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

Це не було б прийнятно майже в будь-якій іншій професії.

Доцільно розраховувати, що дизайнер, який спеціалізується на розробці веб-сайтів / додатків, достатньо добре знає CSS та HTML, щоб забезпечити вам робочі та зручні файли такого типу.

Дизайнери, які надають графічні редактори WYSIWYG, - це візуальні чи графічні дизайнери. Існує багато різних видів дизайнерів.

Однак існує також багато різних рівнів навичок, здібностей та досвіду. Той, хто проектує меблі, може це зробити виключно на комп’ютері з інструментами 3D-дизайну, і в цьому випадку їх знання про те, як повернути токарний верстат або керувати маршрутизатором з ЧПУ, може бути цілком теоретичним. Вони роблять свої проекти, а потім відправляють їх, щоб їх виготовили інші.

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

Ви не зможете переконати свого друга змінити спосіб їх роботи. Якщо ви хочете мати веб-дизайнера з навичками HTML та CSS для створення власних конструкцій, вам потрібно буде знайти його.