Тогда можно пойти чуть дальше и сказать, что может быть вообще все тесты не нужны. Зачем - ведь разработчик так и так что-то забудет, не в коде так в тесте.
Тесты конечно же нужны. Они, хоть и не избавляют от ошибок принципиально, зато повышают качество относительно.
Опять же, тесты хороши тем, что через них можно сделать регресс. Вот например, захотите вы обновить версию мапструкта с 3 на 4, как будете убеждаться что в вашем большом проекте всё ок после апдейта, если нет на это тестов?
А от забывчивости разработчика увы средств особо нет, кроме как проверять всю сделанную им работу на код ревью и на приемочных тестах. И то не 100% гарантия. И mapstruct это никак не меняет в целом.
С mapstruct то же самое - если не протестил маппинг, то не факт что оно работает.
Может быть новое поле он и прокинет сам, а может и неправильно прокинет.
Самое противное с ним - код компилируется и запускается, но это не значит что всё хорошо. Он или в рантайме где-то потом упадёт, или неправильно значения передаст, например поле-список всегда будет пустым.
Один из больших минусов - код у него внутри на java. И когда используешь его с DTO на kotlin, он генерит код с супер-странной nullability, и в рантайме частенько можно ловить NPE, когда он пытается в not-null поле этот самый null положить.
Бывает, что работаешь и смотришь не только в свою команду, но и в 5-10 соседних, и тоже получаешь с этого опыт - кто кого нанял и как, какие решения принимались и как, какой был менеджмент, как была организована работа и так далее. Тем более если быть кем-то типа деливери менеджера, там точно придётся погружаться в разные команды и помогать чинить процессы.
Конечно, будучи в роли мидла-разработчика так широко редко получается видеть, но у людей же разные роли. Допустим можно быть в архитектурном комитете, это тоже даёт много опыта от других команд: сначала видишь проблему и их идею, потом узнаешь как прошла реализация и что получилось, какие всплыли косяки.
О сотнях автор может быть преувеличивает (а может быть и нет), но кажется мысль статьи не в этом, и можно просто принять оценочное суждение автора.
То есть и ваши варианты вывозить "не под силу каждому" получается? А то показалось, что раз 300к для вас - это худо-бедно интересные деньги, и вы досадуете, что вывозить такое не под силу каждому, то у вас есть более выигрышные по этому соотношению варианты - где 300к вывозить могут почти все например.
"Как хочу, так и комментирую. Автор мне должен, а я ему нет". Вашу позицию так понял с ваших слов. Что ж, я получается тоже могу в своём комменте написать "любую дичь", но не стану, потому что не хочу.
Отягчающим обстоятельством является тот факт, что ТС - фрилансер, на значит любой текст на популярном ресурсе - это бесплатная его реклама.
Понятно, что любая статья - это пиар.
Ок, ничего не понял в вашей оценке рекламности, но не уверен, что хочу нырять в кроличью нору :)
Конкретно эта статья, хоть и не является примером и эталоном, была всё-таки мне интересна. А вы говорите, что её тут быть не должно.
Простите, но я не хочу, чтобы из-за того, что статья кому-то не понравилась, её нельзя было прочитать вообще никому. Я не хочу, чтобы вы решали за меня, что мне читать, а что нет.
Тем более не вижу смысла обсуждать в комментариях к этой статье всю личность автора целиком и на этом основании хейтить все его материалы. Хотя людям такое и свойственно, по-моему это не всегда полезно. Тем более, что автор не ссылался на другие свои статьи в этой.
Зато ваш коммент явно негативно эмоционально окрашен, пассивно-агрессивный и деструктивный. Вы не оперируете фактами, чтобы дать понимание вашей точки зрения, а просто бомбите. Отсюда и моё негодование. Если вам кажется, что статья не соответствует уровню хабра, то мне кажется, что ему не соответствует ваш комментарий. Вместо того, чтобы попытаться что-то улучшить или прояснить, вы просто бомбанули хейта в коммент, и теперь кажется искренне удивляетесь, "а нас то за что? Это автор плохой, а я хороший". Вас я не знаю, но мне кажется, если вас и правда волнует стандарт и уровень хабра, то попробуйте и свои комментарии приводить в соответствие к нему.
Что за повальная привычка демотивировать авторов в комментариях? В какую статью ни зайдешь, везде одно и то же - "зачем тут эта статья", "автор лучше бы Х сделал, чем это писать"...
Так и перестают люди писать.
"И слава богу", скажете вы, "меньше дурацких статей". А кто судья? Если вам что-то не было полезным, не значит, что это надо выкинуть на помойку. Мне вот наоборот интересно смотреть на перспективу, с которой смотрят на мир другие люди, и тем более иметь возможность диалога в комментариях.
Достаточно одного такого комментария, как ваш, чтобы искренний человек перестал писать, а другой человек не смог с ним пообщаться. Что в этом хорошего?
Простите, к сожалению у нас нет для вас "правильных" авторов, есть только обычные люди, которые хотят поделиться с сообществом, все с разным опытом, взглядами, умением писать. И если не выгонять их пинками, а помочь, то может быть они станут "правильными" когда-то. Или вы станете.
Если у вас на примете есть более легкий способ поднимать 300к, поделитесь плз, а то какая-то недосказанность. Вы так говорите "худо-бедно интересные деньги", как будто это не топ 1% зарплат по РФ, и как будто есть много более простых способов получать если не 300, то хотя бы 250, с удаленкой, ДМС и плюшками.
Если у вас душа не лежит, то тут нужно не кровати двигать, а весь персонал менять. Многие люди вообще не ощущают связи с тем, что делают, и при этом думают, что это ненормально, что им не хочется делать этого. Странная ситуация.
Что-то вы гребёте под одну гребёнку - в тимлиды записали и CTO, и руководителя отдела и архитектора...
То, что вы называете тимлидом, обычно называют "технический менеджер". И никто не тимлид, кроме тимлида - менеджера 1 уровня, который руководит исполнителями.
Архитектор и вовсе не тимлид, если он конечно не взял на себя и такую роль - руководить командой.
Вы отделили роль техлида, и это действительно отдельная роль, которую тимлид может как брать на себя, так и делегировать. При этом вы не выделили 2 другие роли тимлида - управление командой и управление проектами. Они тоже могут быть делегированы, например проджект менеджеру и эйчару.
У того же CTO уже чуть другой круг обязанностей, и говорить, что "все они тимлиды и все делают в общем-то одно и то же" - это по-моему сильное упрощение, ведь при переходе от тимлида к CTO нужно получить пожалуй даже больше компетенций, чем при переходе из разработки в лиды.
откуда у вас в голове сидит "ватерфолл - это годы"? Кто это вбил в голову?
Никто не вбивал, не беспокойтесь. В такой срок я оцениваю разработку средних размеров проекта, включая написание ТЗ и приёмку. Это пример. Не спорю, что можно и за 2 месяца что-то небольшое сделать и запустить в эксплуатацию. Но чем больше, тем дольше.
Ваш онлайн-сервис - это как раз-таки простой проект. Как это можно не понимать?
Просто с какой точки зрения? С точки зрения наукоемкости может быть ничего замысловатого нет в том, чтобы одни люди продавали, а другие люди покупали вещи.
Если же говорить про количество и сложность процессов, количество и требования к данным, к надежности систем и т. д., то мне кажется вполне сравнимо.
Опять же, чтоб построить производственный цех, нужно стоять на плечах гигантов - иметь разработанные и апробированные технологии, кучу документации по ним, поготовленных специалистов и т. д. Построить цех с нуля невозможно. Так вот, часть современного бизнеса примерно этим и занимается - заходит в неизвестные ниши, находит новые способы решить бытовые потребности людей. Там нет методички, как построить цех. Там есть только идеи.
Даже ракеты строить учились десятилетиями методом проб и ошибок, и в науке почти всё так работает. Невозможно дать ТЗ на то, чего нет и неизвестно как это сделать.
Если вы откроете манифест аджайла, то обнаружите, что это и есть тот самый метод проб и ошибок, только применительно к разработке. Не понимаю, как можно говорить, что такой метод годится только для простых проектов, наоборот, это очень близко к RnD.
Наоборот же. Предположим, вы бизнес - запускаете какой-то онлайн-сервис. У вас есть гипотезы, каким-то образом конечно же протестированные, но полностью провалидировать эти гипотезы можно только реальным продуктом, которым будут пользоваться.
И вы несёте ТЗ в контору по разработке ПО, и через 2 года вам выдают красивый онлайн-сервис.
И одновременно с вами ваш конкурент тоже решает запустить такой же сервис, только разработку ведёт по agile. Через полгода у него появляется MVP, а через 2 года половина ваших потенциальных пользователей - уже пользователи сервиса-конкурента.
Да, их сервис вышел сначала без каких-то важных фич, но это было уже лучше, чем ничего. Лучше и для пользователя, и для бизнеса.
И за эти 2 года ваш конкурент провёл кучу А-Б тестов, пообщался с пользователями, и сделал пару-тройку фич, которые были востребованы, но изначально не было известно, что они должны работать именно так.
Итого - через 2 года бизнес конкурента имеет хороший денежный поток, базу пользователей, бэклог по улучшению, и уже улучшился под потребности пользователей.
Вы через 2 года имеете сдвиг запуска ещё на 3 месяца, но это уже не так важно. Почему? Потому что вам теперь снова требуется разработка - пользоваться вашим сервисом особо не хотят, ведь в нём не хватает части удобных фич, которые есть у конкурента. Поэтому вы пишете ещё одно ТЗ и снова несёте в контору, ждёте ещё 9 месяцев... Если ещё не закроете бизнес к тому времени, потому что прибыли у вас как было 0, так и осталось.
И тем более, ваш конкурент обладает ещё более важным преимуществом - он может зафэйлиться быстрее (пресловутый fail fast). Через год он уже сможет понять, есть ли деньги в этой нише, и если проект не летит, то закрыть его. По сравнению с вами он сэкономит 50% стоимости и времени. И через 2 года уже выпустит другой сервис. А вы всё ещё будете в неведении, отобьются ли ваши вложения в разработку.
И это ещё я не беру во внимание целый ряд рисков: контора-исполнитель может вообще закрыться, или плохо написать ваш проект, или затягивать сроки. Прозрачности в waterfall гораздо меньше, потому что часто проект даже не запускается до момента 90%-готовности. Да, можно будет подать на них в суд в каких-то случаях, но нам-то нужен не суд, а сервис.
И тем более, после написания сервиса его всё равно придётся менять, развивать, дописывать. Не могу себе представить ПО, которое выпустили и не дорабатывают годами, по крайней мере в вебе. Получается, если начать менять код, то ВСЁ РАВНО ПРИДЁТСЯ МЕНЯТЬ КОД. И от истории с agile-подходом это на самом деле не будет сильно отличаться. Вот только в agile-команде к этому уже все готовы, а в waterfall-команде ещё не факт что кодовая база готова к большим доработкам.
Мне кажется, вы мало понимаете, какие у предпринимателей потребности и какие риски, и почему огромную ценность имеет быстрый фидбэк от пользователей.
Даже в вашем примере со скамейками существует так называемый тактический урбанизм - сразу обычно непонятно, как именно нужно организовать общественное пространство, чтобы людям нравилось, где именно и какие именно поставить лавочки. Поэтому за 2 недели делают самые убогие лавки за 100р/штука, ставят и смотрят, как ими пользуются, опрашивают людей. И только потом, имея фидбэк пользователей, проектируют более основательное решение.
Спасибо за статью, автор. Похоже её не так просто понять основной массе аудитории, средний разработчик или QA часто довольно смутно понимает, чем отличается проджект менеджер, продакт менеджер, бизнес-аналитик, системный аналитик, скрам-мастер, и причём здесь тимлид :)
Так что имхо мало кто сможет прямо нормально погрузиться в материал.
А по сути статьи - совместить БА и СА - это уже не очень просто, и эффективно так делать получится скорее на небольших проектах. Вы к этому добавили ещё сверху тимлида и проджекта, что вообще похоже на чудеса эквилибристики. Из моего опыта так можно жить только если команда состоит из 2 человек, а аналитика требуется по минимуму, и при этом заказчики и стейкхолдеры проекта - очень лояльные люди, и у них с вами и между собой отличная коммуникация. Во всех остальных случаях это путь в трэш и безумие :)
Тогда можно пойти чуть дальше и сказать, что может быть вообще все тесты не нужны. Зачем - ведь разработчик так и так что-то забудет, не в коде так в тесте.
Тесты конечно же нужны. Они, хоть и не избавляют от ошибок принципиально, зато повышают качество относительно.
Опять же, тесты хороши тем, что через них можно сделать регресс. Вот например, захотите вы обновить версию мапструкта с 3 на 4, как будете убеждаться что в вашем большом проекте всё ок после апдейта, если нет на это тестов?
А от забывчивости разработчика увы средств особо нет, кроме как проверять всю сделанную им работу на код ревью и на приемочных тестах. И то не 100% гарантия. И mapstruct это никак не меняет в целом.
С mapstruct то же самое - если не протестил маппинг, то не факт что оно работает.
Может быть новое поле он и прокинет сам, а может и неправильно прокинет.
Самое противное с ним - код компилируется и запускается, но это не значит что всё хорошо. Он или в рантайме где-то потом упадёт, или неправильно значения передаст, например поле-список всегда будет пустым.
Один из больших минусов - код у него внутри на java. И когда используешь его с DTO на kotlin, он генерит код с супер-странной nullability, и в рантайме частенько можно ловить NPE, когда он пытается в not-null поле этот самый null положить.
Поэтому нужны тесты и Kotlin, чтобы проверять поля и не проверять null-ы.
Чего и добиваются эти "комментаторы".
Бывает, что работаешь и смотришь не только в свою команду, но и в 5-10 соседних, и тоже получаешь с этого опыт - кто кого нанял и как, какие решения принимались и как, какой был менеджмент, как была организована работа и так далее. Тем более если быть кем-то типа деливери менеджера, там точно придётся погружаться в разные команды и помогать чинить процессы.
Конечно, будучи в роли мидла-разработчика так широко редко получается видеть, но у людей же разные роли. Допустим можно быть в архитектурном комитете, это тоже даёт много опыта от других команд: сначала видишь проблему и их идею, потом узнаешь как прошла реализация и что получилось, какие всплыли косяки.
О сотнях автор может быть преувеличивает (а может быть и нет), но кажется мысль статьи не в этом, и можно просто принять оценочное суждение автора.
То есть и ваши варианты вывозить "не под силу каждому" получается? А то показалось, что раз 300к для вас - это худо-бедно интересные деньги, и вы досадуете, что вывозить такое не под силу каждому, то у вас есть более выигрышные по этому соотношению варианты - где 300к вывозить могут почти все например.
"Как хочу, так и комментирую. Автор мне должен, а я ему нет". Вашу позицию так понял с ваших слов. Что ж, я получается тоже могу в своём комменте написать "любую дичь", но не стану, потому что не хочу.
Ок, ничего не понял в вашей оценке рекламности, но не уверен, что хочу нырять в кроличью нору :)
Тейк с рекламой вообще не понял. Даже если человек не фрилансер, любая статья всё равно его пиарит. Например как мои статьи.
Так давайте тогда всем запретим писать на хабр, чего уж там.
Конкретно эта статья, хоть и не является примером и эталоном, была всё-таки мне интересна. А вы говорите, что её тут быть не должно.
Простите, но я не хочу, чтобы из-за того, что статья кому-то не понравилась, её нельзя было прочитать вообще никому. Я не хочу, чтобы вы решали за меня, что мне читать, а что нет.
Тем более не вижу смысла обсуждать в комментариях к этой статье всю личность автора целиком и на этом основании хейтить все его материалы. Хотя людям такое и свойственно, по-моему это не всегда полезно. Тем более, что автор не ссылался на другие свои статьи в этой.
Зато ваш коммент явно негативно эмоционально окрашен, пассивно-агрессивный и деструктивный. Вы не оперируете фактами, чтобы дать понимание вашей точки зрения, а просто бомбите. Отсюда и моё негодование. Если вам кажется, что статья не соответствует уровню хабра, то мне кажется, что ему не соответствует ваш комментарий. Вместо того, чтобы попытаться что-то улучшить или прояснить, вы просто бомбанули хейта в коммент, и теперь кажется искренне удивляетесь, "а нас то за что? Это автор плохой, а я хороший". Вас я не знаю, но мне кажется, если вас и правда волнует стандарт и уровень хабра, то попробуйте и свои комментарии приводить в соответствие к нему.
Что за повальная привычка демотивировать авторов в комментариях? В какую статью ни зайдешь, везде одно и то же - "зачем тут эта статья", "автор лучше бы Х сделал, чем это писать"...
Так и перестают люди писать.
"И слава богу", скажете вы, "меньше дурацких статей". А кто судья? Если вам что-то не было полезным, не значит, что это надо выкинуть на помойку. Мне вот наоборот интересно смотреть на перспективу, с которой смотрят на мир другие люди, и тем более иметь возможность диалога в комментариях.
Достаточно одного такого комментария, как ваш, чтобы искренний человек перестал писать, а другой человек не смог с ним пообщаться. Что в этом хорошего?
Простите, к сожалению у нас нет для вас "правильных" авторов, есть только обычные люди, которые хотят поделиться с сообществом, все с разным опытом, взглядами, умением писать. И если не выгонять их пинками, а помочь, то может быть они станут "правильными" когда-то. Или вы станете.
Если у вас на примете есть более легкий способ поднимать 300к, поделитесь плз, а то какая-то недосказанность. Вы так говорите "худо-бедно интересные деньги", как будто это не топ 1% зарплат по РФ, и как будто есть много более простых способов получать если не 300, то хотя бы 250, с удаленкой, ДМС и плюшками.
Если у вас душа не лежит, то тут нужно не кровати двигать, а весь персонал менять. Многие люди вообще не ощущают связи с тем, что делают, и при этом думают, что это ненормально, что им не хочется делать этого. Странная ситуация.
Вы начинаете что-то подозревать :)
Что-то вы гребёте под одну гребёнку - в тимлиды записали и CTO, и руководителя отдела и архитектора...
То, что вы называете тимлидом, обычно называют "технический менеджер". И никто не тимлид, кроме тимлида - менеджера 1 уровня, который руководит исполнителями.
Архитектор и вовсе не тимлид, если он конечно не взял на себя и такую роль - руководить командой.
Вы отделили роль техлида, и это действительно отдельная роль, которую тимлид может как брать на себя, так и делегировать. При этом вы не выделили 2 другие роли тимлида - управление командой и управление проектами. Они тоже могут быть делегированы, например проджект менеджеру и эйчару.
У того же CTO уже чуть другой круг обязанностей, и говорить, что "все они тимлиды и все делают в общем-то одно и то же" - это по-моему сильное упрощение, ведь при переходе от тимлида к CTO нужно получить пожалуй даже больше компетенций, чем при переходе из разработки в лиды.
Опять же не понимаю ваше деление на простое и сложное - получается СДЭК и почта сложные, авито - простой?
Никто не вбивал, не беспокойтесь. В такой срок я оцениваю разработку средних размеров проекта, включая написание ТЗ и приёмку. Это пример. Не спорю, что можно и за 2 месяца что-то небольшое сделать и запустить в эксплуатацию. Но чем больше, тем дольше.
Просто с какой точки зрения? С точки зрения наукоемкости может быть ничего замысловатого нет в том, чтобы одни люди продавали, а другие люди покупали вещи.
Если же говорить про количество и сложность процессов, количество и требования к данным, к надежности систем и т. д., то мне кажется вполне сравнимо.
Опять же, чтоб построить производственный цех, нужно стоять на плечах гигантов - иметь разработанные и апробированные технологии, кучу документации по ним, поготовленных специалистов и т. д. Построить цех с нуля невозможно. Так вот, часть современного бизнеса примерно этим и занимается - заходит в неизвестные ниши, находит новые способы решить бытовые потребности людей. Там нет методички, как построить цех. Там есть только идеи.
Даже ракеты строить учились десятилетиями методом проб и ошибок, и в науке почти всё так работает. Невозможно дать ТЗ на то, чего нет и неизвестно как это сделать.
Если вы откроете манифест аджайла, то обнаружите, что это и есть тот самый метод проб и ошибок, только применительно к разработке. Не понимаю, как можно говорить, что такой метод годится только для простых проектов, наоборот, это очень близко к RnD.
Наоборот же. Предположим, вы бизнес - запускаете какой-то онлайн-сервис. У вас есть гипотезы, каким-то образом конечно же протестированные, но полностью провалидировать эти гипотезы можно только реальным продуктом, которым будут пользоваться.
И вы несёте ТЗ в контору по разработке ПО, и через 2 года вам выдают красивый онлайн-сервис.
И одновременно с вами ваш конкурент тоже решает запустить такой же сервис, только разработку ведёт по agile. Через полгода у него появляется MVP, а через 2 года половина ваших потенциальных пользователей - уже пользователи сервиса-конкурента.
Да, их сервис вышел сначала без каких-то важных фич, но это было уже лучше, чем ничего. Лучше и для пользователя, и для бизнеса.
И за эти 2 года ваш конкурент провёл кучу А-Б тестов, пообщался с пользователями, и сделал пару-тройку фич, которые были востребованы, но изначально не было известно, что они должны работать именно так.
Итого - через 2 года бизнес конкурента имеет хороший денежный поток, базу пользователей, бэклог по улучшению, и уже улучшился под потребности пользователей.
Вы через 2 года имеете сдвиг запуска ещё на 3 месяца, но это уже не так важно. Почему? Потому что вам теперь снова требуется разработка - пользоваться вашим сервисом особо не хотят, ведь в нём не хватает части удобных фич, которые есть у конкурента. Поэтому вы пишете ещё одно ТЗ и снова несёте в контору, ждёте ещё 9 месяцев... Если ещё не закроете бизнес к тому времени, потому что прибыли у вас как было 0, так и осталось.
И тем более, ваш конкурент обладает ещё более важным преимуществом - он может зафэйлиться быстрее (пресловутый fail fast). Через год он уже сможет понять, есть ли деньги в этой нише, и если проект не летит, то закрыть его. По сравнению с вами он сэкономит 50% стоимости и времени. И через 2 года уже выпустит другой сервис. А вы всё ещё будете в неведении, отобьются ли ваши вложения в разработку.
И это ещё я не беру во внимание целый ряд рисков: контора-исполнитель может вообще закрыться, или плохо написать ваш проект, или затягивать сроки. Прозрачности в waterfall гораздо меньше, потому что часто проект даже не запускается до момента 90%-готовности. Да, можно будет подать на них в суд в каких-то случаях, но нам-то нужен не суд, а сервис.
И тем более, после написания сервиса его всё равно придётся менять, развивать, дописывать. Не могу себе представить ПО, которое выпустили и не дорабатывают годами, по крайней мере в вебе. Получается, если начать менять код, то ВСЁ РАВНО ПРИДЁТСЯ МЕНЯТЬ КОД. И от истории с agile-подходом это на самом деле не будет сильно отличаться. Вот только в agile-команде к этому уже все готовы, а в waterfall-команде ещё не факт что кодовая база готова к большим доработкам.
Мне кажется, вы мало понимаете, какие у предпринимателей потребности и какие риски, и почему огромную ценность имеет быстрый фидбэк от пользователей.
Даже в вашем примере со скамейками существует так называемый тактический урбанизм - сразу обычно непонятно, как именно нужно организовать общественное пространство, чтобы людям нравилось, где именно и какие именно поставить лавочки. Поэтому за 2 недели делают самые убогие лавки за 100р/штука, ставят и смотрят, как ими пользуются, опрашивают людей. И только потом, имея фидбэк пользователей, проектируют более основательное решение.
Спасибо за статью, автор. Похоже её не так просто понять основной массе аудитории, средний разработчик или QA часто довольно смутно понимает, чем отличается проджект менеджер, продакт менеджер, бизнес-аналитик, системный аналитик, скрам-мастер, и причём здесь тимлид :)
Так что имхо мало кто сможет прямо нормально погрузиться в материал.
А по сути статьи - совместить БА и СА - это уже не очень просто, и эффективно так делать получится скорее на небольших проектах. Вы к этому добавили ещё сверху тимлида и проджекта, что вообще похоже на чудеса эквилибристики. Из моего опыта так можно жить только если команда состоит из 2 человек, а аналитика требуется по минимуму, и при этом заказчики и стейкхолдеры проекта - очень лояльные люди, и у них с вами и между собой отличная коммуникация. Во всех остальных случаях это путь в трэш и безумие :)
Роль системного аналитика не подразумевает анализ рынка, а роль бизнес-аналитика вполне себе. Автор пишет, что совмещал обе.