Шаблоны разработки. Антипаттерны (завершение)
Vložit
- čas přidán 22. 08. 2024
- Обновленный курс GRASP and GoF Design patterns - bit.ly/2W3djGN
💪 ПРОКАЧАЙ СВОИ ХАРД-СКИЛЛЫ ЗА 2 МЕСЯЦА!
Продолжение курса "Шаблоны разработки программного обеспечения".Антипаттерны
Плейлист • Шаблоны разработки. Вв...
Все материалы курса лекций (включая конспект лекций) на моем канале на SlideShare:www.slideshare....
Изучение Blockchain developer bit.ly/2Ro2hV2
Изучение Android bit.ly/2RcvzWB
Молодой и красивый Сергей Немчинский.
просто с усами, это отличает сильно
Спасибо Немчинскому, я любитель самоучка, но еслибы 10 лет назад знал что есть такие курсы, обязательно пошёл бы и не приобретал знания на болезненом опыте.
В очередной раз ловлю себя на мысли, что проходили мы это еще в университете давным-давно, но тогда это не воспринималось так остро, а сейчас - насмотревшись на кучу кода, переданного интеграторами и проведя годы в его рефакторинге... Ох, некоторые вещи я теперь знаю, как называются))))
Спасибо
Оптимизация не всегда говнение. Правда, в моём опыте в основном выходит скорее выкорчёвывание мыльного пузыря и прочего говна с целью максимального упрощения кода (иногда сложность кода сокрыта слоями абстракции. Сей антипаттерн крайне распространён и называется ORM. Шутка это лишь наполовину, и похоже, потребует объяснения). И как результат -- О ЧУДО! -- код действительно начинает работать сильно быстрее. И обычно такую оптимизацию я называю побочным эффектом, чтобы заказчик не пугался.
ОРМ надо уметь готовить. Часто выходит сделать на ОРМе даже быстрее, чем на нативном SQL
Приведу пример, где, все же пригождался закомментированный код: начал писать оптимизирующую фичу, в процессе понял, что есть сложности, времени на эту фичу уйдет намного больше запланированного, а есть в другом месте код, который требует срочной реализации. Закомментировал новое, вернул старое неоптимальное, написал todo и ушел заниматься делами. Через несколько дней появилось время, вернулся и дописал оптимизацию, хотя, конечно, за эти дни появились новые мысли, часть переделал, но закомментированное помогло не забыть основную идею.
Не знаю, когда Вы это делали, под какой системой контроля версий и какой объём кода требовал изменений, возможно тогда такой подход был вполне ок.
Сейчас подобные задачи элементарно решаются отдельной веткой в гите:
Надо сделать оптимизацию - от последней версии сделали отдельную ветку и там ковыряетесь.
Потребовалось срочно добавить фичу, а оптимизацию ещё не доделали - создаёте новую ветку от того же места, добавляете фичу, проверяете, сливаете в основную ветку.
Затем доделываете оптимизацию и так же сливаете изменения в основную ветку.
Итого задачи не мешают друг другу, переключаться между ними легко и просто, а главное - у Вас всегда есть 100% рабочая версия Вашей программы.
До знакомства с гитом я не пользовался системой контроля версий вообще, т.к. считал, что раз пишу код один, нафига мне это надо. А как попробовал, теперь всё делаю с гитом, ибо так намного удобнее.
@@0imax В принципе, да, согласен, с GIT это все работает, но, возможно это моя личная психология, мне проще на короткое время повесить todo и закомментированный кусок кода, который потом будет постоянно попадаться на глаза, чем делать отдельную ветку, которая при активной работе может и забыться/потеряться, и которую потом еще надо будет сливать с тем, что ушло вперед.
В последнее время, однако, чаще получается другое использование: у меня код готов и работает, а в интеграции у коллег что-то сломалось, поэтому, часть рабочего кода до починки комментируем с пояснением, что текущее состояние - костыль, и условием, когда его можно будет откатить.
Имена переменных с венгерской нотацией прекрасно запоминаются. В памяти держится не только имя, но и тип переменной. Через некоторое время префиксы добавляются "в уме" добавляются автоматически. Как раз имя переменные без префикса начинают выглядеть "странно".
Не могу сказать что она устарела: Microsoft до сих пор использует венгерскую нотацию в том числе и в новых API. В Java венгерская нотация ограниченно используется в Android API (префикс m для полей класса).
Весёлая концовка получилась
Про оптимизацию кода скажу пару слов. Можно писать быстрый код сразу, либо писать медленный. Взять хоть те же патерны регекспов в цыкле. Вроде может показаться обычным при тестовых прогонах. Но! Если вы начнете проводить SVT тестирование, то к вам придет инженеры и скажут, что вы тут "наковногодили" и у вас патерны постоянно компилируется. Лучше об этом думать на автомате. Это только один из примеров. Есть уйма кода которая ведет себя похоже. Кодите пожалуйста сразу быстро, нет сложности в оптимизации в момент измышления над кодом.
Норм объясняешь))
29:10
Проект надо изучать не по коду, особенно если он говен. А по руководству системного программиста, где бы была расписано архитектура , концепции и тд но никто так не работает потому что архитекторов в команде нет. Это как строители без бригадира. Но если на стройке все понимают что бригадир нужен, то в ИТ все не понимают что нужен архитектор в команде. Поэтому столько гавнокода и рождается и так будет... потому что бизнесу нужны демки прям ща ...
а IDEA ж вроде умеет уже давно подставлять по абривиатуре.. не так?
+Sergey Nemchinsky
ну, если по абривиатуре всегда вводить, то найдётся (относится к таинственному коду), или таже венгерская натация
хотя сам сие не предпочитаю )