Шаблоны разработки. Антипаттерны (завершение)

Обновленный курс GRASP and GoF Design patterns - bit.ly/2W3djGN
💪 ПРОКАЧАЙ СВОИ ХАРД-СКИЛЛЫ ЗА 2 МЕСЯЦА!
Продолжение курса "Шаблоны разработки программного обеспечения".Антипаттерны
Плейлист • Шаблоны разработки. Вв...
Все материалы курса лекций (включая конспект лекций) на моем канале на SlideShare:www.slideshare.net/SergeyNemch...
Изучение Blockchain developer bit.ly/2Ro2hV2
Изучение Android bit.ly/2RcvzWB

[@t.f.5722]

Молодой и красивый Сергей Немчинский.

[@Das.Kleine.Krokodil]

просто с усами, это отличает сильно

[@user-qg6fn3qx9m]

Спасибо Немчинскому, я любитель самоучка, но еслибы 10 лет назад знал что есть такие курсы, обязательно пошёл бы и не приобретал знания на болезненом опыте.

[@9Corvinus]

В очередной раз ловлю себя на мысли, что проходили мы это еще в университете давным-давно, но тогда это не воспринималось так остро, а сейчас - насмотревшись на кучу кода, переданного интеграторами и проведя годы в его рефакторинге... Ох, некоторые вещи я теперь знаю, как называются))))

[@Das.Kleine.Krokodil]

Спасибо

[@betking1990]

Норм объясняешь))

[@cybd08]

Весёлая концовка получилась

[@kai3341]

Оптимизация не всегда говнение. Правда, в моём опыте в основном выходит скорее выкорчёвывание мыльного пузыря и прочего говна с целью максимального упрощения кода (иногда сложность кода сокрыта слоями абстракции. Сей антипаттерн крайне распространён и называется ORM. Шутка это лишь наполовину, и похоже, потребует объяснения). И как результат -- О ЧУДО! -- код действительно начинает работать сильно быстрее. И обычно такую оптимизацию я называю побочным эффектом, чтобы заказчик не пугался.

[@SergeyNemchinskiy]

ОРМ надо уметь готовить. Часто выходит сделать на ОРМе даже быстрее, чем на нативном SQL

[@svyatoslavs945]

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

[@0imax]

Не знаю, когда Вы это делали, под какой системой контроля версий и какой объём кода требовал изменений, возможно тогда такой подход был вполне ок. Сейчас подобные задачи элементарно решаются отдельной веткой в гите: Надо сделать оптимизацию - от последней версии сделали отдельную ветку и там ковыряетесь. Потребовалось срочно добавить фичу, а оптимизацию ещё не доделали - создаёте новую ветку от того же места, добавляете фичу, проверяете, сливаете в основную ветку. Затем доделываете оптимизацию и так же сливаете изменения в основную ветку. Итого задачи не мешают друг другу, переключаться между ними легко и просто, а главное - у Вас всегда есть 100% рабочая версия Вашей программы. До знакомства с гитом я не пользовался системой контроля версий вообще, т.к. считал, что раз пишу код один, нафига мне это надо. А как попробовал, теперь всё делаю с гитом, ибо так намного удобнее.

[@svyatoslavs945]

@@0imax В принципе, да, согласен, с GIT это все работает, но, возможно это моя личная психология, мне проще на короткое время повесить todo и закомментированный кусок кода, который потом будет постоянно попадаться на глаза, чем делать отдельную ветку, которая при активной работе может и забыться/потеряться, и которую потом еще надо будет сливать с тем, что ушло вперед. В последнее время, однако, чаще получается другое использование: у меня код готов и работает, а в интеграции у коллег что-то сломалось, поэтому, часть рабочего кода до починки комментируем с пояснением, что текущее состояние - костыль, и условием, когда его можно будет откатить.

[@Xilax220]

Про оптимизацию кода скажу пару слов. Можно писать быстрый код сразу, либо писать медленный. Взять хоть те же патерны регекспов в цыкле. Вроде может показаться обычным при тестовых прогонах. Но! Если вы начнете проводить SVT тестирование, то к вам придет инженеры и скажут, что вы тут "наковногодили" и у вас патерны постоянно компилируется. Лучше об этом думать на автомате. Это только один из примеров. Есть уйма кода которая ведет себя похоже. Кодите пожалуйста сразу быстро, нет сложности в оптимизации в момент измышления над кодом.

[@dutnum5766]

Имена переменных с венгерской нотацией прекрасно запоминаются. В памяти держится не только имя, но и тип переменной. Через некоторое время префиксы добавляются "в уме" добавляются автоматически. Как раз имя переменные без префикса начинают выглядеть "странно". Не могу сказать что она устарела: Microsoft до сих пор использует венгерскую нотацию в том числе и в новых API. В Java венгерская нотация ограниченно используется в Android API (префикс m для полей класса).

[@TheKotopec]

29:10

[@alexpepper2146]

а IDEA ж вроде умеет уже давно подставлять по абривиатуре.. не так?

[@alexpepper2146]

+Sergey Nemchinsky ну, если по абривиатуре всегда вводить, то найдётся (относится к таинственному коду), или таже венгерская натация хотя сам сие не предпочитаю )

[@gen7891]

Проект надо изучать не по коду, особенно если он говен. А по руководству системного программиста, где бы была расписано архитектура , концепции и тд но никто так не работает потому что архитекторов в команде нет. Это как строители без бригадира. Но если на стройке все понимают что бригадир нужен, то в ИТ все не понимают что нужен архитектор в команде. Поэтому столько гавнокода и рождается и так будет... потому что бизнесу нужны демки прям ща ...