Тесты в первую очередь — механизм проверки того, что-то, что написано — работает. Вопрос не в том, необходимо покрывать тестами или нет, а вопрос в том, как убедится, что только что написанный код работает. Существует несколько неправильных способов писать рабочий код. Можно открывать интерактивную консоль, выполнять код там и копировать его внутрь методов, можно использовать дебаггер для перехвата управления приложением и опять же, в интерактивной консоли пробовать угадать рабочий код. Можно после каждого изменения в любом месте перезапускать сервер (возможно, в вашем фреймворке есть способ делать это автоматически) и вручную проверять поведение приложения в целом. А можно попытаться автоматизировать этот процесс и проверять код сразу в тестах. В итоге появились три запрещающих правила:

1. Табу на использование интерактивной консоли в процессе написания кода.
2. Запрет на дебаггер при разработке.
3. Нельзя держать запущенным приложение локально, чтобы иметь возможность кликать, и проверять результат.

Соблюдая эти три нехитрых правила не писать тесты просто не получается.

Не все согласны с мнением относительно табу на использование интерактивной консоли. Иногда консоль может быть крайне полезной и удобной. Она же может позволить избавиться от ненужных тестов, проверить быструю гипотезу и много еще чего такого. После вчерашнего поста мне прислали ссылку на статью, где автор как раз рассказывает что по его мнению должна делать хорошая интерактивная консоль. Очень хорошая и полезная статья, рекомендую к ознакомлению.

Она напоминает о таком режиме программирования, которую многие называют «спайк». В этом режиме разработчик понятия не имеет как будет выглядеть будущая программа, какой у нее будет интерфейс и какая архитектура. Он просто творит. Это очень полезный вид разработки, который должен сформировать полную и целостную картину того, как должна выглядеть будущая программа, но не более. Но писать настоящий код в таком режиме нельзя. После сформировавшегося мнения о будущей программе весь спайканый код нужно удалить и начать писать нормальный код с тестами и проверками.

Понятие «покрытие тестами» нужно только разработчику. Этот критерий говорит тебе какое место приложения ни разу не запускалось (помним о вышеупомянутых правилах и о том, что консоль запускать вообще не надо). В итоге получится, что непокрытый тестами код ни разу не запускался вообще при разработке и, возможно, попадет на рабочий сервер так ни разу и не проверенным. Поэтому вопрос написания тестов должен звучать так: смогу ли я написать программу ни разу не запустив интерактивную консоль и сервер при разработке или не смогу? Кроме того, при такой стратегии разработки понятие полезного и бесполезного теста просто лишено смысла. Если разработчик захотел что-то проверить, он обязательно напишет тест. Если ему не захотелось проверить код по какому-то условию, то теста на это не появится в принципе. Последним по списку, но никак не по важности является тот факт, что длинные методы в стиле спагетти, которые делают несколько вещей сразу, просто неудобно писать. Это же еще проверять тестами нужно!

Очевидно, что арбалет, как устройство появилось значительно позже лука. Проблема, которую решал создатель арбалета достаточно проста и очевидна — хотелось сохранить кинетическую энергию натянутой тетивы без участия мускулатуры стрелка. В итоге арбалет получился более громоздким, менее дальнобойным, более дорогим в изготовлении, менее скорострельным, менее убойным на средних дистанциях. Лук (особенно длинный лук) уделывал арбалет по всем показателям, тем не менее, после популяризации арбалета практически все армии так или иначе использовали в первую очередь именно арбалет, а не лук. И причина этому очень простая.

Чтобы вырасти и Робином Гудом и сделать так, чтобы стрела хотя бы летела в нужном направлении, не говоря уже о хоть какой-нибудь точности, нужно потратить не один месяц, а может быть даже и не один год. А получить целый отряд справных лучников, работающих в команде, еще менее вероятно и более тяжело. А вот с арбалетами и арбалетчиками все намного проще, ведь пары часов инструктажа вполне достаточно, чтобы организовать заградительную стену стрел в ближайшей стычке с врагом. Экономически и стратегически легче найти и нанять десять арбалетчиков и вручить им десять арбалетов, чем воспитать одного лучника.

Само собой, сеньор-лучник будет в пять раз лучше любого джуниора-арбалетчика и бюрократии для одного лучника не требуется вовсе. И организовывать командную работу одному лучнику не нужно. На десять арбалетчиков нужно еще одного тим-лида, пару офис-менеджеров и одного кадрового агента, чтобы заменять убитых и уволенных арбалетчиков и придворного организатора праздников, чтобы развлекал толпу арбалетчиков, пока те не стреляют. В итоге владение луком стало приятным бонусом при найме арбалетчиков, а потом лук и вовсе перерастёт скорее в хобби, чем в основную профессию. Хотя, безусловно, на конференциях арбалетчиков говорят все исключительно о том, как правильно владеть луком и как сильно техника владения луком помогает стрелять из арбалета. И что на десять арбалетчиков в команде нужно иметь пару лучников. И что если бы все десять тысяч арбалетчиков в регулярной армии владели бы луком, то можно было бы и Византию захватить.

Но все мы знаем, что в результате побеждает стандартизация, а не профессионализм.

В Нидерландах, в семнадцатом веке, покупкой и продажей тюльпановых семян занимались цветоводы и ценители, что не удивительно. Но в какой-то момент в процесс покупки-продажи тюльпановых семян включились непрофессиональные спекулянты, сделали из этого фьючерсы и цены на луковицы некоторых сортов тюльпанов многократно выросли. Через некоторое время, из-за огромного ажиотажа, цены на обычные тюльпанные луковицы тоже пошли вверх и тоже стали объектом фьючерных торгов спекулянтов. Потом к этому процессу подключились и те, кто не был ни цветоводом, ни спекулянтом, а просто хотел заработать на хайпе. Говорят, это был первый в истории биржевой пузырь, потому как через полтора года цены рухнули и начались многолетние тяжбы между продавцами и покупателями ничем не обеспеченных тюльпановых контрактов. К слову, на пике своей популярности луковица редкого сорта тюльпанов стоила, как три годовых дохода ремесленника средней руки.

«Не смехотворно ли платить золотом за бесполезные корневища?», спрашивал какой-то там историк спустя полтора века. Да, уж. Через полтора века наверняка уже смехотворно.

Давайте на секундочку представим, что у нас нет никаких СУБД и данные есть в оперативной памяти в виде обычных структур данных. Идеальное решение по скорости доступа, идеальная интеграция с бизнес-логикой.

И тут же появляется первая проблема рестарта приложения, ведь хочется не терять данные. И тут эволюция компьютеров не придумало пока ничего другого, кроме как сохранить эти данные на жесткий диск. И только вопрос в том, как это сделать. Транзакционность, распределенность, конкурентность, производительность. Это все, конечно же интересно, но сейчас мы говорим о том, что же все-таки сохранять в файлике, а что нужно считать в реальном времени в бизнес-логике.

Если мы наши данные будем как-то стандартизировать и просто записывать в файл, то рано или поздно (но скорее рано) захочется рядом с данными держать еще и вычисляемые данные, вроде count, max, order_by и ортогональные срезы данных, вроде where, where-join и union. Так или иначе это делать нужно и вопрос только в том, где это делать и в каком формате.

И тут с легкостью обнаруживается, что это стандартная проблема абстрагирования и инкапсуляции логики. Можно четко сформулировать проблему, где будет вполне ясно сказано где у нас просто данные, а где вычислимые данные и валидации этих данных. И вдруг окажется, что бизнес-логика, со всеми манипуляциями инвойсами, юзерами и чем-там-у-вас-еще должна быть железобетонно отделена от слоя, где эти данные денормализуются, валидируются, транзакционируются и все прочее.

Окажется, что ту часть любого приложения о которой мы с вами сейчас говорим, можно абстрагировать до следующей цепочки:

(`Б` - бизнеслогика) -> (`Д` - денормализация) -> (`П` - персистентность)

Тогда вопрос и все мнения можно свести лишь к приоритету операций. К тому, что у вас конкретно инкапсулировано: Д+П или просто П. Соответственно, если Б недостаточно отделено от Д, то может сложиться впечатление, что Д — это часть Б, но это очевидно, что не так.

А если приложение написано нормально, и Д достаточно отделено от П, то совершенно не важно где конкретно вы занимаетесь Д.

(Б + Д) + П — плохо
Б + (Д + П) — немножко лучше
(Б) + (Д) + (П) — хорошо

Внимательно сравнив эти три варианта, становится понятно, что до тех пор, пока бизнес-логика ничего не знает о денормализации, и абстракция денормализации не протекает, то совершенно не важно где конкретно денормализуются данные.

Беда только в том, что в попытке достичь варианта (Б) + (Д) + (П), неизбежно получается вариант (Б + Д) + П.

Сейчас стало крайне модным отвязывать себя от какой-то конкретной технологии и считаться неким «специалистом, который все может и не надо ему указывать какие инструменты ему использовать». Безусловно, крайне похвально с точки зрения технической подкованности самого специалиста. Но это же крайне опасно с точки зрения проекта и остальных его участников. Подумайте сами, если только что нанятый специалист в команду считает, что вон тот кусочек приложения было бы крайне эффективно переписать на языке-который-никто-кроме-него-не-знает, то последнее, что нужно делать — это переписывать это на том самом языке.

Умение работать в коллективе — одна из важнейших характеристик разработчика и не редко именно с этого нужно начинать собеседование. Понимание способностей и предпочтений всех своих коллег — главная характеристика умения работать в коллективе.

В непосредственно рутинной каждодневной разработке становится целой проблемой определить насколько хорош код, который вот прям сейчас вот пишется. И это не потому что разработчик недостаточно хорош для этого кода, а потому что придуманный код для писавшего по определению уже самый лучший, а иначе тогда вообще зачем он его придумал тогда. Обычно риторика добавления костылей в кодовую базу оперирует понятиями «могут быть какие-то части кода не совсем красивые, но по-другому ведь никак тут не напишешь», и последствия таких рассуждений мы с вами все знаем. Существует техника самопроверки написанного кода, при котором обнаружить все проблемные места в пулл реквесте нельзя, но большинство из них отловить все-таки можно. Это набор лакмусовых бумажек (триггеров, если хотите), о которых нужно всегда помнить в процессе написания кода. Вот некоторые из них:

— Достаточно ли просто тестировать получившийся код? Если возникают проблемы с написаниями тестами, то где-то тут попахивает плохим кодом.
— Хорошо ли этот код масштабируется вертикально? И речь тут не о запуске нескольких приложений рядом, а о добавлении сущностей уровня выше. Вроде 'company_id' если хотите.
— Легко ли придумать название методу или переменной? Если называние не слишком очевидное или придумывается тяжело, то скорее всего и содержимое не слишком очевидно.
— Много ли методов нужно переопределять? Много ли граничных условий обрабатывается? Или в общем случае: как формулируются правила по которым работает ваша функциональность и сколько исключений из этих правил? Касается это не сколько бизнес-логики, а сколько правильно подобранной архитектуры и структуры кода. Если в системе нашелся неприятный баг и исправить его можно, добавив еще одно условное ветвление, то значит этот баг появился не на пустом месте, а от неправильно подобранной структуры кода.

Таких критериев достаточно много, некоторые даже просто так сформулировать не получается и в каждом отдельно взятом проекте условия могут разниться. Более того, отдельно взятый разработчик уже имеет набор таких критериев где-то у себя в подсознании и определяет плохо пахнущий кусок кода именно по этим критериям. Попробуйте сформулировать эти критерии для себя письменно и постоянно совершенствуйте этот список. Помимо четкой формулировки говнокода вы еще получите прекрасный инструмент самотестирования, ведь через полгода написания свой код кажется не таким уж и хорошим, а вот почему — будет видно по появившимся новым критериям.

Последние пару лет одной из самых шумных и горячих темой остается машинное обучение с нейронными сетями (ну, или эмуляциями нейронных сетей). Вещь эта настолько интригующая и необузданная, что вызывает бурю эмоций как у разработчиков, так и у инвесторов. Выглядит это полнейшей магией, видимо, чем и подкупает.
Как по мне, использование нейронных сетей для решения любой из проблем является для разработчика чистосердечным признанием в собственной беспомощности и несостоятельности составить набор проверок и действий, который решит требуемую задачу в алгоритмических рамках.
Само собой, использовать нейронные сети и все их подобия можно и даже нужно, но только лишь там, где совершенно нет возможности хоть как-то детерминировать требуемый процесс.

​​Сегодня ссылки на очень хорошую статью и ее переводе на русский язык об «ошибке выживших». Цитата для затравочки:

«Как, спрашивала Авиация сухопутных войск, как можно увеличить процент возвращающихся бомбардировщиков. Военные инженеры объясняли, что бомбардировщикам союзников не помешало бы больше брони, но наземный экипаж не мог обшить самолеты, как танки, они бы просто не взлетели. Тогда командиры попросили определить оптимальные места, чтобы добавить броню только туда... Военные осмотрели бомбардировщики, сумевшие вернуться с вражеской территории. Они отметили все места, в которых самолеты были повреждены больше всего. Осматривая один самолет за другим, они замечали, что, в основном, больше всего дыр от пуль было вдоль крыльев, возле стрелка хвостовой стрелково-пушечной установки и по центру нижней части корпуса. Отлично. Крылья. Корпус. Хвост. Учитывая эту информацию, где бы вы поставили допброню? Разумеется, командующие решили добавить брони там, где увидели наибольший ущерб — где было больше всего дыр от пуль. Но Вальд сказал, что это будет абсолютно неправильно. Установка дополнительной брони в этих местах вообще не улучшит их шансы. Понимаете, почему это глупая затея?»

В телеграмме не так уж и много каналов, на которые стòит подписаться. Много каналов могли бы быть хорошими, но огромное количество рекламы на этих каналах не дает им это сделать. Другие каналы могли быть интересными, но огромное количество второсортных новостей в ленте этих каналов понижает качество содержимого, что читать их уже не хочется.
Но некоторые каналы все еще не сдают позиции и продолжают заинтересовывать меня, как скрупулёзного и требовательного читателя качественными статьями и внятными темами. Если вы не читаете вообще никаких каналов в телеграме (кроме «Экстраполяции» естественно), то на эти каналы даже стоит подписаться, наверное. Но я на вас не давлю, вам решать.

@just_data_science. Канал об обработке и анализе данных. Пишет живо и с душой.

@JoyFromX. Телеграмовский аналог книги «занимательная математика», которую многие читали в детстве. С математическими задачами.

@SysadminNotes. Записки практикующего админа. Много разных маленьких админских радостей и критически важные для серверов знания. Применяю, конечно же, я их чуть менее, чем редко, но канал хороший и читать легко.

@theoryofgames. Как понятно из названия, канал о теории игр. Просто и доступно. Читаю с удовольствием.

@unilecs. Прям, подборка задач на собеседование. Читаю условия с интересом, решать, понятное дело, не решаю. Но если вдруг вы только учитесь программированию советую решать.

Конечно же вы помните, что на канале «Экстраполяции» платной рекламы нет, впрочем, как и нынче популярного и жутко раздражающего взаимного пиара (это когда два канала рекламируют друг друга). И этот пост — не исключение. Реклама ли это? Конечно реклама! Эти каналы мне нравятся и их рекламирую, потому что это будет полезно вам, моим читателям. Куплен ли этот пост? Конечно же нет. В «Экстраполяции» можно прочитать только то, что я считаю правильным и честным по отношению своим читателям.
Тут никогда не при каких обстоятельствах не будут рекламироваться каналы с секретами онлайн-казино, быстрого способа заработать, каналы успешных бизнесменов или еще какой подобной чушью. Как по мне, это верх неуважения к читателям — рекламировать подобного рода сомнительный контент.
Для вас — только самое лучшее, мои дорогие.

Кстати, чтоб два раза не вставать. Что вы думаете по поводу таких вот ссылок на то, что стоит почитать тут вот, в телеграмме? Без рекламы и только интересности.

​Аджайл-скрам-канбан достаточно хорошо себя зарекомендовал в теории и крайне некомфортно выходит с ним работать на практике по одной простой причине: постоянно требуется какая-то дополнительная стимуляция, чтобы соблюдать все основные каноны выбранной методологии. Все ретроспективы, митапы, стендапы, беклоги и пленинг-покеры нужны исключительно как стимулирование разработчика делать то, что ему не очень хочется делать. И для этого процесса стимуляции нужен отдельный человек с отдельной должностью, задача которого состоит в том, чтобы следить за выполнением всех заранее оговоренных заповедей.

Конечно же, главная задача любой методологии состоит не в том, чтобы запутать и усложнить процесс разработки. И не в том, чтобы его как-то упростить или сделать прозрачным. Основная задача, которую решают, вводя хоть какую-нибудь методологию — стандартизация. Придумав (или позаимствовав) набор правил ведения проекта, можно добиться ситуации, когда любой вопрос можно решить, используя этот самый свод правил. И не важно что это за ситуация такая, у аджайла-скрама найдется алгоритм поведения, который точно расскажет что нужно делать с той или иной задачей.

Если кажется, что после внедрения скрама в проекте все только усложнилось, то это точно не кажется, это так и есть. И это нормально. Если видно, что после внедрения методологии нужно делать какие-то усложненные бюрократические действия, то это безусловно неэффективно с точки зрения решения конкретной задачи, но крайне эффективно с точки зрения управления всем проектом целиком.

Сегодня ссылка на очень древнюю статью (и ее перевод) от Джоэла Спольски, которая не потеряла актуальности и является каноничным примером правильного масштабирования предприятия. Или «методологии», если хотите.

Конечно, сейчас, очень тяжело удивить кого-нибудь сравнением компании с программистами с макдональдсовской организацией труда, но тогда статья Джоэла была очень удачной. И до сих пор используется термин «голый повар» из этой статьи, применимо к разработчикам-импровизаторам высокого уровня.

Совершенно не понимаю похвальный ли это термин или ругательный. А вы как думаете?

​Одно из самых главных заблуждений любого планирования задач состоит в том, что все друг-другу врут. Как бы это парадоксально не звучало. Разработчики умножают оценку, которая им кажется реальной на три, менеджеры потом еще сверху удваивают, а потом еще управляющие еще на три, и потом стейкхолдеры особо не надеются уложиться в срок.

Есть кучу попыток этот процесс как-то формализовать и лишить человеческого фактора, но в общем и целом задача все еще не решена и решается исключительно опытностью менеджеров, которые непосредственно общаются с исполнителями. Самая работоспособная схема использует условные единицы измерения, и вот тут-то и начинаются враки. Первое, что говорят новичку в команде старожилов, что их условный хронопопугай вмещает в себя где-то пять часов разработки и нужно оценивать это именно так — делением оценки в часах на пять. И вот тут-то и начинается вранье. Каждый у себя в голове оценивает задачу в часах и потом несложными математическими операциями превращает это в сторипоинты. А потом внимательно смотрит на коллег пронизывающим взглядом и думает, не слишком ли маленькое (или наоборот, большое) количество хронопопугаев получается. А потом умножает так, чтобы соответствовать ожиданиям коллег и менеджеров. И дальше по накатанной.

А нужно знание о количестве часов в одном сторипоинте держать в строжайшей тайне каждому из участников. Ввести табу на знание коэффициента перевода часов в сторипоинты других участников команды и станет сразу хорошо. Каждый участник системы воспринимает по-своему этих попугаем. Когда разработчик думает, что задачу можно сделать за пять часов, он смело называет «один попугай» вообще не признаваясь никому сколько часов ему кажется это выходит. «Один» и все тут, никаких часов или сроков. А каждый его услышит совершенно по-своему, ведь коэффициент у каждого свой. Тогда этот механизм будет работать.

А сейчас, к большому сожалению, подавляющее большинство команд знают коэффициент перевода часов в попугаев и поэтому система не работает.

Идеальная методология ведения проекта должна никак себя не проявлять в процессе. Она должна быть настолько естественной и непринужденной, на сколько это вообще возможно. Чтобы этого добиться, нужно помнить, что человек очень ленив от природы. Любой без исключения. И мозг наш устроен таким образом, что мы самым естественным образом придумывает как достичь желаемого с минимальными усилиями. Конечно же, очень важно что считается тем самым «желаемым», но говорим мы сейчас о разработчиках, а у них целью по определению стоит решение поставленной задачи. И проектные менеджеры с завидной регулярностью пытаются решить эту проблему.

(Продолжение следует…)

Итак, задача.

Дано: разработчику нужно решить поставленную перед ним задачу с минимальными усилиями (для разработчика).
Цель управляющего: ввести систему учета и оценки задач для грамотного планирования.

И самое время вспомнить об аджайле. Пусть разработчик прежде чем делать задачу сначала потратит время на ее оценку и описание способа решения. Потом защитит свою позицию на совещании перед коллегами и управляющими. Потом каждый день будет писать отчет о проделанной работе в вольной форме, отмечать прогресс задачи. Само собой попутно у него возникают куча проблем и вопросов, на которые разработчик хочет получить ответы. И разработчик ищет самый простой способ получить ответы на свои вопросы. И тут самое интересное: что конкретно он делает? Идет общаться лично (если это возможно, конечно же), звонит по аудио-видео связи, если он любит общаться или же пишет в чат, если наш подопытный — интроверт. После получения всех ответов можно было бы и к решению задачи приступить, но вот незадача, нужно же еще тикет поправить, внести в отчетность все разговоры и статус тикета еще же обновить! Само собой, все, что необходимо сделать разработчику после того, как решение уже известно, воспринимается разработчиком как лишние действия и все естество человека идет против того, чтобы это делать. Найдется тысяча причин по которой редактирование тикета ну просто необходимо отложить на потом, а статус задачи тоже катастрофически важно не изменять прямо сейчас. Конечно же разработчик делает задачу, правильно все оформив в кодовой базе, а вот на остальное сил и энтузиазма уже не остается.

Возможное решение: нанять специального человека, выдать ему плеть и полномочия постоянно проверять актуальность бюрократической машины. За проступок разработчик получит десять ударов плетью. Цель достигнута, разработчик совершенно не желает прочувствовать всю мощь хлыста на себе.

Проблема: наш разработчик резко меняет приоритеты. Главное — правильно заполнять все в джире, а задачу сделать, собственно, не главное. Само собой, интерес к проекту и к работе над ним резко угасает, руководство пытается компенсировать это денежными бонусами, что, собственно, не помогает. Толковые разработчики, которые пишут хороший и правильный код, уходят и остаются те, которые хотят больше денег и согласны заполнять тикеты. От того и планерки утренние такие скучные и затянутые.

(Продолжение следует…)

​Давайте с вами вместе подумаем над более правильным решением вчерашней проблемы (см. два поста выше) в рамках большинства существующих компаний и организаций. Решение должно быть вполне выполнимо, не требовало бы расстрелять всю старую команду и набрать молодую кровь или сделать так, чтобы менеджерам вместо плёток выдавали электрошокер. Напишите мне личным сообщением (@aratak) как вы видите решение такой повсеместной проблемы. Или быть может проблемы нет вовсе? Расскажите мне как у вас устроен процесс. Если вас тоже долгое время гложет этот вопрос, напишите мне сообщением что-то вроде «правильного ответа не знаю, но очень хочу узнать». Мой никнейм в телеграмме @aratak. Его же можно найти в описании канала. Только не обижайтесь, если я вам не отвечу или отвечу односложно. Конечно, я буду стараться ответить всем, но не уверен, что у меня это физически получится. Жду!

​​Ребята, спасибо всем, кто написал весточку в личку. Вроде бы ответил всем, никого не упустил. Как и предполагалось, многие видят описанную проблему, но железной стратегии не нашли. Были и решения, с которыми я лично не согласен, но универсальной пули для такой глобальной проблемы быть не может, поэтому постараюсь сформулировать и опубликовать все присланные решения, тем более, что они вполне себе легко систематизируются. Встречайте с понедельника на волнах нашего канала рубрику #полныйаджайл.

А вы, мои дорогие, присылайте личным сообщением описание процесса управления проектом в вашей команде и мы опубликуем самые интересные анонимно или публично. Такое сакраментальное знание не должно таиться, им обязательно нужно делиться.

Наверное, вы заметили, что за все существование канала на нем ни разу не было ни одного поста о блокчейне и биткойне. Не хочу нарушать эту традицию. Очень надеюсь, что те читатели, которые приобрели во владение криптовалюту не проверяют ее стоимость каждые пять минут, а понимают, что такое приобретение можно рассматривать исключительно как долгосрочную инвестицию, и никакие колебания курса в пределах дня, недели или даже месяца вообще не важны. Перестаньте это делать, купили и купили — молодцы. Примечание: к вам это не относится, если вы торгуете и зарабатываете на криптобиржах. Тогда проверяйте сколько душе угодно, это ваша работа.

Я мог бы написать о своем крайне негативном отношении первичного размещения монет («ПРМ» получается), но делать этого на этом канале не буду. Уверен, большинство читателей и так весьма осторожно относяться к ICO и подобным ни к чему не обязывающим инвестициям, как и я. Разве что найдутся такие, которые путем размещения монет пытаются привлечь инвестиции к своим собственным проектам. В таком случае, ай да хитрецы! Но не пытайтесь нас, обычных пользователей, обмануть! Мы-то знаем, что большинство ICO-проектов по своей сути являются аферой, лучше уж купить пачку биткоинов, чем таким вот методом приумножать свой капитал с помощью сомнительных инвестиций.

Канал «Экстраполяция IT» — отдушина от мира криптовалютных криптовалют. Именно поэтому тему блокчена и биткоинов оставляю остальным каналам.

​​

Сегодня в ленте пилотный выпуск рубрики «Полный Аджайл». Напоминаю, что в ней публикуются различные заметки по техпроцессам разработки и в первую очередь не от редакции, а от вас, дорогие читатели. Присылайте ваши мысли и описание ваших техпроцессов мне личным сообщением, ведь такие ценные знания должны быть общим достоянием.

О снижении гибкости управления проекта

Можно желать упростить рабочие процессы программиста до того, что ему ничего не нужно будет делать. Но ведь все проблемы контроля и определения сроков исходят из требований гибкости и постоянного изменения требований. Ведь при каскадной модели мы относительно точно знаем сколько людей с какими навыками нужно для выполнения проекта, так как все процессы делятся на этапе подготовки проекта. С этим в теории просто и понятно.

А когда требования меняются каждый день, то программист должен понимать общую архитектуру проекта, покрывать тестами, рассказывать что да как коллегам. Внедряются новые фреймворки, и хорошо если не нагрузили девопсом. Фронтендеры пишут не только браузерный джаваксрипт, но и серверный слой на nodejs, верстают, работают с моделями баз данных и прочее прочее. То, что по-правильному таких разработчиков нужно назвать «гибридные разработчики» и наверняка вы помните статью об этом.

Одна из сложностей такого подхода — понять, что происходит в соседней команде и при необходимости принять задачу оттуда порой не самый простой момент. Получается, чем менее четкое понимание проекта на старте, тем более универсальны должны быть разработчики и тем больше менеджеров нужно чтобы связывать все структуры. В итоге понятно, что снижать менеджерскую нагрузку по версии разработчика можно пропорционально снижению гибкости проекта. Так себе решение получается, но со стороны программиста выглядит именно так.

Мы стали заложниками того, что проекты запускаются, тестируются и меняются без стратегии, одна тактика.

#полныйаджайл