Как стать автором
Обновить
16
0
Евгений Ромашкан @EvgeniiR

Software Engineer

Отправить сообщение
Под оригинальной статьёй с десяток заплюсованных комментариев о том что автору не нужен AWS API Gateway и этот самый гейтвей стоит конских денег.

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

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

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

Посыл хороший, плюсую)

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

На мой взгляд, проблема этой статьи в том, что автор слишком уж фокусируется на тезисе «принимайте простые решения», дополняя это некоторой частью воды, и после прочтения, особенно после того как автор называет названия паттернов «жаргоном», «хайпом», складывается впечатление что делать нужно исключительно решения понятные даже студенту(вспомним Дядю Боба про «every 5 years the number of programmers doubles»).
Думаю что очень верно подметил комментатор выше про
Потому что вы его уже знали. Это часть профессиональной деградации, когда тебе кажется, что все и так очевидно и просто, зачем об этом везде пишут.

И «простые» для разработчиков Uber решения находятся далеко за границами известного в каком-нибудь средне-маленьком проекте. (Как, например, event-driven-architecture которую Uber активно используют, или микросервисы — https://eng.uber.com/building-tincup/).
P.S.
В-третьих, мы практически никогда не ссылались на распространенные архитектурные паттерны и другой общепринятый жаргон, который используется в популярной литературе по архитектуре ПО вроде руководства Мартина Фаулера. Не было упоминаний микросервисов, serverless-архитектуры, границ приложений, событийно-ориентированной архитектуры (event-driven architecture) и всего остального. Некоторые из этих терминов всплывали во время сессий мозгового штурма; однако, у нас не было никакой необходимости ссылаться на них самих в проектной документации.

Вот тут явно что-то не то, ибо в Убере как раз во всю используется event-driven-architecture, существуют чёткие границы между командами и т.п. (их блог — https://eng.uber.com/ )
Может быть они в свою техническую документацию копируют описание паттерна без его названия, иначе я этот абзац никак объяснить не могу )
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать Тору проект по своему желанию и усмотрению.

Ну то есть вы считаете что можно на крупный проект посадить с десяток джунов клепать привычный и понятный им и большинству процедурный код и всё норм?

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

А по поводу пары-тройки избранных — есть методики распространения знаний в команде(Code Review, Pair programming). Уже пол века как есть.

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

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

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

Вот верно про проблему с определениями.
Что-то мне подсказывает что 99% этих случаев проблем производительности ИМ написанных фрилансерами это не "highload"(который моден нынче), а монстры лагающие при 100 юзерах потому что на каждый товар по 50 запросов в БД делается.
Мне очень интересно было бы посмотреть на сколько-либо серьезный и действительно высоконагруженный проект написанный фрилансерами (отмечу что речь в топике именно о фрилансе, а не удаленной работе в штате).

Я бы обобщил — делайте Value Objects иммутабельными, DateTime в том числе :)
Наследование — один из столпов ООП.

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

Для переиспользования кода нет никаких аргументов в пользу наследования, кроме того что из-за хайпа и моды на Java/C++ стиль «ООП» новички не интересуются альтернативами и упускают из вида объективные ценности и концепты при проектировании классов. Хотя бы те же Interface Segregation Principle(и, конечно, LSP), и стоящие за ними концепты coupling/cohesion и влияние всего этого на вероятность каскадных изменений и читаемость кода.
Да с тем, что качество кодовой базы влияет на трудоемкость анализа и качество оценок — никто же не спорит. Просто, вы, судя по всему, считаете эти факторы определяющими «скорость разработки новых фич». А это — далеко не так. Их влияние на эту «скорость» весьма опосредовано и ограничено.

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

Чем хуже текущая кодовая база, тем:
1 — больше времени нужно затратить в среднем на разбор одинакого объёма кода
2 — больше, причём в разы, объём кода который нужно разобрать

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

?! Это же вообще никак с *качеством* кодовой базы не связано.

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

Именно об этом тот же «Design Stamina Hypothesis» график от Фаулера
И даже если для себя принято такое правило, сторонний код не обязан ему подчиняться.

Инверсия управления — наше всё )
И «проблема» в том, что именно с качеством *кодовой базы* (наличием отсутствия технического долга, если хотите… хоть это и из области «не научной фантастики») это все связано (если вообще связано) весьма условно.

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

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

P.S. И да, читают код больше чем пишут.
Высокое внутреннее качество способствует более быстрому выпуску новых фич, потому что их проще, быстрее и дешевле делать.

И? Это чтоль что-то говорит о качестве *продукта*?! О качестве «внешнем»?! Ну можем «фичи» быстрее делать… наверное. Дальше-то что?

Я вам так скажу… качество кодовой базы *реально* важно только в одном единственном случае. Если вы *зарабатываете* именно на нем :-) Во всех остальных случаях, качество продукта — первично. А оно — скорее, к сожалению — от качества кодовой базы не зависит. По крайней мере, пока наличие этой зависимости нам выявить не удалось :-(

Я это вам как «менеджмент» говорю.

Ответьте, как «менеджмент», какой продукт сочтут более качественным пользователи — работающее стабильно и без багов приложение с регулярной поставкой новых фич в обещанные сроки, или приложение в котором релизы и новые фичи выходят с затяжкой в месяцы, а баги обкатываются на живых пользователях(которое, наверняка, ещё и стоить будет дороже)?
Что такое качество кода?

Влияние совокупности принятых и реализованных на какой-то момент времени решений, на объём трудозатрат требуемый для внедрения последующих фич в проект.

Его можно сравнить с написанием книг. Эта книга написана качественно, а эта некачественно (видимо, автор был пьян). Никакого качества кода нет.

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

2. «Качественный» код не обязательно даёт какие-то ускорения проекту в будущем.

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

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

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

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

А это уже говорит о проблемах менеджмента

3. Следование методологии TDD, «чистой архитектуре» ради архитектуры, абстракциям ради абстракций значительно замедлит проект.

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

4. Грамотное написание комментариев, разделение проекта по функциям упрощает чтение кода, ускоряет его развитие.

Статистики у вас конечно же нет?
Большое количество комментариев в коде уже говорит о проблемах.

Забавно, кстати, этот абзац — он ведь про то, чего по вашим же словам — «нет»

5. Хоть с архитектурой, хоть без вы можете написать ужасный код.

Хоть с архитектурой хоть без вы можете построить некачественно здание(речь вообще вроде шла о качественной архитектуре)

6. Архитектура ПО — это не строительство небоскрёба. Это строительство велосипеда, в котором наличие насоса, ремнабора влияет на то, доедете ли вы вообще. Всё на всё влияет, от установки шин до руля.

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

upd: Перечитал и понял что вообще не понял что вы хотели донести данным абзацем.

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

1. Общая логика != Общий код
2. В одном только языке PHP, каждый будний день, используя его пакетный менеджер, устанавливается 25-30 млн готовых пакетов чтобы переиспользовать их код packagist.org/statistics
3. Понятие «Чистый код» оно вообще не о переиспользовании, оно больше про сложность понимания кода и количество кода который нужно изменить для внедрения новых решений, а эти две вещи прямым образом влияют на скорость развития проекта.

8. «Он ответил так, как ответил бы любой опытный архитектор: «Мы принимали хорошие решения, но только сейчас понимаем, как нужно было делать правильно».
Вы серьёзно? А что такое „правильно“? Почему его „правильное“ решение не устареет через полгода и не станет неправильным?

Вся разработка сейчас об относительных понятиях лучше/хуже, и нет ничего страшного в том что решение выбранное пол года назад кажется уже не таким хорошим.
«There is no Silver Bullet»

9. Я видел один проект, где чистота архитектуры была выставлена на первый план. Это отнимало очень много моральных сил со всеми тестированиями, методологиями, абстракциями. Я не видел более медленного проекта. По моим оценкам, всё должно было делаться раза в три быстрее и без „архитектуры“.

Я видел один проект(на самом не один), где разработка новых фич была выставлена на первый план и разработчиками в том числе. Они не тратили время на тестирование, методологии, абстракции, они в лучшем случае не пушили с локалки в мастер и имели ручного тестировщика или пачку приёмочных/smoke тестов.
Каждый раз проводя ретроспективу своих действий в одиночку или с командой, я понимал что больше половины(процентов 70, а то и 90) затраченного мною или командой времени уходило на разбор текущей кодовой базы с целью понять как приспособить её к новым требованиям, а не на саму часть имплементации этих требований в коде, не говоря уже об отдельных задачах на рефакторинг существующей кодовой базы, так как без этого эффективность работы падала бы и дальше, вплоть до уровня полной неокупаемости внедрения новых фич и остановки развития проекта.
php задумывался как язык с нестрогими возможностями. Это как купить себе трактор, а потом в ходе модификации оказаться на феррари. Все вокруг говорят круто, но это уже не трактор который хотелось.


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

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

Лихо вы, однако, сначала высказываете предположение(«может банально не прожить»), а потом строите утверждение так, будто предположение доказано и уже превратилось превратилось в 100%-ную истину.

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

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

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

Если бюджеты у вас с Ребеккой одинаковые, то ей очень сложно развиваться дальше, тк она больше ресурсов тратит на вылизывание кода. То есть: у Вас и у Р. По 10 миллионов. Вы сделали бету и уже тестируете на пользователях, а Ребека за те же деньги только закончила архитектуру и бэкенд. Вам и Ребекке нужны ещё деньги, но вам — чтобы пилить дальше фишки, а Ребекке чтобы закончить то же приложение что у вас уже было. Рано или поздно, вы поглощаете Ребекку

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

Раз уж мы под статьёй Фаулера, процитирую его же книжку, абзац написанный в контексте старой басни Эзопа про черепаху и зайца:
Spoiler
Современные разработчики также участвуют в похожей гонке и проявляют
похожую самонадеянность. О нет, они не спят, нет. Многие современные
разработчики работают как проклятые. Но часть их мозга действительно
спит — та часть, которая знает, что хороший, чистый, хорошо проработанный
код играет немаловажную роль.
Эти разработчики верят в известную ложь: «Мы сможем навести порядок потом, нам бы только выйти на рынок!»
В результате порядок так и не наводится, потому что давление конкуренции на рынке никогда не
ослабевает. Выход на рынок означает, что теперь у вас на хвосте висят
конкуренты и вы должны стремиться оставаться впереди них и бежать
вперед изо всех сил.
Поэтому разработчики никогда не переключают режим работы. Они
не могут вернуться и навести порядок, потому что должны реализовать
следующую новую функцию, а потом еще одну, и еще, и еще. В результате
беспорядок нарастает, а продуктивность стремится к своему пределу около
нуля



А вообще, к чему это всё — есть такое понятие как анализ рисков, на основе чего можно принимать решения. Если его нет — в какую крайность не ударяйся, ни к чему хорошему это не приведёт.
>А вы готовы платить в 2-3 раза больше за чуть менее глючное ПО?

Фаулер пишет о том что грамотное проектирование как раз таки окупается со временем.
Так с чего пользователю придется платить больше?)
Ваша правда.
Думаю, в таком случае тут важнее тот момент что часто тесты не появляются и с развитием стартапа, по крайней мере те тесты, что пишут разработчики(unit)
Переписывать больще половины кодовой базы проекта из-за изменения требований это уже, извините, не изменение требований, а новый проект получается.
Ещё бы можно было «обновлять» выборку без больших расходов

А в чём проблема?

Если обновить данные в таблице(без объектов) то просто запрос через тот же SQL/DQL на обновление.

Если в цикле объекты обновлять — Query::iterate() и EntityManager::clear() чтобы IM/UoW почистить — manual

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность