Источник счастья⁠⁠

Особенно если ТС не пишет, как решил проблему и в чем она была, когда у тебя ровно та же проблема

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

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

Умерьте пыл. Во-первых, что плохого в том, чтобы быть джуном? Во-вторых, периодически все ими бывают. Так, около 6 лет назад все iOS-разработчики стали джунами. Ну просто потому что никто из них до того не писал на Swift, не было до 2014 никакого Swift потому что. Скорее, плох тот, кто никогда не бывает джуном, потому что это значит, что человек не изучает ничего нового.

А что, не бывает багов не в коде, а, например, в фреймворке? Или в чужой библиотеке, которую ты используешь вполне таки в своём коде?

Ваше мнение очень важно для нас!

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

Лично я всегда готов сказать заказчику «нет». И часто это действует волшебно. Из серии:

— Каждый пятый спринт мы будем работать над качеством кода, поэтому в эти спринты мы не будем добавлять функциональность в продукт.

— Я не согласен.

— Значит, мы не готовы взяться за ваш проект, извините.

— Почему?

— ...

И далее идет объяснение, почему. Потому что это экономит время в долгосрочной перспективе, потому что мы следим за качеством продукта, потому что у нас так принято, мы это не просто так выдумали и это часть технологического процесса, может, мы еще и на тестировании экономить будем? — да что угодно. Люди в большинстве своём весьма некомфортно чувствуют себя, когда им отказывают, и если вы реально готовы им  отказать, если они не будут работать на ваших условиях, то шансы на то, что они согласятся, резко повышаются. Ну а если заказчик не уважает вас, как профессионала, то это либо повод усомниться, а профессионал ли вы на самом деле, либо нужен ли вам заказчик, который не уважает ваш труд. Я свой труд уважаю, поэтому не работал (я сейчас ушел в другую сферу) с заказчиками, не согласными с моими условиями.

Я понимаю, о чём вы. Но в приведенной мной ситуации всё же правильнее вставить костыль, а нормально решить вопрос позднее, чем рисковать, что заказчик не получит нужную функциональность вовремя. Это приоритетнее в данном случае.

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

Нужно договориться с заказчиком, что каждый четвёртый-пятый (кому сколько требуется) спринт в продукт не будет внедряться никаких новых функций, и весь спринт будет целиком и полностью посвящен работе над качеством. Здесь и удаление костылей и замена их на нормальные решения, и рефакторинг, и даже задачи, напрямую не связанные с кодом. Заказчику при этом объясняется, что 20-25% времени разработки, потраченные на улучшение качества продукта "изнутри" позволят работать эффективнее в оставшиеся 75-80% времени, экономя разработчикам в среднем по 40-50% времени на задачу, и таким образом общая продуктивность команды будет только выше.