Тест на профпригодность или Этапы решения задач
HTML-код
- Опубликовано: 21 окт 2024
- Кент Бег, создатель TDD (разработка через тестирование) и один из основоположенников Экстремального Программирования (XP) высказал очень интересную идею, а именно Этапы решения задач. Помимо самого алгоритма данные этапы можно использовать как "лакмусовую бумагу" для определения профпригодности разработчика. Подробнее смотри в видео.
#чистый_код #программирование #разработка
*
Источник: "Чистая архитектура" Роберт Мартин Изд "Питер" 2021 стр 250 (Купи, изучи эту книгу, и остальные книги Роберта Мартина, и тебе больше не потребуется смотреть видосики от всяких it-блогеров)
► www.ozon.ru/ca...
► www.chitai-gor...
*
★ Автор: Дмитрий Афанасьев.
★ Канал: clck.ru/JVYct
*
► Выразить благодарность, поддержать донатом развитие канала.
★ www.tinkoff.ru...
★ www.donational...
*
► Еще интересные курсы:
★ Видеокурс по Laravel: clck.ru/JVYa2
★ Видеокурс по Git: clck.ru/JVYYm
★ Объяснение SOLID: clck.ru/JVYXq
★ Шаблоны проектирования: clck.ru/JVYX7
★ Структурные шаблоны проектирования: clck.ru/TVB9Y
★★★ Все курсы → clck.ru/JVYVd
![FNAF vs TF2 - Episode 2 [SFM]](http://i.ytimg.com/vi/z5b3V2-VLb0/mqdefault.jpg)
![Porto: Архитектурный шаблон [ Базовые концепции ] ► Порто №1](/img/1.gif)
Снимайте больше видео пожалуйста. Очень помогают в обучении.
Ну это о задачи зависит. Рефакторинг не всегда получается сделать.
И от архитектуры проекта тоже зависит.
Задачи часто типовые. Берем уже готовый компонентт за основу и так же делаем - получаем сразу вписанный в архитектуру код.
И еще хотелось бы курс(видео) по тестированию на PHP :)) было бы интересно и полезно посмотреть
При любом удобном случае оставляю ссылку на твой канал. Благодаря тебе, не побоюсь теперь этого слова коллега, я познал все CMS и фреймворки мира. Ты заложил основу и ссылки на знания, пускай не все переданные тобой, но через с твоей помощью указанные пути. Три года с тобой мастер!)
Бля, ну подписался оказывается только сейчас
Благодарю! 🙏
Спасибо, Дима) очень полезное видео
Накипело!😉 Чувствуется прям видос снял для своих подчиненных)
У нас хорошая команда )))
Как обычно, на одном дыхании. Спасибо.
🙏
Есть в планах что-нибудь по Symfony? Я думаю, для знающих Laravel будет полезно увидеть другой подход в формировании архитектуры.
Архитектура не зависит от фреймворка. И 9аконы архитектуры всегда одни. А что касается курса по симфони, в ближайших планах его нет.
С новым годом!
Студентам своим как раз показываю, сперва делаю, потом рефакторим и оптимизируем)
Канал бриллиант по программированию. Спасибо
Тут возникает еще один БОЛЬШОЙ вопрос. Сколько времени отводится на решение задачи? Дается ли время на реализацию 2 и 3 пунктов? Понимает ли менеджмент, что это за пункты и чем программист будет заниматься это время? Нередко бывает так, что управление проекта только слышали эти слова - "рефакторинг", "оптимизация". А если завести об этом речь, получаем ответ дескать сейчас на это времени нет, будем это делать потом сейчас нам надо реализовывать новые функции... И в таких командах программисты работают годами.
Все 3 пункта и есть решение задачи. Убрать один из них - задача не решена, а то что "оно" работает - это не решение, это нанесение вреда, который даст о себе знать некоторое время спустя.
"Кент Бек" ващето))) орал весь видос, когда автор произносил "Кент Бег"
Ну хоть проорался!
@@DmitryAfanasyev спасибо)))
Отличное видео)
Всегда делаю так интуитивно)) теперь знаю что иду по пути профессионализма))
делая первый пункт, думаю о втором и третьем. да и чтобы потом что-нибудь не забыть, ещё комментариев лучше накидать
спасибо за труд
/*TODO*/ ;))
Dmitry Butler
Спасибо за урок , очень качественно и как всегда с юмором!
Большое спасибо!
Методом проб и ошибок эти вещи начали пробегать в головушке.
Теперь вижу, что похоже это тру вэй.
Однозначно в закладочки.
Дед мороз контент подогнал. Спасибо :)
Четко!
Была задача когда ещё джуном был на испытательном сроке, до меня делал разработчик статистику, там 37 тысяч запросов в дебагбаре(профайлер в симфони) было на вывод статы)) Вот это жесть была, аж целую неделю пришлось разребать. Причём обязательно оптимизацию надо смотреть на прод-базе, а не на тестовой/стэйджинге, ибо разница может быть огромной.
Это к теме оптимизации, спасибо за видос :)
В ларе чаще всего такие страницы (с 100500 запросами) появляются когда забывают сделать жадную загрузку... И да, бывает что либо на тестовой бд, либо на малом объеме записей это можно упустить.
@Dmitry Afanasyev В симфони есть способ просто вытаскивать все данные через коллекцию сущности, а потом от её элементов по отношению геттером вытаскивать ещё подэлементы из других таблиц, этим способом крайне не рекомендуется пользоваться)
Это нечто вроде такого вышло "под капотом":
$analytics = 'select id from analytics'; // берём всю стату
foreach ($analytics as $analytic) {
$exhibitor = 'select name from exhibitors where $analytic[id]'; // на каждый элемент-строку статы по отношению берём из другой таблицы
}
Тому в симфони надо орм-билдер-запросы сразу же писать, использовать where, джойны, агрегатные функции и т.д)
Спасибо очень годно
Ура ура ура !)
С новым годом !))) на первом пункте останавливаются обычно только на бомж проектах из фриланса
🙏 Взаимно!
Позвольте уточнить. Вы на собеседовании требуете три пункта сразу? Или это типа домашнего задания? Если домашнее, то все понятно и логично. Если на собеседовании, то насколько велика задача и сколько на это отводится времени? При этом гуглить/маны разрешено я надеюсь?) И последнее, если не сложно поделитесь задачей, или хотя бы аналог ее ( интрига:) ) Хочется понять объемы и сложность по 10 бальной шкале
Уже давно не даем задачу на собеседовании. А когда давали, соискатель решал ее до собеседования и на собесе обсуждали решение.
По поводу оптимизации - Вордпресс и Магенту сразу можно гулять отправлять.
Смотря какой проект. Если нагруженный, то может и стоит.
Дмитрий, где можно почитать поподробнее про этапы решения задач от Кент Бега? Насколько знаю его идею про TDD его идея заключалась в так называемом «красный-зеленый-рефакторинг». Сначала напиши тест, чтобы при запуске он фейлился. Потом максимально быстро напиши код, чтобы тест прошел успешно. А потом занимайся рефакторингом кода. Вы про эту идею хотели рассказать в видео или про что то другое?
В описании к видео указал источник.
Спасибо!
Спасибо большое, очень полезное видео.
Сейчас пока на уровне Джуна, всю логику кидаю в сервисы. Хотелось бы как-то узнать о правильной архитектуре, что посоветуете?
Роберт Мартин "Чистый код", "Чистая архитектура"
Очень интересно посмотреть вариант декомпозиции в деле. Как из плохого кода получить хороший. Литературу или видео. Спасибо
Роберт Мартин "Чистый код"
Да, согласен)
Ураа
Это конечно здорово и мимимишно, но в подавляющем большинстве случаев реальность такова, что 90% рынка будут решать задачи здесь и сейчас. Все эти архитектурные решения, ресерч, покрытие тестами и т.д будут делаться либо себе в убыток, в нерабочее время, либо в собственных пет-проектах.
Увы, но как показывает опыт, "чистый код" это удел интерпрайза и опенсорса, и то не всегда. Малый и средний бизнес требует "быдлокод" для решения ситуативных задач. И насколько бы ты не был убидителен, менеджмент таких компаний слабо понимает профит от грамотно спроектированного и написанного приложения.
Есть отличное высказывание на эту тему от ExtremeCode, с которым я в целом согласен. В общем как мотивирующий ролик по саморазвитию - да, как руководство к действию - нет. Либо придется искать софтвер компанию с пониманием стратегии и процессов, либо выгорание через пол года диких перероботок тебе обеспечено.
Кстати это одна из тех причин, из-за которой становится IT специалистом только ради зароботка, самая безсмысленная вещь на свете.
Анекдот:
- Учитель, а мне когда-нибудь пригодится эта ваша математика в жизни?
- Нет. Она пригодится только умным детям.
Мораль: Какой прием чистого кода (рефакторинга, архитектур) и когда применять - решение за разработчиком.
Суть в том чтобы это ЗНАТЬ и УМЕТЬ. А говорить - "Всё херня, давай по новой" и исключать из своего обучения эти знания - удел вечных джунов.
Плох (лох?) тот казак, что не мечтает стать атаманом!
@Dmitry Afanasyev Программирование, как и иностранный язык, это не умение, а навык. Грош цена теоретическим знаниям без их реализации в живых проектах. Можно сколь угодно долго рассуждать о патеррнах/алгоритмах/solid'ах, но до тех пор, пока это не будет применено в реальной разработке и желательно не один раз, понимание степени надобности, или в некоторых случаях бессмысленности, само собой не придет.
Мало того, что это не везде применимо и оверинжениринг не меньшая боль чем "чистый код", который к слову утопия. Часть из этого может быть применена только в специфических задачах, детектирование которых приходит только с опытом. В реальности же, если ты фриланс-трюкач или галерный-подданый, имплименить такой подход в каждом своём проекте, это самоубийство и гарантированно скорый поход к психологу или кардиологу.
Здорово, если тебе выпал шанс стать счастливчиком, которого в мир большой разработки проведут за ручку взрослые дяденьки и в довесок дадут площадку для саморазвития и игрушек. На практике такой шанс выпадает единицам и ты либо попадаешь на галеры, либо заходишь в программирование через фриланс.
Поэтому еще раз повторю свой предыдущий месседж для тех, кто будет смотреть этот видеоролик. Первое - важно не количество использованных "паттернов", а понимание для чего они были использованы. Второе - если ты работаешь в нижнем сегменте рынка, не лезь оно тебя сожрет. Третье - хорошего кода не бывает.
Все эти вещи должны применятся осознанно, а главное там где от этого можно получить эстетический, профессиональный или материальный профит, а не убитые нервы или сожженную психику. Хочешь прокачать скилл, заводи пет-проект необходимый для автоматизации собственных задач и пили "красиво" или ищи компанию где не похер на то как работает их продукт.
Говорю на своём опыте, сэкономите много нервов и сил :)
😍❤❤❤❤🤟👍👍👍
Простите что беспокою но у меня есть пару вопросов местами не связанны с темой видео
1) Что делать если куча моделей?
например зауженный пример есть категории там связи с дочерними категориями и с товарами мне их нужно загрузить хоть я и использую ленивую загрузку но в игоге моделей дохера одно из решений это самому прописывать sql запросы со всеми join и тд но они пизде* какие тяжёлые не ужели нету другого способа?
2) Как мне правильно кэшировать результат запроса?
Например есть 100к товаров как мне его правильно за кэшировать пару вариантов
За кэшировать 100к товаров с модельками и работать уже только с кэшью. Если товар поменялся то вносить изменение в кэш и в базу. Мне этот вариант не нравится так как кэш будет слишком большой и медленный.
За кэшировать частями но если товары добавляют сами пользователи то как мне узнать какой части кэши находится товар ?. Проходить по каждой кэши искать товар рессурсо ёмкая задача. А если товар захотят удали к примеру есть 100 кусков кэши по 100 товара и пользователь удалил товар то в одной кэши будет уже 99 товаров а выводить 99 товаров на страницу уже не красива так как вёрстка была рассчитана на 100 товаров пересчитывать кэш это затратно по ресурсам
Судя по видео проф не пригоден
Хорошие вопросы. Вариант для отдельного видео.
@@loadmore все начинают с профнепригодности, и я тоже. Главное не остаться в этом...
@@DmitryAfanasyev Понял жду видео) надеюсь на все вопросы будут ответы.
Уверен что Дмитрий снимет более понятно и полезное видео, но попробую добавить свое ИМХО.
Серебряных пуль не существует, для каждой задачи оптимальным будет свое решение.
То, на что я бы обратил внимание
1. Да join самое лучшее решение в разрезе "цена/качество" решение.
2. Посмотрите в сторону индексов, порой это сходу решает задачу, но тут надо понимать к каким данным это применяется
3. Судя из того что вы описали, возможно вам поможет денормализация БД или настраиваете репликацию чисто для SELECT запросов. Тяжесть ваших текущих запросов, может быть связана с блокировкой при добавлении. Как вариант делаете отдельную таблица-превью, где вы поддерживаете актуальные агрегированные данные из разных таблиц но уже в одной.
4. Как по мне то кешировать надо то, что чаще всего запрашивают, иначе в этом нет никакого смысла. Был у меня когда-то проект, который попросили немного ускорить, так там для загрузки по скролу, все строки с БД были запихнуты на фронт в JSON-переменную и JS-ом это дергали при скроле :) с пустой БД это наверное работало быстро, но когда ушли за 10К строк начались проблемы.
5. Еще возможно стоит обсудить с заказчиком, а надо ли все данные на одной странице и все сразу отображать, возможно часть данных стоит догружать через AJAX-запросы в зависимости от действий пользователя
Блин. Зря достал плавки )
Сначала не понял, а потом кааак понял 😂
😂 😂
О каком дебаг баре идёт речь?)
github.com/barryvdh/laravel-debugbar
Сначала ставлю лайк, а потом смотрю! С Новым годом!
Скажу по своему опыту. Если программер пишет код, что нуждается в рефакторинге - это кодер. А без моделирования и проектирования все эти потуги, с оптимизацией, пустая трата времени. Так что, эти советы для идеального Мира. А по факту никто не выделит, из руководства, времени для рефакторинга. Так и останется - нет ничего более постоянного, чем временное.
Фаулер, Бек, Мартин иного мнения и в XP предлагают эволюционное проектирование с помощью рефакторинга. По этому рефакторинг становится частью разработки задачи и не нуждается в одобрении руководства.
Эти американцы - понаписывают книг, а потом вся эта писанина превращается в религию какую-то.
Всегда, по мере развития, любой проект обрастает костылями и техническим долгом, который очень часто в спешке так и остается годами висеть.
если приходится писать костыли - факт что говно проекты ( все время живем вчерашним днем )