Думаете, чтобы разработать ракету нужен детальный техпроект, план и далее сборка по чертежам? Тогда вы сильно удивитесь, если прочитаете, как это делается в SpaceX
Не надо вводить в заблуждение и ссылаться на то что раз SpaceX якобы делает ракеты по наитию то и все так должны делать.
Во первых это не правда. Специально перечитал главу про SpaceX из книги на которую вы ссылаетесь. Нет там ничего о том что сейчас они собирают ракеты без плана и чертежей. Могу предположить что возможно на начальных этапах что-то подобное и было, когда Макс сам за это отвечал но все мы помним как его ракеты взрывались а потом он и сам признал в одном из интервью что если бы на его месте был бы более опытный человек этих взрывов можно было бы избежать но на тот момент такого человека не было.
Во вторых мне кажется что нежелание продумывать детали фичи перед началом работы над ней прикрываясь всякими там Agile характеризует руководителя проекта как человека не способного стратегически мыслить и доносить свои мысли и идеи подчиненным в понятной для них форме. Конечно не все можно продумать заранее но любые ошибки найденные на этапе планирования исправить проще и дешевле чем те же ошибки (я сейчас не имею ввиду баги разработчиков) сделанные на этапе разработки.
В третьих, я сам руковожу проектами и ставлю задачи командам, и предыдущее утверждение основано на моем личном опыте.
Спасибо за статью. Приятно видеть что есть люди понимающие важность документации.
Из личного опыта могу добавить что у себя сделал обновление документации частью процесса разработки. В каждой фиче есть подзадача о том что после завершения разработки нужно добавить или обновить существующую документацию: подправить архитектуру, добавить детали реализации в описание фичи в Wiki и т.д. Эта задача как и любая задача разработки должна пройти ревью (быть просмотрена и понята другим членом команды в идеале не задействованным в работе над этой фичей). При таком подходе у нас документация всегда в актуальном состоянии и при этом время на написание документации запланировано в работу над фичей и обычно не требует больших трудозатрат, да и делается по свежей памяти а не через пол года после релиза.
А можно посоветовать литературу по маркетингу для тех кто программистов которые уже находятся на стадии, когда у вас уже есть какие-то заказы, пришедшие по сарафанке?
Автор статьи предлагает вынести логику из сервисов бизнес логики в контроллеры, но почему бы не пойти дальше, зачем тогда использовать эту ненужную прослойку под названием репозиторий и вообще зачем ORM можно же напрямую SQL запросы в базу писать или (как уже в комментариях было отмечено) хранимки использовать? Да и этот бесполезный IEmailService — кому он нужен? Пишите все в контроллере. Да и кому вообще нужна тестируемость, программисты должны код без ошибок писать, к чему еще думать про какие-то там тесты пусть QA баги ищет.
[Это был сарказм]
Ну а если по делу то цель создание сервисов бизнес логики равно как и репозиториев это разделение ответственности. Вы ведь упоминали в статье про трехслойную архитектуру (кстати слоев вполне может быть больше чем три, взять хотя бы тот же DDD) суть разделение по слоям не в следовании каким-то каргокультам внушенным нам рептилоидами а в разделении ответственности. Контроллеры отвечают за HTTP (ну или другой протокол обмена сообщениями), репозитории за взаимодействие с базой данных… Реализация IEmailService например за отправку почты. Я обычно бизнеслогику засовываю в .Net Standard либы чтоб не было соблазна «платформо-зависимый код» в них писать.
Слышали наверняка что слои верхнего уровня не должны знать о реализации нижнего уровня? Кто знает что там у него под капотом у реализации IEmailService, может быть он запускает механическую ногу, которая пинает спящего возле офиса бомжа, который несет вашему юзеру бумажку с распечатанным сообщением. В любом случае автор ведь использует интерфейс сервиса вместо того чтобы на прямую реализацию вставить туда где она используется будь то сервисы или контроллеры (т.е. подсознательно понимает что разделение ответственности не такая плохая идея).
Собственно к чему я это все тут написал — писать код в котроллере технически возможно, равно как и писать запросы к базе на прямую, или пинать бомжа напрямую без использования механической ноги. Но правильно ли это? Если этот проект планируется развивать и поддерживать многие годы то думаю писать все в контроллере плохая идею. Времена идут, все меняется, сегодня вы реквесты/респонсы через ASP.NET обрабатываете, завтра вместо контроллеров решите например Azure Functions с их HttpTriggers использовать после завтра например в Лямбды все завернете или еще чего другое придумается (тут уже упоминали Graph QL)… Подлодку делят на отсеки потому что если в одном из них пробоина, можно просто перекрыть перегородки и подлодка не потонет. Так же и тут, слои нужны для того чтобы в случае изменения реализации одного из них все остальные слои не пришлось переделывать, или вообще весь проект переписывать.
P.S. Ничего не имею против бомжей и не призываю их пинать. Считаю что этим людям просто где-то в жизни не повезло и надо помогать вернуться в социум.
Если я правильно понимаю этот принцип аджайл манифеста какраз и говорит нам что никаких митингов не надо делать:
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation
Сходным образом можно доказать, что получение солнечной энергии в космосе уже в этом веке станет дешевле получения энергии на Земле любыми известными способами. Затем эту энергию можно по лучу отправлять на землю в виде микроволн.
Основным импортом из космоса будут безмассовые фотоны, переносящие данные и энергию.
Посвятите дилетанта, с помощью каких технологий планируется фотонами энергию на землю передавать?
Если это мощный лазер — не повредит ли это атмосфере земли (не вызовет ли парниковый эффект например)?
Если такие теологии уже существуют почему бы не поставить солнечные батареи на Луне и не передавать энергию оттуда на землю без всякого гемороя с захватом астероидов?
Взаимно. Расшарю вашу статью коллегам. У нас тут какраз недавно дискуссия по схожей теме шла, а тут будет ещё один аргумент в поддержку моих доводов)))
За время своей работы так же пришел к тому что важно вопросы на собеседовании приблизить к повседневным задачам на проекте, по этому считаю что человека нужно собеседовать на проект а не «проверять универсально».
Обычно я ещё даю кандидату небольшое тестовое задание (от силы на пару часов работы) максимально приближенное к реальному проекту. И прошу его сделать в течение недели. Оставляю ему свою электронную почту куда он может слать вопросы по мере выполнения задания. Этим я убираю стресс, так как человек работает в удобной для него обстановке в удобное для него время. Обычно по вопросам присылаемым мне на почту уже можно многое сказать о кандидате. Потом, если он все таки сделал задание (кстати тут отсеивается сразу процентов 50 кандидатов), мы беседуем с ним по его коду, он рассказывает почему реализовал все так а не иначе, что новое изучил в процессе выполнения задания.
Пока ещё (тут я стучу по дереву) все принятые мной кандидаты оправдали возложенные на них надежды и даже превосходили мои ожидания
Спасибо за статью. Все выше перечисленные ошибки совершал мой лид когда я работал ещё на первом проекте.
Ну, и всегда стоит помнить, что в сорванных сроках виноват не “тот джуниор, что долго копается в коде”, а его тимлид.
Собственно это и стало причиной моего ухода из той компании.
Сейчас, после восьми лет работы, когда я сам уже стал лидом, стараюсь не наступать на эти грабли и это действительно дает свой результат. Я действительно горжусь своей командой.
Единственная ремарка, порой лида тоже ставят в жесткие рамки, и времени долго сидеть с джунами просто нет, менеджеру ведь нужен результат в короткие сроки
Не надо вводить в заблуждение и ссылаться на то что раз SpaceX якобы делает ракеты по наитию то и все так должны делать.
Во первых это не правда. Специально перечитал главу про SpaceX из книги на которую вы ссылаетесь. Нет там ничего о том что сейчас они собирают ракеты без плана и чертежей. Могу предположить что возможно на начальных этапах что-то подобное и было, когда Макс сам за это отвечал но все мы помним как его ракеты взрывались а потом он и сам признал в одном из интервью что если бы на его месте был бы более опытный человек этих взрывов можно было бы избежать но на тот момент такого человека не было.
Во вторых мне кажется что нежелание продумывать детали фичи перед началом работы над ней прикрываясь всякими там Agile характеризует руководителя проекта как человека не способного стратегически мыслить и доносить свои мысли и идеи подчиненным в понятной для них форме. Конечно не все можно продумать заранее но любые ошибки найденные на этапе планирования исправить проще и дешевле чем те же ошибки (я сейчас не имею ввиду баги разработчиков) сделанные на этапе разработки.
В третьих, я сам руковожу проектами и ставлю задачи командам, и предыдущее утверждение основано на моем личном опыте.
Спасибо за статью. Приятно видеть что есть люди понимающие важность документации.
Из личного опыта могу добавить что у себя сделал обновление документации частью процесса разработки. В каждой фиче есть подзадача о том что после завершения разработки нужно добавить или обновить существующую документацию: подправить архитектуру, добавить детали реализации в описание фичи в Wiki и т.д. Эта задача как и любая задача разработки должна пройти ревью (быть просмотрена и понята другим членом команды в идеале не задействованным в работе над этой фичей). При таком подходе у нас документация всегда в актуальном состоянии и при этом время на написание документации запланировано в работу над фичей и обычно не требует больших трудозатрат, да и делается по свежей памяти а не через пол года после релиза.
[Это был сарказм]
Ну а если по делу то цель создание сервисов бизнес логики равно как и репозиториев это разделение ответственности. Вы ведь упоминали в статье про трехслойную архитектуру (кстати слоев вполне может быть больше чем три, взять хотя бы тот же DDD) суть разделение по слоям не в следовании каким-то каргокультам внушенным нам рептилоидами а в разделении ответственности. Контроллеры отвечают за HTTP (ну или другой протокол обмена сообщениями), репозитории за взаимодействие с базой данных… Реализация IEmailService например за отправку почты. Я обычно бизнеслогику засовываю в .Net Standard либы чтоб не было соблазна «платформо-зависимый код» в них писать.
Слышали наверняка что слои верхнего уровня не должны знать о реализации нижнего уровня? Кто знает что там у него под капотом у реализации IEmailService, может быть он запускает механическую ногу, которая пинает спящего возле офиса бомжа, который несет вашему юзеру бумажку с распечатанным сообщением. В любом случае автор ведь использует интерфейс сервиса вместо того чтобы на прямую реализацию вставить туда где она используется будь то сервисы или контроллеры (т.е. подсознательно понимает что разделение ответственности не такая плохая идея).
Собственно к чему я это все тут написал — писать код в котроллере технически возможно, равно как и писать запросы к базе на прямую, или пинать бомжа напрямую без использования механической ноги. Но правильно ли это? Если этот проект планируется развивать и поддерживать многие годы то думаю писать все в контроллере плохая идею. Времена идут, все меняется, сегодня вы реквесты/респонсы через ASP.NET обрабатываете, завтра вместо контроллеров решите например Azure Functions с их HttpTriggers использовать после завтра например в Лямбды все завернете или еще чего другое придумается (тут уже упоминали Graph QL)… Подлодку делят на отсеки потому что если в одном из них пробоина, можно просто перекрыть перегородки и подлодка не потонет. Так же и тут, слои нужны для того чтобы в случае изменения реализации одного из них все остальные слои не пришлось переделывать, или вообще весь проект переписывать.
P.S. Ничего не имею против бомжей и не призываю их пинать. Считаю что этим людям просто где-то в жизни не повезло и надо помогать вернуться в социум.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation
Посвятите дилетанта, с помощью каких технологий планируется фотонами энергию на землю передавать?
Если это мощный лазер — не повредит ли это атмосфере земли (не вызовет ли парниковый эффект например)?
Если такие теологии уже существуют почему бы не поставить солнечные батареи на Луне и не передавать энергию оттуда на землю без всякого гемороя с захватом астероидов?
А можно чуть подробнее раскрыть этот пункт.
В частности что вы понимаете под этой фразой?
За время своей работы так же пришел к тому что важно вопросы на собеседовании приблизить к повседневным задачам на проекте, по этому считаю что человека нужно собеседовать на проект а не «проверять универсально».
Обычно я ещё даю кандидату небольшое тестовое задание (от силы на пару часов работы) максимально приближенное к реальному проекту. И прошу его сделать в течение недели. Оставляю ему свою электронную почту куда он может слать вопросы по мере выполнения задания. Этим я убираю стресс, так как человек работает в удобной для него обстановке в удобное для него время. Обычно по вопросам присылаемым мне на почту уже можно многое сказать о кандидате. Потом, если он все таки сделал задание (кстати тут отсеивается сразу процентов 50 кандидатов), мы беседуем с ним по его коду, он рассказывает почему реализовал все так а не иначе, что новое изучил в процессе выполнения задания.
Пока ещё (тут я стучу по дереву) все принятые мной кандидаты оправдали возложенные на них надежды и даже превосходили мои ожидания
в VS2017 тесты видны и запускаются.
Ну, и всегда стоит помнить, что в сорванных сроках виноват не “тот джуниор, что долго копается в коде”, а его тимлид.
Собственно это и стало причиной моего ухода из той компании.
Сейчас, после восьми лет работы, когда я сам уже стал лидом, стараюсь не наступать на эти грабли и это действительно дает свой результат. Я действительно горжусь своей командой.
Единственная ремарка, порой лида тоже ставят в жесткие рамки, и времени долго сидеть с джунами просто нет, менеджеру ведь нужен результат в короткие сроки