А как же всё сделать с первого раза без багов и тестирования?
За 100 тысяч миллионов каждый сможет. Вот вам крошка от рекламного бюджета и сроки до завтра.
Ееее! Пять деняк!!
Ну шо? Уже готово? А когда будет готово? А почему не готово? А может быть готово? Посмотри, готово или нет? А сейчас?
это не про программистов. во всяком случае, не в нормальных компаниях. программистам похуй "как у них", у программиста есть геймдиз который скажет что делать и даст четкую задачу. ну или как в мандфише - нахуй не нужны эти геймдизы, сделай всё как у них прост. но это н наример нормальной компании
Большая часть гейдева - повторение одной и той же херни которую ранее сделали чуваки покруче
...за мало деняк и с адскими переработками
Всё так. Особенно, проклятые мобильные донатные дрочильни
мне казалось что кодеры в мобильный геймдев идут делать дрочильны только ради опыта делать такое. и насчет мало деняк - вопрос очень спорный. с одной стороны конечно в не игровой разработке может платят и лучше. а с другой - в проклятых мобильных донатных дрочильнях можно просто 3 года переходя с одного рабочего места на другое использовать один и тот же свой код. у меня есть пример пары чуваков которые на 85% реюзают на следующих рабочих местах вещи которые разрабатывали когда работали со мной 4 года назад. и по факту получают нормальные деньги за то что делают минимум.
стат такой то = достали значение из базы/файл/объекта, прибавили еще одно из другого объекта(стат есть? статвалью : 0), еще одного из другого объекта, еще одного из другого объекта, еще одного из другого объекта, (еще 5-10 итераций)
стат следующий - достали значение...
Для простенького дьяблоида таких статов будет например десятка полтора-два.
Это для гейм-дезайнеров, левел-дизайнеров, сценаристов - разнообразие. Для кодеров - немножко примитивных алгоритмов, немножко математики редко превышающей 7ой класс школы, и этого барахла - как кирпичей в человейнике.
стат следующий - достали значение...
Для простенького дьяблоида таких статов будет например десятка полтора-два.
Это для гейм-дезайнеров, левел-дизайнеров, сценаристов - разнообразие. Для кодеров - немножко примитивных алгоритмов, немножко математики редко превышающей 7ой класс школы, и этого барахла - как кирпичей в человейнике.
чуть расширю - нет, конечно бывает над чем подумать надо, типа алгоритма Дейкстры с А* оптимизацией для хорошего патфайндинга, но это делается один раз, приделывается к клику по карте и всё.
Ну или если это герое-образная стратегия - прописать все фазы боя в первый раз, есть над чем подумать. Но в итоге оно сводится к стейтмашине, которая крутиться в своих 5-7 стейтах внутри одного While и содержит некоторое количество IF-ов.
Еще в Искуственном Идиоте врагов бывает что-то интересное: но в конечном итоге он сводится либо к проверке эффективности постука сферического в вакууме одног, либо с моделированием боя наперед (ога, внутри боя ИИ думает ровно тем же алгоритмом, который используется для автобоя. А сложность игры регулирует на сколько ходов вперед он это смоделирует)
Ну или если это герое-образная стратегия - прописать все фазы боя в первый раз, есть над чем подумать. Но в итоге оно сводится к стейтмашине, которая крутиться в своих 5-7 стейтах внутри одного While и содержит некоторое количество IF-ов.
Еще в Искуственном Идиоте врагов бывает что-то интересное: но в конечном итоге он сводится либо к проверке эффективности постука сферического в вакууме одног, либо с моделированием боя наперед (ога, внутри боя ИИ думает ровно тем же алгоритмом, который используется для автобоя. А сложность игры регулирует на сколько ходов вперед он это смоделирует)
Нда.. стагнировал на старой работе где сижу говнокодером. Стал искать новую, и выяснил, что отстал от всех современных вещей - А вы знаете церемонии Аджайл? - Шта? А вы конечно покрываете всю работу юнит-тестами? Паттернов придерживаетесь строго? - Нет, звонит заказчик, говорит сделать задание вчера, и я спотыкаясь бегу делать как получится.
И т.д..
И т.д..
Большая часть компаний - говно
Предположу, что ты работал в банках, окологосухах или когда проект начинается от тз и закачивается сдачей заказчику.
То есть, или нет бесконечного цикла внедрения новых фичей богу фичей или факап слишком дорого выйдет.
В аналитике, например, цена ошибки не настолько высока, поэтому часто жертвуют многим ради меньшего ТТМ.
То есть, или нет бесконечного цикла внедрения новых фичей богу фичей или факап слишком дорого выйдет.
В аналитике, например, цена ошибки не настолько высока, поэтому часто жертвуют многим ради меньшего ТТМ.
Кто ж спорит
если у тебя старый проект, которому 20+ лет который работает еще на какой-нибудь 8ой джаве, или написан на С под старую архитектуру, у которого 300+ тыщ строк кода, и он обслуживает миллионы клиентов и при этом стабильно работает
его в большинстве случаев не будут переписывать на новые технологии, это супер-дорого
его в большинстве случаев не будут переписывать на новые технологии, это супер-дорого
Если он на восьмой джаве, значит, ему не 20 лет.
Или его как минимум переделывали на восьмую джаву.
Или его как минимум переделывали на восьмую джаву.
В восьмерке были какие-то серьезные изменения? А то может рантайм поменяли, запустили и типа пусть работает.
Я в мире дотнета таких видел много лет назад - взяли .NET 2.0 код, перекомпилировали и запустили под .NET Core. И в итоге код типа как на .NET Core работает, а по факту никаких возможностей новой платформы не использует.
Я в мире дотнета таких видел много лет назад - взяли .NET 2.0 код, перекомпилировали и запустили под .NET Core. И в итоге код типа как на .NET Core работает, а по факту никаких возможностей новой платформы не использует.
Стримы, опционалы, предикаты, ещё дофига всего по мелочи.
https://habr.com/ru/articles/216431/
Сразу видно, что ты не джавист, иначе бы такого дурацкого вопроса не задавал.
https://habr.com/ru/articles/216431/
Сразу видно, что ты не джавист, иначе бы такого дурацкого вопроса не задавал.
Если у тебя старый проект и там ничего трогать не надо, то тебе и программисты не нужны
Если у тебя старый проект, но там нужны изменения, и ты их делаешь без тестов - хуйня затея
Если у тебя архитектура проекта такая, что ты не можешь добавить тесты без переписывания всего проекта - у тебя технический долг
Если ты по крайней мере не думаешь про то, как решить технический долг - ты говнокомпания
Так что как ни крути, если про тесты ты слышишь только на собеседовании - вероятно, ты в говнокомпании
Если у тебя старый проект, но там нужны изменения, и ты их делаешь без тестов - хуйня затея
Если у тебя архитектура проекта такая, что ты не можешь добавить тесты без переписывания всего проекта - у тебя технический долг
Если ты по крайней мере не думаешь про то, как решить технический долг - ты говнокомпания
Так что как ни крути, если про тесты ты слышишь только на собеседовании - вероятно, ты в говнокомпании
Звучит прямо как девиз
юнит тесты писать тестировщику? вообще не представляю, как это может работать
Тут может быть обратная реакция - если везде суешь свои паттерны, надо и не надо - то иди нафиг.
В соседнем отделе одного такого послали, после того, как он заявил на требование начальника добавить какую-то фичу - "не могу, паттерн такое не позволяет". И мне самому приходилось упрощать и оптимизировать код после таких любителей совать паттерны туда, где без них сделать проще и быстрее.
В соседнем отделе одного такого послали, после того, как он заявил на требование начальника добавить какую-то фичу - "не могу, паттерн такое не позволяет". И мне самому приходилось упрощать и оптимизировать код после таких любителей совать паттерны туда, где без них сделать проще и быстрее.
Скорее всего там не паттерны виноваты были, а то что он так код написал, что вот эта ебучая новая фича туда не ложилась ну никак! И всё надо переписывать (уже с другими паттернами).
А ему лениво. Но не скажешь же начальнику, что не хочешь из-за лени =)
К слову, паттерны - это в первую очередь про безболезненное добавление функционала в существующий код. Так что если в его код новая фича никак не страивается, значит не это не паттерны виноваты, это его косяк проектирования, что он не предусмотрел расширение в эту сторону.
Да, я в курсе, это это умение из разряда телепатии, но тем не менее, всё равно важно понимать, где и в каких местах тебе могут докинуть фичей, чтобы не пришлось потом всё переписывать. Считаю, это качество - одно из основных, что отличает опытного разраба от не очень опытного.
Не знание миллиона технологий. А умение понять, что нужно бизнесу, куда двигается проект и какие фичи в него вскоре добавятся. И писать текущий код для текущих ТЗ с учетом этого понимания. Тогда и для новых фичей будет ответ не "ой, мы так не можем", а "конечно без проблем, у нас уже для этого всё предусмотрено", именно это бизнесу и нужно!
А ему лениво. Но не скажешь же начальнику, что не хочешь из-за лени =)
К слову, паттерны - это в первую очередь про безболезненное добавление функционала в существующий код. Так что если в его код новая фича никак не страивается, значит не это не паттерны виноваты, это его косяк проектирования, что он не предусмотрел расширение в эту сторону.
Да, я в курсе, это это умение из разряда телепатии, но тем не менее, всё равно важно понимать, где и в каких местах тебе могут докинуть фичей, чтобы не пришлось потом всё переписывать. Считаю, это качество - одно из основных, что отличает опытного разраба от не очень опытного.
Не знание миллиона технологий. А умение понять, что нужно бизнесу, куда двигается проект и какие фичи в него вскоре добавятся. И писать текущий код для текущих ТЗ с учетом этого понимания. Тогда и для новых фичей будет ответ не "ой, мы так не можем", а "конечно без проблем, у нас уже для этого всё предусмотрено", именно это бизнесу и нужно!
Ну может он на синглтонах (а что, тоже паттерн!) все нарисовал. Тогда действительно может быть что "паттерн не позволяет". А так по моему хорошо спроектированный код как-то сам по себе начинает SOLID отвечать. Да и остальные паттерны, если они к месту, очень даже полезны. А вот понимание когда они к месту, а когда нет - вот это и есть основное отличие сеньора от миддла
Вспомнил одного сектанта, который сразу с собеса начал нам всем затирать, какой охуенный паттерн MVVM, стильно, модно, молодёжно, давайте я вам весь код на MVVM перепишу.
Ему дали проект, который была нужда переписывать, со словами: если ты сумеешь свой сраный MVVM натянуть на ту архитектуру, которая в этом проекте нужна (а это данные с датчиков и расчёты по этим данным), то флаг в руки. Он нихуя не смог. Написал интерфейс (который бесполезен без тонны расчётов, которые он так и не сделал) и съебал из конторы через пару месяцев. Мы его прозвали аферистом.
Ему дали проект, который была нужда переписывать, со словами: если ты сумеешь свой сраный MVVM натянуть на ту архитектуру, которая в этом проекте нужна (а это данные с датчиков и расчёты по этим данным), то флаг в руки. Он нихуя не смог. Написал интерфейс (который бесполезен без тонны расчётов, которые он так и не сделал) и съебал из конторы через пару месяцев. Мы его прозвали аферистом.
Ну если тело начало писать интерфейс (MVVM - это все таки больше UI) вместо ядра системы - то есть 3 варианта:
1. Он таки баран
2. Баран таки PM, который на дал нормальные требования
3. Изначальный код был таким говном, что его переписать было неподьемной задачей
1. Он таки баран
2. Баран таки PM, который на дал нормальные требования
3. Изначальный код был таким говном, что его переписать было неподьемной задачей
PM в конторе отсутствовал как класс. Можно сказать, в его роли выступил гендир, который купился на россказни афериста про "стильно, модно, молодёжно". Предупреждая следующий вопрос: тимлида, который бы следил, что там этот аферист вообще пишет, тоже не было. Один раз аферист для гендира устроил презентацию промежуточного результата своей работы, на эту презентацию согнали весь отдел, и естественно, ничего, кроме интерфейса, он не показал.
Изначальный код действительно был говном, поэтому и встала задача переписывать всё с нуля. Изначальный код был на делфе (а переписывать надо было на шарпе), но это ещё не самое главное. Самое главное - был утверждённый документ с формулами, по которым делались расчёты, но формулы эти заведомо неправильные, и переделывать алгоритмы расчётов надо было с учётом того, что датчики привирают, а отказаться от этих датчиков/заменить их нельзя, потому что они вмурованы в бетон. Старая программа на делфе при помощи каких-то хитрых алгоритмов выдавала более-менее вменяемые данные.
В целом задача это такая, что человеку ниже сеньора её не доверишь, и один сеньор (человек, ранее работавший в конторе и сопровождавший программу на делфе) оценил время переделки в год. Аферист предложил меньше, поэтому гендир его и взял.
И ещё раз повторю: MVVM там нахуй не нужон, MVVM это хуйня для веба, просто чтобы пересылать данные между интерфейсом и базой, а тут ядро системы - алгоритмы расчёта, которые в схему MVVM не укладываются вообще.
Изначальный код действительно был говном, поэтому и встала задача переписывать всё с нуля. Изначальный код был на делфе (а переписывать надо было на шарпе), но это ещё не самое главное. Самое главное - был утверждённый документ с формулами, по которым делались расчёты, но формулы эти заведомо неправильные, и переделывать алгоритмы расчётов надо было с учётом того, что датчики привирают, а отказаться от этих датчиков/заменить их нельзя, потому что они вмурованы в бетон. Старая программа на делфе при помощи каких-то хитрых алгоритмов выдавала более-менее вменяемые данные.
В целом задача это такая, что человеку ниже сеньора её не доверишь, и один сеньор (человек, ранее работавший в конторе и сопровождавший программу на делфе) оценил время переделки в год. Аферист предложил меньше, поэтому гендир его и взял.
И ещё раз повторю: MVVM там нахуй не нужон, MVVM это хуйня для веба, просто чтобы пересылать данные между интерфейсом и базой, а тут ядро системы - алгоритмы расчёта, которые в схему MVVM не укладываются вообще.
Аджайлу уже лет этак 23, в нашей стране этак 16.
Сейчас обычно тебе про SOLID и SCRUM заливают.
В целом "звонит заказчик и говорит сделать вчера, а ты делаешь как получится" и есть Agile, потому что на бумаге всё красиво на деле, как всегда обосрались.
Паттерны обычно никто строго не придерживается, но хотя бы обзор их знать нужно. Например если ты Java раб, то хотя бы интерфейсы осознавать.
В юнит тестах ничего сложного нет, их и макака написать сумеет.
Отстать можно по стеку разве что нынче, но если как бы потратить месяцок вечеров часа по 2-3 на то чтобы поделать туториалы и попробовать решить задачки, то и это не проблема.
Сейчас обычно тебе про SOLID и SCRUM заливают.
В целом "звонит заказчик и говорит сделать вчера, а ты делаешь как получится" и есть Agile, потому что на бумаге всё красиво на деле, как всегда обосрались.
Паттерны обычно никто строго не придерживается, но хотя бы обзор их знать нужно. Например если ты Java раб, то хотя бы интерфейсы осознавать.
В юнит тестах ничего сложного нет, их и макака написать сумеет.
Отстать можно по стеку разве что нынче, но если как бы потратить месяцок вечеров часа по 2-3 на то чтобы поделать туториалы и попробовать решить задачки, то и это не проблема.
«звонит заказчик и говорит сделать вчера, а ты делаешь как получится»
К счастью, в больших компаниях можно выбить себе больше авторитета и слать таких чертей в йух, потому что вертели мы всей командой делать херню которая, во-первых, скорее всего, не нужна, во-вторых, идёт поперёк процессов. У всех горит, всем надо вчера. Настоящие же срочные задачи приносит лид всей разработки. Когда разрабов мало, а задач много, можно стравливать бизнес между собой за право принести тебе задачку.
> В целом "звонит заказчик и говорит сделать вчера, а ты делаешь как получится" и есть Agile, потому что на бумаге всё красиво на деле, как всегда обосрались.
Это не обосрались, это литералли Agile. Его изначально делали и продвигали, как противовес Waterfall, где ты на 5 лет вперёд спланировал разработку, а пока делал - конкуренты вывели продукт на рынок, требования поменялись, а те что ещё не поменялись - не имеют к реальности никакого отношения.
В какой-то момент появилось понимание, что не во всех областях это круто работает, и выкатили несколько практик, в которой центральная идея - сделать то что нужно заказчику и потребителю, а сбоку подвешены ритуалы, которые не дают процессу развалиться в хлам, и добавляют немножко предсказуемости.
Это не обосрались, это литералли Agile. Его изначально делали и продвигали, как противовес Waterfall, где ты на 5 лет вперёд спланировал разработку, а пока делал - конкуренты вывели продукт на рынок, требования поменялись, а те что ещё не поменялись - не имеют к реальности никакого отношения.
В какой-то момент появилось понимание, что не во всех областях это круто работает, и выкатили несколько практик, в которой центральная идея - сделать то что нужно заказчику и потребителю, а сбоку подвешены ритуалы, которые не дают процессу развалиться в хлам, и добавляют немножко предсказуемости.
Это литералли обосрались и херовый ПМ. Если заказчик звонит напрямую разработчику и говорит что надо что-то сделать - то это не аджайл, это балаган.
Это задача менеджера - общаться с заказчиком.
И как ни странно, тогда все делается быстрее, и зкаказчик довольнее. Потому что как минимум "заказчик" - это обычно не один человек, а какое-то предприятие, с разными отделами и иногда порлитической грызней между ними.
Это задача менеджера - общаться с заказчиком.
И как ни странно, тогда все делается быстрее, и зкаказчик довольнее. Потому что как минимум "заказчик" - это обычно не один человек, а какое-то предприятие, с разными отделами и иногда порлитической грызней между ними.
Или заказчик звонит напрямую гендиру, гендир без анализа спускает задачу менеджеру, макака-менеджер тоже без анализа спускает задачу разработчику (попутно выясняя, какой разработчик вообще работает над этим сервисом, ибо сам менеджер этого не знает и не считает нужным знать).
У меня так было.
У меня так было.
Звечит как адская говноконтора-соковыжималка. Или 1с-франчайзи, что в принципе то же самое.
Не, не 1с, веб-сервисы на джаве. Просто контора застряла в стадии стартапа на много лет.
Я в итоге оттуда благополучно съебался.
Я в итоге оттуда благополучно съебался.
А на практике в большинстве случаев возникает методология разработки под названием "скрамопад", сочитающая ритаулы аджайла с гибкостью водопада. (Нет, я, конечно, утрирую, никто не делает N месяцов проектирования, N месяцов разработки, N месяцов тестов и N месяцов деплоя, как этого требует классический водопад).
Вы команда. Вы зависите от K команд и еще M команд зависят от вас. Менеджеры, лиды, PMы и прочие черти собираются на шабаш и проводят свои темные ритуалы под названием "планируем релиз". В результате высирают расписание чо когда кому даёт свои deliverables.
Я тут где-то пропустил такой момент, что иногда ты нихера не знаешь, сколько времени надо делать фичу X, и чтобы это выяснить, тебе нужно потратить некое количество времени и произвести некие исследования. Когда великие боги расписания релизов не дают тебе времени, то производится оценка по методолгии "хер к носу".
Вы начинаете хуярить спринты.
В расово верном аджайле каждый юзер сторис дает атомарный deliverable и value заказчику, а каждый спринт - законченный отрезок работы. И можно депллоить, блять. Смешно, никогда такого не видел. Зачастую поебать и крупная задача (эпик) плюс-минус нарезается на юзерстори, но зачастую половина сделанных юзерсторей не имеет никакого смысла без второй половины.
Также в расово верном аджайле разраб способен хуярить не приходя в сознание, без исследований, проектирований и архитектур. Потому что подумать - это не deliverable. Нам было поебать, когда вещи нетривиальные, у нас иногда были целые юзерстори на подумать.
В какой-то момент вы обсираетесь. Методолгия оценки "хрен к носу" дала ошибку. Задача оказалось сложнее, чем ты думал. Разработчики оказались более ебланами. Или обосрался кто-то другой и входящие зависимости не успевают подвести в срок. Короче, задача растягивается. Одна, вторая, третья и так далее. Что это за звуки? Это трещит распсание релизов. Вместе с ним начинает трещать жопа у PMа, чтобы придумать, как всё все сделать, что надо (а всё надо!), а что надо чуть поменьше, и можно выкинуть.
Обосраться недостаточно. У нас же гибкие разработки. В какой-то момент к PM, менеджеру и прочим чертям приходят черти из других команд и говорят, что им очень, очень очень очень нужна фича Y. Но фичи A, B, C, которые мы запланировали на релиз и которые не успеваем, конечно же, тоже нужны. Крч, ебашьте. См. пикчу.
Чем реже релизы, тем сложнее шабаш, тем выше риск обосраться. При всем уважении к всяким веберам, наши релизы чаще всего поставляются в виде tar.gz всяким другим разработчикам, поэтому мы не CI/CD gonna brrr и катить релиз каждые два дня из мастера. (Это не значит, что CI и тестов нет) А если ваши релизы зашиваются в железо, то это еще больнее.
Вы команда. Вы зависите от K команд и еще M команд зависят от вас. Менеджеры, лиды, PMы и прочие черти собираются на шабаш и проводят свои темные ритуалы под названием "планируем релиз". В результате высирают расписание чо когда кому даёт свои deliverables.
Я тут где-то пропустил такой момент, что иногда ты нихера не знаешь, сколько времени надо делать фичу X, и чтобы это выяснить, тебе нужно потратить некое количество времени и произвести некие исследования. Когда великие боги расписания релизов не дают тебе времени, то производится оценка по методолгии "хер к носу".
Вы начинаете хуярить спринты.
В расово верном аджайле каждый юзер сторис дает атомарный deliverable и value заказчику, а каждый спринт - законченный отрезок работы. И можно депллоить, блять. Смешно, никогда такого не видел. Зачастую поебать и крупная задача (эпик) плюс-минус нарезается на юзерстори, но зачастую половина сделанных юзерсторей не имеет никакого смысла без второй половины.
Также в расово верном аджайле разраб способен хуярить не приходя в сознание, без исследований, проектирований и архитектур. Потому что подумать - это не deliverable. Нам было поебать, когда вещи нетривиальные, у нас иногда были целые юзерстори на подумать.
В какой-то момент вы обсираетесь. Методолгия оценки "хрен к носу" дала ошибку. Задача оказалось сложнее, чем ты думал. Разработчики оказались более ебланами. Или обосрался кто-то другой и входящие зависимости не успевают подвести в срок. Короче, задача растягивается. Одна, вторая, третья и так далее. Что это за звуки? Это трещит распсание релизов. Вместе с ним начинает трещать жопа у PMа, чтобы придумать, как всё все сделать, что надо (а всё надо!), а что надо чуть поменьше, и можно выкинуть.
Обосраться недостаточно. У нас же гибкие разработки. В какой-то момент к PM, менеджеру и прочим чертям приходят черти из других команд и говорят, что им очень, очень очень очень нужна фича Y. Но фичи A, B, C, которые мы запланировали на релиз и которые не успеваем, конечно же, тоже нужны. Крч, ебашьте. См. пикчу.
Чем реже релизы, тем сложнее шабаш, тем выше риск обосраться. При всем уважении к всяким веберам, наши релизы чаще всего поставляются в виде tar.gz всяким другим разработчикам, поэтому мы не CI/CD gonna brrr и катить релиз каждые два дня из мастера. (Это не значит, что CI и тестов нет) А если ваши релизы зашиваются в железо, то это еще больнее.
Только чур мух с котлетами не смешивать. Весь аджайл про то что цель бизнеса — делать деньги, цель разработки — помогать бизнесу делать задачи, и надо не долбиться в мозг, а придерживаться более-менее вменяемого процесса разработки, но реагировать на нужды бизнеса. Всё.
Вот эти все спринты, атомарность, деливереблы и прочее звучит как скрам, и я видал хорошую реализацию скрама, но обычно скатывается всё в крайность - или упёртый жесткий "мы наапланировали и менять ничего не будем даже если бизнес сгорит", или козацкая вольница с плавающей длиной спринтов, вкидыванием-выкидыванием всего мира на ходу, и прочие фокусы с шляпой и зайцами. Что, опять же, идеалам аджайла "в целом" не противоречит, но и там и там приводит к неудобствам в долговременной перспективе.
Классика реальной аджайл разработки - разного рода скрамбаны (помесь скрама с канбаном), где есть общая цель и эпиков на полгода-год вперёд, ближайшие месяца три расписаны в виде примерных сторей, а дальше фиксированые спринты, и работа по беклогу. При чём спринты, по большому счёту, особо не нужны, но Аджайл это Скрам, и надо его чтить, надо так, ну. Можно KPI прикидывать на отрезке, но опять же, это и без спринтов можно было бы делать. Иногда к ним релизы подвязаны (отголоски того самого "скрамопада", особенно во всяких регулируемых областях).
А по большому счёту, чем бы дитя не тешилось, лишь бы было эффективно и предсказуемо. Одной мерки на всех не сделаешь, каждый подгоняет Аджайл под себя, и живёт счастливо. Или страдает, если пытается делать точно по букве какой-нибудь книжечки.
Вот эти все спринты, атомарность, деливереблы и прочее звучит как скрам, и я видал хорошую реализацию скрама, но обычно скатывается всё в крайность - или упёртый жесткий "мы наапланировали и менять ничего не будем даже если бизнес сгорит", или козацкая вольница с плавающей длиной спринтов, вкидыванием-выкидыванием всего мира на ходу, и прочие фокусы с шляпой и зайцами. Что, опять же, идеалам аджайла "в целом" не противоречит, но и там и там приводит к неудобствам в долговременной перспективе.
Классика реальной аджайл разработки - разного рода скрамбаны (помесь скрама с канбаном), где есть общая цель и эпиков на полгода-год вперёд, ближайшие месяца три расписаны в виде примерных сторей, а дальше фиксированые спринты, и работа по беклогу. При чём спринты, по большому счёту, особо не нужны, но Аджайл это Скрам, и надо его чтить, надо так, ну. Можно KPI прикидывать на отрезке, но опять же, это и без спринтов можно было бы делать. Иногда к ним релизы подвязаны (отголоски того самого "скрамопада", особенно во всяких регулируемых областях).
А по большому счёту, чем бы дитя не тешилось, лишь бы было эффективно и предсказуемо. Одной мерки на всех не сделаешь, каждый подгоняет Аджайл под себя, и живёт счастливо. Или страдает, если пытается делать точно по букве какой-нибудь книжечки.
> где есть общая цель и эпиков на полгода-год вперёд, ближайшие месяца три расписаны в виде примерных сторей
А как всякие входящие и исходящие зависимости разруливаются?
> А по большому счёту, чем бы дитя не тешилось, лишь бы было эффективно и предсказуемо. Одной мерки на всех не сделаешь, каждый подгоняет Аджайл под себя, и живёт счастливо.
Ну с этим я согласен. Иногда получается и живёт счастливо, а иногда происходит рак.
А как всякие входящие и исходящие зависимости разруливаются?
> А по большому счёту, чем бы дитя не тешилось, лишь бы было эффективно и предсказуемо. Одной мерки на всех не сделаешь, каждый подгоняет Аджайл под себя, и живёт счастливо.
Ну с этим я согласен. Иногда получается и живёт счастливо, а иногда происходит рак.
Костяк юнитов сейчас прекрасно пишется при помощу GitHub Copilot (*). Он прямс хорошо базовый код рисует, остается только перепроверить и местами тесткейзы добавить.
(*) Только код должен быть не совсем говно
(*) Только код должен быть не совсем говно
Ну хреначит он иногда откровенную ересь. Как минимум путает типы данных. Но я ленивый и тупой, и за помощь в мокании всё равно благодарен
Копропилот сливает данные всем подряд, нарушая корпоративную тайну.
Или это строка из какого-то открытого репозитория (например Ozon Tech), на котором нейросеть обучали.
Кстати, ребята из Ozon эту таску уже никогда не доделают, у них Жира заблокирована.
Кстати, ребята из Ozon эту таску уже никогда не доделают, у них Жира заблокирована.
> у них Жира заблокирована
Откуда знаешь? Более вероятно, что у тебя прав нет, потому что ты в озоне не работаешь.
Откуда знаешь? Более вероятно, что у тебя прав нет, потому что ты в озоне не работаешь.
Новость от 8 августа 2023 года:
Разработчик программного обеспечения Atlassian (Trello, Jira и др.) начнет отключать от сервисов учетные записи, зарегистрированные из России и Белоруссии. Об этом компания сообщила в рассылке для пользователей (есть в распоряжении «Ъ»).
Российские и белорусские аккаунты будут отключены от сервисов компании в течение 30 дней после получения уведомления. «Мы связываемся с вами, чтобы сообщить, что Atlassian сворачивает свою деятельность в России и Белоруссии»,— сказано в рассылке пользователям.
Разработчик программного обеспечения Atlassian (Trello, Jira и др.) начнет отключать от сервисов учетные записи, зарегистрированные из России и Белоруссии. Об этом компания сообщила в рассылке для пользователей (есть в распоряжении «Ъ»).
Российские и белорусские аккаунты будут отключены от сервисов компании в течение 30 дней после получения уведомления. «Мы связываемся с вами, чтобы сообщить, что Atlassian сворачивает свою деятельность в России и Белоруссии»,— сказано в рассылке пользователям.
Ну вот потому и спрашивают, чтобы люди учились. И не было такого идиотского представления.
Юнит тесты надо уметь писать, а не думать, что это легко. Если не писал, то это плохо. Или вот про то, что заказчик хочет. Пусть заказчик опишет требования и приоретизирует задачу. Команда ее оценит. И у заказчика будет представление, сколько это занимает времени и что остальные задачи придется отложить. Часто людей бесит неопределенность, а не сама задержка.
Юнит тесты надо уметь писать, а не думать, что это легко. Если не писал, то это плохо. Или вот про то, что заказчик хочет. Пусть заказчик опишет требования и приоретизирует задачу. Команда ее оценит. И у заказчика будет представление, сколько это занимает времени и что остальные задачи придется отложить. Часто людей бесит неопределенность, а не сама задержка.
Юнит тесты это зачастую не более чем сверка входа и выхода зафиксированного ожидаемого результата.
На деле практически никогда они особо не пригождаются, потому что устаревают раньше времени.
Смысл они имеют только при Test Driven Development парадигме, когда ты пишешь тест раньше фичи, но эта концепция явно не для всех.
Поэтому эти ваши "надо уметь писать" это всё хуйня от тестировщиков.
Юнит тесты пишутся либо в середине разработки для отладки процессов, либо в конце разработки блока для фиксации результата.
Описание требований от заказчика и приоритизация задачи это тоже смешная история. Большинство заказчиков нихуя в этом вашем ИТ не понимает и редко даже может описать что им конкретно нужно. Поэтому все от менеджеров до техлидов ебутся с их хотелками приземляя их на землю.
Был потенциальный заказчик, который хотел систему, которая выдаст ему патенты и схемы и процесс изготовления по заданному в поиске изделию - аля, ввёл boeing 747 и получил все тех данные, чертежи и пошагово как на заводе слепить и чтобы всё с ИИ!!. Откуда брать схемы изготовления заказчик конечно же не уточнил.
Про "остальные задачи придётся отложить" тоже смешное. Бизнес в России живёт по принципу - набрать заказов чтобы делать их несколько лет, потому что потом денег может не быть. Поэтому одна команда может параллельно делать несколько проектов.
Людей не бесит неопределённость, потому что они являются её причиной. Их бесит как раз таки задержка и недопонимание почему в этом вашем ИТ за ваши ахуевшие деньги так долго всё делают. А то что он хуйни наворотил в своём ТЗ его особо не коробит.
На деле практически никогда они особо не пригождаются, потому что устаревают раньше времени.
Смысл они имеют только при Test Driven Development парадигме, когда ты пишешь тест раньше фичи, но эта концепция явно не для всех.
Поэтому эти ваши "надо уметь писать" это всё хуйня от тестировщиков.
Юнит тесты пишутся либо в середине разработки для отладки процессов, либо в конце разработки блока для фиксации результата.
Описание требований от заказчика и приоритизация задачи это тоже смешная история. Большинство заказчиков нихуя в этом вашем ИТ не понимает и редко даже может описать что им конкретно нужно. Поэтому все от менеджеров до техлидов ебутся с их хотелками приземляя их на землю.
Был потенциальный заказчик, который хотел систему, которая выдаст ему патенты и схемы и процесс изготовления по заданному в поиске изделию - аля, ввёл boeing 747 и получил все тех данные, чертежи и пошагово как на заводе слепить и чтобы всё с ИИ!!. Откуда брать схемы изготовления заказчик конечно же не уточнил.
Про "остальные задачи придётся отложить" тоже смешное. Бизнес в России живёт по принципу - набрать заказов чтобы делать их несколько лет, потому что потом денег может не быть. Поэтому одна команда может параллельно делать несколько проектов.
Людей не бесит неопределённость, потому что они являются её причиной. Их бесит как раз таки задержка и недопонимание почему в этом вашем ИТ за ваши ахуевшие деньги так долго всё делают. А то что он хуйни наворотил в своём ТЗ его особо не коробит.
Если у тебя тесты устаревают - то это плохие тесты. Или у тебя большие проблемы в коде.
Их основное предназначение - гарантировать что при внесении изменений в код ты ничего не ломаешь.
Их основное предназначение - гарантировать что при внесении изменений в код ты ничего не ломаешь.
Ну вообще-то устаревание тестов - это нормальный процесс, когда правишь код. Потому что тесты тоже надо править вслед за кодом, который они тестируют.
Ну если ты правишь код и тебе надо править тесты - то надо подумать не творишь ли ты хуйню. Особенно если надо править тесты на поведение методов, которые вызываются другими методами.
Ну если у тебя тесты, которые не устаревают, то это явно проверка на то что функция возвращает не None.
Возможно ты конечно один из тех надмозгов, который полтора месяца проектирует функцию, которую потом надо переписывать или вокруг которой надо костыли писать, но тогда бог тебе судьба.
Возможно ты конечно один из тех надмозгов, который полтора месяца проектирует функцию, которую потом надо переписывать или вокруг которой надо костыли писать, но тогда бог тебе судьба.
насчёт тестов - жизненно
большинство тестов тупо фиксируют ту функциональность, что есть, а не описывают, какой она должна быть. со всеми костылями и косяками. а потом еще это "согласует буизнес" и не смей это тронуть - сразу вой поднимается
и это даже не самое плохое. бывает, что то, что тестится, оно всё замокано, ни крупицы продового кода в тестах не юзается - хороши тесты!
на текущем проекте мне даже попадались тесты вида assertTrue(true)
большинство тестов тупо фиксируют ту функциональность, что есть, а не описывают, какой она должна быть. со всеми костылями и косяками. а потом еще это "согласует буизнес" и не смей это тронуть - сразу вой поднимается
и это даже не самое плохое. бывает, что то, что тестится, оно всё замокано, ни крупицы продового кода в тестах не юзается - хороши тесты!
на текущем проекте мне даже попадались тесты вида assertTrue(true)
>тесты тупо фиксируют ту функциональность, что есть, а не описывают, какой она должна быть
Так ведь если так не делать, тесты будут красненькие и в панамку хуев напихают. А релиз надо выпускать уже завтра! Ну и что что не соответствует. Тесты пройдены, значит ошибок нет!
Давайте не будем расшатывать лодку и подводить коллег. Вы же понимаете. Все всё понимают.
Так ведь если так не делать, тесты будут красненькие и в панамку хуев напихают. А релиз надо выпускать уже завтра! Ну и что что не соответствует. Тесты пройдены, значит ошибок нет!
Давайте не будем расшатывать лодку и подводить коллег. Вы же понимаете. Все всё понимают.
> большинство тестов тупо фиксируют ту функциональность, что есть
Да, это примерно 45% того, что должны делать тесты. Зафиксировать контракт, чтобы быть уверенным, что вот этот кусок кода продолжает работать так, как работал. Чтобы быть уверенным, что ты случайно что-то не сломал изменениями. Если тесты упали, смотришь - это ты сломал, или ранее был незамеченный косяк.
Функциональность, какой она должна быть - это либо очень простая функциональность, на которую тесты уровня "легко видеть", либо формальная верификация. Формальная верификация возможно очень мало где, очень долго и очень дорого. Во всех остальных случаях всегда есть вероятность, что в коде есть незамеченные ошибки, а в тесте непокрытые частные случаи. Такова жизнь.
Вторые 45% пользы тестов существуют раз в жизни при написании тестов и кода. Нет, я не сторонник TDD, потому что в нетривиальном коде хуй ты напишешь сначала тесты. Тем более, до реализации ты зачастую и внешний интерфейс представляешь примерно, и он может уточняться новыми деталями.
Но в сложной системе тестировать функциональность "руками" зачастую невозможно. От твоего куска зависят еще куски, от них еще куски, и еще куски, а где-то там сверху уже прикладные интерфейсы. Такое ручное тестирование сродне удалению апендикса через нос. Поэтому тесты. Пишешь код. Пишешь код. Пишешь тесты. Правишь код. Правишь тесты. Дописываешь код. Дописываешь тесты. Снова правишь. Еще раз правишь. И так далее, до тех, пока пазл не сложиться.
Да, это примерно 45% того, что должны делать тесты. Зафиксировать контракт, чтобы быть уверенным, что вот этот кусок кода продолжает работать так, как работал. Чтобы быть уверенным, что ты случайно что-то не сломал изменениями. Если тесты упали, смотришь - это ты сломал, или ранее был незамеченный косяк.
Функциональность, какой она должна быть - это либо очень простая функциональность, на которую тесты уровня "легко видеть", либо формальная верификация. Формальная верификация возможно очень мало где, очень долго и очень дорого. Во всех остальных случаях всегда есть вероятность, что в коде есть незамеченные ошибки, а в тесте непокрытые частные случаи. Такова жизнь.
Вторые 45% пользы тестов существуют раз в жизни при написании тестов и кода. Нет, я не сторонник TDD, потому что в нетривиальном коде хуй ты напишешь сначала тесты. Тем более, до реализации ты зачастую и внешний интерфейс представляешь примерно, и он может уточняться новыми деталями.
Но в сложной системе тестировать функциональность "руками" зачастую невозможно. От твоего куска зависят еще куски, от них еще куски, и еще куски, а где-то там сверху уже прикладные интерфейсы. Такое ручное тестирование сродне удалению апендикса через нос. Поэтому тесты. Пишешь код. Пишешь код. Пишешь тесты. Правишь код. Правишь тесты. Дописываешь код. Дописываешь тесты. Снова правишь. Еще раз правишь. И так далее, до тех, пока пазл не сложиться.
> Зафиксировать контракт
чтобы зафиксировать контракт, этот контракт должен быть. то есть в тестах может содержаться какая-то информация, которой в коде нет. но у нас не так. упавший тест - это не повод задуматься над правильностью кода, а повод подшаманить тест не глядя
тесты должны помогать выявлять косяки, если они не помогают их выявлять, то они нах не нужны, они лежат мёртвым грузом и только тратят время при сборке.
и вынуждают тебя каждый раз в 2х местах править код хуй знает зачем
как бы ты отнесся к тесту, который в коде с опечаткой проверяет наличие этой опечатки?
о такой фигне речь, а не о чем-то супер сложном
или вот: есть некая апиха, которая может или отдать данные, или вернуть список кодов ошибок и их описаний. что бы ты проверял, коды или текст ошибок? или и то и то? и проверял бы наличие тех ошибок, которые ожидаются; отсутствие тех, которые не ожидаются; или строгое соответствие списков ошибок?
спойлер: у нас можно найти в тестах любое сочетание вот этого всего, и хуй знает чем руководствовались в конкретном месте
в чем там контракт и почему он меняется всё время - я хз
чтобы зафиксировать контракт, этот контракт должен быть. то есть в тестах может содержаться какая-то информация, которой в коде нет. но у нас не так. упавший тест - это не повод задуматься над правильностью кода, а повод подшаманить тест не глядя
тесты должны помогать выявлять косяки, если они не помогают их выявлять, то они нах не нужны, они лежат мёртвым грузом и только тратят время при сборке.
и вынуждают тебя каждый раз в 2х местах править код хуй знает зачем
как бы ты отнесся к тесту, который в коде с опечаткой проверяет наличие этой опечатки?
о такой фигне речь, а не о чем-то супер сложном
или вот: есть некая апиха, которая может или отдать данные, или вернуть список кодов ошибок и их описаний. что бы ты проверял, коды или текст ошибок? или и то и то? и проверял бы наличие тех ошибок, которые ожидаются; отсутствие тех, которые не ожидаются; или строгое соответствие списков ошибок?
спойлер: у нас можно найти в тестах любое сочетание вот этого всего, и хуй знает чем руководствовались в конкретном месте
в чем там контракт и почему он меняется всё время - я хз
всегда так было. просто раньше спрашивали про другое. а так - всегда при переходе из одного коллектива в другой тебе задавались любимые вопросы нового коллектива. их тоже можно понять они хотят разработчика +/- на одной с ними волне. при этом редко кто открывает позиции на того самого чувака, который будет json перекладывать - и это будет его максимум задач.
хотя в итоге может получится так, что новый коллектив ровно такой же как старый. я помню как очень очень давно не смог ответить на вопрос по Oracle связанный с аналитическими функциями (там бывают такие хитрые конструкции с окнами, которые я не мог себе визуализировать) . Меня на работу взяли (хотя я упал духом, но видимо просто лучше не нашлось) и что(!?) - я ни разу не встретил использования аналитических функций как на собеседовании. Вопрос был, но за годы работы ни одной бизнес задачи не было.
хотя в итоге может получится так, что новый коллектив ровно такой же как старый. я помню как очень очень давно не смог ответить на вопрос по Oracle связанный с аналитическими функциями (там бывают такие хитрые конструкции с окнами, которые я не мог себе визуализировать) . Меня на работу взяли (хотя я упал духом, но видимо просто лучше не нашлось) и что(!?) - я ни разу не встретил использования аналитических функций как на собеседовании. Вопрос был, но за годы работы ни одной бизнес задачи не было.
Был я в такой же ситуации 20 лет тому назад (серьезно, это было 20 лет назад). Задроченный ин-хауз программист (причем на языке учетной программы, а не настоящий программер) на предприятии. Всем всё надо, я во всем виноват (даже в том что бухгалтерия проебалась или что тупая овца в принтер бумагу со скрепками сунула) и все это за 300 долларов в месяц.
Прочитай на хабре про "церемонии аджайл", про солид, про юнит-тесты - это займет месяц максимум. И иди на собеседование. Глпаное помнить что всегда можно сказать что ты что-то использовал, даже если это не так. Главное понимать о чем ты говоришь.
И когда я решил оттуда рвать когти, на первых двух собеседованиях я обосрался примерно по этой же схеме, хех.
Просто помни что собеседование - это место где ты продаешь себя и свои знания. Подумай в чем ты хорош, и делай упор на это. Провалил собес - ну бывает, чо. Выучи то что спрашивали, и иди на следующий. И все получится.
Прочитай на хабре про "церемонии аджайл", про солид, про юнит-тесты - это займет месяц максимум. И иди на собеседование. Глпаное помнить что всегда можно сказать что ты что-то использовал, даже если это не так. Главное понимать о чем ты говоришь.
И когда я решил оттуда рвать когти, на первых двух собеседованиях я обосрался примерно по этой же схеме, хех.
Просто помни что собеседование - это место где ты продаешь себя и свои знания. Подумай в чем ты хорош, и делай упор на это. Провалил собес - ну бывает, чо. Выучи то что спрашивали, и иди на следующий. И все получится.
Прохождение собеседований в ИТ и работа в ИТ - это разные скиллсеты. Это уже даже не постирония, про это прямо говорят.
На самом деле, тут два стула (e.g. типа собесов):
1. Обычно в небольшие галеры или продуктовые компании тебя попросят рассказать о прошлом опыте, немного погоняют по стеку технологий, попросят решить что-то простенькое на 10 минут, чтобы понять что ты вообще тот, за кого тебя выдаёшь. Если всё ок - дают весло и гребешь (интенсивность задаётся надсмотрщиком).
2. Бигтех и wannabe бигтех - "расскажите о своих выступлениях на конференциях и вкладе в сообщество", ёбанный литкод на live coding, culture fit, leadership principles, прочее сектантство на пять раундов собеседований. Потом возможны варианты - или въёбываешь как проклятый, чтобы на performance review было что рассказать, либо пилишь полгода мелкую хуйню, остальное время рассказываешь в linkedin про impact и best practices чувакам, которые влезли на первый стул.
Промежуточные варианты возможны.
На самом деле, тут два стула (e.g. типа собесов):
1. Обычно в небольшие галеры или продуктовые компании тебя попросят рассказать о прошлом опыте, немного погоняют по стеку технологий, попросят решить что-то простенькое на 10 минут, чтобы понять что ты вообще тот, за кого тебя выдаёшь. Если всё ок - дают весло и гребешь (интенсивность задаётся надсмотрщиком).
2. Бигтех и wannabe бигтех - "расскажите о своих выступлениях на конференциях и вкладе в сообщество", ёбанный литкод на live coding, culture fit, leadership principles, прочее сектантство на пять раундов собеседований. Потом возможны варианты - или въёбываешь как проклятый, чтобы на performance review было что рассказать, либо пилишь полгода мелкую хуйню, остальное время рассказываешь в linkedin про impact и best practices чувакам, которые влезли на первый стул.
Промежуточные варианты возможны.
Кстати, то, что тебя спрашивают про церемонии, возможно показатель, что в резюме у тебя так или иначе прописано "стагнировал N лет в говноконторе". Наниматель пытается понять, умеешь ли ты вообще работать в более или менее стандартной командной среде. Скорее всего стоит:
1. Почитать и набраться терминов
2. Вычесать CV от этих красных флагов
1. Почитать и набраться терминов
2. Вычесать CV от этих красных флагов
Ну так-то да. Отстал немного. На лет 15. По крайней мере столько времени назад от меня стали это всё требовать. Вещи сами по себе полезные, но всё зависит не от технологий, а от того как их используют. Очень много контор, которые работают как распиздяи - одни не знают когда и как правильно и оправданно юзать юниттесты. Другие уверены что зная паттерны люди перестанут говнокодить (вообще нет).
А вот без хорошо поставленных процессов (типа аджайла) я уже слабо представляю как можно что-то спланировать и оценить для заказчика.
А вот без хорошо поставленных процессов (типа аджайла) я уже слабо представляю как можно что-то спланировать и оценить для заказчика.
Выгорел.
Так вообще не исключающие себя тезисы.
Умер хомячком.
>>> А вы знаете церемонии Аджайл?
>>> В бинарном восславлении возвышая голоса,
Восславим дух Аджайл,
Омнисисей дарованный принцип разработки
Своей силой вы защищаете меня
Своей заботой я развиваю святой код
Священным маслом ублажаю вас
Успокойтесь, духи машины,
И примите мое благословление
>>> В бинарном восславлении возвышая голоса,
Восславим дух Аджайл,
Омнисисей дарованный принцип разработки
Своей силой вы защищаете меня
Своей заботой я развиваю святой код
Священным маслом ублажаю вас
Успокойтесь, духи машины,
И примите мое благословление
А разве не в этом вся суть IT-сферы? Чтоб работать поменьше, а получать побольше.
Сперва въёбываться, потом проёбываться.
Сперва вникаешь в рабочий процесс, отлаживаешь его, автоматизируешь рутину, упрощаешь интеграции. Потом отдыхаешь, пока работа работает саму себя.
Сперва вникаешь в рабочий процесс, отлаживаешь его, автоматизируешь рутину, упрощаешь интеграции. Потом отдыхаешь, пока работа работает саму себя.
Да, в IT сфере программист может за день не написать ни строчки кода. И при этом заказчик будет доволен как слон. Только "есть один нюанс" (с) - ждо этой стадии карьеры этому разработчику надо расти минимум полтора десятка лет.
Чтобы написать коммент, необходимо залогиниться
И т.д..