Comments 210
То есть три года назад вы были Д'Артаньяном?
Немного покапитански. Хотя спорить невозможно.
По мере роста собственной квалификации, всегда наступает момент, когда чуешь себя олицетворением мудрости. И через n-ое время это чувство разбивается об суровую реальность.
Помню когда только начинал читать чужой код, ни раз посещали мысли: «Зачем так сложно? Ну накрутили! Можно же легче!». И спустя пару лет читая тот же самый код мысли совершенно другие: «Как изящно! А этот прием надо взять на вооружение!»
По мере роста собственной квалификации, всегда наступает момент, когда чуешь себя олицетворением мудрости. И через n-ое время это чувство разбивается об суровую реальность.
Помню когда только начинал читать чужой код, ни раз посещали мысли: «Зачем так сложно? Ну накрутили! Можно же легче!». И спустя пару лет читая тот же самый код мысли совершенно другие: «Как изящно! А этот прием надо взять на вооружение!»
А потом может оказаться, что с экономической точки зрения это был самый эффективный выбор. За счет быстрой разработки, нарастив базу пользователей, стартап продастся за хорошую сумму и основатели получат хороший капитал.
А потом может оказаться, что некоторым людям не по душе мир, в котором критически важные для цивилизации вещи делаются через задницу. И вообще, у этих людей точка зрения — не экономическая. И это люди приходят к выводу, что если капитализм работает именно так, как Вы рассказали — то капитализм надо разрушить.
Результаты их труда обычно наблюдаются в разрухе и упадке целых стран.
СССР, Куба, Венесуэла, Северная Корея, Иран — все они смогли отстоять свое право на лучший путь.
СССР, Куба, Венесуэла, Северная Корея, Иран — все они смогли отстоять свое право на лучший путь.
Тогда уж и Китай сюда же припишите.
На Японию скинули две ядерные бомбы, в Германии камня на камне не оставили, в Южной Корее в это время еще матыгой землю обрабатывали, а в Израиле еще ветер по пустыне колючки носил. Мне кажется, что все гораздо сложнее, чем неравноценный старт.
На Японию скинули две ядерные бомбыОт которых погибло, по самым крайним оценкам, 200 тысяч человек. Страшно, конечно, когда от одной бомбы 100 тысяч человек гибнут, но немцы уничтожили миллионы — пусть для этого им и потребовалось куда больше бомб.
в Германии камня на камне не оставилиНо зато оставили людей. Конество погибших солдат сравнимо, а вот количество погибших мирных жителей — нет.
Может быть и стоило «сравнять с землёй» Германию, чтобы «равные условия» создать, но… гуманизьм… а история сослагательного наклонения не имеет.
Многие города пришлось отстраивать заново, но весьма недешёвые автобаны нужно было только чуток подлатать.
в Южной Корее в это время еще матыгой землю обрабатывалиВот это — хороший пример. Вот только непонятно на чью мельницу: основной причиной бурного роста были… пятилетние планы и… градообразующие компании.
а в Израиле еще ветер по пустыне колючки носил.Ну, туда другие страны столько всего привезли, что можно было бы и на Луну слетать. Тот факт, что это произошло не в результате завоеваний, а в результате «идеологической обработки» с точки зрения экономики большой роли не играет.
Мне кажется, что все гораздо сложнее, чем неравноценный старт.На самом деле всё просто: социализм обеспечивает высокую эффективность создания того, что мы знаем как делать — но низкую для того, чего не знаем. Капитализм — наоборот. Потому выигрывают те страны, которые удачно сочетают эти два подхода, а не те, кто ударяется в крайности.
Ок, меняем «а счет быстрой разработки, нарастив базу пользователей, стартап продастся за хорошую сумму и основатели получат хороший капитал» на «а счет быстрой разработки, понравившись партийному начальству, отдел получит путевки на море и основатели купят „Волгу“». Стало лучше?
Проблема-то не в капитализме вовсе, а в людях.
Проблема-то не в капитализме вовсе, а в людях.
На переходе от СССР к РФ я наблюдал лично многих людей. И наблюдал издали медийных персон. Перерождение было потрясающее.
Вот почему-то так бывает, что в одной системе — человек один; а система сменилась (система переродилась; или человек перешёл в другую систему) — и человек как будто совсем другой.
Я читал, как англичане, любящие животных у себя дома — при переезде в другую страну становятся жестокими к животным. Пруфа не будет — давно читал.
В Японии с её феодальными традициями — отношения между работниками корпорации долговременные. И работники ведут себя иначе. Неужто там люди другие? А мне кажется — дело в системе отношений.
В СССР отдел, который быстро что-то разработал — не мог быстро разбежаться. И после путёвок на море вкупе с «Волгами» — мог поехать на Колыму (это при И.В.Сталине).
Вот, кстати, хороший пример:
Где-то в 200*-х годах на этапе появления P'II — появились диски ёмкостью более 32 GB, и компьютеры на этих дисках стали виснуть на этапе BIOS, до загрузки OS. Я что-то не слышал, чтобы программисты были как-то наказаны за такое.
А при И.В.Сталине — они бы поехали на Колыму. За вредительство. И это было бы правильно.
А то, как говорил А.Райкин — «за качество никто не отвечает».
Вот почему-то так бывает, что в одной системе — человек один; а система сменилась (система переродилась; или человек перешёл в другую систему) — и человек как будто совсем другой.
Я читал, как англичане, любящие животных у себя дома — при переезде в другую страну становятся жестокими к животным. Пруфа не будет — давно читал.
В Японии с её феодальными традициями — отношения между работниками корпорации долговременные. И работники ведут себя иначе. Неужто там люди другие? А мне кажется — дело в системе отношений.
В СССР отдел, который быстро что-то разработал — не мог быстро разбежаться. И после путёвок на море вкупе с «Волгами» — мог поехать на Колыму (это при И.В.Сталине).
Вот, кстати, хороший пример:
Где-то в 200*-х годах на этапе появления P'II — появились диски ёмкостью более 32 GB, и компьютеры на этих дисках стали виснуть на этапе BIOS, до загрузки OS. Я что-то не слышал, чтобы программисты были как-то наказаны за такое.
А при И.В.Сталине — они бы поехали на Колыму. За вредительство. И это было бы правильно.
А то, как говорил А.Райкин — «за качество никто не отвечает».
Если за любую ошибку отправлять на Колыму — то все специалисты быстро закончатся. Потому что не ошибается только тот, кто ничего не делает.
И еще: проблема не в тех людях, кто пишет софт — а в тех, кто его принимает.
И еще: проблема не в тех людях, кто пишет софт — а в тех, кто его принимает.
Вы так говорите, как будто билет на Колыму — строго в один конец. А ведь Королёв съездил туда — и после этого отправил Гагарина в космос.
Естественно, на Колыму надо отправлять не за каждую ошибку — а за самые сильные ошибки. Тогда специалисты, не желающие ехать туда — будут соревноваться в минимизации ошибок. А отдельные плохие специалисты, которые туда всё-таки поедут — своей поездкой вразумят и мотивируют оставшихся.
Кстати, тех, кто принимает софт — за ошибки в софте тоже надо отправлять на Колыму. Для меня — они тоже входят в понятие «специалисты».
Естественно, на Колыму надо отправлять не за каждую ошибку — а за самые сильные ошибки. Тогда специалисты, не желающие ехать туда — будут соревноваться в минимизации ошибок. А отдельные плохие специалисты, которые туда всё-таки поедут — своей поездкой вразумят и мотивируют оставшихся.
Кстати, тех, кто принимает софт — за ошибки в софте тоже надо отправлять на Колыму. Для меня — они тоже входят в понятие «специалисты».
Вы так говорите, как будто билет на Колыму — строго в один конецА вы так говорите будто съездить на Колыму — это практически путевка в санаторий. Я бы даже с гарантией возврата не хотел бы туда попасть.
Тогда специалисты, не желающие ехать туда — будут соревноваться в минимизации ошибок.
Чтобы минимизировать ошибки нужно ничего не делать. Все специалисты разбегуться по местам с наименьшей ответственностью и останутся только глупые но жадные (да и то только при условии что оплата будет заметно выше рынка).
А отдельные плохие специалисты, которые туда всё-таки поедут — своей поездкой вразумят и мотивируют оставшихся.Мотивируют сбежать туда, где нет такой ответственности.
А вы так говорите будто съездить на Колыму — это практически путевка в санаторий. Я бы даже с гарантией возврата не хотел бы туда попасть.Ну, тут я должен заметить, что в системе, в которой попасть на Колыму (точнее — под репрессии государства) вообще невозможно — человек подвергается другим опасностям. В частности, чиновники, имеющие иммунитет — разваливают инфраструктуру, в т.ч. здравоохранение; ну и появляется неиллюзорный шанс попасть в эпидемию.
Чтобы минимизировать ошибки нужно ничего не делать.У Вас в логике что-то поломалось. «Ничего не делать» — это тоже ошибка; и зачастую более тяжёлая, чем сделать неоптимально.
Все специалисты разбегуться по местам с наименьшей ответственностьюА на таких местах — зарплата низкая. И социальный статус паршивый. А работа — грязная и вредная для здоровья. Ну, давай, беги, никто не держит — посмотрим, сколько ты там выдержишь (это я не Вам, а абстрактному собеседнику, который испугался ответственности).
Общественно-историческая практика показывает, что люди не боятся риска. Посмотрите, сколько людей в 199*-е пошли в бандиты — при этом отлично понимая, что результатом косяка может оказаться отправка даже не на Колыму, а на пару метров под землю, и возможно, живьём.
«Ничего не делать» — это тоже ошибка; и зачастую более тяжёлая, чем сделать неоптимально.С чего это? Если я учась на инженера-программиста вижу что за баги таких как я ссылают на колыму, то я забираю документы и иду работать продавцом или дворником. Система потеряла специалиста и получила неквалифицированного работника. По квалификации я — ничего не делаю и шансов уехать далеко и надолго у меня практически нет.
А на таких местах — зарплата низкая. И социальный статус паршивый. А работа — грязная и вредная для здоровья. Ну, давай, беги, никто не держит — посмотрим, сколько ты там выдержишь (это я не Вам, а абстрактному собеседнику, который испугался ответственности).Ну у нас же есть исторические примеры, которые показывают что да — убегут. Или по вашему шаражки в которых ученых заставляли трудиться они почему появились?
Если я учась на инженера-программиста вижу что за баги таких как я ссылают на колыму, то я забираю документы и иду работать продавцом или дворником.Оно так не работает. Посмотрите вокруг — сколько человек переходят улицу в неположенном месте, сколько людей совокупляются без предохранительной защиты, сколько людей пускаются в финансовые аферы.
Система потеряла специалиста и получила неквалифицированного работника.Через год работы дворником Вы понимаете, что это не сильно лучше, чем Колыма. И поступаете снова.
По квалификации я — ничего не делаю и шансов уехать далеко и надолго у меня практически нет.Вообще-то, если Вы не ликвидировали вовремя гололёд — то шанс отправиться на Колыму есть и в роли дворника.
Ну у нас же есть исторические примеры, которые показывают что да — убегут.С нетерпением жду имена убежавших.
Или по вашему шаражки в которых ученых заставляли трудиться они почему появились?Я что-то не помню, чтобы работавшие в шарашках люди пытались куда-то бежать. Ни до посадки, ни во время отбывания срока на Колыме, ни во время работы в шарашке.
Оно так не работает. Посмотрите вокруг — сколько человек переходят улицу в неположенном месте, сколько людей совокупляются без предохранительной защиты, сколько людей пускаются в финансовые аферы.
Вот именно эти люди и будут писать глючные программы в промежутках между поездками на Колыму.
А вот тут уже будет действовать искусственный отбор:
- Те, кто по генетическим или образовательным причинам будут писать самые глючные программы — первыми отправятся на Колыму.
- Те, кто какое-то время смогут избежать глюков — останутся на месте, родят детей и воспитают учеников.
Примерно то же самое происходит с теми, кто переходит улицу в неположенном месте. Те, кто переходят удачно (по причине того, что хорошо умеют оценивать риски) — выживают. Те, кто не умеют оценивать ситуацию — либо не переходят дорогу в неположенном месте (по нашей ситуации — "не идут работать программистами"), либо попадают в аварию; некоторые гибнут сразу, некоторые выживают.
Те, кто выжили в аварии — учатся на собственном плачевном опыте. Т.е. либо начинают дотошно соблюдать правила, либо учатся ориентироваться на дороге.
Те, кто не делают ни того, ни другого — на второй… третьей итерации отправляются на тот свет.
И у программистов есть свои правила разработки программ. Те, кто будут соблюдать эти правила — особых успехов не достигнут, но и на Колыму не попадут.
Но в ряде случаев — для достижения хорошего результата правила надо нарушать. Собственно, все новые наборы правил создаются теми, кто не боялся нарушать старые правила. Но тут уже надо смотреть, оценивать свои способности и возможные риски.
Собственно, я тут веду к мысли о том, что и хреновые программисты тоже найдут себе работу — там, где не требуется высокое качество кода. Естественно, там д.б. налажен автоматический контроль за качеством работы — т.е. будут нужны системы тестирования, написанные высококвалифицированными программистами.
А вот к написанию BIOS'а — могут допускаться только высококвалифицированные программисты: на высокую зарплату и с высокой ответственностью.
Собственно, я тут веду к мысли о том, что и хреновые программисты тоже найдут себе работу — там, где не требуется высокое качество кода.
То есть вы признаете, что бывают области где высокое качество кода не требуется? Ну и о чем тогда спор?
Очевидно, спор о том, нужна ли высокая степень ответственности (т.е. уголовные наказания) для программистов, которые работают в областях, где высокое качество кода такИ да — требуется.
Процитирую свои постулаты — чтобы напомнить, о чём спор был изначально:
- "А потом может оказаться, что некоторым людям не по душе мир, в котором критически важные для цивилизации вещи делаются через задницу. И вообще, у этих людей точка зрения — не экономическая. И это люди приходят к выводу, что если капитализм работает именно так, как Вы рассказали — то капитализм надо разрушить."
Это на тему экономической эффективности, которая почему-то ставится некоторыми людьми на роль целевой функции. Причём интересно, что эффективность подразумевается в отношении одного предприятия, а не всего общества в целом — на убытки всего общества в данном случае принято плевать. - "На переходе от СССР к РФ я наблюдал лично многих людей. И наблюдал издали медийных персон. Перерождение было потрясающее."
Это на тему того, что поведение человека определяется не ртолько его внутренними качествами, но и внешней ситуацией. Т.е. качество работы программиста определяется не тотлько его знаниями и трудолюбием — но и тем, какую задачу перед ним ставит менеджер (т.е. — - за что наказывает, за что поощряет). Капитализм умеет прощать ошибки — даже при том, что они нанесли огромный ущерб. А значит — поощряет к безответственности и разгильдяйству.
PS: Забавны местные минусующие. Возразить по теме им явно нечего — они просто не хотят читать неприятную правду.
Если бы они считали, что я говорю неправду — они бы возразили. Но возражений нет. Видимо, они сами понимают, что я прав.
Ну и все, я так понимаю, знают, что здесь от кармы зависит возможность размещать комментарии.
Мысли свои озвучиваешь вслух. Но про дебилов молчишь, конечно, все-таки культурный человек. Но на лице все написано.
Чаще встречал не такое «озвучивание мыслей», а вопросы вроде «Ребят, а чего вы на второй версии сидите? И почему не пользуетесь вот этой клёвой фишкой?»
В результате либо получаешь объяснение и понимание, либо оказывается, что просто некому было взяться за внедрение (нет опыта, нет времени etc) – и вот он, твой звёздный час, ты уже не джун-подмастерье-пятачок-за-пучок, а ценный (и уникальный!) член команды.
Ага, тебе и перепиливать все со 2 на 3 версию, такому молодцу! Инициатива бывает наказуема.
Джуны не задают такие вопросы, за неимением опыта. Зато в такой конторе джуны превратятся в тех, кто умеет писать легаси и код лапшу.
Или получаешь сопротивление, ибо и без того в проекте присутствует зоопарк различных технологий, в котором у каждого модуля множество кода на разных языках с историей лет в 10-15, и каждое подобное действие только увеличит этот зоопарк…
Невозможно в такой теме не упомянуть эффект Даннинга-Крюгера.
конечно же в связке с «синдромом самозванца».
мне лично удобнее просто напоминать себе о них время от времени
конечно же в связке с «синдромом самозванца».
мне лично удобнее просто напоминать себе о них время от времени
> Во-первых, для сборки фронтенда у нормальных людей давно уже используется Webapck, на худой конец Gulp
Нет. У нормальных людей на dev все работает без сборки и излишних усложнений.
Нет. У нормальных людей на dev все работает без сборки и излишних усложнений.
Прекрасная иллюстрация к статье
Странно, мне использование сборки в dev окружении всегда казалось оверинжинирингом и решением проблем, которых изначально быть не должно.
То есть LESS или там SASS, JSX и Typescript — это тоже «оверинжиниринг и решение проблем, которых изначально быть не должно»?
Не подскажите, где найти такой веб, где решаемых этими инструментами проблем не существует? :-)
Не подскажите, где найти такой веб, где решаемых этими инструментами проблем не существует? :-)
Вы пишите очень правильную вещь. Для вакуума. Проблема в том, что вы ничего не знаете о ситуации. В комментарии выше, вам наглядно показали, что могут быть случаи когда сборка необходима.
Несколько раз оказывался в позиции когда видишь что творится форменный неадекват. Спрашиваешь а почему? Узнаёшь: "а потому". По сути нехватка квалификации, легаси, лень, работа наотвали и многое другое. Предлагаешь взвешенное решение. Спорят. Аргументируешь свою позицию. Соглашаются. Всех собак и реализацию вешают на тебя. Реализуешь. Благодарят. Главное всё сделать аккуратно, мягко и без оскорблений. Конфликты совсем ни к чему.
Ну и если по всем пунктам везде дичь, то это хороший повод задуматься: а не пойти ли мне туда, где дичью буду я, а не наоборот. В ту контору, где мои стандарты качества малы. Где дяди и тёти с большими головами научат тебя великому… Ой, что-то меня понесло.
Ну я к тому, что хорошо когда ты в окружении тех, кто умнее. А не наоборот. Хотя сопли пузырями уже пускать не получится. И задачи будут сложными. Но ведь в этом и весь кайф, разве нет?
Сначала ищешь компанию с большими головами, чтобы научиться. Потом ищешь с большими проблемами и большими деньгами, чтобы обменять опыт на значимость, карьеру, и материальные ценности…
Меня за реализацию одной такой вещи оштрафовали, и даже не потому, что что-то сломалось, а просто «изменений много, кто это тестировать будет?!». В итоге вместо одного комплексного решения было решено сделать 114 костылей. Как раз по 10 костылей на задачу, на пару недель тасками занят. Хотя одно корректное решение заняло 3 дня и было уже готово, но…
Хм, за предложение «Python заменить на Go» в уже в развившемся проекте, вполне можно выйти на свежий воздух до окончания испытательного срока)
А почему, собственно? Если там python2, то переход на Go может оказаться сравнимым по сложнрости с переходом на python3, а отдача больше…
Автор в статье как раз и отвечает на ваш вопрос и достаточно подробно)
Потому что вы хотите заниматься «интересными» на ваш взгляд вещами и развлекаться, либо учиться за счет работодателя, либо набивать резюме, а не работать и приносить компании прибыль. Развлекайтесь в свободное от работы время, пожалуйста.
Если для разработки был выбран Питон, то наверно, в этом есть причины — более высокая скорость и низкая цена разработки, наличие готовых отлаженных библиотек и инструментов.
Если для разработки был выбран Питон, то наверно, в этом есть причины — более высокая скорость и низкая цена разработки, наличие готовых отлаженных библиотек и инструментов.
Очень может быть, что 10 или 20 лет назад это и был хороший выбор. Вот только в 2020м он эта… всё, кончится. И пора на что-то другое переходить.
Вариант «перейти на Go» не выглядит априори хуже, чем вариант «перейти на python3»
Вариант «перейти на Go» не выглядит априори хуже, чем вариант «перейти на python3»
Вот только в 2020м он эта… всё, кончится.
Что именно кончится?
Python 2… тут счётчик секунды отсчитывает…
Закончится не питон а его официальная поддержка, разве нет? Интерпретатор не самоуничтожится на всех системах в 2020 и никто не запретит писать на нем и дальше.
Уфф, да и мир праху его. Основная масса перешла уже на третий питон.
К тому же третий подпилили, и переносить проекты уже не так больно как два-три года назад.
Ну и добавлю тоже, переход со второго на третий, несопоставим по издержкам с переходом на Go.
К тому же третий подпилили, и переносить проекты уже не так больно как два-три года назад.
Ну и добавлю тоже, переход со второго на третий, несопоставим по издержкам с переходом на Go.
Основная масса перешла уже на третий питон.Основная масса? Откуда статистика? Из проектов, с которыми сталкиваюсь я: Android — In order to use repo, please install Python 2.x, Chromium — You must have Git and Python v2 installed already…
Ну и добавлю тоже, переход со второго на третий, несопоставим по издержкам с переходом на Go.Сопоставим, к сожалению. Беда в том, что если у вас не скриптик на 20 строк, а большой проект, то вы не можете одномоментно переехать сразу со 2го на 3й. Вам нужна версия, которая работает с двумя питонами сразу.
Это, в общем-то возможно сделать — но требует изучение третьего, причём очень специфического диалекта.
Альтернатива — разбить всё на две части (python2 и python3), связать их через RPC и потихоньку перетаскивать функционал. Но если идти этим путём — то уже можно и на любой другой язык перейти.
Из проектов, с которыми сталкиваюсь я
Это скрипты сборки, им тупо лень, а учитывая что замороженную версию Python 2.7 никто стирать не будет из интернетов, все обойдется.
Реально используемые в проектах модули и библиотеки в основном переписали, во всяком случае я не сталкивался с отсутствием поддержки третьего питона в либах уже года два. Сам давно пишу на третьем.
Это, в общем-то возможно сделать — но требует изучение третьего, причём очень специфического диалекта.
Да кто вам сказал такое?) Ситуация давно уже не та, недавно очень большой проект переводил со второго на третий. После отработки конвертирующей утилиты остались только строчек 10 где юникодные строки не совсем принятым образом были описаны, и то все это сразу выпало в ошибки и было быстро исправлено.
Насчет перехода с Python на Go. Прокрутите в голове два сценария (Вы тимлид, или того хуже CTO, владелец):
- Ваши программисты тупо не захотели изучать Go
- Ваши программисты захотели, изучили и пригрозили уволится если не прибавите 30% ЗП, и это не пустые слова учитывая дефицит гошников на рынке.
Ваши действия?
Если программисты требуют просто за использование Go «прибавку к зарплате» — то это значит, что, по их мнению, переход на Go бессмысленнен. Соответственно в этом случае он и не состоится. Тут всё просто.
Однако я не очень понимаю откуда возьмутся программисты «тупо хотящие изучать python3» и при этом «тупо не хотящие изучать Go».
Однако я не очень понимаю откуда возьмутся программисты «тупо хотящие изучать python3» и при этом «тупо не хотящие изучать Go».
Программисты могут потребовать прибавки просто потому, что гоошники сейчас получает больше чем питонеры. А они же ведь теперь Go знают) Логика проста.
Однако я не очень понимаю откуда возьмутся программисты «тупо хотящие изучать python3» и при этом «тупо не хотящие изучать Go».Мы же вроде говорим про тех кто раньше писал на Python 2, нет? Скорее всего они уже знают отличия третьего от второго, и даже что-то писали га третьей версии. А Go — это другой язык, с другой парадигмой, и кучей всяких неоднозначностей в синтаксисе. Я вообще не пойму, все не только мне да и все пишите в том ключе, как будто Python2 и Python3 разные языки программирования.
Скорее всего они уже знают отличия третьего от второго, и даже что-то писали га третьей версии.Непонятно — откуда. Если у них в проекте только Python2, то они вполне могут ничего про Python3 и не знать.
Программисты могут потребовать прибавки просто потому, что гоошники сейчас получает больше чем питонеры. А они же ведь теперь Go знают) Логика проста.Точно так же можно вашу логику обратить и сказать, что переход на Go сделает их более ценными сотрудниками для следующего работодателя — потому можно согласится с тем, что на текущем месте они его изучат бесплатно (в надежде «отбить» затраты своего времени в будущем).
Я вообще не пойму, все не только мне да и все пишите в том ключе, как будто Python2 и Python3 разные языки программирования.Потому что я не могу взять программу на Python2 и просто взять её и перенести на Python3.
Например если это работа с сетевыми протоколами, то это смесь US-ASCII с произвольными байтами. Строки на Python2 это отлично пережёвывают, строки на Python3 — нет. Да, в послдених версиях Python3 стало получше, но ощущение того, что это другой язык — не пропало, увы. Несовместимых изменений слишком много.
А Go — это другой язык, с другой парадигмой, и кучей всяких неоднозначностей в синтаксисе.Да, но он, по крайней мере, этого не скрывает.
Я вот читаю ваш спор, и как человек очень далёкий от питона, недоумеваю. Вы так рассуждаете о разнице между python2 и python3, как будто это словно разница между java и javascript. Или там и правда настолько сильно всё перепахали, что учить учить и не переучить?
Или там и правда настолько сильно всё перепахали, что учить учить и не переучить?Там изменили небольшую часть. Но критически важную — работу со строками. Причём изменили самую суть: если в Python2 вы могли взять случайную последовательность байт — и работать с ней, как если бы это была строка… то в Python3 от вас требуют «правильную строку» из кодпоинтов. А на практике вы это, зачастую узнаёте «по ходу», уже начав работать со строкой (к примеру HTML и meta charset)
При этом, что характерно в Go очень много оличий от питона… но вот как раз принципы работы со строками — там похожи на Python2.
Потому и получается странная дилемма: изучить Python3 для человека, знающего Python2 несложно, а вот переписать готовы код — увы, нет. А с Go — всё ровно наоборот.
Правда тут нужно учитывать, что это всё так пока у вас много своего кода. Сторонние же библиотеки, зачастую, для Python3 похожи на библиотеки от Python2, но непохожи на библиотеки от Go. Если у вас много сторонных библиотек, уже переписанных на Pyehton3, то переход на Python3 будет разумнее.
В итоге: переписывание с Python'а на Go — это действительно не всегда разумно… но точно то же самое можно сказать и про переход с Python2 на Python3.
Несовместимых изменений слишком много.
Что кроме строк?)
Куча всего по мелочи. Всякие
Я сейчас не говорю о том сделало ли это язык лучше или хуже — это сделало его несовместимым, из-за чего, собственно, все проблемы.
printы и range, sort (потерявший cmp) и map (возвращающий итератор, а не список) — и куча всего ещё.Я сейчас не говорю о том сделало ли это язык лучше или хуже — это сделало его несовместимым, из-за чего, собственно, все проблемы.
Все перечисленное конвертируется утилитой 2to3.
Во-первых не всё (
То есть вы получаете неработающий полуфабрикат (смотри пункт 1), который нельзя даже пытаться запускать не отконвертировав вообще всё (смотри пункт 2). Восхитительно!
cmp, скажем, не конвертируется, ибо это не так-то просто сделать и руками), а во-вторых, что куда хуже, код, обработанный 2to3 больше нельзя запускать под python2!То есть вы получаете неработающий полуфабрикат (смотри пункт 1), который нельзя даже пытаться запускать не отконвертировав вообще всё (смотри пункт 2). Восхитительно!
Простите, но вы гениально высасываете проблемы из пальца))
Простите, но это не моё изобретение, а простое объяснение причин того, что переход с C++98 на C++11 у нас занял пару лет и скоро закончится переход на C++17, а вот python3 используется ещё очень мало где, большинство команд используют python2 и переходить на python3 пока не планируют, а кое-кто перешёл на Go.
Вы можете продолжать жить в своём мире розовых поней, но я, пожалуй, останусь в серой реальности.
Вы можете продолжать жить в своём мире розовых поней, но я, пожалуй, останусь в серой реальности.
Ага, полностью заменить язык в уже существующем проекте.
Т.е. менять окружение нa котором код работает / искать сопоставимые библиотеки / заново настраивать сборку / переписывать всю логику и тесты / фиксить новые баги / тестировать, тестировать, тестировать… По сути написать весь проект с нуля.
Нефиговое такое предложение от «новенького» сотрудника.
Т.е. менять окружение нa котором код работает / искать сопоставимые библиотеки / заново настраивать сборку / переписывать всю логику и тесты / фиксить новые баги / тестировать, тестировать, тестировать… По сути написать весь проект с нуля.
Нефиговое такое предложение от «новенького» сотрудника.
Ну так вам всё равно придётся всё это делать — так не лучше ли начать когда у вас есть выбор — делать сегодня или завтра? И не доводить ситуацию до покупки систем 10-летней давности с рук на eBay (как НАСА с системами, обслуживающими Шаттлы приходилось делать)?
И да — как раз это логично делать новому сотруднику: для него это системы не являются «старыми, проверенными», так что ему всё равно в них придётся разбираться… можно и воспроизвести логику на другом языке «для закрепления»
И да — как раз это логично делать новому сотруднику: для него это системы не являются «старыми, проверенными», так что ему всё равно в них придётся разбираться… можно и воспроизвести логику на другом языке «для закрепления»
Ну так вам всё равно придётся всё это делать — так не лучше ли начать когда у вас есть выбор — делать сегодня или завтра?
Почему все равно придется это делать? Python2 перестанет работать нa новом железе в 2020? К тому же переход на 3й питон все-таки значительно проще чем переход на абсолютно другой язык с другой парадигмой.
так не лучше ли начать когда у вас есть выбор — делать сегодня или завтра
Зависит. Если бизнесу нужны фичи, a вы тут такой в белом пальто «давайте все перепишем лучше», то вас с этим предложением скорее всего пошлют, и будут правы.
И да — как раз это логично делать новому сотруднику: для него это системы не являются «старыми, проверенными», так что ему всё равно в них придётся разбираться… можно и воспроизвести логику на другом языке «для закрепления»
Вы работали на крупных проектах в которых работает несколько человек? Я пару месяцев назад начал работать на довольно большом проекте и я до сих пор не знаю некоторых моментов в бизнес логике. Проекту 3-4 года, там большe 100к строк кода и он разбит на несколько репозиториев. Физически невозможно все это «с наскока» изучить и знать все детали.
К тому же, раз взяли нового сотрудника, значит проект растет (либо кто-то ушел), значит нужны руки. В проекте скорее всего есть фичи и баги над которыми надо работать прямо сейчас, а не ждать несколько месяцев пока новый сотрудник все перепишет.
а не ждать несколько месяцев пока новый сотрудник все перепишетЕсли бы несколько месяцев да один сотрудник, то еще нормально, такие деньги у взрослого бизнеса обычно есть. Обычно это несколько иные сроки.
Ну понятно, что один сотрудник не сможет навести порядок сразу во всём проекте. И вовсе не факт, что ему дадут возможность «наводить порядок» там, где ему кажется, что всё страшнее всего.
Скорее всего у тех, кто знаком с проектом дольше будет другое понятие о том, что нужно чистить в первую очередь.
Но бросать нового человека на «горящие» и «критические» фичи — это феерический бред.
Скорее всего у тех, кто знаком с проектом дольше будет другое понятие о том, что нужно чистить в первую очередь.
Но бросать нового человека на «горящие» и «критические» фичи — это феерический бред.
Зависит. Если бизнесу нужны фичи, a вы тут такой в белом пальто «давайте все перепишем лучше», то вас с этим предложением скорее всего пошлют, и будут правы.Если «бизнесу» нужны фичи примо «здесь и сейчас» и он для этого вас нанял — то это значит, что «бизнес» понятия не имеет о том, как разрабатывается софт и для вашего же душевного спокойствия лучше с ним больше не общаться. Да, просто закинуть объявление и начать искать другую задачу.
Вы работали на крупных проектах в которых работает несколько человек? Я пару месяцев назад начал работать на довольно большом проекте и я до сих пор не знаю некоторых моментов в бизнес логике.Об этом и речь — ещё у классиков об этом писали: если вы добавляете на проект человека и ожидаете немедленной отдачи — вас ждёт разочарование.
Новый человек — это работа на перспективу. Всегда.
В проекте скорее всего есть фичи и баги над которыми надо работать прямо сейчас, а не ждать несколько месяцев пока новый сотрудник все перепишет.Худшее, что можно сделать с новым человеком — кинуть его на амбразуру и поручить ему фичи, от которых зависит судьба проекта в ближайшие месяц-другой.
Гораздо лучше — поручить ему что-то от чего в будущем может быть хорошая отдача, но что не развалит проект в случае неудачи. Переход на другую библиотеку/язык/etc (о котором «давно говорили, но не было времени») — как раз сюда относится…
Разумеется не нужно давать новчику «карт-бланш». И на наивный вопрос «а почему тут до сих пор Python2» хороши бы иметь ответ.
Но ответ «бизнесу нужны фичи, нам некогда рефакторить код» — наихудший из возможных.
Мы начинали обсуждение с полного переписывания проекта на другой язык. Понятно что отрефакторить небольшую часть проекта — это нормальное задание для нового сотрудника, но давайте не будем передергивать.
Никто не ждет от «новеньких» немедленной отдачи и не будет сразу кидать их на жизненно-важные фичи. Но ждать несколько месяцев пока человек там разбирается в отрыве от основной команды тоже никто не будет.
Может это вы понятия не имеете о том как работает бизнес? Все-таки он вас нанял, а не наоборот.
Возможно, но в реальной жизни так бывает довольно часто.
Никто не ждет от «новеньких» немедленной отдачи и не будет сразу кидать их на жизненно-важные фичи. Но ждать несколько месяцев пока человек там разбирается в отрыве от основной команды тоже никто не будет.
Если «бизнесу» нужны фичи примо «здесь и сейчас» и он для этого вас нанял — то это значит, что «бизнес» понятия не имеет о том, как разрабатывается софт и для вашего же душевного спокойствия лучше с ним больше не общаться.
Может это вы понятия не имеете о том как работает бизнес? Все-таки он вас нанял, а не наоборот.
Но ответ «бизнесу нужны фичи, нам некогда рефакторить код» — наихудший из возможных.
Возможно, но в реальной жизни так бывает довольно часто.
Но ждать несколько месяцев пока человек там разбирается в отрыве от основной команды тоже никто не будет.
Не совсем, когда берут стажеров, по крайней мере у нас, это вполне обычно.
Может это вы понятия не имеете о том как работает бизнес? Все-таки он вас нанял, а не наоборот.Я не знаю как работает бизнес, но я знаю как работает разработка программ. Бизнес же обязан учитывать эти реалии.
Как нельзя нанять людей, которые будут натягивать навесные потолки пока у вас не залит фундамент, так нельзя нанимать новичков в надежде заткнуть ими «горящие» дыры. Это просто физика проуесса и на какое «знание бизнеса» её не изменит.
Я не знаю как работает бизнес, но я знаю как работает разработка программ. Бизнес же обязан учитывать эти реалии.
Наоборот. Разработчики должны учитывать реалии бизнеса. Когда люди будут платить просто за то что вы пишете клевый код — вы будете правы, но пока мы вроде как решаем бизнес задачи.
так нельзя нанимать новичков в надежде заткнуть ими «горящие» дыры
Про «горящие дыры» это вы сами придумали. Я говорил просто про фичи и баги, которые сейчас нужно закрывать. В проекте, который находится в активной разработке, они всегда есть.
Наоборот. Разработчики должны учитывать реалии бизнеса.Нет. Разработчикам точно так же наплевать на «реалии бизнеса», как каменотёсам или уборщице. Они выполняют свою работу — так как умеют, не халтуря — а «бизнес» платит им зарплату. Учитывать реалии бизнеса они будут тогда, когда будут владеть своим бизнесом. Кому-то это нравится, кому-то нет, но не нужно перекладывать свою задачу на других.
Я говорил просто про фичи и баги, которые сейчас нужно закрывать.Чем они отличаются от «горящих»?
В проекте, который находится в активной разработке, они всегда есть.Конечно — но их нельзя поручать новичку. Так же, как вы не поручите только что нанятому иниженеру рассчёт какого-нибудь нестандартного моста, так и только что нанятому разработчику нельзя поручать задачи, от успешного «закрытия» которыз зависит немедленная судьба проекта.
Я не знаю как работает бизнес, но я знаю как работает разработка программ. Бизнес же обязан учитывать эти реалии.
Нет. Разработчикам точно так же наплевать на «реалии бизнеса», как каменотёсам или уборщице.
А как вы решаете проблемы бизнеса не имея понятия о его проблемах? Или вы не решаете проблемы бизнеса?
А как вы решаете проблемы бизнеса не имея понятия о его проблемах? Или вы не решаете проблемы бизнеса?Я не решаю проблемы бизнеса — я решаю (или не решаю) поставленные бизнесом передо мной задачи. И отвечаю только за те обещания, которые я дал кому-то. А не за то, что кто-то кому-то пообещал от моего имени.
Я очень хорошо помню совещание, где наш финансовый директор объяснял «как устроена жизнь». И там был пассаж (обращённый меньше к нам и больше к отделу маркетинга): «для того, чтобы деньги поступили на счёт контрагента на этой неделе заявка должна быть внесена в систему не позднее 8 частов утра в понедельник». И после этого добавление: «если вам нужно, чтобы деньги были перечислены через два дня, а иначе у вас сорвётся важное мероприятие (тут весь отдел маркетинга затаил дыхание), то… ваше мероприятие сорвётся, а мы вам посочуствуем… очень-очень посочувствуем...».
Каждый должен хорошо делать своё дело и не пытаться лезть туда, где он некомпетентен, вот и всё.
Я не решаю проблемы бизнеса — я решаю (или не решаю) поставленные бизнесом передо мной задачи.
А вы вообще зачем бизнесу понадобились? С какой целью он ставит вам задачи? Какого рода он ставит задачи? На каком языке он их описывает? Почему он вам платит деньги? Зачем ему вообще ставить вам задачи? Интересна ваша логика. Люди любых профессий решают проблемы реального мира. Какие проблемы в таком случае решаете вы?
Люди любых профессий решают проблемы реального мира.Что вы подразумеваете под «реальным миром»? Тот, который можно пощупать? Тогда какие вещи, которые можно пощупать, порождает бухгалтер? И на каком языке они описываются?
Почему он вам платит деньги? Зачем ему вообще ставить вам задачи?Очевидно, что это связанные вопросы и ответ — такой же, как в случае с каменотёсам или уборщицей: потому что для бизнеса дешевле нанять меня, чем самому разбираться в том, как пишутся программы (я не говорю, что я уникален, нет, любой бизнесмен сможет научиться писать программы хоть на C++, хоть на PHP… если потратит на это несколько лет).
Какого рода он ставит задачи? На каком языке он их описывает?Очевидно, что задачи ставятся на языке, который должен быть понятен нам обоим. Обычно это некоторый компромисс между тем, как могу сформулировать задачу я и тем, как её видит бизнес. В мелких компаниях — бизнесмену приходится немного изучать язык программистов, а программистам — язык каменнотёсов или токарей (в зависимости от того, чем бизнес занимается), в крупных этому делу может помочь PM.
А вы вообще зачем бизнесу понадобились? С какой целью он ставит вам задачи?А это извините, уже не моё дело.
Вот рассмотрите какую-нибудь реальную задачу. Там будет много про осцилографы, удалённый доступ к самосвалу и прочие интересные штуки — но там ничего не будет про то, как бизнес будет добывать деньги на оплату всех этих покатушек и там не будет обсуждения рентабельности всей затеи в зависимости от сроков исполнения проекта.
Потому что это не моё собачье дело. Моя задача — оценить (по возможности точно) затраты на ту или иною фичу, которую от меня хотят и указать — кто и когда её может сделать. Также немаловажно — оценить как это повлияет на другие фичи (ибо про это бизнес склонен забывать). А уж стоит ли её делать в таком раскладе или нет — вопрос не ко мне.
Тогда какие вещи, которые можно пощупать, порождает бухгалтер? И на каком языке они описываются?
Например он рассчитывает вашу ЗП (руководствуясь законами и мат аппаратом) которую вы потом можете пощупать. Не понимая из чего складывается ваша ЗП он насчитает вам полную фигню. На человеческом: «Рассчитайте пожалуйста ЗП нашему программисту за текущий месяц».
потому что для бизнеса дешевле нанять меня, чем самому разбираться в том, как пишутся программы
А зачем вообще ему понадобились какие то там программы? Что они ему дадут? Ему просто деньги не куда девать? Вы утверждаете что не решаете проблем бизнеса. Но зачем бизнесу программы? Объясните? Зачем мне уборщица, если у меня чисто? Зачем мне камнетес, если я использую дерево? Вопрос не в том, чье это дело, вопрос в том зачем вас бизнес нанял. Отвечая на вопрос «Это не мое дело», вы просто уходите от очевидного ответа.
А очевидный ответ тако: Он вас нанял, чтобы решить с помощью вас какие то свои проблемы. Именно бизнес ставит перед вами задачи (Вы сами это сказали). Отсюда очевидно следует что вы решаете проблемы бизнеса, хотите вы это осознавать или нет. Других причин нанимать вас и платить вам деньги нет. Если бы у него не было этих проблем, не было бы смысла ставить вам задачи и вообще вас нанимать.
Отсюда очевидно следует что вы решаете проблемы бизнеса, хотите вы это осознавать или нет.С таким же успехом можно сказать, что автомеханик, меняя колесо в машине Фон Брауна решал задачу доставки человека на Луну. Ну потому что без машины, которую ему бы починили Фон Браун не смог бы добраться дл работы и сделать свой Сатурн.
И, точно также, как автомеханика не волнует кто и куда поедет на отремонтированной им машине — так же и меня не волнует для чего бизнесу нужно то или иное изменение в программе, которое он попросил меня сделать.
Ну вот простой пример: если мы писали всё программу на Java, а бизнесу вдруг потребовалась версия на C#, то мне неважно — почему вдруг так. Моя задача оценить — сколько человек и времени для этого потребуется. А дальше — бизнес пусть решает, хочет он за это платить или нет.
Отвечая на вопрос «Это не мое дело», вы просто уходите от очевидного ответа.Нет. Я не ухожу от ответа — я его выношу за скобки. Если вот то самое переписывание на C# бизнесу нужно сделать за месяц, а по моим оценкам оно займёт месяца четыре — то я не собираюсь рвать на себе волосы или сидеть по ночам из-за того, что наш продукт нельзя показать важному заказчику.
Я это очень хорошо понял на одной из моих первых работ, когда от меня попросили сделать «простенькую формочку» для забивания каких-то данных. А потом оказалось, что эти данные нужно не просто вбивать, но и искать по ним (а зачем нам данные в базе если искать нельзя?), а также сохранять возможные критерии поиска (но иначе же мы никакой экономии не получим, наша табличка в Excel так умеет, а ваша база почему-то нет), а ещё там будет пользователей несколько (но у нас же несколько подразделений — куда же без этого) и так далее.
Одного раза — хватило. С тех пор я чётко придерживаюсь правила: ни при каких условиях не браться за работу, под которую я не подписывался. И мне пофиг — что там у бизнеса в результате произойдёт. Если бизнес хочет изменить требования — нужно менять оплату и, обязательно, сроки.
Я вам про цель, вы мне про (неадекватные) сроки. Я вас понял. Останемся каждый при своем мнении. Я как программист решаю проблемы бизнеса, вы их не решаете. Главный критерий все равно один — результат.
Главный критерий все равно один — результат.Вот только критерии разные. Если мы говорим о том самом переписывании на C#.
Если мы запланировали версию на C# через полгода, а я за месяц отконвертировал только базовые классы и юнит-тесты, то с моей точки зрения — всё хорошо, я сделал адеватную часть работы.
А с точки зрения — произошла полная катастрофа: у него через месяц была назначена встреча с потенциальными инвесторами — и там нужно было что-то показать. А показывать-то и нечего.
Я вам про цель, вы мне про (неадекватные) сроки.Это связанные вещи. Сравните с автомехаником. Вы «уграли машину в ноль» и привезли её на грузовике в ремонт. Вам говорят: «двигатель — усё, тут нужно капиталку делать». Так вот если вы на это подписались — то не вина механика в том, что через три дня вы собрались ехать на дачу, а машина разобрана!
Можно было бы договориться о том, чтобы в двигателе заменили бы, по-быстрому, клапана, вы бы съезли на дачу, а уж потом — делали капиталку… но это должен быть ваш выбор, не выбор автомеханика!
То же самое и с программами: я не решаю проблемы бизнеса — я решаю проблемы, которые бизнес передо мною поставил и которые, что важно, я принял.
То же самое и с программами: я не решаю проблемы бизнеса — я решаю проблемы, которые бизнес передо мною поставил и которые, что важно, я принял.
Это тавтология. Проблемы которые бизнес перед вами поставил это и есть проблемы этого самого бизнеса.
1) Бизнес не ставит вам задачу: Хоту разработать приложение на С# состоящее из нескольких модулей, с REST API и интерфейсом на Angular, работающем в облаке Google.
2) Бизнес приходит и говорит: Вы профессионал, я не знаю как и что там делать, но мне нужна от вас CRM система, или приложение для расчета налогов, или приложение для прогнозирования погоды.
Вы меня убеждаете в том, что вы занимаетесь тем что написано в пункте 1), я говорю о том, что вы по факту занимаетесь тем что написано в пункте 2). Хотите вы этого или нет, ваши абстрактные кони в вакууме ни кому не нужны и платят вам не за это.
Бизнесу/заказчику/людям пофигу как там оно устроено внутри и из чего состоит. Это вообще не их головная боль. Они хотят чтобы то что вы для них делаете решало их реальные проблемы.
И мы вообще сейчас не рассматриваем вопрос приняли вы что-то или нет. Как вам будут оплачивать работу Приняли, делаете, не приняли, делает кто-то другой.
Вот только критерии разные. Если мы говорим о том самом переписывании на C#.
К слову бизнес не ставит таких задач. Они не знают что такое C#. Если вам ставят такие задачи, то вам их ставит не бизнес а какая то менеджерская прослойка, которая понятия не имеет о чем она говорит. Выбор технологий вообще дело не бизнеса а технарей исходя из требований этого самого бизнеса.
Это связанные вещи. Сравните с автомехаником. Вы «уграли машину в ноль» и привезли её на грузовике в ремонт. Вам говорят: «двигатель — усё, тут нужно капиталку делать». Так вот если вы на это подписались — то не вина механика в том, что через три дня вы собрались ехать на дачу, а машина разобрана!
Можно было бы договориться о том, чтобы в двигателе заменили бы, по-быстрому, клапана, вы бы съезли на дачу, а уж потом — делали капиталку… но это должен быть ваш выбор, не выбор автомеханика!
Моя проблема здесь как «бизнеса» — Машина не едет, а я хочу чтобы она поехала. И именно эту задачу решает автомеханик. Все остальное детали, которые к нашей дискусси не имеют никакого отношения.
Бизнес часто не может оценить адекватно сроки — да
Бизнес часто не знает что должно получиться в итоге — тоже да.
Бизнес иногда лезет с нравоучениями (типа делай на вот этом) — да такое бывает.
Я с этим с вами не спорю. Это все есть, я с этим согласен но это вообще о другом. Все эти вопросы закрываются экспертным мнением (вашими условиями и мнением как исполнителя).
Но бизнес как правило всегда знает, каких целей он хочет достичь вашими руками. И именно для этого вы ему нужны, чтобы он достиг своих целей и решил свои проблемы, а не те которые вы себе придумали.
2) Бизнес приходит и говорит: Вы профессионал, я не знаю как и что там делать, но мне нужна от вас CRM система, или приложение для расчета налогов, или приложение для прогнозирования погоды.Извините — но мне он этого не говорит. Он либо говорит моему PM'у, либо сам работает PM'ом если компания маленькая.
Они хотят чтобы то что вы для них делаете решало их реальные проблемы.Это их законное желание — но это не то, под чем я подписываюсь.
1) Бизнес не ставит вам задачу: Хоту разработать приложение на С# состоящее из нескольких модулей, с REST API и интерфейсом на Angular, работающем в облаке Google.Вот именно так и только так он её и ставит. Сам или с чьей-то помощью — меня не волнует. В некоторых условиях я могу ему помочь составить задачу в подобных терминах — но и только.
Хотите вы этого или нет, ваши абстрактные кони в вакууме ни кому не нужны и платят вам не за это.Когда-то, много лет назад, я соглашался с подобными доводами. Но те времена — давно прошли. Сейчас я просто не буду подписываться на задачу класса 2). Это — не то, что я умею делать и это — не мои проблемы. Её нужно сначала свести к задаче класса 1), а потом уже заниматься чем-то ещё.
К слову бизнес не ставит таких задач.Ставит. Я этот пример не придумал. Он более, чем жизненный.
Они не знают что такое C#.В моём случае речь шла о CEO и разговоре/демонстрации потенциальным инвесторам. И о том, что такое C# и Java знали как те, так и другие. Да, они знали о них на уровне «наши подрядчики работают с C# и не работают с Java» — но они об этом знали и для них это было важно.
Если вам ставят такие задачи, то вам их ставит не бизнес а какая то менеджерская прослойка, которая понятия не имеет о чем она говорит.Ну… если владельца фирмы отнести к «менеджерской прослойке»…
Выбор технологий вообще дело не бизнеса а технарей исходя из требований этого самого бизнеса.Зависит от бизнеса, извините. Но если бизнес большой и там есть «менеджерская прослойка», способная это делать… этот подход тоже годится.
Моя проблема здесь как «бизнеса» — Машина не едет, а я хочу чтобы она поехала.Возможно — но это бизнес-задача только если вы, как бизнес, предоставляете машины в прокат. В противном же случае бизнес-задача будет другая. Ну, скажем «отвезти руководителя на встречу» или «доставить запчасти в удалённое подразделение». Но механику наплевать на ваши запчасти и ваших руководителей. Ему важно знать — будете вы оплачивать расточку клапанов или полную переборку двигателя. В обоих случаях «машина поедет», вот только в первом случае он встанет через 200 км, а во-втором — сможет ещё несколько тысяч километров отмотать. Однако первое можно сделать за день-два, а на второе потребуется пара недель. И вот механик выкладывает на стол эти варианты — а дальше уже бизнес решает какой ему подходит.
Ровно то же самое происходит с программистами. А попытки сформулировать задачу в бизнес-терминах и этим ограничиться следует пресекать — ничем хорошим это не кончается.
И именно для этого вы ему нужны, чтобы он достиг своих целей и решил свои проблемы, а не те которые вы себе придумали.С этим я не спорю. Я спорю с тем, что меня, с какого-то перепугу, всё это должно волновать.
Если вместо разумного ответа отправляют на воздух, то это не так плохо: иначе пришлось бы там работать.
Если сильно хочется, то лучше зайти с фразы: «А не думали ли вы о Go». Просто к моменту вашего появления этот вопрос наверняка поднимался и было сломано куча копий. Поэтому ваше радикальное предложение во всем белом, может вызвать мягко говоря негативную реакцию.
А если они от вас услышали о существовании Go и вообще, то да, работать возможно и не надо там.
А если они от вас услышали о существовании Go и вообще, то да, работать возможно и не надо там.
На практике оно означает: попробуй сначала понять, что происходит, а уже потом начинай критиковать и предлагать решения.Общепринятое название этого принципа — Chesterton's fence
Все правильно, но… Есть два варианта. Один, когда люди тебе объясняют почему все именно так, почему были приняты такие решения и чем они были обоснованы. В таком случае скорее всего появится адекватное решение. А второй вариант: "- Так исторически сложилось.". И тут невольно все равно начинаешь задумываться. Ну т.е. ок, я идиот и не разобрался до конца. Но что значит эта фраза? Почему вы не хотите раскрывать, как и зачем были приняты те или иные решения. В прочем да, люди по большей части не идиоты.
Почему вы не хотите раскрывать, как и зачем были приняты те или иные решения
Странный коммент. Разве не понятно? Питон 2, потому что на нем написано сотни тысяч строк кода, а для переписывания нету времени — вечные дедлайны.
Как-то один человек подошел ко мне и сказал за полгода до релиза игры, которую мы писали в течении трех лет большой фирмой: «этот фреймворк уже не модный, давай перейдем на другой фреймворк, может какие плюшки интересные будут». Вот что у такого человека в голове творится? У нас есть игра в бете, в которую уже играют тысячи людей, которая работает и соответствует желанию дизайнеров. И за полгода до релиза он предлагает перейти на другой фреймворк просто так. На совершенно неизвестный команде фреймворк за полгода до релиза.
Почему выбран этот фреймворк, что есть? Да, так исторически сложилось. Как вообще разница, почему? Может потому что другого впринципе не было. А может потому что в тот день лид поленился и использовал первую ссылку. Когда говорят «исторически сложилось» про такие вещи, то говорят: «какая разница почему? давай не вспоминать, почему мы приняли то или иное решение 5 лет назад, давай подумаем, как сделать продукт лучше сейчас».
Вполне адекватный прагматичный программист (если программист, конечно — если это продакт менеджер, например, то такого человека надо гнать в шею). Он пришел, чтобы обменять свое время на зарплату. Если при этом можно еще и разобраться в новом фреймворке, вообще отлично. По сути, договоренности о том, что программист «делает продукту лучше сейчас» нет, он такого никому не обещал. Утонет игра от багов — да, неприятно, надо новую работу искать (что тоже не факт) — напряг, но решаемо. Просидеть годы на немодном фреймворке — реальная проблема, которая заставит вкалывать в нерабочее время, чтобы догнать современный мир. Поэтому, у человека в голове происходят очевидные вещи — он максимизирует свой интерес.
Задача программиста — выдать качественный продукт. Да, иногда пути для менеджера непонятны. Зачем какой-то рефакторинг, если лучше фичу зафигачить? Но иногда это необходимо для выдачи качественного продукта.
Если программист готов разламать всю экосистему разработки без шанса на исправление до релиза ради сиюмитной прихоти — есть два варианта:
1. Он крайне тупой и просто не понимает, что предлагает
2. Он саботажник и ему вообще плевать, выйдет ли продукт и в каком качестве
В любом случае такого работника не пожелаю никому заполучить ни в одном предприятии. То есть именно того программиста, о котором вы говорите — который сознательно выбирает решение, которое приведет к невозможности выпуска продукта, потому что хочет за деньги работодателя потренироваться.
Вот на угольной станци кочегар перестал подкидывать уголь в печку, потому что ему слишком жарко. Плевать, что люди по городу мерзнут, он и не обещал, что сделает городу лучше сейчас. А вот то, что жарко кочегару — реальная проблема.
Если программист готов разламать всю экосистему разработки без шанса на исправление до релиза ради сиюмитной прихоти — есть два варианта:
1. Он крайне тупой и просто не понимает, что предлагает
2. Он саботажник и ему вообще плевать, выйдет ли продукт и в каком качестве
В любом случае такого работника не пожелаю никому заполучить ни в одном предприятии. То есть именно того программиста, о котором вы говорите — который сознательно выбирает решение, которое приведет к невозможности выпуска продукта, потому что хочет за деньги работодателя потренироваться.
Вот на угольной станци кочегар перестал подкидывать уголь в печку, потому что ему слишком жарко. Плевать, что люди по городу мерзнут, он и не обещал, что сделает городу лучше сейчас. А вот то, что жарко кочегару — реальная проблема.
Есть один маленький нюанс. Работа кочегара легко контролируется.
Программист в этом плане делает работу, у которой нет четких показателей эффективности, решения имеют двойное дно, да и когнитивных способностей большинства программистов хватает, чтобы придавать своим решениям благородный вид.
А мы с Вами спорим о разных вещах. Вот Вы говорите, что забить болт на бизнес, и качать скиллы — плохо. А я ведь и не спорю, что плохо, и тоже так считаю. Я говорю, что это выгодно, и не вижу программисту выгоды делать иначе.
Вот на угольной станци кочегар перестал подкидывать уголь в печку, потому что ему слишком жарко-> потерял работу в тот же день. Поверьте, если такая возможность у него была бы, то с удовольствием пользовались бы. Точно так же, как рабочие на заводах забивают втулки молотом, когда их не проверяют (факт реален, и взят не с потолка).
Программист в этом плане делает работу, у которой нет четких показателей эффективности, решения имеют двойное дно, да и когнитивных способностей большинства программистов хватает, чтобы придавать своим решениям благородный вид.
А мы с Вами спорим о разных вещах. Вот Вы говорите, что забить болт на бизнес, и качать скиллы — плохо. А я ведь и не спорю, что плохо, и тоже так считаю. Я говорю, что это выгодно, и не вижу программисту выгоды делать иначе.
Я говорю, что это выгодно, и не вижу программисту выгоды делать иначе.
Подолью масла, уж не обессудьте. Это выгодно, пока отрасль еще не сформировалась. Это выгодно, не профессионалам, т.к. можно делать из людей идиотов и при этом не напрягаясь зарабатывать неплохие деньги. О чем говорят сейчас все пионеры отрасли, такие как Мартин Фаулер, Дядюшка Боб и другие? О том, что отрасль очень молодая и профессионалов очень мало.
Выгода программисту делать иначе, заключается в том, что делая иначе он становится на путь настоящего профессионализма, который в дальнейшем спасет его карьеру. Вечно так как сейчас все равно продолжаться все равно не будет. И если посмотрите, к примеру всякие «конструкторы сайтов» уже отнимают некоторые рабочие места у низко квалифицированных кадров, которые еще 10 лет назад клепали сайт за сайтом в одиночку рисуя цифры с потолка.
Странный коммент. Разве не понятно?
Нет не понятно.
Я, когда прихожу в новую компанию, хочу конкретно знать почему и при каких условиях и обстоятельствах были приняты те или иные решения во первых. А во вторых хочу понять сам бизнес и его потребности. Из первых рук, от владельцев.
Как раз чтобы не ходить и не предлагать идиотские решения из категории: "- Все гавно, надо переделать.", а для того, чтобы понимать как с тем что уже есть жить и работать, что менять, что оставлять как есть и вообще куда двигаться и какие проблемы нужно решать.
Питон 2, потому что на нем написано сотни тысяч строк кода
Отвечу честно и прямо. По моему мнению, это вообще не аргументы.
Я сразу спрошу: А почему тогда не Java, на ней еще больше кода написано. А почему не JavaScript, на нем вообще тонны кода и куча недорогих спецов. И т. д., и т.п.
Если вы выбрали технологию исключительно из-за популярности, вы решали свои проблемы, а не проблемы бизнеса. А именно следующие:
1) Чтобы было просто найти того кто потом это будет поддерживать
2) Чтобы как можно меньше пришлось писать кода и в принципе думать
Аргументы это:
1) Потому что на момент создания продукта стояли «такие-то» задачи
2) Кол-во разработчиков было «такое», их квалификация была «такая»
3) Бюджет был «такой», выбор был среди «того то» и «того то»
4) Стратегия была «такой-то»
а для переписывания нету времени — вечные дедлайны.
В таком случае надо уходить из профессии. Потому что дэдлайны это нормально, это не повод не переписывать те или иные части системы. «Нет времени» — это про квалификацию и самоорганизацию. У бизнеса никогда нет времени, и ни когда не будет. Надо приспосабливаться к ситуации. Этот процесс итерационный. Пишешь новую фичу, увидел плохой кусок кода, сел и по пути переписал.
Есть несколько более объективных причин не переделывать тот или иной код:
1) Данный код работает и на 100% выполняет свою функцию.
2) Данный код не удорожает дальнейшее развитие продукта и не мешает идти вперед.
3) В данный момент отсутствуют необходимые для этого ресурсы.
Абстрактная фраза «Исторически сложилась», (при отсутствии желания раскрывать подробности) для меня звучит так: "- Отстань, мы тут думаем исключительно с своих личных интересах. Чем сложнее и запутаннее продукт, тем сложнее нас уволить, тем дороже обходится его поддержка, тем больше мы получим ЗП и тем увереннее будем себя чувствовать."
Я кстати тоже пару раз употреблял, эту фразу. Буквально так: «Так исторически сложилось, потому что ресурсы не позволили использовать вот это и то решение. Сейчас это дерьмо работает и выполняет свои задачи. По моим прогнозам оно не принесет проблем еще где то пол года, потом мы будем пилить фичу которая затронет это дерьмо. Если у тебя есть желание, давай сядем, подумаем над тем что с этим можно сделать и зафиксируем на бумаге. Либо отложим этот вопрос до того момента пока это дерьмо не начнет мешать»
Я сразу спрошу: А почему тогда не Java, на ней еще больше кода написано.
Нет, не вообще в мире, а вот прям в этом проекте. Питон 2 до сих пор, ибо на нем написано сотни тысяч строк кода.
Потому что дэдлайны это нормально, это не повод не переписывать те или иные части системы
Серьезно? Для вас рефакторинг — это переход на Гоу, как выше там кто-то говорил?
Вообще я понял. Вы говорите о тактических решениях, а я — о стратегических. Тем не менее даже в пяти строчках кода ответ «так исторически сложилось» иногда вполне достаточен. Это значит, что нету особых причин для именно такого подхода и вы можете предложить подход получше. Что не так?
Серьезно? Для вас рефакторинг — это переход на Гоу, как выше там кто-то говорил?
Для меня рефакторинг, это поменять имена переменных и названия методов на более выразительные. Вынести что-то в отдельный модуль и т.д. Не изменив при этом ни одного теста.
Тем не менее даже в пяти строчках кода ответ «так исторически сложилось» иногда вполне достаточен
Эта фраза без раскрытия подробностей всегда звучит как «От***бись». И это просто не профессионально.
Фраза «исторически сложилось» означает, что работает — не трогай.
Когда перестанет работать (появятся новые требования, или прекратится поддержка старой технологии, или ещё что-то) — тогда и будем переписывать.
Когда перестанет работать (появятся новые требования, или прекратится поддержка старой технологии, или ещё что-то) — тогда и будем переписывать.
В самой фразе «так исторически сложилось» ничего плохого нет, а вот в реакции на неё есть.
Подобная фраза, с моей точки зрения — это не повод оставить что-то в покое, а руководство к действию: если единственная причина — то, что кто-то поленился в своё время сделать осмысленный выбор, то это значит что выбор не поздно сделать и сейчас!
Другое дело, что нужно адекватно оценивать силы: если вы хотите начать рефакторинг, который даст вам экономию 5 строк и хотите затратить на это полгода, то вас никто умным не назовёт… а вот если можно выкинуть 500 строк кода, потратив на это пару часов работы… почему нет?
Подобная фраза, с моей точки зрения — это не повод оставить что-то в покое, а руководство к действию: если единственная причина — то, что кто-то поленился в своё время сделать осмысленный выбор, то это значит что выбор не поздно сделать и сейчас!
Другое дело, что нужно адекватно оценивать силы: если вы хотите начать рефакторинг, который даст вам экономию 5 строк и хотите затратить на это полгода, то вас никто умным не назовёт… а вот если можно выкинуть 500 строк кода, потратив на это пару часов работы… почему нет?
то, что кто-то поленился в своё время сделать осмысленный выбор, то это значит что выбор не поздно сделать и сейчас!Совсем необязательно. Если кто-то поленился или не смог сделать выбор 5 лет назад, то это совсем не значит что сейчас это реально поменять с текущими ресурсами компании.
Если вы не можете этого поменять сейчас, то, стало быть, вы не сможете этого сделать и через 10 лет, то есть ваша компания — ходячий труп и работать там не стоит.
Другой вопрос, что вам может быть невыгодно менять это решение вот прямо сейчас — ну так заведите баг и отслеживайте там соотвествующие решения.
Заодно будет что ответить последующим новичкам вместо пресловутого «тут брать лестницу и доставать бананы не принято».
Другой вопрос, что вам может быть невыгодно менять это решение вот прямо сейчас — ну так заведите баг и отслеживайте там соотвествующие решения.
Заодно будет что ответить последующим новичкам вместо пресловутого «тут брать лестницу и доставать бананы не принято».
Если вы не можете этого поменять сейчас, то, стало быть, вы не сможете этого сделать и через 10 лет, то есть ваша компания — ходячий труп и работать там не стоит.Конечно же нет. Во-первых банки с системами на коболе до сих пор существуют и нормально себя чувствуют. Да, естественно когда-нибудь это все-таки умрет, но оно уже прожило больше абсолютного большинства проектов на любом модном языке/технологии. Оно прожило больше большинства проектов даже если считать с того момента как кобол устарел.
С другой стороны через 10 лет необходимость в данном инструменте может отпасть и его просто не придется менять. Или экономическая выгода переделывания в какой-то момент все-таки перевесит и вы таки сможете поменять через 10 лет. Но не сейчас, потому что сейчас это пока что не выгодно.
И это, наверняка, не все варианты когда ваше утверждение неверно.
Другой вопрос, что вам может быть невыгодно менять это решение вот прямо сейчасИменно! Значит сейчас выбор делать — поздно. Вы же сами себе противоречите.
ну так заведите баг и отслеживайте там соотвествующие решенияВы хоть раз сталкивались с багом (а здесь это вообще не баг, в лучшем случае улучшение), которому лет 5? На сколько долей процента информация в нем была актуальна? По моему опыту в живом проекте баги открытые дольше года проще закрыть чем разобраться какую часть из него вообще имеет смысл читать.
Заодно будет что ответить последующим новичкам вместо пресловутого «тут брать лестницу и доставать бананы не принято».Ой да ладно, как будто ответ: «Да, вы правы, я завел баг 5 лет назад и мы ждем когда наконец настанет время его сделать» сильно лучше. «Исторически сложилось» хотя бы прямо в ответе не подразумевает что этого никто делать не будет, ваш же вариант убивает любую надежду.
Сталкивался и не один раз. Как раз в случае, когда что-то нужно кардинально переделать — рефакторинг может и больше занять. А уж 2-3 года, когда процесс идёт — это вообще норма.ну так заведите баг и отслеживайте там соотвествующие решенияВы хоть раз сталкивались с багом (а здесь это вообще не баг, в лучшем случае улучшение), которому лет 5?
Вот, кстати, у нас переход системы сборки с, внезапно, python2, на, внезапно, Go… начали два года назад, к 2020му должны завершить… Вопрос «успеем или нет» — пока открыт.
Понятно, что под тем «зонтичные» бегом сейчас висят десятки других… Но первый год его существенны — там шла только медленно текущая дискуссия на тему «как, когда, что» мы планируем делать…
Ой да ладно, как будто ответ: «Да, вы правы, я завел баг 5 лет назад и мы ждем когда наконец настанет время его сделать» сильно лучше.Да, разумеется.
«Исторически сложилось» хотя бы прямо в ответе не подразумевает что этого никто делать не будет, ваш же вариант убивает любую надежду.Ссылка на баг как раз этого не подразумевает. Она даёт вам возможность посмотреть — насколько на эту тему вообще думали и что решили. И да, если все предложения по изменению чего-либо так и висят годами и «всем пофиг», то ясно, что отсюда нужно уходить: вы так и будете валить лес тупым топором, потому что вам его заточить не дают.
А в нормальной же ситуации люди завезённые баги, вообще-то, стараются закрывать. И вопрос «а почему сделано вот через такую… хмм… странную конструкцию» должен либо получить нормальный ответ («мы не можем перейти на Go с Python 2, пока не будут модули для X, Y и Z» — и дальше, соответственно, ещё три бага), либо вы получите задачу, под которую можно уже пытаться получить ресурсы (успешно или нет — другой вопрос) — если все «исторически сложившиеся» причины пропали, и, соответственно, блокеров больше нет.
P.S. Кстати если все три бага (про X, Y, и Z) закрыты как «infeasible» — то это ещё не конец! Кто-то другой может из за вас сделать — и тогда можно будет заново активизировать и родительский баг! А вот ответ «так исторически сложилось» — ничего подобного делать не позволяет. В чём, собственно, и проблема.
В реальности не все так очевидно. Обычно новые требования можно поддержать добавлением костыля. Работает? Работает, но каждый новый костыль добавлять все сложнее. В какой момент нужно остановиться и переписать все заново?
Собственно уже ответили, но просто пример из моей практики: в компании где я работаю используют Mercurial. Когда я спросил почему не Git, то ответ был именно такой: исторически сложилось. Когда начинали популярность была примерно одинаковая, а сейчас уже есть экосистема, тулза для билда и деплоя завязанная на меркуриал и несколько десятков разработчиков которые к нему привыкли. Да и не то чтобы уж он был плох, просто не популярен и не всегда после гита очевиден. Это именно «исторически сложилось».
> "- Так исторически сложилось."
> Но что значит эта фраза?
Она значит:
Люди, народавшие этот хлам до тебя — они теперь твои начальнички. Они свой код любят и лелеят, но предпочитают в него больше не соваться потому что это не барское дело. Они даже стараются не вспоминать о том, что когда-то работали простыми кодерками, принимали от кого-то указания и правили код после ревью. Жри кактус и молча улыбайся. В противном случае сразу после первого вопроса «кто и почему это писал», будет принято кулуарное решение о том, что ты не влился в коллектив (недостаточно софтскиллз, не разделяешь корпоративные ценности, нелоялен, критически настроен по отношению к коллегам — может быть любая причина другая, которую все равно никак не померишь) — это решение доведут до твоего сведения в день окончания испытательного срока.
> Но что значит эта фраза?
Она значит:
Люди, народавшие этот хлам до тебя — они теперь твои начальнички. Они свой код любят и лелеят, но предпочитают в него больше не соваться потому что это не барское дело. Они даже стараются не вспоминать о том, что когда-то работали простыми кодерками, принимали от кого-то указания и правили код после ревью. Жри кактус и молча улыбайся. В противном случае сразу после первого вопроса «кто и почему это писал», будет принято кулуарное решение о том, что ты не влился в коллектив (недостаточно софтскиллз, не разделяешь корпоративные ценности, нелоялен, критически настроен по отношению к коллегам — может быть любая причина другая, которую все равно никак не померишь) — это решение доведут до твоего сведения в день окончания испытательного срока.
кто и почему это писалОбычно на этот вопрос отвечает система контроля версий. В идеале, к коммиту должен быть указан таск, чтобы и на «почему» ответить.
Когда концентрация начальничков достигает некоторого критического порога они затевают переезд с одной системы контроля версий на другую. История коммитов при этом волшебным образом куда-то исчезает. Вместе с ней исчезают и многие комменты из кода.
С тасками еще проще — в запущенных случаях никаких тасков нет (как нет и джиры, например) и постановки задач приходят к новому сотруднику в виде потока голосовых звонков, цитат из корпоративного чата и цитат из писем заказчика. От новичка при этом требуется проактивная позиция — он должен задавать вопросы по своей задаче случайным людям, вызывая у последних взрывной рост ЧСВ.
С тасками еще проще — в запущенных случаях никаких тасков нет (как нет и джиры, например) и постановки задач приходят к новому сотруднику в виде потока голосовых звонков, цитат из корпоративного чата и цитат из писем заказчика. От новичка при этом требуется проактивная позиция — он должен задавать вопросы по своей задаче случайным людям, вызывая у последних взрывной рост ЧСВ.
Все так. А главным мерилом всего является коммерческая успешность. Если налепили чего попало, но оно работает и зарабатывает бабки — значит все было правильно. Ибо теперь есть возможность разлеплять и делать хорошо, разбираясь в причинах почему налепили. А если налепили и оно не зарабатывает — значит никакой презумпции ума, так же как если все красиво и не зарабатывает; но в таких случаях обычно новичком не придешь, ибо все уже «украдено до нас».
Все так, но только если люди которые это налепили и люди которые смогли это продать одни и те же люди. Потому что в ином случае на их месте могли оказаться другие люди которые бы сделали по другому, но проект все равно взлетел бы, потому что продавали и раскручивали его не они.
Согласен. "… подвиг одного — это преступление другого", и так навреняка бывает, что толковый продажник все вытягивает на своем горбе. Мне не доводилось такого видеть, но легко допускаю возможность. Чаще же лепят, успешно, когда лепка производится осознанно. Обычно налепителями руководит тот, кого нанял тот же, кто нанял тех кто продает. И если этот (или эти) кто-то нанявший руководителей понимае[ю]т чего хотят — все устаканивается.
Все люди умны и адекватны, если не доказано обратное.
Это ложное утверждение. По сути повествования оно строится как контр-тезис к утверждению «Все люди дебилы». Но строится некорректно.
В свое время, в университете, у нас на зачете по алгебре логики преподаватель любил задавать один вопрос. Сам он был почти лысый. И давал такое задание студентам — сформулируйте отрицание очевидно ложного выражения: «Все люди лысые». Один из самых распостраненных ответов который давали студенты не думая был — «Все люди с волосами».
На что он с театральной паузой и неподдельной болью в глазах переспрашивал — «И даже я?...»
После этого все, кто сдавал эказамен навсегда умудрялись запомнить, в чем суть булевой операции отрицания выражения :)
Не все люди адекватны и умны — это утверждение истинно.
Не все люди дебилы — и это утверждение тоже истинно в то же время.
Исходите из истинности этих двух предположений и вы не только не будете попадать в неловкие ситуации, но и принесете максимальную пользу своим свежим взглядом на новом месте на устоявшиеся практики и процедуры.
«не все» будет гораздо легче воспринимать, если запомнить, что это синоним «некоторые»
Антоним только. «Не все люди лысые» === «некоторые люди не лысые».
«не все» будет гораздо легче воспринимать, если запомнить, что это синоним «некоторые»
Нет, это не синоним. И в таком восприятии часто кроется много заблуждений.
«не все» — это «некоторые» ИЛИ «никто».
Кванторы всеобщности и существования не вляются прямыми антагонистами.
Словосочетание «презумпция ума», как несложно догадаться, построена по аналогии с презумпцией невиновности. Вот определение из википедии:
Если следовать вашей логике, то получается, что презумпция невиновности тоже не имеет смысла, поскольку некоторые люди виновны и сидят в тюрьме, а некоторые нет.
Презу́мпция невино́вности (лат. praesumptio innocentiae) — один из основополагающих принципов уголовного судопроизводства, заключающийся в том, что лицо считается невиновным, пока его вина в совершенном преступлении не будет доказана в порядке, предусмотренном законом, и установлена вступившим в законную силу приговором суда
Если следовать вашей логике, то получается, что презумпция невиновности тоже не имеет смысла, поскольку некоторые люди виновны и сидят в тюрьме, а некоторые нет.
«презумпция невиновности» — это не истина. Она действительно не имеет никакого другого смысла, кроме упорядочивания процедуры судопроизводства. Это просто условность, закрепленная в форме формальных юридических процедур на законодетельном уровне. Ее с тем же успехом можно заменить на «презумпцию виновности» или что-то еще. Законодательство к истине, как и справедливости, имеет очень отдаленное отношение и является следствием культурно-исторического развития социума — а там возможны какие угодно причуды.
Соответственно аппеляция к «презумции ума» на аналогии с «презумпцией невиновности» (оставляя открытым вопрос насколько вообще такая аналогия уместа) — это не более чем условность в способе упорядочивания рассуждений принятая конкретным индивидом. Да, можно делать и так. Но можно и по другому.
Соответственно аппеляция к «презумции ума» на аналогии с «презумпцией невиновности» (оставляя открытым вопрос насколько вообще такая аналогия уместа) — это не более чем условность в способе упорядочивания рассуждений принятая конкретным индивидом. Да, можно делать и так. Но можно и по другому.
Ваш комментарий вполне себе не более чем условность ;) Только смысл от меня ускользает. Причём здесь логическая ошибка? В чем она заключается?
Комментарий не условность:) Что то из утверждений в нем — возможно. Но сам он точно не условность.
В утверждении, что Все люди умны и адекватны, если не доказано обратное.
И тем более в утверждении Про себя я называю это правило: «презумпция ума». Оно абсолютно универсально, и работает почти во всех ситуациях и для всех людей.
Оба утверждения весьма и весьма спорные.
Причем формулируемое следствие вполне годное:
Но оно выглядит как классический пример ложной индукции и это единственная причина, по которой я дал свои комментарии. Вы сделали такой вот вывод, но другой читатель может принять ваши исходняе утверждения а прийти к другим выводам, отличных от ваших. Например, полностью отказаться от поиска ошибок в действиях других, приспосабливая свою позицию вместо указания на ошибочность сложившегося порядка.
Не все люди умны и адекватны по умолчанию. Но они и совсем не дебилы.
На мой взгляд, эта предпосылка больше соответствует реальности и выводы из нее более полезны на практике.
Пусть лучше читатели увидят этот тред и задумаются об этом:)
Причём здесь логическая ошибка? В чем она заключается?
В утверждении, что Все люди умны и адекватны, если не доказано обратное.
И тем более в утверждении Про себя я называю это правило: «презумпция ума». Оно абсолютно универсально, и работает почти во всех ситуациях и для всех людей.
Оба утверждения весьма и весьма спорные.
Причем формулируемое следствие вполне годное:
На практике оно означает: попробуй сначала понять, что происходит, а уже потом начинай критиковать и предлагать решения.
Но оно выглядит как классический пример ложной индукции и это единственная причина, по которой я дал свои комментарии. Вы сделали такой вот вывод, но другой читатель может принять ваши исходняе утверждения а прийти к другим выводам, отличных от ваших. Например, полностью отказаться от поиска ошибок в действиях других, приспосабливая свою позицию вместо указания на ошибочность сложившегося порядка.
Не все люди умны и адекватны по умолчанию. Но они и совсем не дебилы.
На мой взгляд, эта предпосылка больше соответствует реальности и выводы из нее более полезны на практике.
Пусть лучше читатели увидят этот тред и задумаются об этом:)
Это ложное утверждение. По сути повествования оно строится как контр-тезис к утверждению «Все люди дебилы». Но строится некорректно.
Как указали в ветке рядом, презумпция ума не строится как контр-тезис к чему-либо. Кроме того, говорить, что она является ложным утверждением, значит не понимать, что в точности она утверждает.
Во-первых, презумпция это импликация «если ..., то ...»: если не доказано обратное, то человек считается умным. Во-вторых, презумпции всегда верны с точки зрения логики: если не доказано обратное, то X <=> если не «не X», то X
презумпция ума не строится как контр-тезис к чему-либо
Это, вообще говоря, неизвестно. Строится оно так и или нет. Что было на уме у автора только ему известно. Утверждение лишь говорит о том, что эта логическая конструкция эквивалентна другой с точностью до изоморфизма.
презумпции всегда верны с точки зрения логики
Истинность логического высказывания как элемента булевой алгебры и семантическая верность утверждения с точки зрения здравого смысла — это, как говорят в Одессе, «две больших разницы».
если не доказано обратное, то человек считается умным.
Это абсурд. Это видно даже невооружённым глазом. По смыслу это тоже самое, что: «если не доказано обратное, то человек считается ТОРТОМ». И для этого даже не нужно поверхностное знание вводного курса алгебры. Причина кроется в том, что по определению импликация определена однозначно только для результата, который обычно принято записывать буквой «Л» или «0»(ноликом или кружочком, да как угодно). По своему применению импликация лишь приближена к союзам «если…, то…», но напрямую им не эквивалентна. Это просто математический формализм.
Кажется, что вы больше сосредоточены на форме (Если A, то B). Но форма сокращенная. Полная форма выглядит так: если не доказано обратное, то я буду считать, что человек умный. Я выбрал это сокращение по аналогии с презумпцией ума. Ее полная форма выглядит аналогично. Обратите внимание, что в этом случае пример с тортом становится менее абсурдным.
если не доказано обратное, то я буду считать, что человек умный
Формально, это утверждение идентично «если не доказано обратное, то я буду считать, что человек глупый»… ключевое здесь — я буду считать, а считать можно что угодно, ктож запретит… Но ни «форма», ни «импликация», ни «булева алгебра» — тут ровным счётом непричём. Эти все фигуры речи лишь «семантические вопросы» и область человеческих фантазий. Их обсуждение имеет такую же ценность, как обсуждение цвета галлюцинаций под воздействием лёгких психотропных веществ.
просто как всё гениальное
Все люди умны и адекватны, если не доказано обратное.
Первое правило волшебника гласит: "Люди глупы".
Как мне представляется, это более правильное представление (особенно если рассматривать полную формулировку правила). Только нужно понимать, что ты тоже человек и очень даже подпадаешь под это правило.
del
Если вспомнить первоисточник, то там исключений нет. Глупы все, ибо все способны поверить в то, что хочется видеть правдой, или в то, что страшно увидеть правдой.
Опять же, в первоисточнике приводится пример, как первое правило использовали против умного (казалось бы), опытного чародея (пример, кстати, жизненный, в реальной жизни встречающийся, и, что характерно, никакой магии, голая психология).
И я бы даже добавил к первому правилу (исключительно ради красного словца, на истину никак не претендую).
Ум — это мера понимания чужой глупости.
Мудрость — это мера понимания собственной глупости.
Я не пытаюсь вывести соотношение умных и глупых. Я даже никак не смогу опровергнуть первое правило волшебника. Я просто вижу вокруг себя очень много высокомерных людей, которые считают, что они понимают все и обо всем, и тут же спешат об этом поведать миру. На Хабре концентрация такого рода «экспертов» просто зашкаливает. В какой-то момент я начал замечать подобного рода вещи и за собой. Именно об этом и статья. Если хотя бы несколько человек задумается, то я не зря старался.
Будем надеяться, что из многочисленных ответов вам наконец удастся понять, что «высокомерие» и «ум» — это слабо связанные и сильно разные вещи. А уверенность людей в том «что они понимают все и обо всем, и тут же спешат об этом поведать миру» абсолютно ничего не говорит об их уме, а скорее об его отсутствии.
То что вы называете «презумпция ума» — это обычная наивность и доверчивость. Со временем это обычно проходит. Эмпатия штука сильная в социальных сообществах, но есть и масса других, не менее эффективных, способов поддерживать нормальный контакт с людьми.
В реальной жизни в принципе с любыми людьми, можно и нужно обсуждать проблемы, если в этом есть необходимость, независимо от оценки их умственных способностей. Гораздо практичней принимать реальность такой, какая она есть, а не приписывать ей желаемые свойства. И вместо «презумции ума» просто придерживаться «презумции взаимного уважения», а вот наличие «ума» ещё надо доказать…
Задумайтесь лучше об этом, чтоб, действительно от ваших стараний была польза.
То что вы называете «презумпция ума» — это обычная наивность и доверчивость. Со временем это обычно проходит. Эмпатия штука сильная в социальных сообществах, но есть и масса других, не менее эффективных, способов поддерживать нормальный контакт с людьми.
В реальной жизни в принципе с любыми людьми, можно и нужно обсуждать проблемы, если в этом есть необходимость, независимо от оценки их умственных способностей. Гораздо практичней принимать реальность такой, какая она есть, а не приписывать ей желаемые свойства. И вместо «презумции ума» просто придерживаться «презумции взаимного уважения», а вот наличие «ума» ещё надо доказать…
Задумайтесь лучше об этом, чтоб, действительно от ваших стараний была польза.
Да не переживайте вы так за меня. У меня все хорошо. А за Хазанова спасибо! Очень его люблю
Да за вас я и не переживаю:) Но вы вышли со своей спорной точкой зрения в публичное пространство и адресовали её неопределённому кругу лиц. Кто-то из них может по случайности в неё поверить, и чтоб свои решения они могли принимать более взвешенно и рационально, мои комментарии к вашему посту адресованы исключительно им. Но вести ух наиболее уместно именно в режиме диалога с автором, просто как наиболее эффективный в данном контексте риторический приём. И за то что поддерживаете эту дискуссию вам отдельное спасибо!
И вот ЭТО получило 53 плюса?! «Да тут все придурки!» (с) Автостопом по галактике.
На самом деле — нет. Просто все люди находятся в разных областях познания мира. Так что, в каких-то областях даже умнейшие люди — полные придурки.
В общем, без обид, весь смысл в одной фразе:
Никогда не делайте абсолютных утверждений о реальном мире.
Мир всегда найдёт, чем вас удивить… ой… кажется, я сделал абсолютное утверждение :)
На самом деле — нет. Просто все люди находятся в разных областях познания мира. Так что, в каких-то областях даже умнейшие люди — полные придурки.
В общем, без обид, весь смысл в одной фразе:
Никогда не делайте абсолютных утверждений о реальном мире.
Мир всегда найдёт, чем вас удивить… ой… кажется, я сделал абсолютное утверждение :)
Мне посчастливилось сегодня сформулировать новый закон Мерфи
Справедливости ради, разве не таковы по умолчанию все граждане с точки зрения правоохранительных органов, все читатели инструкций с точки зрения их авторов, все ученики с точки зрения учителя и т.д.
Считай что все люди безумные идиоты, если не доказано обратное.
Справедливости ради, разве не таковы по умолчанию все граждане с точки зрения правоохранительных органов, все читатели инструкций с точки зрения их авторов, все ученики с точки зрения учителя и т.д.
Это очевидное следствие из основного закона: «Всё, что может пойти не так, пойдет не так». Поэтому давайте запретим всё, что не разрешили явно, особенно всяким дуракам. Именно так делает Линукс — пожалуй, самая свободная операционная система в мире.
Как ни странно, ненавистная всеми Винда делает, как настоящая женщина — ровно наоборот.
Как ни странно, ненавистная всеми Винда делает, как настоящая женщина — ровно наоборот.
«Она сумела открыть себе дорогу в лаборатории, играя на алчности червелицых. Народ Мэмми умел делать многое, чего не умели делать они — различные приборы и остроумные приспособления, облегчающие работу и жизнь. Начала она с невинных вопросов, почему они делают что-нибудь так, а не иначе, другим, более экономным и рациональным способом? По традиции или в силу религиозных соображений?»
(«Это просто фантастика»)
Хайнлайн, «Имею скафандр — готов путешествовать»
Ну, есть исключения.
Написал вам ответочку habr.com/post/427917 :)
Проблема в том, что новички учатся чему-то новому, не изучив старое, потому что то самое старое — унылое г. Но это не всегда так, это унылое г. раньше было самым прорывным что было на планете. Отсюда и вездесущая джава и легаси. И это бесконечный процесс. Завтра python3 станет унылым г. при выхоле Go2, например.
А есть ситуации когда приходишь в компанию, которая делает оборудование, претендующее на надёжность, а там ардуина.
Презумпция программиста: бросаться из крайности в крайность, не разбираться как вести себя в разном окружении и ситуациях, следовать всегда жестким правилам, которые ставишь сам себе в голове, считать несогласных дураками, при этом делая вид что сам скромнейший и мудрейший человек. + Заметил что многие коллеги пытаются заменить здравый смысл тн опытом. Каждая ситуация и человек требует отдельного подхода и иногда надо бросаться в крайности.
Хочешь переписать? Заэстимируй, посчитай сколько денег для бизнеса уйдет. Как вариант можно сделать отдельный новый проект для новых девелопментов и потихоньку на него переходить.
Докер? Сделай сам для себя, автоматизируй все процессы сборки — внезапно выяснится что ты очень даже перформишь по мнению манагеров, только за счет рестартов.
Вебпак? Если все и так собирается одной командой то смысла нет. Если не собирается то простейший шелл или нпм скрипт может помочь.
Хочешь переписать? Заэстимируй, посчитай сколько денег для бизнеса уйдет. Как вариант можно сделать отдельный новый проект для новых девелопментов и потихоньку на него переходить.
Докер? Сделай сам для себя, автоматизируй все процессы сборки — внезапно выяснится что ты очень даже перформишь по мнению манагеров, только за счет рестартов.
Вебпак? Если все и так собирается одной командой то смысла нет. Если не собирается то простейший шелл или нпм скрипт может помочь.
// Webapck
Полгода назад для сборки HTML5-игр у меня был 1 маленький JS-скрипт, который работал очень быстро и занимал всего несколько килобайт. Этого было вполне достаточно.
Летом, для совместимости с Jenkins, перешли на Webpack. Добавилась папка node_modules в сотни тысяч файлов и десятки мегабайт. Скорость сборки вебпаком — дольше в несколько раз. Это уже не говоря о зависимости от Интернета, которая требуется для npm install. Так что я могу понять ситуацию в начале статьи.
Но… совместимость с промышленным стандартом (и другими разработчиками) и системами автоматизированной сборки решает. Так что я могу понять и тех, кто использует webpack даже для ситуаций, которые по сути заключается в копировании файлов и замене текстов (скрипт для ноды пишется меньше чем за сутки, ты получаешь полный контроль над процессом и ультимативную скорость, но привыкшие к webpack смотрят на тебя, как на вомбата ))
Полгода назад для сборки HTML5-игр у меня был 1 маленький JS-скрипт, который работал очень быстро и занимал всего несколько килобайт. Этого было вполне достаточно.
Летом, для совместимости с Jenkins, перешли на Webpack. Добавилась папка node_modules в сотни тысяч файлов и десятки мегабайт. Скорость сборки вебпаком — дольше в несколько раз. Это уже не говоря о зависимости от Интернета, которая требуется для npm install. Так что я могу понять ситуацию в начале статьи.
Но… совместимость с промышленным стандартом (и другими разработчиками) и системами автоматизированной сборки решает. Так что я могу понять и тех, кто использует webpack даже для ситуаций, которые по сути заключается в копировании файлов и замене текстов (скрипт для ноды пишется меньше чем за сутки, ты получаешь полный контроль над процессом и ультимативную скорость, но привыкшие к webpack смотрят на тебя, как на вомбата ))
Э… а в чем заключается особая совместимость Webpack с Jenkins? Jenkins же умеет произвольные команды выполнять…
я просто поленился развернуть всю сумму причин. Пожалуй, сейчас, когда я обдумал все, главной является такая причина, что одно дело недокументированный самописный скрипт, а другое — известная документированная система, которую легко расширять. Сейчас я перешел на TypeScript и нормальную систему модулей, так что обратно на самодельный коллектор файлов вряд ли уже перейду, разве что сойду с ума и захочу сделать собственный реализатор модулей и транспайлер с TypeScript впридачу ))
я уже лет 15 мучаюсь с проектом на перле. жутко напрягает.
но легаси. переделать долго и дорого
но легаси. переделать долго и дорого
Все люди умны и адекватны, если не доказано обратное.
Ok. Согласен.
попробуй сначала понять, что происходит, а уже потом начинай критиковать
ИМХО это не следует из первого, т.е. ИМХО критиковать, т.е. задавать критические вопросы можно и нужно с первого шага. Если люди умны и адекватны, то они ответят, да еще порадуются, что взяли нового умного сотрудника. (Сужу по себе: я радуюсь, когда новый сотрудник сразу задает мне вопросы).
И простите — исходя из презумпции ума технический вопрос по статье:
Там уже стоит готовый к работе ноутбук.
Почему ноут, а не десктоп — последний и дешевле, и конфигурировать, и ремонтировать его проще, м.б. я отстал от жизни?
Почему ноут, а не десктопТочного ответа я не знаю, но там где я сейчас работаю это, похоже, сделано как самый простой способ обеспечить работникам мобильность. Как в пределах офиса — сходить пообщаться в переговорке, показать что-то на митинге, так и просто поработать из дома на рабочем инструменте не заморачиваясь обустройством рабочего же пк дома. Плюс компания последние полтора года (а то и больше) активно растет и занимаемый опенспейс каждые несколько месяцев несколько меняется, так что примерно раз в полгода твое рабочее место меняет свое местоположение в офисе и ноутбук вместо ПК здорово упрощает при этом жизнь. К нему правда идут еще мониторы дополнительные, так что все равно есть заморочки. Но я напрямую не спрашивал, это скорее из наблюдений.
Почему ноут, а не десктоп — последний и дешевле, и конфигурировать, и ремонтировать его проще, м.б. я отстал от жизни?
Само как-то вышло. Неосознанно. Люди вокруг меня уже давно все работают за ноутбуками. Ничего не имею против стационарного компьютера.
У меня дома стоит ноут игровой. Покупал, чтобы можно было ночью играть и смотреть фильмы на кухне, а в компании там вообще можно где угодно засесть, можно с ним к коллеге сходить с вопросом, в случае отключения электричества ещё пару часов работать и т.д. Можно взять домой, в машину, на улице, в кафе работать, к клиенту сгонять… Много плюсов. Сейчас использую, как стационар, но и дома есть преимущества: не шумит, не жрёт энергию, можно куда угодно поставить. Сам работаю за внешним монитором, клавой и мышкой.
Да. Спасибо. Я согласен, что для дома (в том числе и для надомной работы) ноут имеет большие плюсы (хотя я и дома на десктопах работаю). Но в статье речь про рабочее место в офисе. Я и спросил: зачем в офис ноут на каждое рабочее место? ИМХО для презентаций и командировок дешевле иметь несколько дополнительных ноутов на несколько десятков сотрудников. Наверное, дело еще и в однородности персональных задач: только программистам, у которых почти только текст, не нужно «высокой графики», а если 50 дизайнеров на 45 программистов — тогда м.б. сложнее.
ИМХО для презентаций и командировок дешевле иметь несколько дополнительных ноутов на несколько десятков сотрудниковНе проще. У разных сотрудников — разные проекты, разное окружение, они привыкли к разному софту. Если мне нужно ехать в командировку, то я совсем не горю желанием тратить день заранее на поднятие нужного окружения и потом еще день на его чистку. Ладно, почистить можно и накатыванием образа, но настраивать и загружать все возможно необходимые данные? Гораздо проще, как раз, когда рабочее место можно взять и увезти с собой.
Ok, очевидно, что дорогой мощный ноут лучше, чем слабый немобильный ПК. Я только сомневаюсь, что все конторы на все рабочие места ставят самые дорогие и мощные ноуты.
Разница между дорогим мощным ноутом и средним меньше чем зарплата среднего программиста за месяц. Я могу понять что нет денег у стартапа, который еще не начал зарабатывать, но в компании, которая уже зарабатывает, адекватной причины не покупать нормальное железо для программистов — нет. Хотя ситуации бывают разные и иногда, я уверен, что без именно ПК не обойтись.
Хотя ситуации бывают разные и иногда, я уверен, что без именно ПК не обойтись.Да. Для многих работ я меняю «винт», а бывает, что и без «винта».
Еще одно соображение против ноута — это безопасность. Пропажа или кража ноута со всеми исходными кодами создаваемого ПО и БД для многих компаний крайне нежелательна. Системный блок ПК утащить и незаметно вынести гораздо сложнее.
Надо исходить из аксиомы: на чём начали проект, на том и заканчиваем. Менять средства разработки нужно тогда и только тогда, когда задача текущими средствами не решается.
попробуй сначала понять, что происходит, а уже потом начинай критиковать и предлагать решения.
Беда в том, что люди начинают следовать этому простому и понятному правилу только наломав кучу дров! И так по кругу.
Как-то я писал про легаси код статейку и про причины этого явления: cleverman.org/post/legasi-kod-zlo-vselenskogo-masshtaba
Эту же статью я могу сжать в совсем короткий тезис, который был мною увиден в течении последних 10 лет. Берут на проект человека, рассказывая про гениальный новаторский проект и самые современные технологии. Естественно в вакансии требования на знание самых последних версий, подходов/паттернов и т.д. Первые три месяца специалист прозревает от того п*зде… а, что происходит на проекте, лезет со своими вопросами и предложениями. Через этот срок, когда кто-то ему задает вопрос про то, как он видит проект, и что нужно делать, ответ всегда одинаковый у всех без исключений: «Мне пох… й!»
А еще через небольшой промежуток времени такой специалист сваливает, так как его контора жестко обманула и кинула, обещав одно, а на самом деле макнув с головой в легаси. А «талантливым» разработчикам что создали это легаси, вместе с такими же менеджерами, только и остается писать статьи просам дурак «Презумция ума».
Эту же статью я могу сжать в совсем короткий тезис, который был мною увиден в течении последних 10 лет. Берут на проект человека, рассказывая про гениальный новаторский проект и самые современные технологии. Естественно в вакансии требования на знание самых последних версий, подходов/паттернов и т.д. Первые три месяца специалист прозревает от того п*зде… а, что происходит на проекте, лезет со своими вопросами и предложениями. Через этот срок, когда кто-то ему задает вопрос про то, как он видит проект, и что нужно делать, ответ всегда одинаковый у всех без исключений: «Мне пох… й!»
А еще через небольшой промежуток времени такой специалист сваливает, так как его контора жестко обманула и кинула, обещав одно, а на самом деле макнув с головой в легаси. А «талантливым» разработчикам что создали это легаси, вместе с такими же менеджерами, только и остается писать статьи про
Как говорил знакомый следователь: «Главное при проведении следсвенных мероприятий поиске первопричин плохих решений не выйти на самого себя»
Одна из самых полезных статей за последнее время :)
Такой шикарный заголовок и такая дичь в посте и комментариях(
Нашёл уже два «ответа» на этот пост. Ну да, давайте засрём Хабр «ответками», и так — на каждый пост, с которым кто-то не согласен. Мне одному кажется, что задул плохой ветер?
С другой стороны, если другими методами добиться кармы и плюсов нельзя, то система будет взломана. У тех ребят по 2к и 4к просмотров, все в плюсе.
Такие ответки на Хабре не редкость. Кажется, Хабру нужен новый инструмент: дерево взаимосвязей «пост-ответ».
С другой стороны, если другими методами добиться кармы и плюсов нельзя, то система будет взломана. У тех ребят по 2к и 4к просмотров, все в плюсе.
Такие ответки на Хабре не редкость. Кажется, Хабру нужен новый инструмент: дерево взаимосвязей «пост-ответ».
От текста отчётливо повеяло вконтактовскими пабликами по саморазвитию для убогих духом и слабых интеллектом.
Делаю такое крайне редко — на моей памяти вроде второй раз за три года — но тут минусы статье и автору я поставил. Первый раз был — когда в статье на полном серьёзе советовали тухлый китайский планшет на Атоме в качестве рабочей машины под Автокад.
P.S: На этот «вброс» накидали уже 2 шт «статьи-ответа». Их тоже проминусовал. Посты-вбросы, порождающие обсуждения «обо всём и ни о чём», ИМХО ведут к деградации ресурса. Не надо давать им плодиться.
Делаю такое крайне редко — на моей памяти вроде второй раз за три года — но тут минусы статье и автору я поставил. Первый раз был — когда в статье на полном серьёзе советовали тухлый китайский планшет на Атоме в качестве рабочей машины под Автокад.
P.S: На этот «вброс» накидали уже 2 шт «статьи-ответа». Их тоже проминусовал. Посты-вбросы, порождающие обсуждения «обо всём и ни о чём», ИМХО ведут к деградации ресурса. Не надо давать им плодиться.
Вы замеряли производительность обоих вариантов?
возникает множество вопросов о том, что происходит у него в голове
Так задайте их!=) Так и спросите, мол, о сэнсей, зачем ты пишешь эти 12 строк, если можно написать одну, и ни один тест не сломается*?
с его слов, нечитаемы как раз — литералы
А вот, кстати, и половина ответа на ваши вопросы. Вам удобнее одно, ему другое, кому-то ещё – что-то третье. Объективных метрик удобства, читаемости и прочей феншуйности не существует, так что здесь спасут только code conventions. Возможно, вам стоит направить усилия как раз на их разработку и внедрение?
* — только не забудьте сначала это проверить, а то мало ли…
return formats.map(x => `.${x}`).join(',')
Вот вам контр-вопрос. Зачем писать по-модному, если можно написать по-простому? Зачем использовать шаблонные строки там, где они не нужны?
return formats.map(x => '.' + x).join(',')Декларативность-то нужна не ради декларативности, а ради понимания. Я вот с трудом представляю себе программиста, который не понимает что получится в результате конкатенации строки из одной точки с переменной.
Что же до сравнения понятности двух вариантов — я бы сравнивал их следующим образом. Есть данные, а есть разметка. Данные тут — точка и переменная (2 символа), разметка же содержит 3 символа в случае конкатенации и 5 символов в случае интерполяции. Получается, что конкретно в данном случае вариант с интерполяцией почти полностью состоит из разметки, что делает его довольно сложным для понимания.
В то же время, уже две конкатенации дают такую же синтаксическую нагрузку как интерполяция, а три — проигрывают ей. Поэтому лично я предпочитаю использовать простую конкатенацию для добавления префикса или суффикса, и интерполяцию для остальных случаев.
Что же до сравнения понятности двух вариантов — я бы сравнивал их следующим образом. Есть данные, а есть разметка. Данные тут — точка и переменная (2 символа), разметка же содержит 3 символа в случае конкатенации и 5 символов в случае интерполяции. Получается, что конкретно в данном случае вариант с интерполяцией почти полностью состоит из разметки, что делает его довольно сложным для понимания.
В то же время, уже две конкатенации дают такую же синтаксическую нагрузку как интерполяция, а три — проигрывают ей. Поэтому лично я предпочитаю использовать простую конкатенацию для добавления префикса или суффикса, и интерполяцию для остальных случаев.
Я это называю презумпция разумности. Разумности принятия конкретного решения, выбора фреймворка и прочее.
Поэтому возгласы: какой идиот это писал?! — совершенно излишни. Сначала нужно узнать про контекст, в котором решалась данная задача. А для этого нужно подойти к разработчику, который это делал и спросить чем он руководствовался при решении задачи.
Может там спешили к релизу, делали тяп-ляп, потом времени переделать не было — так оно и дожило то тебя. Поэтому автор может обратить внимание еще на пару мест в коде, которые также надо переделать.
Но вообще нужно помнить, что люди ошибаются и не рациональные решения могут быть даже у очень рациональных людей.
Поэтому возгласы: какой идиот это писал?! — совершенно излишни. Сначала нужно узнать про контекст, в котором решалась данная задача. А для этого нужно подойти к разработчику, который это делал и спросить чем он руководствовался при решении задачи.
Может там спешили к релизу, делали тяп-ляп, потом времени переделать не было — так оно и дожило то тебя. Поэтому автор может обратить внимание еще на пару мест в коде, которые также надо переделать.
Но вообще нужно помнить, что люди ошибаются и не рациональные решения могут быть даже у очень рациональных людей.
Эту бы «презумпцию ума» тем людям которые любят кричать что их ни кто (или конкретно ты) не уважает. Я так думаю всем этого не хватает.
> С людьми, оказывается, можно обсуждать проблемы. И, о чудо, вокруг меня не одни идиоты, и я не самый умный, вернее случается, что идиот именно я. Идиоты встречаются, конечно, но в целом реже, чем до открытия во мне презумпции. Что не может не радовать.
А до этого Вы не обсуждали? Я не программист, но на старой работе прекрасно знал, в каком месте наделано нетиповое спорное решение (говно) и по какой причине, поэтому когда мне указывали на это другие сотрудники, мне было, чем спокойно объяснить тот или иной нюанс, либо признать, что это косяк, который не исправлен по причине нехватки времени и более срочных задач.
Людей за идиотов считать конечно не нужно, но я не вижу проблем в том, что новый человек приходит на новое место и задается вопросами «что за фигня?» вслух. Вы же не человека идиотом называете, а решение идиотским. Проблема не в этом человеке, а в человеке по другую сторону, который на такие вопросы отвечает в стиле «ты что, самый умный тут?»
А до этого Вы не обсуждали? Я не программист, но на старой работе прекрасно знал, в каком месте наделано нетиповое спорное решение (говно) и по какой причине, поэтому когда мне указывали на это другие сотрудники, мне было, чем спокойно объяснить тот или иной нюанс, либо признать, что это косяк, который не исправлен по причине нехватки времени и более срочных задач.
Людей за идиотов считать конечно не нужно, но я не вижу проблем в том, что новый человек приходит на новое место и задается вопросами «что за фигня?» вслух. Вы же не человека идиотом называете, а решение идиотским. Проблема не в этом человеке, а в человеке по другую сторону, который на такие вопросы отвечает в стиле «ты что, самый умный тут?»
Смех-смехом, но в конторе из уст в уста пересказывают леденяющую кровь и одновременно поражающую своей абсурдностью историю (старожилы клянутся и божатся, что это правда) — наняли лет 5 назад товарисча, который решил, что Вариант №1 — единственно правильный. В принципе, может и обтесался бы со временем, ибо молодой был и инициативный, пустил бы энергию в нужное русло при помощи коллег, но… не повезло ему с таймингом…
Наш офис (который считается «вспомогательным» и в котором «сидят» почти все «поддерживающие» подразделения, включая айтишников всех мастей) в тот момент как раз только что переехал в новое здание, по случаю чего в него съехалось все большое начальство из Очень Большого Города. Новый сотрудник решил, что лучше шанса ему может и не выпасть, поэтому, не откладывая ничего в долгий ящик, отмаршировал напрямую к Самому Большому Айтишнику, когда тот сидел за обедом с другими Очень Большими Начальниками, и, без предисловий и преамбул (но не забыв представиться!), выдал ему сходу и без прикрас всё (вообще ВСЁ), что думал об инфраструктурных решениях компании.
Удивленные боссы выслушали его, поблагодарили, после чего настоятельно попросили зайти к ним Местного Главного Айтишника, у которого в красках поинтересовались его недавно принятыми кадровыми решениями.
Говорят, что история компании (по крайней мере, нашего департамента) не знала других случаев разрыва трудового договора по инициативе работодателя всего через неделю после начала работы. Но товарисч, видимо, глубоко поразил всех…
Наш офис (который считается «вспомогательным» и в котором «сидят» почти все «поддерживающие» подразделения, включая айтишников всех мастей) в тот момент как раз только что переехал в новое здание, по случаю чего в него съехалось все большое начальство из Очень Большого Города. Новый сотрудник решил, что лучше шанса ему может и не выпасть, поэтому, не откладывая ничего в долгий ящик, отмаршировал напрямую к Самому Большому Айтишнику, когда тот сидел за обедом с другими Очень Большими Начальниками, и, без предисловий и преамбул (но не забыв представиться!), выдал ему сходу и без прикрас всё (вообще ВСЁ), что думал об инфраструктурных решениях компании.
Удивленные боссы выслушали его, поблагодарили, после чего настоятельно попросили зайти к ним Местного Главного Айтишника, у которого в красках поинтересовались его недавно принятыми кадровыми решениями.
Говорят, что история компании (по крайней мере, нашего департамента) не знала других случаев разрыва трудового договора по инициативе работодателя всего через неделю после начала работы. Но товарисч, видимо, глубоко поразил всех…
Именно по этой причине все будут тихо сидеть, засунув языки в одно место и тихо пилить какашку. Так как никто не хочет стать следующей жертвой бизнеса. А что там творится в проекте, коде и архитектуре, то это разработчиков вообще и не парит, это же не их бизнес, и плевать на его будущее.
Я думаю, что мораль истории лишь в том, что у любого рацпредложения (каким бы поистине рациональным оно ни было!) должна быть правильная аудитория и правильное время его внесения.
Я не думаю, что шиномонтажник Формулы 1, который посреди заезда внезапно подойдет к президенту команды и начнет ему увлеченно рассказывать, какие шины Мишлен — кака, и как надо немедленно купить Бриджстоун, долго проработает в команде :)
Я не думаю, что шиномонтажник Формулы 1, который посреди заезда внезапно подойдет к президенту команды и начнет ему увлеченно рассказывать, какие шины Мишлен — кака, и как надо немедленно купить Бриджстоун, долго проработает в команде :)
Вы описываете какие-то крайности. Когда проект только на этапе создания и еще не вышел в релиз, то о каких кучи менеджеров вообще может идти речь? Типа мы еще и доллара не заработали, то у нас уже начальства в разы больше чем программистов. Это абсурд. Поэтому пример с Формулой 1, который наложен на ваш комментарий выше, и не катит. Так как из вашего комментария очевидно, что проект уже существует и явно приносит прибыль. Но даже если и взять этот пример во внимание, то давайте проанализируем его.
Специалист по шинам, возможно оценил погоду, дорожное покрытие, другие факторы и пришел к экспертному выводу, что резину нужно срочно менять. На питстопе это делается за секунды! И плоха та команда, которая не держит ассортимент для заезда. Значит они реально самоуверенные дураки, которые сделали ставку всего на один вариант. Продолжим. Спеца по резине послали нах и избавились от него. Предположим, что команда проиграла. Стали после разбираться в причинах и пришли к выводу, что резина сыграла плохую шутку. Итог истории: команда проиграла дважды. Первый раз — проиграв в заездах, и второй — потеряв высококвалифицированного специалиста, который реально смог бы принести победу.
А вообще, у меня на этот счет статейка написана: cleverman.org/post/problemy-pri-roste-it-kompanii
После ее прочтения становится многое понятно, почему никому не интересен свежий взгляд и перемены. И даже такие серьезные проекты, как Дробокс, Скайп и многие другие, скатились до уровня УГ и помирают в жутких конвульсиях. А все потому, что зациклились на своей важности, исключительности, и своем внутреннем мирке, который оказался в итоге не конкурентоспособен.
Специалист по шинам, возможно оценил погоду, дорожное покрытие, другие факторы и пришел к экспертному выводу, что резину нужно срочно менять. На питстопе это делается за секунды! И плоха та команда, которая не держит ассортимент для заезда. Значит они реально самоуверенные дураки, которые сделали ставку всего на один вариант. Продолжим. Спеца по резине послали нах и избавились от него. Предположим, что команда проиграла. Стали после разбираться в причинах и пришли к выводу, что резина сыграла плохую шутку. Итог истории: команда проиграла дважды. Первый раз — проиграв в заездах, и второй — потеряв высококвалифицированного специалиста, который реально смог бы принести победу.
А вообще, у меня на этот счет статейка написана: cleverman.org/post/problemy-pri-roste-it-kompanii
После ее прочтения становится многое понятно, почему никому не интересен свежий взгляд и перемены. И даже такие серьезные проекты, как Дробокс, Скайп и многие другие, скатились до уровня УГ и помирают в жутких конвульсиях. А все потому, что зациклились на своей важности, исключительности, и своем внутреннем мирке, который оказался в итоге не конкурентоспособен.
Как странно, что никто в комментариях не упомянул Бритву Хэнлона, которая полностью противоречит смыслу статьи.
Sign up to leave a comment.
Презумпция ума