2631
Канал об IT в целом и о программировании в частности. На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
Разнообразные формулировки говнокода сходятся в одном субъективном критерии — это когда плохо. Ну, то есть, трудно понять, трудно сопровождать, плохо написано, легко нечаянно сломать, некрасиво. Самое красивое определение этого термина — код без структуры или с большим количеством исключений из набора правил, принятым текущей структурой. Но с ним и вопроса особого нет, вопрос с костылём поинтереснее.
Костыль — частично пересекающееся с этим понятие, как на диаграммах венна, не весь говнокод — костыль и не любой костыль — говнокод, хотя последнее встречается пореже. Костыль — это когда что-то используется не по прямому назначению, а случайно, сайдэффектом. То есть, когда ты читаешь код, некоторое время его перевариваешь, понимаешь, почему это работает и восхищённый чужой изворотливостью крутишь головой. Или когда ты пишешь код, в определённый момент весело говоришь «о, так оно сейчас вот так заработает!» добиваешь парой слов, запускаешь и правда работает, а ты хитро хихикаешь.
Известный любому программисту термин "багофича" — это тоже о костыле. Только не сама багофича, а вот когда есть баг, а ты его в коде используешь как фичу. Частный случай костыля.
#айтермин
Короткие новости по рубрике #айтермин
Во-первых, спасибо вам, друзья, за такую большую активность. Предложений по формулировке «костыля» и «говнокода» пришло множество. Постараемся рассказать о всех и ничего не упустить. Некоторые, даже планируем опубликовать целиком, как есть. Следите за активностью по тегу.
Еще хотелось отметить, что подавляющее большинство ответов оперировало такими понятиями, как «хорошо», «понятно», «быстро», «тяжело» и «удобно». Это безусловно хороший вариант определения, при условии, что нужно договориться заранее что же такое «хорошо» и «удобно». Думается мне, что договориться о точном определении таких терминов будет ой как не просто.
Некоторые ответы описывали костыль, как облегченную версию говнокода. Ну, которая, в отличие от говнокода, «изолированна», «не мешает архитектуре» и «всего лишь попахивает, а не воняет». Как по мне, если смешать килограмм говна и килограмм бананов, то мы получим два килограмма говна, а не смузи из съедобного и плохо пахнущего.
Если вам есть что сказать по этой теме, пишите личным сообщением мне (@aratak) с пометкой тегом.
Продолжение следует!
Интересное дело, все вот знают о существовании определений «говнокод» и «костыль». Эти два термина существуют отдельно друг от друга, что не удивительно, ведь означают они разные вещи. Хотя же можно подумать, что говнокод — это набор костылей с примесью ещё чего-то. Но костыль в коде далеко не всегда является говнокодом. И наоборот, далеко не каждый говнокод можно смело классифицировать, как костыль. Очень похоже на то, что нужно срочно устроить ликбез. Я предлагаю основательно разобраться в этом вопросе.
Уверен, что подавляющее большинство подписчиков канала мастерски умеют определять говнокод, особенно чужой, ведь это самый первый навык, которым овладевает разработчик в нашей профессии. Что для вас говнокод? Что такое костыль по вашему мнению? Присылайте личным сообщением мне (@aratak) с пометкой #айтермин ваше определение этих замечательных определений.
Свою версию вместе с вашими присланными можно будет почитать по тегу ближайшие недели.
Сегодня мы обсудим классическую задачу на понимание ложных убеждений (false belief task).
Ребёнку показывают двух кукол, Салли и Энн; у Салли есть корзинка, а у Энн — коробка. Ребёнок видит, как Салли кладёт свой шарик в корзинку и уходит. Пока Салли нет, озорница Энн перекладывает шарик из корзинки в свою коробку и тоже уходит. Теперь Салли возвращается. Ребёнка спрашивают: «Где Салли будет искать свой шарик»?
Совершенно очевидно, что Салли будет искать шарик в корзине, потому как наблюдателю известно, что Салли не ведает о том, что Энн перепрятала шар. И очевидно это тем, кто наблюдает за наблюдателем и видит, что он видит и какой вопрос ему задают.
Чтобы усложнить пример, можно наблюдателя интегрировать в систему и заставить взаимодействовать с Энн и Салли. Например, выдать несколько коробок и разрешить менять положение шара после Энн так, чтобы и Энн и Салли точно знали где находится шар. Или заменим существительные в этом эксперименте на что-нибудь айтишное.
Например, тестировщица Шьямала нашла в системе баг и хочет рассказать программисту Раджешу и менеджеру Кумару о нем. Молодая и неопытная Шьямала вполне в состоянии сказать «ребята, у вас сайт не работает», более опытная скажет «У вас в профиле пользователя баг» и только матёрая кюэйщица напишет по шагам как воспроизвести этот баг.
Многие могут подумать, что это достаточно очевидно и любая шьямала уже давно не делает глупостей таких вот глупостей. Но достаточно вспомнить случаи, когда хотелось взять в руки сарумановский шар, чтобы понять что же коллега пытается донести, как все становится на свои места. Эксперимент Салли и Энн, к слову, в большинстве своем дети до четырех лет пройти не могут. Пятилетки практически все отвечают правильно.
Друзья, мы совершенно пропустили тот момент, когда нас стало три тысячи. Мне очень приятно, что у нас собралась такое хорошее и активное комьюнити разработчиков. Вы самые лучшие 🎉.
Я знаю, что кнопочки с лайкодизлайками ставят далеко не все, из тех, что читает канал, а не просто на него подписан. У каждого своя причина, но сегодня я хотел бы вас попросить, в порядке исключения все-таки нажать на воздушный шарик (🎈), если вы читаете это сообщение. Нажмите на робота (🤖), если вы не читаете канал, а просто на него подписаны, а на пришельца (👽) не нажимайте вообще, пожалуйста.
Спасибо!
В телеграме работа с публичными каналами кардинально отличается от привычных площадок. В ютубе, например, все блоггеры, как один, начали просить нажимать на колокольчик, чтобы мгновенно узнавать о новой публикации, новостные ресурсы начали добавлять бесячую браузерную нотификацию о новых постах. А в телеграме же с точностью до наоборот. Пользователей просят нажимать «mute», чтобы новые посты не раздражали. Даже тем, кто не убрал звук оповещений, сообщение не приходит благодаря особому тихому режиму отправки сообщений. Попробуйте отжать «mute» на недельку на канале и убедитесь сами — появится значок непрочитанного сообщения, но форсированное уведомление приходить не будет. За другие каналы ручаться не могу :-)
Ещё в телеграме напрочь отсутствуют встроенные механизмы продвижения и популяризации каналов. Тут нет вкладки «тренды», нет «мои друзья читают», нет «рекомендаций». С точки зрения пользователя это безусловный плюс. И именно поэтому масса каналов изобилует рекламой других каналов и подборками каналов. Просто это чуть ли не единственный способ рассказать о канале новым читателям. Наверняка многие из вас узнали об «Экстраполяции» через рекламу на других каналах.
Хочу попросить вас, мои любимые, рассказать о моем канале вашим друзьям. В телеграме ли, на фейсбуке ли. Может даже при личном контакте. Особенно приятно мне будет, если вы вместе со ссылкой на «Экстраполяцию» опубликуете понравившийся пост у себя на страничке. Увеличим количество
Я уверен, мы можем стать одним из лучших айтишных сообществ рунета. Попробуем?
Лайвхаки от Экстраполяции
В Макоси есть замечательная малоиспользуемая возможность добавлять правила автозамены при наборе текста. Конечно, простейшие опечатки и грамматические ошибки система исправляет автоматом, но вот слэнг и дурные привычки системе исправить очень тяжело и в общем случае невозможно. Вроде «ггг», «чо», «хз» или «ща». И эта фича операционной системы может помочь.
Пишите грамотно и пусть ваши собеседники не знают о ваших лингвистических пристрастиях!
P.S. Скриншот мой, правил много.
Ну, и чтобы два раза не вставать, хочу рассказать еще об одном канале, который я читаю с удовольствием. Возможно, вы его знаете по не очень смешному «смешному твитеру». Это Владислав Козуля и его телеграм-канал @PROprgmr. В канале появляются только авторские заметки о нелегкой судьбе фронтендера, за что и ценится.
К слову, недавно Владислав рекомендовал своим читателям «Экстраполяцию» совершенно безвозмездно и на добровольных началах. Можно с уверенностью сказать, что содержимое канала — это действительно его мнение, а не купленный «нейтив».
Читайте только самое лучшее, друзья!
Ребята, доброе утро!
В армии существует замечательный, на мой взгляд, критерий, по которому не сложно отличить хорошего бойца от плохого. Речь о выражении «я бы с ним в разведку не пошел». И ведь действительно, когда спрашивают о состоятельности боевого товарища, то критериев может быть масса, и у каждого эти критерии разнятся в зависимости от полученного опыта и достоинств. Одному важно метко ли стреляет его напарник и быстро ли он бегает. Другому важно, чтобы напарник молчал и вкусно готовил, а третьему необходимо в напарники того, кто не боится змей и умеет управлять боевым вертолетом. Пытаться составить мало-мальски универсальный список качеств и свойств бойцов, мы очень скоро скатимся в перечисление характеристик какой-нибудь RPG вроде «Фалаута» или «Скайрима». И отличить хорошего бойца от плохого будет крайне сложно.
А вот такая субъективная оценка товарища по оружию очень легко даст понять хороший ли боец вот этот вот джаваскрипт-разработчик или не очень хороший. Согласен ли ты работать в проекте, где он будет тимлидом? Можно ли ему доверить задачу, которую потом спросят с тебя?
Если оба ответа — «нет», то такого бойца нужно срочно переводить в стройбат и не подпускать с продакшену.
Наверное, вы заметили, что за все существование канала на нем ни разу не было ни одного поста о блокчейне и биткойне. Не хочу нарушать эту традицию. Очень надеюсь, что те читатели, которые приобрели во владение криптовалюту не проверяют ее стоимость каждые пять минут, а понимают, что такое приобретение можно рассматривать исключительно как долгосрочную инвестицию, и никакие колебания курса в пределах дня, недели или даже месяца вообще не важны. Перестаньте это делать, купили и купили — молодцы. Примечание: к вам это не относится, если вы торгуете и зарабатываете на криптобиржах. Тогда проверяйте сколько душе угодно, это ваша работа.
Я мог бы написать о своем крайне негативном отношении первичного размещения монет («ПРМ» получается), но делать этого на этом канале не буду. Уверен, большинство читателей и так весьма осторожно относяться к ICO и подобным ни к чему не обязывающим инвестициям, как и я. Разве что найдутся такие, которые путем размещения монет пытаются привлечь инвестиции к своим собственным проектам. В таком случае, ай да хитрецы! Но не пытайтесь нас, обычных пользователей, обмануть! Мы-то знаем, что большинство ICO-проектов по своей сути являются аферой, лучше уж купить пачку биткоинов, чем таким вот методом приумножать свой капитал с помощью сомнительных инвестиций.
Канал «Экстраполяция IT» — отдушина от мира криптовалютных криптовалют. Именно поэтому тему блокчена и биткоинов оставляю остальным каналам.
Давайте с вами вместе подумаем над более правильным решением вчерашней проблемы (см. два поста выше) в рамках большинства существующих компаний и организаций. Решение должно быть вполне выполнимо, не требовало бы расстрелять всю старую команду и набрать молодую кровь или сделать так, чтобы менеджерам вместо плёток выдавали электрошокер. Напишите мне личным сообщением (@aratak) как вы видите решение такой повсеместной проблемы. Или быть может проблемы нет вовсе? Расскажите мне как у вас устроен процесс. Если вас тоже долгое время гложет этот вопрос, напишите мне сообщением что-то вроде «правильного ответа не знаю, но очень хочу узнать». Мой никнейм в телеграмме @aratak. Его же можно найти в описании канала. Только не обижайтесь, если я вам не отвечу или отвечу односложно. Конечно, я буду стараться ответить всем, но не уверен, что у меня это физически получится. Жду!
Читать полностью…
Идеальная методология ведения проекта должна никак себя не проявлять в процессе. Она должна быть настолько естественной и непринужденной, на сколько это вообще возможно. Чтобы этого добиться, нужно помнить, что человек очень ленив от природы. Любой без исключения. И мозг наш устроен таким образом, что мы самым естественным образом придумывает как достичь желаемого с минимальными усилиями. Конечно же, очень важно что считается тем самым «желаемым», но говорим мы сейчас о разработчиках, а у них целью по определению стоит решение поставленной задачи. И проектные менеджеры с завидной регулярностью пытаются решить эту проблему.
(Продолжение следует…)
Сегодня ссылка на очень древнюю статью (и ее перевод) от Джоэла Спольски, которая не потеряла актуальности и является каноничным примером правильного масштабирования предприятия. Или «методологии», если хотите.
Конечно, сейчас, очень тяжело удивить кого-нибудь сравнением компании с программистами с макдональдсовской организацией труда, но тогда статья Джоэла была очень удачной. И до сих пор используется термин «голый повар» из этой статьи, применимо к разработчикам-импровизаторам высокого уровня.
Совершенно не понимаю похвальный ли это термин или ругательный. А вы как думаете?
В телеграмме не так уж и много каналов, на которые стòит подписаться. Много каналов могли бы быть хорошими, но огромное количество рекламы на этих каналах не дает им это сделать. Другие каналы могли быть интересными, но огромное количество второсортных новостей в ленте этих каналов понижает качество содержимого, что читать их уже не хочется.
Но некоторые каналы все еще не сдают позиции и продолжают заинтересовывать меня, как скрупулёзного и требовательного читателя качественными статьями и внятными темами. Если вы не читаете вообще никаких каналов в телеграме (кроме «Экстраполяции» естественно), то на эти каналы даже стоит подписаться, наверное. Но я на вас не давлю, вам решать.
@just_data_science. Канал об обработке и анализе данных. Пишет живо и с душой.
@JoyFromX. Телеграмовский аналог книги «занимательная математика», которую многие читали в детстве. С математическими задачами.
@SysadminNotes. Записки практикующего админа. Много разных маленьких админских радостей и критически важные для серверов знания. Применяю, конечно же, я их чуть менее, чем редко, но канал хороший и читать легко.
@theoryofgames. Как понятно из названия, канал о теории игр. Просто и доступно. Читаю с удовольствием.
@unilecs. Прям, подборка задач на собеседование. Читаю условия с интересом, решать, понятное дело, не решаю. Но если вдруг вы только учитесь программированию советую решать.
Конечно же вы помните, что на канале «Экстраполяции» платной рекламы нет, впрочем, как и нынче популярного и жутко раздражающего взаимного пиара (это когда два канала рекламируют друг друга). И этот пост — не исключение. Реклама ли это? Конечно реклама! Эти каналы мне нравятся и их рекламирую, потому что это будет полезно вам, моим читателям. Куплен ли этот пост? Конечно же нет. В «Экстраполяции» можно прочитать только то, что я считаю правильным и честным по отношению своим читателям.
Тут никогда не при каких обстоятельствах не будут рекламироваться каналы с секретами онлайн-казино, быстрого способа заработать, каналы успешных бизнесменов или еще какой подобной чушью. Как по мне, это верх неуважения к читателям — рекламировать подобного рода сомнительный контент.
Для вас — только самое лучшее, мои дорогие.
Кстати, чтоб два раза не вставать. Что вы думаете по поводу таких вот ссылок на то, что стоит почитать тут вот, в телеграмме? Без рекламы и только интересности.
Последние пару лет одной из самых шумных и горячих темой остается машинное обучение с нейронными сетями (ну, или эмуляциями нейронных сетей). Вещь эта настолько интригующая и необузданная, что вызывает бурю эмоций как у разработчиков, так и у инвесторов. Выглядит это полнейшей магией, видимо, чем и подкупает.
Как по мне, использование нейронных сетей для решения любой из проблем является для разработчика чистосердечным признанием в собственной беспомощности и несостоятельности составить набор проверок и действий, который решит требуемую задачу в алгоритмических рамках.
Само собой, использовать нейронные сети и все их подобия можно и даже нужно, но только лишь там, где совершенно нет возможности хоть как-то детерминировать требуемый процесс.
У обычных разработчиков (серверных, если хотите), а не у «фронтенд-разработчиков» с идентификацией все более или менее аккуратно и очевидно. Фраза «я разработчик и я знаю питон, скалу, руби, эрланг и сервера настраивать» никого не удивляет и вполне естественна. А вот «я фронтенд-девелопер и умею все, что в браузере работает», звучит почему-то раздуто.
Еще подмечено, что у крутых нодэджеэсеров считается зазорным уметь хорошо верстать. Но это не точно.
«Правило бутерброда» в современную айти-эпоху заиграло новыми красками и сейчас должно называться «правилом бэкапа».
Вообще, процесс бекапа не так интересен, как процесс восстановления из бекапа. Поэтому постановка вопроса «делаете ли бекапы» в корне не верен. Правильный вопрос: «Умеете ли вы восстанавливать из бекапов?».
Дальше должна идти тирада об полезности учебных тревог в военных частях и аналогии с падением серверов, но я её лучше оставлю для самостоятельного размышления.
#личностноеразвитие
Про повышения. Большинство наемных сотрудников считает, что руководство его заметит, оценит и повысит зарплату. Это большое заблуждение. Ни один руководитель в здравом уме не будет увеличивать расходную часть, тем самым уменьшая доходную. Если вы встречали компанию в которой происходит периодическая оценка персонала и сама компания инициирует повышения, то это заслуга HR департамента и им удалось "продать" руководству эту необходимость. Например, еще лет 5 назад, в IT был бурный рост ставок и дабы гребец не сбежал, его повышали. С тех пор ставки доросли до своего максимума, рынок немного стабилизировался.
Как же получить повышение? Ответ очевиден и прост, только вот признавать его мало кто желает... Надо показать свою ценность. Больше и усердней работать? Нет. Нужно решать задачи бизнеса. Тут возможны разные сценарии. Можно прийти с анализом, мол, такой-то процесс неэффективен, эта система работает недостаточно быстро, там затраты можно снизить, а тут можно малой кровью сделать продукт лучше. Это, безусловно, лучше чем не делать ничего или ныть о том как все плохо. У этого подхода есть недостаток: то что сотрудник считает важным, может таким не являться для руководителя. При отказе же, сотрудник демотивируется и может впасть в депрессию.
Самый верный вариант - это поговорить с руководителем и выяснить какие задачи стоят перед руководителем, чем можно ему помочь, какие есть финансовые и временные ограничения. Затем стоит тщательно проанализировать полученные данные и идти на повторную встречу с предложениями по решению задач. Помните про ценность? Ценность в том, чтобы предложить наиболее эффективное решение, продумать все до мелочей, быть готовым взяться за реализацию и решить проблему бизнеса. Если решения нет, то лучше прямо об этом сообщить, а не пытаться придумать хоть что-то. Если уже браться, то обязательно доводить до конца, а то второго шанса может и не выпасть.
@noTieinIT
В эфире наша уже постоянная рубрика «Полный Аджайл» с заметками по техпроцессам разработки от читателей.
О мотивации менеджеров и коллективной стратегии
В команде почти всегда есть тот, кто рвётся в менеджеры. Вот на эту здоровую голову можно и переложить со своей здоровой проблемы джиры, мотивируя это каким-то повышением. Как показывает практика, люди готовы ждать этого повышения два-три года, если их периодически хвалить и всячески словесно поощрять. За это время человек может заработать себе новое звание «за выслугу лет» или просто потому, что стал опытнее и круче. Но все это под соусом его управленческих навыков и лидерских качеств.
Если нет такого человека, назначаешь срам-мастером каждого работника по спринту. От него требуешь планирования, оценок и ретроспектив. А дальше - он уже делает все по накатанной. Но команда должна понимать, что в следующем спринте его место займёт кто-то другой. И коллективная стратегия работает лучше индивидуальной. Главное, чтобы она была направлена на тикеты, а не против твоих процессов.
#полныйаджайл
Второй выпуск рубрики «Полный Аджайл» с заметками по техпроцессам разработки от читателей. Присылайте ваши мысли и описание ваших техпроцессов мне личным сообщением, ведь такие ценные знания должны быть общим достоянием.
О сторипоинтах
tl;dr: Sp = t • Grade
Сторипоинты это работа в физическом смысле. А умение справится с работой у разработчика — это мощность. Все мы помним из физики, что мощность пропорциональна отношению работы ко времени. Или иначе работа это мощность, умноженная время. Поэтому называть планируемое время работы над задачей можно и нужно. Только после этого нужно только приводить к работе-сторипоинтам правильно, домножая на мощность. Разработчик это в своей голове вряд ли сделает это как нужно.
#полныйаджайл
Ребята, возможность эту можно найти в системных настройках, в разделе «клавиатура». Не все нашли :-)
Читать полностью…
Месяц назад в нашем уютном канале была статья о лакмусовых бумажках в программировании. В ней рассказывалось о неких критериях написания кода, по которым можно сказать, что что-то идет не так. Помните же? Сегодня будет еще одна лакмусовая бумажка от программирования. Очень похоже на то, что это прям целая рубрика будет. И назовем ее, скажем, «Две полоски», по аналогии со всеми известным процессом :-) В эту рубрику также принимаются ваши критерии и советы, пишите личным сообщением с пометкой #двеполоски.
Итак, критерий.
Временных решений не бывает.
Бывают решения, которые предпочитаются более удачным по разным обстоятельствам: меньшее время, более простой код, упрощенный дизайн и прочее. Но то решение, которое делается здесь и сейчас может просуществовать годами без изменений и переплестись с другими частями приложения настолько тесно, что заменить его будет крайне тяжело. Конечно, на компромиссы идти нужно и делать это приходиться постоянно, но тешить себя мыслью, что решение временное и можно тут слегка поступиться принципами нельзя.
Ребята, технический пост.
На днях столкнулся с таким понятием, как нативная реклама. Нет, раньше я, конечно знал что это такое и понимал как оно работает, но масштабов проблемы не видел.
В общем, предложили мне (в очередной раз) опубликовать рекламу в «Экстраполяции». Обычно в таких случаях я просто закатываю глаза к небу и отвечаю что-то вроде «нет, рекламы на канале не бывает». А в этот раз как-то настойчиво предлагали, с уверенностью, что такая реклама на канале вообще бывает. Рекламодатель сильно удивился отказу и прислал ссылку на пост с подбором различных каналов, где четко и ясно написано, что это не реклама и исключительно моё мнение. Говорит, что думал, что это «такой нейтив». Мол, купили моё мнение и рекламирую я каналы под видом независимого и неподкупного.
Вот такая она, эта нативная реклама, друзья. На каналах, где плевать на своих читателей, она подается под видом мнения автора. Читайте «Экстраполяцию», ссылки на что угодно тут появляются только потому, что это интересно и полезно, а не потому что за нее заплатили.
Сегодня в ленте пилотный выпуск рубрики «Полный Аджайл». Напоминаю, что в ней публикуются различные заметки по техпроцессам разработки и в первую очередь не от редакции, а от вас, дорогие читатели. Присылайте ваши мысли и описание ваших техпроцессов мне личным сообщением, ведь такие ценные знания должны быть общим достоянием.
О снижении гибкости управления проекта
Можно желать упростить рабочие процессы программиста до того, что ему ничего не нужно будет делать. Но ведь все проблемы контроля и определения сроков исходят из требований гибкости и постоянного изменения требований. Ведь при каскадной модели мы относительно точно знаем сколько людей с какими навыками нужно для выполнения проекта, так как все процессы делятся на этапе подготовки проекта. С этим в теории просто и понятно.
А когда требования меняются каждый день, то программист должен понимать общую архитектуру проекта, покрывать тестами, рассказывать что да как коллегам. Внедряются новые фреймворки, и хорошо если не нагрузили девопсом. Фронтендеры пишут не только браузерный джаваксрипт, но и серверный слой на nodejs, верстают, работают с моделями баз данных и прочее прочее. То, что по-правильному таких разработчиков нужно назвать «гибридные разработчики» и наверняка вы помните статью об этом.
Одна из сложностей такого подхода — понять, что происходит в соседней команде и при необходимости принять задачу оттуда порой не самый простой момент. Получается, чем менее четкое понимание проекта на старте, тем более универсальны должны быть разработчики и тем больше менеджеров нужно чтобы связывать все структуры. В итоге понятно, что снижать менеджерскую нагрузку по версии разработчика можно пропорционально снижению гибкости проекта. Так себе решение получается, но со стороны программиста выглядит именно так.
Мы стали заложниками того, что проекты запускаются, тестируются и меняются без стратегии, одна тактика.
#полныйаджайл
Ребята, спасибо всем, кто написал весточку в личку. Вроде бы ответил всем, никого не упустил. Как и предполагалось, многие видят описанную проблему, но железной стратегии не нашли. Были и решения, с которыми я лично не согласен, но универсальной пули для такой глобальной проблемы быть не может, поэтому постараюсь сформулировать и опубликовать все присланные решения, тем более, что они вполне себе легко систематизируются. Встречайте с понедельника на волнах нашего канала рубрику #полныйаджайл.
А вы, мои дорогие, присылайте личным сообщением описание процесса управления проектом в вашей команде и мы опубликуем самые интересные анонимно или публично. Такое сакраментальное знание не должно таиться, им обязательно нужно делиться.
Итак, задача.
Дано: разработчику нужно решить поставленную перед ним задачу с минимальными усилиями (для разработчика).
Цель управляющего: ввести систему учета и оценки задач для грамотного планирования.
И самое время вспомнить об аджайле. Пусть разработчик прежде чем делать задачу сначала потратит время на ее оценку и описание способа решения. Потом защитит свою позицию на совещании перед коллегами и управляющими. Потом каждый день будет писать отчет о проделанной работе в вольной форме, отмечать прогресс задачи. Само собой попутно у него возникают куча проблем и вопросов, на которые разработчик хочет получить ответы. И разработчик ищет самый простой способ получить ответы на свои вопросы. И тут самое интересное: что конкретно он делает? Идет общаться лично (если это возможно, конечно же), звонит по аудио-видео связи, если он любит общаться или же пишет в чат, если наш подопытный — интроверт. После получения всех ответов можно было бы и к решению задачи приступить, но вот незадача, нужно же еще тикет поправить, внести в отчетность все разговоры и статус тикета еще же обновить! Само собой, все, что необходимо сделать разработчику после того, как решение уже известно, воспринимается разработчиком как лишние действия и все естество человека идет против того, чтобы это делать. Найдется тысяча причин по которой редактирование тикета ну просто необходимо отложить на потом, а статус задачи тоже катастрофически важно не изменять прямо сейчас. Конечно же разработчик делает задачу, правильно все оформив в кодовой базе, а вот на остальное сил и энтузиазма уже не остается.
Возможное решение: нанять специального человека, выдать ему плеть и полномочия постоянно проверять актуальность бюрократической машины. За проступок разработчик получит десять ударов плетью. Цель достигнута, разработчик совершенно не желает прочувствовать всю мощь хлыста на себе.
Проблема: наш разработчик резко меняет приоритеты. Главное — правильно заполнять все в джире, а задачу сделать, собственно, не главное. Само собой, интерес к проекту и к работе над ним резко угасает, руководство пытается компенсировать это денежными бонусами, что, собственно, не помогает. Толковые разработчики, которые пишут хороший и правильный код, уходят и остаются те, которые хотят больше денег и согласны заполнять тикеты. От того и планерки утренние такие скучные и затянутые.
(Продолжение следует…)
Одно из самых главных заблуждений любого планирования задач состоит в том, что все друг-другу врут. Как бы это парадоксально не звучало. Разработчики умножают оценку, которая им кажется реальной на три, менеджеры потом еще сверху удваивают, а потом еще управляющие еще на три, и потом стейкхолдеры особо не надеются уложиться в срок.
Есть кучу попыток этот процесс как-то формализовать и лишить человеческого фактора, но в общем и целом задача все еще не решена и решается исключительно опытностью менеджеров, которые непосредственно общаются с исполнителями. Самая работоспособная схема использует условные единицы измерения, и вот тут-то и начинаются враки. Первое, что говорят новичку в команде старожилов, что их условный хронопопугай вмещает в себя где-то пять часов разработки и нужно оценивать это именно так — делением оценки в часах на пять. И вот тут-то и начинается вранье. Каждый у себя в голове оценивает задачу в часах и потом несложными математическими операциями превращает это в сторипоинты. А потом внимательно смотрит на коллег пронизывающим взглядом и думает, не слишком ли маленькое (или наоборот, большое) количество хронопопугаев получается. А потом умножает так, чтобы соответствовать ожиданиям коллег и менеджеров. И дальше по накатанной.
А нужно знание о количестве часов в одном сторипоинте держать в строжайшей тайне каждому из участников. Ввести табу на знание коэффициента перевода часов в сторипоинты других участников команды и станет сразу хорошо. Каждый участник системы воспринимает по-своему этих попугаем. Когда разработчик думает, что задачу можно сделать за пять часов, он смело называет «один попугай» вообще не признаваясь никому сколько часов ему кажется это выходит. «Один» и все тут, никаких часов или сроков. А каждый его услышит совершенно по-своему, ведь коэффициент у каждого свой. Тогда этот механизм будет работать.
А сейчас, к большому сожалению, подавляющее большинство команд знают коэффициент перевода часов в попугаев и поэтому система не работает.
Аджайл-скрам-канбан достаточно хорошо себя зарекомендовал в теории и крайне некомфортно выходит с ним работать на практике по одной простой причине: постоянно требуется какая-то дополнительная стимуляция, чтобы соблюдать все основные каноны выбранной методологии. Все ретроспективы, митапы, стендапы, беклоги и пленинг-покеры нужны исключительно как стимулирование разработчика делать то, что ему не очень хочется делать. И для этого процесса стимуляции нужен отдельный человек с отдельной должностью, задача которого состоит в том, чтобы следить за выполнением всех заранее оговоренных заповедей.
Конечно же, главная задача любой методологии состоит не в том, чтобы запутать и усложнить процесс разработки. И не в том, чтобы его как-то упростить или сделать прозрачным. Основная задача, которую решают, вводя хоть какую-нибудь методологию — стандартизация. Придумав (или позаимствовав) набор правил ведения проекта, можно добиться ситуации, когда любой вопрос можно решить, используя этот самый свод правил. И не важно что это за ситуация такая, у аджайла-скрама найдется алгоритм поведения, который точно расскажет что нужно делать с той или иной задачей.
Если кажется, что после внедрения скрама в проекте все только усложнилось, то это точно не кажется, это так и есть. И это нормально. Если видно, что после внедрения методологии нужно делать какие-то усложненные бюрократические действия, то это безусловно неэффективно с точки зрения решения конкретной задачи, но крайне эффективно с точки зрения управления всем проектом целиком.
Сегодня ссылки на очень хорошую статью и ее переводе на русский язык об «ошибке выживших». Цитата для затравочки:
«Как, спрашивала Авиация сухопутных войск, как можно увеличить процент возвращающихся бомбардировщиков. Военные инженеры объясняли, что бомбардировщикам союзников не помешало бы больше брони, но наземный экипаж не мог обшить самолеты, как танки, они бы просто не взлетели. Тогда командиры попросили определить оптимальные места, чтобы добавить броню только туда... Военные осмотрели бомбардировщики, сумевшие вернуться с вражеской территории. Они отметили все места, в которых самолеты были повреждены больше всего. Осматривая один самолет за другим, они замечали, что, в основном, больше всего дыр от пуль было вдоль крыльев, возле стрелка хвостовой стрелково-пушечной установки и по центру нижней части корпуса. Отлично. Крылья. Корпус. Хвост. Учитывая эту информацию, где бы вы поставили допброню? Разумеется, командующие решили добавить брони там, где увидели наибольший ущерб — где было больше всего дыр от пуль. Но Вальд сказал, что это будет абсолютно неправильно. Установка дополнительной брони в этих местах вообще не улучшит их шансы. Понимаете, почему это глупая затея?»
В непосредственно рутинной каждодневной разработке становится целой проблемой определить насколько хорош код, который вот прям сейчас вот пишется. И это не потому что разработчик недостаточно хорош для этого кода, а потому что придуманный код для писавшего по определению уже самый лучший, а иначе тогда вообще зачем он его придумал тогда. Обычно риторика добавления костылей в кодовую базу оперирует понятиями «могут быть какие-то части кода не совсем красивые, но по-другому ведь никак тут не напишешь», и последствия таких рассуждений мы с вами все знаем. Существует техника самопроверки написанного кода, при котором обнаружить все проблемные места в пулл реквесте нельзя, но большинство из них отловить все-таки можно. Это набор лакмусовых бумажек (триггеров, если хотите), о которых нужно всегда помнить в процессе написания кода. Вот некоторые из них:
— Достаточно ли просто тестировать получившийся код? Если возникают проблемы с написаниями тестами, то где-то тут попахивает плохим кодом.
— Хорошо ли этот код масштабируется вертикально? И речь тут не о запуске нескольких приложений рядом, а о добавлении сущностей уровня выше. Вроде 'company_id' если хотите.
— Легко ли придумать название методу или переменной? Если называние не слишком очевидное или придумывается тяжело, то скорее всего и содержимое не слишком очевидно.
— Много ли методов нужно переопределять? Много ли граничных условий обрабатывается? Или в общем случае: как формулируются правила по которым работает ваша функциональность и сколько исключений из этих правил? Касается это не сколько бизнес-логики, а сколько правильно подобранной архитектуры и структуры кода. Если в системе нашелся неприятный баг и исправить его можно, добавив еще одно условное ветвление, то значит этот баг появился не на пустом месте, а от неправильно подобранной структуры кода.
Таких критериев достаточно много, некоторые даже просто так сформулировать не получается и в каждом отдельно взятом проекте условия могут разниться. Более того, отдельно взятый разработчик уже имеет набор таких критериев где-то у себя в подсознании и определяет плохо пахнущий кусок кода именно по этим критериям. Попробуйте сформулировать эти критерии для себя письменно и постоянно совершенствуйте этот список. Помимо четкой формулировки говнокода вы еще получите прекрасный инструмент самотестирования, ведь через полгода написания свой код кажется не таким уж и хорошим, а вот почему — будет видно по появившимся новым критериям.
