Вне области применения

        Мое становление как программиста  началось в 2005 году и продолжается по  сей день.
    Несомненно,  многие читатели   смогут  похвастаться    более   обширным опытом, но речь
    пойдет   о  другом.  Мой  профессиональный рост   наложился на     интересный  период —
    повышение  культуры     программирования в   рунете,    если     это   можно   так назвать.
    Профессионалы   были  всегда,   но  сегодня    подкованность   среднего программиста(во
    всяком случае в сфере best pracices) несравнимо выше, чем тогда.

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

        Концепция   паттернов не   нова,  идея    о  неизобретении  своего   велосипеда набила
    оскомину,   за отстуствие     тестов  принято посыпать  голову пеплом и   каяться   как на
    страшном     суде.  Достаточно   прочитать  примерно   5 книг    по  проектированию, чтобы
    понять, что   сейчас модно и как нужно  писать код. Загвоздка в  другом — даже прочитав
    25   книг вы  не поймете когда   нужно писать какой  код. В какой‐то мере можно научиться
    этому  глядя  на  старших товарищей, которые  выдают идеи  того,  когда можно применить
    то  или  иное решение, при  этом ход  мыслей, который привел   к такому   решению опять
    остается за кадром.

        В  итоге  у новичка  в лучшем случае  в голове получается некая карта, описывающая
    когда   можно  применять что‐либо, причем  карта довольно ограниченная. И горе новичку,
    если он окажется впечатлительным, а   результат  будет  отличным  —   у   человека может
    появиться любимый паттерн. И он этот паттерн может бережно пронести скозь годы, лепя
    его в    самых  причудливых   местах,   и    вызывая   тем  самым   искреннее удивление и
    неподдельную ненависть коллег.


    Краткий экскурс в права меньшинств

        Вы не  любите  TDD? Любите  писать  код   в процедурном стиле? Не   используете EJB?
    Ай‐ай‐ай,  да  как у   вас только  земля  под ногами   не горит. Любой  социум   делится на
    группы,   и если  вы не  готовы  вступить  в одну группку, то  вас с радостью   причислят к
    другой.    Как     и    везде,    где  в основе    логики     поведения     лежат биологические
    закономерности,    между   группами    наблюдается    конкуренция. Какая‐то     из групп
    выигрывает   почетный   приз   Права  Обладания    Абсолютной   Истиной,    остальные же
    объявляются врагами рода человеческого, в лучше случае забавными маргиналами.

        Все, в общем‐то  понимают это, достаточно глянуть любой пост на хабре, посвященный
    оверинженирингу  —    он будет заплюсован, но в  комментариях  можно   будет   увидеть с
    десяток килобайт   демагогии на  тему  почему все‐таки автор   неправ. Но сделать ничего
    нельзя  —  каждый кто  захочет  пойти против сложившегося   порядка вещей, будет либо
    проигнорирован, либо   осмеян.  Ситуацию  усугубляет   то,   что те   авторитеты, которые
    могли бы подкрепить  протест  своим именем, как правило,   в этом не  заинтересованы —
    они уже  сидят  на  непыльных  должностях, где  правила Совершенного  кода в принципе
    работают,  и  им   уже   нет дела до того,  что  в соседнем сегменте софтостроения люди
    ломают копья в спорах на тему «как же правильно писать код».

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

        Самое забавное,  что находятся   люди,   готовые искренне  и   горячо спорить  на тему,
    какой  же  на самом деле должна быть реализация  паттерна  под тем или  иным названием,
    опуская тот факт, что имя по  поводу которого они  спорят ‐ всего лишь   условность для
    человека,  решившего  записать свой  личный  опыт  именно   под таким   названием. Самое
    печальное, что  находятся  и те, кто  слушает предыдущих и, горестно  качая  головой, тут
    же каются,  что   дескать    не  смогли они   правильно понять  определение, обещая стать
    лучше.    Но  здоровую  самокритику невозможно заменить нездоровым  самобичеванием, и
    лучше они не становятся.


    На вершине Олимпа

        Мартин  Фаулер — наш   царь,  отец и бог. Все  мы чтим его как человека, надававшего
    линейкой   по  рукам    несметным  полчищам   начинающих  программистов, и  во многом
    определившего  мировоззрение   целого поколения ИТ‐шников. Мы скорее всего никогда не
    узнаем как  и почему он стал  мерилом  хорошести  кода. Быть может его книги стали той
    самой заглушкой  для    потока  некачественных программистов,  вливавшихся в отрасль до
    момента  пока  пузырь доткомов   не  лопнул.  А    может   быть   он  правда   первым, кто
    систематизировал  все то, что было  накоплено   в плане  проектирования программ  к тому
    времени. Все это дела давно минувших дней.

        А  сегодня  мы имеем  набор  рекомендаций, ставших негласными  правилами хорошего
    тона  в разработке.  Возможно  эти  правила и хорошие, попробуем   очертить  границы их
    применения:

    1) Языки со статической типизацией — в первую очередь C++ и Java.

    2)  Крупные    программные    продукты,   создающиеся      из расчета взаимозаменяемости
    программистов, участвующих в проекте.

    3) Программные     продукты,    рассчитанные  на    дальнейшее   развитие   и длительное
    сопровождение.

    4)   ПО    рассчитанное на  довольно  жесткие требования   надежности  — корпоративные
    решения в общем.

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


    Черный рынок

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

        Немалое  количество   отраслевого софта  не  меняется годами   —   программы просто
    обслуживают техпроцессы, для   которых были созданы, а  изменения,  вносимые  в них —
    чисто  косметические.  Конечно,  код находящийся  там    чаще     всего  оставляет желать
    лучшего, но он вполне расширяем в рамках тех требований, которые к нему ставятся.

        Еще более  изящной неопределенность будущего  ПО может выступать в случае, когда
    будет ли  оно развиваться   определяется  тем, как  быстро оно сможет выйти на рынок и
    отбить  вложения, чтобы  получить   средства  для  дальнейшего развития.  Абстракции не
    всегда    значительно   увеличивают   объем кода,     но всегда   увеличивают   время его
    написания.    Наверняка       есть        игрушечные(получившие        со      старта огромное
    финансирование)  и не в  меру удачливые стартапы,  которые могут себе позволить такую
    роскошь как   написание по всем параметрам богоугодного  кода. И это здорово — должны
    же  быть где‐то на  земле счастливые программисты.  Но не  следует  рассматривать такие
    проекты как закономерность.

        Отказоустойчивость —    скорее    вопрос  предпочтений.   Мы    понимаем,    что наши
    программы  должны  работать стабильно.  Вопрос в   том,   насколько  стабильно. Все что
    пишется нами, пишется  для  решения какой‐то задачи. И если в постановке  этой задачи
    не    требуется  обеспечить  100% отказоустойчивость,  то  скорее  всего она и  правда не
    нужна.   Все  имеет  цену  — за    отказоустойчивость    надо  платить,  тратить    время на
    создание оберток,  проверок, систем резервирования.  И в конечном итоге наша задача не
    создать совершенно неубиваемую систему, а сделать  так,   чтобы затраты на повышение
    надежности    системы  оказались   меньше   затрат    вызванных   ее     простоем. Звучит
    кощунственно, но при трезвом рассмотрении так оно и есть.

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

        Кстати   именно с  этого сегмента  рынка начинают свой  профессиональный   путь почти
    все программисты. И  им      на голову  сыпятся советы,  один замечательнее  другого. Но
    реальность такова,  что следуя   этим   советам на  данном этапе   своего   развития и при
    участии в  таких  проектах — это прямая  дорога  к провалу. Парадокс ситуации в том, что
    те,  кто может реально следовать   хорошим практикам, в данном сегменте рынка либо не
    работают, либо вообще  не  нужны  из‐за  высоких    расценок.  А    те, кто не может пока
    эффективно исполнять  роль «хорошего  программиста»,   наоборот всячески присутствуют
    на рынке  труда  в    данном   сегменте и активно  шпыняются  на  предмет невыполнения
    заветов совершенного кода.

        Нельзя   сказать, что    новичкам     советуют    использовать   паттерны, тестирование,
    расширяемую архитектуру  по злому  умыслу, нет. Все   эти советчики искренне желают им
    добра,   не  замечая   при   этом,  что    задачи    решаемые ими    несколько отличаются.
    Применение  хороших практик тут   не даст  положительной  обратной связи, они просто не
    подходят  для   решения   поставленных  тут   задач.    Варясь   в  котле  мелких  и средних
    проектов и  пытаясь    писать совершенный код,  новичок обречен снова и   снова срывать
    сроки и делать то, что никому не нужно.

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


    Мракобесие отраслевых масштабов

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

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

        Кстати, как  проверить  достоверность информации,  даваемой  в таких   книгах? Только
    ударившись в  область  допущений,   что  код   будет  меняться так   или  вот   так. Любой
    второкурсник   сможет  к   примерам, описываемым в    книгах   привести контр‐примеры,
    которые будут лаконичнее и эффективнее, решая при этом ту же задачу.

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

        Второй    вариант — это самостоятельный   поиск решения.  Отношение  к таким людям
    мягко  говоря негативное, а  чаще всего    —  презрение.  Негатив идет по двум причинам:
    во‐первых,    сформировано      общественное    мнение,     гласящее,    что     человек не
    использующий   best practices —  это    и  не человек   вовсе,  во‐вторых,  обучающийся на
    своем опыте,  неизбежно  будет совершать  ошибки. Как  правило,   ошибки эти подмечают
    его более опытные коллеги, для которых подобные огрехи ‐ и правда детский лепет.

        Беда     в     том,   что   формализация   процесса    обучения  программированию пока
    отсутствует, причем даже  в  головах  тех,  кто через этот процесс прошел. Например, вы
    состоявшийся программист, попробуйте во  время проектирования очередного  модуля или
    сколько‐то    серьезного   класса  задавать  вопрос  «почему»   на  каждое свое действие,
    попробуйте   с  точки зрения логики обосновать последовательность ваших действий, так
    чтобы одно однозначно следовало из другого.

        Чтобы сэкономить ваше время,  скажу, что у вас    не  получится.   Если получится, то
    ваша твердолобость   достойна всяких похвал, этот же  пост прочтения  вами  не достоин,
    закройте его.   В процессе  создания   архитектуры вы оперируете не   знаниями, а скорее
    опытом. Вы не сможете прыгнуть  выше  своей головы, создав архитектуру по  книжке, до
    тех   пор пока не   придете  к  необходимости     подобных построений   сами.   Но можете
    обмануть интервьюера на собеседовании, использовав обратное утверждение.


    Эвристическое бессилие

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

        Я тщетно и долго искал людей, которые  были бы способны прочитать банду четырех, а
    потом строить  абстракции и успешно применять  их в  своем коде. Если что, речь о людях
    без опыта.  Если что, синглетон не в счет.  Что‐то  в голове  не позволяет  брать  и плодить
    штучные  абстракции  по  образу  и  подобию     прочитанного:  либо человек   не понимает
    зачем это делается и  в итоге  абстракция  создает  проблем больше, чем решает, либо он
    честно признается себе,  что не видит куда  это можно  приткнуть.  Возможно есть те, кто
    способен на такой способ обучения, но их мне встречать не доводилось. А вам?

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

        Знаний на уровне  формального  описания предмета часто недостаточно для успешного
    его применения.  Они  должны   быть    встроены  в логические цепочки на уровне фактов,
    которые должны быть не просто  заучены,  но  прочувствованы.  Обычно такое осмысление
    приходит   в процессе   практики(реже    —   когда, через  несколько  месяцев  или лет вы
    чувствуете, что  что‐то в  голове встало  на свои места и вы готовы   этим пользоваться).
    Причем независимо  от   того читал  ли  программист  про  паттерны  или нет. Если задачи
    будут  показывать  неэффективность его   текущего  подхода, то  он   придет к решению,
    которое будет  работать лучше.  Неважно   как он обзовет  это  у себя в голове. Объяснить
    получившийся  паттерн  другому   программисту    — минутное   дело. И  к   тому  же, если
    описание  паттерна формируется    в мозгу  каждого программиста   на     тех примерах с
    которыми он имел  дело, то,  даже  имея  общее определение, два человека, используя его,
    будут говорить о  довольно разных вещах, что опять  таки делает привязку к официальным
    паттернам нежелательной.

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


    Объять необъятное

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

        Негласный принцип     программирования   гласит,   что   вместо  того,   чтобы создавать
    заново, лучше  расширить   или  изменить уже имеющееся. Благо  технология позволяет. К
    слову  технология позволяет   и   апгрейдить  физические   устройства для достижения ими
    нужных  функций.  Тем не менее это  почему‐то не  делается.  Наверняка из соображений
    чисто экономического характера.

        Имея  два подхода —  переписывание  с  нуля  и   расширение  готового  мы  привыкли к
    тому, что второй вариант лучше, менее трудозатратнее. При этом забывая, что:

    а) в случае криво  написанного нерасширяемого кода мы  получаем большие сложности с
    добавлением функционала

    б)  в  случае создания расширяемого   кода стоимость  переписывания закладывается уже
    на этапе первоначального написания кода

        Трудозатраты будут в обоих  случаях, вопрос  лишь в том, когда они больше. И именно
    на  этот   вопрос  по‐хорошему   должен   знать ответ     опытный      программист. Опытный
    архитектор может  дать   задание  написать говнокод, но  с одним условием   —    никто не
    должен про это узнать.


    Область применения

        Вы можете  годами не находить  себе  места в  связи  с  тем, что не можете найти места
    практикам, о которых  вы читаете, но это  скорее всего   не  значит, что  с  вами  что‐то не
    так.  Неважно сколько паттернов вы знаете и используете, важно лишь то, что   вы можете
    применить   их  к  месту. Я вообще убежден что объем   знаний  хорошего проектировщика
    можно      освоить   за     пару месяцев,  но чтобы   научиться     правильно    их применять
    потребуются годы.

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

        Если вы все   таки   хотите  понять кто и  зачем   все  это использует,    то изучайте код
    больших проектов на  Java, C#,   C++. В особенности это будет полезно программистам на
    скриптовых языках, потому что так можно  будет  наглядно  увидеть ту разницу  в подходе
    к программированию на, например,  Java и  Python. В любом случае, даже если вы найдете
    реализацию   того  или  иного  паттерна,  не    следует  принимать это   близко к сердцу,
    паттерны  обычно  рождаются  или   выбираются  в рамках конкретного  проекта. Так что
    велика  вероятность того, что увиденное там   не может   быть применено в текущем вашем
    проекте.

        Если  начальство требует от вас писать «правильный  код»   —  пишите! Вы  либо правда
    еще не понимаете, что с вашим профессиональным уровнем  не  так,  и тогда вам полезно
    будет сделать так,  как  говорят, если же  ваш тимлид  человек идейный, вот и не спорьте
    с ним —  рядовому программистишке  его  веру не  разрушить,  а  пинки  потом получать не
    вам.


    Что делать?

        Думать,   хорошо  думать  прежде  чем  использовать что‐то  что вы не  понимаете. Если
    оно  кажется вам  ненужным,   то оно  и правда может  таким  быть.  Если вы  видите, что
    тесты нужны  вашей программе как собаке боковой карман — не пишите их, вы все равно
    не сможете  написать их   так,  чтобы   они приносили пользу.    Если   вы ознакомились со
    списком паттернов, а потом с ужасом  обнаружили, что в вашем коде за   последние пару
    лет  в лучшем случае нашли пристанище 3‐4  из  них,  но в  остальном вы  довольны своим
    кодом, и с его сопровождением нет проблем, то оставьте все как есть.

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

    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 108

      0
      На одном дыхании. Давно стал считать: предел совершенства — есть цель.
        +3
        «Лучшее — враг хорошего» (с) М. Джиованни, 1574 и другие
        Я к тому что слепо бросаться в крайность перфекционизма все же не стоит.

        А статья довольно интересная, есть о чем задуматься. Интересно, будет ли это редким случаем, когда статья больше комментариев?!
          +5
          Недавно читал статью — tl;dr: погоня за идеалов вызывает депресию и приводит к прокрастинации. Именно перфекционизм, а не лень.
            0
            Все так и есть, проверено лично :(
        +66
        Courier New для текста? Вы издеваетесь?
          +47
          А мне нравится почему-то. Напоминает чтение txt много лет назад, книг с либру, например.
            +25
            Всё же режет глаз, особенно на фоне других постов.
              +1
              Именно шрифт заставил меня прочитать этот текст. Действительно при моих ассоциациях выглядит как класика, рядом с примитивной попсой рядом. Так что на вкус и цвет…
              +3
              чтение txt много лет назад, книг с либру, например.

              Я до сих пор читаю книги на сайте либру.
              +3
              Мне, как постоянному пользователю различных IDE, намного проще воспринимать моноширинный шрифт. Да, да — сам удивляюсь.
                –5
                <pre>...</pre>
                

                зато, таким образом можно выравнивать текст по ширине, чего стандартный редактор не позволяет
                  +12
                  Всегда бесило это выравнивание, особенно на lib.ru
                    0
                    Узкую колонку текста читать всегда легче. На широкой колонке глаз может постоянно сбиваться со строки.
                      +9
                      Обычно ширину колонки я могу менять, изменяя размеры окна браузера. Здесь — нет.
                        +9
                        Фиксированная ширина текста — прошлый век.
                        Сейчас принято делать текст резиновым, чтобы пользователь сам выбирал себе ширину и не зависеть от прихоти дизайнера.
                        +1
                        Откуда столько нелюбви к моим словам, просто констатирующим тот факт, что Courier New был выбран из-за решения применить предварительно форматированный текст?
                        Если вы прочитаете предыдущие посты автора, то увидите, что в них он использует стандартное оформление. Может именно этот пост и надо читать только на мониторе, и в том виде, как это задумал автор? Это далеко не научная статья, а скорее изречение мыслей автора, и эффект при прочтении довольно своеобразный. И уж точно выделяющийся из общей массы. В конце концом, все же нам выбирать читать что-либо или нет.
                        Как итог, имеем половину комментариев, посвященных исключительно проблеме выбранного автором шрифта. Хотя других тем для дискуссии здесь уж точно хватает.
                      +2
                      Особенно, с телефона
                        +3
                        У меня на планшете строчки поста обрезаются в правой части, где они контактируют с желтыми хабраблоками вместо нормального переноса.
                        +3
                        Там не Курьер Нью, а моноширинный по дефолту в настройках браузера.
                        • UFO just landed and posted this here
                            +1
                            Правая или левая граница может быть за кожухом, поэтому лучше 78, а еще лучше 76!
                            0
                            Разделяю ваше негодование. Сам подумал, что надо мной издеваются, когда не смог найти в хабротэгах способа выравнивать текст по ширине.
                              0
                              Хорошо, что есть Clearly
                                0
                                Да еще без русских переносов!
                                  –2
                                  Очень хуёво сглаживается в Линуксе.
                                    0
                                    Вру, сглаживается хорошо. Просто непривычно. А вообще: беллетристика моноспэйсом о непрагматизме.
                                  +28
                                  После прочтения машинально ткнул esc. :)
                                    +1
                                    Интересный стиль, читается на одном дыхании.

                                      +15
                                      Сделать фон синим/ серым в стиле nc/dn и получится ня.
                                        +10
                                        Я наверное как раз из тех, кто не следует догмам и не молится на «совершенные техники». Когда-то давным-давно я услышал фразу: «Чтобы быть кузнецом — надо ковать!» — и вот с тех пор это как руководство к действию… но тут еще и Ленина можно добавить «Учиться, учиться и еще раз учиться!»

                                        Мне нравится программирование именно тем, что это — творческий процесс. Конечно, чтобы что-то творить в программировании, нужно многое знать, поэтому я во все времена читал и читаю множество книг — без этого никак — всегда надо быть в курсе современных тенденций, техник, понимать работу современных IT-технологий. Но множество прочитанной информации я просто принимаю к сведению, ибо любая прошедшая через мозг информация так или иначе меняет наше сознание. Возможно прозвучит странно, но я ни одну из новомодных парадигм программирования не принял как руководство к действию, как догму. Как сказал классик: «Мало ли что можно рассказать?.. Не всему же надо верить.». Проще воспринимать это надо все, как полезные советы, не более того, и уж тем более не превращать эти знания в «единственно верную религию».

                                        Знать техники хорошо и полезно, но применять их нужно только тогда, когда это действительно необходимо именно Вам, когда это не вызывает у Вас каких либо затруднений в реализации, когда Вы, так сказать, и умом понимаете, и душой принимаете. Применение всех парадигм программирования ради того, чтобы только были — это вред, а стремление применять их все — это бред!

                                        Мне нравится программировать, мне нравится учится, мне нравится учится на собственном опыте, тем самым приумножая его. Порой я даже могу заново написать очередной проект, с нуля — тогда порой появляются новые идеи сами собой, хотя можно было бы запихнуть давным-давно в какой-нибудь паттерн алгоритм и забыть про него. А мне интересно творчество, интересно создавать что-то свое, новое!

                                        И еще. Я даже толком не помню названия всех этих паттернов проектирования (хотя книгу 4-х прочитал ради интереса), но я их использую в том или ином виде. Я не считаю, что строгая типизация — это то благо, которое помогает писать без ошибок. Я не использую технику покрытия тестами и разработку через тестирование. И тем не менее… даже без всего этого я умудряюсь писать надежные системы, стараюсь писать красивый, строгий и лаконичный код.

                                        Подход к программированию может быть разнообразным. Очень важна именно практика программирования, опыт, основанный на хорошем базисе знаний. А дань моде, строгое следование каким-то правилам — это от лукавого.
                                          +2
                                          У меня паттерны рождаются вынужденно, как способ повышения абстракции при наращивании функционала. Водопадом ведь сейчас не модно проектировать :)

                                          Скажем, есть две страницы и переключалка между ними. Переключаемся в коде страниц. Потом добавили третью — поняли, что нужно сделать диспетчер. Гуру здесь отличается от новичка тем, что делает это уже на второй. Сделали, поместили в глобалы (ну а как же :) ). Потом оказалось, что нужно добавить другой модуль, который не связан с первым. Инстанцируем класс модуля. Делаем второй диспетчер и выносим из глобалов в модуль, создаем фабрику диспетчеров, потом диспетчер диспетчеров и так далее.
                                          Никто не может предугадать заранее, в каком направлении пойдет развитие системы. А идеальная абстракция и так уже создана — это сам язык.
                                            +4
                                            А просто один алгоритм переключения, использующий список (массив) идентификаторов (или пусть даже объектов) страниц, Вас уже не устраивает? Обязательно нужно городить весь этот огород из модулей и диспетчера? ;-)
                                              0
                                              Алгоритм можно обернуть в функцию, в класс — это уже от стиля зависит. Не вижу принципиальной разницы. Ключевой момент в том, что обработка переходов передается из кода страницы куда-то на сторону.
                                                +1
                                                Ключевой момент в данном контексте как раз не алгоритм, а использование более простых структур вместо всего этого зоопарка классов, модулей, диспетчеров, фабрик. Не примите за оскорбление, но что, действительно настолько сильно мозг сломан ООП-методологией и паттернами или это просто шутка такая?
                                                  0
                                                  Насчет диспетчера диспетчеров шутка. А все остальное — нет. Когда проект большой, то разобраться в нем без применения структурирования невозможно.
                                                  Для каждой системы свои простые структуры. Если у вас всего 10 разнородных сущностей, то вы можете не строить над ними второй этаж. А если 100, то вы задумаетесь и над третьим. Иначе просто повеситесь от объема избыточного кода и трудновычищаемых зависимостей.
                                                    +2
                                                    Полагаю, если Вы уже с 3-й страницы в данном примере начинаете строить такие ООП-зАмки, то Ваш висящий где-нибудь трупик найдут гораздо раньше, чем Вы доберетесь до 100 «разнородных сущностей» (звучит уже даже как-то угрожающе, как монстры какие-то ;-) ), ибо в данном случае избыточность плодите как раз Вы, при чем с завидной производительностью и рвением, насколько я понял.

                                                    Думаю, такого рода библиотеки будут очень в помощь Вам: habrahabr.ru/post/172119/
                                                    Настоящее ООП! Берите, не стесняйтесь, пользуйтесь! ;-)
                                                      –4
                                                      >php

                                                      Спасибо, все понятно.
                                                        +1
                                                        Аналог на джава:
                                                        github.com/Mikkeren/FizzBuzzEnterpriseEdition
                                                          0
                                                          Извращенством можно заниматься на любом языке. Фраза была о том, что мне все понятно стало с собеседником. Он не использует тесты (не считает нужным), лабает что-то единолично на пхп (причем спокойно может переписать все заново) и у него хороший код. Ок, мне не о чем с ним разговаривать. Очевидно у нас с ним слишком разное восприятие того, что такое разработка.
                                                            0
                                                            > Очевидно у нас с ним слишком разное восприятие того, что такое разработка.

                                                            Можно поинтересоваться о Вашем восприятии? Занимательно было бы узнать о настоящей разработке!
                                              +15
                                              создаем фабрику диспетчеров, потом диспетчер диспетчеров и так далее.

                                                0
                                                  +3
                                                  — Поэтому, на этой неделе мы представим единую фабрику фабрик фабрик инструментов, чтобы каждую фабрику фабрик инструментов Вы могли произвести с помощью одной, объединенной фабрики. Фабрика фабрик фабрик будет производить только те фабрики фабрик инструментов, какие Вам нужны, и каждая из этих фабрик фабрик будет производить фабрику, основанную на Ваших требованиях к инструменту.

                                                  habrahabr.ru/post/141477/
                                                  +1
                                                  Гуру сделает в N Измерениях, а не в одном, еще до добавления первой страницы, причем с абстрактным классом для абстрактной операции, где навигация — лишь частный случай перемещения вьюпорта в абстрактных данных :)
                                                    0
                                                    Причем он напишет для этого свою либу и выложит на гитхаб, да :)
                                                  +9
                                                  Уберите pre и больше никогда не пользуйтесь! Читать с мобильных устройств просто невозможно!
                                                    +1
                                                    Весьма приятная статья, спасибо.
                                                    Мысль про бо́льшую неоднозначность «расширяемость vs с нуля» для меня свежа, возьму на вооружение и проверки.
                                                      +1
                                                      Я все-таки спрошу: вы читали The Pragmatic Programmer?
                                                        +1
                                                        что такое «чистый код» каждый понимает по своему и это хорошая тема для флейма. Я всегда был врагом излишней патернизации в угоду производительности, так как основная специфика — это высоко-нагруженность.
                                                        И правильно сказал автор, что Фаулер царь и бог только в своем классе разработки приложений.
                                                        По большей части — паттерны нужны, но когда точно знаешь, что проект заточен под MySQL/PgSQL и тип БД меняться точно не будет — нет смысла наворачивать на класс общения с БД Адаптер. Другое дело — коробочный вариант…
                                                        Я тут недавно пообщался с некоторыми тимлидами, которые готовы в паттерны завернуть все что угодно. Особенно увлечены ОРМ. Но, если выкинуть 35-45% кода, то он все равно решит эту же задачу. Так зачем платить больше, если ждем диких нагрузок? Хотим производительности от БД на больших объемах — шардим данные… А если шардим данные, то какого черта завязываемся на ОРМ, архитекторы хреновы :(…
                                                        сорри — наболело…
                                                          –7
                                                          ОРМ — Опытный Ракетный Мотор? Мне кажется, рекетные технологии достаточно быстры.
                                                            –1
                                                            Что не так? Object Relation Mapping будет ORM, по-русские оно тоже так будет ru.wikipedia.org/wiki/ORM
                                                            0
                                                            Эхх… Пятница. У всех наболело.
                                                            а постановка задачи сейчас судя по всему во всех областях хромает — вот и копаем «от забора и до обеда».
                                                              0
                                                              Вот моя теория насчет любви тимлидов к ORM. Есть масса проектов, где использование ORM более, чем уместно. Тимлидам он нравится, т.к. если задача хорошо ложится на возможности ORM — кодеры быстро пишут понятный и легко изменяемый/сопровождаемый код. Скорость разработки и стоимость поддержки настолько приятнее, что иногда ORM можно увидеть и в местах, где он по каким-то причинам (например — производительность) не очень уместен.
                                                              +2
                                                              Наилучший свод правил, по моему личному мнению, как писать «правильный» код, содержится в книге по экстремальному программированию. Не важно как именно ты пишешь, применяешь паттерны или нет, оопэ или шмоопэ, используешь фреймворки или фонтанируешь рулонами спагетти, тщательно все документируешь или считаешь, что лучшая документация это код, пишешь комментарии или нет, главное — стоимость поддержки в будущем. Если через пол года, не вызывая никаких проблем, за максимально короткий срок можно внести исправления в систему, значит код написан правильно.

                                                                +2
                                                                Автор справедливо подмечает, что далеко не всем проектам потребуется поддержка.
                                                                  0
                                                                  Тогда любая реализация является идеальной.
                                                                    +4
                                                                    Пожалуй, лишь та, на написание которой уходит минимальное количество времени.
                                                                0
                                                                «Я требую продолжения банкета!»
                                                                  +3
                                                                  кто может реально следовать хорошим практикам, в данном сегменте рынка либо не работают, либо вообще не нужны из-за высоких расценок

                                                                  Есть противоположный пример — проект, написанный на коленке за пару недель, выстрелил и приносит прибыль уже много лет. При этом проект уходил в другие команды и возвращался, в итоге разобраться в нем могут только люди с опытом, и расценки при этом гораздо выше среднего. Взять и все переписать не получится — нет тестов, кроме тех, которые начали писать совсем недавно. Да, все так плохо, но продукт работает в куче (сотня, в перспективе — 1000) точек и приносит деньги.

                                                                  При это есть противоположный пример — параллельно писали проект по всем правилам, спринг, maven, тесты, абстракция на абстракции — в итоге все ведущие программисты уволились, индусы проект не потянули, и проект просто забросили. А писали его года 3.

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

                                                                  качестве аргумента к использованию какого-то подхода аппелировать к гипотетической ситуации, вероятность возникновения которой подозрительно мала

                                                                  Да! Только вчера был длинный разговор с коллегой, который хотел взять и все переписать на другую архитектуру, аргументы вида «а вот если прилетят инопланетяне, то и тогда новую архитектуру можно будет расширить» :)
                                                                    +2
                                                                    Отличная статья. А то я вчера прочел про то как человеку впаривают автотестирование на его небольшие веб проекты, что мне аж плохо стало… Теперь баланс добра и зла восстановлен.
                                                                      +1
                                                                      «попробуйте во время проектирования очередного модуля или сколько-то серьезного класса задавать вопрос „почему“ на каждое свое действие, попробуйте с точки зрения логики обосновать последовательность ваших действий, так чтобы одно однозначно следовало из другого»

                                                                      Вот эта способность и отличает инженеров от ремесленников. Буковки SOLID, LSP, O(n), NF, Кнут и подобные вполне себе позволяют ответить на вопрос «почему».

                                                                      А сказка про «простые» проекты, которые можно делать на коленке — отмазка неуча.

                                                                      P.S. А вот с выводами, с оговорками, согласен. Любой инструмент нужно применять понимая зачем, когда и как. Не понимаешь — учись. Но что бы учиться, надо читать и пробовать. А не говорить себе «эта фигня никому не нужна»

                                                                      P.P.S. Я таких называю «кодеры», в отличие от «разработчиков». Вторые — инженеры. Первые — ремесленники. Может быть и те и те нужны. Но я предпочитаю работать с инженерами.

                                                                        +2
                                                                        Еслми копнуть в глубь истории то инжинер (engineer) — это двигателист. Высококвалифицированный техник который поддерживает работоспособность хитрого агрегата, а так же может скомпоновать его из известных блоков более или менее представляя их назначение. Он совершенно не в курсе почему именно эта марка стали должна идти на впускной выпускной клапан, причем толковый еще интересуется почему (стойкость к воздействиям и т.д.), а ведь есть просто шаманы — они запомнили что на клапана ставится 95-я и им просто поболту что есть уже более 50 видов сталей плюс композиты которые даже лучше справяться по своим показателям, но он будет пихать «старое и проверенное», а частенько еще и редко и дорогое в замене и поддержке. Оба ничем не отличаются от ремесленников — просто первый может следя за рынком создать сверхлегкий ДВС известной схемы, а второй будет клепать ширпотреб по чужим чертежам. Создание принципиально новой схемы — это дело совершенно других ребят — математиков и цсников, которые разрабатывают новые алгоритмы, придумывают хитровыделанные алгебры и хитроразмерные функциональчики.
                                                                        Цепочку: Ученый — Компоновщик(он же дизайнер, он же архитектор) — Производитель никто не отменял. Чистые ученые скатятся в софистику и теории, чистые компоновщики будут играть во все то же лего из тех же кубиков, а производственники будут клепать тот же самый велосипед или смартфон иногда делая вип версию с гравировочкой и стразиками, или лоу кост — без вай-фая.
                                                                          +2
                                                                          «Двигателист»!!!

                                                                          Вы бы хоть со словарём сначала сверились, что ли. Или у гугла спросили.
                                                                          ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80

                                                                          Вот такие «двигателисты» и ваяют говнокод на коленке, не понимая почему это именно говнокод.
                                                                            –2
                                                                            о, у кого-то правда вызвала батхёрт :)
                                                                              0
                                                                              Вы кроме википедии, ничего не читали чтоли?
                                                                              Дабы подавить развитие баттхерта рекомендую поглядеть в итиль и посмотреть чем занимается инженер (дофига обязанностей техника и чу-чуть принеси подай), и чем дизайнер-проектировщик-архитектор, а то корчите из себя не пойми что, а обязанностей не знаете.
                                                                              Далее: парень отвечающий на паровую машину — это mechanic, но на подлодках там все пипец как сложно… И там уже engineer (двигателист).
                                                                              Вы упоминаете инженера в старом советском понимание, тот самый у которого мозг между ушами и один костюм на всех фотках в паспорте. Современный инженер уже другой: он платит кредиты, отвисает по кабакам, смотрит теорию большого взрыва чтобы чувствовать себя чуть умнее остальных и причем например не может объяснить разницу между SAS и SATA, или свято верует в то что по HDMI кабелю идет аналоговый сигнал и даже не интересуется подробностями, хотя при этом смеется над бухгалтершами неумеющими включить или выключить компьютер (а ведь их это точно так же неинтересует пункт два как и его пункт один). Он собрал, оно работает, он получил бабки и доволен. Не правда-ли мерзкое животное? Не все такие, но вот большинство…
                                                                              Относительно кода могу согласится с одним из вышеописанных примеров: если это сделано быстро, работает четко и поддается до/переработке — это хороший код. Перевод на русский: если эта машина для меня комфортна и выполняет поставленные ей задачи, ремонтируется в тех условиях в которых я ее буду эксплуатировать и ремонтируется доступным мне инструментом — я ее возьму и буду ездить. То есть по пустыне хорош уазик карбюраторный ибо он подлежит восстановлению чуть ли не из металлолома с помощью кувалды лома, коекакой матери… ах да… пару консервных банок не забыть чтобы в случае чего карбюратор собрать было из чего. Но это не значит что на этом чудовище я буду гонять по городу где есть сервис центры и прочие достижения цивилизации? :)
                                                                                0
                                                                                Вы описали какого-то отморозка :) Наверное мне повезло — рядом со мной таких исчезающе мало.

                                                                                Для начала, я имею основания полагать, что прочитал я, как минимум, не меньше вашего.

                                                                                Инженер — это создатель. Инженер — тот кто понимает почему он делает в данной ситуации так или иначе. И может объяснить своё решение. Инженер понимает, когда и какой инструмент или метод применим, а не делает всё одной и той же кувалдой или одни и тем же микроскопом. Тот, кто знает научные основы своей профессии и умеет их применять для создания чего-то нового — как систем, так и инструментов или методов создания систем. И для этого инженер непрерывно учится.

                                                                                Если вы не видите разницы между должностью в штатном расписании и профессией, я не буду дальше спорить.

                                                                                Собственно, автор статьи пишет примерно о том же — метод и инструмент надо применять осознано, а не потому что прочитал умную книжку. Только, судя по комментариям, большинство восприняли текст как «паттерны говно, TDD отстой, clean code — дурацкое требование начальства». И это печалит.

                                                                                P.S. Кстати, культура речи и письма тоже один из признаков профессионала :)

                                                                                P.P.S. Ну таки признайте, что с двигателистом вы облажались :) Действительно, очень легко подумать, что engineer от слова engine. Но увы.
                                                                                  –1
                                                                                  К сожалению не признаю. современный инженер в IT это всетаки от слова «двигателист», а не от французских корней :(
                                                                                  Нашел только один подвид старого советского — design engineer.
                                                                                  Остальные просто квалифицированные техники.
                                                                                  Просто удивляет ваша реакция. Заказываете блэйд сервер ibm. Приезжает первый «инженер», заносит сервер в серверную, распаковывает, монтирует в стойку, проверяет наличие питания и готовность к следующему этапу. потом второй который все коммутирует ставит пустые ОС на лезвия и уезжает, потом третий который делает тонкую настройку, если вы берете нештатные лезвия то будет полуторный который втыкает апгрейды памяти в лезвия… И это все «ИНЖЕНЕРЫ». Настоящие инженеры по ITIL. Но мне их удобнее называть «двигателистами» Ибо они под разряд даже техника наладчика все не проходят.
                                                                                  В тяжелом машиностроении кстати тоже попадались забавные тела в ранге инженеров. Им в институте вбили пять формул (может и больше) и они катают по ним как шаманы по кругу с бубном и только на них и смотрят… Ни о чем больше не думают… Кстати благодаря им и приелся у меня термин двигателист :) Это еще лет 15 назад было. Связать их с французским словом определяющим полет мысли было сложно… Гдето как крота с ласточкой.
                                                                                  Но дело в том что в IT инженер — это как директор в както попавшейся мне гейрбалайфоподобной конторе. Не было там никого ниже директора, так и тут нет техников — они все называются инженерами. А инженеры называются архитекторами. В общем просто подмена понятий.
                                                                                  Если бы были такие должности как «верстальщик кода», «алгоритмист», «техник-монтажник» — было бы понятнее, но путем присвоения красивого и звучного звания «программист» быдлокодеру — можно сыграть на его себялюбии и удержать при меньшей зарплате. :)
                                                                                  И я вижу различие. Но вот почему-то слишком много «двигателистов» поработав в должности — мнят себя инженерами…
                                                                              0
                                                                              Не «двигателист», скорее все-таки «проектировщик/создатель машин» или «машинник», если по вашему. :) И в общем случае подразумевается как раз человек, который и в теме насчет марки стали (или хотя-бы понимающий, что этот вопрос обязательно требует подключения профильного специалиста), и потенциально способный выдавать нестандартные решения, типа роторно-поршневого двигателя (если уж вы начали о ДВС).
                                                                                0
                                                                                Кхм.

                                                                                Если ссылки не помогают, скажу прямо:

                                                                                An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics, and ingenuity to develop solutions for technical problems. Engineers design materials, structures, and systems while considering the limitations imposed by practicality, regulation, safety, and cost. The word engineer is derived from the Latin roots ingeniare («to contrive, devise») and ingenium («cleverness»).
                                                                            0
                                                                            Написано хорошо и правильно — но всю статью пережевывается одна банальная мысль — не принимайте на веру чужой опыт.
                                                                            Относитесь ко всему со здоровым скептицизмом. Особенно к тому, на что молятся массы. Думайте своей головой.

                                                                            Автор, спасибо.
                                                                              0
                                                                              PS: Собственно к данной статье это тоже относится ;)
                                                                              0
                                                                              Я считаю, что есть только один хороший паттерн — сажать разработчика на поддержку своего проекта. А там уж пусть как хочет, так и пишет. И не важно — наговнокодил он или напаттернил. И то, и другое может вызвать жуткий баттхерт у другого программиста.
                                                                                +2
                                                                                Это экономически нецелесообразно.
                                                                                  0
                                                                                  Если узко смотреть, то да. А если весь жизненный цикл продукта учесть, то уже не факт.
                                                                                    0
                                                                                    Как раз наоборот. Вы же не хотите зависеть от единственного поставщика услуг на протяжении всего срока дизни продукта, давая ему тем самым возможность диктовать вам условия?
                                                                                      0
                                                                                      Клиент по любому будет зависеть от разработчика, который написал программу. И надо сразу в договоре прописать его обязательства по поддержке. Иначе у клиента может быть полная засада при выявлении проблем.

                                                                                      Проблема в том, что все стремятся оптимизировать только себя. Если «написал, сдал, а там хоть трава не расти». То трава и не вырастет. А если на поддержку посадили, то он опять себя начинает оптимизировать, но уже на новом уровне — чтобы было просто для юзеров и безглючно.
                                                                                        0
                                                                                        Клиент по любому будет зависеть от разработчика, который написал программу.

                                                                                        Вот этого и надо избегать. По крайней мере, это в интересах клиента (или, если смотреть мельче, в интересах начальства конкретного программиста).

                                                                                        И надо сразу в договоре прописать его обязательства по поддержке.

                                                                                        Не выйдет. Ну будет у вас в договоре полгода гарантийного обслуживания — а дальше что? А пожизненные обязательства на себя никто брать не будет, это невыгодно.

                                                                                        А если на поддержку посадили, то он опять себя начинает оптимизировать, но уже на новом уровне — чтобы было просто для юзеров и безглючно.

                                                                                        Кто вам это сказал?
                                                                                          0
                                                                                          Время жизни конкретной программы обычно не более 3-5 лет. Этого вполне хватит для «пожизненных» обязательств. А если продукт развивать, то опять же это уже долгосрочный договор. К примеру, на холодильники в среднем гарантия 3 года. И ничего — живут же (заметьте, там есть такая фишка как износ).

                                                                                          Кто вам это сказал?

                                                                                          Мне это говорит логика. Все пытаются внедрять паттерны и всяческие улучшалки кода, чтобы в нем было легче разобраться стороннему программисту. Но фишка в том, что это базируется на изначально плохом предположении, что нужно отдать поддержку и развитие кода стороннему программисту. То есть модель написал, сдал и забыл. Я понимаю, что пока это не во всех случаях сработает, но стремиться к этому нужно обязательно. На мой взгляд, это как бы показатель зрелости индустрии.
                                                                                            0
                                                                                            Время жизни конкретной программы обычно не более 3-5 лет.

                                                                                            Во-первых, вы никогда не видели систему старше десяти? Я видел.

                                                                                            А во-вторых, за это время можно сменить двух-трех контракторов.

                                                                                            Этого вполне хватит для «пожизненных» обязательств.

                                                                                            За деньги в несколько раз превышающие стоимость разработки.

                                                                                            Но фишка в том, что это базируется на изначально плохом предположении, что нужно отдать поддержку и развитие кода стороннему программисту.

                                                                                            У вас неверная формулировка: не «стороннему», а «другому». Вот у меня в отделе ротация кадров — код писал один человек, через месяц уволился, теперь поддерживать другому. Я, очевидно, заинтересован в том, чтобы этот «другой» мог в нем (коде) разобраться быстро, а стоимость его поддержки была минимальной.
                                                                                              0
                                                                                              Я тоже видел систему старше десяти лет. Ее грызут одни и те же програмисты. Стоимость разработки при поддержке другим программистом возрастает, а не уменьшается! Потому что ему сложнее и дольше разобраться в коде.

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

                                                                                              На самом деле такая поддержка занимает не так уж много времени и не напрягает.
                                                                                                0
                                                                                                Стоимость разработки при поддержке другим программистом возрастает, а не уменьшается!

                                                                                                Понятно. Контрактов с пятикратно завышенной ценой просто потому, что «а куда вы денетесь», вы не видели?

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

                                                                                                Вот об этом я и говорю: вы исходите из благонамеренности разработчика. А зря.
                                                                                                  0
                                                                                                  Мы просто сейчас говорим о разных вещах. Я говорю о том, как надо, а вы о том, как есть. Я и без вас знаю, что мир несовершенен. Что на улице кучи собачьего дерьма. Но это не значит, то так должно быть и не надо стремиться к чистоте и порядку.

                                                                                                  Ну, то есть, разрабочик ПО, в моем понимании, это производитель (а не просто работник). А значит, должен обеспечивать гарантию. Короче, он хотя бы «вправе» это делать, как по закону о защите прав потребителя.

                                                                                                  Не знаю, есть ли возможность по трудовому кодексу заключать такие соглашения (в плане прописывания обязанностей по поддержке). Если нет, то в принципе, неплохо было бы ввести такую инициативу. Хорошо бы у юристов спросить…

                                                                                                  Если такую возможность ввести, то это нехило бы изменило ландшафт. Дополнительным бонусом было бы уменьшение монополизации. Например, все пользуют 1С, Java, C#, PHP и т.п., потому что там уже сформирован рынок труда. Разработка на чем-то новом и перспективном не ценится, как раз из-за косяков с поддержкой. А гарантийную поддержку сложно или нельзя прописать юридически. Поэтому имеем сильную тенденцию к монополизации. Это относится в том числе и к ОС, СУБД и прочим платформам.

                                                                                                  Как считаете?
                                                                                                    0
                                                                                                    Ну, то есть, разрабочик ПО, в моем понимании, это производитель (а не просто работник).

                                                                                                    Уже неверно. Чтобы он был производителем, ему нужно дать больше автономности — что неэффективно для компании.

                                                                                                    Не знаю, есть ли возможность по трудовому кодексу заключать такие соглашения (в плане прописывания обязанностей по поддержке).

                                                                                                    Нет. Если мы говорим о наемном труде (а не о контракте на выполнение работ) — то нет.

                                                                                                    Как считаете?

                                                                                                    Считаю, что у нас с вами диаметрально противоположное понимание монополизации. В моем представлении монополизация — это когда конкретные работы может выполнять только один исполнитель (что ставит его в положение монополиста). И это как раз то, что вы предлагаете своим «пусть поддерживает тот, кто пишет».

                                                                                                    Еще раз: поддержка — это рынок. Нет никакого смысла быть на нем альтруистом.
                                                                                                      0
                                                                                                      Ну вот вы говорите, что у вас из отдела увольняются программисты, остается какой-то рабочий код. Почему вам, как компании неэффективно, чтбы они поддерживали то, что они накодили? Хотя бы в течение гарантийного срока. Хотя бы за четко прописанные деньги. Я реально не понимаю вашей логики. Ну и пусть вы будете зависеть от программиста. Но и он же по договору будет привязан к вам. Риски же снижаются, стоимость работ тоже.
                                                                                                        0
                                                                                                        Потому что качество этой поддержки будет ниже, чем мне бы хотелось — и у меня нет ровным счетом никакого способа повлиять на него.
                                                                                                          0
                                                                                                          Почему качество поддержки будет ниже?
                                                                                                            0
                                                                                                            Потому что у исполнителя нет никаких причин делать свою работу хорошо — все равно от этого ничего не зависит.
                                                                                                              0
                                                                                                              Почему не зависит? Во-первых, если поддержку прописать в договоре, то качество ничем не будет отличаться. Во-вторых, качество исправления глюков дискретно: или исправил, или нет. В-третьих, программист будет заинтересован в уменьшении количества обращеней к нему. В-четвертых, программист будет-таки ловить свои глюки, а не чужие. А это две большие разницы.
                                                                                                                0
                                                                                                                Ваш варинат — утопия.
                                                                                                                Давайте рассмотрим причины ухода человека с работы

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

                                                                                                                Уволили
                                                                                                                Когда работника увольняют по любой из причин, это является стрессовой ситуацией для него. Происходит процесс «сжигания мостов», чтобы быстрее построить новые. Нередко возникнет желание отомстить за несправедливое отношение или апатия. Оба варианта являются рисковыми для работодателя. Чтобы снизить риски нужно будет создать процесс контроллирования работы саппортера кода. Это уже дороже замещения данной вакансии новым работником.

                                                                                                                Уволился сам
                                                                                                                Причины могут быть разными, но интерес к написанному коду все еще теплится. Работник уже принял решение, что интерес к новой работе превышает интерес к текущей, и восстановить статус кво будет очень сильно трудно.

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

                                                                                                                  А насчет утопии я не согласен. На собственном опыте — ничего страшного не вижу. Это договоренность просто. Хочешь — договаривайся, хочешь — нет. Выбор каждого. В конце концов за поддержку старого кода деньги платят. Это обычная работа.
                                                                                                                    0
                                                                                                                    Вот именно потому, что «хочешь — нет» работать и не будет. Мало кто захочет.
                                                                                                                  0
                                                                                                                  Во-первых, если поддержку прописать в договоре, то качество ничем не будет отличаться.

                                                                                                                  От качества работы того же программиста ранее. В лучшем случае. И кто сказал, что оно меня устраивало?

                                                                                                                  Во-вторых, качество исправления глюков дискретно: или исправил, или нет.

                                                                                                                  Глупости какие. Есть как минимум «за сколько времени» и «какой ценой для системы».

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

                                                                                                                  Зависит от условий договора.

                                                                                                                  В-четвертых, программист будет-таки ловить свои глюки, а не чужие. А это две большие разницы.

                                                                                                                  Несомненно. Свои ошибки замечать сложнее.

                                                                                                                  Но самое главное: вы забываете, что «поддержка» — это не только исправление ошибок. Модернизировать систему кто будет? Или написали и выбросили?
                                                                                                                    0
                                                                                                                    Ладно, господа. Надоело мне тут с вами спорить ниачем. Все равно никто никого не переубедит.
                                                                                  –1
                                                                                  Все правильно, со всем согласен, не согласен только с тем, что разработчик не должен спорить с лидом. Наобород, команда должна участвовать в принятии решений, спорить, доказывать, а иногда даже саботировать решения тимлида (да-да, в прямом смысле этого слова). Ведь такой лид уйдет, а разгребать оставшееся болото придется команде. У хорошей команды должен быть инстинкт самосохранения.
                                                                                    0
                                                                                    Вы уверены, что уйдет лид, а не команда?
                                                                                    0
                                                                                    При наличии компетентного руководства очень может статься, что его «уйдут», отправят на второстепенный проект или переведут на какую-нибудь не слишком ответственную должность до того, как разбежалась вся команда.
                                                                                      0
                                                                                      При наличии компетентного руководства не должно быть некомпетентного тимлида.

                                                                                      (ну и вы почему-то исходите из того, что команда знает лучше тимлида, хотя у него — при компетентном руководстве — больше опыта и выше профессиональный уровень)

                                                                                      Можно спорить, можно отстаивать свою точку зрения, но если решение принято — его надо соблюдать, иначе это ставит под угрозу весь продукт.
                                                                                        0
                                                                                        Мы видимо подразумеваем разные случаи. Если это вариант, где гуру руководит работой студентов, то мне кажется, что и разногласий у них не возникнет. А вот когда уровень у всех примерно одинаковый, точка зрения команды может оказаться полезной, по крайней мере игнорировать ее означало бы то же самое, что нанять студентов. И в этом случае в решении, принятом одним человеком рисков будет больше, чем в коллективном.

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

                                                                                        Так вот, я это все к тому, что тимлид — должность, требующая навыков общения с людьми и умения находить компромиссы. Если кто-то не согласен с его точкой зрения, он должен высказать свои сомнения. Если при этом возникают серьезные разногласия и при этом окончательное решение продавливается административными методами — значит перед нами некомпетентный тимлид. В этом случае как раз уместно игнорирование такого решения.
                                                                                          0
                                                                                          А вот когда уровень у всех примерно одинаковый

                                                                                          Когда уровень примерно одинаковый, не должно быть тимлида. Смысла нет.

                                                                                          В этом случае как раз уместно игнорирование такого решения.

                                                                                          Нет. У вас нарушена логика. Вы считаете признаком некомпетентности тимлида тот факт, что он продавливает решение административными методами. Это означает, что его некомпетентность лежит в области управления людьми, а не правильности принимаемых решений — и поэтому из этого никак не вытекает, что его решение нужно игнорировать.

                                                                                          Если же «команде» кажется, что решение тимлида неверно технически (кстати, такого обычно не бывает, чаще это кажется одному из членов команды), то нельзя его тихо игнорировать — это банально опасно. Нужно либо увольняться, либо идти к начальству.
                                                                                            0
                                                                                            Когда уровень примерно одинаковый, не должно быть тимлида. Смысла нет.

                                                                                            Проблема в том, что мы не можем построить коммунизм внутри отдельно взятой команды, кто-то должен заниматься общими вопросами.

                                                                                            Нет. У вас нарушена логика. Вы считаете признаком некомпетентности тимлида тот факт, что он продавливает решение административными методами. Это означает, что его некомпетентность лежит в области управления людьми, а не правильности принимаемых решений — и поэтому из этого никак не вытекает, что его решение нужно игнорировать.


                                                                                            Логика в том, что решение, которое приходится продавливать вряд ли чем-то обосновано, иначе остальные не стали бы дружно протестовать.

                                                                                            Если же «команде» кажется, что решение тимлида неверно технически (кстати, такого обычно не бывает, чаще это кажется одному из членов команды), то нельзя его тихо игнорировать — это банально опасно. Нужно либо увольняться, либо идти к начальству.


                                                                                            Насчет отдельных разработчиков — соглашусь, это встречается чаще, но решается просто — назначением задачи на кого-то из числа согласных, конфликта при этом не возникает. Но заявление по собственному, как по мне, очень уж радикальная мера.
                                                                                              0
                                                                                              Проблема в том, что мы не можем построить коммунизм внутри отдельно взятой команды
                                                                                              Вы про self-regulating teams (в скраме, например) не слышали?

                                                                                              кто-то должен заниматься общими вопросами.

                                                                                              Это какими, например?

                                                                                              Логика в том, что решение, которое приходится продавливать вряд ли чем-то обосновано, иначе остальные не стали бы дружно протестовать.

                                                                                              Эта логика неверна. Во-первых, я еще ни разу не видел, чтобы команда протестовала «дружно». А во-вторых, люди могут протестовать просто в силу неприятия нового (или нежелания делать больше работы, или еще что-то).

                                                                                              Зачастую людям банально лень.

                                                                                              решается просто — назначением задачи на кого-то из числа согласных

                                                                                              К сожалению, это не решает проблем системного характера (тесты, конвенции, трекинг и так далее).

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

                                                                                              А зачем мне сотрудник, который не согласен работать так, как я считаю лучше для компании? Тем более — зачем мне сотрудник, который осознанно саботирует принятые в компании решения?
                                                                                                0
                                                                                                Вы про self-regulating teams (в скраме, например) не слышали?

                                                                                                Может быть где-то в параллельной вселенной и существует такое явление, но в реальности хоть убейте, не могу себе представить заказчика, который вкладывает в проект свои деньги и соглашается с тем, что ответственность в случае каких-то неприятностей ляжет на абстрактную «команду» — он скорее будет скандалить и требовать линчевать скрам мастера / тимлида / техлида / кого угодно еще.

                                                                                                А зачем мне сотрудник, который не согласен работать так, как я считаю лучше для компании? Тем более — зачем мне сотрудник, который осознанно саботирует принятые в компании решения?

                                                                                                Вы подменяет смысл сказанного. Речь шла о том, зачем сотруднику увольняться в случае разногласий и я высказался в том смысле, что «незачем». Если вы говорите о том, зачем тимлиду сотрудник и почему бы ему просто не уволить такого умника, то нужно понимать, что во-первых решения об увольнении не принимаются спонтанно одним человеком, это достаточно сложный и неприятный процесс, а во-вторых тимлид же и нанимал этого человека, стало быть попытаться уволить кого-то — все равно что признаться в собственной ошибке.
                                                                                                  0
                                                                                                  Может быть где-то в параллельной вселенной и существует такое явление, но в реальности хоть убейте, не могу себе представить заказчика, который вкладывает в проект свои деньги и соглашается с тем, что ответственность в случае каких-то неприятностей ляжет на абстрактную «команду» — он скорее будет скандалить и требовать линчевать скрам мастера / тимлида / техлида / кого угодно еще.

                                                                                                  Заказчика это вообще волновать не должно. Заказчика общается с руководителем проекта (который с тим-лидом ничего общего не имеет).

                                                                                                  Речь шла о том, зачем сотруднику увольняться в случае разногласий и я высказался в том смысле, что «незачем».

                                                                                                  Альтернатива — идти к начальству — озвучена уже.

                                                                                                  во-вторых тимлид же и нанимал этого человека, стало быть попытаться уволить кого-то — все равно что признаться в собственной ошибке.

                                                                                                  Признавать свои ошибки как раз полезно.
                                                                                                    0
                                                                                                    Заказчика это вообще волновать не должно. Заказчик общается с руководителем проекта (который с тим-лидом ничего общего не имеет).

                                                                                                    Хорошо, допустим в той схеме, о которой вы говорите есть некий руководитель проекта и нет тимлида, но что он будет делать в случае неудач? Он будет объяснять заказчику что луна в стрельце или попробует внутри команды найти виноватого? А найдет ли?
                                                                                                      0
                                                                                                      Он будет объяснять заказчику что луна в стрельце или попробует внутри команды найти виноватого? А найдет ли?

                                                                                                      А не надо искать внутри команды виноватого. Нужно спрашивать у команды, как и когда проблема будет решена.
                                                                                      0
                                                                                      тезисы статьи:
                                                                                      — не все паттерны нужно применять… и не везде…
                                                                                      — обьектноориентированный подход не самый лучший и не единственный
                                                                                      — тестирование не решает все проблемы
                                                                                      — цена разработки программы должна быть меньше ее продажной цены
                                                                                      (привет кэп)

                                                                                      странный вывод из всего этого: современные методики разработки зло.
                                                                                      причем если неопытные разработчики делают все плохо по незнанию, то опытные злонамеренно, из гордыни…

                                                                                      … проэкты которые не надо поддерживать, они пишуться изначально без ошибок, одним человеком в обозримое время и больше не повторяются — это плод больного воображения
                                                                                        0
                                                                                        Один из основных тезисов (даже рецептов), который всегда мне приходил в голову при произнесении предложений в стиле «А почему от GoF я не стал писать код лучше?», «Что-то я не могу понять, где какой паттерн запихнуть», и.т.д. автор изложил в следующем предложении
                                                                                        Если вы все таки хотите понять кто и зачем все это использует, то
                                                                                        изучайте код больших проектов на Java, C#, C++.


                                                                                        Остается только добавить, что нужно изучать код хороших с т.з. этого самого кода проектов. Какой проект хороший — для новичка определить трудно.
                                                                                          +1
                                                                                          Можно сократить пост до фразы: «мода ≠ догма».

                                                                                          Only users with full accounts can post comments. Log in, please.