Да, если бы можно было достичь идеала - определение "тех долг" рожденное в 1992году до наших дней бы не дожило. Стремясь к идеалу держим хотя бы баланс.
Вот это нормальный видос, не то что некоторые платных уроков понафигачат, где один код и после этого, как наложат в один контроллер, что убирать никто не хочет за такие ковришки. Бывает ещё такая ситуация, контроллер нормальный, но этот говна чертёж лежит где нибудь в наблюдателе или в другом паттерне, который писался две недели и иногда заказчика лучше не пускать на черновик(другой домен под паролем для демонстраций) Он говорит, у тебя же все работает, что ты там ещё делаешь, погнали дальше, давай в продавшего, некогда ждать, потом доделаешь и задачи, задачи, с пониманием, что если придёт такой, который в контроллер кладёт, точно не разберёт, как он дебажить то будет, если там ещё очереди с элементами сложных алгоритмов, что даже опытный возможно откажется ну и ничего не сделать, так руки не доходят, только надеешься, что расширение функционала в том поднаправленнии не потребуется, а то прийдут коллекторы)))
Мудрое видео. Видел проект который в третий раз переписывали из-за технических долгов и всë равно наступают на те же грабли. Конечно, опытные программисты будут стоить дорого для бизнеса в такой ситуации, если они ещë согласятся работать с этим говнокодом.)
Спасибо за видео. Все детально и по полочкам. Такое ощущение, что теоретическая часть для видео формировалась на базе той фирмы, на которой я сейчас работаю. Передам это видео высше стоящим, как шанс на просветление.
Дмитрий расскажите пожалуйста используете ли Вы в своих проектах DDD (domain driven design), может есть уже материал на канале (пойду посмотрю про пицца код). Какую структур разработки используете Вы. Есть пакеты для организации структуры в виде модулей (к примеру: nWidart/laravel-modules). Что посоветуете?
У нас в наличии базовая архитектура laravel котрая частично мутировала сначала в сервисы, затем в модульность. Сейчас модульность обретает черты porto. Рекомендовать могу "чистая архитектура" Мартина (при условии что Чистый код изучен) и porto
У меня сейчас на проэкте такая же ситуация, куча хардкода из за вечной спешки клиента и его грандиозных планов, всегда надо здесь и сейчас, еще очень класно что он не зная кода умеет делать эстимейты, эстимейт 2 часа в итоге 4 дня, нервам уже конец - хочется застрелится, я уже ненавижу кодинг реально хочется заниматся чем то другим... Протсо жизненно мужик говорит !
)) А как уговорить клиента на закрытие техдолга (не своего) когда клиент требует новых фич, а всё уже погрязло в долгах (или такая перспектива погрязания маячит уже близко)?
@@VladimirKrygin-j4d Так и сказать - "от этой фичи и дальше будет увеличиваться время добавление этих самых фич". Тут другая проблема - клиенту на все эти премудрости пофигу. И технический долг становится лишь удобством разработки. В маленьких фирмах не хватает людей и чтобы не упустить клиентов, рефакторинг задвигается очень глубоко. В крупных рефакторят параллельно. В общем, проблема технического долга эта по большей степени внутренняя проблема компании/команды разработчиков и клиенту про эту проблему рассказывать... ну такое себе.
Дмитрий решил уничтожить проблему говнокода в корне. Меньше программистов пишущих говнокод - меньше проблем с проектами на говнокоде. Не можешь победить врага - возглавь его
Не дежурное спасибо. Редкий случай, когда не заметил как видео закончилось и хотелось еще. Для себя сделал выводы, что не нужно "стрелять пушкой по воробьям", не лениться и уметь моделировать развитие ситуации на пару шагов вперед(а вдруг заказчик тут захочет чего-то, а вдруг я буду этот кусок кода использовать часто и лучше его вынести куда-либо, например в хелпер и т.д.). Но сам в "долгах как в шелках" ) . Вопрос: можно ли считать умышленные тех долги неким механизмом защиты своей "нужности" со стороны разработчика, этакой страховкой и были ли в Вашей практике такие подозрения или конкретные ситуации?
Спасибо за комментарий. 🙏 По вопросу - это больше похоже на вредительство человека с низкой самооценкой. Опасаясь что не сможет найти работу в другой компании умышленно нанося вред создает свою незаменимость. Походу тут надо к психологу сходить на пару консультаций - разобраться в причинах низкой самооценки. К счастью такого не встречал. По полагаю таким говном занимаются наши чиновники - "троечники" дорвавшиеся до власти. Надеюсь среди программистов таких нет.
@@DmitryAfanasyev Спасибо за ответ. Только подтвердили мои догадки - беда в голове. К своему сожалению, встречался с такими людьми, работая в саппорте на "первой линии обороны". Данные товарищи очень резко реагировали на критику своих творений(был доступ к небольшой части скриптов). И еще один вопрос: опираясь на Ваш опыт, кто больше влияет на "долги": заказчик или разработчик(включая начальство)?
Чаще всего виноват разработчик. Заказчику не надо знать процесс решения задачи - эскиз, рефакторинг, тест. Чаще всего разработчики сами выбрасывают шаг "рефакторинг" даже когда нет команды ASAP. Заказчик об этом шаге чаще всего узнает когда долг накопился и надо выделять ресурсы на оплату долгов. Вот именно тогда надо объяснять, уговаривать, убеждать и тп.
Всё по делу, спасибо. Правда невозможно отрефакторить код который ты сначала написал, если ты закончил писать, то считаешь что код хороший и выполняет поставленные задачи. Про его качество ты узнаешь в процессе тестирования, и скорее всего это понимание придет от кого-то другого
Спасибо Дмитрий за видео. Однозначно лайк. Скажите, у вас есть возможность записать видео - как сделать поддомены для городов. Весь инет перерыл, путного ответа нет. для москвы - > сайт.ру (без поддомена) для питера - > спб.сайт.ру для новосибирска - > нск.сайт.ру решается путем в роутах: 'domain' => '{domain}.' . env('SITE_URL'), контроллер public function index($domain) но вот только не задача, когда в роут приходит null по москве выдает 404 ошибку. и как и где ее ловить))
Никогда не знаешь пригодится ли этот проект кому то еще, поэтому в мелких проектах много технических долгов)) А самое интересное что за это никто не хочет платить поэтому от этого не куда не денешься, заказчик не понимает что ты тратишь на рефакторинг дополнительное время
Свой и чужой опыт. В идеале надо чтобы задачу перед заливкой смотрел всегда второй программист и не сам внес правки, а написал рекомендации, пояснил почему надо сделать именно так и вернул на доработку.
Присти за такой глупый вопрос но примерно с 20 минуты ты говоришь что делать толстые контроллеры и модели это плохо. Я посмотрел твой курс по laravel и дальше репозиториев не нашёл как сократить код в контроллерав и моделей может ты будешь дальше пилить курс по laravel и там будешь уже учить как правильно писать у меня почти каждый контроллер от 100 до 200 строк кода это без репозиториев а если я добавляю репозитории то весь код будет в них хранится и в чём это лучше? перекидывать код с одного места в другое?
@@DmitryAfanasyev Два года уже учусь программированию и понимаю благодаря тебя что я нифига не чего не понимаю((( если у вас будет свободное время то можете продолжать развивать курс по laravel? Вы единственный кого я смог найти кто говорит что толстые контроллеры это плохо а все остальные учат что это норм
@@DmitryAfanasyev Понял спасибо за ваши труды в образования нас при том что-это бесплатно остальные бы потребовали бы не хилую сумму для изучения. И ещё если вам не сложно знаете ли вы какой нибудь репозиторий на git с хорошим кодом для примера хочу посмотреть как должен выглядеть хороший код что-б к ниму стремится
@@DmitryAfanasyev Ещё есть идея для ваших будующих уроках как на счёт того что-б брать готовые проекты с хорошим кодом и обозревать их что-б было наглядно что такое хороший код