про тех кто пашет как та пчелка

[OhBoy]

Лютый ад. Внезапно заставили работать. И что же делать с понтами типа одной рукой письмо строчу, другою яростно лодку чиню?

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

[АццкоМото]

Лютый ад. Внезапно заставили работать. И что же делать с понтами типа одной рукой письмо строчу, другою яростно лодку чиню?

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

Гораздо интереснее вообще не работать и заниматься исключительно гедонизмом.

Вопрос — ваш работодатель поддержит это финансово? Ну, часть "не работать" он сделает легко. Дальше?

[OhBoy]

Лютый ад. Внезапно заставили работать. И что же делать с понтами типа одной рукой письмо строчу, другою яростно лодку чиню?

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

Гораздо интереснее вообще не работать и заниматься исключительно гедонизмом.

Вопрос — ваш работодатель поддержит это финансово? Ну, часть "не работать" он сделает легко. Дальше?

оценивать работу в ИТ часами, просиженными в офисе может только недалёкий человек (к сожалению, такие есть и в моём офисе, ещё и в высоких чинах). Если голова на месте, вполне можно работать 4 часа и выдавать их за все 8, а то и за 28. Главное это понимать.

[АццкоМото]

Лютый ад. Внезапно заставили работать. И что же делать с понтами типа одной рукой письмо строчу, другою яростно лодку чиню?

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

Гораздо интереснее вообще не работать и заниматься исключительно гедонизмом.

Вопрос — ваш работодатель поддержит это финансово? Ну, часть "не работать" он сделает легко. Дальше?

оценивать работу в ИТ часами, просиженными в офисе может только недалёкий человек (к сожалению, такие есть и в моём офисе, ещё и в высоких чинах). Если голова на месте, вполне можно работать 4 часа и выдавать их за все 8, а то и за 28. Главное это понимать.

Я всегда писал именно это. Но. Работать ноль часов как-то не выходит. А иногда и 4 часа не выдал за 8.

[adda_]

оценивать работу в ИТ часами, просиженными в офисе может только недалёкий человек (к сожалению, такие есть и в моём офисе, ещё и в высоких чинах). Если голова на месте, вполне можно работать 4 часа и выдавать их за все 8, а то и за 28. Главное это понимать.

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

[OhBoy]

оценивать работу в ИТ часами, просиженными в офисе может только недалёкий человек (к сожалению, такие есть и в моём офисе, ещё и в высоких чинах). Если голова на месте, вполне можно работать 4 часа и выдавать их за все 8, а то и за 28. Главное это понимать.

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

Система метрики для порграммистов вполне себе есть. Я себе в джире делаю отчёт и смотрю сколько проблем закрыто с пометкой BUG, смотрю сколько багов появляется, после того, как прошлые баги пофиксены. Я знаю, что один прогер мне на листочке напишет код и он будет работать сразу же, как только попадёт в ПК, а другой будет месяц сидеть над hello world. Понятно, что максимальную скорость работы программиста таким образом не посчитать, но вот качество его кода - легко. Один пишет код и на его код создаётся 50 заявок в джире от бизнеса, а другой пишет код и заявок не создаётся вообще. Очевидно, что материальные вещи оценивать намного проще, но и в данном случае можно добиться результатов при желании. До моего прихода в мою текущую компанию (уже в США), например, никто отчёты не строил вообще. Всем было плевать. А я отчёты строить сильно люблю, поэтому построил их везде где только можно, а отчётность при огромном количестве пользователей вещь незаменимая, пользователя не обманешь - написал кривой код - бизнес будет бить по попе.

[8K]

метрики для порграммистов

О, у нас как раз клоунада разворачивается: надо каждый день хоть один "коммит" но выкатывать. Оно, конечно, и раньше код говно говном был, а уж теперь-то...

[OhBoy]

метрики для порграммистов

О, у нас как раз клоунада разворачивается: надо каждый день хоть один "коммит" но выкатывать. Оно, конечно, и раньше код говно говном был, а уж теперь-то...

А нечего мерять код исключительно количеством. Код надо мерять багами. Пусть они лучше делают медленно, но качественно, потому как те что делают быстро и не качественно, при условии что ещё и тестеры не оттестят весь функционал (а 100% покрыть его нереально), и потом в продакшене надо всё откатывать, то ну его нахрен. У меня такое повсеместно - пофиксили, оттестировали - всё работает, как в продакшн кинули, так то что фиксили работает, а то что фиксить не надо было уже нет и всё по новой. Только уже для другого процесса. Моя мечта это ежедневный дамп продакшена в тест, где можно было бы их творения ставить и тестировать на практически продуктиве, а иначе гаплык.

[ksi]

У меня такое повсеместно - пофиксили, оттестировали - всё работает, как в продакшн кинули, так то что фиксили работает, а то что фиксить не надо было уже нет и всё по новой. Только уже для другого процесса. Моя мечта это ежедневный дамп продакшена в тест, где можно было бы их творения ставить и тестировать на практически продуктиве, а иначе гаплык.

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

[IL]

Болталка на тему того, что слишком усердно рабоатать не надо? или надо?
Для меня недавно откровением было узнать, что тех, кто слишком упорно трудится и работает свер урочно (без доп оплаты) коллеги не любят

努力工作不會讓你富有

Конфуций

[nyekimov]

У меня такое повсеместно - пофиксили, оттестировали - всё работает, как в продакшн кинули, так то что фиксили работает, а то что фиксить не надо было уже нет и всё по новой. Только уже для другого процесса. Моя мечта это ежедневный дамп продакшена в тест, где можно было бы их творения ставить и тестировать на практически продуктиве, а иначе гаплык.

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

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

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

Поэтому тестирование требует основательного подхода и стратегии, а не просто навесить тест на каждую возможную и не возможную ситуацию.

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

[Мальчик-Одуванчик]

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

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

[АццкоМото]

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

Например, считаем количество строк и количество багов. У одного дохренища строк и мало багов. У другого наоборот. Первый кнопки рисует, второй фреймворк. И чо?

Вообще это software engineering 101

[ksi]

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

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

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

А почему методы не работают на многопоточных приложения, в чем принципиальное отличие? Имеется в виду, что баг выплывает только при определенном сочетании условий, как race conditions в multithreading?

А почему нельзя эмулировать как-то стрессовые ситуации? Ну вроде это одна из основных задач, посмотреть как система работает "на пределе"? Или это только для "серьезных" вещей, а обычно нужно просто дешево и сердито?

[valchkou]

А почему методы не работают...
А почему нельзя эмулировать ...

все работает и все можно когда есть деньги.

[Мальчик-Одуванчик]

А почему методы не работают на многопоточных приложения, в чем принципиальное отличие? Имеется в виду, что баг выплывает только при определенном сочетании условий, как race conditions в multithreading?

А почему нельзя эмулировать как-то стрессовые ситуации? Ну вроде это одна из основных задач, посмотреть как система работает "на пределе"? Или это только для "серьезных" вещей, а обычно нужно просто дешево и сердито?

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

[Мальчик-Одуванчик]

А почему методы не работают...
А почему нельзя эмулировать ...

все работает и все можно когда есть деньги.

И время. А последнего обычно не бывает.

[SK]

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

https://www.theatlantic.com/technology/ ... de/540393/
Букав очень многа, но статейка крайне релевантная.

[OhBoy]

У меня такое повсеместно - пофиксили, оттестировали - всё работает, как в продакшн кинули, так то что фиксили работает, а то что фиксить не надо было уже нет и всё по новой. Только уже для другого процесса. Моя мечта это ежедневный дамп продакшена в тест, где можно было бы их творения ставить и тестировать на практически продуктиве, а иначе гаплык.

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

Я бы был исключительно рад, если б у нас отдельные люди занимались регрессионкой. В корпоративной части компании такое есть, в нашем регионе (США) нету, более того, первого тестировщика взяли на работу 3 года назад. Всем плевать.

[ystar]

У меня такое повсеместно - пофиксили, оттестировали - всё работает, как в продакшн кинули, так то что фиксили работает, а то что фиксить не надо было уже нет и всё по новой. Только уже для другого процесса. Моя мечта это ежедневный дамп продакшена в тест, где можно было бы их творения ставить и тестировать на практически продуктиве, а иначе гаплык.

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

Я бы был исключительно рад, если б у нас отдельные люди занимались регрессионкой. В корпоративной части компании такое есть, в нашем регионе (США) нету, более того, первого тестировщика взяли на работу 3 года назад. Всем плевать.

Так это америка.

[OhBoy]

У меня такое повсеместно - пофиксили, оттестировали - всё работает, как в продакшн кинули, так то что фиксили работает, а то что фиксить не надо было уже нет и всё по новой. Только уже для другого процесса. Моя мечта это ежедневный дамп продакшена в тест, где можно было бы их творения ставить и тестировать на практически продуктиве, а иначе гаплык.

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

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

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

Поэтому тестирование требует основательного подхода и стратегии, а не просто навесить тест на каждую возможную и не возможную ситуацию.

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

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

[OhBoy]

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

https://www.theatlantic.com/technology/ ... de/540393/
Букав очень многа, но статейка крайне релевантная.

Лично для меня очевидно, что именно ИТ погубит мир. Это всего лишь вопрос времени.

[OhBoy]

А почему методы не работают...
А почему нельзя эмулировать ...

все работает и все можно когда есть деньги.

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

[uncle_Pasha]

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

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

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

[valchkou]

А почему методы не работают...
А почему нельзя эмулировать ...

все работает и все можно когда есть деньги.

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

это как то противоречит тому что сказал я?