Скажем, грамотного техписателя, который умеет внятно формулировать свои мысли, да еще и понимает подноготную (не обязательно веб), — это надо еще поискать.
Ну да.
_Один мой друг_, сеньор-разработчик, откликнулся на вакансию техписа в СберТехе (зачем – обсуждать не будем). Так вот сразу прислали отказ (без объяснений) и даже не стали проверять, насколько внятно он умеет формулировать свои мысли.
Наш любимый заказчик (20 лет взаимодействуем) выдал как-то «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду».
Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть) Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?
потом выкатит миллионную неустойку
Мы ведь говорим о требованиях, которые были заказчиком утверждены и подписаны, так? Поэтому юридически неа, он бессилен.
в стоимость всех работ сразу закладывать расходы на доработки
Как вариант – почему бы и нет? Но и в этом подходе есть минусы:
Из-за изначально более высоких цен теряем часть потенциальных заказчиков.
Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.
Когда аналитик ставит задачу - дизайнер знает, что есть ширина стопы и что размерная таблица параметрами, которые нужно свести в таблицу, например.
Так вот и я о том, что это аналитик должен знать и учитывать скрытую логику, и вообще бизнес-логику и бизнес-данные. Это он знает, для чего эта задача, какую проблему закрывает и т.д.
Разработчики получают задание в уже очень рафинированном виде, им всё это знать совершенно не нужно. У разработчиков есть свой, огромный пласт знаний – внутреннее устройство системы, и аналитик нужен, в том числе, чтобы разработке не требовалось глубокое погружение в предметную область и бизнес-процессы. Иначе перегрузка и взрыв головного мозга :).
Значит, я неправильно понял, у меня после прочтения сложилось впечатление, что "изменение требований в процессе (или тем более после) разработки – это не проблема заказчика, а проблема исполнителя".
Был неправ, вспылил. Но теперь считаю своё предложение безобразной ошибкой, раскаиваюсь, прошу дать возможность загладить, искупить. Всё, ушел.
Дизайнеры получают подробно выявленные требования. Они понимают, для чего эта задача, какую проблему она закрывает, какие данные необходимы и как всё должно функционировать.
Без такого анализа дизайнер может не учесть скрытую логику или понять её некорректно.
Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
> Но это не проблема заказчика — это проблема исполнителя.
Ну здрастити! Тогда заказчик будет вообще не переставая менять требования.
При возникновении такой ситуации говорим: "Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков". Очень хорошо отрезвляет и заставляет заказчика в будущем больше думать над формулированием своих требований.
Так я и говорю о том, что на Ваших иллюстрациях ни луковая, ни гексагональная архитектура. Так что эти иллюстрации подходят для дизайна, но не подходят для архитектуры.
Примеры тоже все про разделение ответственности по классам, а значит -- про дизайн.
CQRS я просто вспомнил как ещё один пример архитектуры с разделением мутабельности/иммутабельности, к теме статьи это никак не относится.
Хотелось бы уточнить, что сам я за такой подход – разделение мутабельного и иммутабельного кода – всеми руками и ногами, что у меня есть :), просто мы с Вами расходимся во мнении, где кончается архитектура и начинается дизайн. Предлагаю на этом закончить и разойтись, каждый со своим мнением :).
Если мы говорим за архитектуру, в которой иммутабельное ядро (обычно это домен) оборачивается в мутабельную оболочку (оболочки), то тогда это луковичная (onion) или гексагональная архитектуры, и слоёв там больше чем два. Приведённые же иллюстрации (те, на которых круги) как раз таки очень хорошо подходят для концепции широкого и глубокого кода, которая про дизайн.
К слову, ещё один вариант архитектуры с разделением на мутабельные и иммутабельные части – CQRS, только там они не оборачивают друг друга, а существуют параллельно.
Только непонятно, почему автор использует термин "архитектура". Раз мы оперируем классами, то речь идёт об иммутабельном дизайне. Архитектура лежит выше и даже не знает, что там внизу - ООП, ФП или процедурщина.
Вы вообще не привели никакой выборки, но при этом сделали глобальный вывод о всей сфере.
Но неадекватен при этом я, да.
Ну да.
_Один мой друг_, сеньор-разработчик, откликнулся на вакансию техписа в СберТехе (зачем – обсуждать не будем). Так вот сразу прислали отказ (без объяснений) и даже не стали проверять, насколько внятно он умеет формулировать свои мысли.
А ничего, что Git и GitHub – это разные вещи?
Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть) Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?
Мы ведь говорим о требованиях, которые были заказчиком утверждены и подписаны, так? Поэтому юридически неа, он бессилен.
Как вариант – почему бы и нет? Но и в этом подходе есть минусы:
Из-за изначально более высоких цен теряем часть потенциальных заказчиков.
Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.
Так вот и я о том, что это аналитик должен знать и учитывать скрытую логику, и вообще бизнес-логику и бизнес-данные. Это он знает, для чего эта задача, какую проблему закрывает и т.д.
Разработчики получают задание в уже очень рафинированном виде, им всё это знать совершенно не нужно. У разработчиков есть свой, огромный пласт знаний – внутреннее устройство системы, и аналитик нужен, в том числе, чтобы разработке не требовалось глубокое погружение в предметную область и бизнес-процессы. Иначе перегрузка и взрыв головного мозга :).
Значит, я неправильно понял, у меня после прочтения сложилось впечатление, что "изменение требований в процессе (или тем более после) разработки – это не проблема заказчика, а проблема исполнителя".
:)
Причём очень большие, ибо предсказывают будущее люди ну оооочень плохо.
Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
Может быть подразумеваются проектировщики ПО?
> Но это не проблема заказчика — это проблема исполнителя.
Ну здрастити! Тогда заказчик будет вообще не переставая менять требования.
При возникновении такой ситуации говорим: "Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков". Очень хорошо отрезвляет и заставляет заказчика в будущем больше думать над формулированием своих требований.
Там надо щёлкнуть по шкале и выставить ноль. Тогда ответ принимается.
// зануда on
2500 тысяч == 2,5 млн.
// зануда off
:)
Влад, супер! И идея, и реализация.
Единственное, чего не достаёт до идеала – настройки размера шрифта не только в редакторе, но и в output.
P.S. Мне ещё хоткеев не хватает, но это уже капризы )))
Ищу и качаю в свободное от чтения время =D. Накопилось уже 67 гигов книг (и это только по IT).
Каждый рабочий день утром, после подъема, полчаса читаю книги. На одну книгу примерно месяц уходит, в год по 10-12 штук.
Женат + дети, не трезвенник, друзья есть. Воля вот ни разу не стальная. ЧЯДНТ?
Попробовал войти несколько раз, с паузами в несколько часов. Каждый раз ошибка с капчой :(.
Книга шикарна. Крайне всем рекомендую, особенно мне зашла концепция широкого и глубокого кода.
Владимир, спасибо!
P.S. Но всё равно я адепт лондонской школы =D.
Так я и говорю о том, что на Ваших иллюстрациях ни луковая, ни гексагональная архитектура. Так что эти иллюстрации подходят для дизайна, но не подходят для архитектуры.
Примеры тоже все про разделение ответственности по классам, а значит -- про дизайн.
CQRS я просто вспомнил как ещё один пример архитектуры с разделением мутабельности/иммутабельности, к теме статьи это никак не относится.
Хотелось бы уточнить, что сам я за такой подход – разделение мутабельного и иммутабельного кода – всеми руками и ногами, что у меня есть :), просто мы с Вами расходимся во мнении, где кончается архитектура и начинается дизайн. Предлагаю на этом закончить и разойтись, каждый со своим мнением :).
А вот теперь я с Вами не соглашусь :)
Если мы говорим за архитектуру, в которой иммутабельное ядро (обычно это домен) оборачивается в мутабельную оболочку (оболочки), то тогда это луковичная (onion) или гексагональная архитектуры, и слоёв там больше чем два. Приведённые же иллюстрации (те, на которых круги) как раз таки очень хорошо подходят для концепции широкого и глубокого кода, которая про дизайн.
К слову, ещё один вариант архитектуры с разделением на мутабельные и иммутабельные части – CQRS, только там они не оборачивают друг друга, а существуют параллельно.
Только непонятно, почему автор использует термин "архитектура". Раз мы оперируем классами, то речь идёт об иммутабельном дизайне. Архитектура лежит выше и даже не знает, что там внизу - ООП, ФП или процедурщина.
Для описанного в статье подхода Хориков в своей книге использует термины "широкий и глубокий код".