Стоп, вот тут не очень понятно... Если код достаточно хорошо работает по производительности, и его не переписывают, то получается, что его сделали хорошим с первого раза, верно? Если исключить случаи ненагруженных и тормозящих приложений, то получается, что там всё сразу учли с алгоритмами, верно?
А зачем что-то оптимизировать для разовых действий? Никто не спорит, что в таком контексте знания необходимы лишь в том случае, когда объем данным становится слишком большим, чтобы тратить ресурсы просто так (и когда запускать несколько параллельных процессов приведет к переусложнению задачи).
Понятно. Мне очень сложно представить, когда всю систему (включая ядро, дизайн базы/сервисов и пр.) переписывают десятки раз на протяжении пяти лет хотя бы. Причем "переписывают" не включает в себя рефакторинг, выделение классов, переименование методов, добавление документации и прочие мелкие вещи.
В таких условиях, я думаю, действительно нет смысла вообще думать о качестве, о поддержке или о чем-то таком.
Далеко не факт. По моему опыту есть четкая корреляция между "решал много-много Computer Science задач в прошлом" и "быстро замечаю, что система уйдет в N^2". Просто иногда люди решают много задач за год, а иногда это растягивается лет на 10: университет, первые работы (и подготовки), поиск следующей работы и так далее.
Если говорить о математике (а комбинаторика из задачи "сколькими способами вы проползете лесенку, если за раз вы можете 1 или 2 ступеньки" мало имеет отношения к leetcode), то она уже реже требуется, разве что поможет получать более высокий оклад в финансовой компании.
А как работает отмывание денег на артобъектах, если:
KYC заставляет организаторов проверять всех клиентов с деньгами.
Транзакции большие и точно не могут идти от неизвестных людей и мутных локаций (иначе организаторы идут под статью)
Транзакции достаточно большие, чтобы их прятать.
Бухгалтерия известная налоговым (страны обмениваются данными), так что любое подозрение сразу запустит раскрутку цепочки.
Мы не рассматриваем вариант ухода от налогов в стиле "покупка артобъекта у себя втридорога, чтобы потом отдать его музею, а разницу в деньгах вычесть из налогов", ибо это не отмыв.
Это намного сложнее. Большинство произведений как раз являются улучшением предыдущих, когда другой автор (чаще всего с радикально другим опытом) понимает, что необходимо исправить в оригинальном издании.
Например, есть языки программирования (С/Java/C#), и, если так посмотреть, есть немало тех, которые являются их производными: C++/Rust/Kotlin. Более того, на самом деле та же Java взяла много из С, а C# - из Java и Delphi.
Представьте, насколько сложно было бы сделать Java в своё время, чтобы не быть похожим на C?
Собственно, авторское право потому и откатывает культуру назад за счет запрета на производное творчество. Если сделать сроки аналогичными авторскому праву, то и проблема резко уйдет.
Компания не обязана брать всех, кто соответствует каким-то критериям.
Не совсем. Рынок найма работает по другой схеме: на вакансию приходит N человек, из них берут M лучших, с точки зрения фирмы. Плохие условия уменьшают N, так что фирмам желательно держать N не слишком бо́льшим, чем M (чтобы был небольшой выбор, но и чтобы не переплачивать).
Другими словами - чем выше уровень человека (а это условная сумма hard и soft навыков), тем с большей долей вероятности человек будет попадать в M.
А потому, кризис больнее всего (и в первую очередь) бьет по людям с более низкими навыками в области (они будут постоянно попадать в N-M), а по остальным он бьет менее прямо, путем снижения N.
Ну можно взять последнию стоимость компании, когда она торговалась и ее прибыль тогда и сравнить с текущими оценками прибыли
Это очень опасно, так как в последнее время, особенно в АйТи компаниях, прибыль не всегда хорошо коррелирует с оценкой компании. Более того, если мы применяем какую-либо модель (ту де EBITDA), то необходимо договориться о её применимости в случае таких компаний, как X/Твиттер.
Относительно простая семантика языка и отсутствие лишних телодвижений. По сути программа может состоять из двух строчек. Проще только паскаль;
Но ведь реальные приложения не состоят из двух сточек... И про какие телодвижения Вы говорите?
Мощные и в то же время не переусложненные функции, и главное, операторы работы со строками, без необходимости ничего описывать, и дергать функцию за функцией для тривиальных в общем-то вещей;
Какие, например, операторы удобнее функции?
Динамическая типизация опять таки экономит время;
Это же очень спорный аргумент, разве нет? Отсутствие типизации позволяет быстрее написать приложение, в котором не будет кучи warning'ов о некорректном применении типа. Но поддерживать такое будет сложнее.
Низкий порог входа + распространенность.
По сравнению с чем? TS, C# и Kotlin+JavaFX тоже более менее распространены.
Наличие библиотек для работы с чем угодно. Хотите нарисовать пару кружочков ? Запросто. Хотите нарисованное записать в PNG ? Не вопрос. Хотите поработать с последовательным портом или i2c ? Без проблем. Распарсить INI-файл ? Как два пальца;
А в какой технологии из первых 50 языков TIOBE Index такого нет?
Приемлемая скорость работы. Тот код что я написал ниже - ранее был написан на python. Работает медленнее, строк занимает больше;
Это тоже спорный аргумент. Кого-то устроит и Electron, кто-то будет писать на более производительных языках/технологиях.
Более менее толковый дебаггинг, т.е. вывод об ошибках. Вербальный. С указанием на строку где произошла ошибка. Это весьма немаловажно.
Мы сами не знаем, что будет делать наш новый продукт, но надеемся, что что-то хорошее
Вроде, они показали очень серьезный результат. Более того, конкуренты и близко пока не могут подобраться.
Возможности использования тоже громадные уже сейчас, что видно по разного рода интеграциям в другие приложения.
Плюс сложно оспорить тот факт, что OpenAI является лидером в своей области. А потому, вполне разумно предположить, что компания будет и дальше важным игроком, как и Dropbox или Uber для своих рынков.
И вот тут вот у хорошего CIO <...> в дело вступают эксплуатационщики
И как они код проверят? Они легко поймут, что react компонент на N элементов получает N уведомлений о новом объекте при старте программы, а потому сваливается в O(N^2)? Или они будут просто квадратики на презентации смотреть? Как они это выяснять будут?
Как будут понимать, что компонент не оптимизирован под следующую версию Java (которая будет через год), даже зная, что безопасники потребуют её обновить?
Мне лично в бытность главадмином по инфраструктуре приходилось этим заниматься
Да, от части проблем получится уйти, если работать добросовестно. Вот только понять, что система будет работать неэффективно после года работы (ибо накопится условная история) - сложно. В презентациях код показывать не будет, да и админ вряд ли будет его смотреть и анализировать. А далее условная форма будет тормозить по 5-10 секунд на каждом поле, что приведет к тому, что люди будут ворчать. И, конечно же, сисадмин не заметит проблемы, ибо ему не надо вбивать эти документы постоянно. Более того, сисадмину опасно замечать проблемы в процессе эксплуатации, так как он же и подписался под этим решением.
Но я соглашусь, что определенную долю проблем можно попытаться отсечь заранее. Именно потому крупные фирмы (те же банки) лет 20 лет назад стали уходить от outsource решений и стали готовить свои команды.
Так а какой смысл иметь 1 гипермощный сервер, когда можно разложить в кластер на несколько серверов?
Статья именно про это. Если Вы хотите спроектировать систему так, чтобы она эффективно работала на кластере, а не на одном сервере, то Вам будет необходимо знание алгоритмов, технологий, а также наличие тех самых soft skills, кругозора в айти мире (чтобы не выбрать тот же Питон для крупного модуля, когда есть языки со строгой типизацией) и так далее.
В противном случае получится долгострой, ибо постоянно будут встречаться неудачные решения, которые не позволят добавлять новые и новые функции.
С одним сервером всё намного проще. Например, можно брать блокировки (а децентрализованная система скажет спасибо такой идее), можно не напрягаться с eventual consistency, а использовать строгую согласованность и так далее.
И оно покажет то, чего на тестовых серверах просто не увидишь
Всё верно - разработчики тестируют на одном подмножестве сценариев, а вы - на другом. И остается надежда на то, что пользовательский сценарий через месяц будет такой же, как и Вы предсказывали.
Если Вася накосячит и это никто не заметит <...> то значит оно и не нужно.
Такое будет только в идеальном мире, с моей точки зрения.
Я вот замечал такую последовательность событий:
Разработчики пишут сложную систему. В ряде случаев они спрямляют углы, плюс тестировщики смотрят только на частные случаи (они же не могут перебрать все, правда?).
Параллельно с этим, систему продают по B2B каналам. Другими словами - продавцы показывают всё управленцам, а не конечным пользователям.
Систему успешно внедряют, и она начинает работать. Показатели поначалу красивые, конечно.
На протяжении времени оказывается, что система работает медленно и неэффективно. Пользователи жалуются. Лет через пять некоторые из них даже становятся управленцами, а потому уже начинают иметь реальную власть, чтобы давить на переход на что-то иное.
Параллельно с этим, служба поддержки терпеливо отвечает клиентам, что Ctrl-V не работает в их html формах, что плашка "загрузка" может действительно висеть минуту, ибо мы же не гугл какой-то, правда? Ну и некоторые отчеты сделать нельзя, и это было на странице 78 контракта.
Из-за пункта 4, клиенты начинают постепенно уходить к конкурентам и систему отправляют в утиль.
то укажет Васе на проблему.
К этому моменту, эффективный менеджер Вася, скорее всего, уже работает в другой компании, так как среднее время работы на одну фирму явно меньше пяти лет. А если нет, то мало кто будет увязывать низкую производительность с уходом клиентов.
Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так
Кстати, с этим успешно может справиться и любой другой разработчик. Более того, чаще переусложнение идет от отсутствия опыта или знания: например когда человек плохо понимает, как система работает под капотом, например, но успешно справляется с частными случаями.
Другой пример: ошибка в дизайне проектирования вылезла уже после того, когда всем было бы очевидно, что легче переделывать.
Я такого не говорил. И я не слышал, чтобы фирма, где я работаю (или работал) говорила подобное.
Наш CEO, когда пришел сюда год назад, начинал с того, что туалеты мыл за 1,5 МРОТ
Я писал комментарий к Вашей фразе "Ну и что - это по-вашему нормально, что человек потративший пять-шесть лет (да еще и деньги) на высшее образование, после этого должен". И да, высшее образование не гарантирует высокооплачиваемую работу. Более того, в ряде отраслей необходимо еще поработать 5-10 лет (в общем случае) чтобы перестать быть стажером/интерном/помощником, и стать уже независимым специалистом.
Более того, мир такой, какой он есть. Его необходимо принять, вместе с текущей политикой, с текущим ограничением на скорость света, текущими налогами, визами и правилами, с текущей культурой, продолжительностью жизни и так далее. Иначе же будут постоянные разбитые ожидания, не более чем. Собственно, мой посыл именно в этом.
Если говорить об утопичном мире, то я тоже влихую мог бы предложить улучшений, то речь сейчас о том, как идеальнее всего устроиться в текущих реалиях.
Стоп, вот тут не очень понятно... Если код достаточно хорошо работает по производительности, и его не переписывают, то получается, что его сделали хорошим с первого раза, верно? Если исключить случаи ненагруженных и тормозящих приложений, то получается, что там всё сразу учли с алгоритмами, верно?
А зачем что-то оптимизировать для разовых действий? Никто не спорит, что в таком контексте знания необходимы лишь в том случае, когда объем данным становится слишком большим, чтобы тратить ресурсы просто так (и когда запускать несколько параллельных процессов приведет к переусложнению задачи).
Но ведь не весь код одноразовый, так ведь?
Понятно. Мне очень сложно представить, когда всю систему (включая ядро, дизайн базы/сервисов и пр.) переписывают десятки раз на протяжении пяти лет хотя бы. Причем "переписывают" не включает в себя рефакторинг, выделение классов, переименование методов, добавление документации и прочие мелкие вещи.
В таких условиях, я думаю, действительно нет смысла вообще думать о качестве, о поддержке или о чем-то таком.
Это, кстати, очень плохо, если не самый тривиальный код переписывают действительно так часто.
Хотя, возможно, мы говорим про разные компании...
Далеко не факт. По моему опыту есть четкая корреляция между "решал много-много Computer Science задач в прошлом" и "быстро замечаю, что система уйдет в N^2". Просто иногда люди решают много задач за год, а иногда это растягивается лет на 10: университет, первые работы (и подготовки), поиск следующей работы и так далее.
Если говорить о математике (а комбинаторика из задачи "сколькими способами вы проползете лесенку, если за раз вы можете 1 или 2 ступеньки" мало имеет отношения к leetcode), то она уже реже требуется, разве что поможет получать более высокий оклад в финансовой компании.
А как работает отмывание денег на артобъектах, если:
KYC заставляет организаторов проверять всех клиентов с деньгами.
Транзакции большие и точно не могут идти от неизвестных людей и мутных локаций (иначе организаторы идут под статью)
Транзакции достаточно большие, чтобы их прятать.
Бухгалтерия известная налоговым (страны обмениваются данными), так что любое подозрение сразу запустит раскрутку цепочки.
Мы не рассматриваем вариант ухода от налогов в стиле "покупка артобъекта у себя втридорога, чтобы потом отдать его музею, а разницу в деньгах вычесть из налогов", ибо это не отмыв.
?
Это намного сложнее. Большинство произведений как раз являются улучшением предыдущих, когда другой автор (чаще всего с радикально другим опытом) понимает, что необходимо исправить в оригинальном издании.
Например, есть языки программирования (С/Java/C#), и, если так посмотреть, есть немало тех, которые являются их производными: C++/Rust/Kotlin. Более того, на самом деле та же Java взяла много из С, а C# - из Java и Delphi.
Представьте, насколько сложно было бы сделать Java в своё время, чтобы не быть похожим на C?
Собственно, авторское право потому и откатывает культуру назад за счет запрета на производное творчество. Если сделать сроки аналогичными авторскому праву, то и проблема резко уйдет.
У Kotlin присутствует - https://www.baeldung.com/kotlin/tail-recursion#implementing-factorial-as-tail-recursion .
Не совсем. Рынок найма работает по другой схеме: на вакансию приходит N человек, из них берут M лучших, с точки зрения фирмы. Плохие условия уменьшают N, так что фирмам желательно держать N не слишком бо́льшим, чем M (чтобы был небольшой выбор, но и чтобы не переплачивать).
Другими словами - чем выше уровень человека (а это условная сумма hard и soft навыков), тем с большей долей вероятности человек будет попадать в M.
А потому, кризис больнее всего (и в первую очередь) бьет по людям с более низкими навыками в области (они будут постоянно попадать в N-M), а по остальным он бьет менее прямо, путем снижения N.
Это очень опасно, так как в последнее время, особенно в АйТи компаниях, прибыль не всегда хорошо коррелирует с оценкой компании.
Более того, если мы применяем какую-либо модель (ту де EBITDA), то необходимо договориться о её применимости в случае таких компаний, как X/Твиттер.
Разумно. Возьмём в пример C#.
Но ведь реальные приложения не состоят из двух сточек... И про какие телодвижения Вы говорите?
Какие, например, операторы удобнее функции?
Это же очень спорный аргумент, разве нет? Отсутствие типизации позволяет быстрее написать приложение, в котором не будет кучи warning'ов о некорректном применении типа. Но поддерживать такое будет сложнее.
По сравнению с чем? TS, C# и Kotlin+JavaFX тоже более менее распространены.
А в какой технологии из первых 50 языков TIOBE Index такого нет?
Это тоже спорный аргумент. Кого-то устроит и Electron, кто-то будет писать на более производительных языках/технологиях.
А где такого нет?
Вроде, они показали очень серьезный результат. Более того, конкуренты и близко пока не могут подобраться.
Возможности использования тоже громадные уже сейчас, что видно по разного рода интеграциям в другие приложения.
Плюс сложно оспорить тот факт, что OpenAI является лидером в своей области. А потому, вполне разумно предположить, что компания будет и дальше важным игроком, как и Dropbox или Uber для своих рынков.
И как они код проверят? Они легко поймут, что react компонент на N элементов получает N уведомлений о новом объекте при старте программы, а потому сваливается в O(N^2)? Или они будут просто квадратики на презентации смотреть? Как они это выяснять будут?
Как будут понимать, что компонент не оптимизирован под следующую версию Java (которая будет через год), даже зная, что безопасники потребуют её обновить?
Да, от части проблем получится уйти, если работать добросовестно. Вот только понять, что система будет работать неэффективно после года работы (ибо накопится условная история) - сложно. В презентациях код показывать не будет, да и админ вряд ли будет его смотреть и анализировать. А далее условная форма будет тормозить по 5-10 секунд на каждом поле, что приведет к тому, что люди будут ворчать. И, конечно же, сисадмин не заметит проблемы, ибо ему не надо вбивать эти документы постоянно. Более того, сисадмину опасно замечать проблемы в процессе эксплуатации, так как он же и подписался под этим решением.
Но я соглашусь, что определенную долю проблем можно попытаться отсечь заранее. Именно потому крупные фирмы (те же банки) лет 20 лет назад стали уходить от outsource решений и стали готовить свои команды.
Статья именно про это. Если Вы хотите спроектировать систему так, чтобы она эффективно работала на кластере, а не на одном сервере, то Вам будет необходимо знание алгоритмов, технологий, а также наличие тех самых soft skills, кругозора в айти мире (чтобы не выбрать тот же Питон для крупного модуля, когда есть языки со строгой типизацией) и так далее.
В противном случае получится долгострой, ибо постоянно будут встречаться неудачные решения, которые не позволят добавлять новые и новые функции.
С одним сервером всё намного проще. Например, можно брать блокировки (а децентрализованная система скажет спасибо такой идее), можно не напрягаться с eventual consistency, а использовать строгую согласованность и так далее.
Всё верно - разработчики тестируют на одном подмножестве сценариев, а вы - на другом. И остается надежда на то, что пользовательский сценарий через месяц будет такой же, как и Вы предсказывали.
Такое будет только в идеальном мире, с моей точки зрения.
Я вот замечал такую последовательность событий:
Разработчики пишут сложную систему. В ряде случаев они спрямляют углы, плюс тестировщики смотрят только на частные случаи (они же не могут перебрать все, правда?).
Параллельно с этим, систему продают по B2B каналам. Другими словами - продавцы показывают всё управленцам, а не конечным пользователям.
Систему успешно внедряют, и она начинает работать. Показатели поначалу красивые, конечно.
На протяжении времени оказывается, что система работает медленно и неэффективно. Пользователи жалуются. Лет через пять некоторые из них даже становятся управленцами, а потому уже начинают иметь реальную власть, чтобы давить на переход на что-то иное.
Параллельно с этим, служба поддержки терпеливо отвечает клиентам, что Ctrl-V не работает в их html формах, что плашка "загрузка" может действительно висеть минуту, ибо мы же не гугл какой-то, правда? Ну и некоторые отчеты сделать нельзя, и это было на странице 78 контракта.
Из-за пункта 4, клиенты начинают постепенно уходить к конкурентам и систему отправляют в утиль.
К этому моменту, эффективный
менеджерВася, скорее всего, уже работает в другой компании, так как среднее время работы на одну фирму явно меньше пяти лет. А если нет, то мало кто будет увязывать низкую производительность с уходом клиентов.Кстати, с этим успешно может справиться и любой другой разработчик. Более того, чаще переусложнение идет от отсутствия опыта или знания: например когда человек плохо понимает, как система работает под капотом, например, но успешно справляется с частными случаями.
Другой пример: ошибка в дизайне проектирования вылезла уже после того, когда всем было бы очевидно, что легче переделывать.
Я такого не говорил. И я не слышал, чтобы фирма, где я работаю (или работал) говорила подобное.
Я писал комментарий к Вашей фразе "Ну и что - это по-вашему нормально, что человек потративший пять-шесть лет (да еще и деньги) на высшее образование, после этого должен". И да, высшее образование не гарантирует высокооплачиваемую работу. Более того, в ряде отраслей необходимо еще поработать 5-10 лет (в общем случае) чтобы перестать быть стажером/интерном/помощником, и стать уже независимым специалистом.
Более того, мир такой, какой он есть. Его необходимо принять, вместе с текущей политикой, с текущим ограничением на скорость света, текущими налогами, визами и правилами, с текущей культурой, продолжительностью жизни и так далее. Иначе же будут постоянные разбитые ожидания, не более чем. Собственно, мой посыл именно в этом.
Если говорить об утопичном мире, то я тоже влихую мог бы предложить улучшений, то речь сейчас о том, как идеальнее всего устроиться в текущих реалиях.
Это известное когнитивное искажение: https://ru.wikipedia.org/wiki/Вера_в_справедливый_мир