boosty.to/alexkorep - поддержать канал материально instagram.com/aokorep/ - мой инстаграм t.me/devworden - наш телеграм-чат, где можно задать вопросы discord.gg/7B4prKBxkZ - Discord-сервер с каналами по разным языкам программирования Мой микрофон: ya.cc/aAXRs Моя камера: ya.cc/WEPvP Мой рабочий компьютер: ya.cc/WEQGr Ссылки партнерские, я могу получить вознаграждение, если вы купите что-то, перейдя по этим ссылкам.
Вот, задумался о переходе на Mac (до этого - Windows / Ubuntu), и как-то не верится, что 8Gb RAM будет достаточно... Я тут сомневаюсь между 16 и 32... (Я про партнёрские ссылки)
А я тот самый программист, который ходит и в магазин в рабочее время и на море купаться. Если сидеть целый день и кодить без перерыва, продуктивность выше от этого все равно не станет. А вот если в обед сесть на вел и сгонять на море, то нормально перезагрузишься и сможешь до самого вечера доработать без переутомления. Плюс к здоровью и качеству жизни.
Пик продуктивности в 6 вечера это цветочки по сравнению с пиком продуктивности в 2 ночи, особенно когда кодишь квадрокоптеры, которые жужжат и пищат, распугивая соседей
1 Сначала все переписать - не надо 2 На самых модных технологиях - не надо 3 Зафиксить баг не разобравшись до конца 4 Отвлечься, котиков по-лайкать, слеганца, 5 И сделать то, что нам не очень надо - не надо 6 Отправить код, не проведя ревью, 7 Или зафиксить прямо в главном бранче, 8 В продакшене отладку провести свою, 9 И базу из него тащить куда-то дальше + Она ведь не твоя! не надо так! + Не подставляй меня! И лучше не смотри в нея.. 10 Не делать Unit тесты, погрузившись в мрак, 11 Свой код не протестировать руками + Отдав его тестировать, с граблями, + Которые, к тебе еще вернутся, + Столь очевидные, но очень больно бьются + И отбивают все доверие к тебе - не надо 12 Всё legacy отформатировать "по нормам" + Запомни - эти нормы спорны! + Они менялись и изменятся не раз + Так сделаешь - получишь больно в глаз! 13 Ревью чужого кода, не читая, утвердить 14 От эстимейтов, согласившись, отступить 15 Рабочий день на два часа продлить 16 Или рабочий час, себе переложить, + в свой личный - делать так не надо + не важно ты на "удаленке" или рядом 17 Не надо спорить, не дослушав до конца, + Умей услышать и понять гонца, + Которого к тебе коллеги отправляют + Когда проблемы обсудить с тобой желают. Не надо этого всего. Вот список - заучи его. P.S. подробное разъяснение каждого пункта смотрите на канале "Леша Корепанов" "Что нельзя делать ПРОГРАММИСТУ (но очень хочется)" P.P.S. Это предварительный поэтический конспект, для заучивания, и, заодно, комментарий для продвижения алгоритмами 2022-01-30 14:31
После дня размышления, чего не хватает в этом списке, вспомнил очевидное: 18 Пароли в коде не храни И в наш репозиторий их не помещай Равно, как и конфиги с ними А если прокололся - сразу их меняй
Спасибо за видео. Я далеко не новичок в программировании, но мне было интересно послушать. Самый сложный и противоречивый для меня совет это "заканчивать программировать ровно в 6 часов". У этого совета есть как хорошие, так и плохие стороны. У меня это слабое место. Хорошо, что заставили об этом задуматься.
все это своим опытом вымучал за десяток лет и заявляю, что это видео одно из самых полезных для новичков! Тема софт скиллов не очень раскрыта в интернетах, к сожалению и очень классно, что ты ее структурировал!
Интересно было бы узнать также о рабочих лафхаках, когда не понимаешь код и ситуация кажется безвыходной. В этом случае, например, отвлечься - это вполне может спасти человека от моральной гибели от фрустрации. Или поспать. Или поделиться с коллегами. Или выйти в магазин. Понятно, что в идеале хорошо бы быть роботом, без слабостей и держать себя в ежовых руковицах. Но иногда ты просто не можешь чего-то понять, или тебя шокирует обьем работы. И в этих ситуациях нужно, я считаю, человеку подсказать и помочь, дать понять, что все нормально, ты не один такой, и выход есть. Интересно было бы услышать ваш опыт, как вы помогаете коллегам
И это работает, потому что мы смотрим только с одной стороны когда пытаемся решить задачу, но после того как мы отвлечемся и начинаем смотреть на задачу с другой стороны - сейчас решит то что не мог сделать вчера.
Конечно не лайфхак, но все же, есть мнемоническая техника решения сложных задач, т.е. представляем что перед нами не сведущий человек совсем, и ему надо объяснить суть проблемы и суть своего решения, подход, плюсы и минусы и тд) Вдобавок надо четко осознавать, что слона едят ложкой, "космос" в одну итерацию не написать)) Быть последовательным в общем, не переключаться, не отвлекаться и решать траблы по мере поступления) Обладаю немалым кол-ом опыта, около пяти лет работы в компании NetCracker, работал на гигантов в области телекома, в индустрии (на позиции разработчика стаж близится к 10 годам)
Как минимум сообщить наверх, что есть сложности. Но в целом обычно отлаживаешься, вставляешь принты, разбираешься, дезассемблируешь если у тебя нету исходников и т. п.
Один из советов напомнил о недавно прочитанной книге, очень рекомендую: Tony Schwartz, The Way We're Working Isn't Working (есть на русском). Новых истин она не открывает, но очень хорошо раскрывает тему, что мозг человека не может работать с постоянной эффективностью длительное время. Суть в двух словах: наиболее эффективно работать итерациями по полтора-два часа, затем короткий отдых и восстановление. Это позволяет сохранять работоспособность в течение всего рабочего дня, повышает эффективность и к концу дня не будешь выжит как лимон. Разумеется, там ещё про правильное питание, сон, регулярную активность - все как мы любим))
2 камня преткновения - заставить себя работать в рабочее время и заставить себя не работать в нерабочее время. а помимо этих кейсов часто сталкиваюсь с ревью несвязного с задачей кода, но мы в команде договорились - если видим недокументированную багу в процессе разработки - правим по месту при условии, что тесты после исправлений не падают и описываем факт исправления в сообщении пул реквеста - очень помогает в маленькой команде (нас 3 человека). ну и туда - же поддержка кодстайла.
Мне закончить работу в 6 часов вечера помогает привычка оставлять развернутый комментарий для себя, прямо в том месте кода где остановился, где я описываю ход мыслей, откуда и куда я шёл. Так на следующий день получается очень быстро вернуться в поток, особенно если выспался.)
Я полагаю, что основное достоинство удалёнки - возможность не работать непрерывно по 8 часов. Для меня, например, гораздо лучше поработать часика 4, прерваться на часовую прогулку, душ там, отвлечься вообщем. Но 4 часа это не приколочено, зависит от задачи и вовлечённости. Но если делать перерывы не меньше часа, переключаться, можно легко работать по 12 часов без выгорания. Задолбало пилить бэк, застрял, каша в голове, топаем гулять, потом можно фронт поковырять или доки покурить.
С другой стороны это делает рабочий день бесконечным. Получается что "работал" 12 часов, больше ничего не успел вечером, потому что до 9 вечера работал.
Более того, даже 8 часов не надо работать. При работе в офисе, если из 8 часов вычесть все перекуры, кофе, Ютуб, обсуждение нерабочих моментов и т д, то на работу останется часов 5-6. На удаленке немного иначе, но суть та же. Думаю чем стараться отработать 8 часов, можно работать 4-5 производительных часа и 1-2 на митинги, переключения задач. В итоге выйдет за день 5-6 часов. Но это при условии что это только рабочее время, без ютубов и прочих отвлекающих факторов. Если прям упарываться и работать ровно 8 часов, то кукухой поехать можно.
@@mootal2202 Тут, конечно, палка о двух концах. И ситуации у всех разные, как и приоритеты. Для меня самый главный профит в том, что контекст из башки выпасть не успевает. Судя по разным мнениям, получается типа сложного процента. К примеру, если работать больше, условно, на 2 часа в день, то прирост экспы не 25%, а 30-35%. Но такие марафоны чреваты "блевотой от кода", если не "выбивать себя" на свежий воздух, праздность... Я у бати подсмотрел, он постоянно что-то делает, но одно и тоже относительно (дня) недолго. Но весь день возится. Надоест электрика, пойдёт в огород, потом гвозди позабивает. А зимой ещё снег чистить надобно ))) Я ещё подумал, что кто-то может тянуть эту лямку только ради денег. Тут всё сложно, конечно. Просто я сам с детства живу компами и всё равно торчать за ним всё время буду стараться. Так что мои мысли - имхо, отчасти со своей колокольни...
Есть программа математическая с открытой лицензией, очень популярна у иностранцев, чем в РФ, хотя тоже используют ее дизайнеры. Так там эту программу не перерабатывали толком 10 лет, всё ругаются, но делают. За год жена исправила почти 70% багов и выложила новую версию. Ей самой очень нравится эта программа, так теперь программисты сообщества обсуждают её в дискорте, что смогла сделать что им не удалось. По факту, жена не программист, а больше математик.
Я борюсь с усталостью и отвлечениями с помощью Pomodoro. Ставлю концентрацию на 30 мин и пашу, потом у меня перерыв мин 5, я ложусь на диванчик, меня тут же ловит мой кот и ложится со мной, мин 5 я дремлю и слежу, чтобы ни о чем не грузиться, кручу песню в голове. Потом опять на 30 мин кодить. Мозг так благодарно начинает работать, это не передать! Итак у меня все устроено циклом на нужное время 4 или 6 часов, а в середине у меня большой перерыв на упражнения. На котиков лучше не залипать и прочие соцсети. Потом мозг перестраивается и ему лень начинать все заново.
Я не разу не программист, а даже наоборот, я - риэлтор, но черт побери до чего приятно послушать настолько грамотную и плавную речь от очень уравновешенного человека ! есть чему поучиться в плане подачи информации !
блин!! мистер корепанов, какой же вы молодец, что решили снимать такие видева. это очень сильно упрощает понимание и алгоритм действий, который надо делать чтобы двигаться дальше по карьерной лестнице, да и по жизни в целом. мое глубочайшее почтение и уважение вам. надеюсь в будущем мы с вами встретимся и я расскажу вам свою историю становления одним из крутейшим айтишником.
"До конца рабочего дня осталось ВСЕГО шесть часов, а тебе на ревью прислали 500 строк кода!!!" Походу не только у программистов так работа поставлена. Очень много где видел.
Очень приятная подача материала. Несмотря на то, что от программирования я далек, с удовольствием посмотрел ролик. Даже реклама удивила. Не просто перечисление достоинств спонсора, но целая история, благодаря которой можно проследить за ходом мыслей рассказчика и что-то для себя подчеркнуть.
Мне, как джуну было интересно, особенно про фикс багов поо месту (знаю что так нельзя, но из-за невысокого скилла слишком часто и сильно тянет так делать), про форматирование файла тоже заставляет задуматься, пожалуй больше не буду так делать или буду отсылать правки по формату отдельно, чтобы можно было принять быстро
"Все переписать" встречал даже таких активных новых ребят, которые это предлагали в легаси системе с 8-ми летней историей... Сам не так давно переписывал приличный кусок(далеко не всю имеющуюся систему) функциональности. Планировалось в общей сложности управиться в 3 месяца...управились в 5 и еще 2 месяца отлавливали баги...
Не знаю что там было на видео, до конца не досмотрел, но внимательно дослушал. Классный формат типа около подкаста и информация жизненная. Однозначно лайк)
Спасибо! Спорить с людьми не выслушав не стоит всем, не только программистам) а что до остальных пунктов, то, да, вы всё правильно говорите, но жизнь так многообразна. Три года я поддерживал один старый проект для очень большого иностранного банка. через год работы узнал, что моя рабочая станция в сети банка - продакшин сервер нашего проекта. всё нормально было, никто не пострадал) ревью это вообще любимая песня. слишком много людей любят ревьювить чужой код повышая своё ЧСВ и слишком мало относятся к ревью серьёзно. было в моей практике, что ревью помогали, но чаще случалось, что приводили к совершенно неоправданным задержкам деливери без малейшей пользы для кода. и про юнит тесты тоже история известная... в целом, по большому счёту, программисту можно всё. лишь бы потом всё хорошо было)
очень сильно согласен, ревью какая-то порочная практика, пользы от нее с гулькин нос, а минус телега. Если код работает, выполняет свою задачу и на него написан тест - он имеет право попасть на прод. Исключение если человек сам хочет чтобы его код посмотрели. И обычно при сложных фичах люди таки хотят вторую пару глаз.
@@avonaryagami слышал, что когда Оракл купил Солнцевских из Оракла в Сан прислали инструкции отправлять код на ревью в Оракл. Из Сан ответили вопросом "а у вас есть компетентные специалисты?".
Обычно в компании коммиты в мастер и девелоп напрямую запрещены политикой репозитория, только через мерж пулл-реквеста. Ну и если был аппрув пулл-реквеста и внесены изменения, то аппрув слетает, то есть пока ревьюер не посмотрит ещё раз, ничего не смержишь ;)
Смотришь на совой же код, написанный год назад и думаешь: "какой же это пиздец". Надо всё переделывать... но потом понимаешь, что переделывать - это просто дохуя времени, которого и без того ни на что не хватает :)) Ну и дописываешь то, что есть по итогу :)))
12:18 Блин! Ты прям в точку. Пару недель назад именно так и было. Поменял пару строчек и решил поправить все пробелы, отступы и переносы. Потом глянул на список изменений и понял, что мои 2 строчки там просто потерялись. Пришлось сделать усилия и отменить почти все лишние правки. Только то, что рядом с основными изменениями оставил.
У меня еще есть спорный пункт Часто по процессам нужно передавать на тестирование баг или фичу после прохождения ревью. Но мне попадались проекты где ревью было очень долгим, и изза этого не удавалось успеть под релиз. Например ждешь правок день, выкатываешь что-то по комментариям, опять ждешь. Хотя тестировщик может взять на тестирование уже прямо сейчас. В итоге в какой-то момент, если оценивал что комментарии врядли вызовут серьезные переделки, то заливал апдейт в тестовый стейдж прямо из моей фича/багфикс бранчи Часто удается сильно выиграть время. Но иногда получилось заставлять тестировщика проверять одно и то же 2, а то и 3 раза. Хотя в целом тестировщики на моей практике все равно отмечали больше плюсов у такого подхода
тут вопрос регламентов если по регламенту допустимо до 24 часов ревью проводить, то значит это такая скорость проекта, и это нормально Если же выходит за регламент, то это уже нарушения, и надо обращаться к комуто. К начальству или еще к кому. Вообще фраза *"тестировщик может взять на тестирование уже прямо сейчас"* не выглядит правильной, если по технологии нужно сначала провести ревью. Это все равно, что: я уже готов сейчас выложить картошку на сковороду, но она еще не нагрелась.
По всем пунктам в точку 👌 Стоит только отметить, что всего сказанного не стоит делать исключительно из-за вашей лени или прихоти. Порой дедлайны просто не оставляют выбора. Тот же «дешевый фикс» иногда единственное возможное решение - в сжатые сроки бывает невозможно разобраться с гнилым легаси, который до тебя фиксили вот такими же быстрыми заплатками.
Пойти за хлебом в рабочее время это вообще не считается каким-то криминалом у нас на проекте, это как пойти к кофе поинту с кем-то по болтать в старые времена
Алексей, предлагаю записать видео про то как "правильно" составить резюме и как его поддерживать/улучшать. Знаю, тема сложная, но думаю будет интересно узнать от Вас это. Спасибо, что лайкаете. Продолжайте в том же духе, надо чтоб Алексей увидел нас.
Для меня самое эффективное оказалось пополнять файл по мере того что я хорошего сделала. Когда нужно отправлять резюме у меня есть куча инфы какая я молодец. Без этого все достижения забываются у меня))
Как говорят, если итальянцу связать руки, он не сможет говорить. Мне кажется у вас есть итальянские корни. ))) * Спасибо за ваш труд, прям видно что каждый пунктик выстрадан на собственной шкуре
12:16 Меня всегда учили и я взял за правило, отправлять переформатирование отдельным пулл-реквестом. Чтобы его отдельно ревьювили, и оно не мешалось с изменением логики.
6:23, спасибо, больная тема... у меня не кодинг, у меня учёба, тонны новой информации и отвлекаешься постоянно, причём делаешь это не осознанно, осознаешь только когда уже отвлёкся и занят чем то другим... я всё не могу понять, толи у меня мозг слабый, толи это у всех так...
Спасибо за подборку! Мне кажется, было непросто разложить всё по полочкам так, но это действительно круто. Можно даже какой-нибудь лист А4 с этими мыслями составить!
Не знаю насколько это самоочевидно Нервы и сон бережет такая практика - быстро накидать прототип с максимальным количеством заглушек. На кнопках, где функционал еще не готов, не вешаем onclick. Нет текстуры - вешаем котика. В простейших случаях это значит нарисовать ui и закодить все базовые переходы. После этого в любой момент если придут и прикажут показать что есть, можно будет предоставить"почти" готовую апку. После этого работать становится сильно легче. Дэдлайн по крайней мере не давит. Это я к пункту "Не уйти домой в 6 часов, бросив на полпути". В случае схемы выше, бросать можно в любой момент после написания прототипа.
О, дебажить код на продакшене, это любимая тема моих коллег с предыдущей работы )) Камень в огород Директора ИВЦ, надеюсь ты это прочитал )) А на предложение что нужно пользоваться гитом и тестовую среду хотя бы поднять, я получил ответ, что это мне только надо.
Хотелось бы видео по уровням английского в иностранных компаниях. Какой уровень для каждого уровня программистов. Где используется высокий уровень, как общаться вживую с носителем-клиентом, работодателем, индусом
Как по мне оказалось проще совместно кодить огромной командой когда находишься на огромной круизном лайнере тем самым плавно совмещая работу + отдых + развлечения в одном флаконе попутно путешествуя по всему миру.
эх, встать в 18 с рабочего места (я дома работаю) и забыть про работу - совсем не про меня последний год, ибо ремонт и ребенку на всякие кружки в другой конец города надо не к 18-19, а к 17, и чтоб наработать положенные 8 часов порой приходится и до 2 ночи сидеть, ибо в середине дня на час-два отъезжал по вопросам ремонта, а потом за пару часов до конца рабочего дня отбежал еще на 2-3 часа по домашним делам....и в итоге конец рабочего дня смещается с 19 (ибо в 10 сел) на 19+4... а там еще пару строк кода дописать... и отдергиваешь себя уже в 2-3 ночи за шкирку спать ( одно успокаивает - это временно все
по поводу пункта 14. "соглашение с навязанной оценкой трудоемкости" иногда есть возможность сказать "Ну давай сделай сам за то время, за какое ты думаешь оно делается". А в ответ очевидное "А я не умею".
Вы так говорите про ревью - но на деле 100проц ревьюстов не лезут разбираться в реальную логику, а смотрят поверхности, и кроме как "там комментарий не понятен" или "тут можно сократить вызовы" - реальной логикой никогда не занимаются. Так же некоторые глюки бывают в определенном юзере именно на проде, и увы приходится именно проверять на продакшене.
Личный совет по предварительной оценке трудозатрат: - Если постановщик говорит "что тут делать? хватит и 15 минут" Отвечаю без агрессии: "Зачем тогда я вам, если это так просто и быстро?" или "Покажите, как вы это сделаете за 15 минут и я вам заплачу свою ставку" - Если у вас есть хоть капля сомнений, то либо увеличивайте сразу срок х2, либо поясняйте, что задача не выглядит понятной и засыпайте вопросами постановщика. Не бойтесь, задавая правильные вопросы, вы себя не выставите тупым. - Если вы понимаете, что не успеваете, то сразу сообщайте постановщику. Да, он будет упираться и противиться увеличению трудозатрат, но и вы должны приводить аргументы: нет тестовых данных, нет доступа или прав. Если же задача оказалась просто сложнее или более трудоемкой когда согласился на такие трудозатраты или сроки: да, взялся за гуж - не говори, что не дюж. Придется поработать ночами.
да, нужно максимально сроки себе выбивать. Сделаешь быстрее-хорошо, все будут рады. Но зато не придётся ночами работать случаях, если задача сложнее оказалась, чем на первый взгляд
@@TEENASPECT вряд ли так получится, что тебе вместо недели дадут три месяца времени. Так что как по мне, лучше взять неделю, когда реально требуется 5 дней, нервничать и недосыпать из-за любой непродуманной ситуации - это путь к выгоранию и проблемам со здоровьем
Вот как раз для НТ продакшн БД и нужно использовать, обезличенные естественно. Я понимаю, что для многих НТ это что-то типа АТ, только запускаемое много раз, но на самом деле любое хорошее НТ - это вообще другой тип тестирования, скрипты в котором выступают лишь инструментом для достижения нагрузки, и не более. Поэтому да, для каких-то отладок фич, модулей, АТ - продакшн БД нельзя использовать, в то время как для НТ - это крайне рекомендуется.
Алексей, у нас в команде принято на уровне настроек atlassian stack, что для merge в develop необходимо: 1. не менее 2-х апрувов на код ревью + я могу наложить вето 2. удачный билд с юнит тестами 3. удачный деплой на dev стенд 4. отсутствие ошибок при миграции БД на dev стенде 5. пройденный скан с помощью Sonar 6. апрувы сбрасываются в случае дополнительных комитов 7. комитить в мастер и девелоп можно только через пулл реквест.. 8. покрытие кода должно быть на уровне +- 80% . Я как devops не могу позволить своим разработчикам вольности в git :)
Чем больше ограничений, правил и проверок - тем медленней скорость выпуска новых фич. Для пререлизной версии one-page приложения такой workflow явно избыточен, а для новой версии автопилота в самолёте - недостаточен. Про этот баланс хорошо написано в книге "практики системного и сетевого администрирования"
@@ne4to777 Просто это время должно учитываться при планировании. Это описание обычных проверок в ci\cd. Я бы только убрал проверку на покрытие тестами, иначе рефакторинг нельзя вмержить (после него кода часто становится меньше и покрытие падает)
@@ne4to777 Если потребуется провести фичу или багфикс в нарушение договоренностей - мы сделаем это с минимальными проверками(например недавно пришлось вывести фичу совсем без покрытия тестами). Речь идет о стабильности релизов в условиях отсутствия факапов и особых нарушений дедлайнов. Если сборка, деплой или миграция БД на dev/stage будет неуспешной - зачем пытаться выводить это в prod, для того чтобы заниматься откатом?
К счастью, половина пунктов закрывается правилами команды и компании - у нас например нет доступа к проду и его базе, нельзя пропустить код ревью или тестирование. Так что остается только бороться с отвлечениями, соблазном заапрувить что-то не глядя или зафиксить багу не вникая. Немного отвлекаться в рабочее время имхо все же можно, хотя бы чтобы дать мозгу передышку, можно в том числе переключится и что-то поделать дома - на столе прибраться, растения полить, чаю сделать, но вот об отлучках из дома все же стоит предупреждать, чтобы не попасть в неловкую ситуацию.
@@arinelex мои предпочтения уже поменялись. Немного почитав про vim, начал его активно использовать. К тому же, как linux пользователь, с терминалом я работаю постоянно. Не потому, что я не умею устанавливать DE, но потому-что мне нравится клавиатурный интерфейс
Разработка и тестирование на тестовом окружении - для слабаков 😁, только продакшен, только хардкор! Был случай: чуть не поседел, когда толком не разобравшись жахнул изменения сразу на проде...
Когда только начал учиться программированию и понимаешь, что помимо русского и английского есть отдельный язык на котором говорят программисты, где найти уроки по нему?))))
Я согласен с тем, что не нужно сразу соглашаться на изменение сроков выполнения задачи, что не программист не может оценить адекватно сроки, но у нас менеджеры работают с бэкгрундом разработчика, хотя он тоже может свое мнение навзязать со своей колокольни, за какое время он бы выполнил задачу, а не я, начинающий.
Видишь ли, оценка делается так: задача детально описывается и разбивается на итерации продукта от начальной до релиза исходя из функциональности промежуточных результатов, а итерации - на подзадачи, те - на подзадачи еще меньше и так до тех пор, пока длительность мелкой подзадачи не будет очевидна. Называется это "WBS" - work breakdown structure. При этом бывает полезно использовать программулину с диаграммой Ганта для учета зависимостей между задачами и автоматического суммирования. MS Project слишком монструозный для небольших проектов, и есть огромное количество недорогих или вовсе бесплатных инструментов. Вроде просто, да? Но здесь есть один косяк: ВСЕГДА что-то в этом списке задач будет упущено. Поэтому ВСЕГДА надо делать поправку. Есть шутка: если в задаче все понятно, и нечто похожее ты уже делал и помнишь - поправка равна числу E, а если ты похожего не делал - то Pi ... Реально же для вычисления поправки нужно смотреть собственную статистику промахов оценка/реальность... А потому - лажают с оценками все. И начинающие, и опытные
boosty.to/alexkorep - поддержать канал материально
instagram.com/aokorep/ - мой инстаграм
t.me/devworden - наш телеграм-чат, где можно задать вопросы
discord.gg/7B4prKBxkZ - Discord-сервер с каналами по разным языкам программирования
Мой микрофон: ya.cc/aAXRs
Моя камера: ya.cc/WEPvP
Мой рабочий компьютер: ya.cc/WEQGr
Ссылки партнерские, я могу получить вознаграждение, если вы купите что-то, перейдя по этим ссылкам.
Вот, задумался о переходе на Mac (до этого - Windows / Ubuntu), и как-то не верится, что 8Gb RAM будет достаточно... Я тут сомневаюсь между 16 и 32... (Я про партнёрские ссылки)
А я тот самый программист, который ходит и в магазин в рабочее время и на море купаться. Если сидеть целый день и кодить без перерыва, продуктивность выше от этого все равно не станет. А вот если в обед сесть на вел и сгонять на море, то нормально перезагрузишься и сможешь до самого вечера доработать без переутомления. Плюс к здоровью и качеству жизни.
Вот те раз , у меня говорит времени нету вам видосики писать , а посмотреть другие видосики за то время есть :)
@@romawar1869 война войной, а обед по расписанию 😅
ты в лос-анджелесе?
согласен! нас вообще не контролируют время и в принципе можно без разрешения отработать в выходные или вообще вечерами за счет других дней
++++++++
Пик продуктивности в 6 вечера это цветочки по сравнению с пиком продуктивности в 2 ночи, особенно когда кодишь квадрокоптеры, которые жужжат и пищат, распугивая соседей
1 Сначала все переписать - не надо
2 На самых модных технологиях - не надо
3 Зафиксить баг не разобравшись до конца
4 Отвлечься, котиков по-лайкать, слеганца,
5 И сделать то, что нам не очень надо - не надо
6 Отправить код, не проведя ревью,
7 Или зафиксить прямо в главном бранче,
8 В продакшене отладку провести свою,
9 И базу из него тащить куда-то дальше
+ Она ведь не твоя! не надо так!
+ Не подставляй меня! И лучше не смотри в нея..
10 Не делать Unit тесты, погрузившись в мрак,
11 Свой код не протестировать руками
+ Отдав его тестировать, с граблями,
+ Которые, к тебе еще вернутся,
+ Столь очевидные, но очень больно бьются
+ И отбивают все доверие к тебе - не надо
12 Всё legacy отформатировать "по нормам"
+ Запомни - эти нормы спорны!
+ Они менялись и изменятся не раз
+ Так сделаешь - получишь больно в глаз!
13 Ревью чужого кода, не читая, утвердить
14 От эстимейтов, согласившись, отступить
15 Рабочий день на два часа продлить
16 Или рабочий час, себе переложить,
+ в свой личный - делать так не надо
+ не важно ты на "удаленке" или рядом
17 Не надо спорить, не дослушав до конца,
+ Умей услышать и понять гонца,
+ Которого к тебе коллеги отправляют
+ Когда проблемы обсудить с тобой желают.
Не надо этого всего. Вот список - заучи его.
P.S. подробное разъяснение каждого пункта
смотрите на канале "Леша Корепанов"
"Что нельзя делать ПРОГРАММИСТУ (но очень хочется)"
P.P.S. Это предварительный поэтический конспект, для заучивания,
и, заодно, комментарий для продвижения алгоритмами
2022-01-30 14:31
После дня размышления, чего не хватает в этом списке, вспомнил очевидное:
18 Пароли в коде не храни
И в наш репозиторий их не помещай
Равно, как и конфиги с ними
А если прокололся - сразу их меняй
Начинайте сразу с рендеринга.
@@Eustrop Говоите по-русски... Так никто делать не будет. Если надо что-то скрыть, это будет сделано по умолчанию.
Удивительно. Вы задаете команды которые сами не профилируете. Это делает за Вас АИ, с хера Вы(субъекты) хотите?... Это риторика.
Just add pst...brr...tsip.. and u have got programmers rap. Жги!
Спасибо за видео. Я далеко не новичок в программировании, но мне было интересно послушать. Самый сложный и противоречивый для меня совет это "заканчивать программировать ровно в 6 часов". У этого совета есть как хорошие, так и плохие стороны. У меня это слабое место. Хорошо, что заставили об этом задуматься.
У меня как-то просто всегда с навязанной трудоёмкостью.
- Сколько?
- Три дня.
- Да ладно, что тут делать, это ж до завтра можно запилить.
- Запили.
3:45
> "Я даже рассказывать вам про это не буду"
> Рассказывает
все это своим опытом вымучал за десяток лет и заявляю, что это видео одно из самых полезных для новичков! Тема софт скиллов не очень раскрыта в интернетах, к сожалению и очень классно, что ты ее структурировал!
Интересно было бы узнать также о рабочих лафхаках, когда не понимаешь код и ситуация кажется безвыходной. В этом случае, например, отвлечься - это вполне может спасти человека от моральной гибели от фрустрации. Или поспать. Или поделиться с коллегами. Или выйти в магазин. Понятно, что в идеале хорошо бы быть роботом, без слабостей и держать себя в ежовых руковицах. Но иногда ты просто не можешь чего-то понять, или тебя шокирует обьем работы. И в этих ситуациях нужно, я считаю, человеку подсказать и помочь, дать понять, что все нормально, ты не один такой, и выход есть. Интересно было бы услышать ваш опыт, как вы помогаете коллегам
И это работает, потому что мы смотрим только с одной стороны когда пытаемся решить задачу, но после того как мы отвлечемся и начинаем смотреть на задачу с другой стороны - сейчас решит то что не мог сделать вчера.
Конечно не лайфхак, но все же, есть мнемоническая техника решения сложных задач, т.е. представляем что перед нами не сведущий человек совсем, и ему надо объяснить суть проблемы и суть своего решения, подход, плюсы и минусы и тд) Вдобавок надо четко осознавать, что слона едят ложкой, "космос" в одну итерацию не написать)) Быть последовательным в общем, не переключаться, не отвлекаться и решать траблы по мере поступления) Обладаю немалым кол-ом опыта, около пяти лет работы в компании NetCracker, работал на гигантов в области телекома, в индустрии (на позиции разработчика стаж близится к 10 годам)
Вы назвали все правильные ответы которые и должны быть в таких ситуациях
Как минимум сообщить наверх, что есть сложности. Но в целом обычно отлаживаешься, вставляешь принты, разбираешься, дезассемблируешь если у тебя нету исходников и т. п.
+, согласен, я пример этому.
Один из советов напомнил о недавно прочитанной книге, очень рекомендую: Tony Schwartz, The Way We're Working Isn't Working (есть на русском). Новых истин она не открывает, но очень хорошо раскрывает тему, что мозг человека не может работать с постоянной эффективностью длительное время. Суть в двух словах: наиболее эффективно работать итерациями по полтора-два часа, затем короткий отдых и восстановление. Это позволяет сохранять работоспособность в течение всего рабочего дня, повышает эффективность и к концу дня не будешь выжит как лимон. Разумеется, там ещё про правильное питание, сон, регулярную активность - все как мы любим))
2 камня преткновения - заставить себя работать в рабочее время и заставить себя не работать в нерабочее время. а помимо этих кейсов часто сталкиваюсь с ревью несвязного с задачей кода, но мы в команде договорились - если видим недокументированную багу в процессе разработки - правим по месту при условии, что тесты после исправлений не падают и описываем факт исправления в сообщении пул реквеста - очень помогает в маленькой команде (нас 3 человека). ну и туда - же поддержка кодстайла.
Мне закончить работу в 6 часов вечера помогает привычка оставлять развернутый комментарий для себя, прямо в том месте кода где остановился, где я описываю ход мыслей, откуда и куда я шёл. Так на следующий день получается очень быстро вернуться в поток, особенно если выспался.)
Я полагаю, что основное достоинство удалёнки - возможность не работать непрерывно по 8 часов. Для меня, например, гораздо лучше поработать часика 4, прерваться на часовую прогулку, душ там, отвлечься вообщем. Но 4 часа это не приколочено, зависит от задачи и вовлечённости. Но если делать перерывы не меньше часа, переключаться, можно легко работать по 12 часов без выгорания. Задолбало пилить бэк, застрял, каша в голове, топаем гулять, потом можно фронт поковырять или доки покурить.
С другой стороны это делает рабочий день бесконечным. Получается что "работал" 12 часов, больше ничего не успел вечером, потому что до 9 вечера работал.
Более того, даже 8 часов не надо работать. При работе в офисе, если из 8 часов вычесть все перекуры, кофе, Ютуб, обсуждение нерабочих моментов и т д, то на работу останется часов 5-6.
На удаленке немного иначе, но суть та же.
Думаю чем стараться отработать 8 часов, можно работать 4-5 производительных часа и 1-2 на митинги, переключения задач. В итоге выйдет за день 5-6 часов. Но это при условии что это только рабочее время, без ютубов и прочих отвлекающих факторов.
Если прям упарываться и работать ровно 8 часов, то кукухой поехать можно.
@@mootal2202 Тут, конечно, палка о двух концах. И ситуации у всех разные, как и приоритеты. Для меня самый главный профит в том, что контекст из башки выпасть не успевает. Судя по разным мнениям, получается типа сложного процента. К примеру, если работать больше, условно, на 2 часа в день, то прирост экспы не 25%, а 30-35%. Но такие марафоны чреваты "блевотой от кода", если не "выбивать себя" на свежий воздух, праздность...
Я у бати подсмотрел, он постоянно что-то делает, но одно и тоже относительно (дня) недолго. Но весь день возится. Надоест электрика, пойдёт в огород, потом гвозди позабивает. А зимой ещё снег чистить надобно )))
Я ещё подумал, что кто-то может тянуть эту лямку только ради денег. Тут всё сложно, конечно. Просто я сам с детства живу компами и всё равно торчать за ним всё время буду стараться. Так что мои мысли - имхо, отчасти со своей колокольни...
Есть программа математическая с открытой лицензией, очень популярна у иностранцев, чем в РФ, хотя тоже используют ее дизайнеры.
Так там эту программу не перерабатывали толком 10 лет, всё ругаются, но делают. За год жена исправила почти 70% багов и выложила новую версию.
Ей самой очень нравится эта программа, так теперь программисты сообщества обсуждают её в дискорте, что смогла сделать что им не удалось. По факту, жена не программист, а больше математик.
Поделитесь названием и ссылочкой на переделку))
"Не буду заливать на гит, обновлю сразу на сервере через ftp" - главный спонсор 500-ых ошибок.
Смотрела ваши видео до того, как начала работать программистом, ничего не было понятно, а сейчас слушаю и могу сразу понять обо всём, что вы говорите)
На самом деле видео про котиков заставляет задуматься и свежим взглядом оценить свой код
Хомяк ну Вы же сами признали, что Вы хомяк...) С добрым умыслом.
Я борюсь с усталостью и отвлечениями с помощью Pomodoro. Ставлю концентрацию на 30 мин и пашу, потом у меня перерыв мин 5, я ложусь на диванчик, меня тут же ловит мой кот и ложится со мной, мин 5 я дремлю и слежу, чтобы ни о чем не грузиться, кручу песню в голове. Потом опять на 30 мин кодить. Мозг так благодарно начинает работать, это не передать! Итак у меня все устроено циклом на нужное время 4 или 6 часов, а в середине у меня большой перерыв на упражнения. На котиков лучше не залипать и прочие соцсети. Потом мозг перестраивается и ему лень начинать все заново.
В течение скольки месяцев удаётся держать такую практику?
Я не разу не программист, а даже наоборот, я - риэлтор, но черт побери до чего приятно послушать настолько грамотную и плавную речь от очень уравновешенного человека ! есть чему поучиться в плане подачи информации !
блин!! мистер корепанов, какой же вы молодец, что решили снимать такие видева.
это очень сильно упрощает понимание и алгоритм действий, который надо делать чтобы двигаться дальше по карьерной лестнице, да и по жизни в целом.
мое глубочайшее почтение и уважение вам.
надеюсь в будущем мы с вами встретимся и я расскажу вам свою историю становления одним из крутейшим айтишником.
Тролль 80 уровня?
@@werewolfvit тот самый чел который во всём ищет подвох😑
"До конца рабочего дня осталось ВСЕГО шесть часов, а тебе на ревью прислали 500 строк кода!!!"
Походу не только у программистов так работа поставлена. Очень много где видел.
Очень приятная подача материала. Несмотря на то, что от программирования я далек, с удовольствием посмотрел ролик. Даже реклама удивила. Не просто перечисление достоинств спонсора, но целая история, благодаря которой можно проследить за ходом мыслей рассказчика и что-то для себя подчеркнуть.
Мне, как джуну было интересно, особенно про фикс багов поо месту (знаю что так нельзя, но из-за невысокого скилла слишком часто и сильно тянет так делать), про форматирование файла тоже заставляет задуматься, пожалуй больше не буду так делать или буду отсылать правки по формату отдельно, чтобы можно было принять быстро
"Все переписать" встречал даже таких активных новых ребят, которые это предлагали в легаси системе с 8-ми летней историей...
Сам не так давно переписывал приличный кусок(далеко не всю имеющуюся систему) функциональности. Планировалось в общей сложности управиться в 3 месяца...управились в 5 и еще 2 месяца отлавливали баги...
Очень зашло: что-то актуально мне сейчас, что-то знакомо, что-то полезное. Спасибо большое! (Переучиваюсь в 39)
Не знаю что там было на видео, до конца не досмотрел, но внимательно дослушал. Классный формат типа около подкаста и информация жизненная. Однозначно лайк)
Спасибо! Спорить с людьми не выслушав не стоит всем, не только программистам) а что до остальных пунктов, то, да, вы всё правильно говорите, но жизнь так многообразна. Три года я поддерживал один старый проект для очень большого иностранного банка. через год работы узнал, что моя рабочая станция в сети банка - продакшин сервер нашего проекта. всё нормально было, никто не пострадал) ревью это вообще любимая песня. слишком много людей любят ревьювить чужой код повышая своё ЧСВ и слишком мало относятся к ревью серьёзно. было в моей практике, что ревью помогали, но чаще случалось, что приводили к совершенно неоправданным задержкам деливери без малейшей пользы для кода. и про юнит тесты тоже история известная... в целом, по большому счёту, программисту можно всё. лишь бы потом всё хорошо было)
очень сильно согласен, ревью какая-то порочная практика, пользы от нее с гулькин нос, а минус телега.
Если код работает, выполняет свою задачу и на него написан тест - он имеет право попасть на прод. Исключение если человек сам хочет чтобы его код посмотрели. И обычно при сложных фичах люди таки хотят вторую пару глаз.
@@avonaryagami слышал, что когда Оракл купил Солнцевских из Оракла в Сан прислали инструкции отправлять код на ревью в Оракл. Из Сан ответили вопросом "а у вас есть компетентные специалисты?".
Обычно в компании коммиты в мастер и девелоп напрямую запрещены политикой репозитория, только через мерж пулл-реквеста. Ну и если был аппрув пулл-реквеста и внесены изменения, то аппрув слетает, то есть пока ревьюер не посмотрит ещё раз, ничего не смержишь ;)
Когда вижу свой старый "говнокод" , то всегда хочется полностью переписать
3:42 "Создать кластер, это делается за минуту. Я даже рассказывать вам про это не буду. Открываем панель управления..." 🤣🤣🤣
Смотришь на совой же код, написанный год назад и думаешь: "какой же это пиздец". Надо всё переделывать... но потом понимаешь, что переделывать - это просто дохуя времени, которого и без того ни на что не хватает :)) Ну и дописываешь то, что есть по итогу :)))
12:18 Блин! Ты прям в точку. Пару недель назад именно так и было. Поменял пару строчек и решил поправить все пробелы, отступы и переносы. Потом глянул на список изменений и понял, что мои 2 строчки там просто потерялись. Пришлось сделать усилия и отменить почти все лишние правки. Только то, что рядом с основными изменениями оставил.
Большую часть, из того, что вы говорите, я не понимаю, но всё равно благодарен вам и смотрю с удовольствием.🙂
У меня еще есть спорный пункт
Часто по процессам нужно передавать на тестирование баг или фичу после прохождения ревью. Но мне попадались проекты где ревью было очень долгим, и изза этого не удавалось успеть под релиз. Например ждешь правок день, выкатываешь что-то по комментариям, опять ждешь. Хотя тестировщик может взять на тестирование уже прямо сейчас.
В итоге в какой-то момент, если оценивал что комментарии врядли вызовут серьезные переделки, то заливал апдейт в тестовый стейдж прямо из моей фича/багфикс бранчи
Часто удается сильно выиграть время. Но иногда получилось заставлять тестировщика проверять одно и то же 2, а то и 3 раза.
Хотя в целом тестировщики на моей практике все равно отмечали больше плюсов у такого подхода
тут вопрос регламентов
если по регламенту допустимо до 24 часов ревью проводить, то значит это такая скорость проекта, и это нормально
Если же выходит за регламент, то это уже нарушения, и надо обращаться к комуто. К начальству или еще к кому.
Вообще фраза *"тестировщик может взять на тестирование уже прямо сейчас"* не выглядит правильной, если по технологии нужно сначала провести ревью. Это все равно, что: я уже готов сейчас выложить картошку на сковороду, но она еще не нагрелась.
@@Das.Kleine.Krokodil Да, как правило так было в местах с сильно поломанными процессами
@@MrFijirald ну если процессы поломаты, то только на личной иннициативе выезжать
изучите Trunk Based Development. Думаю в Вашем случае решит все проблемы.
Жизненно!! И очень большая плотность информации в видео, это сегодня радует!
Офигительное видео! Несколько раз чуть не заорал вслух "как же жизненно!"
Я не являюсь программистом, но услышал кучу полезных советов! Спасибо!
По всем пунктам в точку 👌 Стоит только отметить, что всего сказанного не стоит делать исключительно из-за вашей лени или прихоти. Порой дедлайны просто не оставляют выбора. Тот же «дешевый фикс» иногда единственное возможное решение - в сжатые сроки бывает невозможно разобраться с гнилым легаси, который до тебя фиксили вот такими же быстрыми заплатками.
Значит, задача поставлена некорректно.
Лёша красавец, продолжай)))
Пойти за хлебом в рабочее время это вообще не считается каким-то криминалом у нас на проекте, это как пойти к кофе поинту с кем-то по болтать в старые времена
Ох, как жизненно! По ходу повествования "ткнулся носом" буквально во всё, что было, есть и возможно ещё будет есть.
Алексей, предлагаю записать видео про то как "правильно" составить резюме и как его поддерживать/улучшать. Знаю, тема сложная, но думаю будет интересно узнать от Вас это.
Спасибо, что лайкаете. Продолжайте в том же духе, надо чтоб Алексей увидел нас.
Солидарен с Вами!!!
+
+
+, работаю уже много лет, а резюме так и не сделал актуальное
Для меня самое эффективное оказалось пополнять файл по мере того что я хорошего сделала. Когда нужно отправлять резюме у меня есть куча инфы какая я молодец. Без этого все достижения забываются у меня))
Как говорят, если итальянцу связать руки, он не сможет говорить.
Мне кажется у вас есть итальянские корни. )))
* Спасибо за ваш труд, прям видно что каждый пунктик выстрадан на собственной шкуре
Шикарный выпуск. Новичкам на носу зарубить всё это.
Я еще не программист, но уже хожу за хлебом в рабочее время🥳
Алексей, у вас всегда самые интересные и полезные видео👍🏻👏🏻
12:16
Меня всегда учили и я взял за правило, отправлять переформатирование отдельным пулл-реквестом. Чтобы его отдельно ревьювили, и оно не мешалось с изменением логики.
Даже отдельным коммитом можно. PR не так сложно смотреть будет. Плюс есть линтеры/стайлкопы, чтобы кривое форматирование не пушили.
6:23, спасибо, больная тема... у меня не кодинг, у меня учёба, тонны новой информации и отвлекаешься постоянно, причём делаешь это не осознанно, осознаешь только когда уже отвлёкся и занят чем то другим... я всё не могу понять, толи у меня мозг слабый, толи это у всех так...
Спасибо за подборку! Мне кажется, было непросто разложить всё по полочкам так, но это действительно круто. Можно даже какой-нибудь лист А4 с этими мыслями составить!
12-40 - спасибо претиеру с другой конфигой который норм так глаза помозолил ревьюверам)
Я не так давно начал учиться, написал прогу и первые фиксы делал как раз прямо на сервере через nano ))) что мне очень понравилось )))
Спасибо за видео.Коммент в поддержку!
Алексей, огромное спасибо за мысли, они и правда имееют место быть! Еще раз спасибо за твои труды!
Не знаю насколько это самоочевидно
Нервы и сон бережет такая практика - быстро накидать прототип с максимальным количеством заглушек. На кнопках, где функционал еще не готов, не вешаем onclick. Нет текстуры - вешаем котика. В простейших случаях это значит нарисовать ui и закодить все базовые переходы. После этого в любой момент если придут и прикажут показать что есть, можно будет предоставить"почти" готовую апку. После этого работать становится сильно легче. Дэдлайн по крайней мере не давит.
Это я к пункту "Не уйти домой в 6 часов, бросив на полпути". В случае схемы выше, бросать можно в любой момент после написания прототипа.
Предлагаю записать видео по теме "Разногласия и конфликты в команде."
Я не прогер, но какая-же жиза)) Про постановку задач и прокрастинацию вообще в точку)
О, дебажить код на продакшене, это любимая тема моих коллег с предыдущей работы )) Камень в огород Директора ИВЦ, надеюсь ты это прочитал ))
А на предложение что нужно пользоваться гитом и тестовую среду хотя бы поднять, я получил ответ, что это мне только надо.
Хотелось бы видео по уровням английского в иностранных компаниях. Какой уровень для каждого уровня программистов. Где используется высокий уровень, как общаться вживую с носителем-клиентом, работодателем, индусом
Супер видео!!
Надо не соглашаться на чужие эстимейты + уметь закрыть ноут в 6 вечера.
Но я так пока не умею)
Дельные советы) возьму на вооружение)
Как по мне оказалось проще совместно кодить огромной командой когда находишься на огромной круизном лайнере тем самым плавно совмещая работу + отдых + развлечения в одном флаконе попутно путешествуя по всему миру.
А разве есть такие?
@@igorjeddex7942 звездит
Про продуктивность за час до конца рабочего дня это в точку. У меня то же самое. И не важно, в какой сфере.
эх, встать в 18 с рабочего места (я дома работаю) и забыть про работу - совсем не про меня последний год, ибо ремонт и ребенку на всякие кружки в другой конец города надо не к 18-19, а к 17, и чтоб наработать положенные 8 часов порой приходится и до 2 ночи сидеть, ибо в середине дня на час-два отъезжал по вопросам ремонта, а потом за пару часов до конца рабочего дня отбежал еще на 2-3 часа по домашним делам....и в итоге конец рабочего дня смещается с 19 (ибо в 10 сел) на 19+4... а там еще пару строк кода дописать... и отдергиваешь себя уже в 2-3 ночи за шкирку спать (
одно успокаивает - это временно все
Наивный...
по поводу пункта 14. "соглашение с навязанной оценкой трудоемкости" иногда есть возможность сказать "Ну давай сделай сам за то время, за какое ты думаешь оно делается". А в ответ очевидное "А я не умею".
Вы так говорите про ревью - но на деле 100проц ревьюстов не лезут разбираться в реальную логику, а смотрят поверхности, и кроме как "там комментарий не понятен" или "тут можно сократить вызовы" - реальной логикой никогда не занимаются.
Так же некоторые глюки бывают в определенном юзере именно на проде, и увы приходится именно проверять на продакшене.
Всё в точку! :)
Нравится формат рекламы, в котором вы сами пробуете как это.
Даешь видео как правильно и не правильно писать тикеты!))
6:42
Вместо того, чтобы учиться программированию я смотрю Лёшины видео про программирование. 😆
Переписать чужой как "как положено" - это ж святое!!!! :) А то понапишут как курица лапой - хрен разберешься.
Всё вырубаю этот видос, хорош прокрастинировать...
В моей госконторе половина всего списка не делается. Спасибо, еще раз убедился, что надо менять место)
Личный совет по предварительной оценке трудозатрат:
- Если постановщик говорит "что тут делать? хватит и 15 минут"
Отвечаю без агрессии: "Зачем тогда я вам, если это так просто и быстро?" или "Покажите, как вы это сделаете за 15 минут и я вам заплачу свою ставку"
- Если у вас есть хоть капля сомнений, то либо увеличивайте сразу срок х2, либо поясняйте, что задача не выглядит понятной и засыпайте вопросами постановщика. Не бойтесь, задавая правильные вопросы, вы себя не выставите тупым.
- Если вы понимаете, что не успеваете, то сразу сообщайте постановщику. Да, он будет упираться и противиться увеличению трудозатрат, но и вы должны приводить аргументы: нет тестовых данных, нет доступа или прав. Если же задача оказалась просто сложнее или более трудоемкой когда согласился на такие трудозатраты или сроки: да, взялся за гуж - не говори, что не дюж. Придется поработать ночами.
да, нужно максимально сроки себе выбивать. Сделаешь быстрее-хорошо, все будут рады. Но зато не придётся ночами работать случаях, если задача сложнее оказалась, чем на первый взгляд
@@etb6250 нет, это расхолаживает и перестаешь сдавать "до". Потом когда надо будет соглашаться на дедлайн - можно профакапить жёстко.
@@TEENASPECT вряд ли так получится, что тебе вместо недели дадут три месяца времени. Так что как по мне, лучше взять неделю, когда реально требуется 5 дней, нервничать и недосыпать из-за любой непродуманной ситуации - это путь к выгоранию и проблемам со здоровьем
Благодарю за видео. Наверное, оно предупредит десятки моих косяков в будущей карьере. Спасибо.
Да. Зачёт...) Узнаёшь себя сразу...))
Прокрастинация очень страшная вещь, в отличии от лени невозможно себя заставить что-то сделать, через силу и нехочу, не получает
Любая важная деятельность вызывает отвращение
вы просто сильно устали и ленитесь решать эту проблему
@@tazmanov7738 похоже, это уже не прокастнация, а выгорание.
Похоже, задача сильно большая с неясным планом решения; или опять же большая, но очень скучная.
Спасибо за видео! Интересно, пару мыслей взял на вооружение)
02:08 шок-контент. Одна из сильнейших нативок, что я видел за последний год.
спасибо, Алексей, ценные советы!
Вот как раз для НТ продакшн БД и нужно использовать, обезличенные естественно.
Я понимаю, что для многих НТ это что-то типа АТ, только запускаемое много раз, но на самом деле любое хорошее НТ - это вообще другой тип тестирования, скрипты в котором выступают лишь инструментом для достижения нагрузки, и не более.
Поэтому да, для каких-то отладок фич, модулей, АТ - продакшн БД нельзя использовать, в то время как для НТ - это крайне рекомендуется.
Как всегда прекрасный ролик! Огромное спасибо)
"А иногда повезло и старого кода нет совсем 😂"
Интересный ролик, мне понравился)
Алексей, у нас в команде принято на уровне настроек atlassian stack, что для merge в develop необходимо: 1. не менее 2-х апрувов на код ревью + я могу наложить вето 2. удачный билд с юнит тестами 3. удачный деплой на dev стенд 4. отсутствие ошибок при миграции БД на dev стенде 5. пройденный скан с помощью Sonar 6. апрувы сбрасываются в случае дополнительных комитов 7. комитить в мастер и девелоп можно только через пулл реквест.. 8. покрытие кода должно быть на уровне +- 80% . Я как devops не могу позволить своим разработчикам вольности в git :)
Чем больше ограничений, правил и проверок - тем медленней скорость выпуска новых фич. Для пререлизной версии one-page приложения такой workflow явно избыточен, а для новой версии автопилота в самолёте - недостаточен. Про этот баланс хорошо написано в книге "практики системного и сетевого администрирования"
@@boikov , просто человеку еще не прилетало за раздувание TTM.
@@ne4to777 Просто это время должно учитываться при планировании. Это описание обычных проверок в ci\cd. Я бы только убрал проверку на покрытие тестами, иначе рефакторинг нельзя вмержить (после него кода часто становится меньше и покрытие падает)
@@ne4to777 Если потребуется провести фичу или багфикс в нарушение договоренностей - мы сделаем это с минимальными проверками(например недавно пришлось вывести фичу совсем без покрытия тестами). Речь идет о стабильности релизов в условиях отсутствия факапов и особых нарушений дедлайнов. Если сборка, деплой или миграция БД на dev/stage будет неуспешной - зачем пытаться выводить это в prod, для того чтобы заниматься откатом?
все это звучит как челендж того, что я собираюсь сделать за один рабочий день завтра
Послание понятное, Браво, браво!
К счастью, половина пунктов закрывается правилами команды и компании - у нас например нет доступа к проду и его базе, нельзя пропустить код ревью или тестирование. Так что остается только бороться с отвлечениями, соблазном заапрувить что-то не глядя или зафиксить багу не вникая.
Немного отвлекаться в рабочее время имхо все же можно, хотя бы чтобы дать мозгу передышку, можно в том числе переключится и что-то поделать дома - на столе прибраться, растения полить, чаю сделать, но вот об отлучках из дома все же стоит предупреждать, чтобы не попасть в неловкую ситуацию.
красавчик реакт натив топ)
9:50 - как же похоже на правду...
Никогда не понимал и не особо хотел vim. Возможно придется
Не факт. По большому счету он был удобен в консольной системе. А многие ли сейчас работают в консольной сессии?
@@arinelex мои предпочтения уже поменялись.
Немного почитав про vim, начал его активно использовать. К тому же, как linux пользователь, с терминалом я работаю постоянно. Не потому, что я не умею устанавливать DE, но потому-что мне нравится клавиатурный интерфейс
РОНЯТЬ ПРОД
РОНЯТЬ ПРОД
РОНЯТЬ ПРОД
Когда я увидел таймкод "реклама " , я подумал , что будет какой-нибудь совет , отучающий от бездумной рекламы, а нет это просто реклама
Супер!
Пять баллов!!!
Спасибо.
Половина ситуаций это про меня :)))
Большая часть советов подходит к любой профессии.
Разработка и тестирование на тестовом окружении - для слабаков 😁, только продакшен, только хардкор!
Был случай: чуть не поседел, когда толком не разобравшись жахнул изменения сразу на проде...
Выпуск класс !!
Когда только начал учиться программированию и понимаешь, что помимо русского и английского есть отдельный язык на котором говорят программисты, где найти уроки по нему?))))
Лёша, было бы очень круто увидеть тебя в подкасте «мы обречены»
Я согласен с тем, что не нужно сразу соглашаться на изменение сроков выполнения задачи, что не программист не может оценить адекватно сроки, но у нас менеджеры работают с бэкгрундом разработчика, хотя он тоже может свое мнение навзязать со своей колокольни, за какое время он бы выполнил задачу, а не я, начинающий.
Видишь ли, оценка делается так: задача детально описывается и разбивается на итерации продукта от начальной до релиза исходя из функциональности промежуточных результатов, а итерации - на подзадачи, те - на подзадачи еще меньше и так до тех пор, пока длительность мелкой подзадачи не будет очевидна. Называется это "WBS" - work breakdown structure. При этом бывает полезно использовать программулину с диаграммой Ганта для учета зависимостей между задачами и автоматического суммирования. MS Project слишком монструозный для небольших проектов, и есть огромное количество недорогих или вовсе бесплатных инструментов. Вроде просто, да? Но здесь есть один косяк: ВСЕГДА что-то в этом списке задач будет упущено. Поэтому ВСЕГДА надо делать поправку. Есть шутка: если в задаче все понятно, и нечто похожее ты уже делал и помнишь - поправка равна числу E, а если ты похожего не делал - то Pi ... Реально же для вычисления поправки нужно смотреть собственную статистику промахов оценка/реальность...
А потому - лажают с оценками все. И начинающие, и опытные
3:33 главное, когда устраиваешься на профессию девопса, не стать девоПСОМ