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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
Развернуть ветку
46 комментариев
Павел Костюнин

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

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

Ответить
Развернуть ветку
37 комментариев
Никифор Серяков

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

Ответить
Развернуть ветку
3 комментария
Павел

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

Ответить
Развернуть ветку
Johnny Vorony
Ответить
Развернуть ветку
vic buynoff

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

Ответить
Развернуть ветку
13 комментариев
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
2 комментария
Konstantin Balashov

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

Ответить
Развернуть ветку
Виталий Хахмович

Добрый день.

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

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

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

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

Ответить
Развернуть ветку
7 комментариев
Sergey Belikov

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

Ответить
Развернуть ветку
17 комментариев
William Nash

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

Ответить
Развернуть ветку
Никита Хисматов

а ты хорош

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Boris Yangel

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

Ответить
Развернуть ветку
Dmitriy Alekperov

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

Ответить
Развернуть ветку
Dmitry Ds

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

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

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

Ответить
Развернуть ветку
Ilya Slezkin

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

Ответить
Развернуть ветку
Nick Stepanov

Я думаю идеального кода не бывает. 
Писать тесты под все это не правильно. В целом согласен по большей части с вами

Ответить
Развернуть ветку
Reb Rending

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Юрий Б.

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

Ответить
Развернуть ветку
11 комментариев
Аккаунт удален

Комментарий недоступен

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

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

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

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

Ответить
Развернуть ветку
Юрий Б.

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

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

(С) Башорг 2013

Ответить
Развернуть ветку
Миша Магадан

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

Ответить
Развернуть ветку
Сергей Токарев

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

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

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

Ответить
Развернуть ветку
Reb Rending

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

Ответить
Развернуть ветку
Карфаген должен быть разрушен

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

Ответить
Развернуть ветку
vic buynoff

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

Ответить
Развернуть ветку
F. K.

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

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

Ответить
Развернуть ветку
Alexander Gretschann

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

Ответить
Развернуть ветку
Sergey Stepanchenko

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

Ответить
Развернуть ветку
1 комментарий
AEW

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Денис Перевозчиков

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

Ответить
Развернуть ветку
Айдар Бариев

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

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

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

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

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

Ответить
Развернуть ветку
Artem Petrenkov

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

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

Ответить
Развернуть ветку
3 комментария
Valera Rybakoff

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

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

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

Ответить
Развернуть ветку
2 комментария
Make Luv

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

Ответить
Развернуть ветку
Александр Савинов

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

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

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

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

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

Ответить
Развернуть ветку
9 комментариев
Pixel Lens
Фил с хабры ушел. Велкам.

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

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

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

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

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

Ответить
Развернуть ветку
Pavel Doronin
Ответить
Развернуть ветку
Alexey Kuznetsov

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

Ответить
Развернуть ветку
Boris Yangel

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

Ответить
Развернуть ветку
1 комментарий
Artem Gruzdev
а не про домейн драйвен девелопмент

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

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

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

Ответить
Развернуть ветку
4 комментария
John Preston
Драйвен девелопмент
Ответить
Развернуть ветку
Андрей Чуль

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

Ответить
Развернуть ветку
Сергей Ленский

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

Ответить
Развернуть ветку
Anton Z.

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

Ответить
Развернуть ветку
Ingvar K

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

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

Ответить
Развернуть ветку
Nikita Malyshev

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

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

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

Ответить
Развернуть ветку
8 комментариев
Pavel Guzhikov

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

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

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

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

Ответить
Развернуть ветку
one channel

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

Ответить
Развернуть ветку
7 комментариев
Sam Beckett

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

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

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

Ответить
Развернуть ветку
1 комментарий
miteigi nemoto

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Dmitry Semenikhin

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

Ответить
Развернуть ветку
Artemy Abubakirov

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

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

Ответить
Развернуть ветку
Карфаген должен быть разрушен

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

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

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

Ответить
Развернуть ветку
10 комментариев
Alex Chernyshev

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

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

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

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

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

Ответить
Развернуть ветку
Ingvar K

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

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

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

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

_______________________

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

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

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

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

Ответить
Развернуть ветку
9 комментариев
Make Luv

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

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

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

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

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

Ответить
Развернуть ветку
3 комментария
Roman Alex

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

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

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

Ответить
Развернуть ветку
Make Luv

Кровосток?

Ответить
Развернуть ветку
1 комментарий
Месье Никита
Мы живем ради развития индустрии и разработки

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

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

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

Ответить
Развернуть ветку
Ivan Vishnyakov

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

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

Слабак!

Ответить
Развернуть ветку
2 комментария
Evgen Seo

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

Ответить
Развернуть ветку
Чайка О.

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

Ответить
Развернуть ветку
Michael Smith

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Ingvar K

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

Ответить
Развернуть ветку
1 комментарий
Alexander Shibaev

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

Ответить
Развернуть ветку
3 комментария
Леонид Лютов

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

Ответить
Развернуть ветку
Evgen Seo

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

Ответить
Развернуть ветку
Eвгений С

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Ватник в Америке

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

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

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

Ответить
Развернуть ветку
Bucky Bucks

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

Ответить
Развернуть ветку
1 комментарий
Александр Карачёв

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

Ответить
Развернуть ветку
Alexandre Svergoun

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
1 комментарий
Миша Магадан

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

Ответить
Развернуть ветку
Bulat Ziganshin

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

Ответить
Развернуть ветку
Leha Shum

Круто что вы признали свои ошибки. К сожалению 99% на это не способны)
Пост шикарный

Ответить
Развернуть ветку
Oleg D

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

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

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

Ответить
Развернуть ветку
Anton Z.

я начинаю догадываться почему у вас 5 акков на хабре забанено

Ответить
Развернуть ветку
Ingvar K

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

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

"Когда я приступил к работе, я охренел. У них всё было сделано неправильно."

Ясно, понятно :)

п.с. Как крутой разработчик топящий за архитектуру и двигающий индустрию, ответьте за ваш нейминг "selectDevs", "devs", "Dev[]", "d" зачем буквы экономим? ;)

Ответить
Развернуть ветку
Карфаген должен быть разрушен

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

Ответить
Развернуть ветку
1 комментарий
Илья Мартынов

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

Ответить
Развернуть ветку
vic buynoff

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

Ответить
Развернуть ветку
danil nik

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

Ответить
Развернуть ветку
Карина Иванова
Можно месяцами рожать идеальную архитектуру

а потом понять, что 9 из 10 гипотез были неверными и этот функционал не нужен.

Ответить
Развернуть ветку
Alex Chernyshev

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

MVP это все же 'Valuable Product', пусть и 'Minimal', достаточно странно иметь отношение к продукту на уровне 'лишь бы работало'.
Ну и потом есть определенная недооценка масштаба: что-то похожее на продукт создается за год-полтора работы, это легко может быть 150-100к строчек кода, что уже нужно как-то сопровождать.
Это только потом, если продукт станет успешным можно будет вешать окружающим лапшу на уши: 'делали мы в подвале, на коленке, беременные тремя детьми и питаясь дошираками. Страдали и молились'. 

Ответить
Развернуть ветку
3 комментария
Bucky Bucks

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

Ответить
Развернуть ветку
Vitaly Karasik

Писать автор умеет, продажником или начальником скоро будет.
А по теме - "There are no best practices in software architecture. Only tradeoffs" (https://twitter.com/danielbryantuk/status/1232681086880276480)

Ответить
Развернуть ветку
Алексис Второй

Такой крутой и успешный, а свой github братишкам покушать не принёс.

Ответить
Развернуть ветку
Алексей Королев

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

Ответить
Развернуть ветку
Василий Петров

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

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

Ответить
Развернуть ветку
Владимир Воробьев

Ебать, вы тут наспорили. Добрее надо быть что ли. 

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

Всё правильно пишет, вопрос в другом. Почему у фаундеров не было нормального продакта/проджекта , тимлида или СТО  и они слушали человека с нулевым опытом в продуктовой разработке и выводе продукта на рынок, странно это.

Ответить
Развернуть ветку
Artem Petrenkov

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

Ответить
Развернуть ветку
3 комментария
Evgen Seo

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

Ответить
Развернуть ветку
Alexander Shibaev

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

Ответить
Развернуть ветку
Анастасия Drinkblood

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

Ответить
Развернуть ветку
Карфаген должен быть разрушен

О, фанбаза для придания авторитета подъехала.
Можете показать тонны красивого, оптимизированного кода?

Ответить
Развернуть ветку
1 комментарий
Eвгений С

Специально такой неидеальный код написал в картинке да?)

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

Ну он же решает свою задачу, так?

Ответить
Развернуть ветку
1 комментарий
vic buynoff

return false; жосткая ересь. Сжигать на кострах...

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

фабрика тщеславия поучаствую тоже чтоль.

Пишешь ядро.

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

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

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

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

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

пардоньте а вы кто? )
ну там яхта где-то припаркована или пара проектов есть?

по факту - пошла череда хайповых статей. Магазы за 100р или не за 100, программеры те или не те. 
Предлагаю сразу стартовать с https://www.youtube.com/watch?v=fGGzGTMr-FE

Ответить
Развернуть ветку
Alexey Sitka

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

Ответить
Развернуть ветку
Alexey Laptev

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

Ответить
Развернуть ветку
John Johnes

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

Мидл старается все усложнить ради усложнения, т.к. ему кажется, что сложно == (красиво && правильно). И постоянно пытается впихнуть везде паттерны / вот эти крутые архитектурные штуки, лишь потому что он их знает или недавно узнал, а не потому что они решают задачу.

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

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

Ответить
Развернуть ветку
Борис Моренко

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

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

Комментарий удален модератором

Развернуть ветку
Ingvar K

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

Ответить
Развернуть ветку
Сергей Некрасов

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

Ответить
Развернуть ветку
Alex Chernyshev

1. Тесты (внезапно) бывают разные.  Unit-тесты ( про которые тут все и пишут ) - да, под большим вопросом если сразу и на всю систему. 
А вот функциональное тестирование -  must have сразу, тк эмулирует поведение пользователя в системе.
Интеграционное тестирование - обязательно если у вас есть бинарные сборки и инсталляторы.
Smoke testing - обязателен после любого релиза. В случае самого простого стартапа это product/business owner, прокликивающий все ключевые кнопки в системе.

2. Проекты (внезапно) бывают разные, если вдруг вы переедете в долину и откроете компанию 'Пегий Дудочник' , в основе которой будет лежать библиотека с алгоритмом сжатия - вам (сюрприз) сразу с ходу будет нужно много unit-тестов, сложных чтобы не ловить регрессии.

Ответить
Развернуть ветку
Alexandre Svergoun

Заметил тоже самое. Даже хуже. У большей половины тех у кого было покрытие тестами - это было бесполезное покрытие. 
 

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

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

Ответить
Развернуть ветку
3 комментария
Сергей

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

а код на скрине, так пишут только джуны.
Почему не так? Можно было и другой пример показать
devs.filter(d=>d.type === 'startup')

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

Омг, щас бы ревью бутафорского кода для картинки делать

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

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Evgen Seo

к крутому программисту нужен крутой стартапер (с)

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

Ответить
Развернуть ветку
Alexandre Svergoun
крутой стартапер продумает целиком функционал системы

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

Ответить
Развернуть ветку
2 комментария
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Дмитрий Кудрявцев

Если говорить о стартапах, то там важно за максимально короткое время создать работающую бизнес-модель. Желательно продать продукт или услугу ещё до её реализацию. Иначе потраченные деньги, нервы и главное время будут впустую даже на технически правильном проекте. Кому он нужен? Именно поэтому важно сделать mvp или первые продажи подтвердить. И чем дешёвле, быстрее, тем лучше.

Ответить
Развернуть ветку
Радик Сен

Хорошо зашел :-) !

Ответить
Развернуть ветку
Гриша Булыжников

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

Ответить
Развернуть ветку
Serega Ignatov

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

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

А я думал так только маркетологи сраться могут :-О

Ответить
Развернуть ветку
Serge Ovchinnikov

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

Ответить
Развернуть ветку
Alexander Shibaev

Всё максимально просто. Качество со скоростью разработки имеют вполне себе четкую зависимость. По сути с увеличением качества скорость разработки падает по экспоненте. Стремление сделать идеально рушит скорость в 0. 95% идеальности вместо 99% может дать увеличение скорости в условные 2 раза. У автора очевидное стремление к 99 и непонимание происходящего вообще в принципе. Ровно поэтому писать полное говно также не стоит, ибо увеличение качества практически ничего не стоит, а бонусов даёт прилично. Поддержка идеального кода практически одинакова с поддержкой почти идеального кода или даже просто нормального, а времени на него будет потрачено в n раз больше. 

Ответить
Развернуть ветку
Denis Shilov

Буду краток. Кг/ам. Причём он сам это в тексте упомянул.
Не смог понять бизнес требований и слил пацанам проект.

Ответить
Развернуть ветку
Dmitriy Alekperov

СТО в стартапе? нуну

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Dmitry Kovalenko

Забавная статья. И камменты интересные.

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

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

Программисты бывают трёх типов: 1) любят обсуждать как писать код 2) любят писать код 3) любят решать проблемы. Кого из них нанимать, думаю, очевидно.

Ответить
Развернуть ветку
Artem Petrenkov
Люди, которые не понимают иронии в "Король разработки" или считают меня невероятно тупым, или сами невероятно тупые.
Ответить
Развернуть ветку
Oleg Makarov

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

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

Кто вас назвал хорошим программистом? Очевидно тот, кто в разработке не разбирается.

Ответить
Развернуть ветку
Vladislav Sorokin

бизнес = это погоня за выгодой, а не за красотой кода.

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

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

Ответить
Развернуть ветку
danil nik

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

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

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

Ответить
Развернуть ветку
Nick Stepanov

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

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

На самом деле важен не сам код, важны ресурсы которые есть у компании. Если компания способна ввделить ресурсы под качественный код, то нанимает 6-7 frontend разработчиков, например и ставит сроки проекта 1 год.
И тут есть время для проектирования, тестов и тд.
А если один разраб для mvp, 2-3 месяца то ни о тестах, ни о архиектуре речи не может быть... да и проект скорее всего загнется 

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

Комментарий удален модератором

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