выбрать популярные домены второго уровня из списка Alexa
— как то не очевидно, что от этого есть польза. Думаю большинство пользователей применяет ящики небольшого количества бесплатных почтовых систем (типа mail.ru или gmail.com) и ящики на доменах которых нет в топе Alexa (знаю много случае когда у пользователя есть домен на котором висят ящики, но на этом домене не висит сайта или каких то других сервисов). Я бы использовал другую логику: известные почтовики + корпоративные домены
Я верю, что где-то есть разработчики моей мечты — зрелые, самоорганизующиеся и с продуктовым мышлением.
— тут есть обратная сторона) В одной из контор видел «зрелых» разработчиков, которые ПМа хренами крыли когда им казалось, что он предлагает то что, на их взгляд, заказчику не нужно. И, да, они стремились лично пообщаться с заказчиком)
Это один из рисков быстрой разработки.
На другой чаше весов — мы будем продумывать архитектуру, писать ТЗ, долго и качественно все реализовывать, а потом, например, выйдет закон, который скажет, что так больше делать нельзя (а такое часто бывает с b2b продуктами). И мы получим много потраченных денег и ненужный продукт, но зато с классной архитектурой.
— не надо называть продуктом то что им не является, вы делаете не продукт, а прототип, да и то усеченный (в прототип, архитектура тоже обычно закладывается). Вместо того чтобы расписывать в ТЗ неизвестно что, надо сообщить разработчику граничные условия, что он должен сделать — самокат или автомобиль и, если автомобиль, то грузовой или легковой. Детали про окраску, фары и отделку салона на ранних этапах не нужны. Как раз архитектура, часто описывается даже не в виде кода, а в виде блоксхем и если и требует заметных трудозатрат, то на отработку не проверенных гипотез — типа, а сможем мы лить в базу XX по YYY запросов в сек. Ну и насчет законов влияющих на архитектуру… такая мизулина еще не родилась или вы называете архитектурой не то что я.
эта картинка стоит у нее в качестве заставки на рабочем столе.
Если посмотреть на эту картинку, то видно, что на первом этапе MVP, например, не имеет двигателя. Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали»
— кто то неправильно понимает картинку. Я вижу, что изначально проектируется приложение на которое можно установить двигатель, но пока его нет — толкаем руками, типа приложение принципиально может масштабироваться, но сдаем мы его на одной ноде. Видимо не донесли до разработчика/архитектора граничные условия и он понял что всегда будут руками толкать, либо он все понял, но на вас болт положил и саботирует, ссылаясь на то что изначально про двигатель ничего не говорилось (а сказать надо было).
На всякий случай та же картинка еще раз:
Я не объясняю, какую проблему решает их фича, а просто набрасываю задачи в бэклог, надеясь, что команда сама придет ко мне с вопросами
— постыдились бы такое писать! Ваша задача мотивировать команду, а не демотивировать ее. Уверен, что разработчики видя задачи в бэклоге комментируют это так: «опять какая то мутная и непонятно кому нужная хрень, которую потом придется переделывать».
В общем, хорошего менеджера, умеющего работать не только с заказчиком, но и с исполнителями, также трудно найти как и хорошего разработчика.
Грустная статья. Автор плохо понимает что именно он пишет:
Я понимаю опасения разработчиков, но, общаясь с пользователями, я понимаю, что большинству из них не нужна идеальная архитектура… Они готовы (на первых этапах, конечно) терпеть баги
Нужно эту фичу переделать
— непродуманная архитектура, помноженная на многократные доделки и переделки, рождает блохастое чудовище, которое проще усыпить чем вылечить. Через пару лет существования такого продукта неожиданно окажется, что добавление новой фичи или устранение простой на вид ошибки вызывает у разработчиков непропорционально большие трудозатраты. И не говорите тогда, что вас не предупреждали — все эти стоны разработчиков про необходимость рефакторинга, это вам четкий сигнал, что продукт с гнильцой.
Следствия вашего подхода к разработке:
— низкая мотивация в команде (это уже заметно в статье) и недовольство менеджмента в отношении команды, с последующей текучкой кадров;
— бесконечный поток ошибок в продукте, в стиле эту лапу вытащили, другая увязла. Да еще и ошибки устранять будете медленно. За это получите справедливое недовольство клиента, который наивно предполагал что покупает качественный продукт.
Также хорошо видно, что автор не понимает термин MVP. Минимально работоспособный продукт, это продукт с минимальной функциональностью, а не интерфейс пришитый белыми нитками к коленке. Хорошая картинка про это:
«Повторный код уже написан» — плохо, но еще хуже если его еще раз продублировать (т е написать то же самое в третий, четвертый раз)
«работает — не трогай» — каждая новая фича дается все тяжелей, устранение простых, на первый взгляд, багов требует много времени
Отсутствие тестов или их низкое качество, также можно отнести к техническому долгу. Автотесты (на прктике) не могут выявить все ошибки. Естественно, что найденную ошибку придется устранить, но никто не гарантирует, что устраняя ошибку в одном месте, тем самым не создаешь ее в другом.
Обо всем этом много уже написано: Роберт Мартин «Чистый код», Мартин Фаулер «Рефакторинг» и т д. Думаю, что в этих книгах можно найти гораздо больше аргументов на тему «почему» надо писать чистый код. Хотя, конечно, все зависит от продукта и установок в команде — если команда слышит что продукт никому не нужен, а самих программистов завтра выгонят, ну и конечно незабываемое — «это надо было сделать вчера», то все это не стимулирует разработчиков писать качественный код. Часто менеджер однодневка своим общением с командой закладывает мину в продукт.
— фичу добавили и забыли про нее, больше с ней не работают. Разве что какие то ошибки вылезут. Но добавление каждой новой фичи требует все больше усилий со стороны команды.
— добавил код, который меняет данные, ошибка вылезла совсем в другом месте, где раньше все нормально работало (ужас еще в том, что поскольку это место совсем другое, то проблем там не ждешь и это место не тестируется — тут спасет только полный регресс тест, а это время и деньги).
Тоже поделюсь наблюдением: имеется некий продукт с большим количеством не документированных классов и частой сменой команды разработчиков. Новые разработчики не имея времени и желания исследовать чужой код, при внедрении фич, лепили собственный код, дублирующий уже имеющийся функционал. Потребность в рефакторинге очевидна, но предложенная метрика, основанная на частоте изменений в файлах, ничего подозрительного не покажет.
Можно даже предположить, что там где часто изменяют одни и те же файлы, фактически происходит рефакторинг, а там, где старый код долго остается неизменным, есть какая то проблема)
Я имел в виду, что оценка основанная на "файлах" это частный случай (взгляд программиста), а "продукт" (взгляд менеджера) — это не только код, но и тестирование, и интеграционные решения. Например, изменив тип аргумента в одном из методов web-сервиса я произведу малозаметные, с точки зрения «файла» изменения, с чудовищными последствиями для «продукта» — типа труднообнаружимых ошибок (если мы не побеспокоились заранее об интеграционных тестах) и необходимости доработок в приложениях интегрирующихся с нашим API. Этот пример не удачен с точки зрения темы рефакторинга, но он показывает что объем трудозатрат при внедрении фичи для продукта в целом может слабо коррелироваться с количеством измененных файлов или строк кода. Т е сама методика оценки объема технического долга, основанная на подсчете количества изменений в коде и частоте изменений в файлах может быть верной для некоторых продуктов, а для других продуктов эта методика не даст реальной картины.
Критерий «количество усилий на поддержку файла с кодом» мне кажется частным случаем в оценке технического долга и слабым аргументом для менеджера с которым придется эту проблему обсуждать.
Более существенно количество паразитных трудозатрат (отношение объема нового кода к объему переписанного кода, объем регрессионного тестирования) при добавлении фич. В продукте с большим техническим долгом внедрение фич вызывает непропорционально большие трудозатраты и чем дольше копится этот долг, тем выше сложность/цена внедрения нового функционала.
— как то не очевидно, что от этого есть польза. Думаю большинство пользователей применяет ящики небольшого количества бесплатных почтовых систем (типа mail.ru или gmail.com) и ящики на доменах которых нет в топе Alexa (знаю много случае когда у пользователя есть домен на котором висят ящики, но на этом домене не висит сайта или каких то других сервисов). Я бы использовал другую логику: известные почтовики + корпоративные домены
— тут есть обратная сторона) В одной из контор видел «зрелых» разработчиков, которые ПМа хренами крыли когда им казалось, что он предлагает то что, на их взгляд, заказчику не нужно. И, да, они стремились лично пообщаться с заказчиком)
— не надо называть продуктом то что им не является, вы делаете не продукт, а прототип, да и то усеченный (в прототип, архитектура тоже обычно закладывается). Вместо того чтобы расписывать в ТЗ неизвестно что, надо сообщить разработчику граничные условия, что он должен сделать — самокат или автомобиль и, если автомобиль, то грузовой или легковой. Детали про окраску, фары и отделку салона на ранних этапах не нужны. Как раз архитектура, часто описывается даже не в виде кода, а в виде блоксхем и если и требует заметных трудозатрат, то на отработку не проверенных гипотез — типа, а сможем мы лить в базу XX по YYY запросов в сек. Ну и насчет законов влияющих на архитектуру… такая мизулина еще не родилась или вы называете архитектурой не то что я.
— кто то неправильно понимает картинку. Я вижу, что изначально проектируется приложение на которое можно установить двигатель, но пока его нет — толкаем руками, типа приложение принципиально может масштабироваться, но сдаем мы его на одной ноде. Видимо не донесли до разработчика/архитектора граничные условия и он понял что всегда будут руками толкать, либо он все понял, но на вас болт положил и саботирует, ссылаясь на то что изначально про двигатель ничего не говорилось (а сказать надо было).
На всякий случай та же картинка еще раз:
— постыдились бы такое писать! Ваша задача мотивировать команду, а не демотивировать ее. Уверен, что разработчики видя задачи в бэклоге комментируют это так: «опять какая то мутная и непонятно кому нужная хрень, которую потом придется переделывать».
В общем, хорошего менеджера, умеющего работать не только с заказчиком, но и с исполнителями, также трудно найти как и хорошего разработчика.
— непродуманная архитектура, помноженная на многократные доделки и переделки, рождает блохастое чудовище, которое проще усыпить чем вылечить. Через пару лет существования такого продукта неожиданно окажется, что добавление новой фичи или устранение простой на вид ошибки вызывает у разработчиков непропорционально большие трудозатраты. И не говорите тогда, что вас не предупреждали — все эти стоны разработчиков про необходимость рефакторинга, это вам четкий сигнал, что продукт с гнильцой.
Следствия вашего подхода к разработке:
— низкая мотивация в команде (это уже заметно в статье) и недовольство менеджмента в отношении команды, с последующей текучкой кадров;
— бесконечный поток ошибок в продукте, в стиле эту лапу вытащили, другая увязла. Да еще и ошибки устранять будете медленно. За это получите справедливое недовольство клиента, который наивно предполагал что покупает качественный продукт.
Также хорошо видно, что автор не понимает термин MVP. Минимально работоспособный продукт, это продукт с минимальной функциональностью, а не интерфейс пришитый белыми нитками к коленке. Хорошая картинка про это:
Ну а это вообще супер:
Обо всем этом много уже написано: Роберт Мартин «Чистый код», Мартин Фаулер «Рефакторинг» и т д. Думаю, что в этих книгах можно найти гораздо больше аргументов на тему «почему» надо писать чистый код. Хотя, конечно, все зависит от продукта и установок в команде — если команда слышит что продукт никому не нужен, а самих программистов завтра выгонят, ну и конечно незабываемое — «это надо было сделать вчера», то все это не стимулирует разработчиков писать качественный код. Часто менеджер однодневка своим общением с командой закладывает мину в продукт.
— добавил код, который меняет данные, ошибка вылезла совсем в другом месте, где раньше все нормально работало (ужас еще в том, что поскольку это место совсем другое, то проблем там не ждешь и это место не тестируется — тут спасет только полный регресс тест, а это время и деньги).
Можно даже предположить, что там где часто изменяют одни и те же файлы, фактически происходит рефакторинг, а там, где старый код долго остается неизменным, есть какая то проблема)
Более существенно количество паразитных трудозатрат (отношение объема нового кода к объему переписанного кода, объем регрессионного тестирования) при добавлении фич. В продукте с большим техническим долгом внедрение фич вызывает непропорционально большие трудозатраты и чем дольше копится этот долг, тем выше сложность/цена внедрения нового функционала.