Что такое Design first и Code first

В раз­ра­бот­ке мно­го тео­рий, мето­дов и под­хо­дов. Вот один из спо­со­бов на это посмот­реть: с точ­ки зре­ния гла­вен­ства дизай­на или кода. Вот два подхода:

  1. Code First — сна­ча­ла код, потом всё остальное.
  2. Design First — сна­ча­ла про­ек­ти­ро­ва­ние, потом всё остальное.

В наших учеб­ных про­ек­тах в «Коде» мы дей­ству­ем по пер­во­му прин­ци­пу, пото­му что наша зада­ча — запу­стить что-то рабо­то­спо­соб­ное как мож­но быст­рее. Сна­ча­ла у нас счи­та­ет­ся логи­ка, запус­ка­ют­ся функ­ции и нажи­ма­ют­ся кно­поч­ки, а уже потом мы при­ду­мы­ва­ем интер­фейс и наво­дим красоту. 

Под­ход Design First рабо­та­ет наобо­рот: про­ек­ти­ров­щи­ки сна­ча­ла при­ду­мы­ва­ют, как про­дукт дол­жен выгля­деть со сто­ро­ны и рабо­тать, а потом уже про­грам­ми­сты при­ду­мы­ва­ют, как это ожи­вить. Они смот­рят на экра­ны и на логи­ку рабо­ты и пишут код, кото­рый будет рабо­тать имен­но так, как хотят дизайнеры.

У каж­до­го под­хо­да есть свои плю­сы и минусы.

🤔 Что есть дизайн

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

В более широ­ком смыс­ле дизайн — это как про­дукт устро­ен. Напри­мер, как рабо­та­ет вход в лич­ный каби­нет: по паро­лю, по отпе­чат­ку паль­ца, через соц­се­ти или вхо­да как тако­во­го вооб­ще нет, а при­ло­же­ние про­сто каким-то вол­шеб­ным обра­зом узна­ёт чело­ве­ка? Это дизайн. 

Или, напри­мер, покуп­ка това­ра: пом­нит ли сайт ваш адрес и номер кар­ты? Есть ли покуп­ка в один клик? А если есть — куда достав­ля­ет­ся товар? Как изме­нить адрес достав­ки, если уже опла­тил? После­до­ва­тель­ность окон, кно­пок, раз­ных путей по про­дук­ту — всё это тоже дизайн. 

В рус­ском язы­ке сло­во «дизайн» часто свя­зы­ва­ют имен­но с кра­со­той, но в мире ИТ оно ско­рее озна­ча­ет «про­ек­ти­ро­ва­ние», то есть «как эта вещь устроена». 

Code first

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

Глав­ное пре­иму­ще­ство здесь — ско­рость. Мы не про­ек­ти­ру­ем интер­фейс, не рису­ем про­то­ти­пы в гра­фи­че­ском редак­то­ре, не обра­ща­ем вни­ма­ние на шриф­ты, цве­та и оформ­ле­ние. Наша зада­ча — быст­ро понять, будет ли рабо­тать технология.

✅ Плюс под­хо­да — про­дукт рабо­та­ет почти сразу. 

❌ Минус — в том виде, в кото­ром он рабо­та­ет, им может быть неудоб­но поль­зо­вать­ся. Что­бы ста­ло удоб­но, нуж­но спро­ек­ти­ро­вать интер­фейс и отдать на дора­бот­ку про­грам­ми­стам, а это для них может озна­чать пере­ра­бот­ку кода.

Code first

Design first

В под­хо­де Design First про­ек­ти­ров­щи­ки сна­ча­ла при­ду­мы­ва­ют про­дукт извне: что и как долж­но рабо­тать с точ­ки зре­ния чело­ве­ка. Может быть, соби­ра­ют про­то­тип и тести­ру­ют его на пользователях. 

Когда дизайн про­ве­рен, про­грам­ми­сты пишут для него код.

✅ Плюс в том, что про­дук­ты полу­ча­ют­ся более дру­же­люб­ны­ми и удобными. 

❌ Минус — делать такие про­дук­ты дольше.

Design first

Вы тут понарисовали, как нам это реализовывать? 

Глав­ная слож­ность под­хо­да Design First — когда про­ек­ти­ров­щик мало что зна­ет о тех­ни­че­ских огра­ни­че­ни­ях раз­ра­бот­ки, поэто­му при­ду­мы­ва­ет очень слож­ные в реа­ли­за­ции вещи. И слу­ча­ет­ся кон­фликт: дизай­нер это нари­со­вал, а раз­ра­бот­чик не может это сде­лать в отве­дён­ное время.

Напри­мер: 

  • Дизай­нер при­ду­мал, что при­ло­же­ние реко­мен­ду­ет това­ры опре­де­лён­ным обра­зом. У нас есть модуль товар­ных реко­мен­да­ций, но дизай­нер нари­со­вал для него нестан­дарт­ное пове­де­ние. Пере­пи­лить модуль реко­мен­да­ций — это рабо­ты на месяц. 
  • Дизай­нер при­ду­мал нестан­дарт­ный эле­мент интер­фей­са. Он нужен по смыс­лу в этом при­ло­же­нии, но его нет в биб­лио­те­ках и гай­длай­нах для раз­ра­бот­чи­ков под эту ОС. Один этот эле­мент сто­ит несколь­ких недель работы. 
  • При­ло­же­ние долж­но хра­нить дан­ные о поль­зо­ва­те­ле для его удоб­ства. Но что­бы их хра­нить, нуж­но ста­но­вить­ся опе­ра­то­ром пер­со­наль­ных дан­ных и орга­ни­зо­вы­вать инфра­струк­ту­ру в Рос­сии, а мы на это не рас­счи­ты­ва­ли. При­дёт­ся пере­счи­ты­вать эко­но­ми­ку и пере­де­лы­вать бэкенд с учё­том рос­сий­ских серверов. 

Это одна из при­чин, поче­му в раз­ра­бот­ке так важ­ны обще­ние и управ­ле­ние. Когда слу­ча­ют­ся такие столк­но­ве­ния, у раз­ра­бот­чи­ков дол­жен быть тим­лид или дирек­тор по раз­ра­бот­ке, а у дизай­не­ров — глав­ный дизай­нер, кото­рые дого­во­рят­ся меж­ду собой, что из дизай­на долж­но пой­ти под нож, а где долж­ны напрячь­ся разработчики. 

Так и живём: тут ком­про­мисс, там невоз­мож­но, тут слиш­ком доро­го, там некра­си­во, и такая ерун­да целый день.

Текст и иллю­стра­ции:
Миша Поля­нин

Редак­тор:
Мак­сим Ильяхов

Кор­рек­тор:
Ира Михе­е­ва

Иллю­стра­тор:
Даня Бер­ков­ский

Вёрст­ка:
Маша Дро­но­ва

Достав­ка:
Олег Веш­кур­цев