Как стать автором
Обновить

Комментарии 202

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Если серьёзно, то фиг его знает, как правильно. Настолько всё неоднозначно для каждого проекта. Куча обвязки не касающейся кода. Бюджет, сроки, психотип заказчика и его умение/готовность понимать и принимать собеседника, компромиссы, двигаться в хотелках, пользователи и их тараканы итд итп. Бррр, жутко становится, как начинаешь думать про внекодовые обвязки)
Работал с Symfony и нодой, в том числе с WS. Могу сказать, что для нужд стартапа backend API с поддержкой WS можно сваять очень быстро — есть множество готовых фреймворков куда проще того же Symfony.
P.S. Судя по тому, что Вы пишете с ошибкой — «Symphony», с ним Вы не знакомы явно :).
Да это же перевод на скорую руку, типа translate google. Смесь из англицизмов, которые совсем не соответствуют нормальным разговорным англицизмам, которые все понимают. У меня от «менеджер по продукту» слёзы текут. «PM» называется, Product Manager. Ну, или переводите нативно: «Главный по работам».

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

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

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

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

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

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

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

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

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

Думаю многие с вами не согласятся, особенно те, кто с ними работал по несколько лет.
И вы знаете — какая будет сложность у констурукции из 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++. Кто бы спорил.

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

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

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

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

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

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

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

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

Но вот как раз с желанием, как правило, и напряг.
Если 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 и работать с этим становится невозможно.

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

С бек-эндом ситуация не лучше. Тот же php не просто так стал популярным — в условном 98 году выбор был невелик (перл был тяжким).
В случае с PHP и javaScript — да, наверное. Всё упиралось в то, что на многих хостингах был только PHP, а в браузерах — только JavaScript.

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

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

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

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

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

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

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


Как же хорошо, что в Python она не такая. Но зачем вникать в такие мелочи, правда?
И пока вас устраивает что “весь пар уходит в гудок” (99% имеющихся у вас ресурсов уходят на “простоту”) — всё отлично.
Золотые слова, утащил)
Ещё раз: С++, собственно, потому такой большой, что он стремится полностью описать язык. В достаточной степени для того, чтобы на нём можно было реальные программы не заглядывая куда-либо ещё.
В то же время в случае с языками типа JS, Python или там C# — это не так.
Масса вещей, притом практически важных вещей (если бы это не было практичесви важно, то не было бы столько статей про “войну” со сборщиком мусора, чистку строк и прочего — согласитесь) в стандарте не описаны.
И вот если посмотреть на то, сколько всего нужно знать, чтобы сказать «всё, подводных камней не осталось, любые алгоритмы на база этого языка мы можем теперь спокойно реализовывать» — то эти 1151 страница покажется мелочью.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это напрочь не входит в задачи школьного курса программирования и начального ВУЗовского «ОП и АЯ». Цель этих курсов не профессиональная подготовка, а просто научить составлять программы молодого человека, который в этом ни в зуб ногой.
Не, ну погодите, давайте еще раз — речь об обучении начинающих. Они не знают по определению ничего. И у них нет задачи изначально зарабатывать на этом деньги. Ну т.е. да, школа. И какая разница? И что лучше, простой язык, или практически применимый, но более сложный (не обязательно, но обычно все-таки да)?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

Проверить можно по линку
dotnetfiddle.net/N04mJc
Ну вот по сравнению с условным Groovy тут все практически такое.

println("Hello World!")


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

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

«Сильно устаревшие» — это в смысле на несколько месяцев? Когда там эту фичу выкатили в прод, в ноябре или декабре 2020? Поверьте, за этот срок у C# шансов стать основным языком для образования не прибавилось.
Это не говоря уже о том, что как раз сама по себе функция main смысл имеет, т.к. что такое точка входа в программу, это то, что надо рассказывать на самом первом занятии. Вот всякие там using, void, Console, пустые скобочки где параметры пишутся, это уже сущности из серии «расскажем потом».
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: Пространство имен не может напрямую включать в себя такие члены, как поля или методы
Вам не обязательно брать мохнатую древнюю пятую версию для демонстрации сего. Достаточно взять самую актуальную LTS, там тоже не скомпилится :)
так а смысл учиться программировать на заведомо мёртвом языке?

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

см выше

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

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

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

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

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

беглое гугление показало, что мужики 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

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

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

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

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

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

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

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

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

Кобол используют 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/

Ну это надо поделить на 2, если не на 10. Кобол, даже современный, довольно таки многословен. Явные объявления, главным образом, там где во многих языках они либо вообще не нужны, либо пишутся короче.
Именно так. А исходной предпосылкой является кнутовское «Преждевременная оптимизация — корень всех зол». Он говорил, правда, про программирование, а не про разработки вообще или управление разработками вообще, но суть та же. Ну и это вот «Самый короткий путь — который ты знаешь» сюда же.
Весомый, безусловно. И вот тут появляется необходимость весьма тщательно оценивать и другие инструменты, потому что чем выше лежит ошибка (неудачный выбор архитектуры, стека и т.п) — тем дороже эта ошибка будет стоить.
С чего Вы решили, что они не знают Ноду, если там даже фраза есть. Вот такая:
потому что не знали другие так же хорошо, как эти
Не находите, что она говорит о том, что Ноду они знают, просто не так же хорошо, как Симфони и Ангуляр?
«Я буду использовать для этого проекта «X», потому что знаю его»
Это не заблуждение, это очень хороший аргумент. Просто нужно помнить, что он не единственный и не исчерпывающий.
Можно сформулировать его так — «Для решения задачи можно использовать «X»,«Y»,«Z», из них Я лучше всего знаю «Y», поэтому буду использовать его»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы разводите балаган. Всего доброго.
Пользователь получает ускоренный доступ к новому продукту. В качестве благодарности за это он участвует в тестировании.
Почему я не сомневаюсь, что Вы не захотите, чтобы обувь, что Вы купите была «ускоренного доступа» с возможностью отблагодарить производителя своим участием в тестировании оной?
Может быть захочу. Тогда закажу себе вот эти инновационные башмаки на кикстартере и приму участие в тестировании.
Я ни слова не говорил ни про Кикстартер, ни про инновационности. И я ни слова не говорил о контролируемом «ускоренном доступе». Вы, по ходу дискуссии, пытаетесь сформировать удобные для своей позиции условия, которых в исходных условиях дискуссии не было. Так не делается.
А я ни слова не говорил про обувь, это вы решили применить дискуссионный прием подмены предмета, подменив ПО обувью. В нормальной дискуссии так не делают, но раз уж вы решили так поступить, я указал что и ваш нечестный прием не позволяет достичь нужной вам цели.
Хороший ход!) Но мимо. Я лишь предложил аналогию, которые Вы вправе отвергнуть, приведя аргументированное доказательство отказа.
Если речь идёт о выпуске MVP, то писать тесты — это одно из самых худших вложений ресурсов разработки, которые только можно придумать.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

2. Делать руками и делать кодом, зачастую вообще ни по алгоритму ни щапрашиваемым данным не похожи.
Описание заказчика что он хочет на выходе, к пониманию как это в коде написать, никак не приближает.
Поэтому 100500 раз переписать с нуля — нормально, регрессивно что-то, где-то потерять — легко. Хорошо если оно вылезет сразу, а не боком в готовом коде.
Приводятся врачи как образец не тупого пользователя. Ну еще бы, у них образования в несколько раз (а то и на порядок) больше чем у программистов, иной раз больше, чем у всего отдела вместе взятого. Они решают сложные и важные задачи, они типа прослойка интеллигенции: ) Разумеется, врачи умнее и имеют более высокий IQ, чем, скажем, продавец или кассир или таксист. Так что вывод хоть и правильный, но основан на нестандартных данных. Далеко не все пользоватали и врачи. И многие из них, увы, интеллектом не блещут. Что, с другой стороны, не дает повода не считаться с ними.
CTO стартапа из 3 человек… хоть бы уже не позорился лычкой и экспертным мнением. Хотя учитывая как он считал себя «синьёром»…
Типичная история, как только человек переходит из разработки в менеджмент, то оказывается и архитектура продуманная не нужна, и юнит-тесты не нужны и документация бесполезна. И вообще надо было MVP фигакс-фигакс в продукшен.

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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


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

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


так вот, пункт 2 про «прыгать надо», пункт 3 — «думать надо».

Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.
а без юнит тестов точно бы справились?
Без юнит тестов и прочих необязательных вещей они могли успеть запустить MVP, прежде чем кончился бюджет. Лучше запускаться без тестов, чем вообще не запускаться, не находите?
Может лучше владельцем бизнеса браться за те идеи, на которых у них хватит денег? И хватит с запасом, а не так, что «мы тут посчитали, получилось 10 миллионов, вот ровно столько у нас и есть»
У 100% стартапов которые я знаю как запускались(а знаю я не один десяток), до MVP ни один не выдержал предполагаемых сроков. Соответственно, и бюджет превысили. Битые стартаперы уже заранее это знают и закладывают 20-30-50% времени/денег плюсом, но есть масса нюансов, да и инвесторы — живые люди с эмоциями. Если кто-то заявляет точную сумму для запуска стартапа, например 10 лямов 100 рублей, то это либо проходимец, либо глупый человек.
Лучше запускаться без тестов, чем вообще не запускаться, не находите?
выводы автора построены на нескольких предположениях:
1. их провал не был безусловным;
2. они бы представили достаточно рабочее решение без тестов в срок;
3. отсутствие тестов не провалило бы их проект в будущем;
4. отсутствие культуры разработки не спровоцировало бы разработчиков увольняться.
В статье автор не приводит основания своих предположений. А теперь с точки зрения разработчика, что лучше — проработать год на проекте с чистым кодом, или тянуть три года в проекте с велосипедами из костылей?
проработать год на проекте с чистым кодом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

>Одна из лучших мотиваций работников – деньги

Ну если брать типы мотивации по Герчикову, то только один реально о деньгах

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

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

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

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

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

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

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

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

После прочтения статьи сложилось ощущение, что автор оригинала почти нигде не работал до должности 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. :)

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

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

С другой стороны, "Не заставляйте меня думать" © Стив Круг.

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