Pull to refresh

Comments 84

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

Статья о том, как растут из миддлов в сеньоры.
> сеньоры
обычно пишут абстракции над абстракциями =)
мидлы просто решают проблему в лоб, а потом выкидывают код и пишут новый, если потребуется внести правку.
Отличная статья, спасибо! Со многим сталкивался сам, многое видел у других.
> 2. Reusable Business Functionality
> 2. Повторное использование кода

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

Уж лучше "Повторное использование бизнес-функционала"

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

Но вообще статья отличная

Странное оправдание. Не надо переводить на 30% плохие статьи? Переводчик — не гуглтранслейт, должен отвечать за вышедшее из под него.

Я полез в исходник потому, что содержимое пункта мне мозг сломало. Потому, что в содержимом речь про банальную связность.
Я не сказал, что она на 30% плохая. Я сказал, что взял статью, перевёл (это заняло несколько часов), потом ещё раз посмотрел на оригинал — и он стал уже значительно изменён, на глаз где-то на треть. Но поскольку первоначальный вариант тоже был не плох — я решил публиковать его. Отслеживать во времени все текущие и будущие правки и вносить изменения в перевод — это уже какая-то сверхзадача, непонятно зачем это делать.
Это именно то, что я называю: «Архитектура ради архитектуры».
Имхо пункт про «велосипедостроение» автор втиснул не к месту. Ибо это понятие к оверинжинирингу ортогонально.
Часто написание «велосипеда» наоборот приводит к более простой системе, ее поддержке итп, чем попытка поженить несколько «стандартных» велосипедов фреймворков. Ведь «стандартные» велосипеды развиваются в своем направлении, часто не имеющем ничего общего с вашими задачами и вашей производственной необходимостью. Да и сами часто страдают от оверинжиниринга в попытке удовлетворить стопицот не нужных вам кейсов. Тут, по моему, хорошо подходят собственные аргументы автора про «повторное переиспользование кода» и «обобщим вообще все».

Я все это к тому, что не стоит так яро навешивать табу на подобную практику. Как и с любым действием стоит оценить трудозатраты против выхлопа и ответить на вопрос «зачем писать свой велосипед». Если ответ есть — значит не стоит этого бояться, ведь может именно из вашего велосипеда вырастет новый популярный опенсорс проект.
Жаль, что у нас нет статистики, сколько велосипедов было написано и сколько их взлетело до уровня популярного опенсорс проекта.
И посчитать, сколько денег было потрачено зря.
Такая статистика практически не собираема, ибо предполагает решение одной и той же задачи обоими способами и последующим сбором данных и анализом результатов на протяжении лет в объеме всей индустрии.
Что, в принципе, и рождает подобные религиозные споры.

Можно лишь предположить, что, как и со стартапами, подобных велосипедов не доходит до опенсорса приблизительно 99,9 процентов. Но зато выстрелившие 0,1% дают достаточный профит для того, чтобы продолжать их строить. Спринг, кассандра, хадуп, бутстрап и тд и тп — были созданы теми самыми велосипедистами, решавшими конкретные задачи в конкретной конторе.
К тому же, нельзя считать, что если велосипед не дошел до опенсорса — то деньги зря потрачены. Люди решили конкретные проблемы в конкретных проектах, не спасая попутно весь мир. Что в общем тоже хороший результат.
>Но зато выстрелившие 0,1% дают достаточный профит для того, чтобы продолжать их строить.

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

Это очень очень очень высокий уровень риска.
Нет. Написанный велосипед решает основные бизнес-задачи, грубо говоря, приносит нормальную прибыль. В 0.1% случаев он начинает приносить сверхприбыль, на которую в общем случае не рассчитывали.
Глупо было бы обобщать и говорить, что все велосипеды хороши или все велосипеды плохи.

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

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

В общем, на мой взгляд, надо быть Гуглом или Яндексом, чтоб браться за серьезные велосипеды.
Я возражал прежде всего против «потерять деньги». В худшем случае (случаи когда велосипед до конца не написан и выброшен не рассматриваем) это не потеря денег, а неэффективное вложение, приносящее доходов меньше, чем могло бы приносить вложение во что-то другое.
Ну тогда мы разошлись в том, что мы называем потерей денег.

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

Именно. У них был свой (а теперь можно утвержать что и — правильный) ответ на вопрос «зачем нам строить свой велосипед». Ведь те же самые задачи можно было решить попытавшись скомбинировать «стандартные» решения. Но получилось бы сложнее, глючнее, ненадежнее, медленнее, дороже (нужное подчеркнуть).
Я к тому, что писать или не писать что-то свое ни в коей мере не связано с желанием. Оно связано с аргументацией технической и экономической необходимости. Если велосипед будет лучше, проще, дешевле чем что-то стандартное — то само собой не остается аргументов против такой разработки ни у бизнеса, ни у разработчиков ( ну кроме, разве что, психологического дискомфорта верующих в то, что они неспособны сами создать что-то лучше того, что есть на рынке ).
Это идеализация – как «должно было бы быть» если бы все оценивали задачи и их возможные решения с точки зрения продукта, потенциальной прибыли, скорости, надежности, поддержки и т. д. И это здорово, если это так и работает где-то.

Однако, практика изобретения велосипедов – сплошь, и рядом и во многих случаях она не обоснована «экономическими параметрами». Наоборот, инженерам часто все равно на конечный результат (с точки зрения бизнеса), они просто хотят сами спроектировать какие-то технические вещи, потому что им просто интересно это делать, и их обоснования типа «у нас будет лучше» или «мы сделаем это быстрее/дешевле» не основываются на реалиях. Наоборот, у истоков таких начинаний часто оказываются люди, которые плохо разбираются в предметной теме, не знают как уже созданные «велосипеды» работают (и не хотят знать!), не могут оценить реальные требования, которые могут возникнуть в перспективе, и т. д.

Мне кажется, автор хотел подчеркнуть именно этот момент, а не «хорошо» или «плохо» изобретать что-то в принципе.
Поддержу. Бывает нужен клоунский цирковой одноколесник, а в наличии только универсальные вело-мотоциклы, из которых сначала нужно частично выкинуть а частично спрятать под ковер все лишнее, чтобы получить нужную функциональность.
UFO just landed and posted this here
Хорошая статья, только недавно прочитал её на Медиуме)
А как Вы его вообще читаете так, чтобы находить что-то интересное? Есть какие-то Best Practices?
Честно говоря, я сам там только пару дней назад зарегистрировался и почти случайно нашел эту статью по тегу php.
да, статья хорошая, но есть пару «но»
как бы заказчик не менял ТЗ, и как бы не пришлось менять бизнесс-логику — думать нужно всегда и пытаться писать идеальный код, можно писать тяп-ляп и это может работать, но написанный хорошо код будет легче саппортиться и он легче будет принимать капризы заказчика.

Жать на практике это доказать практически нереально. У меня часто возникают споры с другими синьерами -но нет времени проверить ту, либо другую архитектуру — заказчик никогда не заплатит за это, нужно просто что-то принять и работать дальше. Лишь спустя пол-года (зависит от частоты изменений и проекта) будет видно — правильное ли было принято решение. Так вот хороший программист отличается от посредственного тем, что он правильных решений принимает больше — его проект не скатывается в спагети через пол года, а остается более-менее читабельным, понятным.

Трудно понять что ты ошибся (или не ошибся) в момент анализа проблемы и реализации решения — на это нужен опыт (+, возможно, везение :))

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

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

Согласен, например у меня впринципе не возникает такких проблем, какие возникают у соседнего отдела, т.к. я принял другое решение на каком-то раннем этапе, хотя задачи похожие. И теперь та команда борется с ветрянными мельницами… а я могу лишь говорить «а я ведь говорил!» :) но формально тогда у меня небыло доказательств.

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

Нет серебряной пули. Best practices могут и усложнить жизнь конкретному проекту.

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

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

Отсюда растут несколько выводов:
1. Понять неправильность выбранного решения можно в различные моменты, но желательно сделать это вовремя и следовать только ему иначе попадаешь в ловушку метаний «или-или».
2. На ранних стадиях это влечёт за собой не полную «погруженность» в проблему, а следовательно не все нюансы такого подхода будут известны для будущих решений.
3. На поздних стадиях может не хватить времени на изменение уже сделанного и пойдёт так как есть (если оно работает), главное не вляпаться в сопровождение или расширение функционала ( =( sad but true но это лучший вариант учения на своих ошибках, хуже если ошибки не твои...).

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

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


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


При этом не нужно стремиться оценить задачу с точностью до минуты. Я предпочитаю оценивать задачи с гранулярностью в четыре часа.


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

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

Нет, такая методика приводит к тому, что посмотрев на задачу я могу довольно точно оценить, сколько времени на неё нужно, даже не вникая в детали.

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

Думаю, стоит отметить, что я говорю о не долгосрочной перспективе — планирование на несколько недель.

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

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

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

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

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

Да. Посмотрите, например, лекции Гугла. Там так прямо и говорят — если падает, то пусть уже падает.

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

Неэффективность можно выбросить
Да. Посмотрите, например, лекции Гугла. Там так прямо и говорят — если падает, то пусть уже падает.

Посмотрите код гугла (Android, Chrome) сколько там обработок ошибок и исключений.
Лекции Гугла это как мнение жителей Австрии этому поводу: у них не может быть общего мнения. На практике лекции Гугла представляют из себя мнение пары опытных программёров, но у них есть пара не менее опытных знакомых которые имеют противоположное мнение.
>Неэффективность можно выбросить
Это уже эзотерика какаято
>Да. Посмотрите, например, лекции Гугла. Там так прямо и говорят — если падает, то пусть уже падает.
Подозреваю что вы не понимаете о том что там говорят.
Сами то будете пользоваться например веб сервером который падает от любого некорректного запроса?
Некорректный запрос — это не исключение. Это стандартный сценарий, который должен стандартно обрабатываться. Исключение — это когда new не смог память выделить — тут нечего особо уже делать и да, веб-сервер должен упасть. Дальше можно анализировать креш-дамп.
>когда new не смог память выделить
Точно такой же стандартный сценарий как и некорректный запрос. В случае если это некий сервер и ему не хватает памяти для очередного подключения можно просто вернуть ошибку подключения с соответствующей информацией, и не надо ни какие дампы анализировать, сразу всем будет понятно что произошло, а сервер спокойно продолжит работу.
Совершенно не такой же. Запрос приходит извне, от юзера — и понятное дело, что он может быть какой-угодно. Обработка какого-угодно запроса — штатная ситуация. С другой стороны ситуация, когда new не может выделить память — это ошибка разработчиков или админов. И им нужно на неё отреагировать — пофиксить код, апгрейднуть сервер или сделать нормальное горизонтальное масштабирование. Эту ошибку нельзя просто проглотить и замолчать. Именно что должен быть креш, дамп, анализ и действие по исправлению.
>Эту ошибку нельзя просто проглотить и замолчать
А еще есть такая штука называется электронная почта, туда можно слать письма с возникшими эксепшенами.

Тут 2 варианта
1) забиваешь на эксепшены и тебе в 5 утра звонят с криками у нас нихрена не работает, все упало, сделай что нибудь мы кучу бабок просираем.
2) пилишь обработку эксепшенов, по ночам сервер ловит хайлоад и разгребает столько сколько позволяют ресурсы, пока ты смотришь эротические сны, а утром ты приходишь на работу, делаешь себе кофе, читаешь отчеты об ошибках, смотришь графики и со всем этим идешь к босу просить денег на новое железо.
А еще есть такая штука как логи и сервисы их мониторинга. А ещё есть сервисы контроля процессов.
>>Например код который не обрабатывает исключительные ситуации идеален?
it depends.

>>Что бы ты выкинул из сортировки пузырьком?
Ничего. Он идеален.

>>Или что ты выкинешь из когда который сам по себе не эффективно решает задачу, требует больше ресурсов чем нужно
Всё бы выкинул и переписал заново. Если мы говорим об идеальной ситуации, разумеется.
1) если обработку исключительных ситуаций можно («may», а не «can») выкинуть, то код не идеален

2) код сам по себе не решает задачу, её решает алгоритм в нём реализованный, код может быть идеальным, а алгоритм — нет.
>2) код сам по себе не решает задачу, её решает алгоритм в нём реализованный, код может быть идеальным, а алгоритм — нет.
Так код это и есть алгоритм записанный на определенном языке, что там может быть лишнего? неиспользуемая переменная? Чистить такие вещи задачи линтера, им только ленивый не пользуется. Получается мы живем в мире идеального кода)
Там могут быть ненужные по ТЗ обработки исключительных ситуаций, например :)

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

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

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

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

Не не всё остальное. Например именование переменных, декомпозиция на функции/методы, единственная ответственность — пока нет сильного ИИ, никакой линтер не скажет, что переменную лучше назвать amount, а не sum или count.
>В лог и так запишется необработанное исключение.
Кто его запишет если все упало? Да еще и с бектрейсом без которого эксепшен практически бесполезен.

>А процесс перезапустится, если указать что-то типа restart always
Я бы посмотрел на тебя если бы у тебя базы данных падали и запускались по restart always
Есть вообще хоть один плюс от того что процесс падает?
>Не не всё остальное. Например именование переменных, декомпозиция на функции/методы, единственная ответственность — пока нет сильного ИИ, никакой линтер не скажет, что переменную лучше назвать amount, а не sum или count.
Ну и что в этих кейсах ты выкидываешь?
Или вот смотри отличный пример придумал, играешь ты в КС или танки или еще во что нибудь, напряженная борьба, сидишь потеешь и тут сервер падает, всех нафиг выкидывает из игры, ок логинишься играешь дальше и через 15 мин сервер опять падает, и новость на сайте: «Вот так и так мы превысили критический онлайн так что сервера будут падать, но вы не переживайте у нас включен restart always так что через 2-3 мин после падения они снова будут подниматься, наш тех. дир. VolCh убедил нас что это самая правильная логика работы серверов, через недельку мы купим новое железо а пока терпите. „

Надеюсь такой пример убедит тебя что ты говоришь полную ерунду)
Не что имел в виду tdrive, но на сколько мне известно линтеры только анализируют и предупреждают, остальное делает программист. Кстати компилятор или линковщик таки могут выкинуть переменную или функцию если они не используются.
Краткое содержание статьи: «Делайте то, что нужно и не делайте того, что не нужно». Ой, и еще «правильно оценивайте сроки».
ну я бы скорее сказал «во всем важна Золотая Середина»
Я добавлю еще один синдром, он называется «Я это увидел на Хабре, надо внедрять».
Очень часто слышу по своему опыту, главное всегда одно обоснование технологии: ну на Хабре же написали для чего это.
Откровенно слабая статья. Резюмировать можно парой девизов, которые опытные и так знают, а начинающие просто не имеют опыта, чтобы это понять:
1. Не применяйте сложных решений, если нет необходимости.
2. Не применяйте методики только потому, что кто-то очень много о них говорит.

К слову, вот эти «профессионалы паттернов» даже не понимают, насколько смешно они выглядят, когда носятся с формулами а-ля «2х3=6». А если «3х2»? А если «4*y=?». Сначала идёт задача и её понимание, и только потом, МОЖЕТ БЫТЬ, после того как придумано решение, его можно «стандартно» решить шаблоном, да и то, если этот шаблон нужен.
>2. Не применяйте методики только потому, что кто-то очень много о них говорит.
А когда их нужно применять?

>Сначала идёт задача и её понимание, и только потом, МОЖЕТ БЫТЬ, после того как придумано решение, его можно «стандартно» решить шаблоном, да и то, если этот шаблон нужен.
Так сказал как будто паттерны проектирования что то плохое, это архитектурные решения проверенные временем, ну относительно проверенные. Они не могут быть нужны или не нужны, они или подходят для задачи или не подходят.
> А когда их нужно применять?

Когда в них есть явная необходимость. Ваш К.О. :) Беда в том, что Интернет — он как тупая сплетница, переносит из одних страниц в другие, перевирает, додумывает, после чего неокрепшие умом «сеньоры» лепят их где ни попадя.

> Так сказал как будто паттерны проектирования что то плохое

Именно. Представь себе, ты пришёл на урок математики, а тебе объясняют: «2 + 3 = 5» — запишите, дети, ЭТО ОЧЕНЬ ВАЖНО!
Смысл? Тебе дают квадратное уравнение, а у тебя в голове «2 + 3». Ну да, на очередной задаче сложения ты это применишь, но в программировании не осталось «простого сложения», над каждой задачей надо думать. И от того, что пара паттернов подошла в твоей задаче, это вовсе не повод кричать о них на каждом углу. Да и самих шаблонов (стоящих, чтобы помнить) — раз-два и обчёлся. Фактически, это ты как программист должен такие шаблоны выдавать на ура после минуты раздумий (т.е. идём по пути задача -> решение), а не бегать с десятком шаблонов «в какую бы задачу их воткнуть». Люди потеряли смысл паттернов — от того и городят то, что и написано в заголовке статьи — переусложнённое ПО.
>Тебе дают квадратное уравнение, а у тебя в голове «2 + 3»
Так паттерны это и есть квадратные уравнения, это шаблон, можешь взять его частично, можешь дополнить…
>это ты как программист должен такие шаблоны выдавать на ура после минуты раздумий
любую архитектуру надо проверять на опыте и делать выводы, паттерны это то что уже проверено и известны плюсы и минусы.
>т.е. идём по пути задача -> решение
все верно
>а не бегать с десятком шаблонов «в какую бы задачу их воткнуть».
так же как и не решать все задачи через квадратные уравнения, это проблема ограниченного кругозора а не паттернов, причем тут они вообще?
>Люди потеряли смысл паттернов — от того и городят то, что и написано в заголовке статьи — переусложнённое ПО.
не понимаю о чем ты и где ты нашел хоть что то сложное в паттернах, он как раз и помагают не усложнать, это простые удачные решения часто встречающихся задач.
Давай рассмотрим реальную ситуацию, вот стоит у тебя задача построить некую систему реального времени, например систему мониторинга, ты можешь неделю думать как и что тебе сделать, попробовать что нибудь написать, потом еще неделю на осознание того что твое решение нифига не подходит по требованиям да же в теории… или можешь вспомнить про лямбда и каппа архитектуры и у тебя в голове готовая схема ключевых элементов системы, надо только конкретные детали додумать. Или ты можешь сейчас на ура выдать пару альтернатив лямбда и каппа архитектурам, после минуты раздумий, которые лучше подойдут под эту конкретную задачу? Очень интересно было бы послушать.
На прошедшем pgday вот этот чел http://pgday.ru/ru/2016/speakers/28 рассказывал что у них все построено на микросервисах, один микросервис переписывается командой с 0 за неделю и при таком раскладе совершенно пофиг на чем он написан, хоть на хаскеле, зато разработчики ни чем не ограничены в выборе технологий и могут спокойно набираться опыта и расти в профессиональном плане.
Несколько вещей гарантированно будут увеличиваться со временем: ***,
энтропия вселенной

Объясните, пожалуйста эту мысль.
Sign up to leave a comment.