{"id":9001,"title":"\u0417\u0430\u0447\u0435\u043c \u043d\u0443\u0436\u0435\u043d \u0444\u0438\u043d\u0442\u0435\u0445 \u043a\u0430\u043a \u0441\u0435\u0440\u0432\u0438\u0441. \u041d\u0430\u043f\u0430\u0434\u0430\u0435\u043c \u0441 \u043a\u0440\u0438\u0442\u0438\u043a\u043e\u0439","url":"\/redirect?component=advertising&id=9001&url=https:\/\/vc.ru\/promo\/321129-kritika-finteh-kak-servis-eto-dorogo-slozhno-i-slishkom-universalno&placeBit=1&hash=0f11beca127b0260f19ba1d57bd2ebb2f81750b56fe49269b93cb930545c9faa","isPaidAndBannersEnabled":false}
Карьера
Фил Ранжин

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
397 комментариев
Популярные
По порядку
Написать комментарий...

Не нанимайте крутых программистов

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

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

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

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

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

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

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

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

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

352

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

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

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

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

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

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

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

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

–50

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

Три раза кек.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

205

Ох и накатали вы текста, написали бы просто "спроектировал архитектуру тебе за щеку, проверяй"

115

Так не интересно

23

Ебать вас двоих козьим хером, влепил лайк обоим, продолжайте!

17

И я тут с попкорном постою!

5

Займу за вами

2

Аж чуть не прослезился, очень душевно 😅

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

24

Т.е. свой обсёр с тестами и рефакторингом ты решил просто не заметить?

–18

Обсер - это когда ты не смог понять текст комментария. Или ты 5к символов решил не заметить? Ладно, проиллюстриую свою мысль более понятным примером.

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

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

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

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

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

Твой уровень - это уровень секретарши, не разработчика, не инженера - а секретарши. Красиво и правильно оформить бумажки. И не видеть за этими бумажками сути.

А теперь я отвечу на твои предъявы
Обсер с рефакторингом

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

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

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

Я бы написал свое личное мнение про то что в TDD буква D обозначает "долбоеб", и то что если хочешь рисовать чертеж жопой - рисуй, твое право, каждый извращается как хочет. Может в этом даже реально свои плюсы есть. 

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

32

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

9

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

0

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

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

3

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

20

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

0

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

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

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

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

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

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

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

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

А потом начинаются разговоры типа
Но их нужно грамотно применять

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

8

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

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

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

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

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

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

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

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

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

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

8

Там воткнул - здесь воткнул

Ну так потом и получается
начинает лепить паттерны ради паттернов

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

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

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

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

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

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

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

Это лишь вопрос восприятия. 

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

3

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

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

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

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

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

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

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

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

4

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

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

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

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

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

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

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

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

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

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

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

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

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

0

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

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

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

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

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

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

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

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

2

Да, есть некие общие паттерны в системах.

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

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

Ты либо так уныло траллируешь, либо
Вообще не понял о чем тут текст.

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

1

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

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

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

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

3

Ты не понимаешь! Нет, это ты не понимаешь!

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

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

0

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

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

0

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

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

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

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

0

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

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

0

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

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

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

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

4

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

0

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

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

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

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

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

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

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

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

1

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

А ты мне втираешь что дверь в туалете надо ставить. Это даже умственно отсталые знают.

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

2

А вообще конечно эти слова нужно выбить в камне.

3

Господи, ты кто? Тебя что создал скайнет, чтобы в нужное время появится и рахренчить автора статьи? =) Лайк конечно, обоим, может что-то полезное узнаю

3

Илитно

1

Такое ощущение, что эта статья написана, чтобы Вы тут оставили свои комментарии :) 

1

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

В 2020 всерьёз приводить ООП-талмуд банды четырёх как ориентир, это десять из десяти, конечно.

12

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

0

Я отвечаю за качество всего сервиса(считай вообще всего что предоставляет компания), т.к. конечным продуктом моих ручек является сетевая штука, которая принимает вообще весь входящий трафик. У меня есть цели, которые заключаются в том, чтобы выжать +x% скорости каждый год. Если я ошибаюсь и это приводит к увеличению лейтенси, то и вся компания страдает. Смещается время загрузки на p99, пользователи ждут дольше и соотвественно раньше закрывают сайтик. Ни один менеджер или аналитик не сможет мне сказать что делать. Для этого ему нужно будет сначала погрузиться в  сетевые железки, процессоры и прочее, что приведет к тому, что он просто сам станет разработчиком.

0

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

0

наверное всё же за сервис аналитики и манагеры говорят вам, а вы всё же только и делаете сетевую штуку.

Зачем нужны аналитики и менеджеры, если у меня есть графики, которые покрывают все начиная от сетевой части и заканчивая статистикой из хрома?

То, что вы узконаправленный специалист уже как бы намекает на это.

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

0

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

0

Как это не может сказать, что делать?
"Повысь скорость открытия страницы до 300мс"

–1

Открытие страницы это не ко мне. Моя часть именно сетевой уровень, т.е. TCP/UDP,  TLS, передача самих данных. Отрытием страниц уже занимаются фротендеры, т.к. основное время тратится на рендер хтмлек. Человек, который придет и скажет что надо сократить время без понимания специфики работы всех слоев скорее всего пойдет искать новое место работы. Ну и с малой вероятностью сядет разбираться как заполняются буферы сетевых карт, чтобы правильно сформулировать задачу нужному отделу.

0

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

0

Просто ускорения не бывает. Бывает какая-то технология, которая возможно за X единиц ресурсов снизит лейтенси на Y или позволит на Z гигабайт больше трафика прокачивать. Чтобы принять решение реализовывать ее или нет нужно очень глубоко погружаться в тему, а если уж так глубоко погружаешься, то и смысла держать на позиции менеджера или аналитика нет. Задача менеджера на ревью рассказать какой ты крутой и почему ты должен получить промоушен.

0

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

0

Говоря про архитектуру в GoF - ты "каталог OBI" выдаёшь за "архитектуру дома".

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

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

0

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

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

4

Любой костыль - это сохранение текущего времени в ущерб будущему

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

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

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

При чем затраченное время нарастает по экспоненте в зависимости от наложенности костылей

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

Названный вами «долбоебизм» сохраняет огромную кучу ресурсов при масштабировании проекта при чем в любом направлении.

Да, да, да. Бездумное покрытие тестами всего и вся, многочасовой срач в код ревью по теме названий методов - сохраняет кучу ресурсов. Сами то понимаете что говорите?

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

Вот вы говорите "качество кода". А что это такое? В чем измеряется? С ходу ответите? Какой код качественный, а какой нет?

Или например
Вы никогда заранее не узнаете какая часть проекта будет меняться, а какая нет.

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

Или еще например
Костыль - это затрата и времени, и ресурсов.

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

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

Вот честно, наберитесь опыт сначала перед тем как спорить. 

73

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

–7

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

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

Костыльность растет системно до тех пор, пока вся эта хрень не перестает работать в принципе

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

16

Ну и давайте будем честны, проектов совсем без костылей не существует в природе. Если не считать таковыми - hello world

4

И за hello world я не уверен, так как такую простую функцию сделать на высокоуровневом языке вместо ассемблера, считай костыль )))))

3

Разработчики - уникальные инвалиды, любящие костыли.
- Ты хотел сказать индивиды?
- Нет.

4

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

1

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

И писать проект на коленке не значит строить его на костылях.  ред.

5

Автор ровно такой же, как 99% остальных разрабов. Лично я в скольких проектах работал, ни разу не видел ГРАМОТНОЙ архитектуры, ГРАМОТНОГО планирования разработки и т.п. Это настолько редкость, что пора в Красную книгу заносить.

7

Лично я в скольких проектах работал, ни разу не видел ГРАМОТНОЙ архитектуры

Ну так расскажите что такое по вашему грамотная архитектура

Автор ровно такой же, как 99% остальных разрабов.

Перебарщиваете, в индустрии все не настолько плохо ред.

3

Готовы ответить за всю индустрию? Успехов.

0

Вы хотябы на мой коментарий ответьте

6

 Ну так расскажите что такое по вашему грамотная архитектура

Это комплексный вопрос, на который в одном посте не ответишь; на него многие пытались ответить (так что ответов достаточно), в последнее время на него подзабили - всё правда, надо фигачить продукты и фичи, жизненный цикл короток и на раскачку нет времени (с). ред.

0

на него многие пытались ответить (так что ответов достаточно)

Так я ваш ответ хочу услышать, а не чужие.

Ладно, забейте, вы скучно тролите

5

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

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

–1

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

0

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

–3

Лол, ты че, серьезно зарегался чтобы показать как тебя триггернуло? Мне уже даже инетресно на что конкретно ты так обижаешься ред.

1

Бывают такие костыли, что век стоят - не шелохнутся. 10 раз "good practice" поменяется в индустрии, а костыль - вот он, стоит красавец, только крепче стал.

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

24

А потом костыль перерастает в CVE, остаётся только гадать сколько лет им пользовались не по назначению 😄

1

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

0

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

0

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

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

6

Если стартовали нормальные программисты это здание простоит и с вашей мансардой

3

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

5

Но здание же не обрушится, я видывал те здания которые рушились от таких конструкций

0

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

2

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

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

0

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

0

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

С этим всегда проблема. по крайней мере сейчас.

 Быстрых лидов я могу набрать по 12рублей за клик. Но от них одни проблемы они хотят за пол копейки миллион. И когда ты им говоришь, что из этого куска шерсти сделаешь 7 шапок, но они будут не по их размеру им пофиг. Поэтому работая с таким бизнесом будет fail = fail.

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

А тот кто сделал и оно работает и один раз взял много, но потом не дописывал свои баги за ваши деньги.

Это мой опыт среднего малого, и маленький кусок крупного бизнеса. Я не претендую на 100% верность своего опыта. просто делюсь тем, что уяснил за 10 лет.

2

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

0

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

0

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

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

1

Спорные утверждения с самого начала. Давайте я простой пример из жизни приведу: Вы делаете А/Б тест. Вообще если вы нормальная компания - вы всегда делаете А/Б тесты. Так вот, если вы будете писать на каждый тест супер крутой идеальный код без костылей - вы увеличиваете нагрузку на разработку в разы и выкидываете время (а значит - деньги) на ветер. Если вы хороший разработчик, вы понимаете, что это А/Б тест который с вероятностью 50--60-70-90% будет выкинут в корозину. И в данном случае задача номер 1 сделать чтобы оно работало. А вот после принятия результатов А/Б - код уже можно отрефакторить с делать лучше.

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

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

2

Поправлю
Вы делаете А/Б тест. Вообще если вы нормальная компания - вы всегда делаете А/Б тесты

Если вы не сервис с большим трафиком ("большой" - от индустрии зависит), то вы даже А/Б тест не делаете. Потому что вам нужен кратный рост аудитории, а не выжать еще чуть-чуть монетизации из текущей. А кратный рост и так видно

0

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

0

"Любой костыль - это сохранение текущего времени в ущерб будущему". верно в теории, но на практике есть два серьезных "но". 1-ое "но" - "сохранение текущего времени" происходит 100%, а вот "ущерб в будущем" наступает примерно "50/50". и 2-ое "но". сохранение времени, а значит более быстрый запуск позволяет быстрее заработать первые деньги (утрирую). кто играл в игры типа "варкрафт/старкрафт", знает силу умелого быстрого "раша" (rush) на ранних стадиях игры. так вот тут примерно то же самое.

0

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

14

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

4

А еще раньше были программисты и схемотехники как отдельные профессии. Пойдем глубже?

0

Я не застал тех кто совмещал бы и назывался просто программистом.

ps Схемоте́хника — научно-техническое направление, занимающееся проектированием, созданием и отладкой (синтезом и анализом) электронных схем и устройств различного назначения.

0

... Когда коммент лучше статьи

12

Не надо путать опытных программистов и крутых программистов. Это совершенно разные люди.

3

Не обязательно измерять опыт временем

0

Время ни при чем.

0

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

8

Ты не понимаешь значение термина "крутой программист". На пальцах: это чел, который работал в Яндексе или Гугле, Джетбрейнс или Оракл, даже год стажа достаточно. Опыт не важен, важен брэнд.

–16

и его отовсюду поперли)

10

На пальцах: это чел, который работал в Яндексе или Гугле, Джетбрейнс или Оракл

Это что-то из разряда культа карго. 

6

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

4

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

0

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

2

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

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

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

1

 фантастические решения

 с кривым-косым почерком, но инновационно и необычно

Данунах.
Разработка - ремесло. А разработчики - ремесленники на галерах. Гениев с ахуенными фантазиями тут не надо. ред.

2

Гении есть в любой сфере жизни, безотносительно необходимости в них. Но чаще они так же необходимы, как 99,99% стандартных трутней (боже, когда уже разработчики поймут, что они обычные шестерёнки бизнеса, а не боги снизошедшие на землю бренную?)

0

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

0
Уполномоченный файл

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

1

напомнило: http://macode.ru 

5

Типа Брюс Уиллис, который в каждом фильме спасает планету одним движением брови.

0

Полностью поддерживаю! Автору рано ещё называть себя крутым разработчиком. Без обид.

2

"Крутая архитектура это не когда как в книжках, от профессоров, которые ничего кроме текста лаб не писали. " wtf am I reading.

0

Добрый день.

Прочитал массивный кусок этого треда и ваших комментариев в частности.

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

Каким образом вы видите развитие навыков проектирования у бывших студентов, которые становятся программистами (и нужно ли им это вообще)? Ну и как собственно развивать эти навыки у себя?  Существует ли какой-то системный подход для этого?

Было бы круто, если бы вы написали статью на эту тему, потому что видно по крайней мере по тому, что вы пишите, что у вас довольно большой опыт.

0

Каким образом вы видите развитие навыков проектирования у бывших студентов, которые становятся программистами

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

Ну и как собственно развивать эти навыки

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

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

Поэтому стоит выбирать проекты, где еще нет готовых решений. Игры (Хотя сейчас есть unity где тоже все готовенькое), библиотеки, фреймворки. Помню раньше был бум писателей своих CMS с которых многие угарали, но это наверное один из лучших примеров для обучения. Пользоваться этими говноcms конечно никто не будет, но чтобы навыки прокачать - лучше не придумаешь.

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

Существует ли какой-то системный подход для этого?

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

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

1

Согласен с вами, что разработчики должны прокачивать скилл на своих проектах, уметь проектировать систему с нуля, понимать работу системы на всех слоях абстракции. Но таких людей единицы, чаще же встречаются люди, которые имеют какой-то опыт, но в некоторых вопросах уперлись в тупик или (и) имеют неверное представление, таких нужно только подтолкнуть, указать верный путь и помочь (!) развиться.
Если смотреть на вещи как - вы все пидарасы, а я мушкетер - то никакого развития не будет. Это как про масштабы команды, так и про все программистское сообщество в целом.
Не согласен с вами, что систематизированные подходы (чистый код, паттерны) делают из людей дурачков. Проблема не в самой информации, а в слепом следовании идеям. Всегда нужно иметь голову на плечах. А тем, у кого нет своей головы, помочь ее найти (см. предыдущий абзац). Систематизация информации встречается повсюду, в том числе в упомянутом вами сопромате: можно было бы вручную выводить формулы расчета напряжений в балках, вычислять объемные интегралы, потратив кучу времени и наделав ошибок, а можно воспользоваться готовой формулой и типовыми схемами расчета напряжений.
Также не согласен, что тренды и хайповость это прямо очень плохо (это в тему другого поста про контейнеризацию и микросервисы). Тренды / хайп стимулируют сообщество как катализатор. Взять тот же кубер. Проблема с управлением кластера были, каждый решал ее своим костылем, если мог. Гугл сделал свое решение, стал форсить тему, получил обратную связь, что-то дополнил и улучшил. В итоге имеем поддерживаемый рабочий продукт (!).
И опять же, не надо думать, что кубер виноват, что манагеры и девопсеры стремяться впихнуть его туда, где ему не место. Это проблема самой организации, а не инструмента.

0

Главная проблема - это отстутсвие программисткой школы. В итоге качественные программисты сейчас просто не воспроизводятся. 

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

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

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

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

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

1

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

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

Систематизация информации встречается повсюду, в том числе в упомянутом вами сопромате

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

Всегда нужно иметь голову на плечах

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

0

Взять тот же кубер

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

чаще же встречаются люди, которые имеют какой-то опыт, но в некоторых вопросах уперлись в тупик или (и) имеют неверное представление, таких нужно только подтолкнуть, указать верный путь и помочь (!) развиться.

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

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

0

Спасибо, есть над чем поразмыслить.

А какую-то профессиональную литературу имеет смысл читать в начале пути или это скорее всего принесет только вред?

0

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

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

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

0

Хотел написать похожий комментарий, но даже добавить нечего. Архитектурные астронавты такие астронавты... https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

0

А вы видели вообще большие проекты написанные без паттернов и архитектуры? По принципу лишь бы работало? 
Когда например в проекте несколько однотипных бинарников с копией оболочки, общаяющиеся между собой одновременно через локальный вебсервер по http и COM+ какому-нибудь. 
Или нестареющая классика вроде Microsoft Access + интеграционная обвязка на VB. 

Статья хорошая и Joel не дурак, но свою голову то тоже включать рекомендуется.

0

Сколько раз вам паттерноебам повторять: паттерны != архитектура, и паттерны != проектирование архитектуры. Паттерны - частный случай архитектуры, и имеют весьма слабое отношение к проектированию.

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

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

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

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

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

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

0

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

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

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

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

1