Вопрос повторю — почему это странно? Может статья плохая, по формату не подходит или по количеству символов. А может тема щекотливая. Если тема, то подскажите, отчего вам кажется, что эти издания сообща действуют по указке откуда-то. Должна же ваша вера на чем-то быть основана. Вот мне и хочется основания увидеть.
Кажется есть проблема. Каждый день делаем два предсказания — цена пойдёт вверх, цена пойдёт вниз. Затем даём клиентам хеши сбывшихся предсказаний. Профит.
Математика нужна была во все времена, потому и дожила. До нашей эры было строительство и торговля. Попробуйте сориентировать в пространстве храм, или спланировать строительство пирамиды. Сколько вам нужно гребцов, сколько камня, как быстро все это движется и т.д. и т.п.
В средние века нужно было строить мельницы и прочие механизмы (коих было множество), проектировать замки, оружие и осадные орудия. Торговля, навигация в морях и т.п. В эпоху возрождения потребность в вычислениях еще более усилилась — появились банки и финансы.
Упомянутые паровые машины на глазок построить можно, только ездить будут плохо и будут часть взрываться. Элементарная система из регулятора Уатта в сочетании с паровым двигателем может быть неустойчивой. Чтобы в этом разобраться нужно либо дифуры считать или ездить на паровозе до первого взрыва.
Ну и так далее, до современных алгебраических топологий и прочего.
Процедуры и библиотеки с повторно используемым кодом были ещё в ассемблере в 60е если не раньше. А о том, что удобно делать изолированные «кубики» и из них собирать механизмы люди додумались ещё в Древнем Египте, за 5000 лет до ООП.
ООП это про посылку сообщений, то есть о позднем связывании, о полиморфизме. Ещё о состоянии, то есть приёмник сообщения на один и тот же запрос может по разному отвечать.
Далее утверждается, что это удобно. Правда не уточняется кому и для чего это удобно. Вроде как все должно быть очевидно. Новация очевидна, простота на лицо, всем идеи нравятся. В итоге имеем то, что имеем.
Главное, чтобы студент мозги напрягал и тренировал в течение 5-6 лет, а этого как раз в универе нет.
Чтобы студент мозги напрягал его нужно а) мотивировать негативно — отчислением, армией, кредитом на образование и прочими карами б) мотивировать позитивно — дать заниматься вещами, связанными с выбранной специальностью в команде единомышленников.
Если не верить Голивуду, то похоже такое можно найти только в единичных вузах и это нигде не поставлено на поток, даже в США. А про этот тест я ниже отписался, мне кажется он американцами для американцев составлен и качество образования не имеет к нему отношения.
Образование у нас отстой, не спорю. Сдал тест — ответил на 10 из 16 вопросов. Сдавал ночью, с телефона, без бумажки и ручки. Вот такие ошибки
Вопрос 2 — не понял, что надо считать сложность конкретно по этому дереву, ответил 3 так как log2(8) = 3. Это сказывается отсутствие опыта сдачи подобных тестов.
Вопрос 4 — Читал про two way set associative cache абзац в английской вики, ничего не понял, ответил наобум, не угадал. Это комбинация языка и плохой статьи в вики.
Вопрос 5 — не знал, есть шпаргалка по нотации в конце теста, интерпретировал выражения как posix style regexp, был неправ. Это опять отсутствие опыта работы с тестами.
Вопрос 11 — забыл добавить байты в конце структуры для выравнивания адреса следующей до 8 байт. Сказывается то, что последний раз структуры выравнивал 5 лет назад.
Вопрос 12 — до сих пор не знаю почему не прав.
Вопрос 15 — затупил, знал правильный ответ, но выбрал не тот пункт. Опять же, опыт с тестами.
Итого — если бы я чаще сдавал тесты и лучше владел языком, мой результат был бы 13 из 16. Если бы я больше занимался системным программированием, то было бы 16 из 16. Кажется тест сделан американцами под их программу, а мне надо почитать про процессоры и память.
А кто сказал, что ФП что-то ускоряет? Я видел как знание предметной области, задачи, железа, ОС, языка, алгоритмов и библиотеки ускоряет разработку. Ещё я видел как разработку замедляет отсутствие нормальных IDE, средств отладки, мониторинга и профилирования. Ещё очень сильно разработку замедляет увлечение всякими «концепциями» типа ООП, ФП при отсутствии знаний перечисленных выше.
Принцип четкий, спору нет, но есть проблемы. Первая — никаких границ применимости нет. То есть непонятно, нужно ли все 100% кода делать расширяемыми во все стороны или только часть. Если часть, то значит есть некие требования, данные свыше, о том, что это часть должна быть расширяемой. Но раз есть требования к расширяемости, из которых эта расширяемость вытекает явно, то зачем принцип?
Вторая — расширять предлагается только то, что авторы принципа знают как расширять, а не то, что расширять обычно нужно. Например, мне надо добавить новую функциональность — ускорить обработку запросов в 3 раза. Или синхронный код сделать асинхронным. Или однопоточный, многопоточным. Код менять мне точно нужно будет, значит был нарушен open-closed принцип.
Третья — противоречия с другими, не менее священными принципам. Очень общие сигнатуры вроде
на практике всегда противоречит LSP. Усложнение системы в угоду расширяемости противоречит KISS. Попытка спрятать все за абстракциями натыкается на принцип текущих абстракций Джоэла Спольски и т.д.
SRP и прочие принципы очень замечательные и правильные, но не имеют четкого определения и потому годиться только для красивых статей и флеймов. Можно сколько угодно уточнять определения или попытаться дать четкую формулировку языком математики. Вот тогда станет ясно, что все сложно, что у принципов нет ни определения ни границы применимости.
Про опционы это все сказки в текущих реалиях, даже первый наёмный сотрудник получает копейки в итоге, немногим выше того, что он заработал бы без опциона. Акции, как часть зп, популярны у топовых компаний вроде гугла и Амазона и их совсем нет у 99% остальных. В топовых компаниях, это реальные деньги, в остальных нет. Тем не менее разделять ценности компании принято и этой действительно важно для эффективной работы.
Есть важные ценности компании типа «уважать клиента», «сделать все возможное для решения проблемы», «работа с полной отдачей» и всякий бред типа «мы за социальную справедливость и мир во всем мире». Когда говорят о ценностях имеют в виду первое. Если вы не согласны с тем, что клиента нужно уважать и что работать нужно с полной отдачей, то вы просто плохой работник и все. Опционы, доли и акции никак к этому не относятся.
Все вы правильно думаете, но кажется направление не верное взяли. Нет такой архитектуры, про которую было бы известно, почему она работает и точные границы ее применимости. Так происходит не потому, что эта информация утаивается в целях маркетинга, просто никто этого не знает, включая автора архитектуры.
Из опыта известно, что одни разбиения системы на модули лучше чем другие, критерии можно выбрать любые — скорость, понятность, простота поддержки и т.п. Также известно, что хорошие разбиения найти сложнее чем плохие, для этого нам нужны люди с опытом, всякие архитекторы, тим лиды и т.п. Этот феномен объяснить можно так — хорошая архитектура (разбиение на модули) оптимизирует какие-ты параметры, доля таких разбиений в множестве всех возможных, видимо, не велика.
Как только происходит попытка поставить вопрос об архитектуре формально, математически строго, все споры заканчиваются. Становится ясно, что мы ничего об этом не знаем. Мы не знаем как описывать архитектуру, как сравнивать разные варианты, как гладко/непрерывно переходить от одного к другому и т.д. Где-то в ответах на эти вопросы зарыта «серебряная пуля» или строгое доказательство ее отсутствия.
Ниже я привожу вопросы, которые у меня возникают по вашему комментарию. Вопросы риторические, конечно-же.
пытаюсь решить проблему экспоненциального замедления скорости развития проекта
Кто сказал, что сложность растет экспоненциально? Если так, то что конкретно движет ростом сложности? Если понять закон роста сложности, то скажет ли это нам что-то об объекте, сложность которого растет? Возможно ли, что мы сможем это знание применить, чтобы рост сложности замедлить? Что такое сложность, может быть это вещественное число, вектор, оператор или может быть комплексное число или кватернион?
за счёт усиления изоляции между компонентами-микросервисами
Откуда известно, что усиление изоляции всегда ведет не к росту, а к уменьшению сложности? Можно ли вообще сложность сравнивать или она больше похожа на матрицу или граф для которого операцию сравнения однозначно определить нельзя? Как определить степень изоляции, опять же, это число, вектор или что-то еще? Только ли изоляция влияет на сложность или есть еще параметры? Может ли быть такое, что изоляция вносит лишь маржинальный вклад в общую сложность?
Я не понимаю, что вы пытаетесь сказать. Вы предлагаете делать распределенную систему (микросервисы) чтобы иметь возможность нанимать менее квалифицированных разработчиков под управлением очень квалифицированного архитектора?
По вашей логике судьбу специалиста определяет не он сам, а «адекватная контора» с «интересными задачами». Грустно это.
Просто кто-то учится всю жизнь, без перерывов, а кто-то просто фигачит не вдаваясь в подробности, лишь бы работало. За 10-15 лет разница между ними становится настолько огромной, что вторым первые кажутся уже даже не людьми, а магами, которые волшебным образом решают проблемы.
Когда неуёмный креатив команды загоняют в загончик — не важно, в виде сервиса, слоя, интерфейса, компонента или класса — это называется архитектура. И вот когда её нет — тогда команду точно ничего не спасёт.
Верно! А вот все остальное совершенно не верно. Навскидку
— Непонятно как замена MyModule.MethodA на HttpClient.Get(«mymodule/methoda») внезапно влияет на архитектуру?
— Непонятно, что мешает архитектору спроектировать интерфейсы между модулями также, как если бы он делал микросервисы и получить все преимущества микросервисной архитектуры без ее недостатков?
— Средний проект на 1 000 000 строк, микросервисов по 500 строк будет 2000. Почему бардак из 2000 модулей будет, а бардака из 2000 микросервисов не будет?
— Почему тестировать модуль «сложно», а тестировать микросервис просто?
— Почему микросервисы параллельно разрабатывать можно, а модули нельзя?
Если неуёмный и безжалостный креатив команды нужно останавливать и загонять его в загончик в виде сервиса и отгораживаться от него с помощью RPC или очередей, то у меня для вас плохая новость. Эту команду и проект ничего не спасёт и все быстро скатится к спагетти коду. С другой стороны, если креатив по делу, то совершенно не имеет значения микросервисы там или монолит. Сервисы сами появятся когда будут нужны.
Нужно понимать, что срок жизни отличного программиста на рынке труда это считанные месяцы за 10-20 лет. Есть у меня знакомый А, он может за 2-3 недели изучить распределённую систему (ядро биржи, ~100KLOC), в которой куча многопоточности, сложная логика и нет документации и начать решать любые задачи с отличной скоростью и качеством, не задавая даже вопросов авторам кода. Есть знакомый Б, который после года работы с этой же системой не может выйти за пределы одного, небольшого модуля. Резюме знакомого А никогда даже не было опубликовано, нашёл работу студентом, а после сам выбирал работодателя. Знакомый Б всегда открыт к предложениям и его легко найти и на hh и в LinkedIn. Аналогичная история у всех, без исключения, моих знакомых уровня А. Их просто нет на рынке труда и они там никогда не появятся.
Вопрос повторю — почему это странно? Может статья плохая, по формату не подходит или по количеству символов. А может тема щекотливая. Если тема, то подскажите, отчего вам кажется, что эти издания сообща действуют по указке откуда-то. Должна же ваша вера на чем-то быть основана. Вот мне и хочется основания увидеть.
А что в этом странного? Есть основания считать, что они подконтрольны кому-то, кто против Ассанжа?
Кажется есть проблема. Каждый день делаем два предсказания — цена пойдёт вверх, цена пойдёт вниз. Затем даём клиентам хеши сбывшихся предсказаний. Профит.
В средние века нужно было строить мельницы и прочие механизмы (коих было множество), проектировать замки, оружие и осадные орудия. Торговля, навигация в морях и т.п. В эпоху возрождения потребность в вычислениях еще более усилилась — появились банки и финансы.
Упомянутые паровые машины на глазок построить можно, только ездить будут плохо и будут часть взрываться. Элементарная система из регулятора Уатта в сочетании с паровым двигателем может быть неустойчивой. Чтобы в этом разобраться нужно либо дифуры считать или ездить на паровозе до первого взрыва.
Ну и так далее, до современных алгебраических топологий и прочего.
Процедуры и библиотеки с повторно используемым кодом были ещё в ассемблере в 60е если не раньше. А о том, что удобно делать изолированные «кубики» и из них собирать механизмы люди додумались ещё в Древнем Египте, за 5000 лет до ООП.
ООП это про посылку сообщений, то есть о позднем связывании, о полиморфизме. Ещё о состоянии, то есть приёмник сообщения на один и тот же запрос может по разному отвечать.
Далее утверждается, что это удобно. Правда не уточняется кому и для чего это удобно. Вроде как все должно быть очевидно. Новация очевидна, простота на лицо, всем идеи нравятся. В итоге имеем то, что имеем.
Аплодирую стоя, давно ждал! Когда релиз ждать?
Главное, чтобы студент мозги напрягал и тренировал в течение 5-6 лет, а этого как раз в универе нет.
Чтобы студент мозги напрягал его нужно а) мотивировать негативно — отчислением, армией, кредитом на образование и прочими карами б) мотивировать позитивно — дать заниматься вещами, связанными с выбранной специальностью в команде единомышленников.
Если не верить Голивуду, то похоже такое можно найти только в единичных вузах и это нигде не поставлено на поток, даже в США. А про этот тест я ниже отписался, мне кажется он американцами для американцев составлен и качество образования не имеет к нему отношения.
Образование у нас отстой, не спорю. Сдал тест — ответил на 10 из 16 вопросов. Сдавал ночью, с телефона, без бумажки и ручки. Вот такие ошибки
Вопрос 2 — не понял, что надо считать сложность конкретно по этому дереву, ответил 3 так как log2(8) = 3. Это сказывается отсутствие опыта сдачи подобных тестов.
Вопрос 4 — Читал про two way set associative cache абзац в английской вики, ничего не понял, ответил наобум, не угадал. Это комбинация языка и плохой статьи в вики.
Вопрос 5 — не знал, есть шпаргалка по нотации в конце теста, интерпретировал выражения как posix style regexp, был неправ. Это опять отсутствие опыта работы с тестами.
Вопрос 11 — забыл добавить байты в конце структуры для выравнивания адреса следующей до 8 байт. Сказывается то, что последний раз структуры выравнивал 5 лет назад.
Вопрос 12 — до сих пор не знаю почему не прав.
Вопрос 15 — затупил, знал правильный ответ, но выбрал не тот пункт. Опять же, опыт с тестами.
Итого — если бы я чаще сдавал тесты и лучше владел языком, мой результат был бы 13 из 16. Если бы я больше занимался системным программированием, то было бы 16 из 16. Кажется тест сделан американцами под их программу, а мне надо почитать про процессоры и память.
А кто сказал, что ФП что-то ускоряет? Я видел как знание предметной области, задачи, железа, ОС, языка, алгоритмов и библиотеки ускоряет разработку. Ещё я видел как разработку замедляет отсутствие нормальных IDE, средств отладки, мониторинга и профилирования. Ещё очень сильно разработку замедляет увлечение всякими «концепциями» типа ООП, ФП при отсутствии знаний перечисленных выше.
Вторая — расширять предлагается только то, что авторы принципа знают как расширять, а не то, что расширять обычно нужно. Например, мне надо добавить новую функциональность — ускорить обработку запросов в 3 раза. Или синхронный код сделать асинхронным. Или однопоточный, многопоточным. Код менять мне точно нужно будет, значит был нарушен open-closed принцип.
Третья — противоречия с другими, не менее священными принципам. Очень общие сигнатуры вроде на практике всегда противоречит LSP. Усложнение системы в угоду расширяемости противоречит KISS. Попытка спрятать все за абстракциями натыкается на принцип текущих абстракций Джоэла Спольски и т.д.
SRP и прочие принципы очень замечательные и правильные, но не имеют четкого определения и потому годиться только для красивых статей и флеймов. Можно сколько угодно уточнять определения или попытаться дать четкую формулировку языком математики. Вот тогда станет ясно, что все сложно, что у принципов нет ни определения ни границы применимости.
Про опционы это все сказки в текущих реалиях, даже первый наёмный сотрудник получает копейки в итоге, немногим выше того, что он заработал бы без опциона. Акции, как часть зп, популярны у топовых компаний вроде гугла и Амазона и их совсем нет у 99% остальных. В топовых компаниях, это реальные деньги, в остальных нет. Тем не менее разделять ценности компании принято и этой действительно важно для эффективной работы.
Есть важные ценности компании типа «уважать клиента», «сделать все возможное для решения проблемы», «работа с полной отдачей» и всякий бред типа «мы за социальную справедливость и мир во всем мире». Когда говорят о ценностях имеют в виду первое. Если вы не согласны с тем, что клиента нужно уважать и что работать нужно с полной отдачей, то вы просто плохой работник и все. Опционы, доли и акции никак к этому не относятся.
Из опыта известно, что одни разбиения системы на модули лучше чем другие, критерии можно выбрать любые — скорость, понятность, простота поддержки и т.п. Также известно, что хорошие разбиения найти сложнее чем плохие, для этого нам нужны люди с опытом, всякие архитекторы, тим лиды и т.п. Этот феномен объяснить можно так — хорошая архитектура (разбиение на модули) оптимизирует какие-ты параметры, доля таких разбиений в множестве всех возможных, видимо, не велика.
Как только происходит попытка поставить вопрос об архитектуре формально, математически строго, все споры заканчиваются. Становится ясно, что мы ничего об этом не знаем. Мы не знаем как описывать архитектуру, как сравнивать разные варианты, как гладко/непрерывно переходить от одного к другому и т.д. Где-то в ответах на эти вопросы зарыта «серебряная пуля» или строгое доказательство ее отсутствия.
Ниже я привожу вопросы, которые у меня возникают по вашему комментарию. Вопросы риторические, конечно-же.
Кто сказал, что сложность растет экспоненциально? Если так, то что конкретно движет ростом сложности? Если понять закон роста сложности, то скажет ли это нам что-то об объекте, сложность которого растет? Возможно ли, что мы сможем это знание применить, чтобы рост сложности замедлить? Что такое сложность, может быть это вещественное число, вектор, оператор или может быть комплексное число или кватернион?
Откуда известно, что усиление изоляции всегда ведет не к росту, а к уменьшению сложности? Можно ли вообще сложность сравнивать или она больше похожа на матрицу или граф для которого операцию сравнения однозначно определить нельзя? Как определить степень изоляции, опять же, это число, вектор или что-то еще? Только ли изоляция влияет на сложность или есть еще параметры? Может ли быть такое, что изоляция вносит лишь маржинальный вклад в общую сложность?
Просто кто-то учится всю жизнь, без перерывов, а кто-то просто фигачит не вдаваясь в подробности, лишь бы работало. За 10-15 лет разница между ними становится настолько огромной, что вторым первые кажутся уже даже не людьми, а магами, которые волшебным образом решают проблемы.
Верно! А вот все остальное совершенно не верно. Навскидку
— Непонятно как замена MyModule.MethodA на HttpClient.Get(«mymodule/methoda») внезапно влияет на архитектуру?
— Непонятно, что мешает архитектору спроектировать интерфейсы между модулями также, как если бы он делал микросервисы и получить все преимущества микросервисной архитектуры без ее недостатков?
— Средний проект на 1 000 000 строк, микросервисов по 500 строк будет 2000. Почему бардак из 2000 модулей будет, а бардака из 2000 микросервисов не будет?
— Почему тестировать модуль «сложно», а тестировать микросервис просто?
— Почему микросервисы параллельно разрабатывать можно, а модули нельзя?
Если неуёмный и безжалостный креатив команды нужно останавливать и загонять его в загончик в виде сервиса и отгораживаться от него с помощью RPC или очередей, то у меня для вас плохая новость. Эту команду и проект ничего не спасёт и все быстро скатится к спагетти коду. С другой стороны, если креатив по делу, то совершенно не имеет значения микросервисы там или монолит. Сервисы сами появятся когда будут нужны.
Так что 25 это не вершина, это самое начало профессионального пути.
Нужно понимать, что срок жизни отличного программиста на рынке труда это считанные месяцы за 10-20 лет. Есть у меня знакомый А, он может за 2-3 недели изучить распределённую систему (ядро биржи, ~100KLOC), в которой куча многопоточности, сложная логика и нет документации и начать решать любые задачи с отличной скоростью и качеством, не задавая даже вопросов авторам кода. Есть знакомый Б, который после года работы с этой же системой не может выйти за пределы одного, небольшого модуля. Резюме знакомого А никогда даже не было опубликовано, нашёл работу студентом, а после сам выбирал работодателя. Знакомый Б всегда открыт к предложениям и его легко найти и на hh и в LinkedIn. Аналогичная история у всех, без исключения, моих знакомых уровня А. Их просто нет на рынке труда и они там никогда не появятся.
Может кто-то наблюдает другую картину?