Comments 6
Спасибо! Очень интересные статьи))
Спасибо.
Осилил обе части и внимательно почитал ТЗ которое тут привели, как пример. Оно исчерпывающее для дизайнера, много скриншотов, все поля расписаны, класс и даже вполне нормально для frontend разработчика (хотя не совсем), но для бэкенда там ничего. Ни про валидацию серверную, структуру БД, внутреннюю бизнес-логику, workflow, откуда брать справочники, словари и т.д. и т.п.
Бэкенду работать с такой спецификацией очень тяжело будет -)
Возможно это у вас в каком-то еще документе описано, который за рамками ТЗ и не показывается заказчику.
Вообщем, про эту часть было бы интересно почитать тоже.
Еще раз спасибо больше, огромный труд проделали.
P.S. И еще, вы совсем как-то упустили момент в статье, с этого нужно было бы начать, что вы используете подход Outside-in в проектировании (от интерфейса), есть еще Inside-out, для «серьезных» сайтов и систем он, чаще, более предпочтительный.
Осилил обе части и внимательно почитал ТЗ которое тут привели, как пример. Оно исчерпывающее для дизайнера, много скриншотов, все поля расписаны, класс и даже вполне нормально для frontend разработчика (хотя не совсем), но для бэкенда там ничего. Ни про валидацию серверную, структуру БД, внутреннюю бизнес-логику, workflow, откуда брать справочники, словари и т.д. и т.п.
Бэкенду работать с такой спецификацией очень тяжело будет -)
Возможно это у вас в каком-то еще документе описано, который за рамками ТЗ и не показывается заказчику.
Вообщем, про эту часть было бы интересно почитать тоже.
Еще раз спасибо больше, огромный труд проделали.
P.S. И еще, вы совсем как-то упустили момент в статье, с этого нужно было бы начать, что вы используете подход Outside-in в проектировании (от интерфейса), есть еще Inside-out, для «серьезных» сайтов и систем он, чаще, более предпочтительный.
Прекрасный пример проектирования.
К сожалению мои попытки сделать что-то подобное заканчивались тем, что по ходу заказчик выдвигал новые требования и части аккуратно созданного документа отправлялись в урну.
К сожалению мои попытки сделать что-то подобное заканчивались тем, что по ходу заказчик выдвигал новые требования и части аккуратно созданного документа отправлялись в урну.
Так смысл в том, чтобы проектировать вместе с заказчиком) Он же носитель идеи! От его мнения мы отталкиваемся, а потом за ручку ведем по этапам проектирования, заставляем утверждать каждый промежуточный этап и в конце он выговаривается полностью, все его замечания учитываются, ничего не нужно выкидывать.
Sign up to leave a comment.
Серьезное проектирование серьезных сайтов. Часть 2. Визуализация