Зачастую запутанный код - длинные файлы и функции с огромными уровнями вложенности и явными несоответствиями. А не вот это вот "как распарсить строку" написанное слишком заумно.
Ключевой момент - целенаправленно инвестировать в исследование этих сложных путей.
В разработке софта в целом, и Калифорнийском Биг Теке в частности, царит культура "выкатить побыстрее, пофиг как". Даже фундаментальные инвестиции разбазариваются на создание очередного стильного модного фреимворка, который медленнее предыдущих.
Кто не хочет учиться на чужих ошибках - учится на своих. Классика. Верификация покупок из АппСтора - не новая проблема. Не удивлюсь если разрабы говорили, что нужно через свой червак верифицировать, а им ПМы "довайте выкатывать так, на вчера нужно было".
Зачастую есть класс Color, и из него достаются разные репрезентации. И создается класс из разных репрезентаций. И так везде. Можно сделать класс кластер под капотом. А можно прост хранить одну репрезенатцию и гонять туда-сюда.
Падажжите. Где опровержение изначальной цитаты в статье?
Я мимокрокодил. Но вот это "как заставить тупой компайлер сделать то, чего я хочу" сплошь и рядом при работе с "продвинутыми" компиляторами.
Стильное-модное-молодежное разбивается о реалии коммерческой разработки и зачастую годится только для прототипов.
Это я конечно утрирую. Но я был бы осторожен с теми, кто говорит "Долой С, перепишем все на Раст и заживем". Впрочем тех кто хочет все переписать на С я бы тоже обходил стороной. :)
L4->L5 промо в калифорнийских компаниях самое тяжелое. И им не важно сколько и какой был опыт раньше. Прийдя на Л4 в компанию будешь считаться на уровне джунов с 3 годами опыта работы. И должен будешь еще 4 года отсидеть, что б подали на промо.
В общем советую просить доп. интервью, что б на Л5 забраться таки. Иначе может быть большая обида.
Кросс-платформенная компиляция довольно широко распространена. Сторонних зависимостей вроде не наблюдается, что сильно упрощает компиляцию. Если у этого файла мало точек входа, то вообще отлично.
Производительность - нужно профайлить. Судя по обсуждению все затыкается в производительность интерпитатора, которому становится сильно сложнее использовать обьектные конструкции. С++ все же намного лучше справляется с этим ввиду отсутствия шага интерпритации. Но возможно я совсем не правильно понимаю, что там творится.
Но переписывтаь это все на С++ конечно сложно. Нужен автоматический транслятор что-ли.
Пока по судам, конгрессам, европарламенту, и т.д. Гугл не потаскают - им вполне плевать на полицию в мелких вопросах. Закон об удалении данных (ГДПР) есть, а закона об обязательном предоставлении сервиса, заботе о сохранности данных нет пока что. Потому можно удалить аккаунт и забить.
Канада и Калифорния очень разные. В одном ЛА бомжей наверное больше чем во всей Канаде. В Торонто бомжей визуально в несколько раз меньше чем в СФ или ЛА. Типа в Торонто стоит в в сквере одна палатка, в ЛА 3. В Торонто под одним мостом живет стая веловоров, в ЛА под каждым (а их тут много). В Торонто возле Salvation Army ошивается 3 бомжа, в ЛА 15.
Социальное жилье по-разному выглядит. Я жил в районе в котором одна из высоток была социальной. Если б никто не сказал, я б и не знал. Может это заслуга того, что район относительно новый. Все здания до 15 лет возрастом.
А вот низкоэтажные социальные районы бросаются в глаза, что в Торонто, что в ЛА. Явно видна неухоженность.
Звучит вполне здраво. Хороший компромисс между убер-аджайлом, где все должны быть фуллстеком, и тотальным огораживанием, где никто не смотрит дальше своего носа.
Особенно правильная мысль о том, что с разработчика снимаются все продуктовые задачи. Зачастую дежурства не влючают это. Убирают часть задач, но ничего хорошего из этого не получается. Разработчик не может магическим образом тратить только 10% времени на он-колл. В итоге и продуктовые задачи буксуют, и он-колл ощущается как пустая трата времени.
Я говорю больше о продуктовых компаниях. Тут свой набор проблем. Можно статью писать. Навскидку:
Фичи планируются на несколько месяцев вперед. Первая фича ломает весь график, и остальные уже делают в режиме "на вчера". И так до бесконечности. Планирование то делают не инженеры. Их только ставят перед фактом дедлайнов.
Даже небольшое изменение кода требует больших ресурсов на анализ и тестирование. Потому что код пишется с учетом существующих проблем. И фикс проблем создает новые проблемы. Гейтинг не панацея.
Промо культура требует импакта. Вот прям так. Получается, что выгодно сделать фичу побыстрее, набрать тех. долга, а другие разберутся. Плюс важно уметь продавать свои заслуги. Можно делать полнейшую фигню и получать повышения. А можно делать важные вещи, но не презентуя их правильно, получать отказы. Очень выгодно заделиверить фичу, набрать тех. долга, а остальные потом разберутся. И каждый разработчик думает "а чем я хуже", и круг продолжается.
Я тоже раньше читал статьи про ужасную культуру разработки в Гугле и прочих, и думал, что это все фигня, и зависит от команды. Попав в Калифорнийскую компанию, я понял, что, к сожалению, все реально так плохо.
Уверен, что никто из кодеров не представляет, почему это происходит, а код в его основе — это просто куча раздутого скопипащенного навоза.
Скорее всего кто-то представляет.
Проблема не в том, что код хреновый. Проблема в том, что на фиксы таких мелочей не выделяется время. Нужно деливерить фичи. Закончили одну фичу, тут же начинается следующая, потому что она была распланирована еще на позапрошлый месяц. Все некритичные проблемы, промахи и т.д. отправляется в категорию тех. долга. Если проблема становится критичной она фиксится. Иначе она существует годами до смерти фичи.
Это типичная история любой крупной компании, любого долгоиграющего проекта.
Это происходит не только потому, что кодеры не пишут низкоуровневого эффективного кода для достижения своей цели: они просто никогда не видели низкоуровневого эффективного, хорошо написанного кода.
Проблема более комплексная. ИМХО она вообще в другой плоскости. Я бы сформулировал так:
Подавляющее большинство программистов пишет тупой процедурный код. Говорят ООП, а на самом деле гоняют тупые ДТО между функциями. В таком коде сложно выделить абстракции, определить границы. Все связано со всем.
При увеличении требований и сложности продукта это приводит к экспоненциальному росту количества кода. Получается порочный круг. Код сложный для понимания - он обрастает костылями. Костыльный код становится сложнее понимать.
В такой системе низкоуровневый код невозможно поддерживать. Потому что он не отделен строгой границей. Его начинают копировать, подгонять под требования. И получаем проблему о которой говорил автор.
Зачастую запутанный код - длинные файлы и функции с огромными уровнями вложенности и явными несоответствиями. А не вот это вот "как распарсить строку" написанное слишком заумно.
Ключевой момент - целенаправленно инвестировать в исследование этих сложных путей.
В разработке софта в целом, и Калифорнийском Биг Теке в частности, царит культура "выкатить побыстрее, пофиг как". Даже фундаментальные инвестиции разбазариваются на создание очередного стильного модного фреимворка, который медленнее предыдущих.
Кто не хочет учиться на чужих ошибках - учится на своих. Классика.
Верификация покупок из АппСтора - не новая проблема.
Не удивлюсь если разрабы говорили, что нужно через свой червак верифицировать, а им ПМы "довайте выкатывать так, на вчера нужно было".
Зачастую есть класс Color, и из него достаются разные репрезентации. И создается класс из разных репрезентаций. И так везде. Можно сделать класс кластер под капотом. А можно прост хранить одну репрезенатцию и гонять туда-сюда.
Стоит заменить "не" на "не только". На каждом этапе оптимизировали, вот и получили результат.
Вампирчики не успели выехать в релиз, буквально, а уже понабежали подражатели, и наклепали своих Survivors версий.
Изменить дизаин и выкинуть стильные-модные-молодежные штуки. Все так.
Падажжите. Где опровержение изначальной цитаты в статье?
Я мимокрокодил. Но вот это "как заставить тупой компайлер сделать то, чего я хочу" сплошь и рядом при работе с "продвинутыми" компиляторами.
Стильное-модное-молодежное разбивается о реалии коммерческой разработки и зачастую годится только для прототипов.
Это я конечно утрирую. Но я был бы осторожен с теми, кто говорит "Долой С, перепишем все на Раст и заживем". Впрочем тех кто хочет все переписать на С я бы тоже обходил стороной. :)
L4->L5 промо в калифорнийских компаниях самое тяжелое. И им не важно сколько и какой был опыт раньше. Прийдя на Л4 в компанию будешь считаться на уровне джунов с 3 годами опыта работы. И должен будешь еще 4 года отсидеть, что б подали на промо.
В общем советую просить доп. интервью, что б на Л5 забраться таки. Иначе может быть большая обида.
Кросс-платформенная компиляция довольно широко распространена. Сторонних зависимостей вроде не наблюдается, что сильно упрощает компиляцию. Если у этого файла мало точек входа, то вообще отлично.
Производительность - нужно профайлить. Судя по обсуждению все затыкается в производительность интерпитатора, которому становится сильно сложнее использовать обьектные конструкции. С++ все же намного лучше справляется с этим ввиду отсутствия шага интерпритации. Но возможно я совсем не правильно понимаю, что там творится.
Но переписывтаь это все на С++ конечно сложно. Нужен автоматический транслятор что-ли.
Вопрос от человека незнкомого с ТС. А этот чекер мог бы быть написан на С++ каком-нибудь? Чего ж ради 15% не сделать?
Всю сеть битка, так всю сеть битка. Те, кто управляют санкицонным списком от этого не пострадают.
Пока по судам, конгрессам, европарламенту, и т.д. Гугл не потаскают - им вполне плевать на полицию в мелких вопросах. Закон об удалении данных (ГДПР) есть, а закона об обязательном предоставлении сервиса, заботе о сохранности данных нет пока что. Потому можно удалить аккаунт и забить.
Канада и Калифорния очень разные. В одном ЛА бомжей наверное больше чем во всей Канаде. В Торонто бомжей визуально в несколько раз меньше чем в СФ или ЛА. Типа в Торонто стоит в в сквере одна палатка, в ЛА 3. В Торонто под одним мостом живет стая веловоров, в ЛА под каждым (а их тут много). В Торонто возле Salvation Army ошивается 3 бомжа, в ЛА 15.
Социальное жилье по-разному выглядит. Я жил в районе в котором одна из высоток была социальной. Если б никто не сказал, я б и не знал. Может это заслуга того, что район относительно новый. Все здания до 15 лет возрастом.
А вот низкоэтажные социальные районы бросаются в глаза, что в Торонто, что в ЛА. Явно видна неухоженность.
Ну дык без правил этот инструмент ничего не сделает.
Вот автор в статье дает рекоммендации по правилам.
Как именно правила енфорсить - это уже за рамками изначальной статьи.
Варианты есть разные:
Гит хук
Статический анализатор в ИДЕ
Серверный линтер
ПР ревью для сложных правил
???
Многие правила очень даже подходят для других языков.
Ну и инструменты разработки не панацея. Никакой инструмент разработки не поможет, когда код выглядит как елка с функциями на 1к строк.
Звучит вполне здраво. Хороший компромисс между убер-аджайлом, где все должны быть фуллстеком, и тотальным огораживанием, где никто не смотрит дальше своего носа.
Особенно правильная мысль о том, что с разработчика снимаются все продуктовые задачи. Зачастую дежурства не влючают это. Убирают часть задач, но ничего хорошего из этого не получается. Разработчик не может магическим образом тратить только 10% времени на он-колл. В итоге и продуктовые задачи буксуют, и он-колл ощущается как пустая трата времени.
Пойду питчить идею менеджеру.
Извиниться и суициднуться это все таки не то же самое.
Я говорю больше о продуктовых компаниях. Тут свой набор проблем. Можно статью писать. Навскидку:
Фичи планируются на несколько месяцев вперед. Первая фича ломает весь график, и остальные уже делают в режиме "на вчера". И так до бесконечности. Планирование то делают не инженеры. Их только ставят перед фактом дедлайнов.
Даже небольшое изменение кода требует больших ресурсов на анализ и тестирование. Потому что код пишется с учетом существующих проблем. И фикс проблем создает новые проблемы. Гейтинг не панацея.
Промо культура требует импакта. Вот прям так. Получается, что выгодно сделать фичу побыстрее, набрать тех. долга, а другие разберутся. Плюс важно уметь продавать свои заслуги. Можно делать полнейшую фигню и получать повышения. А можно делать важные вещи, но не презентуя их правильно, получать отказы. Очень выгодно заделиверить фичу, набрать тех. долга, а остальные потом разберутся. И каждый разработчик думает "а чем я хуже", и круг продолжается.
Я тоже раньше читал статьи про ужасную культуру разработки в Гугле и прочих, и думал, что это все фигня, и зависит от команды. Попав в Калифорнийскую компанию, я понял, что, к сожалению, все реально так плохо.
Скорее всего кто-то представляет.
Проблема не в том, что код хреновый. Проблема в том, что на фиксы таких мелочей не выделяется время. Нужно деливерить фичи. Закончили одну фичу, тут же начинается следующая, потому что она была распланирована еще на позапрошлый месяц. Все некритичные проблемы, промахи и т.д. отправляется в категорию тех. долга. Если проблема становится критичной она фиксится. Иначе она существует годами до смерти фичи.
Это типичная история любой крупной компании, любого долгоиграющего проекта.
Проблема более комплексная. ИМХО она вообще в другой плоскости. Я бы сформулировал так:
Подавляющее большинство программистов пишет тупой процедурный код. Говорят ООП, а на самом деле гоняют тупые ДТО между функциями. В таком коде сложно выделить абстракции, определить границы. Все связано со всем.
При увеличении требований и сложности продукта это приводит к экспоненциальному росту количества кода. Получается порочный круг. Код сложный для понимания - он обрастает костылями. Костыльный код становится сложнее понимать.
В такой системе низкоуровневый код невозможно поддерживать. Потому что он не отделен строгой границей. Его начинают копировать, подгонять под требования. И получаем проблему о которой говорил автор.