Работет ли экстремальное програмирование?

Тебе нравится быть клиентом у компаний которые нанимают васянов-фрилансеров?

Fix.

Тебе нравится быть клиентом у компаний которые нанимают фрилансеров?

Ultimate fix.

Тот у кого есть права на это.

Ну вот. В нормальной ситуации они есть у всех.

Тебе нравится быть клиентом у компаний которые дают доступ к проду любому васяну-фрилансеру?

Я не пробовал, но, полагаю, мне не понравится быть клиентом у компаний, которые нанимают всяких васянов.

Если твой патч добавлен в мастер то что тебе еще нужно? Ты что прямо на проде код пишешь?

Нет, конечно. Но я использую прод в работе.

Это был сайт на друпале и вы синкали новый код через ftp?

??? Какая связь?

Ты до сих пор не смог объяснить какие конкретно процессы тормозятся.

Процесс разработки. Он один.

Зачем им это?

Чтобы работать. Быстро и качественно.

Их может лучше удалить вообще.

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

То что у вас запретили деплоить - это прикладывание подорожника к тому факту что у вас все равно можно выкатить говно в прод.

Да, конечно. Потому что тот, кому поручили выкатывать, естественно, не в состоянии проверить, что именно он выкатывает.

в вашем самом лучше в мире коллективе еще один детский антипаттерн - unactionable monitoring

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

Нет, конечно. Но я использую прод в работе.

Зачем ты это делаешь?

??? Какая связь?

Ну обычно если в прод пушат все кому не лень это означает отсутствие какой либо безопасности и низкие риски от поломки прода. То есть какой нибудь говносайт который ни кому не нужен.

Процесс разработки. Он один.

Какой конкретно этап процесса разработки тормозится и по каким причинам?

Меня как-то раз сделали тимлидом над несколькими контракторами (не фрилансерами, они были из аутсорсинговой компании). Нормальные были ребята, способные, умные. Кроме одного, которого я, в итоге, выгнал (ну, формально не я, но инициатива была моя). Некоторые шикарные фишки были именно ими и прикручены.

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

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

Да, конечно. Потому что тот, кому поручили выкатывать, естественно, не в состоянии проверить, что именно он выкатывает.

Скажу больше, как и вообще любой человек. Ну да, выкатываешь и ты конечно ручками прокликаешь все кнопки и за одно в голове будешь держать еще 10 changes которые вкоммитили твои коллеги между двумя релизами. Делать что-то руками под наздором - иллюзия контроля, за которую приходится дорого платить.

Даже без фрилансеров, мне бы не хотелось что бы мои личные данные были доступны кому угодно из компании.

А потом удивляются откуда в инете базы клиентов очередной компании появились…

Ну может на продуктах попроще кто-то может прибежать, прикрутить ногу, рычаг и мигалку сбоку, закончить контракт и идти гулять.

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

Выполни в такой консоли разок «select * from user_data where user=‘Snowden’» и она тебе ничего не выдаст и порекомендует сидеть и никуда не бежать

Зачем ты это делаешь?

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

низкие риски от поломки прода.

Ты так говоришь, как будто это что-то плохое.

Да, у нас были низкие риски от поломки прода (до смены руководства). Потому что 99% пробравшихся в прод багов исправлялись за пару минут выкатыванием предыдущей версии. Это было совершенно шикарно.

Какой конкретно этап процесса разработки

Ты забюрократизировался.

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

То есть у вас еще и прямой доступ к базе прода был?) понятненько…

Ты так говоришь, как будто это что-то плохое.

Нет, просто это говорит о несерьезности твоей работы.

Ты забюрократизировался.

А ты не можешь сформулировать что тебе мешало работать.

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

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

Да.

Может быть специальная консоль, которая хоть и не позволяет выполнить случайный запрос в базу

В принципе, идея неплохая, но у нас таки был прямой доступ в базу. Что, конечно, открывало возможности для «упс», но на моей памяти единственный «упс» за несколько лет был мой — тот самый, о котором я говорил, где звёзды так сошлись, что в результате правильных, разумных действий прод упал на несколько часов.

Прямого ssh в продакшен у нас не было, но было много инструментов, как правило оформленных в виде Дженкинс-джобов. Например, запустить curl с нужными параметрами на продакшен-сервере, или что-то в этом роде.

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

То есть у вас еще и прямой доступ к базе прода был

Был, но одно с другим не связано.

Нет, просто это говорит о несерьезности твоей работы.

Нет, это говорит о хорошей организации.

А ты не можешь сформулировать что тебе мешало работать.

Ходим по кругу: Работет ли экстремальное програмирование? (комментарий)

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

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

Ну твоя претензия понятна, выкатывать в прод долго неприятно.

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

Деплоить не должны люди. Лучше по крону.

Насколько часто? Хм, ну зависит от скорости обнаружения ошибок на подмножества деплоймента. Если у вас ошибки начнут валиться сразу, можно деплоить чуть быстрее. Если у вас сервис в основном спит и баги в коде всплывут через 2 дня, то на весь деплоймент может и нужно пушить 2 недели. При том от медленного пуша будет профит если плохие версии портят данные только в проценте флота куда это задеплоили. Если у вас 1000 инстансов и уже после первого перезагруженого процесса он может насрать так в базу что упадет весь сервис, то это очень плохой глобальный сервис. Медленный пуш ему не похожет

Ну как вариант, главное что бы у всяких Miguel-ей не было доступа к данным клиентов компании.

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

Был, но одно с другим не связано.

О какой серьезной работе можно говорить если у всех есть доступ к базе прода) Нулевая безопасность компании))

Нет, это говорит о хорошей организации.

Нет, это говорит о том что всем насрать что будет с продом)

Ходим по кругу

Ты так и не смог объяснить откуда у тебя получились 2 недели. Распиши по дням плиз, чем тебе приходилось заниматься 10 рабочих дней до момента попадания патча в прод.

то базу восстановят из бэкапа

Ахахахахах

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

Вот именно. Одна из основных фишек у нас была в том, что почти (почти!) любой баг чинился за пару минут. Новое руководство, возможно, сократило количество багов раза в полтора, но зато увеличило время на фикс до недель.

Деплоить не должны люди. Лучше по крону.

Зачем по крону? У нас поначалу было так: ревью прошло — замёржил — выкатил. Зато если оно упало в проде и была задеплоена предыдущая версия — сразу понятно, из-за чего упало и с чего начинать разбираться.

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

Тут может быть, не спорю.

Мне больше не нравится что без аудита. Вообще даже у самого главного демиурга тоже должен быть какой-то косвенный доступ. Иногда получается разграничить так доступ чтобы никто один не мог бесконтрольно получать доступ. Например консоли аудита пишет команда которая не может ей пользоваться. А пользуется ей тот, кто не может менять ее код. Ну и развитие мысли этой, я тут не эксперт

Распиши по дням плиз, чем тебе приходилось заниматься 10 рабочих дней до момента попадания патча в прод.

Мне? Штаны просиживать. И ждать, пока ДРУГИЕ соблаговолят нажать пару кнопок.

Нулевая безопасность компании

Как раз наоборот.

Нет, это говорит о том что всем насрать что будет с продом)

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

то базу восстановят из бэкапа

Ахахахахах

У вас ещё и бэкапов не делают?

Иногда получается разграничить так доступ чтобы никто один не мог бесконтрольно получать доступ.

А иногда нанимают профессионалов, которые хотят делать хорошую работу.

У вас ещё и бэкапов не делают?

Обязательно делают. Это просто последняя мера. Но если вам успешности бизнеса не мешало идти на такой риск и простои то проблем нету.

Нету какого-то абсолютного стандарта надёжности, все тут относительно того чтобы клиенты были довольны в той мере в которой нужно.

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

Это может не удовлетворить например регулятора. «Правительства США и ЕС, мы мамкой клянёмся что мы честные парни». Хер там, у тебя будет по коридорам шнырять аудиторы и смотреть на технические преграды

Мне? Штаны просиживать. И ждать, пока ДРУГИЕ соблаговолят нажать пару кнопок.

Так это у тебя проблемы с общением с людьми. Обычно нужно просто 1-2 раза написать в чат. Если для тебя это сложно то да, работа в коллективе не твое.

Как раз наоборот.

Ага, с доступом к проду))

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

Конечно))

У вас ещё и бэкапов не делают?

Делают, только восстановление из бекапа не мгновенная операция. А во вторых можно наговнять в базе так что сразу и не заметит ни кто.

Это да. Поэтому я и говорю, что в некоторых случаях могу понять ограничение доступа к проду.

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

Разговор мы начали с культуры размазывания ответственности на весь коллектив, мне кажется, это порочная практика.

Размазывание наказания ты хотел сказать

Обычно нужно просто 1-2 раза написать в чат.

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

Конечно

Практика показывает, что так и есть.

Делают, только восстановление из бекапа не мгновенная операция

Разумеется. Вопрос в балансе, как всегда. Один вариант — прямой доступ есть, риск потратить некоторе время на восстановление базы — есть, реально это не случалось вообще ни разу, зато баги фиксятся оперативно. Другой вариант — прямого доступа нет, риск восстановления базы из бэкапа уменьшен (не до нуля), баги фиксятся неделями.

Размазывание наказания ты хотел сказать

Размазывание ответственности. «Наказание» — слишком сильное слово, никто не штрафует и не отнимает бублики.

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

Вот и пытаюсь получить от тебя ответ на вопрос: «Какие?» Потому что в тех конторах где я работал у программистов не было доступа к проду/мастеру и это ни как ни кому не мешало.

Практика показывает, что так и есть.

Фантазии твои показывают что так и есть)

зато баги фиксятся оперативно

Они и так оперативно фиксятся, нету никаких проблем со скоростью работы. Только у тебя что то не так.

Делают, только восстановление из бекапа не мгновенная операция. А во вторых можно наговнять в базе так что сразу и не заметит ни кто.

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

https://en.wikipedia.org/wiki/Service-level_objective

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

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

можно добавить индекс там где он не нужен и из за него будет деградировать время работы инсерта данных.

leave, спасибо! В трекере очень глаза мозолило.

Что именно, слово «работет»?

Какой ты нетерпеливый. Ещё пару дней, и в других словах ошибки поправят.

Вот, кстати: https://yosefk.com/blog/extreme-programming-explained.html

Да-да, XP — это бессмысленный и беспощадный религиозный культ, в лучших традиция манагерства. Но вопросы был все-таки не в этом. Между строк ты можешь прочитать, что мне все-таки не дают покоя лавры деятелей этого культа и я пытаюсь понять причины их успеха. Потому что я понимаю, что где-то там лежит фундамент моего непонимания заказчиков. Если заказчику нравится бесполезные и даже вредные методы организации работы — значит, я должен делать вид, что практикую эти плохие методы программирования, чтобы привлечь внимание заказчика. Вот и весь мой интерес. Естественно, еще при создании этого треда я прекрасно понимал, что XP в этом виде не работает и не может работать: если один бездарь пишет плохой код, и второй бездарь пишет плохой код, то в парном программировании они... тоже напишут плохой код. Но если ты скажешь «у нас интенсивно задействованы методы XP и Agile» — заказчик сразу же готов нести тебе деньги. Даже если программистов в штате у вас нет совсем.

Вот, кстати: https://yosefk.com/blog/extreme-programming-explained.html

О господи, это нереально крутой чел, похоже, я залипну на пару деньков в его блоге, извиняйте. Признавайся, где ты его откопал? Я только нифига не понял, кто он — HR, просто кодер, тимлид? Я ломал голову над вопросом монореп, я вывел плюсы и подчеркнул тот факт, что для монорепы Git не подход (что довольно очевидно, потому что Git много для чего не подходит), но я так и не додумался до проблемы ветвления монорепы и циклических зависимостей — а ведь ни секунды не сомневаюсь, что они возникнут в реальном проекте, потому что самому однажды приходилось долго и нудно чистить зависимости после команды, которое было в полном составе похеру на то, как собирается проект. Ну типа классическое «работает — не трожь» — ага, только трогать его все равно придется, и скоро такими темпами уже ничего работать не будет.

Я кончил и закурил. Я не могу описать это лучше:

http://yosefk.com/c fqa/picture.html#fqa-6.1

«[6.2] Is C++ a perfect language?

...language is „perfect“ because our requirements from a „perfect“ language are inconsistent with each other. So instead of perfection, good languages provide consistency and usability. This can be called „practical“ from the point of view of language users.

C++ is different - it's designed for perfection. Where other languages give you a feature, C++ gives you meta-features. Instead of built-in strings and vectors, it gives you templates. Instead of garbage collection, it gives you smart pointers. This way, you can (theoretically) implement your own „perfect“ (most efficient and generic) strings. In practice, this turns into a nightmare since many different kinds of strings, smart pointers, etc., each perfect in its own way, will not work with each other. C++ sacrifices usability for perfection.

However, despite the obsession with perfection, C++ is „practical“ - from a language designer's perspective rather than from a user's point of view. The „practical“ thing in C++ is that it's based on C. This helped the language gain popularity. This is also the main reason for inconsistencies in the language - ambiguities in the grammar (declaration/definition, type name/object name...), duplications of functionality in the different features (pointers/references, constructors/aggregate initialization, macros/constants/templates, files/namespaces...). C++ sacrifices consistency for popularity. This „practical“ approach helps to increase the number of C++ users, but it doesn't help those users to get their job done.»

В blame free culture считается что ваш процесс наема людей нанял людей с двумя качествами - профессионализм и хорошие намерения. Допустим у вас есть красная кнопка, которая убивает продакшн. Вася ее нажал. Почему профессионал Вася с хорошими намерениями ее нажал? Это же невозможно. Значит кнопка на стуле и нажать ее можно очень легко жопой даже если ты этого не заметил. Уберите кнопку со стула или переместите ее в ящик с тремя ключами. Тогда ее не нажмет случайно больше никто. Или лучше выдать Васе 100 розг? А потом Грише 100 розг? И так каждому последующему работнику заново

Я всеми руками за, но это полумеры. Нажал жопой на красную кнопку Вася потому, что писал на C++, где такая ситуация является нормой. Идём переписывать код с питона и C++ на норм языки?

Я бы назвал эту расширенную форму не blame-free, а «культура поиска первопричины» или ещё менее популярная «культура использования мозга вместо формальных инструкций». Если причина заключается в том, что Вася систематически не читает доки, чужой и даже свой код, сует костыли и отлынивает от работы — проблема в Васе и Васю нужно выгнать. Если Вася допустил ошибку потому, что инструмент подталкивает к написанию ошибок — тогда проблема в инструменте и, возможно, в недостаточном уровне владения онным Васей. В последнем случае нужно доучивать Васю.

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

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

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

Это случайно не называлось CMM?

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

А почему руководство-то сменилось? Если всё работает, то, по идее, у верховных руководителей не должно возникать вопросов.

Что именно, слово «работет»?

Я сейчас просто заржал. Я сам не заметил этой опечатки, и граммар наци тоже не заметили, но зато экстремальность почему-то «глаза мозолит». Это как одна моя знакома мадам, которая допускает пять ошибок в предложении, но зато «французский» пишет безупречно.

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

По-моему это было актуально когда только появились i286 и компьюютеров на всех не хватало :).

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

Кнут допустим как исключительная мера, но если часто ею пользоваться, то она теряет силу.

Опыт веков подсказывает что вы не правы.

KMK ты смешиваешь 2 разные вещи:

1. Особенности конкретного человека. Знаешь, иногда ведь дешевле заменить, если есть альтернативы.
2. Плотные опенспейсы - зло для всех, а не для кого-то конкретного.