Сярод тых, хто салідарна працуе, знайшліся два чалавекі (або астатнія проста не гатовыя да споведзі перад кам’юніці), якія прызналіся ў нянавісці да працы.
І так, «забойца» жадання працаваць — заказчык.
Сярод тых, хто салідарна працуе, знайшліся два чалавекі (або астатнія проста не гатовыя да споведзі перад кам’юніці), якія прызналіся ў нянавісці да працы.
І так, «забойца» жадання працаваць — заказчык.
— Шукалі таго, хто ненавідзіць сваю працу, — гэта якраз я! Я — fullstack-праграміст на адным не тое каб вялікім, але дарагім праекце. Сеньёр.
Мы ўжо два гады спрабуем разабраць векавы маналіт на мікрасэрвісы, але заказчык амаль не бачыць у гэтым профіту, — хоць пасля пераходу на мікрасэрвісы ў самых крытычных месцах стала разоў у 100 менш адмоў. Але, на жаль, замарозкі распрацоўкі ў маналіце няма — і вельмі часта ўзнікаюць сітуацыі, калі невялікая каманда сёння перапісвае літаральна тое, што ўчора выйшла ў прадакшан ад іншай каманды.
А часам праз пастаянныя накладкі і змены планаў гэта адбываецца паралельна.
Учора я быў вельмі злы, бо дзве гадзіны працаваў бізнэс-аналітыкам. Рэч у тым, што новенькаму на праекце выдалі таску і ён прыйшоў да мяне за парадай.
А я паглядзеў — і пайшоў у фарбах апісваць РМу, а адпаведна і заказчыкам, што гэта не можа быць зроблена ў тым выглядзе, які прадугледжвае заданне.
У нас у два разы менш тэсціроўшчыкаў, чым тэставых сервераў. Таму 2/3 часу пры распрацоўцы чагосьці новага сыходзіць на поўнае пакрыццё юніт-тэстамі. Не, гэта нядрэнна, многія б пра такое марылі, — але гэта неверагодна моцна тармозіць працу.
Дэвопсаў як такіх у нас няма, таму зробце ласку знаць Kubernetes\докер\CI\CD\bash\powershell — і наогул усё, што можа спатрэбіцца, калі нешта пойдзе не так. Як вы зразумелі, ВА асобных таксама няма, таму часам даводзіцца разбіраць пажаданні ўдваіх, утраіх, учацвярых разам з PM і іншымі праграмістамі, а таксама QA.
Яшчэ ў нас заапарк франтэндавых фрэймворкаў… Я проста ненавіджу гэты праект! І даўно — але раней пытанне іміграцыі было важнейшым за мой псіхалагічны стан.
Якое выйсце з сітуацыі — памяняць працу. Я ў працэсе — паўгода ўжо штодня наведваю LeetCode, рыхтуюся да сумоўя. Рэзюмэ рассылаю. Але пошук ідзе няхутка, а вось так сысці «ў нікуды» я не магу таму, што я — адзіны карміцель у сям'і.
Не, праграмістам працаваць мне падабаецца — ад самага дзяцінства (неяк на ўроку інфарматыкі, пакуль усе давалі рады ўкладзеным цыклам, я намаляваў аналагавы гадзіннік на TurboPascal).
Але ты глядзіш на новыя бліскучыя фічы ва ўсялякіх профільных блогераў на ютубе і параўноўваеш з «заапаркам» у сябе на працы з усіх запар фрэймворкаў, пачынаючы ад караля Гароха. І разумееш, што ніколі іх не ўжывеш з гэткім стаўленнем заказчыка да тваёй працы. А на пет-праект вечарамі сіл ужо ніякіх няма.
Я вельмі старанна выбіраю новае месца працы — калі бачу састарэлыя рэчы ў патрабаваннях, то захоўваю ў закладкі, але пасоўваю такія вакансіі ў канец чаргі.
Хацеў бы знайсці працу ў Германіі — і асесці там. Але мяне таксама задаволіла б праца на аддаленым праекце для амерыканцаў (і абавязкова на прадукце, ніякага больш аўтсорсу!) — тады б я выбраў Іспанію і Digital Nomad Visa. Думаю, што да канца лета ўсё ж знайду, а можа нават пераеду (я не ў Беларусі, дзе — не хацеў бы казаць).
Што параіў бы іншым, каб не патрапілі ў такую ж «пастку». Сачыце, хлопцы, за тым, што робіць заказчык. Наведвайце мітынгі, нават калі не хочацца. А калі бачыце неадэкватныя рашэнні — адразу бяжыце. Бо часам выяўляецца, што на цябе «грошай няма». Ёсць на інтэграцыі з сумніўнымі стартапамі, на яшчэ 2-3 новыя маркетынгавыя сэрвісы, а на цябе і на новы сервер для баз даных — не.
— Я ўжо ненавіджу сваю працу — адчуваю апатыю і адначасова злуюся, нават дробязі абураюць.
Я працую на амерыканскага заказчыка, з якім цяжка камунікаваць — ён знікае надоўга. Я на праекце сола, акрамя мяне — кафаўндары, якія раней яго і пісалі.
Менеджменту нуль, што, вядома, прыводзіць у шаленства: іх трое, і кожны гаворыць сваё, таскі не наразаюць у Kanban, а кідаюць у РМ. З кодам складана працаваць — гэта проста міннае поле. За год з лішкам я прывёў трохі да ладу кодбазу, але сам за гэты час ператварыўся ў нейкага неадэквата.
Пакуль я не магу сысці з гэтай працы: яна дае магчымасць карміць сям’ю. Так што я спрабую адцягвацца — гуляю ў відэагульні (але калі прайграю, то зноў злуюся). Яшчэ мне дапамагаюць трымацца прагулкі з жонкай і дочкамі, а таксама размовы з іншымі распрацоўшчыкамі пра тое, як іх таксама даняла жудасная праца.
Трэба сказаць, што стрэс у мяне яшчэ пасля працы ў папярэдняй кампаніі. Ад сакавіка я пачаў шукаць іншую працу, але пакуль не вельмі актыўна. Аднавіў рэзюмэ, закінуў пасты ў лінкедзін.
Я разумею, што, вядома, яшчэ мне патрэбны адпачынак.
Дый наогул вельмі важна мець стабільны адпачынак (ні ў якім разе не прапускайце яго!), гаварыць аб праблемах на праекце, а калі гэтыя праблемы не вырашаюцца — сыходзіць.
А яшчэ практыкаваць дні без працы — не думаць пра яе, не размаўляць (хоць бы адзін дзень). Не чапаць гаджатаў. І не трымаць працоўныя чаты на тэлефоне. Гэта мая парада і сабе, і іншым — каб не апынуцца ў такой жа сітуацыі, як я цяпер.
А з вамі бывае?
Рэлацыраваліся? Цяпер вы можаце каментаваць без верыфікацыі акаўнта.
ох уж эти синьеры, им бы только разрушить монолит создаваемый годами. таких перемен вы хотите?
Типа сеньеры этого захотели. Скорее всего идея какого-нибудь менеджера, который уже на другом проекте сидит или лида который уже в другой компании работает. Видели мы таких уникумов.
Там проблема в том, что Петя как программист малокомпетентен, зато обладает большим самомнением.
Как связаны микросервисы и количество отказов? Я тоже не вижу пока что профита.
Конечно нет. Людям надо работать и развивать продукт, а не ждать пока некомпетентная команда перепишет все на микросервисы, не понимая зачем они вообще нужны.
Ох да, правда? Каждому тестировщику обязательно нужен свой сервер? Вторая часть фразы вообще никак не связана с первой. Какое отношение юнит тесты имеют к наличию или отсутствию тестировщиков или тестовых серверов?
"Юнит тесты сильно тормозят процесс разработки" (c) Сеньор Петя.
Без комментариев.
Ну да. Сениор разработчик обязан знать среду где работает его код и отвечать за его сборку, деплой и работу. Подход "я написал невесть что, перекинул через забор девопсам, плевать как оно там собирается и деплоится" не работает в приличных местах.
Карыстальнік адрэдагаваў каментарый 3 мая 2024, 14:27
Считаете unit тесты как серебряной пулей программирования? Всегда готовы написать unit test на метод GetById(id)?
Карыстальнік адрэдагаваў каментарый 3 мая 2024, 15:02
Нет конечно, зачем вы приписываете мне то, что я не говорил? Юнит тесты не серебряная пуля.
А человек заявляющий, что юнит тесты как-то связаны с количеством тестировщиков, или заявляющий что они тормозят разработку - просто некомпетентен.
Вы не расписали, что этот метод делает и откуда. Предположу, что он вытаскивает кортеж из какого-то хранилища по ключу. Конечно же, такой метод должен быть покрыт юнит тестами.
ну так всякие есть циклы разработки: где-то разраб пишет функционал и тесты от начала и до обеда, где-то только функционал, а потом перекидывает, как вы говорите, за забор и тестировщик. уже пишет тесты. По поводу девопсов тоже спорно - лучше когда это все в одном месте и ответственность за си\сд несет какя-то одна команда\человек, а не хз кто (рандомный чел которому что-то показалось). Тогда не надо искать - а какая это **** поломала пайплайн и почему вдруг ничего не работает, а вчера было все норм. При этом бесспорно что больше знаний - лучше, особенно для синьера-помидора, особенно фулстека разбираться в докере, кубере, тераформе, дженкисе и т.п. можно например и сказать что мастхэв. Вот взяли тебя такого, а проект надо с 0 поднимать, ну и что ты там напилишь
По поводу девопсов конечно можно спорить. Но сеньор не понимающий о том, где и как выполняется его код, как происходит вообще процесс запуска тестов, как разворачивается приложение не может писать нормальное приложение и видеть проблему в целом.
Как такой человек будет принимать какие-то решения, как мелкие, которые возникают каждый день, так и крупные, архитектурные? Он не знает на какой машине и где работает его приложение, в контейнере оно, или на железе. Он не знает как оно деплоится. Как он будет писать какие-то вещи связанные с пользовательскими сессиями? Миграции данных? Невозможно написать миграцию пользовательских данных, не зная процесс деплоймента.
Карыстальнік адрэдагаваў каментарый 3 мая 2024, 18:18
Покрытие 1 строки кода юнит тестом занимает значительно больше 1 строки кода.
Количество строк кода пропорционально связано со сложностью системы. С этой точки зрения юнит-тесты многократно увеличивают сложность системы. Увеличение сложности вполне может быть оправдано преимуществами, которые даёт юнит-тестирование.
Однако, найти метрики уровня "применение юнит-тестов удешевляет разработку в x раз и уменьшает количество багов с прода в y раз" - чрезвычайно сложно. Зато очень легко найти проект, на котором юнит-тестами покрыто то, что легче всего покрыть (утилиты и статика), а 20% критически важного (и самого сложного) функционала - нет.
Популярный аргумент "вы просто не правильно используете..." вызывает у меня встречный вопрос - а может ли считаться хорошей практика, которая на большинстве проектов оказывается "неправильно использованной".
Во многих случаях юнит-тест является единственным быстрым способом для разработчика проверить корректность работы кусочка написанного кода большой системы. Но ценность этих проверок в репе зачастую не выше ценности комита в репу файла с breakpoints, используемыми для дебага какой-либо задачи.
Также как на определённом этапе проекта денормализация БД является нормальной, так и удаление юнит-тестов, проверяющих работу утилит, которые никто не будет менять - тоже.
Более того, у меня нет сомнений в том, что при использовании НЕ test-first approach каждый девелопер без проблем вкинет сотни строк зелёных юнит-тестов в проект - сейчас за него это сделает Copilot. А ещё можно сгенерить тысячи строк юнит-тестов на юнит-тесты. Но непонятно, а нужны ли тогда ещё какие-либо уровни тестирования, если девелопер всё может сделать сам.
Аргумент об улучшении архитектуры (гибкости) для меня звучит как оправдание ограничений инструментов разработки. Если бы результат любого системного вызова в контексте юнит-теста можно было переопределить - зачем писать обёртки, интерфейсы и настраивать DI? Почему практики тестирования должны диктовать практики разработки?
Суммируя - я считаю, что на многих проектах инвестирование усилий в интеграционные тесты даёт больше измеряемой выгоды, чем юнит-тестирование самого простого кода.
Не знаю про какое большинство проектов вы придумали. На ВСЕХ сколь-нибудь значимых проектах тесты есть, и они хорошие. Без автоматических тестов на код невозможно поддерживать проект где больше одного разработчика сколь-нибудь долгое время. Если в проекте покрыто 20% кода тестами, а на 80 забили - он станет помойкой очень быстро и его выкинут и начнут все писать заново.
Про выбор между интеграционными тестами и юнит действительно можно долго говорить. Тем более что грань там довольно размыта на самом деле.
Про удаление юнит тестов не очень понял. Зачем? Они бесплатно гоняются. Тем более если никто не собирается менять ничего, их и поддержитвать не надо. А если вдруг соберется менять - эти тесты будут бесценными.
Как и про уровни тестирования. Тесты не проверяют отсутствие багов же. Тесты проверяют отсутствие регрессии.
Карыстальнік адрэдагаваў каментарый 15 мая 2024, 11:57
По вашей логике врач хирург должен сам за все отвечать? И диагностику проводить и лечение назначать и судно после операции выносить. Тыж врач!
Это очень умный способ ведения спора. Приписать собеседнику идиотскую мысль, а потом ее опровергнуть.
К хирургу который только проводит операцию, и ни диагноз и показания к операции, ни дальнейшее состояние пациента его не волнуют, вы вряд ли хотели бы попасть на стол.
Для меня это звучит аналогично. Почему программист должен отвечать за инфраструктуру, поднимать eks и AD, искать проблемы в данных заказчиков, разговаривать с клиентами, придумывать kpi метрики etc.
Почему операционные системы с изоляцией адресных пространств процессов более стабильны?
Зачем придумали файловые системы, если любые данные это цепочка бит и их можно записать в один длинный файл?
Зачем использовать ссылки, если можно использовать адреса в памяти?
Зачем использовать классы и объекты, если данные хранятся в одном и том же адресном пространстве?
Почему не рекомендуют использовать классы с десятками полей, переменных-членов?
Зачем в языках придумали модификаторы доступа?
Я не вижу никакого профита, так что всем должно быть очевидно, что весь мир разработки программных систем идет не в ту сторону, причем уже давно!
Вы со своими голосами в голове разговариваете? От того что вы мешаете все умные слова в одну кучу, ваши аргументы умнее не выглядят
эх, жаль, я хотел подружиться, ведь вместе, как команда, мы могли бы бросить вызов реальности, поколебать ее устои и принципы
Карыстальнік адрэдагаваў каментарый 4 мая 2024, 13:00
Дружище, давай я попробую ответить.
Разделение адресных пространств не даёт никакой стабильности. Адресные пространства стараются сделать для процессов одинаковыми, чтобы уменьшить количество настроек адресов в коде в процессе загрузки. Изоляция и контроль доступа делается на сегментном уровне. Изоляция собственно процессов как таковых друг от друга имеет смысл а любой многопользовательской ос с разделением ресурсов, и не только адресных пространств и не только от других процессов а прежде всего ядра.
Файловые системы придумали для того, чтобы обеспечить сменяемость носителя в накопителе и пришли к линейной и древовидной структурам данных, первое для стримеров второе для дисков.
Нет никаких ссылок от уровня Асм и ниже, все это указатели, т.е. адреса данных в оп ссылки как мы их знаем в срр допустим ненужная абстракция, вся соль ссылка не может быть пустой а указатель может но это фактически обман, сделай указатель пустой и разименуй. Ссылка просто такой синтаксический но довольно убогий сахар. Но из-за него ты в месте вызова не понимаешь у тебя объект ушел по значению или по ссылке.
Про классы они про мягкое а вы про теплое. Читайте про ооп и забудьте про адресное пространство вам ни стандарт языка ни ABI ни компилятор никаких гарантий про какое то адресное пространство не даёт. Его вообще может и ни быть
Я не знаю какой идиот вам это не рекомендует, но Профит от класса когда он как абстрактная сущность реализует что то из реального мира. Если реальный объект требует 50 членов так тому и быть
Модификаторы доступа придумали для бестолковой реализации концепции черного ящика позволяя ему быть и белым и серым
Как так то?
Программист всегда прав, и знает всё лучше всех, а тут такой coming out...
Как же надо себя ненавидеть чтобы каждый день заниматься проектом который ненавмдишь. Мдааа.
В пратчем оба человечка из мира вебни, не удивительно.
Есть как минимум одна существенная причина для этого - финансовая. В курсе сколько человек сидят в айти чисто ради бабла?
Можно было выбрать интересное направление где вот как минимум меньше такого бардака.
Нет. Не в курсе. Эта информация мне не интересна и бесполезна. Более того это провал почти всегда.
По факту получается как всегда. Сидели ради бабла, в итоге бабла так и нет (рас нет подушки безопасности позволяющей всё бросить и найти нормальную работу), зато есть выгорание, депресняк и прочие последствия. Заниматься тем что ненавидиш до добра не доводит и деньги тут не спасут.
Конкретно про этих ребят ничего не могу сказать. Скорее соглашусь с вами. Но вот конкретно в моем случае, работаю чисто из-за денег - хотя и далеко не в восторге от того что делаю. Помогает не выгорать особая философия жизни - 2 года пашешь, 3 чилишь и делаешь все что нравится.
И что вам это даёт? Много денег так что тратить не успеваете?
А почесу бы не жить постоянно как 3 годе? Работать над тем что нравиться и при это хорошо получать. Зачем обязательно каждые 3 года 2 мучаться выдавливая из себя работу?
Потому что с вашей колокольни это звучит разумно, а с моей колокольни нет. Мне не нравится айтишка и точка. Сижу в ней чисто ради денег и честно признаюсь в этом.
Так вот мне интересно почему с вашей колокольни нельзя заниматься тем что нравиться (будь то IT или НЕ IT) постоянно и заработывать на это более чем достаточно? Есть ведь люди зарабатывающие и за пределами IT тем что им нравиться? Или ваша сфера интересов совсем не прибыльна? Хотелось бы тогда узнать что это за сфера
Да, и это большая беда, что в РБ большой гэп между ЗП в ИТ и другими сферами (это не повод раскулачить первых). В итоге, проще с финансовой, нервной, временной точки зрения, быть средним айтишником, чем хорошим врачом, ветеринаром, конструктором металлоконструкций и т.д. Да, в последних сферах тоже есть крутые спецы с айтишной ЗП или даже выше, но их единицы. Хотя, по факту, айтишник это нормальная инженерная специальность как и любая другая.
IT это отрасль, заливаемая инвестиционными деньгами в надежде на быструю прибыль. Поэтому цель владельцев большинства проектов - рубить бабло, равно как и цель наёмных работников.
Это влечёт за собой массу глобальных последствий для индустрии, от экспоненциального наплыва людей, проходящих те же грабли, что и предыдущее поколение 4-5 лет назад (которые к этому моменту уже "эксперты" и учат других правильно проектировать методом пересказа увиденных в интернете решений задач с других проектов), до волн хайпа, создающих для инвесторов иллюзию прогресса ради выкачивания денег.
Расскажите, а что вы будете делать, если потеряете работу, а интересную для себя не сможете найти?
Карыстальнік адрэдагаваў каментарый 6 мая 2024, 12:05
Нервные они какие-то. Спокойней нужно быть. Свое здоровье дороже, чем какие-то там проекты и заказчики.
Ну а если хочется делать то, что хочется, то это нужно делать лично для себя. А когда делаешь для других и они за это еще платят, лучше просто принять как факт то, что делать нужно те вещи, которые хотят они.
все правильно говорите, не нужно выгорать. десяткм тысяч людей работают на заводах и фабриках, что-то не видно прогрессивных коучей которые им советуют выйти из зоны конфорта. или борцунок с харазментом в сталелитейках
кто за ужин платит - тот девушку и танцует
А так это уже обсуждали, редакция повторяется
The Expert (Short Comedy Sketch)
https://www.youtube.com/watch?v=BKorP55Aqvg
"Кафаўндараў трое, кожны кажа сваё, таскі кідаюць у РМ"
Знайшоў чым сдзявіць: у меня адзін СЕО але таскі 3 разы на дню новыя, "важнейшыя". І гэта ён яшчэ ігнора тое, што з тэхнічнай часткі "гарыць"...