Я вот все слова два раза прочитал, но так и не понял, подходит ли AOSP под ваши критерии большого и специфичного проекта.

да, большой. да, специфический. но говнокод же!

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

Ну вот скажут тебе «мув семантика» или там «атомики/фенсы», дальше что?

В гуглах-фейсбуках таких вопросов на очных не задают вообще.

Угу, зато спрашивают, почему люки круглые.

Лютый фейл - твоё ДНК.

а какой LVL у царя? %)

если вкратце, DELIRIUM в итоге без квартиры остался с таким подходом

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

Спасибо за ваш ответ.

Позвольте задать еще один небольшой вопрос.

Backend инфраструктура одного из 5и самых популярных онлайн ретаейлеров в США по объему заказов. Более 200 сервисов. Пиковые нагрузки во время распродаж (особенно черной пятницы).

При этом IT инфраструктура начала создаваться в начале 90-х для физических магазинов и складов (IBM «кластеры» и т.п.). Т.е. до сих пор еще достаточно компонентов, написанных в те «золотые» времена.

Это достаточно большой и специфичный проект?

Я не знаю кто из вас больший клоун, но в данном случае ты. Очевидно, что опыт является определяющим везде. Да, если ты моешь полы в области уровня «Backend инфраструктура», то ничего ненужно. Под надзором знающих людей ты сможешь кое как мыть полы.

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

Чет это напомнило...

https://images-cdn.9gag.com/photo/aAr8gMd_700b.jpg

Добрый день, дорогой друг.

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


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

Я был Teach Lead для Backend инфраструктуры. Отвечал за performance and stability одного из критических компонентов.

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

P.S.

Очевидно, что опыт является определяющим везде.

100% да. Опыт построения отказоустойчивых систем с максимальным перформансом, без него никуда. Вот только оказывается что принципы эти достаточно общие для разных типов информационных систем.

Везде есть своя специфика. Это правда. Но специфика не отменяет правил построения эффективных программных комплексов, а лишь вносит в них свои коррективы.

Конечно же, я строю свои рассуждения на основе моего опыта и опыта ограниченной группы людей, который не отражает опыт всего человечества.

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

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

Ты правда хочешь поговорить об опыте с царем? :D

Everyone are welcome!

Я был Teach Lead для Backend инфраструктуры. Отвечал за performance and stability одного из критических компонентов.

Пхп тюнил? Хотя нет, рассказывал как пхп тюнить.

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

Отказоустойчивость и «максимальным» никак не соотносятся с базвордом «Backend» и «Teach Lead».

Вот только оказывается что принципы эти достаточно общие для разных типов информационных систем.

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

Везде есть своя специфика. Это правда. Но специфика не отменяет правил построения эффективных программных комплексов, а лишь вносит в них свои коррективы.

Вот ты и спалился. Во-первых пхп и эффективность - это не синонимы. Во-вторых «построение комплексов» - это плебейская область уровня «тюнить пхп».

Конечно же, я строю свои рассуждения на основе моего опыта и опыта ограниченной группы людей, который не отражает опыт всего человечества.

Твой опыт, судя по твоих рассказал, это очередной плебейское говно на пхп и ты там выступал как гуру по тюнингу/выбору версии пхп. Очевидно, что это не задача разработки софта, а просто хайлевел дристня.

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

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

Везде, где не говорится о тюнинге пхп.

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

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

0. Пишет на C++

1. Не пишет на C++

Меня, признаться, удивило, с какой ненавистью вы относитесь к пхп.

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

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

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

Возобновить нашу дискуссию мы вполне можем с ваших комментариев по двум небольшим вопросам:

Подобные варианты уже покрыты вашим высказыванием о «разработке на уровне мытья полов»?

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

Меня, признаться, удивило, с какой ненавистью вы относитесь к пхп.

Неправильно, я называю пхп вообще всю скриптуху и конфигурацию.

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

Судя по той самой риторике - случилось. И какой же там был язык?

Возобновить нашу дискуссию мы вполне можем с ваших комментариев по двум небольшим вопросам:

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

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

По поводу твоих супер-рассказов. Я полистал твои темы. Типичный запартный эксперт. Судя по темам ты какой-то qt-поломой, но судя по риторике(да и по базвордам) ты явно никак не связан с какой-либо обсуждаемой тут «разработкой на крестах».

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

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

Я, честно говоря, уже начал стесняться.

Вы так много говорите обо мне и так старательно увиливаете от ответов на простые вопросы.

Неужели вы влюбились?

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

Вы так много говорите обо мне и так старательно увиливаете от ответов на простые вопросы.

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

Mexican Sugar Dancing? Что это? И я там ваще больше половины слов не знаю)

Давайте на этом закончим. Как обычно тема скатилась в сами знаете что.

Как будто с таким провокационным ОП могло быть иначе.

Дорогой друг,

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

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

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

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


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

Для облегчения вашей задачи я приведу неполный список базовых шагов для проектирования:
1. Декомпозиция задачи на подзадачи.
2. Поиск алгоритмов для решения каждой из подзадач.
3. Разделение системы на компоненты.
4. Выбор методов взаимодействия между компонентами.
5. Обеспечение непротиворечивости информации внутри системы (синхронизация, неполная связность, задержки в передаче данных).
6. Архитектура горизонтального масштабирования.
7. Архитектура вертикального масштабирования.
8. Архитектура поведения системы в случае сбоев отдельных компонент.
9. Архитектура логгирования и доставки логов разработчикам.
10. Архитектура мониторинга системы и мониторинга отдельных ее компонент.

Этот список, конечно, неполный и вы можете дополнить его самостоятельно.


P.S.

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

С моей стороны, это автоматически влечет за собой признание недоказуемым (или даже опровергнутым) вашего утверждения о том, что «опыт <в узкой области> является определяющим».

Если у человека нет врожденной любви к логике, к порядку, если даже после объяснений он дает переменным имена в духе var, val, data, key, array, right_panel, если он не умеет непосредственно выражать свои мысли в коде, то он на всю жизнь будет восприниматься коллегами джуном, несмотря на стаж и знания.

publiK speaking

Сэры разработчики

Если у человека нет врожденной любви к логике, к порядку, если даже после объяснений он дает переменным имена в духе var, val, data, key, array, right_panel, если он не умеет непосредственно выражать свои мысли в коде, то он на всю жизнь будет восприниматься коллегами джуном, несмотря на стаж и знания.

Ох, и насмешил! Вообще, рассуждения и представления о том, как правильно и неправильно писать код, довольно фрагментированы. Можно часто можно встретить прямо противоположные практики и рекомендации по применению. Скажем, в мире ООП принято называть переменные многосложно и избыточно, тогда как в мире ФП обычно ограничиваются однобуквенными или двухбуквенными сочетаниями в стиле x, xs, ys и т.п.

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

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

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

Дело не в длине имен, а в принципе «семантика vs презентация». И речь про функции длиннее пары строк, где все переменные в параметрах.

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

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

То есть, ты не понял. Правильно?

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

test

test

Отличная логика. Как ты выразился - так я и понял. Пиши яснее.

Скажем, в мире ООП принято называть переменные многосложно и избыточно, тогда как в мире ФП обычно ограничиваются однобуквенными или двухбуквенными сочетаниями в стиле x, xs, ys и т.п.

Может это в учебных примерах такие сокращения? Видел однобуквенные идентификаторы и на С++, и на Джаве, и никакой «мир ООП» (кстати, что это такое?) этому не помешал.

Однобуквенных идентификаторов также полно в коде на Фортране и Матлабе, но это вовсе не из-за наличия побочных эффектов (там всё один сплошной побочный эффект) или каких-то особенно понятных сигнатур , а потому что в формулах предметной области такие же обозначения соотв. математических объектов. Т.е. имена выбираются исходя из принятой в предметной области терминологии, а не потому что якобы какая-то парадигма программирования что-то там диктует.

Ты не туда тыкнул. Тебе сюда: Уровни C++ разработчика (комментарий)

Слишком сложно. А зачем все это?

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

Но это требования Макконнелла. Часто можно встретить хороших разработчиков для которых он не авторитет (да и вообще авторитеты - это обычно плохо).

LEVEL 10: Rust

Но это требования Макконнелла

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

Вот если не читал - не гадай, что у него есть.

Читал

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

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

Rust не нужен.

Читал

А что же тогда пишешь, что там ЕГО требования? Или читал не полностью?

На моей памяти никому, кроме джунов этот автор интересен не был.

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

Да че там знать, если там половина воды, а вторая половина очевидных вещей?

ЗЫ читал давно, будучи ещё миддлом.

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

У тебя в продакшене есть самописные сортировки?

Это зависит от того, кто собеседует.

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

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

а в сложных проектах задачу ставит сам программист

Эм. Это не в сложных проектах, а в говноконторах, которые экономят на product owner'ах.

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

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