Comments 84
Статья о том, как растут из миддлов в сеньоры.
> 2. Повторное использование кода
надмозг подсказывает, что «переиспользование бизнесовой функциональности». Но точно не «кода»
Уж лучше "Повторное использование бизнес-функционала"
Но вообще статья отличная
Я полез в исходник потому, что содержимое пункта мне мозг сломало. Потому, что в содержимом речь про банальную связность.
Часто написание «велосипеда» наоборот приводит к более простой системе, ее поддержке итп, чем попытка поженить несколько «стандартных»
Я все это к тому, что не стоит так яро навешивать табу на подобную практику. Как и с любым действием стоит оценить трудозатраты против выхлопа и ответить на вопрос «зачем писать свой велосипед». Если ответ есть — значит не стоит этого бояться, ведь может именно из вашего велосипеда вырастет новый популярный опенсорс проект.
И посчитать, сколько денег было потрачено зря.
Что, в принципе, и рождает подобные религиозные споры.
Можно лишь предположить, что, как и со стартапами, подобных велосипедов не доходит до опенсорса приблизительно 99,9 процентов. Но зато выстрелившие 0,1% дают достаточный профит для того, чтобы продолжать их строить. Спринг, кассандра, хадуп, бутстрап и тд и тп — были созданы теми самыми велосипедистами, решавшими конкретные задачи в конкретной конторе.
К тому же, нельзя считать, что если велосипед не дошел до опенсорса — то деньги зря потрачены. Люди решили конкретные проблемы в конкретных проектах, не спасая попутно весь мир. Что в общем тоже хороший результат.
Я прошу прощения, что размышляю со стороны бизнеса. Получается вы приветствуете инвестиции в мероприятие с риском потерять деньги в 99.9% случаев.
Это очень очень очень высокий уровень риска.
Но тем не менее, при прочих равных написание велосипеда означает, что придется потратить время(деньги) на то, чтобы пройти тот путь, который уже прошли десятки, а иногда сотни людей, участвовавших в разработке того или иного де-факто стандартного решения.
Прибавим к этому время, которое придется потратить на обучение нового программиста работе с велосипедом.
В общем, на мой взгляд, надо быть Гуглом или Яндексом, чтоб браться за серьезные велосипеды.
Я не думаю, что ребят начали строить там велосипед, потому что им хотелось его строить. Возможно на рынке не было подходящих решений, или они были слишком дороги/сложны.
Я к тому, что писать или не писать что-то свое ни в коей мере не связано с желанием. Оно связано с аргументацией технической и экономической необходимости. Если велосипед будет лучше, проще, дешевле чем что-то стандартное — то само собой не остается аргументов против такой разработки ни у бизнеса, ни у разработчиков ( ну кроме, разве что, психологического дискомфорта верующих в то, что они неспособны сами создать что-то лучше того, что есть на рынке ).
Однако, практика изобретения велосипедов – сплошь, и рядом и во многих случаях она не обоснована «экономическими параметрами». Наоборот, инженерам часто все равно на конечный результат (с точки зрения бизнеса), они просто хотят сами спроектировать какие-то технические вещи, потому что им просто интересно это делать, и их обоснования типа «у нас будет лучше» или «мы сделаем это быстрее/дешевле» не основываются на реалиях. Наоборот, у истоков таких начинаний часто оказываются люди, которые плохо разбираются в предметной теме, не знают как уже созданные «велосипеды» работают (и не хотят знать!), не могут оценить реальные требования, которые могут возникнуть в перспективе, и т. д.
Мне кажется, автор хотел подчеркнуть именно этот момент, а не «хорошо» или «плохо» изобретать что-то в принципе.
как бы заказчик не менял ТЗ, и как бы не пришлось менять бизнесс-логику — думать нужно всегда и пытаться писать идеальный код, можно писать тяп-ляп и это может работать, но написанный хорошо код будет легче саппортиться и он легче будет принимать капризы заказчика.
Жать на практике это доказать практически нереально. У меня часто возникают споры с другими синьерами -но нет времени проверить ту, либо другую архитектуру — заказчик никогда не заплатит за это, нужно просто что-то принять и работать дальше. Лишь спустя пол-года (зависит от частоты изменений и проекта) будет видно — правильное ли было принято решение. Так вот хороший программист отличается от посредственного тем, что он правильных решений принимает больше — его проект не скатывается в спагети через пол года, а остается более-менее читабельным, понятным.
Трудно понять что ты ошибся (или не ошибся) в момент анализа проблемы и реализации решения — на это нужен опыт (+, возможно, везение :))
Чтобы научиться принимать правильные решения, нужно принять много неправильных решений. В обзщем-то так и происходит обучение.
Ну не совсем, надо понять что принятое решение было неправильным. А это совсем нетривиальная задача, особенно если учесть, что даже спагетти-код может работать и приносить прибыль.
Мне кажется, что такое решение не всегда может быть взвешено принято на уровне команды. Просто слишком много неизвестных, а попробовать все нельзя. Надо общаться, обсуждать, посещать конференции, митапы. Тогда будет рождаться понимание того, что называют "Best practices" и согласно им уже действовать.
А я и не говорю, что это Серебряная пуля. Но очень часто решаемые задачи бывают схожи. Например, все магазины имеют авторизацию, добавление в корзину, оформление заказа. Изобретать тут какой-то свой огород и набивает те же шишки не имеет смысла никакого.
Отсюда растут несколько выводов:
1. Понять неправильность выбранного решения можно в различные моменты, но желательно сделать это вовремя и следовать только ему иначе попадаешь в ловушку метаний «или-или».
2. На ранних стадиях это влечёт за собой не полную «погруженность» в проблему, а следовательно не все нюансы такого подхода будут известны для будущих решений.
3. На поздних стадиях может не хватить времени на изменение уже сделанного и пойдёт так как есть (если оно работает), главное не вляпаться в сопровождение или расширение функционала ( =( sad but true но это лучший вариант учения на своих ошибках, хуже если ошибки не твои...).
В идеале ситуация решается двумя способами:
Хороший ментор стопорящий на ранней стадии и доходчиво объясняющий, почему в сложившейся ситуации так делать не следует.
Хороший опыт «до», способствующий решению текущих аналогичных задач.
Чтобы хорошо оценивать сроки, нужно постоянно тренироваться это делать. То есть перед началом каждой задачи или спринта, нужно потратить минимум времени на то, чтобы понять о чём задача и оценить сколько времени на неё потребуется. Очень важно записать свои оценки.
После выполнения задачи, нужно сравнить оценку с реальным временем выполнения и проанализировать с чем была связана неверная оценка. При подходе к следующей задаче учесть свои наблюдения.
При этом не нужно стремиться оценить задачу с точностью до минуты. Я предпочитаю оценивать задачи с гранулярностью в четыре часа.
Если регулярно так делать, то через месяц-два таких упражнений, можно научиться давать точные оценки сроков.
Думаю, стоит отметить, что я говорю о не долгосрочной перспективе — планирование на несколько недель.
Не нужно ничего прописывать — смысл в том, чтобы давать грубую оценку и постоянно сравнивать эту оценку с результатом. Через некоторое время появляется навык давать достаточно точные оценки без анализа мелочей.
Например код который не обрабатывает исключительные ситуации идеален? Или что ты выкинешь из когда который сам по себе не эффективно решает задачу, требует больше ресурсов чем нужно? Что бы ты выкинул из сортировки пузырьком?
Например код который не обрабатывает исключительные ситуации идеален?
Да. Посмотрите, например, лекции Гугла. Там так прямо и говорят — если падает, то пусть уже падает.
Или что ты выкинешь из когда который сам по себе не эффективно решает задачу
Неэффективность можно выбросить
Да. Посмотрите, например, лекции Гугла. Там так прямо и говорят — если падает, то пусть уже падает.
Посмотрите код гугла (Android, Chrome) сколько там обработок ошибок и исключений.
Это уже эзотерика какаято
Подозреваю что вы не понимаете о том что там говорят.
Сами то будете пользоваться например веб сервером который падает от любого некорректного запроса?
Точно такой же стандартный сценарий как и некорректный запрос. В случае если это некий сервер и ему не хватает памяти для очередного подключения можно просто вернуть ошибку подключения с соответствующей информацией, и не надо ни какие дампы анализировать, сразу всем будет понятно что произошло, а сервер спокойно продолжит работу.
А еще есть такая штука называется электронная почта, туда можно слать письма с возникшими эксепшенами.
Тут 2 варианта
1) забиваешь на эксепшены и тебе в 5 утра звонят с криками у нас нихрена не работает, все упало, сделай что нибудь мы кучу бабок просираем.
2) пилишь обработку эксепшенов, по ночам сервер ловит хайлоад и разгребает столько сколько позволяют ресурсы, пока ты смотришь эротические сны, а утром ты приходишь на работу, делаешь себе кофе, читаешь отчеты об ошибках, смотришь графики и со всем этим идешь к босу просить денег на новое железо.
it depends.
>>Что бы ты выкинул из сортировки пузырьком?
Ничего. Он идеален.
>>Или что ты выкинешь из когда который сам по себе не эффективно решает задачу, требует больше ресурсов чем нужно
Всё бы выкинул и переписал заново. Если мы говорим об идеальной ситуации, разумеется.
2) код сам по себе не решает задачу, её решает алгоритм в нём реализованный, код может быть идеальным, а алгоритм — нет.
Так код это и есть алгоритм записанный на определенном языке, что там может быть лишнего? неиспользуемая переменная? Чистить такие вещи задачи линтера, им только ленивый не пользуется. Получается мы живем в мире идеального кода)
А линтерам, которые сами чистят код, я бы точно не доверился.
Если в ТЗ чего то нету, а ты понимаешь что это нужно, надо написать манагерам и уточнить. Ни кто в серьезном проекте не забивает на отказоустойчивость софта.
>А линтерам, которые сами чистят код, я бы точно не доверился.
не тупи, они показывают ошибки и ты сам решаешь что с ними делать.
Не знаю, не пользуюсь линтерами, вполне хватает средств анализа кода в IDE. Если это примерно то же самое, то это просто автоматизированное детектирование явной грязи в коде.
Просто не надо их обрабатывать так что бы об этом ни кто не знал) в чем проблема? письмо на почту сложно отправить или в лог записать хотя бы?
>Если это примерно то же самое, то это просто автоматизированное детектирование явной грязи в коде.
Так и есть, а все остальное как ты сам сказал это алгоритм и к оценки идеальности кода не имеет отношения.
Не не всё остальное. Например именование переменных, декомпозиция на функции/методы, единственная ответственность — пока нет сильного ИИ, никакой линтер не скажет, что переменную лучше назвать amount, а не sum или count.
Кто его запишет если все упало? Да еще и с бектрейсом без которого эксепшен практически бесполезен.
>А процесс перезапустится, если указать что-то типа restart always
Я бы посмотрел на тебя если бы у тебя базы данных падали и запускались по restart always
Ну и что в этих кейсах ты выкидываешь?
Надеюсь такой пример убедит тебя что ты говоришь полную ерунду)
Очень часто слышу по своему опыту, главное всегда одно обоснование технологии: ну на Хабре же написали для чего это.
1. Не применяйте сложных решений, если нет необходимости.
2. Не применяйте методики только потому, что кто-то очень много о них говорит.
К слову, вот эти «профессионалы паттернов» даже не понимают, насколько смешно они выглядят, когда носятся с формулами а-ля «2х3=6». А если «3х2»? А если «4*y=?». Сначала идёт задача и её понимание, и только потом, МОЖЕТ БЫТЬ, после того как придумано решение, его можно «стандартно» решить шаблоном, да и то, если этот шаблон нужен.
А когда их нужно применять?
>Сначала идёт задача и её понимание, и только потом, МОЖЕТ БЫТЬ, после того как придумано решение, его можно «стандартно» решить шаблоном, да и то, если этот шаблон нужен.
Так сказал как будто паттерны проектирования что то плохое, это архитектурные решения проверенные временем, ну относительно проверенные. Они не могут быть нужны или не нужны, они или подходят для задачи или не подходят.
Когда в них есть явная необходимость. Ваш К.О. :) Беда в том, что Интернет — он как тупая сплетница, переносит из одних страниц в другие, перевирает, додумывает, после чего неокрепшие умом «сеньоры» лепят их где ни попадя.
> Так сказал как будто паттерны проектирования что то плохое
Именно. Представь себе, ты пришёл на урок математики, а тебе объясняют: «2 + 3 = 5» — запишите, дети, ЭТО ОЧЕНЬ ВАЖНО!
Смысл? Тебе дают квадратное уравнение, а у тебя в голове «2 + 3». Ну да, на очередной задаче сложения ты это применишь, но в программировании не осталось «простого сложения», над каждой задачей надо думать. И от того, что пара паттернов подошла в твоей задаче, это вовсе не повод кричать о них на каждом углу. Да и самих шаблонов (стоящих, чтобы помнить) — раз-два и обчёлся. Фактически, это ты как программист должен такие шаблоны выдавать на ура после минуты раздумий (т.е. идём по пути задача -> решение), а не бегать с десятком шаблонов «в какую бы задачу их воткнуть». Люди потеряли смысл паттернов — от того и городят то, что и написано в заголовке статьи — переусложнённое ПО.
Так паттерны это и есть квадратные уравнения, это шаблон, можешь взять его частично, можешь дополнить…
>это ты как программист должен такие шаблоны выдавать на ура после минуты раздумий
любую архитектуру надо проверять на опыте и делать выводы, паттерны это то что уже проверено и известны плюсы и минусы.
>т.е. идём по пути задача -> решение
все верно
>а не бегать с десятком шаблонов «в какую бы задачу их воткнуть».
так же как и не решать все задачи через квадратные уравнения, это проблема ограниченного кругозора а не паттернов, причем тут они вообще?
>Люди потеряли смысл паттернов — от того и городят то, что и написано в заголовке статьи — переусложнённое ПО.
не понимаю о чем ты и где ты нашел хоть что то сложное в паттернах, он как раз и помагают не усложнать, это простые удачные решения часто встречающихся задач.
Несколько вещей гарантированно будут увеличиваться со временем: ***,
энтропия вселенной
Объясните, пожалуйста эту мысль.
10 ошибок, приводящих к оверинжинирингу ПО