Сказка о разработке
все персонажи вымышлены, все совпадения случайны.
Витя, который хотел как лучше
одним весенним днём Витя решил, что хочет поздравить свою девушку Киру с днём рождения. да так, чтобы на всю жизнь! да так, чтобы раз и навсегда!
он пришёл к своим друзьям-разработчикам со следующей просьбой:
дорогие! я к вам с маленькой просьбочкой, тут делов на полчасика, наверное. хочу сделать для Кирюхи цифровую открытку. можно же сделать такой ну... э... сайт в интернете, куда она всегда будет заходить, а там моё поздравление ей? на бумаге не хочу, чтобы доступ всегда был, где бы она ни находилась, поможете?
чего ж не помочь старому другу. да и в команде разработчиков давно всё работало складно, гладко, отработанно. кстати, разрешите вам их представить:
Юля — юиксер (она же ухуй дизайнер или по красивому: ux/ui). это только звучит страшно. на самом деле Юля — человек, который рисует сайт так, чтобы пользователю было удобно им пользоваться. поэтому в кошмарах ей снится корзина не в верхнем правом углу, а внизу раздела «доставка и оплата»... ещё и с выравниванием
Феликс — фронтенд-разработчик. он оживляет странички в интернете. вот наводишь ты на кнопочку для подтверждения регистрации, и она становится красной, а не белой. это Феликс сделал, а подсказала ему Юля. Феликс ей доверяет и прислушивается (и все остальным тоже рекомендует).
Белла — бэкенд-разработчик. она прикрывает бэк двух ранее упомянутых коллег. кнопочка сколько-угодно может становиться красной, но только Белла может сделать так, чтобы после нажатия на неё где-то сохранялась информация. то есть пользователь навёл на кнопочку, она стала красной, одно нажатие... и Белла записывает твои фамилию, имя и номер телефона в свою внутреннюю базу данных (БД). теперь, если спросить у Беллы каждый из этих кусочков данных, они у неё разложены по полочкам.
и спросила наша бравая команда:
Вить, а чего хочешь-то? как это выглядеть должно, нарисуешь?
недолго думая, Виктор вырвал лист из блокнота и нарисовал что-то эдакое:
ну вот так... нашу фотку по центру, а снизу поздравление. и сердечки на фоне, если можно.
на вопрос Феликса о том, каким устройством пользуется Кира, был получен следующий ответ:
слушайте, ну у неё разные, но я бы хотел, чтобы она открывала с планшета и любовалась.
задача понятна, Юля пошла рисовать красивую картинку.
и важно понимать, что остальные члены команды были в курсе повестки, цели, сути этого мероприятия. в любом проекте ТЗ должно обсуждаться совместно со всеми разработчиками, чтобы каждый из них задал свои уточняющие вопросы, если такие будут. и сказал со своей стороны, всё ли возможно для реализации в указанные сроки.
Много буков
Да, много, основные выводы собраны в конце, там же лежит шаблон ТЗ для разработки. Но чтобы немножко понять внутренние процессы, можете прочитать и саму сказку.
Оглавление
- Как разработка должна работать
Да тут, наверное, делов на полчасика - Почему сложно вносить визуальные изменения
А классно у вас это получается! - Почему не получится просто из одной фотографии сделать галерею и какие вообще сложности бывают с фотками
Пока всё! - Процесс компромиссов. Прислушивайся, и будешь услышан!
А давайте, кстати, вот так попробуем? - Если контент постоянно меняется и дополняется, и хочется управлять им самостоятельно
Другое дело! - Почему продублировать механику не так уж просто, и что вообще за ней стоит
Это же также абсолютно! - Что-то типа выводов
И даже шаблон идеального ТЗ есть!
Часть 1. Да тут, наверное, делов на полчасика
механизм работы в разработке достаточно последовательный. сначала Юля создаёт макет, затем Феликс его оживляет, а потом Белла делает так, чтобы данные где-то хранились и куда-то передавались.
Юля нарисовала макет в Фигме, взяв фотографию ребят и текст, который прислал заказчик (Витя), получилось примерно вот так:
перед тем, как отдавать макеты Феликсу, Юля всегда общается с заказчиком и ждёт его одобрения. она отправила Вите посмотреть, что у неё получилось, он со всем согласился, но попросил добавить подпись к поздравлению, чтобы возлюбленная помнила, от кого открытка. подпись должна была быть, но не очень выбиваться.
в итоге вот такой макет устроил Витю, и работа была запущена дальше. а что это значит для Юли (в идеальном мире)? что она больше к этому проекту не возвращается. поскольку её задача была нарисовать макет, который устроил заказчика и команду.
в игру вступает фронт. Феликс сверстал этот макет. это как? он пишет код, где указывает параметры по каждому объекту на макете, а также как они взаимодействуют с базами данных, если такие есть. к счастью для Феликса, здесь никаких баз данных не было, а значит меньше мороки.
нужно понимать, что под объектом понимаются различные элементы макета. в нашем случае их четыре: фотография, фоновое изображение с сердечками, текст поздравления и подпись. у каждого из них свои настройки.
наш фронтенд запрогал (то есть ручками написал код) многие детали по каждому из объектов, вот, например, некоторые из них:
Дорогая Кирочка!
Будь всегда счастливой, любимой и яркой.
Я хочу провести с тобой всю жизнь!
С днём рождения, моя любовь!
- размер текста: 12 пикселей, расстояние между строками: такое-то, расстояние между буквами: такое-то, цвет... выравнивание... шрифт... вес шрифта (жирный или нет, кириллица или нет)
- а ещё и расположение самого блока с поздравлением, его ширина в пикселях, отступы от фотографии сверху, отступ перед подписью снизу
- а ещё размер фонового изображения, заполнит ли картинка с сердечками весь фон или только центральную часть
- ...и ещё много всякого...
стоит понимать, что в коде это выглядит не так понятно и приятно. но в первую очередь важно понимать, что это достаточно большой объём ручной работы.
Белле в этот раз повезло. когда на фронте была свёрстана картинка, похожая на макет, ей оставалось только выложить кусок кода на их рабочий сервер.
здесь стоит сказать о том, что покупкой домена, обеспечением работы сервера и другими техническими тонкостями занимаются дополнительные специалисты, а не сама по себе команда разработчиков. будем считать, что в нашей истории всё это у них уже имелось.
команда выдохнула. действительно, ушло не очень много времени, порядка 5ти часов непрерывной работы, зато друг будет рад, и девушка его особенно!
они скинули ссылку Вите и вышли за кофе в красивых стаканчиках...
Часть 2. А классно у вас это получается!
Витя ехал в этот момент на свидание с Кирой и был в метро. он открывал сайт в предвкушении чего-то радостно-прекрасного и даже сделал яркость на телефоне повыше. и...
ребят, а чего случилось такое?
сказать, что Витя был ошарашен, это ничего не сказать. хорошо, что День рождения только через неделю. ребята наверняка просто что-то сделали не так и быстро исправятся.
если вдруг и вы, читатель, думаете, что это косяк на стороне команды ЮФБ (Юля, Феликс, Белла), вы ошибаетесь. ведь изначально речь шла о разработке странички для просмотра на планшете.
для каждого устройства (а если быть точнее, для разной ширины экрана) необходимо делать свою отдельную версию и макета, и вёрстки на фронте. ведь для плазменных экранов нужна фотография сильно больше, чем для мобильных телефонов. да и вообще, есть экраны вертикальные, а есть горизонтальные!
кроме соотношения сторон разных экранов, надо также адаптировать макет для различных браузеров, потому что один и тот же шрифт в Chrome и Edge может выглядеть по-разному.
что же... Витя вот не знал, но вы теперь знаете, имейте это в виду!
ребята немного расстроились, что были вынуждены прервать свой кофебрейк, но благо страничка всего из четырёх элементов, они оперативно включились за создание адаптивов (то есть за адаптацию странички к разным версиям экранов). но вы ведь понимаете, мобильный телефон, старый мобильный телефон, домашний телек... вариаций много, как и макетов. поэтому даже на такую простую страничку уходит несколько часов (на рисование макетов Юлей и написание нового кода Феликсом).
обновлённую версию Белла выложила на нужный адрес (да, стоит понимать, что все те изменения, которые вносит фронтенд в код, они происходят только на его рабочем ноутбуке или компьютере и пользователь их не видит. только после публикации кода все внесённые изменения становятся доступны всем-всем).
новый вариант отправлен Вите. 4 часа свидания пролетели так незаметно, что окрылённый Виктор, взглянув на страничку с телефона, довольно написал:
а классно у вас это получается! быстро так! спасибо, ребят!
Часть 3. Пока всё!
счастливые ЮФБ, теперь уж точно уверенные в довольном друге, собирались домой. где-то в душе скреблись кошки, потому что реальный рабочий проект они сегодня абсолютно задвинули, но радость за влюблённых Киру и Витю брала верх. один денёк не так критично. как вдруг на эскалаторе метро Белла сказала:
так, коллеги...
в её мессенджере высветилось сообщение:
на этом моменте следует понимать, что сказка есть сказка. и следующие итерации, которые будут выполнять наши герои, они делают в ущерб своему сказочному рабочему проекту. но в реальной жизни ситуации происходят похожие, и страдают другие, действительно важные и нужные кому-то рабочие проекты.
не спрашивайте, откуда у ЮФБ столько времени и почему они работают за бесплатно. так получилось. сказка на то и сказка, но в реальности всё ведь совсем не так.
Витя прислал архив из 10 фотографий. на них Кира смеялась, танцевала, рисовала, готовила, и чего только не делала. Вите очень хотелось подчеркнуть, какая у него особенная и уникальная девушка. вместе с фотографиями он прислал и новый текст поздравления, чтобы он соответствовал тому, что на фотокарточках.
Юля адаптирует макет, меняя форму галереи, добавляя элементы слайдера.
но важно понимать, что фотографии, как и экраны, бывают разные. и горизонтальные, и вертикальные, и квадратные. и зачастую разработчики сталкиваются с тем, что отображение фотографий тоже надо как-то регулировать, а также учитывать при разработке макета (потому что если сделать макет под вертикальные фотки, а они в итоге будут квадратные, будет печаль). если картинки 3, то, в целом, можно вручную обрезать под необходимые пропорции. но ведь бывают галереи, где их десятки, сотни, и в таком случае заполнение картинкой может быть разным. вот, например, три варианта.
выглядит странно? однозначно. и задача разработчиков в том числе сделать так, чтобы в макете фотографии любых пропорций и ориентации выглядели нормально, без растягивания и потери важных деталей (как на первом примере, где Витя без головы). и я напоминаю, что для телефона, ноутбука и планшета создаются разные макеты. разный диаметр стрелочек, разные отступы и пропорции.
___
10 фотографий в ленте бережно обрезаны руками Юли и Феликса. Витя выбрал вариант заполнения, чтобы картинки были целостными. сайт опубликован.
Витя, ну как? оставляем?
да, ребята, кайф! я любуюсь и радуюсь, уверен, она будет счастлива! пока всё!
Часть 4. А давайте, кстати, вот так попробуем?
Витя попросил сделать галерею в форме сердечка, чтобы лишний раз подчеркнуть свои высокие чувства к Кире. к большому счастью, Юля его предостерегла, поскольку не все фотографии удачно впишутся в такую форму.
в 99% случаев UX-дизайнер готовит макет таким образом, чтобы он был удобен, приятен и доступен в любых обстоятельствах и на любых устройствах. если есть какие-то критичные моменты (например: показать свою любовь), UX-дизайнер предложит, как сделать это более симпатично и удобно.
но опять же! все пожелания необходимо озвучивать до начала работы команды.
Часть 5. Другое дело!
только ЮФБ не учли одного. Вите так понравилось, что через пару часов он решил, что хочет добавить ещё штук 30 фотографий. и часть из первых десяти удалить. здесь, наконец, вступает в игру Белла.
Белла в узком кругу решительно заявляет, что её немного смущает, что ребятам надо обрезать ещё 30 фотографий. и то не факт, что Витя остановится.
в таком случае, чтобы отдать часть работы заказчику (особенно, если он сам заинтересован в том, чтобы постоянно изменять контент, менять порядок, удалять что-то) разрабатывается админка. это что-то вроде личного кабинета, где пользователи могут менять данные, которые в свою очередь передаются на сайт и отображаются там.
здесь-то и подключается бэкенд с его базами данных и способом их хранения. ему необходимо подготовить среду для того, чтобы администратор/заказчик мог удобным образом загружать файлы, сортировать их, добавлять подписи, удалять при необходимости. при этом файлы должны поддерживаться разных форматов (ведь картинки бывают не только jpg), а ещё админка должна быть защищена авторизацией. мало ли кто захочет подглядеть рецепт сырников Киры, который Витя хочет разместить в галерее. да и в реальной жизни мы можем говорить о каких-то внутренних нормативных документах, которые необходимо держать под защитой.
все тонкости авторизации, безопасности, хранения данных, этим всем занимаются разработчики. они делают всё, чтобы не допустить взлома и утечки данных.
так вот! можно сказать, Белле надо сделать отдельное небольшое приложение, которое будет управлять сайтом. а именно — галереей. это, кстати, тоже делается с помощью написания кода и требует много усилий. но с другой стороны позволяет команде разработчиков доверить наполнение платформы кому-то ещё.
потратив n-ное количество времени на разработку админки, Белла скинула Вите логин и пароль. вот как теперь построен процесс:
- Витя загружает фотографию в админку.
- Она сохраняется в папку на сервере.
- В админке ей присваивается ID (уникальный идентификатор).
- Дополнительно каждой фотографии присваивается вес (обычно — порядковый номер). Вес может редактировать администратор. Он отвечает за сортировку карточек в галерее (в галерее они идут в порядке возрастания веса).
- Благодаря тому, что Белла соединила папку с фотографиями на сервере с платформой, фотография практически мгновенно оказывается на платформе, сразу после загрузки. Но обычно в админке создаётся ещё одна колонка для статуса фотографии, где изначально статус черновик, но администратор может поменять его на опубликовано.
- Соответственно, если фотография из админки удаляется, она мгновенно исчезнет и с сайта (поскольку сайт потеряет связь с ней, ведь её больше на сервере тоже нет).
таким образом, в базе данных хранится не только файл фотографии, но и его ID, вес, статус, какие-то технические характеристики, описание, расширение при необходимости и другие детали. всё это — в формате больших таблиц. и у каждого параметра есть свой тип (например, ID и вес — это целые числа, причём ID это автоматическое значение, а вес может быть отредактирован; описание к фотографии это текст; если говорить про технические характеристики, то они сохраняются в формате дробных чисел. каждая переменная имеет свой тип. и это важно понимать). все тонкости ввода данных для каждого параметра также прописывает в коде бэкенд.
почему важен тип данных? потому что в зависимости от типа данных с ними можно проделывать разные итерации. например, текст не сложишь с другим текстом в отличие от чисел. а два дробных числа не объединишь в абзац текста, что вполне себе можно сделать с несколькими словами. если тип данных числа, то их сортируют по возрастанию и убыванию. если буквы — то по алфавиту. и всякое такое.
ну и будет странно, если мы просим у человека ввести его возраст, а он пишет «пятнадцать». точнее, странного ничего, но как это обрабатывать? как выбрать только тех, кто старше 18, если нельзя отсортировать по возрасту?
кстати, ещё Витя попросил, чтобы под каждой фотографией можно было добавить отдельный маленький комментарий именно к ней. как мы помним, Юля в таком случае переделывает макеты для разных видов устройств и отдаёт Феликсу, который меняет отступы, ширину блоков и прочее. после любой маленькой правки! после каждой!
ну! вот это другое дело! теперь я могу всё! спасибо, друзья, с меня поход в пиццерию после праздника. сейчас весь в мыле, готовлю песню для Кирюхи!
и здесь надо сказать о том, что в разработке есть два типа контента.
первый — статичный. например, поздравление от Вити. его прописал в коде Феликс, и он является частью кода страницы. чтобы его поменять, надо лезть в код.
второй — динамический, управляемый. например, фотографии. в таком случае данные можно редактировать достаточно оперативно без участия команды разработчиков. но! для этого нужно разрабатывать отдельную админ-панель.
соответственно, при разработке чего-угодно нужно понимать: как часто будет меняться контент и информация в каждом отдельном блоке?
чем больше блоков меняются, тем больше работы у бэкенда для создания баз данных. это могут быть отзывы участников текстом, видео с мероприятий, ссылки на статьи. если что-то из этого регулярно меняется, лучше сделать управление через админку, чтобы заказчик сам вносил эти изменения, а разработчики были отключены от процесса.
если же блок статичен (ну, например, блок с контактами, где адрес электронной почты меняется очень редко), то проще вносить изменения напрямую через код страницы, то есть через фронтенда.
Часть 6. Это же также абсолютно!
пара дней затишья позволила команде немного переключиться на свои актуальные задачи. Витя же зря время не терял, демонстрируя всю эту пару дней свою электронную открытку всем друзьям. конечно же, при условии, что они сохранят это в тайне.
двадцать четвёртый друг не выдержал и сказал:
слушай, а чего, а давай я тоже напишу? идея-то классная! раскидаем ребятам, пусть они свои поздравления напишут, а Кирюха их будет листать!
Вите было неловко напрягать команду разработчиков, они и так уже несколько дней выделили под его открытку. он поделился своими сомнениями с другом, на что тот ответил:
да ладно тебе, это же также абсолютно! они ж вот слайдер с картинками сделали, какая разница, что будет крутиться, текст или фотки. всё, не парься, пиши своим разрабам, а я пока ребят попрошу пару предложений каждого написать.
стоит ли говорить о том, что большая разница, будет крутиться текст или фотографии? надеюсь, что нет. как и о том, что для создания блока поздравлений, которых будет непонятно сколько, нужно разрабатывать ещё одну таблицу в БД, куда ребята могут через админку подгружать сам текст поздравления, автора поздравления и... ещё почему-то город... Витя подумал, что у Киры столько друзей со всей России, что будет классно показать географию поздравлений. пусть она видит, как её везде любят и ждут!
в процесс снова включились все: Белла занималась адаптацией базы данных под новые цели...
Юля думала, как же уместить в блоке поздравлений и текст, и подпись, и город, и функции слайдера... доработав макет до следующего вида.
а Феликс прописал интеграцию (как связаны данные из таблиц Беллы и контент в макете Юли.
потом, конечно, друзья Киры просили команду бравых разработчиков ещё сделать интерактивную карту, чтобы при наведении на город выводились поздравления друзей оттуда, но это уже совсем другая история...
Часть 7. Что-то типа выводов
на самом деле, их будет не очень много. весь предыдущий рассказ лишь для того, чтобы немного приблизить вас к тонкостям процесса разработки, вёрстки и создания интернет-страниц. с многостраничными сайтами всё гораздо сложнее.
мысль раз: любой маленький объект, который необходимо добавить, требует перезапуска всех процессов разработки. от ux через вёрстку страницы и к созданию баз данных. поэтому любые изменения относительно объектов на странице очень болезненны для разработчиков. любые подвижки, даже немножечко вправо. это не каприз, это условия работы.
но! это почти не касается самого контента. то есть, если в макете было заложено место под квадратную фотографию, фотографию можно будет достаточно легко поменять, если она квадратная. если надо поменять имя члена жюри, это тоже легко сделать, потому что это часть контента.
а вот добавить нового члена жюри = добавить новый объект, ровно как добавить стрелочки по бокам фотки, чтобы они крутились как галерея.
единственное исключение касается объёмов текста и количества символов. если на макете было предусмотрено место под должность члена жюри, то подразумевается, что она не потребует много места. под неё выделяется небольшое поле. если вдруг вы решите кроме должности добавить туда краткую биографию, весь макет съедет нафиг!
мысль два: перед написанием тз поймите для себя, какая информация у вас будет требовать регулярного обновления изменения и обновления, а что будет крайне редко изменяться. это позволит команде понять, для чего нужна админка, а для чего — нет.
и обязательно укажите в своём тз, что количество этапов может поменяться, даже если сейчас их указано 5. ведь, если UX нарисует картинку на 5 этапов, а потом их станет 3, придётся всё переделывать с нуля. гораздо лучше сразу делать картинку такую, которая будет легко адаптироваться под разные параметры, а также параллельно разрабатывать админку, в которой вы сами сможете вносить необходимую информацию, которая будет подтягиваться на страницу.
мысль три: многие судят про создание страничек как про создание слайда презентации. сюда блок, сюда контрл-ц контрл-в, здесь выравнивание по правому краю, здесь цвет быстренько поменял. в разработке всё сложнее.
на интернет-странице каждый объект имеет одинаковые характеристики. и, если часть текста вам нужна синим, а часть чёрным, будет проще сделать два блока, чем редактировать всё внутри одного.
мысль четыре: мы все классные, и каждый делает свою работу. если UX-дизайнер закладывает в макет синий фон, не надо без причины просить его сделать красным. у всего есть свой смысл и замысел, лучше обсудить и прийти к компромиссу. или высказать свои пожелания ДО начала работы. все тонкости, которые могут помочь дизайнеру в работе, лучше озвучивать.
условно, если мы делаем сайт студенческого конкурса или страничку для презентации новой книги, оформление будет визуально разниться, поскольку направлено на разные целевые аудитории.
на этапе написания и обсуждения ТЗ надо озвучить как можно больше: возможно будет так/это может измениться/был вот такой запрос, чтобы это можно было предусмотреть заранее, а не в последний момент.
мысль пять: мы подготовили шаблоны, чтобы на этапе формирования ТЗ вам было чуть проще понимать, что нам важно знать для разработки страничек. во-первых, это может натолкнуть на какие-то ещё неподуманные вами мысли. во-вторых, это здорово облегчит нам работу.
это шаблон для лендингов (страничек в интернете, сайтов).
это шаблон для личного кабинета (если он нужен в рамках проекта).
скачивайте и пользуйтесь, мы будем очень благодарны!
и тогда из точки А в точку В не придётся делать сто тысяч итераций, все рады, счастливы, довольны и не ругаются за день до дедлайна. кра-со-та!
