Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Паттерны forever

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Интересно, придерживаются ли разработчики правила, что любую задачу (не имеется ввиду багфиксинг) можно разложить на паттерны (все велосипеды придуманы еще до нашего рождения), и четко этому следовать по любому изменению кода? И насчет такого стиля общения девелоперов сугубо по понятиямпо паттернам типа «Вот тут будем использовать абстрактную фабрику, а к тому говнокоду нарисуем адаптер» — чисто мыслить этими категориями не явяется ли признаком оторванности от действительности? И как насчет того, что перед тем, как начать непосредственно кодить — создать в каком-нибудь case средстве, диаграмму, нарисовать в паттернах скелет, продебажить как работает логика, а потом уже через code behind сделать наполнение кодом. Или это просто теория о 23 базовых паттернах, систематизированная старым пердуномГаммой для своей докторской, которую можно рассматривать только как понт? Какие у вас есть на эту тему success stories?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Паттерны — это способ научить/объяснить абстрактному «индусу», что и как именно писать. См., например, у Сполски «Big Macs vs. The N_a_k_e_d Chef» В этом смысле, я согласен с eugene_n, это абсолютно нормальная инженерная практика. Истина же, как обычно, находится где-то посредине между «Паттерны — это способ решения любой задачи» и «Паттерны — для лохов, настоящие мужики в них не нуждаются».

P.S. ре-пост, автомодерация не пропускала слово «Nаked», прекрасная иллюстрация к «методу решению задач с использованием паттернов»:))

Че-то не уловил мысли — имеется ввиду, что джун их коряво строит, или не понимает, какие конкретно задачи можно решить с помощью того или иного паттерна, и тем самым ухудшает фунциональность? (Типа в определенных случаях лепит все в конкретику, не понимая прелести абстракции и контракта) Так все вроде приходит с опытом — с первого раза нормально ни у кого ничего не получается:) А Гамма ведь он не персональный тренер — для этого и есть книги:) Лично я знаю только один аргумент, когда их использовать не следует — когда все колбасят один код, и не все знают шаблоны (кто не знает — у того будет много вопросов и будет ламать код время от времени), есть еще? Ну и вообще, все мы когда то были джунами, и чтобы не развился комплекс джуна, ИМХО вмешательство старших товарищей должно быть минимальным (а то он думать разучится:) От старших товарищей ИМХО нормальное оформление кода (вменяемый name convention, комментарии в коде, в т.ч. summary) и кредит доверия — и пусть развивается:)

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

чисто мыслить этими категориями не явяется ли признаком оторванности от действительности?

Это абсолютно нормальная инженерная практика, которая соблюдается везде, кроме разработки софта.

Ну не настолько сурово, но очень близко у нас в проектах. Говнокода почти нет.

Підписатись на коментарі