Карьера
Фил Ранжин
37 783

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

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

В закладки
Аудио

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{ "author_name": "Фил Ранжин", "author_type": "self", "tags": ["\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430","\u043f\u0440\u043e\u0434\u0443\u043a\u0442"], "comments": 383, "likes": 193, "favorites": 318, "is_advertisement": false, "subsite_label": "hr", "id": 127122, "is_wide": false, "is_ugc": true, "date": "Thu, 14 May 2020 20:48:34 +0300", "is_special": false }
Zadarma
Виртуальный телефонный номер через «Госуслуги»
Теперь все, кто имеет подтвержденную учетную запись на портале «Госуслуги» или онлайн-банке одного из трех популярных…
Объявление на vc.ru
0
383 комментария
Популярные
По порядку
Написать комментарий...
339

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

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

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

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

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

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

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

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

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

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

Ответить
–47

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

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

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

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

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

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

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

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

Ответить
196

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

Три раза кек.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
33 комментария
11

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

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

Ответить
0

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

Ответить
9 комментариев
0

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

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

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

Ответить
4

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

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

Ответить
72

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
17 комментариев
24

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

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

Ответить
2 комментария
6

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

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

Ответить
10 комментариев
2

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

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

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

Ответить
2 комментария
0

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

Ответить
12

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

Ответить
4

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

Ответить
2 комментария
12

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

Ответить
3

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

Ответить
0

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

Ответить
12 комментариев
1

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

Ответить
5

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

Ответить
0

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

Ответить
2

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

Ответить
16 комментариев
0

Просто платина и добавить нечего

Ответить
0

Вот тебя я бы нанял.

Ответить
0

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

Ответить
0

Тот самый случай, когда комментарий - лучше самой статьи.

Ответить
0

очень хороший ответ на статью

Ответить
–7

шакал заткнись

Ответить
77

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

Ответить
6

Я заметил, что это какая-то новая братия смузихлёбов. Они как правило из Твиттера, им до 25-30 лет, ведут свой вложик/подкаст. В целом их объединяет одно - именно они знают как правильно набирать народ, чморя HR'ов и компании. Только если они такие умные, то почему до сих пор выжигают глаза кодом?

Ответить
0

Так это тот самый Фил - номер 1 в рейтинге Хабра

Ответить
4

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

Ответить
3

Здесь вам не хабр

Ответить
1

по моему, там Milfgard номер 1 и он совсем не программист

Ответить
8 комментариев
1

Сколько не читал его провокационных высеров, кажется что он просто набивает воды для О1 визы

Ответить
73

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

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

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

Ответить
62

Баян баяныч, сюда постил пару месяцев назад, повторю сного. Просто может я уже старый и эти истории для меня уже не новы? Автор держись.

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

(С) Башорг 2013

Ответить
2

Классика не стареет :)

Ответить
1

// а сам по пьяни

как говорил один адвокат - "а если бы сел тогда, был бы жив"

в смысле "писал бы хорошо - не разбился бы на туареге" ))

Ответить
61

Заголовок надо поменять, на «не нанимайте долбоебов», тогда он будет соответствовать тексту. А так не клеится

Ответить
53

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

Ответить
–6

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

Ответить
48

Да уж писать 3 недели тесты в стартапе это реально похоже на саботаж. 

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

Ответить
35

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

Ответить
2

...и таких как ты, условно 90%. еще 5% таких как автор. и еще 5% таких, кто может и так и так, по необходимости и по ситуации

Ответить
7

И последние 5% окажутся самыми крутыми.

Ответить
2

А потом заходит другой разработчик на проект и в комментариях на vc: «индустрии пиздец, 99% проектов сделаны плохо, блаблабла» 😄

Ответить
1

И быстренько ушел?

Ответить
1

Почему же, сапорт и новые фичи тоже делаю

Ответить
26

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

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

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

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

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

Это говорит шарпист, который кроме своего шарпа ничо не знает и на полном серьезе думает что надо код на 100% тестами покрывать? Не туда воюете, то есть развиваете 

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

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

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

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

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

Ответить
20

Пробелы вместо табов - с ходу досвидание. 😁

Ответить
1

Нажимаю таб, ставится пробел. Потому что пофигу, что ставится

Ответить
13

Это же прикол из сериала.

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

Ответить
1 комментарий
21

1. Занимался хуйней 4 месяца в стартапе
2. Решил свалить, пока все не развалилось
3. Сказал, что это потому что ты слишком крутой программист
4. ????
5. PROFIT

Ответить
14

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

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

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

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

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

Ответить
23

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

Оттого-то Фил и работает исключительно в крупных аутсорсах: пустив пыль в глаза менеджерам и заказчикам, он может месяцами заниматься имитацией бурной деятельности, пока его не раскусят. Благо, паттерны проектирования и функциональные абстракции дают возможность практически неограниченного роста объёмов ничего не делающего кода. Это никакое не «развитие индустрии», а его регресс. Прямо как демагогия из небезызвестного «ответа Путина на вопрос сколько будет 2+2»: слов много, а ответа нет. Такое же политиканство и «руковождение», только от IT-индустрии.

Ответить
3

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

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

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

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

Ответить
2 комментария
11

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

Ответить
17

Значит вы, как и Фил, делаете именно НЕПРАВИЛЬНО.
Суть программиста и инженера - выдать конечное решение, соответствующее требованиям( сроки, бюджет, приемлемая работа на конкретных устройствах или их типах ), а то, как конкретно оно выглядит "под капотом" и сколько по этому поводу можно сделать ссылочек на умные книжки и статейки( притом, "умные" они не объективно, а по мнению энного неизвестного круга лиц ) сторонним людям глубоко наплевать.
И если человек называет себя крутым программистом, но не может исполнить проект в сроки и бюджет, т.е исполнить его ПРАВИЛЬНО - он не крутой и, даже, не хороший программист - он черти кто, незаслуженно получающий зарплату.

Не могу сказать, что сам нереально крутой разработчик, да и на всяких хабрах-хренабрах меня толком тоже нет..
НО я, тем не менее, почему-то хорошо понимаю, что если дело касается стартапа, то речь о конторе с ограниченным бюджетом и сроками и им нередко, для начала, надо выпустить первый релиз - типо MVP и уже потом его допиливать согласно реакции аудитории.
Для них КРИТИЧЕСКИ важны время и бюджет при, нередко, не самых конкретных требованиях итп. И быть тем, кто убивает экономику проекта только ради абстрактного "качества кода" итп - быть тем, кто именно проваливает даже вполне удачный проект и нифига не умеет применять инструментарий( т.к те же тесты итп не всегда и не везде одинаково важны - у каждого проекта свои приоритеты ).

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

Ответить
0

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

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

Ответить
2 комментария
0

'Для них КРИТИЧЕСКИ важны время и бюджет при, нередко, не самых конкретных требованиях итп'
До эпохи стартапов и венчурного капитала, было несколько не так: вот изобрели вы допустим новый тип патрона, запатентовали, лицензировали его для для производства и заработали на отчислениях, много заработали.
При этом процесс изобретения предполагал ПОЛНОЕ погружение в тему, т.е. центром знаний и уникальных компетенций являлся именно изобретатель, никому и в голову не приходило его понукать, ставить какие-то сроки и тд.
Люди жизнь тратили на опыты и исследования но приходили к владельцу капитала с чем-то готовым и уникальным, по крайней мере с уникальными характеристиками.

Тенденция в мире после эпидемии идет в каком-то смысле обратно к такому ( по моим наблюдениям ), "компании-верблюды" - новый термин, как раз про это: выживание без венчура, владение продуктом, упор на качество и тд.

'MVP на коленке за сжатые сроки' как-то уже не очень работает, увы. 

Ответить
2 комментария
5

И это прекрасно. Давно хотел ему ответить, но у меня уже 5ый акк на хабре в бане

Ответить
–5

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

Ответить
6 комментариев
0

У меня уже 20-й акк а VC в бане, и что? )

Ответить
1 комментарий
3

Фил с хабры ушел. Велкам.

Ставлю лайк не глядя

Ответить
0

Да не ушел же, просто и тут решил попробовать делиться видением

Ответить
5

Здесь аудитория подружелюбнее, правильно сделал))

Читал тебя на Хабре))

Ответить
5 комментариев
2

делаю правильно, а не то, что хотят

Скорее у вас, как и у Фила некорректное понимание что правильно, а что нет. От этого и все проблемы.

Ответить
16

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

Ответить
15

GoF мне кажется это худшее что случилось в индустрии. Много раз сталкивался с ситуацией когда разработчик получает задачу, решение которой довольно простое, но из-за количества абстракций, фабрик, 10 абстрактных классов, 12 интерфейсов, 5 уровней наследования сложность решения становится колоссальной и сам разработчик не может реализовать это все без багов, что требует дополнительных затрат на юнит-тестирование всего этого зоопарка абстракций, и вся эта куча, предназначенная казалось бы для решения задачи управления сложностью эту сложность и создает. 
Почему то для многих хорошая архитектура начинает измеряться количеством абстракций, но это не так. Изначальная задача по поддержанию сложности кода на приемлемом уровне не означает что вам нужно абстрагировать все, и найти в книжке паттерн, который можно натянуть на ваш юзкейс, потому что каждая абстракция имеет цену, в том числе цену поддержки, а задача крутого программиста минимизировать цену разработки и я говорю не о деньгах, хотя очевидно что это коррелирует с бизнес-затратами. И зачастую, особенно если речь идет о хай-левел задаче, ад-хок решение конкретного случая дешевле во всех отношениях чем придумывание генерализации для частного случая в том числе и с точки зрения поддержки. 
Есть шуточный пример на гите Hello World Enterprise Edition, который конечно утрирован, но не сильно далек от правды, когда работаешь с GoF адептами на проектах.
Я много лет проектирую фреймворки разной степени величины и с моей точки зрения хороший фреймворк это не тот, который решил все возможные дженерик задачи абстрактно, а наименее интрузивный, с наименьшей стоимостью абстракций, тот который можно выкинуть за день работы и прицепить другое решение и наличие всего этого зоопарка из GoF как правило усложняет, а не облегчает этот процесс. Самая дешевая и удобная абстракция это функция, и если есть возможность использовать функцию и это решает проблему не нужно городить ООП ад. Даже прежде чем создавать класс вместо функции стоит несколько раз подумать. Ну а если руки полезли создавать фабрику вместо вызова конструктора то нужно иметь очень веское обоснование для этого.

Ответить
0

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

Ответить
2

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

Ответить
9

Вот у нас в компании за 5 лет сменилось 4 программиста. И каждый вновь приходящий говорил, что "этим кодом можно выжигать глаза". Вот как так? Это мы постепенно увеличиваем скиллы программистов? Или же это традиция - прийти и повалять код предшественника? Почему-то второе видится логичней.

Ответить
17

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

Ответить
2

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

Опытный программист ведет себя как в старом анекдоте:
""""
Сидит программист глубоко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— Ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!
""""

Ответить
1

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

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

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

Ответить
1

ну скажет он добавочно, что ваши стандарты тоже гавно... ничего не изменится.

Ответить
7 комментариев
9

а не про домейн драйвен девелопмент

driven произносится "дривн"

Ответить
–3

Я разраб, могу как хочу коверкать профессионализмы

Ответить
33

Нет, ты просто плохо знаешь английский.

Ответить
3 комментария
1

Драйвен девелопмент

Ответить
11

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

Ответить
8

На самом деле для автора все еще печальнее. Говорю, как разраб из стартапа (-ов). К сожалению, часть ваших тестов и прочее просиживание штанов всего лишь побочный продукт того, что вас наняли 10 условных человек в тучные годы, а где вам взять работу потом, когда тасков нет - непонятно. Вот вы и переписываете 14 реакт на 16, 3 свифт на 4-ый, ищите Npm-ные либы какого-нибудь select menu банального и потом 3 часа возитесь с конфигами вебпака. Даже докер условный, можете 3-4 дня "конфигурировать", когда он якобы решает проблему деплоймента в пару кликов и поэтому его юзают.
Сами себе создаете проблемы и сами решаете их. Псих. защита просит называть это качественным кодом - но это не так.

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

Ответить
5

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

Ответить
1

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

Ответить
5 комментариев
–3

какой сборщик мусора в JS, когда ты из-за одной буквы в переменной из одного массива лепишь два, потом три, потом четыре и потом у юзера начинает ноутбук дымиться, ты что лепишь тут горбатого?
иммутабельность данных в функциональщине нужна чтобы бывшие дворники не наделали тупых ошибок, как-будто они не с бложиком работают, а с ядерным реактором. Там даже банальная логика не осилена, что если у тебя ошибка в абсолютно некритичных данных, то не надо юзеру создавать 100500 массивов и делать 10000005000000 переборов массивов. Зайдешь на какой-нибудь cian.ru, ба, и новый макбук начинает задыхаться, фронтендщики, епта.

Ответить
7

Перезапускал на днях один свой старый сайт на php - условно каталог музыки. Лень было смотреть в старый код. Написал с чистого листа 15 нужных функций, поместились в один файл, нет ни одного класса или теста. 3 таблицы в sql, 10 внешних html шаблонов, несколько шаблонов вшиты в сами функции. Сайт работает максимально быстро, как я ожидаю и задуманнный редизайн удался. Ошибки вероятны, но в 99% случаев ничего страшного не случится, ибо в 99% штатных случаев работает как надо. Написал этот сайт за несколько вечеров и запустил. Считаю это элегантным решением.

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

Другой правильный разработчик из иной религии ещё бы фреймворк или cms влупил. 

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

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

Ответить
8

Паша Дуров, ты?

Ответить
8

Нет, нет, нет! Только не снова этот выскочка с Хабра со своим говноподкастом, который считает себя Крутым Программистом с Огромной Зарплатой! Пожалуйста, только не здесь!

Ответить
–4

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

Ответить
1

С остальным ты согласен?

Ответить
8

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

Ответить
4

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

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

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

Ответить
5

Кровосток?

Ответить
0

Красное Дерево!

Ответить
4

Статья гарантированно напугает всех кто считает деньги,
поэтому думаю надо дать ряд пояснений для 'непричастных':

"Костыль"/быстрое решение/hotfix - с точки зрения последующих затрат это натурально множитель. Множество костылей и является тн. 'legacy code', по факту.
Каждая следущая добработка в проекте с костылями будет стоить не Х часов разработки а Х * коэффициент костылей.
Вот пример для иллюстрации:
Стоит задача реализовать загрузку файлов картинок через веб-форму,  для генерации и отдачи preview. Задача в такой постановке банальна, посему отдается фрилансеру и делается за день.
Дальше нужно "доработать" загрузку больших картинок, скажем от 1Гб. Все, вы попали на пару месяцев работ, т.к. нужно делать асинхронную загрузку, с прогрессом, с паузой и отменой, с обработкой разрыва связи. Саму генерацию preview нужно тоже докручивать, тк ничего стокового при таких размерах работать не будет.
Дальше нужно добавить "всего лишь" генерацию превью PDF/DOCX какого-нибудь - и вы попали еще раз и сильно, потому что там внутри есть страницы, те на выходе вашего замечательного решения нужен не один сгенеренный preview а несколько. А вы уже например привязали биллинг к количеству сгенеренных пользователем превью.

Т.е всего лишь пара небольших доработок (с точки зрения бизнеса) и проекту на уровне MVP - кабздец, ну либо увеличение бюджета раза в три.

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

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

Ответить
6

Идея хорошая, но в реальности будущее неопределенно.

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

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

Поэтому хороший разработчик не должен писать хороший код в вакууме.
Нужно задавать вопросы:
Зачем этот код нужен? Как он будет использоваться? Какая планируется нагрузка сейчас и через год? Какие планы у бизнеса? и т.п.
И исходя из ответов и собственного опыта (ведь бизнес сам часто не знает точно или обманывает сам себя) предлагать эффективное решение  (цена=время/качество)

_______________________

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

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

Ответить
3

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

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

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

Ответить
0

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

Отлично, а зачем такое решение абстрактному сервису в вакууме, если такая задача может быть никогда и не возникнет? Это как если бы клиент подбирал машину для доставки продуктов по городу, а вы ему вместо условного VW Caddy предлагаете сразу БелАЗ, потому что вдруг какой-то клиент через 10 лет закажет сразу 100 тонн картошки.

Ответить
0

Потому что не бывает абстрактных сервисов в вакууме?
Говорю же: порог чего-то что можно считать 'продуктом' на самом деле очень высок, и там очевидно не только затраты на разработку.
Поэтому на практике ситуации 'такая задача может быть никогда и не возникнет' мало реальны, тк границы продукта закладываются сразу, видны они тоже сразу, как минимум владельцам бизнеса/продукта.

Ответить
8 комментариев
0

Самый адекватный камент.

Ответить
0

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

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

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

Ответить
0

Нет не займет, это именно глобальная концептуальная переделка, тк изначальный вариант это обычный POST с multipart а конечный - что-то на базе https://tus.io/ , гляньте их примеры для оценки сложности.

Ответить
2 комментария
2

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

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

Ответить
12

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

Ответить
2

Но он решил переделать все старые операции заново

это было жестоко! )))

Ответить
0

Хорошие программисты не ссылаются на дядю Боба

Ответить
0

Почему?

Ответить
9 комментариев
6

Мы живем ради развития индустрии и разработки

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

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

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

Ответить
5

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

Ответить
3

+10.
Наверное, так везде, не только в разработке. Мыкаешься со своим качеством/перфекционизмом, как с крестом, и втайне завидуешь весёлым троечникам. 

Ответить
7

Это ложный перфекционизм, от непонимания правильного KPI.

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

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

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

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

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

А задач пользователя он теперь даже не помнит. Как можно забыть бизнес, в котором работал 4 месяца, 2 года назад? )) Вот такое вот понимание предметной области было у него.

Ответить
2

Лучше завидуйте весёлым отличникам.

Ответить
0

"Не знаю таких" (отличница)

Ответить
1

ну с качеством и перфекционизмом можно писать ПО для космических ракет. Там как раз такое нужно.

Ответить
1

Туда не взяли.
Потому что, скорее всего, нет ни качества, ни перфекционизма (вот неожиданность).

Ответить
0

Точно.
*хватит ли ракет на всех перфекционистов?

Ответить
1 комментарий
0

Только таких как Фил и беру. Больше никто не сделает продукт.

Ответить
12

Судя по статье, Фил бросил их, не сделал продукт.

Ответить
4

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

Ответить
–4

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

Ответить
4

Слабак!

Ответить
7

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

Ответить
1 комментарий
0

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

Ответить
4

Всё верно и точно.
 Я уже в США на себе прочувствовал эту разницу.

В крупняке (Microsoft, FB, Google) просят академических знаний, хитрых  и не стандартных подходов, оптимизации и олимпиадной математики в уме или на листе бумаги.

А в стартапах: "Вы же JS разработчик? Вот кароче дизайн, сделайте нам красивую и адаптивную морду, с кнопками, кальуляциями, анимациями и всякими чат ботами, но побыстрее, ибо у нас там уже заказы прут, а сайта и прилы всё нет".

Ответить
0

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

Ответить
1

Я про вхождение писал, а не рутину. В стартапах и рутина по веселей так то.

Ответить
4

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

Ответить
3

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

Ответить
–5

Вот красная рубаха, это не мера, это излишек. Или у тебя там кленовый лист на спине?

Ответить
–3

У него кленовый лист в голове.

Ответить
3

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

Ответить