Не нанимайте крутых программистов, если вы стартап и только начали делать продукт. Они вам все испортят

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

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

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

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

Когда я приступил к работе, я охренел. У них всё было сделано неправильно. Они буквально в тупую брали и решали проблемы продукта, подпирая один костыль двумя другими. Они не выстраивали хорошую архитектуру, не работали по практикам, их кодом можно было выжигать разработчикам глаза.

Я сразу сказал прямо — это не код, это дырявый пакет с мусором, мы всё здесь к чертям перепишем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
397 комментариев
Написать комментарий...
Илитный Иксперт
Не нанимайте крутых программистов

Начнем с того, что Фил не имеет отношения к крутым программистам. Ну может он конечно общался с ними, жал им руки. Но сам - нет.

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

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

Не надо противопоставлять говно на коленке и вылизанный идеальный проект. Это две стороны задней части медали. Опытный разраб пишет быстро и на коленке нормально, не вылизано, но и не говно.

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

Хорошие тесты - это не 100% покрытие, а тесты в местах где ошибки реально критичны, и где ошибок и времени на их фикс больше чем на написание тестов. И уж тем более ни тогда, когда код или архитектура проекта специально приспосабливается под тесты - это конечная остановочка.

Качественно писать код - это не 0 костылей, это костыль вместо переписывания половины проекта, это знать где костыль лучше вместо рефакторинга. 

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

А вообще начинать технический стартап не имея скилла в этой области или доверенного человека с такими скиллами - это лотерея.

Ответить
Развернуть ветку
Фил Ранжин
Автор

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

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

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

Твои опытные разрабы, которые пишут быстро и с приемлемым качеством хороши во всем, но у них одна проблема - они вымышленные.

Классная архитектура, это как в книжке той же "Банды Четырех", каждый из которых писал приложения, размеры и важность которых недостижимы ни для тебя ни для меня.

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

Качественно писать код - это качественно писать код. А городить костыли ради экономии бюджета - это качественно вести бизнес.

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

Ответить
Развернуть ветку
Илитный Иксперт
Классная архитектура, это как в книжке той же "Банды Четырех"

Три раза кек.

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

Программирование - это инженерная специальность. Какая главная задача инженера? Проектировать. Задача программиста - не писать код, не двигать кнопочки, не гонять данные, а проектировать информационные системы.

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

Привожу твои слова

Всю свою карьеру я вносил мизерный вклад в гигантские системы

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

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

Максимальная аналогия для быдла: можно читать сколько угодно книжек про секс, но чтобы иметь минимальный уровень ебли, надо хотябы одну телку выебать, и не один раз. А ты за свою карьеру много телок перелапал, каких то за сиськи, каких то за жопу. А то что их ебать надо, ты и не знаешь. Зато ссылаешься на книжку "половое образование для девочек" из ХХ века. 

Классная архитектура, это как в книжке той же "Банды Четырех", каждый из которых писал приложения, размеры и важность которых недостижимы для меня.

Пофиксил тебя.

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

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

Если обратиться к реальной архитектуре, всмысле домов, то мы увидим что из готовых блоков можно построить хрущевку, в 3 этажа или в 5, в 5 подъездов или в 10. Но ничего кроме хрущевки нельзя. Ни мост, ни любое другое нормальное здание. Только ебучую панельку.

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

Ты ссылаешься на книгу, смысла которой не понимаешь, чтобы аргументировать свою "правоту" в теме, в которой ничего не понимаешь. Это унизительно.

а судя по херне про неважность архитектуры

То что ты интерпретировал мои слова про архитектуру, как ее неважность еще раз подтверждает факт того, что ты не понимаешь что это такое. Я наоброт написал что архитектура критически важна, это размазано по всему тексту моего комментария. Просто кто-то видит на доске интеграл, а кто-то уебищную букву S.

а судя по херне про неважность тех же наименований

Да, да, да. В проектировании архитектуры здания самое важное каким шрифтом подписи в чертеже делать. 

Твои опытные разрабы, которые пишут быстро и с приемлемым качеством хороши во всем, но у них одна проблема - они вымышленные.

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

Качественно писать код - это качественно писать код.

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

Рефакторинг, блядь. А то о чем ты говоришь - это переработка.

Как-то давным давно я зашел в магазин техники, чтобы купить вайфай роутер. Подошел к продавцу, и попросил показать роутеры. Он долго не мог ничего найти и показывал мне какуюто странную хуйню. На вопрос "что за хуйня?" он сказал что wifi - это маршрутизатор, а не роутер. Я покекал и унес домой коробку с моим роутером на одной стороне который было написано "маршрутизатор", а на другой "router". Так вот вопрос, это был не ты?

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

Ответить
Развернуть ветку
Anton Kozlov
 Паттерны не подменяют и не заменяют умение проектировать. Да, они задумывались для этого, но эта попытка провалилась.

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

Ответить
Развернуть ветку
Гала Перидоловна

Да, паттерны не провалились. Это лишь обобщение практик. Но их нужно грамотно применять, чтобы в погоне за "правильным" кодом не получился только "правильный код". Это хорошо прослеживается когда человек читает книжку по паттернам и начинает лепить паттерны ради паттернов. Но потом это проходит со временем, правда не у всех. А так как не обзови их, они все равно будут присутствовать в коде. В openssl, например, многие калбеки организованы так, что стейт можно прокинуть только через ex_data и вот хоть как не пытайся, но все равно там получится синглтон. Иначе получаютс статически переменные, которые приводят к лапше из кода.

Ответить
Развернуть ветку
Илитный Иксперт

Провалились. 

Проектирование - это процесс, которому надо достаточно долго учиться. Это дорого, а программистов нужно много.

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

В результате полиндустрии только говнякать и умеют.

Это лишь обобщение практик

Нет. Практики - это ответ на вопрос "как делать". А паттерны - ответ на вопрос "что делать". Люди, изучающие паттерны не учатся тому как надо проектировать, они начинают запоминать готовые кусочки.

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

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

А потом начинаются разговоры типа

Но их нужно грамотно применять

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

Ответить
Развернуть ветку
Гала Перидоловна
Провалились.

Паттерны не могут провалиться, т.к. это просто теория. Обобщение информации. Человек даже не зная паттернов в том или ином виде все равно к ним приходит.

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

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

Нет. Практики - это ответ на вопрос "как делать". А паттерны - ответ на вопрос "что делать". Люди, изучающие паттерны не учатся тому как надо проектировать, они начинают запоминать готовые кусочки.

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

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

Есть конечно меньшинство, которое может создать что-то не имея опыта разбора готовых результатов, но таких единицы. Из моих знакомых это 4 человека. Один поступил в МГУ на мехмат в 14 лет, остальные чуть позже, но только из-за определенных особенностей системы обучения. Вот они реально могут и занимаются теоретической частью CS. Все остальные не сильно уступают в плане проектирования, но они все читали книги по паттернам. Паттерны даже смотрят на собеседованиях в больших компаниях, но это не первичная задача конечно. Просто за процедурную лапшу возьмут на грейд ниже, ну или вообще не возьмут.

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

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

Ответить
Развернуть ветку
Илитный Иксперт
Там воткнул - здесь воткнул

Ну так потом и получается

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

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

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

а можно просто дать книжку.

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

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

Практики - это ответ на вопрос "как делать". А паттерны - ответ на вопрос "что делать"
Это лишь вопрос восприятия. 

Это не вопрос восприятия, это две разных вещи вообще. В этом и вред паттернов, в том что ты эту разницу не видишь. Отсюда и споры.

Ответить
Развернуть ветку
Гала Перидоловна
И научить их - это проблема, потому что они уже научились думать ебучими паттернами, и привыкли что все просто, сунул паттерн тут, сунул там и кое как работает. А оказывается что проектировать по нормальному в десятки раз сложнее. А если не научиться, то либо будешь дальше клепать по шаблончику куски проектов, либо делать говнище из паттернов на паттернах.

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

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

Это значительная часть, т.к. без нее ты не сможешь коммуницировать внутри команды. В крупных проектах в которых мне довелось учавствовать люди не передавали информацию в виде: "да я тут сделал вот этот класс, у него такие методы и вот так вот все передается". Это выглядело как: "я тут сделал фасад, код упростил, посмотри чо как".  Без этих знаний просто не возьмут на грейд, который позволит именно проектировать что-то на уровне Гугл Спаннера или Кликхауса.

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

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

Это не вопрос восприятия, это две разных вещи вообще. В этом и вред паттернов, в том что ты эту разницу не видишь. Отсюда и споры.

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

Ответить
Развернуть ветку
Илитный Иксперт

Опять все те же мантры, "паттерны надо правильно применять", "это важно для коммуникации в команде", и т.п. 

Конечно не вижу, потому что ее нет

В этом и проблема всех любителей паттернов, они уже уверены что паттерны это и есть архитектура

Проектирование - это процесс, который делает человек чтобы создать архитектуру. А архитектура - это результат этого процесса.

Практики проектирования - это по каким принципам принимаются решения, по каким критериям оценивается качество архитектуры, какие надо принять решения в одном кейсе, а какие в другому и почему. Это KISS в конце концов, если вдруг сам до этого не осилил дойти.

А паттерны - это просто выделенные общие части в уже известном результате.  

Ты не видишь разницу между процессом и результатом, и в итоге сравниваешь жопу с пальцем и утверждаешь что четко видишь что это одно и тоже.

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

Кроме нарушения базовых принципов проектирования и игнорирования критериев качества архитектуры ничего, да. Для паттерноеба ничего удивительного.

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

Без знаний паттернов просто не возьмут на грейд, который позволит именно проектировать что-то на уровне Гугл Спаннера или Кликхауса.

Ладно, я понял, ты так уныло троллишь чтоли?

Ответить
Развернуть ветку
Гала Перидоловна
А паттерны - это просто выделенные общие части в уже известном результате.

Ого, ты наконец сам сказал то, о чем шла речь во всех 100500 коментах ранее. У нас наметился прогресс.

Ты не видишь разницу между процессом и результатом, и в итоге сравниваешь жопу с пальцем и утверждаешь что четко видишь что это одно и тоже.

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

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

Ой, у нас не ынытрпайз. Ты промахнулся. Ты наверное хотел сказать, что Java из-за своей ориентированности на ООП почти вся построена на паттернах. Самое забавное, что даже перебор элементов в три мапе С++ построен на паттерне "итератор", а уж в питоне итераторы и генераторы везде. Даже когда ты вот на vc.ru оставляешь комментарий openssl при создании соединения вызывает cpuid для того, чтобы реализовать паттерн strategy и выбрать реализацию алгоритма с использованием SSE или без.

Ладно, я понял, ты так уныло троллишь чтоли?

Нет, если ты конечно не любитель Lisp'а.

Ответить
Развернуть ветку
Илитный Иксперт
Да, есть некие общие паттерны в системах.

Ответ на то что ты пытаешься мне втолковать, я тебе дал еще много коментов назад

Провалилась попытка заменить изучением паттернов нормальные скиллы, что привело к массе паттерноебов, которые нормальных скиллов не имеют и не пытаются получить

Ты либо так уныло траллируешь, либо

Вообще не понял о чем тут текст.

Могу только предложить рассматривать эту картинку до посинения
https://vc.ru/hr/127122-ne-nanimayte-krutyh-programmistov-esli-vy-startap-i-tolko-nachali-delat-produkt-oni-vam-vse-isportyat?comment=1834044

Ответить
Развернуть ветку
Гала Перидоловна
Провалилась попытка заменить изучением паттернов нормальные скиллы, что привело к массе паттерноебов, которые нормальных скиллов не имеют и не пытаются получить

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

Могу только предложить рассматривать эту картинку до посинения

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

Ответить
Развернуть ветку
Илитный Иксперт
Ты не понимаешь! Нет, это ты не понимаешь!

Чувак, ты даже троллиль и споришь(если это можно так назвать) максимально уныло

Я тебе говорю что ты за забором леса не видишь, а ты мне говоришь что я не понимаю важности забора

Ответить
Развернуть ветку
Вадим Чиняев

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

По поводу много людей, ну ладно хоть не 90% ). По мне много больше людей справляется с фреймворками и знанием популярных либ. Я просто сталкивался с крупным софтом из говна и палок, но при этом стабильно работающим. Тем не менее не готов писать - "многие" Или вот это истинный путь. 

Ответить
Развернуть ветку
Гала Перидоловна
по поводу паттернов - реально карго культ. Как обизянки с гранатами, лишь бы присунуть. Особенно печально когда вместо решения задачи даже на непровославной процедурной лапше, "специалисты" генерят тонну бесполезных классов, в надежде что когда то их будут расширять и в том же духе.

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

По поводу много людей, ну ладно хоть не 90% ). По мне много больше людей справляется с фреймворками и знанием популярных либ. Я просто сталкивался с крупным софтом из говна и палок, но при этом стабильно работающим. Тем не менее не готов писать - "многие" Или вот это истинный путь.

Вообще не понял о чем тут текст.

Ответить
Развернуть ветку
Вадим Чиняев

поясняю - не оперирую процентом, но по своему опыту конторы чаще ищут не читателей книг, а практиков - знание фреймворков и набора либ. 

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

Ответить
Развернуть ветку
Гала Перидоловна
поясняю - не оперирую процентом, но по своему опыту конторы чаще ищут не читателей книг, а практиков - знание фреймворков и набора либ.

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

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

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

Ответить
Развернуть ветку
Иван Иванов

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

Ответить
Развернуть ветку
Илитный Иксперт

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

А людям без опыта ее абсолютно вредно читать. Большинство воспринимает ее как о, ебать, программы строятся из только паттернов, теперь знаю паттерны, ебать я архитектор. И они потом уже неспособны думать вне рамок паттернов. Вон там сверху Халя предлагает юзать абстрактную фабрику, хотя кейсов где она реально нужна в чистом виде - единицы, и я чот не уверен что он с ними сталкивался. Потому шо уже не понимает "как это можно без абстрактной фабрики то?"

Это как если бы художник всю жизнь жил в закрытой комнате с обоями из моны лизы, он бы только мону лизу и мог нарисовать.

Это как для человека который начинал обучение программированю с js

var str = "string"

это просто объект строки.

а для человека который начинал обучение с плюсов это   массив чаров, который упакован в объект string с кучей оптимизаций, который лежит внутри хеш-таблицы по ключу "str", раскручивать эту цепочку глубже можно еще долго

И если для плюсиста переключиться на уровень "ну это просто строка" очень легко, то джиесеру чтобы понять то что понимает плюсист надо несколько лет учиться. а учиться сложна и неохота, тем более что и так на работу берут и платят норм

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

Ответить
Развернуть ветку
394 комментария
Раскрывать всегда