Удачи вам "настраивать моки" под принципиально различающиеся абстракции ФС, особенности сетевого стека и, что самое противное, нативного оконного интерфейса. И как у вас вообще юниттесты под целевую машину Linux буду запускаться на машине разработчика с Windows, когда поддерживаться должны обе ОС?
Пардоньте, я в ветку ниже писал ту же историю, Вы не обязаны были видеть. Но прикол регулярных коммитов в удалённую ветку в том, что можно настроить на неё автоматический прогон интеграционных тестов, и тогда сам понимаешь на каком моменте что-то не угдядел.
На своём окружении проблемы даже не замечал, но проект работает ещё под двумя ОС и в основном разница поведения инкапсулируется библиотеками, но в исключительном наборе случаев ifdefами и не на уровне синтаксиса или семантики, а на уровне логики работы (окружения) приложения. Такое вот бывает. Проблема не в том, что что-то поменял и сломал, а в том что что-то не поменял ещё, и тем самым сломал.
А чем закончилось, ну то есть что из всей истории Вам кажется тут самым важным?
Инвесторы зачастую нередко теряют/приобретают большие деньги, такова суть этой деятельности. С крахом доткомов инвестиции в интернет компании не прекратились, напротив, после небольшой коррекции, стали кратно расти, и создали тот мир, который мы сейчас видим. Если тут и можно найти какую-то аналогию с предсказанием будущего относительно сектора ИИ, то да, коррекции будут, но пока еще даже говорить об этом странно, весь рынок ИИ меньше даже рынка криптовалют, который тоже что-то не спешит схлопываться.
В общем, наверное, я ничего не понял в Вашей фразе "Интернет кончился".
Технические архитектурные решения — тут ещё сложнее. Хороший архитектор принимает их не монеткой и не броском кубика, а на основе опыта, понимания будущих изменений и компромиссов. Многие решения потом оказываются “ой, не туда пошли”, но это не из-за случайности выбора.
О хорошей (чистой, идеальной, и так далее) архитектуре немало книг и статей написано. Проблема, когда рекомендации не удается однозначно применить (или даже истолковать) в случае конкретного контекста. Ни опыт (формализуем, но мало что доказывает), ни чутье (не формализуемо и не измеримо), ни другие факторы никак не доказывают, что принимаемое решение будет эффективно на долгих сроках. У кого-то перевесил опыт ("ну я так уже делал, вышло плохо"), у кого-то перевесило чутье ("что-то мне подсказывает, что это не сработает"), кто-то больше от положительных сценариев отталкивается, кто-то от отрицательных, но некоторые вещи принципиально невозможно сравнить, и выбор относительно них - это не более, чем метафорический бросок монетки. Если можно построить эффективный алгоритм принятия этих решений, то его тут же можно будет использовать в ИИ. Но его просто нет. Не потому что "это слишком сложно", а потому, что, вполне вероятно, его просто нет, как и той самой чистой архитектуры.
Пример простой, но полезным бы я его не назвал. Вот есть функция f(...), есть уже другой код, который опирается, на ее поведение, допустим он нас устраивает. Ничего не мешает добавить в функцию новый дефолтный параметр f(..., newParam=0), и тогда никаких поисков и принятия решений не будет, все будет работать.
Допустим он (другой код) нас не устраивает, причем настолько, что мы к нему даже тесты не писали, и не устраивает, как раз именно из-за того, что мы упустили какую-то существенную часть механики и (в принципе, да) смысла этой функции f.
Первое (и пока единственное что приходит в голову это такая история) Допустим была f(x,y) = sqrt(x2+y2), а нужна была f(x,y,z)=sqrt(x2+y2+z2), так как мы потом поняли, что вообще-то наше пространство трехмерно. Откуда это z брать в остальном коде, без переосмысления исходной задачи ни ИИ ни товарищ сеньор не сообразит без дополнительных вводных. В математическом коде, на этапах проектирования, увы, такое бывает, но обычно означает, что мы вообще не ту задачу решали.
В продуктовом? Но как, почему зачем? Хорошо, допустим была функция LOG(text, severity=LOG_DEBUG) и все джуниорчики решили, что severity это что-то на иностранном, и вообще для продвинутых, и просто дергали LOG(text). Чтобы джуниорчики так больше не делали, лид решил зафорсить этот параметр изменил описание функции на LOG(text, severity), и дал задачку джуниорчикам, чтобы код снова компилился, проставляя severity исходя из здравого смысла между вариантами (DEBUG, WARNING, ERROR, CRITICAL). Один джун везде поставил обратно DEBUG, потому что так раньше работало. Второй решил, что его модуль самый важный в системе, и везде поставил минимум WARNING, но слово CRITICAL его испугало, и от него он отказался. Третий решил, что ERROR = exception, WARNING = тот DEBUG, который для него более важен, а CRITICAL это когда он не знает, как обработать exception в принципе. Лид объяснил почему это не правильно каждому, коммиты не принял, расставил все сам. Прошло три года, тот лид давно уже уехал в Австралию, на его место пришел новый. Посмотрел проект, сказал, "ну вот это и это я понял, тут и тут хорошо, но какой дурак проставлял уровни severity в логировании? Уволить бы его".
Да, примеры из опыта, если что.
И это я к чему. Что даже в такой "простой" задаче нет никакого доказательства, что человек на самом деле умеет ее решать, во всех случаях, а уж тем более, в тех случаях, когда не надо было ее решать в принципе.
UPD. А да, рядовой полезный кейс, это dependency injection, с этим более-менее неплохо ИИ справляется. Главное ему так и сказать, что это DI, а не "прокинь мне пожалуйста ссылку на объект вон в ту ветку, ты должен сделать так, чтобы его имплементация не была видна".
С точки зрения многих вайтишников, это практически единственный формализуемый навык программиста, который монетизируется. Не прошел литкод собес - и нечего монетизировать. Прошел литкод собес, монетизируй хоть пощелкивание пробелом, хотя и какое-то очень ограниченное время. Это и вынуждает некоторых особо упоротых использовать ИИ, чтобы создать себе приложение - ИИ помощника, который помогает проходить литкод (недавно здесь статья была).
По мнению многих работодателей, литкод помогает в короткие сроки понять, как человек мыслит, хотя сейчас уже кажется, что большего абсурда и не придумать - в решении подобных задач, человек и будет мыслить как ИИ, причем хуже ИИ.
Принимать решения необходимо всегда и во всем. В большинстве случаев, правда лишь дальнейшая практика покажет, какое из решений было правильным. Обычно все упирается в "дорогое, но хорошее решение" против "дешевого, но плохого". Такие решения должен принимать человек, которому важно как скажется для него и его бизнеса дорого/дешево хорошо/плохо. Правильно, когда этим занимается владелец бизнеса, материально ответственный управляющий, потому что любые кейсы здесь в каких-то историях могут иметь более подходящее значение. А условный сеньор, не зная всех деталей (не только технических) бизнеса, может с тем же успехом монетку бросить. ИИ тоже так может.
Планировать действия, это на каком уровне? Успеть все что нужно к концу спринта написать, оценить задачу в человекочасах, или же спланировать, что мы будем делать, если одна из библиотек, используемых в нашем проекте, через два года перестанет поддерживаться? Никто так далеко не видит. Вот и здесь, сидят лиды, и подкидывают монетку, нужен ли нам этот слой абстракции, или не нужен. Если угадывают, то получают плюсик в репутацию. Если нет, ничего не теряют.
Большинство реальных проблем выбора исчезнет, как только удастся получить способ писать и переписывать код быстро (= дешево), не теряя его функционала. И все это, да, просто продолжение текста хотелок владельца или ответственного за проект. Разумеется, любой сеньор/лид, который является ИО последнего не будет заменен, именно потому, что он совершает выбор. Про всех остальных - уже сложнее.
Удачи вам "настраивать моки" под принципиально различающиеся абстракции ФС, особенности сетевого стека и, что самое противное, нативного оконного интерфейса. И как у вас вообще юниттесты под целевую машину Linux буду запускаться на машине разработчика с Windows, когда поддерживаться должны обе ОС?
А почему, кстати, у процессоров так мало PCIe линий, это как-то очень дорого реализуется?
Пардоньте, я в ветку ниже писал ту же историю, Вы не обязаны были видеть. Но прикол регулярных коммитов в удалённую ветку в том, что можно настроить на неё автоматический прогон интеграционных тестов, и тогда сам понимаешь на каком моменте что-то не угдядел.
Вот чего я точно боюсь, так это вайб-юристов)
Вайб-адвокат так точно страшный сон)
Кому нам?)
Кому нужно такое неэффективное топливо?
Вайб-менеджер, очевидно)
На пользовательских историях научат. Интернет-то он изрядно тупой.
На своём окружении проблемы даже не замечал, но проект работает ещё под двумя ОС и в основном разница поведения инкапсулируется библиотеками, но в исключительном наборе случаев ifdefами и не на уровне синтаксиса или семантики, а на уровне логики работы (окружения) приложения. Такое вот бывает. Проблема не в том, что что-то поменял и сломал, а в том что что-то не поменял ещё, и тем самым сломал.
Жаль, что рассмотрение массивов размера 10^8 не попало в эту статью, график выглядит как некая интрига пока)
А чем закончилось, ну то есть что из всей истории Вам кажется тут самым важным?
Инвесторы зачастую нередко теряют/приобретают большие деньги, такова суть этой деятельности. С крахом доткомов инвестиции в интернет компании не прекратились, напротив, после небольшой коррекции, стали кратно расти, и создали тот мир, который мы сейчас видим. Если тут и можно найти какую-то аналогию с предсказанием будущего относительно сектора ИИ, то да, коррекции будут, но пока еще даже говорить об этом странно, весь рынок ИИ меньше даже рынка криптовалют, который тоже что-то не спешит схлопываться.
В общем, наверное, я ничего не понял в Вашей фразе "Интернет кончился".
Так, будто не инвесторы выбирают, куда переливать капитал.
О хорошей (чистой, идеальной, и так далее) архитектуре немало книг и статей написано. Проблема, когда рекомендации не удается однозначно применить (или даже истолковать) в случае конкретного контекста. Ни опыт (формализуем, но мало что доказывает), ни чутье (не формализуемо и не измеримо), ни другие факторы никак не доказывают, что принимаемое решение будет эффективно на долгих сроках. У кого-то перевесил опыт ("ну я так уже делал, вышло плохо"), у кого-то перевесило чутье ("что-то мне подсказывает, что это не сработает"), кто-то больше от положительных сценариев отталкивается, кто-то от отрицательных, но некоторые вещи принципиально невозможно сравнить, и выбор относительно них - это не более, чем метафорический бросок монетки. Если можно построить эффективный алгоритм принятия этих решений, то его тут же можно будет использовать в ИИ. Но его просто нет. Не потому что "это слишком сложно", а потому, что, вполне вероятно, его просто нет, как и той самой чистой архитектуры.
И я так понимаю, у этой гипотезы есть какое-то обоснование?
Пример простой, но полезным бы я его не назвал. Вот есть функция f(...), есть уже другой код, который опирается, на ее поведение, допустим он нас устраивает. Ничего не мешает добавить в функцию новый дефолтный параметр f(..., newParam=0), и тогда никаких поисков и принятия решений не будет, все будет работать.
Допустим он (другой код) нас не устраивает, причем настолько, что мы к нему даже тесты не писали, и не устраивает, как раз именно из-за того, что мы упустили какую-то существенную часть механики и (в принципе, да) смысла этой функции f.
Первое (и пока единственное что приходит в голову это такая история) Допустим была f(x,y) = sqrt(x2+y2), а нужна была f(x,y,z)=sqrt(x2+y2+z2), так как мы потом поняли, что вообще-то наше пространство трехмерно. Откуда это z брать в остальном коде, без переосмысления исходной задачи ни ИИ ни товарищ сеньор не сообразит без дополнительных вводных. В математическом коде, на этапах проектирования, увы, такое бывает, но обычно означает, что мы вообще не ту задачу решали.
В продуктовом? Но как, почему зачем? Хорошо, допустим была функция LOG(text, severity=LOG_DEBUG) и все джуниорчики решили, что severity это что-то на иностранном, и вообще для продвинутых, и просто дергали LOG(text). Чтобы джуниорчики так больше не делали, лид решил зафорсить этот параметр изменил описание функции на LOG(text, severity), и дал задачку джуниорчикам, чтобы код снова компилился, проставляя severity исходя из здравого смысла между вариантами (DEBUG, WARNING, ERROR, CRITICAL). Один джун везде поставил обратно DEBUG, потому что так раньше работало. Второй решил, что его модуль самый важный в системе, и везде поставил минимум WARNING, но слово CRITICAL его испугало, и от него он отказался. Третий решил, что ERROR = exception, WARNING = тот DEBUG, который для него более важен, а CRITICAL это когда он не знает, как обработать exception в принципе. Лид объяснил почему это не правильно каждому, коммиты не принял, расставил все сам. Прошло три года, тот лид давно уже уехал в Австралию, на его место пришел новый. Посмотрел проект, сказал, "ну вот это и это я понял, тут и тут хорошо, но какой дурак проставлял уровни severity в логировании? Уволить бы его".
Да, примеры из опыта, если что.
И это я к чему. Что даже в такой "простой" задаче нет никакого доказательства, что человек на самом деле умеет ее решать, во всех случаях, а уж тем более, в тех случаях, когда не надо было ее решать в принципе.
UPD. А да, рядовой полезный кейс, это dependency injection, с этим более-менее неплохо ИИ справляется. Главное ему так и сказать, что это DI, а не "прокинь мне пожалуйста ссылку на объект вон в ту ветку, ты должен сделать так, чтобы его имплементация не была видна".
В кульминационный момент она там достигалась историей, "Вы и кушать за меня будете?" - "Агаа!".
Только вот ИИ обратно в ларец уже никто не запихнет.
С точки зрения многих вайтишников, это практически единственный формализуемый навык программиста, который монетизируется. Не прошел литкод собес - и нечего монетизировать. Прошел литкод собес, монетизируй хоть пощелкивание пробелом, хотя и какое-то очень ограниченное время. Это и вынуждает некоторых особо упоротых использовать ИИ, чтобы создать себе приложение - ИИ помощника, который помогает проходить литкод (недавно здесь статья была).
По мнению многих работодателей, литкод помогает в короткие сроки понять, как человек мыслит, хотя сейчас уже кажется, что большего абсурда и не придумать - в решении подобных задач, человек и будет мыслить как ИИ, причем хуже ИИ.
Принимать решения необходимо всегда и во всем. В большинстве случаев, правда лишь дальнейшая практика покажет, какое из решений было правильным. Обычно все упирается в "дорогое, но хорошее решение" против "дешевого, но плохого". Такие решения должен принимать человек, которому важно как скажется для него и его бизнеса дорого/дешево хорошо/плохо. Правильно, когда этим занимается владелец бизнеса, материально ответственный управляющий, потому что любые кейсы здесь в каких-то историях могут иметь более подходящее значение. А условный сеньор, не зная всех деталей (не только технических) бизнеса, может с тем же успехом монетку бросить. ИИ тоже так может.
Планировать действия, это на каком уровне? Успеть все что нужно к концу спринта написать, оценить задачу в человекочасах, или же спланировать, что мы будем делать, если одна из библиотек, используемых в нашем проекте, через два года перестанет поддерживаться? Никто так далеко не видит. Вот и здесь, сидят лиды, и подкидывают монетку, нужен ли нам этот слой абстракции, или не нужен. Если угадывают, то получают плюсик в репутацию. Если нет, ничего не теряют.
Большинство реальных проблем выбора исчезнет, как только удастся получить способ писать и переписывать код быстро (= дешево), не теряя его функционала. И все это, да, просто продолжение текста хотелок владельца или ответственного за проект. Разумеется, любой сеньор/лид, который является ИО последнего не будет заменен, именно потому, что он совершает выбор. Про всех остальных - уже сложнее.
Если вы в уме умели перемножать кучу трехзначных чисел, то этот навык уже трудно будет монетизироаать.
Скрытый текст