Четыре ошибки программистов, которые я осознал, только когда стал CTO +29


AliExpress RU&CIS

image

Я работал программистом более пяти лет. Не особо впечатляет, ведь кто-то из вас, вероятно, имеет в три раза больший опыт, но мне нравилось думать о себе как о сениор-разработчике. Звучит серьёзно и солидно, правда?

Однажды мне предложили стать Chief Technology Officer (CTO) в медтех-стартапе. Поработав некоторое время на этой новой должности, я могу обернуться назад и сказать, что не был сениор-разработчиком. Не поймите меня неправильно — я по-прежнему считаю, что обладаю отличными знаниями программирования, особенно веб-разработки; но если это так, почему я не думаю, что был сениором?

Всё это из-за четырёх заблуждений, которые у меня были.


Пользователь (?)

1. Пользователь — это идиот


Нет, он не идиот.

Да, пользователи работают с приложением неожиданными, часто странными способами.

Да, пользователи могут задавать вопросы, которые кажутся по-настоящему глупыми.

Да, иногда пользователи просят добавить функции, которые кажутся бессмысленными.

Да, пользователи испытывают трудности с функциями, которые кажутся понятными сами по себе.

Пользователь — не специалист. Мой врач не требует от меня, чтобы я знал отличия между липопротеинами низкой и высокой плотности. Так почему я привык предполагать, что пользователь знает, каким браузером он пользуется? Это очевидно вам и мне, но моя мама считает, что Google и Интернет — это синонимы. Она бы сказала, что не пользуется никаким браузером, потому что использует Google.

Иногда чтобы удовлетворить пользователя мне нужно было переопределять части фреймворков для изменения их стандартного поведения. Иногда мне приходилось добавлять поддержку браузеров, которые я поддерживать не хотел (привет, пользователи Safari). Сегодня это кажется мне глупым, но в то время я действительно думал, что если мне приходится создавать в своём коде обходные пути для удовлетворения требованиям клиента, то в этом виноват клиент.


Выбираем самое лучшее имя для переменной.

2. Мой код — это произведение искусства, и он должен быть идеальным


Чистый код, юнит-тесты, отличная документация — это, без сомнения, важно. Я как программист всегда стремился писать чистый код с использованием современных паттернов, часто проверял актуальность всех зависимостей в проекте и т.п. Я хотел быть Хорошим Программистом.

Когда мой менеджер по продукту попросил отказаться от юнит-тестов, чтобы увеличить скорость разработки, я испытал гнев — разве он не понимает, насколько важны юнит-тесты? У нас не было никакого автоматизированного тестирования, поэтому юнит-тесты оставались единственной надеждой на обеспечение стабильности и отсутствие регрессий в продукте.

Это решение показалось мне недальновидным. Кроме того, он рекомендовал перестать писать документацию и преобразовать код в менее сложную архитектуру (мы могли это сделать, потому что находились в самом начале проекта).

Да, я согласился, что это в какой-то степени ускорит разработку, но был уверен, что это грозит кучей проблем в будущем. Мы потратим кучу времени на устранение регрессионных ошибок, а новая архитектура окажется слишком простой, когда масштаб проекта начнёт расти! И как мы будем знакомить новых программистов с проектом без хорошего readme?

Мы часами обсуждали то, насколько плохо это решение, и сколько оно будет стоить нам в будущем.

Этот проект завершился провалом спустя несколько месяцев, потому что значительно превысил бюджет.

Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.

Разумеется, замечательно писать код, который ты можешь показывать другим и гордиться. Но ещё лучше успешно завершать проекты. В конце концов, программирование — это не искусство.


Отношение моей старой команды к пробованию чего-то нового.

3. Я буду использовать для этого проекта «X», потому что знаю его


В моей предыдущей компании мы создавали каждый проект с одинаковым технологическим стеком: Symfony и Angular. Почему? Является ли Symfony лучшим бэкенд-фреймворком? Нет. Может быть, Angular — единственный способ создания современного фронтенда? Нет. Мы всегда выбирали эту связку технологий, потому что не знали другие так же хорошо, как эти. Это была наша зона комфорта, но действительно ли неправильно выбирать хорошо известные технологии для новых проектов? Это зависит от разных факторов.

Во многих случаях ваш следующий проект будет более-менее похож на предыдущие. Было бы нелогично тратить много времени на изучение новой технологии, потому что у вас уже есть проверенные решения. Но иногда такой выбор будет ошибочным.

Помню проект, в котором самым важным требованием был хорошо работающий WebSocket. Что мы выбрали для создания бэкенда? Symfony, разумеется. Возможно, сегодня реализация WS на PHP будет выглядеть проще, но в то время это было кошмаром. Мы потратили много времени, чтобы заставить его работать. ОЧЕНЬ много. Мы знали, сколько времени (и денег) будет потрачено для создания WS на PHP, но мы отказались от идеи использования Node. Почему? Не могу сказать точно. На Node мы бы создали API в десять раз быстрее, но он не был в технологическом стеке нашей команды.

Я очень счастлив, что программисты в моей нынешней команде более открыты всему новому, чем был я. На прошлой неделе мы решили полностью заменить технологию, используемую для создания части нашей системы. Я уверен, что это решение сэкономит нам много времени, даже если придётся что-то учить с нуля.


Что я думал о решениях менеджера по продукту.

4. Владелец продукта/менеджер по продукту ошибается, я бы сделал лучше


Когда я работал программистом, мои отношения с менеджером по продукту были… натянутыми. Каждый раз когда он говорил мне о новых изменениях в содержании задачи, я думал: «Почему ты не можешь сразу сделать свою работу и определиться с задачей до того, как я начну работать? Разве так сложно решить заранее, как должна работать фича?»

Это было так наивно, но я действительно считал, что всё так просто. Теперь я полностью понимаю, как сложно спланировать каждую деталь проекта. Нужно учитывать ограничения технологий и бюджета (что на самом деле одно и то же), необходимо думать о пользователях, которые будут работать с твоим продуктом, нельзя забывать о требованиях бизнеса и маркетинга. Иногда некоторые требования неизвестны в начале; иногда меняются обстоятельства у бизнеса, а иногда нужно сначала что-то создать, чтобы понять, что это можно сделать лучше.

Ещё один аспект — менеджеры по продукту могут совершать ошибки. Да, всё так просто. Программисты создают баги и PM тоже. Сегодня это кажется мне настолько очевидным. Если бы я был программистом получше, то понял бы это раньше. Вместо того, чтобы пытаться доказать, насколько он ошибается, мне нужно было сосредоточиться на поиске решений.

Это иронично и печально, но в какой-то момент я забыл, что у меня и менеджера одна цель — создание отличного продукта. Просто у него гораздо больше знаний о бюджете, обстоятельствах у бизнеса, требованиях со стороны клиента, дедлайнах и приоритетах. Именно поэтому я не понимал некоторые его решения.

Подведём итог


Для кого-то из вас эти четыре пункта могут оказаться очевидными. Если вы работаете в отличной организованной agile-команде с хорошим руководителем и не забываете основные правила UX, то я искренне рад за вас. Наверно, вы можете быть гораздо лучшим программистом, чем был я. Ведь чтобы «быть хорошим программистом», недостаточно только технических навыков. Гораздо важнее понимать, какую ценность ты можешь принести компании, и как это сделать. Теперь я понимаю определение сениор-разработчика следующим образом:

Сениор-разработчик — это не тот, кто понимает каждый аспект технологии. Это человек, который поможет вашей компании создать качественный продукт, даже если это потребует от него выхода из зоны комфорта. Решения важнее, чем проблемы.




На правах рекламы


Подыскиваете VDS для отладки проектов, сервер для разработки и размещения? Вы точно наш клиент :) Посуточная тарификация серверов самых различных конфигураций, антиDDoS и лицензии Windows уже включены в стоимость.




Комментарии (194):

  1. Bellerogrim
    /#23013698 / +3

    > На Node мы бы создали API в десять раз быстрее

    «Если бы знали его так же хорошо, как Symphony», почему-то автор забыл добавить.

    • TheSprightlyDuke
      /#23013916

      Это явно следует из контекста:

      Symfony, разумеется.

      Почему «разумеется»?
      потому что не знали другие так же хорошо, как эти

      • Bellerogrim
        /#23014354

        Контекст там как раз «а вот на ноде это было бы легче и проще, и не надо держаться за зону комфорта, и забудьте что я говори в предыдущем пункте — сделать здесь и сейчас лишь бы-работало».

        • TheSprightlyDuke
          /#23014420

          Вербальный контекст — это законченный отрывок письменной или устной речи (текста), общий смысл которого позволяет уточнить значение входящих в него отдельных слов или предложений. Наличие вербального контекста всегда напрямую влияет на понимание любых сообщений, и отсюда часто встречающаяся в обществе ошибка цитирования, называемая «вырывание из контекста» (повторение некоторой усечённой части первоначального текста в ущерб его цельности, что может серьёзно искажать его исходное значение).

          При том, что Вы говорите правду, Вы вырываете её (понимаю, что случайно) из контекста, что приводит к ложному выводу.

          • dreesh
            /#23015238

            Комментарий улетел в закладки) Однажды кто-то сказал что, даже то что, негласно и очевидно всем, все равно должен кто-то сказать.

            • TheSprightlyDuke
              /#23015822

              Маленько занимательной математика:
              Когда я решил так сделать было три плюса у первого коммента. Уже восемь) А ниже, у DrPass так и намного больше)

              Вот он пишет:

              В конце-концов, если вы не знаете условный Node.js, почему вы решили, что вы создали бы там что-либо в десять раз быстрее,

              И это при том, что в статье ни слова не сказано, что они не знаю ноду. Там сказано:
              «но он не был в технологическом стеке нашей команды.»

              Более того. Там сказано:
              потому что не знали другие так же хорошо, как эти.
              *как эти, это про Симфони и Ангуляр

              Лично мне эта фраза говорит о том, что, вероятнее всего, учитывая контекст, Ноду они знают, просто не сильно хорошо.

              Стоит ли удивляться, что идиот у большинства разрабов клиент (я тоже так мыслил, одно время)? Про то, что это могла быть абстракция, пример, я вообще промолчу.

              • debagger
                /#23015874

                Лично мне эта фраза говорит о том, что, вероятнее всего, учитывая контекст, Ноду они знают, просто не сильно хорошо.


                Все правильно, если знаешь яваскрипт, то в каком-то смысле знаешь ноду. А яваскрипт они судя по всему знали, раз у них в стеке был англяр.

                • TheSprightlyDuke
                  /#23015884

                  Ну вот drPass, походу, считает иначе, раз пишет:

                  В конце-концов, если вы не знаете условный Node.js,
                  Хотя автор, это явно, пишет о недостаточно хорошем знании. И вообще, он это пишет в РЕТРОСПЕКТИВЕ. То есть сравнивает потенциал не в уме, а наглядно. Вот он и высказывает предположение
                  На Node мы бы создали API в десять раз быстрее
                  дополняя его фактологией
                  но он не был в технологическом стеке нашей команды.

              • dreesh
                /#23015888

                Или у них микроскоп для забивания кудрявых гвоздей)

                Как по мне, если создание "чудовища Франкенштейна" неизбежно, то пусть он будет красавицей хотя бы внешне (архитектура продумана)

                Возможен вариант ультиматума от красавицы, но тогда встает вопрос о трудо-затратах на дипломатические решения. Одно большое чудовище сложнее победить, чем множество маленьких подружить друг с другом)

                • TheSprightlyDuke
                  /#23015902

                  Нормально Вы так завернули, пришлось поперечитывать, чтобы быть уверенным, что понял всё правильно) Таки классика жеж. Поэтому не надо делать голову себе и людям, надо писать на асме!))) Подумаешь, бочкой таблеток не обойдёшься)

                  Если серьёзно, то фиг его знает, как правильно. Настолько всё неоднозначно для каждого проекта. Куча обвязки не касающейся кода. Бюджет, сроки, психотип заказчика и его умение/готовность понимать и принимать собеседника, компромиссы, двигаться в хотелках, пользователи и их тараканы итд итп. Бррр, жутко становится, как начинаешь думать про внекодовые обвязки)

    • JordanoBruno
      /#23015250

      Работал с Symfony и нодой, в том числе с WS. Могу сказать, что для нужд стартапа backend API с поддержкой WS можно сваять очень быстро — есть множество готовых фреймворков куда проще того же Symfony.
      P.S. Судя по тому, что Вы пишете с ошибкой — «Symphony», с ним Вы не знакомы явно :).

      • AndyPike
        /#23015374

        Да это же перевод на скорую руку, типа translate google. Смесь из англицизмов, которые совсем не соответствуют нормальным разговорным англицизмам, которые все понимают. У меня от «менеджер по продукту» слёзы текут. «PM» называется, Product Manager. Ну, или переводите нативно: «Главный по работам».

        1. Пользователь — это идиот

        Это нормальная среда для разработчика UI с учётом UX. Причём всё постоянно меняется. Клиент никогда не виноват, мы для них или для себя это делаем? Золотое правило разработчика.

  2. DrPass
    /#23013728 / +2

    Вот по поводу п.3 я бы возразил. Хорошо известный инструмент — это достаточно весомый аргумент, и если он походит для решения задачи, то лишь это вполне может стать решающим в выборе. В конце-концов, если вы не знаете условный Node.js, почему вы решили, что вы создали бы там что-либо в десять раз быстрее, если вам нужно
    а) выучить его
    б) сталкиваться с неизвестными вам «особенностями» в процессе реализации

    • alemiks
      /#23013998

      Да, поэтому банковский софт на Коболе, а в школе/институте изучают Паскаль. Потому, что "только их и знаем". Так и живём..

      • DrPass
        /#23014016 / +3

        А знаете, что самое забавное? Это не недостаток, как вы вроде бы считаете (ну разве что только в том плане, что специалиста по Коболу найти сложно).
        Паскаль — отличный язык для обучения азам программирования. Он простой, логичный и понятный. Стартовать с него легко, перейти на большинство других языков, кроме JavaScript'овых, тоже весьма легко.
        Ядро банковского софта же в массе своей делает элементарные операции, но делать оно их должно максимально быстро и максимально надёжно. Хотя насчёт Кобола вы скорее преувеличиваете, сейчас это где-то в единичных банках в США осталось разве что. Но все равно суть та же самая: это как раз та сфера, где основное правило при разработке звучит как «работает — не трогай».

        • Nalivai
          /#23014120

          Про паскаль имело хоть какой-то смысл до появляние пайтона, а теперь смысла нет, пайтон простой логичный и понятный, так им еще и пользоваться можно

          • mx-yh
            /#23014178 / +2

            Проблема Пайтона в том что после него, чтобы перейти на другой язык, вам придется начинать с 'нуля'. При том что Пайтон очень простой язык, он намного сложней обычного Си. После Паскаля перейти на Си просто, меняется синтаксис. После Пайтона переход на Си мучительный

            • Xambey
              /#23015350

              При том что Пайтон очень простой язык, он намного сложней обычного Си

              image

              • khim
                /#23015526

                Крайне корявая фраза, но смысл верный. Python (и JavaScript, кстати) — крайне сложные, просто фантастически сложные языки (C++ или там Java отдыхают), на которых, тем не менее просто писать корявые, неэффективные программы.

                Потому что они массу вещей скрывают. И вам про них, типа, “думать не нужно”.

                И пока вас устраивает что “весь пар уходит в гудок” (99% имеющихся у вас ресурсов уходят на “простоту”) — всё отлично.

                Но вот если у вас проект упирается-таки в ресурсы — то тут и возникает проблема: человек, начинавший с Pascal с этим разберётся (хотя и с матами), а человек, начинавший с Python — вряд ли.

                А с другой стороны: так ли это часто кому-то нужно? Умение программировать на Python (или, прости господи, даже на Excel) — сродни умению водить автомобиль, в современном мире нужно почти каждому. А вот умение что-то делать на более низкоуровневых языках — это сродни умению этот самый автомобить оттюнинговать (или вообще сделать с нуля). Многим ли это нужно?

                • Xambey
                  /#23015580

                  Думаю многие с вами не согласятся, особенно те, кто с ними работал по несколько лет. Я как раз такой, и как по мне, гоадация сложности здесь примерно такая: С — > С++ — > Java, c#, go, php, — > python, basic, pascal — > javascript, typescript, lua, bash — > asm, lisp, prolog, labview — это мой личный субъективный топ по сложности. Как по мне, web api, с которым обычно имеют дела через js, это по сложности просто букварь на фоне, скажем, STL c++ и того кол-ва синтаксического сахара, что там есть и который используется в 0.5% программ, и его все добавляют, хороший спец должен его знать и понимать...

                  • khim
                    /#23016282

                    Думаю многие с вами не согласятся, особенно те, кто с ними работал по несколько лет.
                    И вы знаете — какая будет сложность у констурукции из FAQ, да?
                    buf = ""
                    for i in range(50000):
                        buf += "foo"
                    print(buf)
                    
                    Подсказка: FAQ корректен для какого-нибудь Python на калькуляторе, но не для CPython.

                    А сколько строка в Javascript с тремя символами будет занимать в памяти — конечно в курсе? А сколько ещё таких подводных камней, нигде толком не описанных, в обоих языках?

                    Проработав на обоих языках несколько лет вы по врежнему будете порождать корявые и дико неэффективные программы. Да, блин, вспомните пресловутый новый дизайн GMail: почему, чёрт побери, там этот «ужас летящий на крыльях ночи», жрущий ресурсы как не в себя, и дико тормозящий?

                    Вот имено потому что люди знающие JavaScript и/или Python и люди, разрабатывающие на них программы — почти не пересекаются.

                    Потому что масса разных вещей, практически важных для написания эффективных программ, не описана в доках с описанием языка. Про них знают разработчики и те, кто случайно с ними столкнулся и потратил кучу времени, чтобы разобраться с одной какой-нибудь мелкой частностью.

                    Но разработчики языков прикладных программ не пишут (у них на это времени нет), а знание парочки граблей не защищает вас от сотен других, подобных же, которые пока вас по лбу не ударили.

                    И потому, даже проработав на этих языках лет 5 — вы, скорее всего, знаете о них очень мало.

                    Как по мне, web api, с которым обычно имеют дела через js, это по сложности просто букварь на фоне, скажем, STL c++ и того кол-ва синтаксического сахара, что там есть и который используется в 0.5% программ, и его все добавляют, хороший спец должен его знать и понимать...
                    Вот только в случае с STL и C++ вам достаточно открыть один сайт, прочитать один мануал — и всё, на 90% этого достаточно.

                    Случаи, когда нужно углубляться в проблемы конкретного компилятора случаются, да — но они никогда не приводят к тому, что что-то, что должно было, по вашим прикидкам, занимать десять байт, занимают 10 мегабайт или вместо одной микросекунду что-то работает секунду.

                    Однако да, у JavaScript, Python и Web API есть общая “фишка”: вы можете их использовать не зная их, на самом деле. Так “имея общее представление” — уже что-то можно “лабать”. А C++, уж если вы в него полезли, надо знать. И да, разумеется, не знать JavaScript и/или Python — проще, чем знать C++. Кто бы спорил.

                    Но это не делает их более простыми языками.

                    • SergioShpadi
                      /#23016562

                      Если JavaScript и Python настолько невыносимо плохие языки, то почему же они самые популярные?

                      Про JavaScript можно возразить, что это единственный язык для веба, и он стал популярным только из-за популярности веба. Но почему тогда на нем сейчас пишут и сервера (NodeJS) и мобильные приложения (React Native)? Для Python так вообще нет платформы, где его использование обязательно, но он все же стал де-факто стандартом в работе с данными и машинном обучении.

                      Может все дело в том, что JavaScript и Python действительно простые и писать на них код легко и приятно?

                      P.S.: вопросы о том, сколько памяти занимает строка и сложность алгоритма при 50000 итерациях, выдает в вас человека из мира С/С++. JavaScript-программисты не страдают так называемым «байтоебством». На фронтенде (и в большинстве случаев на бекенде) почти никогда не нужны сложные алгоритмы, а в списках редко бывает больше 50 элементов и почти никогда больше 200. Задача JavaScript-программистов чаще всего это «сходить в базу-данных» — «отдать данные фронтенду» — «отрендерить данные на фронтенде» — «обработать ввод пользователя» — «отослать данные на бекенд» — «записать данные в базу». Никакого рокет сайнса.

                      • DreamingKitten
                        /#23016618

                        Это обманчивая лёгкость из-за простоты прототипирования. Действительно, набросать какую-нибудь простую cli утилиту sloc на 50 быстрее всего на Python да и задеплоить её легче благодаря тому, что его пихают чуть ли не в каждую стиральную машину.

                        Но при этом что Python, что JS необратимо повреждают мозг неофитов нестрогой типизацией и автоуправлением памятью. И это вылазит такому неофиту очень боком при неизбежном дальнейшем знакомстве с технологиями сурового энтерпрайза, когда наряду с другим языком приходится осваивать и новые концепции, которые вынуждают его спускаться на пару ступенек абстракции над данными ниже, чем он привык.

                        • khim
                          /#23016658

                          Но при этом что Python, что JS необратимо повреждают мозг неофитов нестрогой типизацией и автоуправлением памятью.
                          Необратимости там, всё-таки, нет. Когда-то меня пугали тем, что поскольку я начал программировать не с Pascal, “как положено”, а с BASIC — то всё, я уже никогда нормально программировать не смогу (хотя в ранних версиях BASIC автоматическая работа была только со строками и массивами).

                          Разобраться со всем можно даже если начали программировать на MathLab каком-нибудь. Было бы желание.

                          Но вот как раз с желанием, как правило, и напряг.

                      • khim
                        /#23016644

                        Если JavaScript и Python настолько невыносимо плохие языки, то почему же они самые популярные?
                        По той же причине, по которой BASIC был популярен в последней четверти XX века (вначале простой, потом “Visual”): ни них просто писать программы, если вас не волнует качество результата.

                        Может все дело в том, что JavaScript и Python действительно простые и писать на них код легко и приятно?
                        Ещё раз. Вы путаете две, вообще говоря, не связанные между собой вещи: сложность языка и сложность использования языка.

                        Турка для приготовления кофе — на два порядка проще, чем кофемашина. Однако пользоваться кофемашиной проще… до тех пор, пока у вас есть какой-то “дядя” который, в случае чего, придёт и разберётся с тем, почему она вдруг, вам, вместо кофе, выдаёт только цветомузыку c шипением и звоном. И пока вас не волнует сколько стоит приготовление этого кофе.

                        И вот та же самая ситуация и с языками программирования: пока вас устраивает что “весь пар уходит в гудок” (99% имеющихся у вас ресурсов уходят на “простоту”) — всё отлично.

                        Как только ресурсы начинают вас волновать — так и выясняется, что JavaScript и Python нифига не просты.

                        Но почему тогда на нем сейчас пишут и сервера (NodeJS) и мобильные приложения (React Native)?
                        Потому что можно сэкономить на зарплате программистов. Особенно в случае с мобильными приложениями. Там за ресурсы вообще не вы платите, а тот, кто пользуется вашим приложением (и матерится, конечно… но вам-то с этого что?).

                        JavaScript-программисты не страдают так называемым «байтоебством».
                        Угу. А результат: когда я учился в школе мы спокойно редактировали там книжки в TeXе по 300-400 страниц на подаренных кем-то списанных IBM PS/2 30-286 с 286м процессором и 1 мегабайтом памяти (в качестве подработки). Без напряга. MIM, emTeX и вот это вот всё.

                        А сегодня то же самое сделать в каком-нибудь онлайн редакторе — боль и страдания. Притом что и памяти у меня на комьютера на четыре порядка больше и процессор на те же четыре порядка быстрее.

                        Тут даже не 99% ушли на простоту, а 99.999% (правда, стоит признать что не всё это — разница в языках, часть это разница в подходах).

                        На фронтенде (и в большинстве случаев на бекенде) почти никогда не нужны сложные алгоритмы, а в списках редко бывает больше 50 элементов и почти никогда больше 200.
                        Ага, а потом кто-нибудь размещает на DeviantArt тысячу картинок (или Хабре — тысячу комментариев) и у вас загрузка многогигагерцового процессора становится процентов 300 и работать с этим становится невозможно.

                        Никакого рокет сайнса.
                        Ну да. Только при этом всё время происходит какой-то “движ”, а когда выкатываются новые версии сайтов, то единственный вопрос, который возникает у пользователей это “господи, за что?”.

                        • hardtop
                          /#23017878

                          Вы так говорите, будто у веб-разработчиков был выбор: дали в браузерах только js — вот его и используют.

                          С бек-эндом ситуация не лучше. Тот же php не просто так стал популярным — в условном 98 году выбор был невелик (перл был тяжким).

                          • khim
                            /#23018474

                            В случае с PHP и javaScript — да, наверное. Всё упиралось в то, что на многих хостингах был только PHP, а в браузерах — только JavaScript.

                            Но Python, Ruby, NodeJS… они стали популярны, когда этой проблемы уже не было.

                            И вот именно потому что MVP на них сделать проще, а когда вы раскрутитесь — можно и на что-то другое перейти.

                            Во многих случаях это кончается совершенно дикими Франкенштейнами и ужасной архитектурой… но попытка сразу сделать хорошо кончилась бы тем, что ваш стартап бы загнулся до выпуска первой версии продукта и всё.

                        • sshikov
                          /#23018692

                          >Угу. А результат: когда я учился в школе мы спокойно редактировали там книжки в TeXе по 300-400 страниц
                          Ну, я такое и в MS Word редактировал. Даже где-то wysiwyg, точнее, есть preview. Лазерные принтеры поддерживал. И тоже в общем на гигабайте и 286 или 386 машинке.

                          • thealfest
                            /#23019584

                            На 286 и 386 не могло быть гигабайта.

                            • sshikov
                              /#23019708

                              Да, мегабайт конечно. Хотя суть в том, что сегодняшнему ворду и гигабайта будет маловато.

                              • khim
                                /#23022882 / +1

                                Вот примерно гигабайт и потребуется. Будет тормозить так же, как четверть века назад на 8 мегабайтах.

                                Только если понять, почему оно тормозит (но работает!) на 8 мегабайтах я могу (от “устаревшего подхода”, когда данные не грузятся в память целиком в MS Word'е отказались, так что ему нужно памяти столько, чтобы весь документ с картинками и графигами поместился), а вот на что ушли остальные 1016 мегабайт — для меня загадка.

                                На обслуживание “небайтоёбства”, надо полагать.

                      • Antervis
                        /#23016676

                        Но почему тогда на нем сейчас пишут и сервера (NodeJS) и мобильные приложения (React Native)?
                        чтобы расширить область применения JS-кодеров. Надеюсь вы не будете пытаться утверждать, что это лучшие технологии для юзкейсов.
                        Может все дело в том, что JavaScript и Python действительно простые и писать на них код легко и приятно?
                        хз, лично у меня от слабой динамической типизации горит как у ракеты. Особенно «приятно» когда x + 1 — 1 может умножить число на 10, а если адекватно валидировать данные, то кода получается в разы больше, чем на плюсах. Вы же понимаете, что простота этих технологий достигается за счет качества реализации? И вы пытаетесь доказать что раз качество реализации на JS/python недостижимо, то оно и не нужно
                        JavaScript-программисты не страдают так называемым «байтоебством»
                        легко говорить о байтоебстве, когда за ресурсы платит пользователь. И если забыть, что даже на этом, далеко не самом большом треде хабра, средняя мобилка уже будет тормозить.

                        • Xuxicheta
                          /#23017616

                          на js легко можно было бы написать чтоб не тормозила. Но почему то это не так.
                          А от типизации спасает статик чекер, типа тайпскрипт.

                          • khim
                            /#23018484

                            на js легко можно было бы написать чтоб не тормозила.
                            Для этого нужен не другой язык, а другие программисты.

                            А другие программисты найдут себе более благодарную работу.

                            Вам КО.

                        • csshacker
                          /#23018780

                          хз, лично у меня от слабой динамической типизации горит как у ракеты.


                          Как же хорошо, что в Python она не такая. Но зачем вникать в такие мелочи, правда?

                • TheSprightlyDuke
                  /#23015860

                  И пока вас устраивает что “весь пар уходит в гудок” (99% имеющихся у вас ресурсов уходят на “простоту”) — всё отлично.
                  Золотые слова, утащил)

                • ldss
                  /#23023080

                  в стандарте с++ 1151 страница:) Не думаю, что он проще js как язык:))

        • ToSHiC
          /#23014170 / +1

          Сильно подозреваю, что финансовая часть постоплатного биллинга в Билайне до сих пор на коболе.

        • alemiks
          /#23014288

          >>> Паскаль — отличный язык для обучения азам программирования. Он простой, логичный и понятный. Стартовать с него легко, перейти на большинство других языков, кроме JavaScript'овых, тоже весьма легко.

          согласен, только это было актуально примерно лет 20-30 назад. Щас он остался только в советских школах, только потому, что "только его и знаем" :) https://habr.com/ru/company/skyeng/blog/555098/

          Язык это же не только синтаксис, но и "экосистема" (тулинг, коммунити, вакансии, поддержка платформ). Для паскаля её на данный момент чуть менее, чем нету

          • DrPass
            /#23014470 / +3

            Язык это же не только синтаксис

            Вам не нужно знать конкретные фреймворки и тулзы, чтобы научиться программировать. Тем более что в школе или там на первых курсах ВУЗа вы ещё понятия не имеете, что вам пригодится.

            • alemiks
              /#23014720

              так а смысл учиться программировать на заведомо мёртвом языке? Для которого и помощь актуальную не найти, бест практисы из 70х-80х в лучшем случае; тулзы из 90-х. Или вы предлагаете преподавать перфокарты, авось изучат сами потом компьютеры, неизвестно же, на каком будут работать. Или изучать латинский язык. Ну и что, что мёртвый, зато изучив его, можно потом изучить другие. Да и неизвестно, какой пригодится

              • Areso
                /#23014820

                Ну и что, что мёртвый, зато изучив его, можно потом изучить другие.

                после латыни очень легко изучаются испанский, итальянский, с некоторой натяжкой — французский.

                • polearnik
                  /#23019588 / -1

                  а может сразу учить испанский , итальянский или французский? Да нет бред какой-то давайте мертвый язык изучать

                  • sshikov
                    /#23019738

                    Ну я вот начинал с Алгола 60. А потом работал на фортране. А потом PL/1 и REXX. И ассемблер S/360. И Perl. И все эти языки практически уже давно как мертвые (или очень нишевые). С технологиями и ОС такая же фигня — еще лет 15 примерно назад не было ни андроида, ни iPhone, и никто не слышал про такие языки, как котлин или Swift, которых не было тоже. А были Symbian и Windows Mobile, которые что? Правильно, умерли.

                    Так и тот язык, который вы изучите сегодня, с некоторой вероятностью тоже будет мертвый, может быть даже лет через 10 (если конечно не станет мейнстримом, а потом нелюбимым многими очередным коболом). Можете конечно изучать только мейнстримные языки — но тогда скорее всего пропустите много интересного.

                    • polearnik
                      /#23021056

                      так смысл в том что вы изучаете актуальный на данный момент язык , разбираетесь в нем и зарабатываете деньги и в случае если он внезапно окажется невостребован то перейдете на другой приглянувшийся язык. ваш опыт то никуда не денется.

                      Вместо этого предлагется изучать паскаль или латынь для того чтоб потом начать с нуля изучать другие похожие языки

                      • DrPass
                        /#23021320

                        так смысл в том что вы изучаете актуальный на данный момент язык, разбираетесь в нем и зарабатываете деньги

                        Это напрочь не входит в задачи школьного курса программирования и начального ВУЗовского «ОП и АЯ». Цель этих курсов не профессиональная подготовка, а просто научить составлять программы молодого человека, который в этом ни в зуб ногой.

                      • sshikov
                        /#23023292

                        Не, ну погодите, давайте еще раз — речь об обучении начинающих. Они не знают по определению ничего. И у них нет задачи изначально зарабатывать на этом деньги. Ну т.е. да, школа. И какая разница? И что лучше, простой язык, или практически применимый, но более сложный (не обязательно, но обычно все-таки да)?

                        • polearnik
                          /#23024724

                          и какие практические задачи вы можете решить с помощью паскаля ? НА питоне вы явно автоматизировать сможете.

                          • DreamingKitten
                            /#23024742

                            давно когда-то низкоуровневый софт писал на Паскале

                            детектор руткитов для винды, SMTP-релей, сбор и обработка статистики с кластера IIS, плагины для разного софта, шелл-коды, внедрялку невидимой DLL в процесс... да много всего.

                            • polearnik
                              /#23028698

                              а на питоне вы не справитесь? экосистема питона побольше паскальей будет. язык неплох в 90-х когда не надо было работать интернетом. но сейчас это атавизм.

                              • DreamingKitten
                                /#23029016

                                Дело не в экосистеме, а в том, что питон в принципе не предназначен для работы с низкоуровневым OS API. А речь идёт именно о периоде середины-конца нулевых, когда задач, требующих прямого доступа туда, ещё было достаточно много.

                                И вместо большой экосистемы в виде горы самописных os-agnostic велосипедов на любой случай более актуальным было знание возможностей API операционки и умение им пользоваться.

                                Та эпоха прошла, её задачи маргинализовались, и сейчас уже нормой считается пихать питон даже в какое-нибудь, прости господи, ардуино, а киллер-фишкой голанга (из синтаксиса которого со страшной силой торчат скриптовые уши) -- способность собраться в пухлый монолитный бинарник, чтобы удобнее было его в докер закидывать. Скажи я такое коллегам в 2005 году, засмеяли бы. А сейчас вполне можно быть востребованным и состоявшимся специалистом, ни разу не нюхав пороха в чём-нибудь типа ollydbg или ida pro.

                          • DrPass
                            /#23026120

                            Паскаль — это непопулярный сейчас язык, но ни разу не отсталый по функциональности. На нём можно без проблем решить любую задачу из тех, что вы решаете на других «десктопных» языках.

                            • polearnik
                              /#23028712

                              ну насчет "без проблем" вы явно загнули. то что он тьюринг полный это да но изза непопулярности для него не написано достаточно библиотек. поэтому эффективно решать задачи вы не сможете

                              • DreamingKitten
                                /#23029172

                                то что он тьюринг полный это да

                                эээ... там вообще-то вполне себе ООП есть.

                                для него не написано достаточно библиотек

                                Вот это, кстати, веяние скриптового времени. Язык считается более крутым, если в его рантайме доступно больше переписанных на нём же стандартных велосипедов, а вовсе не потому, что у него есть какие-то особые возможности, недоступные другим языкам.

                                Но это работает только там, где на питоне написано всё насквозь и код не спускается по уровням абстракции. При использовании традиционных библиотек, например, того же zlib, принципиальной разницы между "import zlib" и "uses zlib" нет -- они спускаются до ABI библиотеки более-менее одинаково.

                              • DrPass
                                /#23030520

                                Я не про тьюринг-полность, а как раз про практическую применимость в продакшене.

                                не написано достаточно библиотек. поэтому эффективно решать задачи вы не сможете

                                Хм. Достаточно — это для каких целей? Сделать какой-нибудь REST-сервер, который объекты гоняет из базу в JSON и обратно, так это делается за одну чашку кофе, что во FreePascal, что в Delphi.
                                Паскаль непопулярный, но не настолько, чтобы быть не современным :)

                          • sshikov
                            /#23027264

                            Вообще говоря — все теже самые. Вам возможно будет неудобно или сложнее — но тут скорее не вопрос возможностей языка, а наличия готовых библиотек на все случаи жизни. Тут конечно популярный язык выигрывает.

              • DrPass
                /#23014902 / +1

                так а смысл учиться программировать на заведомо мёртвом языке?

                Да просто потому, что это очень легко. Попробуте новичку объяснить, как работает хелловорлд на C# или Java. У вас в первой же простейшей программе будет куча понятий, которые вам надо будет сейчас «просто написать как есть», а потом в середине курса до них доберётесь. В Паскале такого нет, язык изначально создавался как учебный (Вирт его для продакшена и не позиционировал), где можно последовательно, от простого к сложному, изучить практически всё.

                • hhba
                  /#23015088

                  Вот, вот, рукоплещу! Все верно.

                  Добавлю только, что мне теперь начинает казаться, что Ада лучше. Она и в обучении хороша, и в жизни пригодится. Мне вот сейчас на нее пересесть и сделать хоть что-то — крайне сложно уже. Новички смогли бы.

                  • khim
                    /#23015530

                    У Ada ещё хуже с экосистемой, чем у Pascal. Начиная с Pascal хотя бы на Delphi или Lazarus можно пересесть и формочи поклепать немного.

                    А Ada заточена под вещи, которые моло кому нужны — всякие высокозагруженные надёжные системы, а банальных ORM к SQL фиг найдёшь.

                    • hhba
                      /#23016298

                      Начиная с Pascal хотя бы на Delphi или Lazarus можно пересесть и формочи поклепать немного


                      Такая себе перспектива )))

                      А Ada заточена под вещи, которые моло кому нужны — всякие высокозагруженные надёжные системы, а банальных ORM к SQL фиг найдёшь


                      Да, но эта ниша есть, и это уже совсем не так смешно, как «формочки клепать».

                      К тому же в Аде много разных интересных аспектов (во всех смыслах этого слова ;D), которые самое время и крайне полезно изучать именно в институте.

                      • khim
                        /#23016332

                        Такая себе перспектива )))
                        Лучше, чем необходимость идти грузить вагоны в три смены, так как с твоими суперкрутыми знаниями Ады тебя никто на работу не берёт (а кредит за обучение выплачивать надо).

                        К тому же в Аде много разных интересных аспектов (во всех смыслах этого слова ;D), которые самое время и крайне полезно изучать именно в институте.
                        “Крайне полезно” для чего? Для того, чтобы найти работу? Вряд ли.

                        А “для души” можно будет и потом почитать, если захочется.

                        • hhba
                          /#23022802

                          Лучше, чем необходимость идти грузить вагоны в три смены, так как с твоими суперкрутыми знаниями Ады тебя никто на работу не берёт (а кредит за обучение выплачивать надо)


                          Это верно. Впрочем и вакансий по этому направлению мало.

                          “Крайне полезно” для чего?


                          Для развития. По факту именно в студенчестве у вас наибольший ресурс для исследования и развития. Пусть даже вы вагоны разгружаете по ночам, да.

                          • khim
                            /#23022856 / +1

                            Для развития. По факту именно в студенчестве у вас наибольший ресурс для исследования и развития. Пусть даже вы вагоны разгружаете по ночам, да.
                            Это какой-то чисто российский предрассудок.

                            Когда вбухать кучу времени на просмотр какой-то муры на YouTube в 30 или там 50 лет — без проблем. А изучить что-нибудь — не, это удел студентов.

                            “Я уже большой, мне учиться не нужно”. А потом “плач Ярославны” про невостребованность и малую зарплату.

                            • hhba
                              /#23022874

                              Стоп-стоп, не передергивайте. Я про другое — про исследовательский ресурс в целом, а не только про ресурс времени. Скажу за себя — у меня сейчас есть опыт и широкий взгляд, но взять и запотеть серьезную тему _вглубь_ для меня сейчас крайне трудно, в сравнении со студенчеством.

                              И, да, лично я вместо Ютуба смотрю Хабр. И, да, это тоже mostly то еще «интеллектуальное времяпрепровождение».

                              • khim
                                /#23022904

                                Скажу за себя — у меня сейчас есть опыт и широкий взгляд, но взять и запотеть серьезную тему _вглубь_ для меня сейчас крайне трудно, в сравнении со студенчеством.
                                Это всё, как и любой навык, тренируется.

                                Тут больше не невозможности, а нежелания.

                                • hhba
                                  /#23022908

                                  Ну нет, это не навык, это типичное возрастное отупление. И оно не только у россиян, ей Богу. :)

                                  Но спорить конечно не буду. Может быть это только я один с возрастом тупею (в связи, среди прочего, с серьезными проблемами с кровоснабжением мозга, выявленными недавно).

                                  • dreesh
                                    /#23023296

                                    Мозг может научиться чему угодно в любом возрасте ( см. МРТ исследование мозга до/после экзамена для таксистов в Великобритании ), а вот переучиваться эт да) "Чем человек старше, тем больше ему лет (с) Кличко" и переучивать соответственно нужно больше переступая через внутренние конфликты.

                                    • hhba
                                      /#23023306

                                      Не мешайте моему самоуничижению ;)

                • ReaderReader
                  /#23019672

                  Да просто потому, что это очень легко. Попробуте новичку объяснить, как работает хелловорлд на C# или Java. У вас в первой же простейшей программе будет куча понятий, которые вам надо будет сейчас «просто написать как есть», а потом в середине курса до них доберётесь

                  У вас сильно устаревшие представления о C# Вот полный код Hello world на C# Больше ничего писать не надо. Где здесь та самая куча понятий, которая нужна здесь и сейчас, а доберемся мы до них когда-нибудь потом?
                  using System;
                  Console.WriteLine("Hello World!");

                  Проверить можно по линку
                  dotnetfiddle.net/N04mJc

                  • sshikov
                    /#23019752

                    Ну вот по сравнению с условным Groovy тут все практически такое.

                    println("Hello World!")
                    


                    А кто такие эти ваши System, и зачем мы его using? И почему Console? И что там за точка после нее?

                    Я не хочу сказать что тут куча лишнего, но два-три (лишних на данный момент) понятия вам таки придется новичку пояснить. И разница между простыми для изучения и практически полезными для работы языками все-таки наблюдается.

                  • DrPass
                    /#23019816

                    У вас сильно устаревшие представления о C#

                    «Сильно устаревшие» — это в смысле на несколько месяцев? Когда там эту фичу выкатили в прод, в ноябре или декабре 2020? Поверьте, за этот срок у C# шансов стать основным языком для образования не прибавилось.
                    Это не говоря уже о том, что как раз сама по себе функция main смысл имеет, т.к. что такое точка входа в программу, это то, что надо рассказывать на самом первом занятии. Вот всякие там using, void, Console, пустые скобочки где параметры пишутся, это уже сущности из серии «расскажем потом».

                  • Dario9000
                    /#23031524

                    Microsoft ® Visual C# Compiler version 4.8.4084.0
                    for C# 5
                    Copyright © Microsoft Corporation. All rights reserved.

                    This compiler is provided as part of the Microsoft ® .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see go.microsoft.com/fwlink/?LinkID=533240

                    HelloWorld.cs(2,1): error CS0116: Пространство имен не может напрямую включать в себя такие члены, как поля или методы

              • Dolios
                /#23014910

                так а смысл учиться программировать на заведомо мёртвом языке?

                Потому что этот инструмент хорошо подходит для обучения? У Кнута в книгах вообще несуществующий язык, если что. Книги по Паскалю все сожгли что ли?


                Для которого и помощь актуальную не найти, бест практисы из 70х-80х в лучшем случае; тулзы из 90-х.

                Какие вам нужны бест практисы и тулзы, чтобы научиться писать циклы, рекурсии и сортировки?


                Или изучать латинский язык

                Еще раз повторю, вы изучаете не язык, а алгоритмизацию. Меня в автошколе учили водить на 21099. После получения ВУ я ни разу потом за руль 21099 не сел, но я могу управлять любым другим массовым легковым автомобилем. Я не понимаю, почему вы так зацикливаетесь на языке, я их штук 15 разных использовал за свою карьеру, точно не помню даже, и к Паскалю вот вообще никакого негатива не испытываю.

                • sumej
                  /#23016742

                  Я учил Паскаль в школе в универе. Не очень то он помог мне с Jacascript, Scala, Python, Go.

                  Его помощь не превышала псевдоязык, на котором мы кенгуру по клеточкам гоняли.

                  • akhmelev
                    /#23017988

                    Когда на горизонте появился Паскаль мы учили Фортран. И все тоже потом на окончании универа ныли, что Фортран отстой и зачем мы его учим, когда вот же есть Паскаль с турбовижн - крутейшая круть на которой крутой софт пишут. А Дельфи и вовсе космос. Но циклы разветвления и рекурсии и на Фортране и на паскале являются одним и тем же объектом для изучения.

                    Правда в том, что все тупо хвалят СВОЙ язык. На котором работают просто. Сейчас. Но мыслить стоило бы шире, язык для работы и язык для учебы ДОЛЖНЫ быть разными. С учётом динамики IT Java сейчас и Java пять лет назад не очень то похожи, хотя это один и тот же язык. Можно начинать возмущаться, почему мы не учили функциональщину, она вон как нужна. То же самое и в вашей претензии. Не было в этих ваших универах тогда го. Его и в мире не было. Как его учить то?

                    А если вспомнить, что турбопаскаль шарпы и тайпскрипт разработал один и тот же человек, то лучи поноса в сторону Паскаля и вовсе нелепы. Всему свое время просто.

                    Вывод: не ругайте другие языки. Даже уходящие. Это глупо. Просто в недалёком завтра Скала Пайтон и Го будут древним отстоем, не сомневайтесь. Выход в том, чтобы знать просто больше. В том числе и языков. Разных.

              • DreamingKitten
                /#23016366

                Для которого и помощь актуальную не найти, бест практисы из 70х-80х в лучшем случае; тулзы из 90-х.

                Вы в курсе о существовании FPC и Lazarus ? Там и с комьюнити и с поддержкой платформ всё в порядке.

          • Dolios
            /#23014670

            Язык это же не только синтаксис, но и "экосистема" (тулинг, коммунити, вакансии, поддержка платформ).

            Язык, это, прежде всего, инструмент. Учат не Паскалю, учат основам алгоритмизации. И Паскаль для этого отлично подходит. При чем тут вакансии, коммунити и поддержка платформ?

          • geher
            /#23016972

            согласен, только это было актуально примерно лет 20-30 назад. Щас он остался только в советских школах, только потому, что "только его и знаем"

            "А мужики-то не знают" (с)

            Embarcadero до сих пор выпускает коммерческие версии IDE с поддержкой Object Pascal, Также до сих пор развивается опенсорсный FPC (и Lazarus с ним).

            Есть даже средства для разработки приложений на Паскале для мобилок и микроконтроллеров.

            Ну да, наверное, это все "советские школы".

            • alemiks
              /#23017154

              беглое гугление показало, что мужики 1) поддерживают легаси и 2) так привычнее

              https://www.quora.com/What-companies-use-the-Delphi-programming-language-extensively?share=1

              https://www.quora.com/Is-anyone-using-Embarcadero-Delphi-these-days?share=1

              Скорее всего, пока это даёт профит эмбаркадерам

              • geher
                /#23019460

                беглое гугление показало, что мужики 1) поддерживают легаси и 2) так привычнее

                Естественно. Только и 1, и даже 2 будут продолжаться еще очень долго, причем не только в советских школах, особенно если учесть, что советских школ стало гораздо меньше, если вообще остались.

                Кстати, интересно, являются ли советскими школы современных КНР и КНДР, и какие языки там дают на информатике, если она там есть? Реально интересно, без какого либо подтекста.

            • /#23023876

              Да, в основном именно "советские школы", ну и немного седых дедов из других стран.

              Откройте HH, Glassdoor и LinkedIn, и сравните относительное количество вакансий для разработчиков на Pascal/Delphi с количеством позиций C++/Java/C#/JS/Python для Мск/СПб в России, в странах ЕС и в США.

              Полученные результаты как никогда точно и однозначно расскажут вам о реальной живучести и востребованности языка, да.

              А если из полученных списков ещё выкинуть покрытые ржавчиной и плесенью легаси-проекты... впрочем, не будем о грустном.

        • sbw
          /#23018754

          Кобол используют 43% банков, 95% банкоматов:

          According to Reuters, you can find 220 billion lines of code still in production. From many federal government agencies to your local bank, COBOL is still in use. An estimated 43% of banking systems and 95% of ATM swipes utilize COBOL code.

          https://www.bmc.com/blogs/cobol-trends/

          • sshikov
            /#23019768

            Ну это надо поделить на 2, если не на 10. Кобол, даже современный, довольно таки многословен. Явные объявления, главным образом, там где во многих языках они либо вообще не нужны, либо пишутся короче.

    • hhba
      /#23015060

      Именно так. А исходной предпосылкой является кнутовское «Преждевременная оптимизация — корень всех зол». Он говорил, правда, про программирование, а не про разработки вообще или управление разработками вообще, но суть та же. Ну и это вот «Самый короткий путь — который ты знаешь» сюда же.

    • greenkey
      /#23015542

      Весомый, безусловно. И вот тут появляется необходимость весьма тщательно оценивать и другие инструменты, потому что чем выше лежит ошибка (неудачный выбор архитектуры, стека и т.п) — тем дороже эта ошибка будет стоить.

    • TheSprightlyDuke
      /#23015856

      С чего Вы решили, что они не знают Ноду, если там даже фраза есть. Вот такая:

      потому что не знали другие так же хорошо, как эти
      Не находите, что она говорит о том, что Ноду они знают, просто не так же хорошо, как Симфони и Ангуляр?

  3. SadOcean
    /#23013736

    «Я буду использовать для этого проекта «X», потому что знаю его»
    Это не заблуждение, это очень хороший аргумент. Просто нужно помнить, что он не единственный и не исчерпывающий.
    Можно сформулировать его так — «Для решения задачи можно использовать «X»,«Y»,«Z», из них Я лучше всего знаю «Y», поэтому буду использовать его»

    • maxzhurkin
      /#23013890

      Это ещё и весомый аргумент, но, опять, не всегда он может перевесить другие

    • awfun
      /#23015016

      В большом проекте кроме знаний командой языка и фреймворка существуют обвязка:
      — самописные утилиты для стандартных функций (проверки, логгирование запросов и тд)
      — деплоймент
      — сбор логов в определенном формате
      — мониторинг
      — генерация апи
      Таким образом, делая выбор в пользу ранее не использованного инструмента, нужно быть готовым отказаться от части наработанных технических решений

    • JordanoBruno
      /#23015978 / +1

      Забивать гвозди микроскопом только потому, что у Вас есть микроскоп и Вы хорошо им умеете пользоваться - это не самая лучшая идея.

      • khim
        /#23016294

        Считать всегда надо. Python на микроконтроллерах — это оно самое и есть. И да, вам, в результате, требуется на порядок более мощный и дорогой микроконтроллер.

        Но если, на практике, это “микроконтроллер за тридцать рублей вместо микроконтроллера за три рубля” и это вам экономит тысячу на оплате программиста… почему нет? При тираже в десяток экземпляров это выгодно. Да и при тираже в сотню может оказаться выгодно, если позволит вам быстрее результат заказчику показать и финансирование получить.

      • SadOcean
        /#23019336

        Я ведь уточнил — если и Я знаю инструмент И он подходит для задачи — это хороший аргумент.
        То есть речь априори не про микроскоп, речь про то, что если картину нужно повесить и есть выбор — клей, шурупы или гвозди, а у меня есть шуруповерт — это вменяемо.
        Проблемы как обычно на стыке — когда используется профессиональный сварочный аппарат для детали, которой бы хватило 10 грамм ПВА
        Или когда забитый крутыми инструментами верстак используют как обеденный стол (он ведь тоже стол), а потом начинаются проблемы с хранением кастрюль.

        Ну то есть если тебе нужно сделать аркаду на 10 минут, для нее лучше подойдет Unity, но если ты регулярно используешь Unreal — нормально написать на нем. Да, десяток метров оверхеда, зато результат получится гораздо быстрее.

  4. crocodile2u
    /#23013928

    Пример в п 2 как бы говорит — не бойтесь писать без тестов. Кроме того, там сказано, что проект развалился — так может, низкое качество результата после отказа от тестов было причиной? Звучит как: ты живешь в хорошем районе, ходишь в дорогой супермаркет, ты слишком закрыт для всего нового, попробуй коробку из-под холодильника и помойки! Не хочешь? Ты закрыт для всего нового! Все равно попробуешь.… Ой, и правда, лучше не стало. Ну извини.

    • DrPass
      /#23013978

      Вообще, я могу достаточно уверенно сказать, что вы ошибаетесь. Если речь идёт о выпуске MVP, то писать тесты — это одно из самых худших вложений ресурсов разработки, которые только можно придумать. «Окупаемость» тестов практически в 100% наступает после какой-то достаточно отдалённой стадии развития и усложнения проекта, и соответственно каждый написанный тест во время разработки MVP — это просто время, на которое вы отодвинули получение инвестиций в ваш проект. И очень хорошо, если вложенных в пресейл средств хватит на подобное баловство. А может и не хватить.

      • NikolasSumrak
        /#23014132 / -1

        Нельзя так просто взять, и сказать, что тесты для MVP - говно. Или - наоборот, серебряная пуля.

        Я могу привести примеры проектов, где тесты только тормозили замену логики работы фич, и примеры проектов, где потраченный на автотест час экономил 8 человеко-часов команды на реопен бага и перетесты.

        • DrPass
          /#23014182

          и примеры проектов, где потраченный на автотест час экономил 8 человеко-часов команды на реопен бага и перетесты.

          Это был точно MVP? ;) И даже если вдруг так (хотя сильно сомневаюсь), это один частный тест. А сколько команда сэкономила бы, если бы тестов в MVP вообще не было, ни этого за 1 час, ни десятков других, каждый тоже по часу-два-три?

          • NikolasSumrak
            /#23015986

            Я не говорю, что тестами нужно покрывать все. Но неужто у вас никогда не было сложных алгоритмов, которые гораздо быстрее протестировать программно, нежели руками?

            • DrPass
              /#23016066

              Конечно, были. Даже несколько. За более чем 20 лет практики. А у вас разве чаще?
              И вам не кажется, что это слишком уж частный случай, чтобы принимать его во внимание?

            • JordanoBruno
              /#23018580

              MVP — это несколько месяцев работы 1-3 разработчиков, а за это время много реально сложных алгоритмов физически не напишешь, так как доля этих алгоритмов в общем объеме кода стартапа обычно крайне невелика. Никто ж не запрещает вообще не писать тесты, ну покройте свой алгоритм, потратьте день.

      • PrinceKorwin
        /#23014296 / -1

        Если речь идёт о выпуске MVP, то писать тесты — это одно из самых худших вложений ресурсов разработки

        Не соглашусь с вами. MVP - предполагает, что решение должно выполнять хоть и минимум, но бизнес задачи.

        Тесты нужны чтобы понимать, что оно решает корректно поставленные перед MVP задачи.

        Если тесты написаны грамотно, то они также будут полезны при написании уже production решения.

        Я, в целом за тесты. Т.к. на моей практики это как раз тот инструмент который очень сильно экономит деньги и ресурсы в разработке.

        • DrPass
          /#23014450

          Не соглашусь с вами. MVP — предполагает, что решение должно выполнять хоть и минимум, но бизнес задачи.

          Ну так для этого тесты ведь не нужны. Тесты нужны, чтобы оно выполняло бизнес-задачи качественно. А ещё они нужны, чтобы в крупном проекте внесение новых изменений не ломало существующий функционал. Т.е. всё то, чего от MVP не требуется в принципе.

          • PrinceKorwin
            /#23014916

            Хм. Тогда мы просто разный смысл вкладываем в понятие MVP.

            Вот про PoC я бы с вами согласился.

            • DrPass
              /#23014974

              MVP — это то, что можно продемонстрировать, заинтересовать и заключить контракт на разработку. PoC — это просто проверить/показать работоспособность идеи. Да, первое обычно сложнее второго. Но тем не менее, требования к MVP совершенно не те, что к продакшену, это по сути просто дорогая разновидность пресейла. И в порядке вещей MVP вообще полностью переписать, если проект получил «зелёный» свет.

      • Alex_ME
        /#23014812

        А как писать-то? Вот пишешь ты модуль, который работает в связке с другими модулями? Как вообще проверить, что это все работает? Каждый раз запускать программный продукт и подходить необходимую, возможно, сложную, последовательность действий руками? Каждый раз? А если не всё ещё написано?

        По моему опыту, 80% ошибок, находимых юнит тестами, находятся на этапе реализации модуля, когда он ещё не написан до конца/неправильно. Не знаю, как вы, а я правильный код с первого раза без проверки не могу написать

      • TheSprightlyDuke
        /#23015870

        Без тестов идёт перекладывание дебага итп, причём даже базовых, на пользователя. По какому праву, мне любопытно?

        • DrPass
          /#23016084

          Как-то у вас всё слишком радикально получается. И перекладывание на пользователя у вас так сразу и безальтернативно произошло без юнит-тестов, и этот процесс вас почему-то возмутил… Поспокойнее надо быть, помягче, так сказать :)

          • TheSprightlyDuke
            /#23016632

            229 символов слабать вместо ответа на простой и прямой вопрос, да ещё и наврать, и оболгать оппонента, ну, такое себе действо) Но проехали, раз не хотите, не вопрос)

            • DrPass
              /#23016854

              Я вам ответил как раз по сути. Ваш простой и прямой вопрос — какая-то нелогичная хрень, и какой ответ вы на него ожидали? Вы не в курсе, что
              а) есть куча способов делать дебаг приложения без юнит-тестов, не перекладывая его на пользователей?
              б) что вовлечение пользователей в тестовый процесс — это не правонарушение, а тоже нормальная и распространённая практика, и жжение в одном месте не должна вызывать в принципе, ни у вас, ни у пользователей?

              • TheSprightlyDuke
                /#23016880

                Вообще, я могу достаточно уверенно сказать, что вы ошибаетесь. Если речь идёт о выпуске MVP, то писать тесты — это одно из самых худших вложений ресурсов разработки, которые только можно придумать. «Окупаемость» тестов практически в 100% наступает после какой-то достаточно отдалённой стадии развития и усложнения проекта, и соответственно каждый написанный тест во время разработки MVP — это просто время, на которое вы отодвинули получение инвестиций в ваш проект. И очень хорошо, если вложенных в пресейл средств хватит на подобное баловство. А может и не хватить.
                Не стесняйтесь, ткните пальцем, где в Вашей цитате этой хоть слово об иных, более эффективных методах дебага, нежели тесты.

                Я ни слова не говорил про юнит-тесты, я говорил про тесты. В ответ на Ваш коммент, где тоже речь о тестах, а не о юнит-тестах. Вы пытаетесь вменить мне то, чего я не говорил. И пытаетесь ввинтить в свою позицию то, чего изначально не было. Ну и кто из нас нелогичную хрень пишет?

                а) есть куча способов делать дебаг приложения без юнит-тестов, не перекладывая его на пользователей?
                Это вообще что? Вопрос о том, что кроме как заставить пользователей быть тестерами, нету способов дебага, или утверждение в форме вопроса?

                б) что вовлечение пользователей в тестовый процесс — это не правонарушение, а тоже нормальная и распространённая практика, и жжение в одном месте не должна вызывать в принципе, ни у вас, ни у пользователей?
                А здесь знак вопроса к чему? Вовлечение пользователя с его согласия и уведомление, что это альфа/бета/итп и явное указание, что может быть куча багов итд, да, нормально. Вот только этого не делают, да и не о таких случаях речь, разумеется, с ними всё в порядке.

                Вы разводите балаган. Всего доброго.

        • /#23016338

          Пользователь получает ускоренный доступ к новому продукту. В качестве благодарности за это он участвует в тестировании.

          • TheSprightlyDuke
            /#23016652

            Почему я не сомневаюсь, что Вы не захотите, чтобы обувь, что Вы купите была «ускоренного доступа» с возможностью отблагодарить производителя своим участием в тестировании оной?

            • /#23016984

              Может быть захочу. Тогда закажу себе вот эти инновационные башмаки на кикстартере и приму участие в тестировании.

              • TheSprightlyDuke
                /#23017014

                Я ни слова не говорил ни про Кикстартер, ни про инновационности. И я ни слова не говорил о контролируемом «ускоренном доступе». Вы, по ходу дискуссии, пытаетесь сформировать удобные для своей позиции условия, которых в исходных условиях дискуссии не было. Так не делается.

                • /#23017022

                  А я ни слова не говорил про обувь, это вы решили применить дискуссионный прием подмены предмета, подменив ПО обувью. В нормальной дискуссии так не делают, но раз уж вы решили так поступить, я указал что и ваш нечестный прием не позволяет достичь нужной вам цели.

                  • TheSprightlyDuke
                    /#23017032

                    Хороший ход!) Но мимо. Я лишь предложил аналогию, которые Вы вправе отвергнуть, приведя аргументированное доказательство отказа.

      • OnYourLips
        /#23016594

        Если речь идёт о выпуске MVP, то писать тесты — это одно из самых худших вложений ресурсов разработки, которые только можно придумать.

        Я категорически не соглашусь. Я делаю задачи с интеграционными тестами быстрее, поэтому MVP будет быстрее. Окупаемость происходит сразу. Потому что без них приходится несколько раз проверять руками, поэтому набросать пару мелких тестов с запросом и проверкой кусочка ответа просто быстрее.
        Естественно это не полноценное покрытие тестами на 90%, выходит только около 70%. И это интеграционные тесты, а не юнит-тесты.

        • DrPass
          /#23016858

          Вообще, я имел в виду как раз юнит-тесты, про них шла речь в контексте. Интеграционные в простых MVP-приложениях занимают не очень много времени, ошибки выявляют, а их невысокий уровень локализации места ошибок вполне достаточен. Поэтому я вам и возражать не буду, я не против интеграционных тестов в MVP, если это даст выгоду.

          • OnYourLips
            /#23017044

            Если это только крудошлепство, то юнит-тесты не нужны совсем, даже если на них есть время.
            А если там калькулятор, то юнит-тесты по нескольким отдельно взятым классам тоже ускорят разработку и сами не займут много времени. Как и интеграционные тесты по всему компоненту.
            Надо смотреть конкретную задачу, чтобы понять возврат инвестиций от тестов относительно скорость разработки. И у некоторых задач время этого возврата — "сразу".


            Разработчик с опытом должен понимать, когда надо писать тесты, а когда их писать не надо. А менеджер с опытом не должен лезть к разработчику с опытом и давать советы про то, в чем он некомпетентен.

  5. ivankudryavtsev
    /#23013982

    Автор был инженером с узким кругозором, стал CTO и понял, что у него узкий кругозор/узколобость.

    Выглядит как мировоззрение джуна, которого внезапно произвели в CTO.

    У программистов много фокусов, но большая их часть вне профессиональной сферы.

    • un1t
      /#23014678

      Ну может не джуна, но как минимум он пропустил роль тимлида и менеджера и сразу стал CTO, что довольно странно.

      • olegborzov
        /#23015346

        Может он CTO в компании где 3-5 разработчиков. Как раз и получается тимлид средней команды.

    • naishin
      /#23018366

      Был хреновым программистом и и считал пользователей баранами. Стал хреновым менеджером и теперь считает программистов баранами.

      Следующее откровение - не все программисты такие бараны как автор :)

  6. NeverIn
    /#23014004

    Статья похожа на стеб, в стиле «антипаттерны», став СТО автор осознал ошибки. которые ошибками не являются.

    Вот они 4 пункта:

    • Кто-то начинает проект с отсутствием бюджета, а потом «давай-давай» надо в срок.
    • Владелец продукта не может описать видение фичи — потом доделаем.
    • Менеджер забивает на тесты — и так работает, съэкономим.
    • И да, вишенка на торте — давайте возьмем технологию X — шеф что-то слышал на конференции про нее крутое.

    • andreyiq
      /#23015820

      1. Сроки поджимают не только из-за отсутствия бюджета

      2. На первом этапе не всегда есть четкое понимание фичи, поэтому выпускают как есть, чтобы как можно быстрее получить отзывы от реальных пользователей и тогда уже станет более понятно в каком направлении развивать

      3. Опять же на начальном этапе чаще всего тесты, чистый код и вот это вот все - зло. Нужно максимально быстро выпустить продукт для проверки жизнеспособности идеи

      4. С этим соглашусь. Все новое лучше на каких-то мало важных и не срочных проектах обкатывать

  7. genuimous
    /#23014018

    Приводятся врачи как образец не тупого пользователя. Ну еще бы, у них образования в несколько раз (а то и на порядок) больше чем у программистов, иной раз больше, чем у всего отдела вместе взятого. Они решают сложные и важные задачи, они типа прослойка интеллигенции: ) Разумеется, врачи умнее и имеют более высокий IQ, чем, скажем, продавец или кассир или таксист. Так что вывод хоть и правильный, но основан на нестандартных данных. Далеко не все пользоватали и врачи. И многие из них, увы, интеллектом не блещут. Что, с другой стороны, не дает повода не считаться с ними.

  8. bibliary
    /#23014190 / -2

    CTO стартапа из 3 человек… хоть бы уже не позорился лычкой и экспертным мнением. Хотя учитывая как он считал себя «синьёром»…

  9. ArVaganov
    /#23014376

    Типичная история, как только человек переходит из разработки в менеджмент, то оказывается и архитектура продуманная не нужна, и юнит-тесты не нужны и документация бесполезна. И вообще надо было MVP фигакс-фигакс в продукшен.

    Вот только уже не ему этот код расширять, поддерживать и ночами чинить неотловленные юнитами (которых нет) баги, а разработчикам.

    Уважаемый СТО, давайте каждый специалист будет заниматься своей зоной ответственности.

    • tcapb1
      /#23014424

      Если у вас есть большие инвестиции и бизнес-модель - да, можно сразу и с тестами и с архитектурой и с документацией. Если же нет, то учитывая что большинство стартапов не взлетают, то уж лучше переписать потом уже работающее решение с нуля (благо шишки уже набиты и есть фундамент для архитектуры), чем выйти за бюджет и не выпустить продукт вовсе или потратить слишком много времени=денег на этот продукт и не успеть выпустить другой, работающий.

      Да, есть риск того, что с нуля переписывать будет слишком накладно, есть риск того, что практики тяп-ляп и в продакшен останутся и в коммерческом продукте, но лучше так, чем утонуть в разработке, про которую даже не знаешь окажется ли она полезной.

    • DrPass
      /#23014484 / +2

      Вот только уже не ему этот код расширять, поддерживать и ночами чинить неотловленные юнитами (которых нет) баги, а разработчикам.

      Ну да, вот только делать они это будут, как правило, в своё рабочее время, в своём уютном рабочем кресле, и за хорошую рыночную зарплату.
      И знаете что? Если не выпустить MVP фигакс-фигакс в продукшен, не показать его как можно раньше заказчику и не пропихнуть проект, чаще всего уютные рабочие кресла и хорошую рыночную зарплату этим разработчикам придётся искать уже в каком-то другом стартапе. Вот такая вот зараза, этот рынок.
      Манагеры, они далеко не всегда такие вот тупые. Они просто код рассматривают не с позиции «насколько интересно его писать и ненапряжно сопровождать», а с позиции «принесёт он прибыль или нет».

      • awfun
        /#23014922

        в своё рабочее время, в своём уютном рабочем кресле, и за хорошую рыночную зарплату

        За одну и ту же зарплату работать в спокойном режиме, или фиксить проблемы на горящем продакшене — две большие разницы, не удивительно что разработчики предпочитают первый подход.
        Думаю, нужно четко различать разницу между работой для MVP/пресейла и разработкой, которая предполагает долгосрочность. Менеджеры в любом случае будут топить за реализацию функциональных требований, и только разработчик может напомнить о нефункциональных (сложности внесения изменений, масштабируемости и пр).

        • DrPass
          /#23015002

          Думаю, нужно четко различать разницу между работой для MVP/пресейла и разработкой, которая предполагает долгосрочность.

          Именно так
          Менеджеры в любом случае будут топить за реализацию функциональных требований

          Менеджеры разные бывают. В общем случае менеджер, если он не совсем уж дятел, понимает, чем чревато низкое качество кода на продакшене, и в состоянии оценить риск. Могу сказать, что разработчиков слушать надо всегда, но вот слушаться или нет, тут уж надо думать головой :)

      • TheShock
        /#23017974

        Манагеры, они далеко не всегда такие вот тупые. Они просто код рассматривают не с позиции «насколько интересно его писать и ненапряжно сопровождать», а с позиции «принесёт он прибыль или нет».

        Это просто способ переложить вину. Менеджер чтобы продать называет нереальные сроки, а потом заставляет программиста под ними подписаться. Когда глупый и неопытный программист ломается под давлением — он становится жертвой. Через 3 месяца менеджер молодец, что продал, а всё сломалось из-за криворукого программиста, который не может написать нормальный код. И тот сидит ночами без оплаты овертаймов, чтобы починить баги, которые являются следствием того, что менеджер переклал свою вину за неправильные сроки на программиста.


        Представьте женщину, которая хочет родить ребёнка принципиально в этом месяце (ну вот всегда мечтала про тельца). И вот на 5-м месяце она заставляет хирурга достать ребёнка. А потом уже пусть подрастает. Пока на хирурге никакой вины за слабое здоровье малыша нету, но если он согласится — будет глупцом.


        Да, прототипы можно сделать быстро и на скорую руку. Но для того, чтобы делать такие прототипы нужно уметь после окончания прототипа убедить менеджера его выбросить и написать с нуля. Обычно же менеджер соглашается: "да-да, я понимаю, не расширяемый прототип", зная, что через 3 месяца он прогнёт программиста и заставит этот мертворождённый продукт поддерживать.

        • KGeist
          /#23020834

          >Это просто способ переложить вину. Менеджер чтобы продать называет нереальные сроки, а потом заставляет программиста под ними подписаться

          Поэтому сроки нужно согласовывать с разработчиками и сразу выделять пул некритичных фич на вылет, если сроки поедут.

  10. edo1h
    /#23014422

    ИМХО пункты 2 и 3 про одно и то же, только с разным знаком.


    старый всем известный анекдот

    Решили проверить уровень интеллекта у человека и обезьяны. Подвесили вместо люстры банан и завели в комнату обезьяну, обезьяна увидела банан и начала прыгать безрезультатно пытаясь достать его тут раздается голос "думай!". Обезьяна остановилась, подумала, огляделась увидела в углу стол, придвинула стол, залезла на него и достала банан. Следом в ту же комнату завели мужика, а вместо банана подвесили бутылку водки. Мужик попрыгал, попрыгал бутылку достать не смог. Тут опять раздается голос "думай!". Мужик остановился, подумал, огляделся, почесал репу и молвил "Че тут думать? Тут прыгать надо, а не думать!"

  11. Antervis
    /#23015070

    Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.
    а без юнит тестов точно бы справились?

    • JordanoBruno
      /#23015256

      Без юнит тестов и прочих необязательных вещей они могли успеть запустить MVP, прежде чем кончился бюджет. Лучше запускаться без тестов, чем вообще не запускаться, не находите?

      • HellWalk
        /#23015348

        Может лучше владельцем бизнеса браться за те идеи, на которых у них хватит денег? И хватит с запасом, а не так, что «мы тут посчитали, получилось 10 миллионов, вот ровно столько у нас и есть»

        • JordanoBruno
          /#23015376

          У 100% стартапов которые я знаю как запускались(а знаю я не один десяток), до MVP ни один не выдержал предполагаемых сроков. Соответственно, и бюджет превысили. Битые стартаперы уже заранее это знают и закладывают 20-30-50% времени/денег плюсом, но есть масса нюансов, да и инвесторы — живые люди с эмоциями. Если кто-то заявляет точную сумму для запуска стартапа, например 10 лямов 100 рублей, то это либо проходимец, либо глупый человек.

      • Antervis
        /#23015838

        Лучше запускаться без тестов, чем вообще не запускаться, не находите?
        выводы автора построены на нескольких предположениях:
        1. их провал не был безусловным;
        2. они бы представили достаточно рабочее решение без тестов в срок;
        3. отсутствие тестов не провалило бы их проект в будущем;
        4. отсутствие культуры разработки не спровоцировало бы разработчиков увольняться.
        В статье автор не приводит основания своих предположений. А теперь с точки зрения разработчика, что лучше — проработать год на проекте с чистым кодом, или тянуть три года в проекте с велосипедами из костылей?

        • JordanoBruno
          /#23016026

          проработать год на проекте с чистым кодом

          Если хочется чистого кода — я бы посоветовал не идти в стартап. Процентов 70 стартапов до MVP лепится из говна и палок, остальные пишут чистый код и играются с новыми технологиями. Потом, правда, 90% таких стартапов с чистым кодом закрываются из-за того, что долго пишут или проблем с новыми технологиями.

  12. KGeist
    /#23015280

    Del

  13. HellWalk
    /#23015322 / -1

    Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.

    Разумеется, замечательно писать код, который ты можешь показывать другим и гордиться. Но ещё лучше успешно завершать проекты.

    Да сколько можно доказывать эту чушь…

    Начнем с конца: лучше успешно завершать проекты — для владельцев бизнеса и руководства — да. Программист получает зарплату за реализованный функционал через написание кода. И отвечает за корректную работу функционала и код, с которым потом могут работать другие программисты.

    Хватит на плечи программистов перекладывать ответственность за бизнес!

    Второе, про MVP за короткое время. Проходили, знаем. Вначале от программистов требуют только скорость разработки MVP, а потом, через год, будут искренне удивляться большому количеству багов и слов о том, что то-то и то-то надо полностью переделать, потому что работать с этим невозможно. И кого будут ругать за большое количество багов? Менеджера Петю? Это не его зона ответственности, крайним будет Вася, который писал код.

    По этому любой опытный программист знает, что слова «нам по быстрому, качество на втором месте» — это развод программиста. Про качество обязательно вспомнят (если проект продолжит жить) и спросят.

    В третьих. Да, бывают разные задачи, разные ситуации, и в некоторых случаях достаточно джуна, который кое-как сделает какой-то простой функционал за месяц, который будет как-то работать и все.

    И эти особенности должно в первую очередь понимать руководство. Иначе, с тем же успехом, оно может нанять 1С-программиста, посадить его делать web-фронт, а потом удивляться плохому результату.

    И, что важно, об условиях и задачах надо честно говорить еще на уровне собеседования. Но много ли вы видели собеседований, где вам говорили «У нас куча задач, сроки горят, на качество и техдолг мы забиваем, готовы работать?» Я вот ни разу. Зато таких подходов к работе по факту — повидал множество.

    По этому уже мне, не собеседованиях, приходится предупреждать «я без авто-тестов не работаю», «я тяп-ляп не работаю» и т.д., чтобы потом у работодателей не было иллюзий, что мня можно склонить в это «давай по быстрому, сроки горят, качество не важно».

    Ну и в заключение. Да, есть бизнесы, которым достаточно тяп-ляп и в продакшен, и которые заставляют своих программистов работать в таком режиме. Но, что очень важно понимать тем, кто соглашается так работать — ваше развитие будет практически стоять на месте. Клепание костылей хорошего опыта не прибавляет. И возникает ключевой момент:

    Но ещё лучше успешно завершать проекты

    Серьезно? Мне вот, как программисту, лучше получать большую зарплату. А для этого мне нужно уметь делать качественные, сложные, высоконагруженнные проекты, с высоким уровнем надежности.

  14. Metotron0
    /#23015420

    какую ценность ты можешь принести компании

    Не знаю, дорасту ли я когда-то до уровня, когда буду думать о своей ценности для компании. Пока просто за деньги делаю свою работу, как умею. Кажется, это слишком высокие концепции для формоклепателя. Что-то из мира высоких зарплат и незаменимых людей, которых единицы.

    • lek349
      /#23016072

      Это чем-то напоминает пирамиду А. Маслоу :)

      Даже заменимый работник с небольшой зп приносит пользу и ценен. По идее, чем раньше это осознаешь, тем лучше, так как это выход на другие приоритеты, цели и, соответственно, деньги

    • sshikov
      /#23018758

      Э… как бы это сказать попроще… клепая формы, вы тоже можете думать о их ценности для конечного продукта, или же не думать. Зачастую выбор «думать» позволяет делать свое дело лучше. Условно — вы могли бы задать аналитику вопрос: «Чувак, а нахрена тут вообще вот эта форма, не проще ли было бы сделать вот так...» — и сэкономить проекту несколько дней, если вы правы, выбросив форму из MVP.

      • Metotron0
        /#23024244

        Мне кажется, осознанность работы должна быть в любом случае, но конкретно в своей работе я чувствую себя таким принеси-подай. Всё время вижу, что у людей вокруг задачи намного сложнее и ценнее. С другой стороны, если мне дадут что-то сложное и незнакомое и бросят одного с этим разбираться, то может лучше и не надо.

        • sshikov
          /#23027258

          Ну почему же сразу бросить одного? Тут вопрос скорее стоит так — если вас можно бросить одного, и вы сами справитесь — то вы вероятно по уровню синьор. Но даже из этого не следует, что синьора нужно бросать одного — с поддержкой он справится быстрее или лучше.

  15. Ob-iVan
    /#23015560

    В статье рассказывается о превращении хорошего программиста в «эффективного менеджера» так, как будто это что-то хорошее.

  16. ivankudryavtsev
    /#23015776 / -1

    Самая большая ошибка в нашей индустрии - считать, что тестирование замедляет разработку. Это справедливо только для кранч-проектов, которые делают очень одаренные люди в период вдохновения, если срок не больше 1-2х недель. Потом все думают как это поддерживать в рабочем состоянии...

    • JordanoBruno
      /#23015996

      Тестирование всегда замедляет разработку. Выгода от экономии времени возникает уже сильно потом и для стартапа это время время может не придти никогда.

      • ivankudryavtsev
        /#23016002

        Не согласен. Любые изменения кода ведут к ошибкам, тестирование быстрее идертифицирует места возникновения ошибок и экономит на этом время. Сразу. Просто эти часы тратятся явно, а не неявно, когда без тестов получилась говноархитектура - рефэкторинг, поиск проблем и мест внесения изменений. Тесты ведут к высокой модульности и простому коду с узкой специализацией, это экономит время всегда, а не потом.

        • JordanoBruno
          /#23016030

          Любые изменения кода ведут к ошибкам

          Ну не знаю, у меня точно не ведут. Да и у многих разработчиков, которых я знаю — тоже не ведут. Разве, что при больших изменениях — могут привести, но они редко делаются, и под них можно и тесты спецом написать уже когда реально это надо.

          • ivankudryavtsev
            /#23016044

            Я сторонник теории об удержании 5+/- 2 сущностей в голове. Возможно, что вы просто уникальный молодец, к моему несчастью и 15 годам в индустрии, я в это все не верю.

            • JordanoBruno
              /#23016198

              к моему несчастью и 15 годам в индустрии

              А, ну тогда понятно, почему. Популярность написания тестов пошла где-то к концу 2000-х, до этого их писали довольно редко, что, впрочем, никак не мешало разработке.

              • ivankudryavtsev
                /#23016354

                Ну так-то и по водопаду в 80х-90х работали и не мешало. А теперь мешает. Вы довольно спорные вещи пишите...

                • JordanoBruno
                  /#23018510

                  По водопаду и сейчас работают очень многие.

          • TheShock
            /#23017978

            Ну не знаю, у меня точно не ведут

            А вы писали что-то сложнее одинаковых крудов?

            • JordanoBruno
              /#23018508

              25 лет вот писал одинаковые круды, ага.

              • TheShock
                /#23018626

                Ну видимо. Меня всегда забавляли люди, которые говорят: "просто пишите код без багов". Не хватает ещё "только побыстрее, пожалуйста.

                • JordanoBruno
                  /#23018698

                  Я где-то сказал — «просто пишите код без багов»?

                  • TheShock
                    /#23020278

                    Вы сказали, что у вас и ваших знакомых разработчиков изменения в коде не ведут к ошибкам.

                    • JordanoBruno
                      /#23020332

                      Зачем Вы передергиваете? Перечитайте еще раз ветку, ivankudryavtsev говорит, что «Любые изменения кода ведут к ошибкам».

                      • TheShock
                        /#23023196

                        Ааа. Вы имели в виду "не все изменения в коде".


                        Я просто оригинальный комент прочитал как "Все изменения в коде МОГУТ привести к багам", на что ваш ответ прочитал как "У меня — нет".

        • APXEOLOG
          /#23016820

          Написание теста отнимает время. Написание хорошего теста отнимает больше времени, чем написание кода, который им покрывается.


          Высокя модульность, код с узкой специализацией, простота рефакторинга — все это хорошо на дистанции. Но если Вам надо накидать прототип или функционал нестабилен и часто меняется, то Вы будете тратить в 2.5 раза больше времени (написание тестов + постоянная правка уже существуюищх после изменения кода) с минимальным выигрышем (отлов пары простых багов)

          • ivankudryavtsev
            /#23016996

            Вот вы так пишите, будто речь идет о лабе - речь все же о человекомесяцах, наложенных на реальный календарь. Если все неопределено и быстро меняется, наоборот именно тесты позволят понять где что развалилось после изменений.

          • JordanoBruno
            /#23018522

            Именно так, видно опытного человека :). Поставил бы плюсик, но злая логика хабракармы и толпы нубов не дают мне это сделать.

    • ftdgoodluck
      /#23016414

      В случае MVP с высокой вероятностью проект никуда дальше не пойдет. И скоуп проекта понятен полностью на этапе его старта — «нам нужно сделать А, Б и В, дальше мы либо получаем инвестиции на развитие, либо выбрасываем». И в таком случае, что тесты, что модульная архитектура — это просто банально лишние расходы.

      • ivankudryavtsev
        /#23016464

        Как насчет MVP в 5 человеко-лет? Если вы скажете, что такое не бывает, то это говорит лишь о вашем опыте, а не о реальности.

        • DrPass
          /#23016866

          Может и бывает, но это из серии «сильно странненького». Какой-нибудь вялотекущий проект, возможно, с длительной исследовательской частью, при крупной корпорации. А вялотекущий — потому что хорошее финансирование на столь длительный срок вряд ли кто решится делать. При крупной корпорации — потому что там в порядке вещей вести кучу проектов, от которых в ближайшем будущем отдачи не ждут, и не особо вникать в детали, форсировать и т.д.

        • JordanoBruno
          /#23018538

          Как насчет MVP в 5 человеко-лет?

          В статье речь шла о месяцах. Для 95% стартапов MVP появляется вообще в течение года, ну 1.5 максимум. Либо не появляется вообще, опять же по причинам, указанным в статье. Несколько лет для MVP — это большая редкость.

          • ivankudryavtsev
            /#23018586

            Вы про календарь или трудозатраты? Я про человеко-месяцы.

            • JordanoBruno
              /#23018596

              Я про срок стартапа. Человеко-месяцы, о которых Вы говорите, не дают представление о проекте без упоминания размера команды.

              • ivankudryavtsev
                /#23018614

                Да, но они говорят о размере кодовой базы и полезности тестов, а если, к примеру, 5 человеколет за 6 месяцев календаря - это капец много кода, сделанного быстро, и без тестов, cicd будет тяжко.

                • JordanoBruno
                  /#23018696

                  Не говорят они ни о размере написанного кода, ни о полезности тестов. Вот мы писали год впятером проект, а тестов было всего несколько штук и только потому, что там данные рассчитывались, по тестам легко было проконтролировать все параметры.

                • DrPass
                  /#23019854

                  Да смотря какого кода. Я не слишком ошибусь, если скажу, что 95% кода — это достаточно простой круд и формы к нему. Ну т.е. тестировать там особо нечего пока не появятся всякие навороты вроде управления правами доступа или там хитрые бизнес-правила (а в MVP они появляться не должны)

      • ivankudryavtsev
        /#23016472

        Еще раз, я считаю, что считать, что тесты вас замедляют - заблуждение. Никакой связи с судьбой проекта это не имеет. Именно через тестирование и cicd делается современный выкат в прод хоть mvp, хоть не mvp. И это ускоряет разработку и упрощает жизнь, а не замедляет.

        • HellWalk
          /#23016734 / +1

          Отказываться от тестов в пользу скорости — это тупик. И дело даже не в том, что тесты на самом деле ускоряют разработку на больших дистанциях, а в том, что у «медленно» нет никаких границ.

          Сделали проект за 2 месяца — медленно, надо за месяц.
          Отказались от тестов, сделали за месяц — медленно, надо за 2 недели
          Стали работать по вечерам и на выходных, сделали за 2 недели — опять медленно.
          И т.д.

          Есть такой тип людей (в том числе и в руководстве), которым всегда мало/медленно/недостаточно хорошо. Удовлетворить таких людей невозможно, их нужно просто выявлять и прощаться с ними. Иначе потом будете пол зарплаты на врачей тратить…

    • KGeist
      /#23020862

      Тесты тестам рознь. Есть такие, что просто проверяют, что метод был вызван, хотя по коду это и так видно. Если кто-то решит это сломать - код-ревью же есть, не вслепую пишем. Вот такими тестами можно пожертвовать. А если какая нетривиальная логика/алгоритм, валидация - там тесты это просто обязательно, я считаю. Одни говорят "не будем писать тесты", другие говорят "сейчас устроим TDD во все поля". Почему нельзя остановиться на середине и тестировать только важные вещи?

  17. Desprit
    /#23015958

    Разумеется, замечательно писать код, который ты можешь показывать другим и гордиться. Но ещё лучше успешно завершать проекты. В конце концов, программирование — это не искусство.

    Как ни как, но нужен баланс. Если вы строитель и вас просят вместо гвоздей использовать изолетну дабы побыстрее сдать проект, как по мне, то нельзя спокойно соглашаться. Я не хочу быть соучастником вывода на рынок очередного говнопродукта. Если в ТЗ на MVP не было выделено бюджета на тестирование и архитектуру, то какая гарантия, что будет выделено потом?

    • dreesh
      /#23016256 / -1

      Хотите сказать что, менеджер вынуждает стать вас поручителем в кредите? Он бонус получит, а вам потом за него возвращать долг в виде психологического здоровья?

      Не читать, я предупредил!

      Вы правда считаете его садистом который питается не рожденными младенцами?

  18. yakimchuk-ry
    /#23016948

    Ловите еще истины:


    1. Деньги для бизнеса важнее чем люди
    2. Бизнесу нужны только результаты, всё остальное это bullshit
    3. Пользователь всегда прав
    4. Видение команды на продукт не значит ничего, главное это обратная связь пользователей
    5. Самый популярный инструмент на текущем отрезке времени – лучший, остальное кот в мешке
    6. Одна из лучших мотиваций работников – деньги

    Истин на самом деле миллион, это лишь что первое в голову пришло.
    Holy War mode on?

  19. AlekseySamoylov
    /#23017448

    Автору, спасибо! Статья хорошая, ее можно дополнить книгой «Идеальный программист» Роберта Мартина.
    И вы, комментаторы, все пишите красиво, правильно… Однако, потом, после очередного посещения модной конференции или прочтения хайповой статьи, начинаете бизнесу палки в колеса вставлять своими технологическими или архитектурными экспериментами, которые годятся только чтобы на собеседованиях хвастаться… То решите прототип для стартапа сразу с микросервисной архитектуры создавать, то соберетесь Kubernetes в проект из двух стабильных сервисов внедрять, то Big Data и Machine Learning на базу данных с парой тысяч строк натравить…
    Для меня эти истины были понятны еще когда я только джуном устроился, потому что до этого много лет разным мелким бизнесом занимался. Но как такое понимание может взяться у разработчика, после получение образования Computer Science в институте, и даже нескольких лет работы?.. Только после того, как его назначат управленцем в бизнес — СТО

    • JordanoBruno
      /#23018552

      То решите прототип для стартапа сразу с микросервисной архитектуры создавать, то соберетесь Kubernetes в проект из двух стабильных сервисов внедрять, то Big Data и Machine Learning на базу данных с парой тысяч строк натравить

      Это как раз понятно и если риски контролируются, то и не страшно. В стартапы как раз многие и идут, чтобы поиграться с новыми технологиями. Это естественный рост для разработчика и возможность записать в резюме новые строки. Задача тут CTO — не допускать бардака и следовать графику.

      • AlekseySamoylov
        /#23019106

        Поиграться, конечно, хорошо, если это происходит дома, или, в крайнем случае, на работе, если платят «будущими дивидендами от стартапа»…
        И не поверю, что здесь ни у кого не было опыта сбора стартовавшего с микросервисов проекта в монолит, или перехода с модной NoSQL на реляционную СУБД, или переписывания реализованного, например, на GO (ничего не имею против этого ЯП) «прогрессивным» разработчиком микросервиса на родной для команды Kotlin или Java (в том случае, если не было объективной причины использовать GO на проекте, помимо желания разработчика)…

        • JordanoBruno
          /#23019196

          Вы мыслите категориями «модно/не модно». Опытные люди мыслят категориями «подходит/не подходит». Начали пилить проект на одном стеке, в процессе увидели, что это не самый лучший выбор, частично заменили — это нормальный процесс в большинстве проектов. Модно/не модно — это уже вторично или даже третично.

          • AlekseySamoylov
            /#23019398

            Полностью согласен! Осмысленность в решениях, смелость в признании ошибок и воля к их исправлению - хорошие качества опытных людей :)

  20. fkthat
    /#23017450

    Этот проект завершился провалом спустя несколько месяцев, потому что значительно превысил бюджет.

    Слушались бы менеджера и проект завершился бы провалом позже, превысив бюджет еще больше.

  21. haword
    /#23018736 / +1

    не знаю какое ПО пишут люди что покрытие unit тестами обязательное, где все друг за другом завязано и этим пользуются пользователи. в большинстве местах где работал всегда требования были такие — нужно еще вчера сделать модуль который позволил бы сделать пользователю такое действие, нужно оно ему или нет решает заказчик он платит. ТЗ состоит из слов — хочу нажать на кнопку и сразу получить результат. спрашиваешь как это сделать? мы не знаем вы же программисты, придумайте. ок, делаешь за 2-3 дня, обновляешь ПО удаленно. Через день говорят — мы не это хотели, сделайте вот так вот так вот. Делаешь. Через день — ой а сделайте к этому еще это и это а то не удобно что то стало. Ок делаешь, обновляешь. Проходит неделя, звонит начальник ИТ отдела — уберите эту фичу она мешает работать, сделайте как было раньше. А вы про покрытие unit тестами.

  22. Maviro
    /#23018738

    «В конце концов, программирование — это не искусство.»
    Не соглашусь.
    Само определение искусства великое множество. Каждый понимает это по-своему. Искусство это то, как человек видит реальный мир, нечто такое, что приносит ему удовольствие.
    Мне нравится как выглядит красивый, аккуратный код, в котором нет ничего лишнего, который минималистичный. Так же как мне нравится минимализм в интерьере или хай-тек в архитектуре.

    Если мне приятно смотреть на красивый и аккуратный код и неприятно смотреть на противоположность — можно ли это назвать искусством? Лично я считаю что да!

  23. Silverthorne
    /#23018740 / +1

    Загуглил профиль автора.
    "Angular developer" (sic!) с 4 годами опыта рассказывает про бытность СТО.
    Ну, такое.

  24. vyakhir29
    /#23018744 / +1

    После прочтения статьи сложилось ощущение, что автор оригинала почти нигде не работал до должности CTO, статью будто бы написал школьник.
    По пунктам в:


    1. Идиотизм пользователя выглядит не более чем личным заблуждением автора. Могу противопоставить личный 20-летний опыт работы в IT — так уж вышло что ни в одной компании, где я работал, мы никогда не исходили из того что пользователь дурак. Конечно при проектировании UI мы принимали во внимание, что UI должен быть интуитивно максимально понятен, но, согласитесь, это не равнозначно предположению, что пользователь глуп. Или, если вы разрабатываете некое API, то вы захотите добавить туда валидацию input параметров, т.к. нельзя полагаться на то, что пользователи вашего API всегда будут передавать валидные значения. Но, опять же, это другое. В общем, п.1 уже как бы намекает на незрелость автора.
    2. Про тесты. Тут автор попутал прототип и MVP. В первом случае тесты действительно — вопрос спорный, ведь вы хотите проверить жизнеспособность вашей идеи, поэтому вопросы engineering & operational excellence можно "отложить". Но если ваш прототип оказался вполне живучим и вы перешли к фазе MVP, то это уже вполне себе продукт, просто с минимальной функциональностью. Что плохого в тестах, кроме того что автор, видимо, слишком ленив чтобы их писать? Кроме того написание юнит тестов обладает хорошим "побочным" эффектом — обычно, если. мне не удается написать маленькие компактные тест кейсы, это почти всегда индикатор того, что мой код написан не очень удачно. Это особенно важно на стадии MVP, ведь вы планируете его расширять, поэтому увеличивать сложность кода без необходимости вам вряд ли нужно. Приведу еще одно соображение — если код пишется кое-как (а если тестов нет то обычно это так), то, скорее всего, и другие вещи в компании тоже делаются кое-как.
    3. С п.3 можно, пожалуй, согласиться — это действительно выглядит распространенным явлением. Правда автора противоречит сам себе. Отказ от тестов он мотивирует отсутствием времени, но на разборки с новыми движками и фреймворками, по его мнению, время есть.
    4. П.4 это та же история что п 1 и автор пытается проецировать свое личное заблуждение на все IT сообщество. Т.к. автор сам обмолвился, что имел терки с PM-ом, то тут, в общем, все ясно и пункт высосан из пальца.

    Однако, больше всего меня повеселило утверждение, что программирование это, якобы, не искусство. Думал перевод неудачный — нет, проверил, и в оригинале дословно то же. Рискну возразить, что искусством можно сделать все — от программирования до мытья унитазов. В контексте статьи более уместным было бы утверждение "я слишком ленив, чтобы относиться к программированию, как к искусству (или просто не очень его люблю)".


    Кажется, я бы не сработался с таким CTO. :)

  25. ldss
    /#23022928

    п.2 работает только в случае «написал, отдал, забыл». Если вы продаете «коробочный» продукт, который пишется и развивается годами, такой подход — прямой путь в ад.
    Например, у нас такой подход за 10 лет привел к тому, что добавление новых фич стало очень медленным, т.к. 40% времени уходит на багфикс

    п.3 работает, если у вас есть бюджет нанять соответствующих спецов и они есть на рынке.
    Например, один из наших менеджеров очень хочет написать новую версию одного из основных модулей на с++ — потому что он быстрее с#. Это действительно так, но для успешной реализации нужны люди, очень хорошо разбирющиеся в языке (а с++ не тот язык, который можно досконально изучить за пару лет). А на рынке таких спецов очень мало, и они хотят много денег. Кроме того, т.к. у нас таких нет, мы не можем адекватно оценить кандидатов