Итак. начнем. С чего все начинается? С заказа. А заказ, это технческое задание. ТЗ. Но хорошо, когда оно есть. Чаще нет, и сделать его заказчику не представляется возможным. Потому что он "хочет чего то, не знает кого".
Однако работать без технического задания, это сущий ад. А посему, прежде чем приступить, прежде чем даже включить компьютер, нужно выпотрошить заказчика на изнанку. Вынуть из него кишки. Чтобы ему самому плохо стало от общения с вами. Это касается не только фриланса, на постоянном месте работы все тоже самое.
Хорошо, если есть менеджер, это его работа. Однако знать такую работу необходимо и программисту. В конце концов тот же менеджер при общении с вами плавно превращается в заказчика.
Так вот. Для того, чтобы вынуть душу из заказчика, придумали DDD (Domain-Driven Design).
Для несведущих это может показаться чем то запредельным. Хотя все, как обычно, гораздо проще, если разогнать туман пафосных терминов и определений.
По сути это язык общения заказчика с исполнителем.
Обычно заказчик понятия не имеет, как и из чего строятся программы, исполнитель ни сном не духом о том, что в итоге представляет себе заказчик. В итоге получается разговор слепого с глухим.
Допустим есть заказ на сайт логистической компании. Заказчик говорит - хочу, чтобы была возможность заказать отправку груза с расчетом оптимального маршрута, выбор способа доставки и система отслеживания.
Реакция исполнителя:
Он говорит: ну... тут нужно применить концепцию MVC, задействовать базу данных, можно Geo IP прикрутить, а вообще нужен хороший фреймворк.
Реакция заказчика:
Так вот, чтобы такого небыло, нужно найти общий язык. Это просто.
Не нужно стесняться показаться дилетантом в специфике заказчика. И не нужно стараться показать свою крутость в программировании. Нужно разговаривать с ним, как с ребенком. И заставить его делать тоже самое с вами. Чем проще, на пальцах, будет обшение, тем лучше результат.
Я много раз был в Европе, там с иностранцами все общаются на "международном английском". Это такой суррогат из неправильных английских слов с примесью местных диалектов. Так вот, парадокс. Чем лучше собеседник знает язык, тем сложнее с ним общаться. Проще всего разговаривать с детьми.
Есть такая тактика, пять "почему". Дети как раз любят эту штуку. Только они могут задать их не пять, а двадцать пять. С заказчиком нужно делать тоже самое.
Берем лист бумаги. Рисуем на нем квадратик. И говорим - это сайт. Чего здесь не хватает? Калькулятора расчетов. Рисуем второй квадратик, пишем на нем сверху - "калькулятор расчетов стоимости". Опять показываем - чего нехватает в этом калькуляторе? Окошка вывода результата и панели для ввода данных. Рисуем еще два квадрата, пишем "результат" и "ввод данных". Тут? Тут вроде бы всё. OK. Как должен выглядеть результат и какие нужно ввести данные?
И так далее, пока не исчезнут все вопросы.
И вот когда они исчезнут, на этом листочке будет ясна не только структура морды, но и многие подводные камни специфики сайта, о которых иногда и заказчик не подозревает.
Это называется "предметная область", которая теперь разрисована в понятную обоим блок-схему.
Это один из самых простых способов реализации DDD. Не нужно ничего мудрить перед заказчиком, особенно с терминологией. И Боже вас упаси рисовать ему UML. Чем проще, тем лучше. С UML разберемся чуть позже.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
