За последние несколько лет, при работе и разговорах со многими разработчиками, я заметила один повторяющийся шаблон поведения. Он начал меня сильно беспокоить, и я продолжаю постоянно говорить и думать о нем, пытаюсь его понять или даже оправдать.
— Почему мы использовали данный подход?
— Не знаю. Это было в какой то статье.
— Не знаю. Я это скопировал из Х(источника).
— Не знаю. Я использовал этот подход на предыдущем проекте.
— Не знаю. Мне кто‑то сказал использовать его.
Данный шаблон поведения — это потребление, а не созидание. Потребление без каких‑либо вопросов. Потребление, прикрывающееся мнением авторитетов.
Я видела, как разработчики использовали решения других людей, как само собой разумеющиеся. Не подумав несколько раз об используемом подходе, не утруждая себя каким‑либо анализом. Одно дело, когда Ден Абрамов (Dan Abramov) говорит тебе, как лучше использовать React или какая‑либо документация по API говорит тебе, что есть только один вариант использования данного API, тогда — да, скорее всего надо будет прислушаться к этому. Другое дело, когда ты используешь какую‑либо информацию из статей без какой‑либо доли скептицизма, тем не менее с таким подходом ты все еще можешь продвигаться по карьерной лестнице, но это также может быть причиной твоего карьерного тупика.
Дерьмовая информация повсюду
В начале своей карьеры я бы никогда в жизни не запостила ничего технического характера в интернете. Я думала, если кто и был настолько храбрым, чтобы осмелиться написать статью или вступить в дискуссию на техническую тему, он-то точно знал, что он делал. Я никогда так не ошибалась.
В какой то момент я поняла, что большинство технического контента в интернете — дерьмо (и кстати, этот блог тоже может быть таким же). Туториалы нам показывают вредные подходы. В статьях полно концептуальных ошибок. И конечно же, люди тоже далеко не идеальны! Сеньоры не всегда являются хорошими разработчиками. Решения тех‑лидов могут быть далеки от идеала. Архитектура хорошо работающего, успешного приложения может быть полным говном. Я видела сеньоров, которые вообще не смыслят в программировании. Зато они вам что‑то о нем рассказывают в интернете. А потом кто‑то приходит и говорит, что использовал решение данного человека, потому что у него должность сеньора в компании X. В какой то мере в этом есть смысл. Но по своей сути, апелляция к авторитету глубоко ошибочна.
Едва ли не первая заповедь науки: «Не доверяй авторитетам». Ученые — тоже приматы, они склонны выстраивать иерархии и забывать это правило. Не раз людям довелось дорогой ценой убедиться в том, что и начальство может ошибаться. Утверждения самого авторитетного лица подлежат такой же точной проверке, как и любые другие.
— Карл Саган (Carl Sagan)
(Цитата из книги «Мир, полный демонов. Наука — как свеча во тьме»)
Чем раньше вы поймете, что повсюду чушь, тем будет лучше. Мы все стараемся как лучше, но тем не менее все люди совершают ошибки, и многолетний опыт, количество статей или зарплата никак не определяет знания человека. В конце концов, мы все можем постить в интернете что угодно.
Почему так происходит?
Мы ленимся. Мы не глупые, мы просто ленивые. Если кто‑то предлагает нам решение, которое работает, зачем нам вообще об этом думать? Почему бы просто не вставить данное решение в продакшн?
У нас нет времени. Обоснование использования подхода может стоить нескольких часов чтения кода, написания большого количества кода для того, чтобы доказать свою правоту или большой тратой времени на исследование. Хотя у всех у нас есть какие‑либо сроки, не так ли?
Так удобней. Логические размышления часто заставляют нас выйти из зоны комфорта, так как нам нужно приобрести новые знания, чуть усердней подумать, чем обычно, чтобы понять некоторые концепции или проделать дополнительную работу. Тогда как пребывание в зоне комфорта — это то, к чему мы стремимся(подсознательно).
Мы не верим в самих себя. Люди, особенно в начале своей карьеры, склонны думать, что их решения никогда не будут достаточно хорошими. Таким образом, они полагаются на мнения ранее упомянутых авторитетов, при этом не подвергая данные мнения никакому сомнению.
Как перестать быть потребителем?
Поймите, что в мире полно заблуждений. Люди и предлагаемые ими решения не безупречны.
Адаптируйте решения к вашим конкретным ситуациям. Нет какого‑либо универсального решения для всего. Сравнивайте разные подходы друг с другом, анализируйте их. Туториалы и статьи показывают лишь идею и совершенно не обязательно будут содержать в себе готовый к использованию код. Всегда анализируйте что‑либо перед тем, как вы соберетесь это использовать.
Верьте в себя. Ваши решения ничем не хуже тех, что лежат на просторах интернета.
Продолжайте учиться и быть любознательными. Быть разработчиком — означает постоянное обучение. Убедитесь, что вы до конца понимаете библиотеку или фреймворк, который вы используете. Это способ извлечь из них максимальную выгоду. Иногда люди используют библиотеки, не до конца вникнув в них. Это приводит к неправильному использованию основных концепций библиотек и производству более сложного или менее производительного кода, чем могло бы быть.
Не потребляйте. Созидайте. Задавайте вопросы. Оставайтесь любознательными.
Комментарии (90)
MonkAlex
20.07.2023 11:13+10Больше всего меня это радует на конференциях. Человек на dotNext рассказывает, всё круто, он как архитектор вот так сделал и вот так у них теперь работает.
Спрашиваешь у него после выступления - вот вашу задачу решает ещё инструмент А и Б, как они вам, в чём плюсы минусы? А человек не стесняясь отвечает - не знаю, не смотрел.
benjik
20.07.2023 11:13+21Вот инструмент, который решает твою задачу достаточно хорошо. Зачем тратить время на А и Б, когда задача уже решена, и скорее всего был опыт с В и Г в прошлом, отмели Д и Е по каким-то причинам, а Ж была на проекте раньше, и с неё долго и мучительно съезжали?
У архитекторов (не 23-летних) обычно и без этого хватает работы.
Про стеснение вообще не понял - зачем стесняться того, что ты чего-то не знаешь или не смотрел?MonkAlex
20.07.2023 11:13+22Делать работу - не вопрос, делай. Рассказывать как у вас всё круто, когда не можешь даже аргументированно сравнить с альтернативами - ну это очень слабый подход.
Возможно ты изобрёл велосипед, а возможно придумал крутую штуку, которую другие не осилили. Но никто не знает.
vedenin1980
20.07.2023 11:13+5Рассказывать как у вас всё круто, когда не можешь даже аргументированно сравнить с альтернативами — ну это очень слабый подход.
С другой стороны, каждую задачу можно решить десятками (а иногда и сотнями) способов. Условно, если есть задача разработать сайт, то существует сотни веб.фреймворков на разных языках программирования, сотни языков и фреймворков для реализации бека. Если перебирать все способы решений всех задач и стать экспертов в каждом — потребуется бесконечное время на реализацию простого сайта.
Поэтому в любом случае, придется делать некоторый short list основываясь либо на чужом мнении, либо на некоторых не всегда корректных параметрах (вроде про этом фреймворк я слышал, а про тот — нет).
Возможно ты изобрёл велосипед, а возможно придумал крутую штуку, которую другие не осилили.
Все уже было в Симпсонах (с). К сожалению, в 99.9(9)% случаев где-то что-то аналогичное уже не раз реализовано, но поиск и адаптация реализации скорее всего обойдется "дороже" реализации с нуля. Поэтому почти все программисты реализуют велосипеды и это нормально.
MonkAlex
20.07.2023 11:13+6Только чем конкретнее задача - тем меньше вариантов. А за разницу между вариантами и отвечает архитектор - понимает что и когда необходимо, в чём разница, как сделать выбор.
Поискать варианты - займет условный рабочий день, хотя бы для поверхностного понимания. А писать свой велосипед может стоить тысячи человеко-часов. Стоит ли того - как раз вопрос к архитектору и у него должны быть причины =)
zac04
20.07.2023 11:13"А писать свой велосипед может стоить тысячи человеко-часов." - возможно в реальности те, кто организует бизнесс и управляет командами, преследуют более прозаичные целы - например сделать велосипед, который приносит деньги сейчас. а не через условный день. ведь скопипастить и зарабатывать сейчас важнее, чем написать хорошо через день для компании.
а вот достигать совершенства можно годами. проблема в том что кто платит, тот и танцует. а все остальные причины и стремления, это остатки подросткового энтузиазма. возможно это естественная эволюция в обществе и другой не будет.
"А за разницу между вариантами и отвечает архитектор - понимает что и когда необходимо, в чём разница, как сделать выбор. " - в реальности 95% реализаций зависит от мидлов, и только, если они пишут какую то откровенную дичь, тогда архитектор или сеньор что то скажут, а в остальных случаях это советы на словах. обычно архитекторы следят за входящей и исходящими данными, что бы они не сильно расходились с принятыми шаблонами. а реализация конкретной бизнес хотелки без привязки к изменению ядра системы их не сильно волнует "как оно там внутри". работы бывает много.
да и ревью бывает кто то неделю проводит, а кто то не смотрит "работает? ок мне некогда".
теория, как оно должно быть и реальная жизнь могут сильно отличаться по моему опыту.
funca
20.07.2023 11:13+2Поискать варианты - займет условный рабочий день, хотя бы для поверхностного понимания
Архитектура в большей степени определяется нефункциональными требованиями - стоимость, надёжность, безопасность, вопросы интеллектуальной собственности, технологии, саппорт и т.п. Сделать ассесмент решения за день это профанация.
Иногда получить от вендора тупо прайс занимает месяцы (у них же там индивидуальный подход к каждому клиенту). Если вы компания, которая пишет софт, то навелосипедить за это время свое оказывается не такой уж плохой альтернативной.
MonkAlex
20.07.2023 11:13+1Я пишу о масштабах поменьше - когда надо на уже работающем продукте добавить фичу и требуется решить, будет эта фича самописной, будет она использовать известные подходы или что-то ещё.
То что вы пишите требует больше времени, естественно. Там и рисков больше и проработка важнее.
0xd34df00d
20.07.2023 11:13+1С таким подходом вам компания билет на конференцию не оплатит.
MonkAlex
20.07.2023 11:13+1Зависит. Бывают хорошие выступления от опытных людей, которые реально разбираются в том, что рассказывают и готовы делиться опытом.
А бывают такие, "для галочки", когда по ощущениям нужно выступить и показать что в компании тоже не дураки и работают у них специалисты. Но большего от них ждать не стоит.
ПС: давно не бывал на конференциях, ибо формат не нравится. За типичный часовой доклад можно рассказать или очень узкую тему или очень поверхностно что-то интересное. Первое клёво, но малопопулярно (потому что тема узкая), а второе на самом деле довольно бесполезно, кроме как узнать "о, так тоже можно сделать". В первый раз узнать, а дальше самому разбираться, ибо доклад не закроет все вопросы =)
funca
20.07.2023 11:13+2По мне, конференции это в первую очередь про общение вживую - все самое полезное и интересное происходит в кулуарах, где можно поговорить с нужными людьми именно о том что тебе нужно. Слушать доклады на широкую публику стоит, ну наверное, если совсем случайно туда попал или делать больше нечего.
AllexIn
20.07.2023 11:13+13Вы всё верно описали. Только это относится не к лектору, а к вам.
Вам надо выбрать технологию - смотрите как 10 лекторов разные технологии используют и выбирайте.
А лектор показывает как лично он что-то сделал. Лектор абсолютно правильно всё сделал. Вы предъявляете неадекватные требования.MonkAlex
20.07.2023 11:13+6Возможно, не уверен готов ли согласиться с такой постановкой.
Я хочу скорее посмотреть один-два-три материала на тему "способы сделать А", чем неизвестное число материалов "как я сделал А".
Понятно, что никто не выдаст качественно первое, но каждый кто сделал А, должен имхо хотя бы представлять, какие у него были способы это сделать =)
Как впаривали микросервисы лет 5-10 назад? Описывали минусы монолита и рассказывали, что микросервисы эти боли решают. Это простые и понятные подходы, есть что с чем сравнить, есть что обсудить, понятно что из чего выведено. А когда просто говорят "используйте микросерисы, мы сделали и нам норм" - ну, окей, вам норм, а мне с этого что? Как мне использовать эту информацию?
markmariner
20.07.2023 11:13+3Вам легко использовать эту информацию: нужно проанализировать плюсы и минусы решения и сравнить с другими решениями.
А если это займёт много времени, то потом можно ещё и лекцию прочитать "как я сравнил 7 способов сделать А и какой оказался хорошим"
MonkAlex
20.07.2023 11:13+2Это если плюсы-минусы озвучены. Иногда озвучены плюсы, минусы опущены за ненадобностью и звучит фантастически. Но без других решений нет понимания, что происходит.
Впрочем, я уже понял, что люди умудряются находить пользу в таких докладах. Рад за них, но не знаю как самому это начать делать.
eton65
20.07.2023 11:13+1Впрочем, я уже понял, что люди умудряются находить пользу в таких докладах. Рад за них, но не знаю как самому это начать делать
Если задача стоит просто сделать надежно работающую систему, то сравнивать разные варианты нет необходимости — просто берем успешный проект, смотрим чтобы технологический стек был достаточно распространенный и все — запускаем это в продакшн.
А если хочется еще и удовольствие получить, то тут без перфекционизма никак.
denis-isaev
20.07.2023 11:13+1Забавно, что этот коммент оказался под статьей которой он на 100% противоречит :)
denis-isaev
20.07.2023 11:13+1Это как обсуждать дерьмовый проходной фильм. Кто-то недоволен потраченным на него временем, и негодует, что трейлер обещал большего, а кто-то предлагает не ругать режиссера - он снимал, что хотел, в конце концов можно посмотреть несколько таких фильмов :)
michael_v89
20.07.2023 11:13Я хочу скорее посмотреть один-два-три материала на тему "способы сделать А", чем неизвестное число материалов "как я сделал А".
Посмотрите один-два-три материала на тему "как я сделал А", это и даст информацию о способах. Потом возьмите и проверьте каждый способ, и найдете плюсы и минусы. Нет времени проверять их все? Ну а почему тогда от других требуете это делать? У них тоже есть свои задачи, и нет времени на то, чтобы проверять всё подряд.
Wesha
20.07.2023 11:13-1Возможно ты изобрёл велосипед, а возможно придумал крутую штуку
Главное — чтобы не батискаф из карбона.
eton65
20.07.2023 11:13Вот инструмент, который решает твою задачу достаточно хорошо
А откуда вы можете это понять, не сравнив с другими подходами?
funca
20.07.2023 11:13+2А откуда вы можете это понять, не сравнив с другими подходами?
Это как в браке - вам не нужно сравнивать всех женщин зоне досягаемости, чтобы жить счастливо с любимой женой. Проблема выбора это вообще не проблема женатых, это проблема тех, кто ещё не определился - множества почти непересекающиеся.
В общем, не стоит перекладывать с больной головы на здоровую. Кто уже давно определился со своим выбором, рассказывают о том как у них теперь все хорошо (или плохо). Если же вам нужно ещё определяться, то слушайте про то, как определиться с выбором - только это будут совсем другие доклады и докладчики.
Wesha
20.07.2023 11:13вам не нужно сравнивать всех женщин зоне досягаемости, чтобы жить счастливо с любимой женой
Однако чтобы понять, что жена — всё ещё любимая, сравнивать, наверное, всё-таки придётся.
carebellum
20.07.2023 11:13+1вообще-то это задача архитектора анализировать альтернативы и делать обоснованный выбор из
ADR, tradeoff, все такое
vtal007
20.07.2023 11:13добавлю, возможно что он использовал тот инструмент, который он хорошо знает. И не только он, а вся команда разработки
MonkAlex
20.07.2023 11:13И это всё равно не повод не знать про альтернативы, на то ты и опытный специалист, архитектор, царь и бог.
vtal007
20.07.2023 11:13+6я просто не знаю проблематику, поэтому ничего не могу сказать
Знаю вот, что сайт можно сделать на 10-ке CMS, и еще 10-ке фреймворков и вообще на голом (энтузиазме) пхп, питоне, джаве и возможно на чем то еще
перепробовать это всё крайне сложно и не нужно
MonkAlex
20.07.2023 11:13+6А никто не оперирует настолько общими вещами. Я уже не помню точно, что там было. Что-то уровня "мы прикрутили graphQL", но не было ничего про выбор инструмента для апи. Т.е. ничего про "ну рест уже старье, потому мы пошли в графкуэль". После выступления я решил уточнить - почему таки graphQL то, что он вам давал, почему не рест, не какая-нибудь odata, способов общаться полно.
И это был очень странный ответ, что "ну мы не смотрели ничего другое, просто взяли graphQL и всё".
И это не то, что ты ждёшь от докладов на крупных конференциях. Обычно человек выступающий на конференции не только способен презентацию свою прокомментировать, но и обсудить всё вокруг темы.
Opaspap
20.07.2023 11:13+6Да чаще бывает наоборот, вот эти А Б, вот твоя задача, ты берешь А и копаншься копаешься копаешься в нем, неделю или день и в итоге пишешь под либу какой то код, недостающий функционал и к концу работы осознаещь, что велосипед ты бы сделал в 10 раз быстрее, и задача была бы в далеком прошлом, а вместо этого ты пилишь никому, кроме тебя, ненужный функционал обложившись доками и гитхабом "удобного инструмента"
DrZliden
20.07.2023 11:13+19Как перестать быть потребителем?
Глупый вопрос наверное но зачем? Я буду тратить своё время, силы. Чтобы чтото там быстрей работало? Какие плюсы для меня лично? По факту это лишний геморой.
Мы например аутсорсили проект на пару с конторой заказчика, проект на микроконтроллере, памяти мало под всё. Одна часть задачи посылать JSON, очень простой JSON. Парсить при этом задачи небыло и не будет. В итоге JSON формировались просто через sprintf. Программист заказчика негодует почему вы так вот поступаете, почему не используте вот эту либу. Ему объясняешь что либа твоя сколько памяти жрет неясно, по коду развесиста, у на сне 16 гигов чтобы плевать на ресурсы. Скрипит зубами соглашается, но очень скрипит. Через пару месяцев в одном из JSON находится ошибка, и начинается вонь воооот я говорил используйте либу вы не слушали, а вы такие растакие(это ещё даже не предпродакшен стадия, а вони было уйма, а функциона реализован на 40% там ещё писать и писать). Ну зная что мы уходим с этого проекта, мне было пофиг я добавил либу которую требовал разрабочик. Выслушал что надо сразу было так делать, вот а мы тут веловипеды делали, делать нам нехрен итд. Через месяц мы покинули проект, а через 3 я узнал, что память внезапно кончилась, и чтобы впихнуться хотя как то надо чуть ли не за каждый байт биться, и пачка либ пошла под снос. JSON вернлся к изначальной реализации.
По факту я был прав, но имело ли это смысл?
Вот честно ИМХО никакого. Два дня припераний, выслушивания что мы все неправы и велосипедисты, доказывание совему руководству, что заказчик мыслит не теми категориями, и здесь так не прокатит. Гораздо проще и продуктивней сразу было пойти на поводу заказчика, все довольны все счастливы, когда возникла проблема начали бы радостно решать её.Вот после таких случаев повпрос стоит ли заморачиваться? Плюсы то где? В домашнем проекте, что хочу то ворочу, но когда это компания то плюсов особо то не видать.
Yuriy_75
20.07.2023 11:13+1Ну да. Кто платит - тот и заказывает музыку. А с внешним заказчиком или с внутренним высокостатусным менеджером спорить - зачем? Разработчик занят зарабатыванием денег, а не установлением истины.
Darkspice Автор
20.07.2023 11:13Да, иногда просто нет выбора. Тебе говорят, что есть срок - выбирай что быстрее. По идее спорить нет смысла, если точно знаешь, что тебя не послушают и не дадут дополнительного времени, потому что на споры и доказательства, как вы и подметили, тоже уходит немало времени и сил.
thevlad
20.07.2023 11:13+1Тот кто отвечает за результат, тот и должен решать. Пару таких "специалистов" на моем опыте были посланы на юг, именно по этой причине.
DabjeilQutwyngo
20.07.2023 11:13-2В цитате вопрос не проверен на состоятельность. Проверочный вопрос к нему -- а возможно ли вообще перестать быть потребителем. Это ведь означает перестать чем-то пользоваться, что уже было сделано. Допустим. Тогда, как минимум, это означает не использовать чей-то опыт, т.е. знания (возможность сделать требующееся). Дальнейшее развитие этой идеи -- реализовывать то, что уже где-то когда-то реализовано. Следующий уровень сложности для воспроизведения -- решать те же проблемы, которые уже решены.
Вот так и утилизируются вникуда ресурсы человечества на многократное решение одних и тех же вопросов и проблем. Это значит, что вся соль и предназначение ИТ, т.е. обеспечение возможности повторного использования результатов труда (а вместе с этим и вложенного в них времени, усилий и добытых при этом знаний, т.е. их капитализация) что сберегает время и разработчикам, и пользователям, выкидывается на помойку.
Дальше проверка на осуществимость: сколько времени и усилий потребуется, чтобы всё сделать самому? Очевидный предел: невозможно самому сделать то, что человечество сделало за несколько тысяч лет (т.к. сюда входят и достижения науки, в первую очередь), не говоря уже о целесообразности. Безусловно, всегда есть порог между затратами времени на сделать самому и найти и изучить готовое решение, а затем его адаптировать под определённые условия применения. Опыт и чуйка помогают выбрать подходящий вариант.
Если изначально плевать на пользователя, его потребности и ресурсы, тогда не стоит заниматься разработкой, хотя бы чтобы не создавать ему проблем и подстав, не паразитировать на нём, продавая (даже опосредовано) кота с шилом в мешке.
DrZliden
20.07.2023 11:13+1а возможно ли вообще перестать быть потребителем.
Мертвые не потребляют, так что на данном этапе развития это грозит всем :)
Это значит, что вся соль и предназначение ИТ, т.е. обеспечение возможности повторного использования результатов трудаПредназначение ИТ решение насущный задач при помощи него самого не более того. Если сказать меркантильно то это инструмент приумножения капитала.
Опыт и чуйка помогают выбрать подходящий вариант.
Если выбор делаешь для себя то да, но есть вариант когда походящий вариант не подходящий вовсе, но проще его принять. Просто потому, что в конце месяца ты получишь ровно столько же денежков, но при этом у тебя не будет болет голова. Потому, что вон те люди считают, что это зашибись, и они это готовы оплачивать. Хотят MQTT да и хрен бы с ним пусть будет MQTT, ко мне притензий нет, и отлично.
Если изначально плевать на пользователя, его потребности и ресурсы, тогда не стоит заниматься разработкой
Если ктото готов мне просто так давать деньги чтобы я мог не заниматься разработкой, то я только за. А так мне платят за выполнение задач. Не за потребности пользователя, не за его ресурсы. Стоит задача делаю, мне платят. И паразитировать на пользователе простите это обычно очень хороший зароботок.
продавая (даже опосредовано) кота с шилом в мешке.
Почитайте почти любой лицензионное соглашения на программу: никто, никому, ничего…
Всё ИТ держится на этом...DabjeilQutwyngo
20.07.2023 11:13+1Предназначение ИТ решение насущный задач при помощи него самого не более того.
Тогда уж вручную пусть выполняют насущные задачи, не нужен в такой парадигме ИТ и даже вреден: операции, видите ли, автоматизирует, время людей плохо транжирит. И проявление этого тренда отлично видно в той пальце- и мыше-возне, которую устраивают дизайнеры пользователям.
У вашего ИТ нет будущего: он не капитализирует вложения в труд и его результаты. Капитализация = преумножение капитала, что реализуется через многократное и повторное использование. Так что никакое это не преумножение капитала, а банальная утилизиация времени жизни людей, чтобы минимум принципиальных, качественных изменений порождали.
DrZliden
20.07.2023 11:13+2Тогда уж вручную пусть выполняют насущные задачи, не нужен в такой парадигме ИТ
Люди платят, это их выбор, а нужно это им или нет не моё дело.
операции, видите ли, автоматизирует, время людей плохо транжирит.
ООо иногда на автоматизацию тратится времени гораздо больше. чем можно былобы потратить без неё, но это не технологично :D А ещё бывает когда трятят на автоматизацию год, зная что через ещё пол года эта задача вообще будет не нужна. Но за это платят, выбор досточно прост либо платят вам, либо соседу.
У вашего ИТ нет будущего
Моё ИТ меня кормит уже лет 20, если ещё 20 прокормит я буду счастлив.
Так что никакое это не преумножение капитала, а банальная утилизиация времени жизни людей
Моя организация заработала на мне больше чем вложила. Я заработал гораздо больше чем вложил. Прибыль есть я рад.
чтобы минимум принципиальных, качественных изменений порождали.
Именно так, это называется долгосрочная перспектива. Вы можете сделать всё что придумали прямо сейчас выкатить на рынок, и через год вам нечего предложить, а жрать хочется. Либо можно выдавать в год по чайной ложке изменений и замечательно при этом жить. А когда стало нечего предложить, всегда можно иконки перерисовать. И так все делают. вот у ифона края стали чуть круглей, а вот у нашего самсунга рамка на мулиметр тонЬшее, налетай торопись покупай живопись.
что реализуется через многократное и повторное использование
Ну повторное использования сейчас в кинематоргафе очень любимо, ремейк. ремастрер, перезагрузка, вот оно повторное использоание во всей красе.
shasoftX
20.07.2023 11:13+5Люди пишут "как в статьях" потому что так проще. Не только для тех кто пишет, но и для тех кто придет потом. И даже работодателю проще, потому что замену искать проще.
Чтобы написать своё, нужно не просто это написать, но доказать что это реально лучше. А так как (смотри абзац 1), то доказать что твоё решение лучше зачастую сложнее чем написать.
DabjeilQutwyngo
20.07.2023 11:13Тогда такое решение не нужно, как и затраты на него: это не решение, а применение готового. Проще или нет -- критерий для человека (чтобы не тратить энергию на мышление), но не для результата. Критерий для результата всегда один: выполнены ли требования, определяющие его. И если для этого кому-то требуется сперва поучиться, понять и познать, то иначе быть не может и не должно, т.к. означает отсутствие развития и профанацию деятельности.
Отличие ИТ от многих других отраслей заключается в том, что объектом обработки являются именно новые задачи, а не уже решённые, когда требуется лишь воспроизвести последовательность действий известного решения. Многие этого не понимают и не готовы к этому: для них непонятно, как это так каждый раз находить путь на новой части карты. Однако именно они приводят к стагнации отрасли, как минимум, а обычно -- к противодействию развитию и решению проблем, за которыми следует деградация и профанация. Если не решать новых задач, то навык решения новых задач не возникает, а имеющийся утрачивается. Так что это выбор между будущим отрасли и его отсутствием.
shasoftX
20.07.2023 11:13+4это не решение, а применение готового.
Так ведь применение готового - тоже решение. Вы не пишите каждый раз новый фреймворк для сайта. В большинстве случаев берется готовое решение и допиливается. К примеру есть Vue, Angular, React. Никто не делает своего потому что удобнее использовать уже существующее. При этом новое может быть быстрее (и в работе и в разработке (после изучения) ), но все кругом пишут в основном на перечисленной тройке а не пишут что-то своё на нативном js.
Вот создатель $mol сделал своё, которое вроде по всем тестам бьёт перечисленное (по крайней мере по его словам), но не используют, так как
Нужно изучать
Нужно поддерживать
И вот уже сколько лет автор пропагандирует это новое, но народ не кидается на это новое. И уже тем более не будет кидаться писать своё подобное с нуля.
Задача ИТ - решать проблему бизнеса. А для бизнеса проверенное и массовое решение зачастую выглядит перспективнее чем что-то новое, пусть даже в этом новом есть свои плюсы.
atshaman
20.07.2023 11:13Комбинаторный рост сложности решений + линейный рост объема доступной информации при дешевом доступе это в общем-то константы бытия и ничего ты с ними не сделаешь.
terrier
20.07.2023 11:13+12Одно дело, когда Ден Абрамов (Dan Abramov) говорит тебе, как лучше использовать React ... — да, скорее всего надо будет прислушаться к этому.
А разве это не типичное "Потребление, прикрывающиеся мнением авторитетов." в терминах статьи?
Darkspice Автор
20.07.2023 11:13Согласен, у автора это прозвучало как исключение из правил.
Тут скорее всего можно было бы данный кусок описать как:
"Если вы и собрались положиться на мнение какого-либо авторитета, то как минимум он должен быть очень близок к той теме, про которую он вам рассказывает."Но опять же, это тогда выбивается из концепции статьи, ведь мы все равно получается полагаемся на чье то мнение, даже создателя какой-либо библиотеки. Тут скорее если выбирать из двух зол.
markmariner
20.07.2023 11:13+1Так Абрамов заинтересованное лицо, он с Реактом на короткой ноге, кажется, что тут наоборот его не надо слушать.
Darkspice Автор
20.07.2023 11:13+1Я немного не уловил связь с тем, что он на короткой ноге и его нельзя слушать.
Тут речь про то, что не надо его слушать или читать если он пишет как правильно использовать React?
Или вы имели введу, что не надо его слушать по поводу того, нужно ли использовать в принципе сам React или выбрать другое решение?
MonkAlex
20.07.2023 11:13+1Двоякое впечатление от статьи.
Если всегда созидать, то ты будешь созидать велосипеды, вместо созрецания и использования чужих прекрасных автомобилей\космолётов.
Созидать можно, когда ты в теме хорош, а конкурентов не видать (или они слабые) - делай что-то хорошее, делай лучше чем остальные, самое время.
А переизобретать то, что уже изобретено и хорошо работает - ради чего? Кто сейчас изобретает свои операционные системы? Скорее фанаты, ибо остальные и так понимают, что уже есть устойчивая экосистема и в ней очень тяжело что-то менять. Кто сейчас пытается делать свой браузер? Остались фактически firefox и chrome. Да, есть неплохие браузеры на базе хрома, но начинать свой с нуля нынче - задача уровня операционной системы. И так во многом - есть готовые продукты, библиотеки, сервисы.
Да, кто-то хорош настолько, что пишет что-то новое и у него оно получится. Но на такого найдется сотня тех, кто попытался и не взлетело. И в этой сотне будут люди, которые расстроятся. Кто-то будет рад полезному опыту, а кто-то будет расстроен тратой времени.
Поэтому безусловное
Не потребляйте. Созидайте. Задавайте вопросы. Оставайтесь любознательными.
не особо полезно. Задавайте вопросы & будьте любознательны - намного лучший момент. И с ним я согласен полностью.
Darkspice Автор
20.07.2023 11:13При большом количестве решений скорее будет выбор более эффективного, в крайнем случае доработка более эффективного решения, ну и в очень крайнем случае создания с нуля, для каких-то своих специализированных нужд.
Ведь время - это деньги, и не всегда его много, что бы идти делать собственный движок для игры, как пример, особенно когда деньги не твои, а того, кто ждет результат уже сегодня или когда их не так много в принципе.
YChebotaev
20.07.2023 11:13Бывают и обратные случаи. Когда вдумчиво, с чувством, толком и расстановкой принимается решение, которое идет в разрез с общепринятой практикой. Как, например, была тут история про то что заказчик захотел делать все на хранимых процедурах в бд. Наверняка обдуманное, хорошее решение, просто так никто не делает
Так что нужен какой-то баланс между упражнениями в анализе решений и общепринятой практикой
Мне кажется, есть какая-то зависимость от масштаба катастрофы, есть что-то пойдет не так. Если это монолит, который развивает 20 команд, то, наверное, нужно выбирать наиболее популярные, поддерживаемые, развивающиеся решения. Например, взять Postgres, а не монгу, даже если последняя в чем-то выигрывает. В микросервисе больше свободы — можно больше экспериментировать и брать более адаптированные под ситуацию решения. В общем, чем больше разработчиков будут работать над проектом, тем больше он будет содержать шаблонных решений
kovserg
20.07.2023 11:13+2Мы ленимся. Мы не глупые, мы просто ленивые.
Толи еще будет. ChatGPT-ы порождают лень в промышленных масштабах, так что в ближайшем будущем, будет еще веселее.
Qvxb
20.07.2023 11:13+3Я видела, как разработчики использовали решения других людей, как само собой разумеющиеся. Не подумав несколько раз об используемом подходе, не утруждая себя каким‑либо анализом.
Хмм а с чего взято что разработчики не думали над подходом и не анализировали?
Другое дело что они вероятно не хотели обсуждать свой выбор с коллегамиОдно дело, когда Ден Абрамов (Dan Abramov) говорит тебе, как лучше использовать React или какая‑либо документация по API говорит тебе, что есть только один вариант использования данного API, тогда — да, скорее всего надо будет прислушаться к этому.
А потом кто‑то приходит и говорит, что использовал решение данного человека, потому что у него должность сеньора в компании X. В какой то мере в этом есть смысл. Но по своей сути, апелляция к авторитету глубоко ошибочна.
xD
Pastoral
20.07.2023 11:13+1Сначала ну очень эффективные менеджеры создают великолепную всеохватывающую систему - рекрутеры, джуниоры, лиды, тестеры, техподдержка... потом поверх, видимо для верности, накладывают систему контроля и поощрения вплоть до KPI... и всё для того, чтобы была надежда, что будет дешевле, а менеджерам казалось что они занимаются разумной, не путать с полезной, деятельностью (не гонялся бы ты
попменеджер за дешевизной, дёшево != хорошо), а потом удивляются - и куда это подевались герои, святыми вдохновлённые и действовать наперекор стимулам охочие.Чем удивляться чему это всё говно, лучше присмотреться к происходящему с теми, кто производит его недостаточно плодовито и/или радостно.
Тут рядом была статья про сроки, бизнесу ведь нужно точно знать когда, а вот фиг. Туда надо было бы написать, что бизнесмен - не искусник снятия кассы и не мастеровитый пользователь административного ресурса, а профессионал по действиям в условиях неопределённости без оружия. Надо было бы, да мне не по карме. Напишу здесь, месседж менеджменту всё одно один.
Что посеешь, то и пожнёшь.
DabjeilQutwyngo
20.07.2023 11:13+2Утверждения самого авторитетного лица подлежат такой же точной проверке, как и любые другие.
Поймите, что в мире полно заблуждений. Люди и предлагаемые ими решения не безупречны.
Верьте в себя.
Авторша не удосужилась проверить сделанные утверждения (не важно, свои или импортированные) и конструкцию из них. Если верить в себя, тогда это порождает именно ту проблему, о которой она написала: на месте авторитетного лица в такой ситуации находится верящий в себя. Несколькими строками выше сама же написала, что люди не идеальны, что проверяется по совершаемым ими ошибкам. А ошибки -- это расхождение ожидаемого поведения или эффекта с фактическим.
И самое главное, что авторша не сделала -- она не проанализировала, что значит верить, какое явление вообще обозначено этим термином, не проследила во всех деталях, как это происходит, что при этом происходит в мышлении, в голове, с картиной мира, к чему и почему это приводит, почему человек вообще имеет мотив верить и ему так больно, когда разум этому пытается противостоять, как возникает рассинхронизация картины мира в голове с тем, что человек описывает ею, и что всё это значит для него и окружающих.
Т.е. авторша сделала ровно тоже самое, что те программисты, взявшие готовое решение без анализа, без проверки на соответствие целям, работоспособности, вызываемых эффектов требуемым: взяла где-то увиденный набор идей без осмысления их по отдельности и в сочетаниях, без анализа их содержания, скомпоновала и выдала. С чего она после этого решила, что если сама не живёт и не ведёт себя так, как хочет этого от других, её слова будут иметь значение для других?
Timofeuz
20.07.2023 11:13+6Бóльшая часть любого контента в принципе дерьмо. Почему технический должен выделяется?
kchhay
20.07.2023 11:13-2Потому что это технический ресурс и именно те, кто его читают - этот самый контент и формируют.
С вашим, пессимистичным, подходом можно и в луже утонуть, потому что прочие утонувшие, в большинстве случаев, тонули в воде.
nronnie
20.07.2023 11:13Для текста, написанным барышней, слишком часто встречается слово "де**мо". Потом я понял, что автор публикации мужчина, поэтому это просто перевод. М.б. я и не прав.
Samid777
20.07.2023 11:13+6Знаете, есть такое шуточное утверждение, что хороший код это не тот код, который не содержит ошибок, а тот код, который работает независимо от того, сколько в нем ошибок. И кое что в этом есть.
Я правда не кодер, я связист и слаботочник в разные периоды. И я предпочитаю разбираться, как работает то, к чему я прикасаюсь. Всю жизнь я видел связистов, которые не разу не слышали, и тем более не употребляли такие слова как дифракция, интерференция, зоны Френеля, эквивалентный радиус и пр. Но они успешно выполняют задачи по связи, и хороших таких масштабов. Есть специалисты по слаботочным системам, у них реализованы огромные проекты, это умные люди. Но они утверждают, возьмем не конкретное утверждение, что блок 1 может быть подключен только способом 1. На самом деле реализаций подключения может быть больше.
Откуда взялось такое ошибочное утверждение. Человек подключил блок способом 2. Не заработало. Он подключил способом 1. При этом устранил плохой контакт, не заметил этого, сделал вывод о том, что есть только один способ подключения. Получил новые знания, они ошибочны, но работать совсем не мешают.
Как это помешает работать специалисту? Да никак. Он просто будет реализовывать на практике 1 из 2 рабочий способ, и все. Все, что он делает, будет работать, как и работало. Единственное что он возможно потеряет, это часть своего времени.
Информацию нужно уметь еще правильно понимать. Вот вспоминаю недавнее обсуждение.
Есть удлинитель, он был намотан, включен, и расплавился. ВОпрос, что способствовало расплавлению удлинителя, то, что он обладает активным сопротивлением, или же его нагрела реактивная составляющая.
Результат. Часть людей упрямо не увидела в удлинителе бифилярную намотку, что сводит его индуктивность к нулю. Они же верили что его индуктивность огромна. Ну это верно разве что для синфазной составляющей, т.е. помехи от перфоратора смотанный удлинитель в сеть не пропустит.
Даже если бы у него и было большое реактивное сопротивление, это только бы уменьшило ток в нагрузке, а не вызвало бы нагрев. Можно вспомнить дроссели в ДРЛ или люминесцентных лампах. Если вместо него ставить резистор, получился бы обогреватель. (видел как именно обогреватель и ставили вместо резистора в озонаторе, сделанном из ДРЛ с разбитой колбой)
А расплавился удлинитель, т.к. тепло выделилось на проводнике, обладающим активным сопротивлении. Просто от намотанного на катушку удлинителя тепло плохо отводится. Был бы удлинитель из сверхпроводника, не нагрелся бы.
Откуда у людей ошибочное понимание процесса? Они услышали, что реактив заствляет греться провода, и нагружает электростанции. Да, это верно. Только греется не устройство с реактивным сопротивлением. Конденсатор, с подходящими параметрами, обладающий реактивным сопротивлением почти НЕ нагреется, ничего почти не будет потреблять, но вызовет ток в подходящих к нему проводах. Если на нем и выделится тепло, то только за счет мизерной активной составляющей.
Так что я соглашусь, что нужно смотреть в самое начало. Лезть в техническую сферу, если вы пропустили в свое время математику, физики, химию, эксплуатировать серьезную аппаратуру не разобравшись в основах электроники на уровне талантливого ПТУшника можно, но возможностей будет несколько меньше. В свое время на некоторых точках я был единственным, кто выполнял задачи по связи, несмотря на то, что не имел никакого образования, что совершенно не мешало учиться самостоятельно. Если хотите понимать, как все работает, то без этого никак.Samid777
20.07.2023 11:13+5И знаете, то, что автор понял сейчас, случайно понял лет в 5...6.
Магазин советский, томительное ожидание в очереди. Ну раньше всегда так было.
Девочка примерно 3 лет играет с дверной пружиной. Ничего необычного, смартфонов в то время не было.
Заходит дедушка. Открывает дверь. Пружина расширилась. Палец девочки попадает в пружину.
Дедушка начинает закрывать дверь. Пружина сжимается. Девочка не рада, начинает громко плакать. Что должен сделать дедушка? Открыть дверь, пружина растянется, палец свободен. Но дедушка, поняв что уже сделал чтото не так, сильнее закрывает дверь, чтобы можно было освободить палец. Тут я немножко был удивлен. Подходят еще взрослые. Они оказались умнее, но не настолько, насолько нужно. Они растягивают пружину, прилагая не слабое усилие. Палец свободен.
Отсюда был сделан вывод. Люди, которыми ты считаешь очень умными, тоже ошибаются. Что бы они не утверждали, или перепроверь, или разберись в этом, прежде чем принимать утверждение и использовать его. Особенно если ошибка в данном вопросе может иметь серьезные последствия.
Далее он был дополнен. Я тоже могу ошибаться. Если ты уверен, что думаешь правильно, проверь свои действия независимым от утверждения способом. Если же утверждение написано в букваре, то убедись, что ты правильно его понял.
9982th
20.07.2023 11:13+1Знаете, в критической, или даже просто нештатной ситуации, человек, если он специально или нечаянно для этого не тренировался, имеет свойство действовать и соображать хуже, чем в спокойной обстановке. Тут и нужно-то было, казалось бы, на секунду остановиться и спокойно подумать, но в нештатной ситуации нет этой свободной секунды — ведь девочка плачет.
Samid777
20.07.2023 11:13С этим пожалуй тоже соглашусь, но еще это зависит от сложности вопроса, и да, верно, от того, как часто подобную проблему приходилось решать. И от умения действовать в критической ситуации. В мое случае тоже подобное бывает. Когда сработало куча сирен, рация разрывается с криком выключи же все это, тот кто хочет это все выключить забыл при этом сбросить тревогу со своей стороны, а добраться до выключения нужно через несколько менюшек, на выключение уходит некоторое время, и оно все равно не выключается, потому что так получилось, что в доме зеркально расположили номера приборов.... И тут думать быстро не получится. При этом охранник, который там будет работать, нажмет несколько кнопок, и все у него получится.
Но когда заходишь в подвал, и видишь что у тебя разгорается пока еще красным пламенем аппаратура, возле ввода на 380 вольт, вот тут, когда нет вокруг десятка глаз и голосов, алгоритм действия в голову приходит почти мгновенно. Потому что с маленьким пожаром сталкивался каждый.
Leetc0deMonkey
20.07.2023 11:13+1Ну вот так и из микросервисов сотворили карго-культ. Хуже - теперь ты должен соответствовать культу, иначе будет сложно найти новую работу.
dom1n1k
20.07.2023 11:13+1Много лет назад я читал книгу по 3d-графике и одна фраза оттуда мне прямо запала в душу.
Автор написал что-то типа: "а что означает вот эта опция, я честно говоря, сам не очень понял". Причем речь там шла о довольно-таки базовых вещах (о типах освещения — диффузное, амбиентное и тд).
Не в жж или телеграм-канале, а в платной бумажной книге.
Помню, я аж подвис — а так разве можно? Автор не постеснялся? Редактор пропустил?funca
20.07.2023 11:13-1С одной стороны невозможно всё знать, с другой - от авторов мы требуем каких-то сверхчеловеческих способностей. Школьные учебники приучают к тому, что в книгах должно быть все правильно. Но и их периодически переписывают, как ту же историю.
По-моему степень полезности книги стоит оценивать по тому, как она вас изменила. Сколько там того, с чем читатели согласны или не согласны - вопрос важный, но вторичный. Ведь менять способно и то и другое)
dom1n1k
20.07.2023 11:13+1Ничего сверхчеловеческого там не было, абсолютно базовые вещи по теме.
Но главное, что книга это не пост в блоге, она готовится неспешно и работает долго. Нет никакой проблемы что-то не знать в моменте. Проблема — забить и фигануть в книгу отписку.
eton65
20.07.2023 11:13+2С одной стороны невозможно всё знать, с другой — от авторов мы требуем каких-то сверхчеловеческих способностей.
Написать книгу профессионально (без ошибок, доходчиво, полно и т.д.) — это сверхчеловеческие способности? Может тогда не надо становиться автором книг?
Школьные учебники приучают к тому, что в книгах должно быть все правильно
Правильно приучают! Зачем нам технический релятивизм?
нравственного и так хватает
amarkevich
20.07.2023 11:13сложно доказывать правоту своего решения, когда в интернетах находится "типичное" решение, которое не оптимально для теекущего проекта
Darkspice Автор
С виду может казаться, что статья слишком очевидная, но на практике имело место наблюдение данного явления, мало того, я сам замечал, что порой как раз таки и был подвержен данному эффекту.
Для меня данный эффект схож с эффектом "социального доказательства", когда люди склонны оценивать правильность чего-либо, исходя из того, насколько это популярно или поддерживаемо у других людей. Тот же выбор библиотеки по количеству звезд, или желание или не желание поиграть во что-либо исходя из оценок на игру, подсознательная оценка видео еще до самого просмотра, а только лишь взгялнув на лайки или дизлайки.
На самом деле сложно судить, о правильности народного или авторитетного мнения, ведь порой выбор данного мнения действительно может сэкономить время, а иногда и навредить.
nronnie
Это вполне нормально, может быть, не как решающий, но вполне разумный аргумент при выборе. По популярному инструменту будет намного проще найти любую информацию и поддержку (книги, статьи, форумы), и больше людей уже сталкивались с какими-либо его особенностями и подводными камнями. Потом еще, если инструмент опенсорсный, то я всегда смотрю на активность его репо, и если, например, там крайний коммит был аж пять лет назад, то это сразу настораживает.
DabjeilQutwyngo
Самое главное в инструменте -- выполняет ли он требуемые функции и удовлетворяет ли остальным требованиям. Какая разница, когда он сделан? Какая разница, кто про него и что написал? Если выполняет, тогда и разговоры лишние. Тривиальнейший пример: метод наименьших квадратов в реализации на некотором языке и его экосистеме. Метод не изменится со временем. Если реализация сделана верно, нет необходимости её менять. Точно также не изменятся методы решения уравнений степени не выше пятой, не поменяются численные методы, и много чего ещё останется прежним, начиная с законов Вселенной (изучаемые физикой, химией, биологией, математикой и т.д.).
Фактор устаревания создан искусственно теми, кто перепевает давно реализованное и хорошо работающее на новый лад, кто занимается перепаковкой сделанного кем-то до него, т.к. иначе придётся вылазить из программирования и залазить в предметную область, в нерешённую проблему, придётся создавать методы решения для неё. А это делается далеко и не только программированием.
selivanov_pavel
Очень большая - если софтина активно не используется, то все внезапно вылезшие баги и несовместимости - ваша личная боль. А если у вас вылезает ошибка в чём-нибудь распространённом - вбиваете в гугл, и в 99.9% случаев кто-то уже решил похожую проблему.
DabjeilQutwyngo
Т.е. во втором случае всё равно потребуется поиск решения, как минимум, а значит тоже затраты времени, но на другое. И это всё равно заботы того, чей результат требует устранения ошибки в используемой функциональности.
Даже не смотря на намеренное удаление вами условия, что метод реализован верно, из активного использования никоим образом не следует такая вероятность наличия решения похожей проблемы, как и само существование такого решения. Особенно там, где нет возможности пересобрать неправильно работающий код.
Пример с Matlab: дизайнеры и программисты умудрились сделать несменямыми достаточно большой набор сочетаний клавиш. При этом почему-то даже не предположили, что какие-то из этих сочетаний клавиш пользователь уже назначил на установку нужной раскладки клавиатуры, например. Это про Ctrl+Shift+0, если что. Обойти эту проблему нельзя даже забравшись на уровень Java, как сделано в паре приложений для настройки сочетаний клавиш. И такого уйма сплошь и рядом. Да тот же Сбер вернул сокрытие символов одноразового кода при подтверждении транзакции, когда выкатил новую версию. В прежней он её исправил (я обращался к их ТП и разрабам), но повторное обращение они уже проигнорировали. И эти люди занимаются ИИ... Чему они его научат, никого не пугает?
Так что не на том уровне пытаесь обезопасить себя от затрат на созданные кем-то проблемы: дело не в распространённости софтины, а в процессе конструирования и реализации фундаментальных подходов типа аккуратного отношения к тому, что выбирает пользователь, к выполнение системных требований. А этот подход следует из уважительного отношения к времени других и действующим для пользователя условиям применения, т.е. чтобы хотя бы не делать ему подстав там, где это очевидно можно не делать. Это вовсе не означает завышения требований или универсальности, это означает не решать за пользователя, не отрубать варианты применения нарушением архитектуры, предусмотренной средой выполнения и применения. Ну и опять же, хотя бы проверять сделанное на целесообразность и работоспособность. А для этого оказывается необходимо переключиться из режима потребления в режим созидания.
luckman
А потом нужно будет перевести проект на новую версию языка или поменять ключевой фреймворк.
И окажется, что обратной совместимости нет, и метод (библиотеку) для подсчёта наименьших квадратов придётся либо фиксить самому, либо искать новую поддерживаемую, перерефакторив все использования старого метода.
DabjeilQutwyngo
Вы опустили то, что следует после цитаты (про перепевание старого на новый лад). Люди смертны. Значит какой-то код однажды перестанут поддерживать. От этого он не перестанет быть работоспособным будучи таковым. Если при перепевании на новый лад вы хотите, чтобы зависимости проапгрейдили за вас, то вы просто хотите, чтобы созданную искусственно проблему перепева на новый лад решили за вас. Это и есть лень и нарушение технологий в одном флаконе. Ведь если технологии не нарушаются, тогда и перепевать не придётся: подключил имеющееся, и оно работает. А ещё есть фактор развития требований. Если они изменились, то это "кому достанется обезьяна", а не "устарел, потому что последний комит был 5 лет назад".
denis-isaev
Перепевание на новый лад может быть вполне обусловлено изменившейся конъюнктурой, вы или перепеваете, или ваш продукт перестает существовать.
DabjeilQutwyngo
Тогда это либо изменение требований, либо искусственно и целенаправленно созданная кем-то ситуация. И зачем-то её создают таким образом, чтобы непременно отменить какую-то функциональность, а потом её реализовывать по которому разу. Это не развитие, а утилизация мыслетоплива разработчиков, чтобы они его потратили, но это не привело к принципиальным изменениям в индустрии в функциональных возможностях.
Продукт не перестаёт существовать хотя бы потому, что есть его пользователи. И если что-то уже работает, то это становится ценностью и обрастает зависимостями в виде процессов, в которые эта функциональность встроена. Её отмена означает разрушение инфраструктуры пользователей, искусственное создание им проблем, чтобы вынудить платить снова за то, что уже было сделано. Такое отношение компаний-разработчиков к инфраструктуре пользователей равносильно отношению злоумышленника, вредителя и вымогателя.
denis-isaev
Получается, что, перепевание софта под x86, amd64, arm и т.п. - это искусственно и целенаправленно созданная кем-то негативная ситуация равносильная вредительству и вымогательству? Не стоит портировать софт на arm, ведь и так норм работает на старой платформе.
mordotron
Во времена первых стандартизаций С++ Джим Вальдо сказал :
Все вот эти "новые версии языка" "новые версии библиотек\фреймворков" это всё только для того чтобы очередная софтварная мегажырная контора могла впаривать новые версии продуктов и зарабатывать деньги, а не обанкротиться и закрыться.
Есть куча примеров софта который один раз сделали нормально и он работает десятилетиями (линуксовые утилиты, например), но это происходит только с некоммерческими продуктами, на которых не заработаешь путём переписывания их функционала в десятый раз на более модный сегодня фреймворк, или добавления нового, крайне сомнительной важности, только для того чтобы было что рассказать на очередной конференции.
Если размотать клубок всех нововведений, выяснится что нить этого клубка не имеет концов : все "улучшения" и изменения, делаются для поддержки новых стандартов, которые точно так же сделаны для поддержки других "улучшенных" стандартов и так по кругу.
Лучшее - враг хорошего.
DungeonLords
Вот как раз линуксовые утилиты потихоньку уходят от морально устаревшей системы сборки. Это процесс нужный для их дальнейшего развития, однако процесс долгий и сложный: ломаются скрипты, автотесты...
boldape
Какая разница, когда он сделан? Какая разница, кто про него и что написал?
Берём ваш пример. Метод наименьших квадратов. Допустим нашли его реализацию на том стэке который нужен, а не на том на каком больше всего реализаций есть. Дальше оказалось реализации 10 лет. Такс 10 лет назад avx2, fma и прочего улучшенного симда не было, а значит сегодняшняя реализация ровно того же самого, но с учётом новых технологий будет работать лучше.
Теория не меняется, но вот мат часть на которой она реализована меняется со временем и соответственно реализации должны адаптироваться под новую матчасть и поэтому нужно выбирать свежее при прочих равных.
homm
У вас ваш комментарий 2 раза подряд показывается.
Wesha
Всё правильно, он самый первый в треде, а потом его кто-то ещё и в "закреплённые" добавил.
homm
И почему же вам кажется правильным закреплять его, если он самый первый в треде?
Wesha
Задайте этот вопрос тому, кто закрепил.
Darkspice Автор
Спасибо, открепил. Я просто совсем и позабыл что первый комментарий остается первым. Просто хотел свои мысли по поводу статьи написать не в статью, а рядом, и закрепил комментарий, чтобы он был сразу виден после статьи.
itGuevara
Ассертивность — навык уверенности в себе. Умение самостоятельно регулировать свое поведение и за него отвечать вне зависимости от оценок и влияния других людей.
https://habr.com/ru/companies/epam_systems/articles/460381/
domix32
Забавно что отсутвует "отсутствие экспертизы" как класса проблемы, но есть "отсутвие времени". Ну то есть по мере того как человек набивает шишки у него появляется понимание и ощущение как делать достаточно хорошо и с уменьшением скоупа и переключении происходит процесс переобучения под новые требования.