Comments 204
«Если бы знали его так же хорошо, как Symphony», почему-то автор забыл добавить.
Symfony, разумеется.
Почему «разумеется»?
потому что не знали другие так же хорошо, как эти
При том, что Вы говорите правду, Вы вырываете её (понимаю, что случайно) из контекста, что приводит к ложному выводу.
Комментарий улетел в закладки) Однажды кто-то сказал что, даже то что, негласно и очевидно всем, все равно должен кто-то сказать.
Когда я решил так сделать было три плюса у первого коммента. Уже восемь) А ниже, у DrPass так и намного больше)
Вот он пишет:
В конце-концов, если вы не знаете условный Node.js, почему вы решили, что вы создали бы там что-либо в десять раз быстрее,
И это при том, что в статье ни слова не сказано, что они не знаю ноду. Там сказано:
«но он не был в технологическом стеке нашей команды.»
Более того. Там сказано:
потому что не знали другие так же хорошо, как эти.*как эти, это про Симфони и Ангуляр
Лично мне эта фраза говорит о том, что, вероятнее всего, учитывая контекст, Ноду они знают, просто не сильно хорошо.
Стоит ли удивляться, что идиот у большинства разрабов клиент (я тоже так мыслил, одно время)? Про то, что это могла быть абстракция, пример, я вообще промолчу.
Лично мне эта фраза говорит о том, что, вероятнее всего, учитывая контекст, Ноду они знают, просто не сильно хорошо.
Все правильно, если знаешь яваскрипт, то в каком-то смысле знаешь ноду. А яваскрипт они судя по всему знали, раз у них в стеке был англяр.
В конце-концов, если вы не знаете условный Node.js,Хотя автор, это явно, пишет о недостаточно хорошем знании. И вообще, он это пишет в РЕТРОСПЕКТИВЕ. То есть сравнивает потенциал не в уме, а наглядно. Вот он и высказывает предположение
На Node мы бы создали API в десять раз быстреедополняя его фактологией
но он не был в технологическом стеке нашей команды.
Или у них микроскоп для забивания кудрявых гвоздей)
Как по мне, если создание "чудовища Франкенштейна" неизбежно, то пусть он будет красавицей хотя бы внешне (архитектура продумана)
Возможен вариант ультиматума от красавицы, но тогда встает вопрос о трудо-затратах на дипломатические решения. Одно большое чудовище сложнее победить, чем множество маленьких подружить друг с другом)
Если серьёзно, то фиг его знает, как правильно. Настолько всё неоднозначно для каждого проекта. Куча обвязки не касающейся кода. Бюджет, сроки, психотип заказчика и его умение/готовность понимать и принимать собеседника, компромиссы, двигаться в хотелках, пользователи и их тараканы итд итп. Бррр, жутко становится, как начинаешь думать про внекодовые обвязки)
P.S. Судя по тому, что Вы пишете с ошибкой — «Symphony», с ним Вы не знакомы явно :).
1. Пользователь — это идиот
Это нормальная среда для разработчика UI с учётом UX. Причём всё постоянно меняется. Клиент никогда не виноват, мы для них или для себя это делаем? Золотое правило разработчика.
а) выучить его
б) сталкиваться с неизвестными вам «особенностями» в процессе реализации
Паскаль — отличный язык для обучения азам программирования. Он простой, логичный и понятный. Стартовать с него легко, перейти на большинство других языков, кроме JavaScript'овых, тоже весьма легко.
Ядро банковского софта же в массе своей делает элементарные операции, но делать оно их должно максимально быстро и максимально надёжно. Хотя насчёт Кобола вы скорее преувеличиваете, сейчас это где-то в единичных банках в США осталось разве что. Но все равно суть та же самая: это как раз та сфера, где основное правило при разработке звучит как «работает — не трогай».
При том что Пайтон очень простой язык, он намного сложней обычного Си
Потому что они массу вещей скрывают. И вам про них, типа, “думать не нужно”.
И пока вас устраивает что “весь пар уходит в гудок” (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)
А сколько строка в 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 можно возразить, что это единственный язык для веба, и он стал популярным только из-за популярности веба. Но почему тогда на нем сейчас пишут и сервера (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 и работать с этим становится невозможно.
Никакого рокет сайнса.Ну да. Только при этом всё время происходит какой-то “движ”, а когда выкатываются новые версии сайтов, то единственный вопрос, который возникает у пользователей это “господи, за что?”.
С бек-эндом ситуация не лучше. Тот же php не просто так стал популярным — в условном 98 году выбор был невелик (перл был тяжким).
Но Python, Ruby, NodeJS… они стали популярны, когда этой проблемы уже не было.
И вот именно потому что MVP на них сделать проще, а когда вы раскрутитесь — можно и на что-то другое перейти.
Во многих случаях это кончается совершенно дикими Франкенштейнами и ужасной архитектурой… но попытка сразу сделать хорошо кончилась бы тем, что ваш стартап бы загнулся до выпуска первой версии продукта и всё.
Ну, я такое и в MS Word редактировал. Даже где-то wysiwyg, точнее, есть preview. Лазерные принтеры поддерживал. И тоже в общем на гигабайте и 286 или 386 машинке.
Только если понять, почему оно тормозит (но работает!) на 8 мегабайтах я могу (от “устаревшего подхода”, когда данные не грузятся в память целиком в MS Word'е отказались, так что ему нужно памяти столько, чтобы весь документ с картинками и графигами поместился), а вот на что ушли остальные 1016 мегабайт — для меня загадка.
На обслуживание “небайтоёбства”, надо полагать.
Вы так говорите, как будто турка…
Стоп. У вас в школе был TeX????
Но почему тогда на нем сейчас пишут и сервера (NodeJS) и мобильные приложения (React Native)?чтобы расширить область применения JS-кодеров. Надеюсь вы не будете пытаться утверждать, что это лучшие технологии для юзкейсов.
Может все дело в том, что JavaScript и Python действительно простые и писать на них код легко и приятно?хз, лично у меня от слабой динамической типизации горит как у ракеты. Особенно «приятно» когда x + 1 — 1 может умножить число на 10, а если адекватно валидировать данные, то кода получается в разы больше, чем на плюсах. Вы же понимаете, что простота этих технологий достигается за счет качества реализации? И вы пытаетесь доказать что раз качество реализации на JS/python недостижимо, то оно и не нужно
JavaScript-программисты не страдают так называемым «байтоебством»легко говорить о байтоебстве, когда за ресурсы платит пользователь. И если забыть, что даже на этом, далеко не самом большом треде хабра, средняя мобилка уже будет тормозить.
И пока вас устраивает что “весь пар уходит в гудок” (99% имеющихся у вас ресурсов уходят на “простоту”) — всё отлично.Золотые слова, утащил)
В то же время в случае с языками типа JS, Python или там C# — это не так.
Масса вещей, притом практически важных вещей (если бы это не было практичесви важно, то не было бы столько статей про “войну” со сборщиком мусора, чистку строк и прочего — согласитесь) в стандарте не описаны.
И вот если посмотреть на то, сколько всего нужно знать, чтобы сказать «всё, подводных камней не осталось, любые алгоритмы на база этого языка мы можем теперь спокойно реализовывать» — то эти 1151 страница покажется мелочью.
Сильно подозреваю, что финансовая часть постоплатного биллинга в Билайне до сих пор на коболе.
Язык это же не только синтаксис
Вам не нужно знать конкретные фреймворки и тулзы, чтобы научиться программировать. Тем более что в школе или там на первых курсах ВУЗа вы ещё понятия не имеете, что вам пригодится.
Ну и что, что мёртвый, зато изучив его, можно потом изучить другие.
после латыни очень легко изучаются испанский, итальянский, с некоторой натяжкой — французский.
а может сразу учить испанский , итальянский или французский? Да нет бред какой-то давайте мертвый язык изучать
Так и тот язык, который вы изучите сегодня, с некоторой вероятностью тоже будет мертвый, может быть даже лет через 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 заточена под вещи, которые моло кому нужны — всякие высокозагруженные надёжные системы, а банальных 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
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: Пространство имен не может напрямую включать в себя такие члены, как поля или методы
так а смысл учиться программировать на заведомо мёртвом языке?
Потому что этот инструмент хорошо подходит для обучения? У Кнута в книгах вообще несуществующий язык, если что. Книги по Паскалю все сожгли что ли?
Для которого и помощь актуальную не найти, бест практисы из 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) так привычнее
Естественно. Только и 1, и даже 2 будут продолжаться еще очень долго, причем не только в советских школах, особенно если учесть, что советских школ стало гораздо меньше, если вообще остались.
Кстати, интересно, являются ли советскими школы современных КНР и КНДР, и какие языки там дают на информатике, если она там есть? Реально интересно, без какого либо подтекста.
Кобол используют 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/
потому что не знали другие так же хорошо, как этиНе находите, что она говорит о том, что Ноду они знают, просто не так же хорошо, как Симфони и Ангуляр?
Это не заблуждение, это очень хороший аргумент. Просто нужно помнить, что он не единственный и не исчерпывающий.
Можно сформулировать его так — «Для решения задачи можно использовать «X»,«Y»,«Z», из них Я лучше всего знаю «Y», поэтому буду использовать его»
Это ещё и весомый аргумент, но, опять, не всегда он может перевесить другие
— самописные утилиты для стандартных функций (проверки, логгирование запросов и тд)
— деплоймент
— сбор логов в определенном формате
— мониторинг
— генерация апи
Таким образом, делая выбор в пользу ранее не использованного инструмента, нужно быть готовым отказаться от части наработанных технических решений
Забивать гвозди микроскопом только потому, что у Вас есть микроскоп и Вы хорошо им умеете пользоваться - это не самая лучшая идея.
Но если, на практике, это “микроконтроллер за тридцать рублей вместо микроконтроллера за три рубля” и это вам экономит тысячу на оплате программиста… почему нет? При тираже в десяток экземпляров это выгодно. Да и при тираже в сотню может оказаться выгодно, если позволит вам быстрее результат заказчику показать и финансирование получить.
То есть речь априори не про микроскоп, речь про то, что если картину нужно повесить и есть выбор — клей, шурупы или гвозди, а у меня есть шуруповерт — это вменяемо.
Проблемы как обычно на стыке — когда используется профессиональный сварочный аппарат для детали, которой бы хватило 10 грамм ПВА
Или когда забитый крутыми инструментами верстак используют как обеденный стол (он ведь тоже стол), а потом начинаются проблемы с хранением кастрюль.
Ну то есть если тебе нужно сделать аркаду на 10 минут, для нее лучше подойдет Unity, но если ты регулярно используешь Unreal — нормально написать на нем. Да, десяток метров оверхеда, зато результат получится гораздо быстрее.
Пример в п 2 как бы говорит — не бойтесь писать без тестов. Кроме того, там сказано, что проект развалился — так может, низкое качество результата после отказа от тестов было причиной? Звучит как: ты живешь в хорошем районе, ходишь в дорогой супермаркет, ты слишком закрыт для всего нового, попробуй коробку из-под холодильника и помойки! Не хочешь? Ты закрыт для всего нового! Все равно попробуешь.… Ой, и правда, лучше не стало. Ну извини.
Нельзя так просто взять, и сказать, что тесты для MVP - говно. Или - наоборот, серебряная пуля.
Я могу привести примеры проектов, где тесты только тормозили замену логики работы фич, и примеры проектов, где потраченный на автотест час экономил 8 человеко-часов команды на реопен бага и перетесты.
и примеры проектов, где потраченный на автотест час экономил 8 человеко-часов команды на реопен бага и перетесты.
Это был точно MVP? ;) И даже если вдруг так (хотя сильно сомневаюсь), это один частный тест. А сколько команда сэкономила бы, если бы тестов в MVP вообще не было, ни этого за 1 час, ни десятков других, каждый тоже по часу-два-три?
Я не говорю, что тестами нужно покрывать все. Но неужто у вас никогда не было сложных алгоритмов, которые гораздо быстрее протестировать программно, нежели руками?
И вам не кажется, что это слишком уж частный случай, чтобы принимать его во внимание?
Если речь идёт о выпуске MVP, то писать тесты — это одно из самых худших вложений ресурсов разработки
Не соглашусь с вами. MVP - предполагает, что решение должно выполнять хоть и минимум, но бизнес задачи.
Тесты нужны чтобы понимать, что оно решает корректно поставленные перед MVP задачи.
Если тесты написаны грамотно, то они также будут полезны при написании уже production решения.
Я, в целом за тесты. Т.к. на моей практики это как раз тот инструмент который очень сильно экономит деньги и ресурсы в разработке.
Не соглашусь с вами. MVP — предполагает, что решение должно выполнять хоть и минимум, но бизнес задачи.
Ну так для этого тесты ведь не нужны. Тесты нужны, чтобы оно выполняло бизнес-задачи качественно. А ещё они нужны, чтобы в крупном проекте внесение новых изменений не ломало существующий функционал. Т.е. всё то, чего от MVP не требуется в принципе.
Хм. Тогда мы просто разный смысл вкладываем в понятие MVP.
Вот про PoC я бы с вами согласился.
А как писать-то? Вот пишешь ты модуль, который работает в связке с другими модулями? Как вообще проверить, что это все работает? Каждый раз запускать программный продукт и подходить необходимую, возможно, сложную, последовательность действий руками? Каждый раз? А если не всё ещё написано?
По моему опыту, 80% ошибок, находимых юнит тестами, находятся на этапе реализации модуля, когда он ещё не написан до конца/неправильно. Не знаю, как вы, а я правильный код с первого раза без проверки не могу написать
а) есть куча способов делать дебаг приложения без юнит-тестов, не перекладывая его на пользователей?
б) что вовлечение пользователей в тестовый процесс — это не правонарушение, а тоже нормальная и распространённая практика, и жжение в одном месте не должна вызывать в принципе, ни у вас, ни у пользователей?
Вообще, я могу достаточно уверенно сказать, что вы ошибаетесь. Если речь идёт о выпуске MVP, то писать тесты — это одно из самых худших вложений ресурсов разработки, которые только можно придумать. «Окупаемость» тестов практически в 100% наступает после какой-то достаточно отдалённой стадии развития и усложнения проекта, и соответственно каждый написанный тест во время разработки MVP — это просто время, на которое вы отодвинули получение инвестиций в ваш проект. И очень хорошо, если вложенных в пресейл средств хватит на подобное баловство. А может и не хватить.Не стесняйтесь, ткните пальцем, где в Вашей цитате этой хоть слово об иных, более эффективных методах дебага, нежели тесты.
Я ни слова не говорил про юнит-тесты, я говорил про тесты. В ответ на Ваш коммент, где тоже речь о тестах, а не о юнит-тестах. Вы пытаетесь вменить мне то, чего я не говорил. И пытаетесь ввинтить в свою позицию то, чего изначально не было. Ну и кто из нас нелогичную хрень пишет?
а) есть куча способов делать дебаг приложения без юнит-тестов, не перекладывая его на пользователей?Это вообще что? Вопрос о том, что кроме как заставить пользователей быть тестерами, нету способов дебага, или утверждение в форме вопроса?
б) что вовлечение пользователей в тестовый процесс — это не правонарушение, а тоже нормальная и распространённая практика, и жжение в одном месте не должна вызывать в принципе, ни у вас, ни у пользователей?А здесь знак вопроса к чему? Вовлечение пользователя с его согласия и уведомление, что это альфа/бета/итп и явное указание, что может быть куча багов итд, да, нормально. Вот только этого не делают, да и не о таких случаях речь, разумеется, с ними всё в порядке.
Вы разводите балаган. Всего доброго.
Следует разделять этапы разработки: если ты пишешь новый продукт, и ограничен во времени и бюджете, то можно отказаться от тестирования, чтобы выдать MVP. Если продукт ужетзапущен, приносит прибыль, а менеджмент просит всё так же отказываться от тестов, то следует увольняться.
Ещё одно замечание по тестам: нельзя отказываться от них полностью. Можно сделать простой тест для проверки целостности, чтобы хоть немного поддержать высокий процент покрытия. По опыту работы с легаси могу сказать, что в 90% код без покрытия тестами работает не так, как планировал разработчик, а следы переписывания говорят, что оно занимало больше времени, чем могла бы занять отладка с тестами. При этом, автор продолжает настаивать на том, что его внутренний компилятор совершенен, и тесты не нужны. В действительности, в некоторых случаях от детального тестирования можно отказаться, но не от написания простых тестов для покрытия. Если случается проблема, то такие тесты легко расширить и решить проблему за ограниченное время.
А если у вас вышел бюджет на разработку, то, скорее-всего, игра просто не стоила свеч, а MVP был недооценён по времени. С чего ТС решил, что бюджет превысили тесты - я не совсем понял.
Автор был инженером с узким кругозором, стал CTO и понял, что у него узкий кругозор/узколобость.
Выглядит как мировоззрение джуна, которого внезапно произвели в CTO.
У программистов много фокусов, но большая их часть вне профессиональной сферы.
Был хреновым программистом и и считал пользователей баранами. Стал хреновым менеджером и теперь считает программистов баранами.
Следующее откровение - не все программисты такие бараны как автор :)
Вот они 4 пункта:
- Кто-то начинает проект с отсутствием бюджета, а потом «давай-давай» надо в срок. Потом всем опционы раздам.
- Владелец продукта не может описать видение фичи — потом доделаем, прикроемся аджайлом и его итеративностью.
- Менеджер забивает на тесты — и так работает, сэкономим, тем более вообще непонятно зачем они.
- И да, вишенка на торте — давайте возьмем технологию X — шеф что-то слышал на конференции про нее крутое. Ничего что экспертизы ноль.
Сроки поджимают не только из-за отсутствия бюджета
На первом этапе не всегда есть четкое понимание фичи, поэтому выпускают как есть, чтобы как можно быстрее получить отзывы от реальных пользователей и тогда уже станет более понятно в каком направлении развивать
Опять же на начальном этапе чаще всего тесты, чистый код и вот это вот все - зло. Нужно максимально быстро выпустить продукт для проверки жизнеспособности идеи
С этим соглашусь. Все новое лучше на каких-то мало важных и не срочных проектах обкатывать
Описание заказчика что он хочет на выходе, к пониманию как это в коде написать, никак не приближает.
Поэтому 100500 раз переписать с нуля — нормально, регрессивно что-то, где-то потерять — легко. Хорошо если оно вылезет сразу, а не боком в готовом коде.
Вот только уже не ему этот код расширять, поддерживать и ночами чинить неотловленные юнитами (которых нет) баги, а разработчикам.
Уважаемый СТО, давайте каждый специалист будет заниматься своей зоной ответственности.
Если у вас есть большие инвестиции и бизнес-модель - да, можно сразу и с тестами и с архитектурой и с документацией. Если же нет, то учитывая что большинство стартапов не взлетают, то уж лучше переписать потом уже работающее решение с нуля (благо шишки уже набиты и есть фундамент для архитектуры), чем выйти за бюджет и не выпустить продукт вовсе или потратить слишком много времени=денег на этот продукт и не успеть выпустить другой, работающий.
Да, есть риск того, что с нуля переписывать будет слишком накладно, есть риск того, что практики тяп-ляп и в продакшен останутся и в коммерческом продукте, но лучше так, чем утонуть в разработке, про которую даже не знаешь окажется ли она полезной.
Вот только уже не ему этот код расширять, поддерживать и ночами чинить неотловленные юнитами (которых нет) баги, а разработчикам.
Ну да, вот только делать они это будут, как правило, в своё рабочее время, в своём уютном рабочем кресле, и за хорошую рыночную зарплату.
И знаете что? Если не выпустить MVP фигакс-фигакс в продукшен, не показать его как можно раньше заказчику и не пропихнуть проект, чаще всего уютные рабочие кресла и хорошую рыночную зарплату этим разработчикам придётся искать уже в каком-то другом стартапе. Вот такая вот зараза, этот рынок.
Манагеры, они далеко не всегда такие вот тупые. Они просто код рассматривают не с позиции «насколько интересно его писать и ненапряжно сопровождать», а с позиции «принесёт он прибыль или нет».
в своё рабочее время, в своём уютном рабочем кресле, и за хорошую рыночную зарплату
За одну и ту же зарплату работать в спокойном режиме, или фиксить проблемы на горящем продакшене — две большие разницы, не удивительно что разработчики предпочитают первый подход.
Думаю, нужно четко различать разницу между работой для MVP/пресейла и разработкой, которая предполагает долгосрочность. Менеджеры в любом случае будут топить за реализацию функциональных требований, и только разработчик может напомнить о нефункциональных (сложности внесения изменений, масштабируемости и пр).
Думаю, нужно четко различать разницу между работой для MVP/пресейла и разработкой, которая предполагает долгосрочность.
Именно так
Менеджеры в любом случае будут топить за реализацию функциональных требований
Менеджеры разные бывают. В общем случае менеджер, если он не совсем уж дятел, понимает, чем чревато низкое качество кода на продакшене, и в состоянии оценить риск. Могу сказать, что разработчиков слушать надо всегда, но вот слушаться или нет, тут уж надо думать головой :)
Манагеры, они далеко не всегда такие вот тупые. Они просто код рассматривают не с позиции «насколько интересно его писать и ненапряжно сопровождать», а с позиции «принесёт он прибыль или нет».
Это просто способ переложить вину. Менеджер чтобы продать называет нереальные сроки, а потом заставляет программиста под ними подписаться. Когда глупый и неопытный программист ломается под давлением — он становится жертвой. Через 3 месяца менеджер молодец, что продал, а всё сломалось из-за криворукого программиста, который не может написать нормальный код. И тот сидит ночами без оплаты овертаймов, чтобы починить баги, которые являются следствием того, что менеджер переклал свою вину за неправильные сроки на программиста.
Представьте женщину, которая хочет родить ребёнка принципиально в этом месяце (ну вот всегда мечтала про тельца). И вот на 5-м месяце она заставляет хирурга достать ребёнка. А потом уже пусть подрастает. Пока на хирурге никакой вины за слабое здоровье малыша нету, но если он согласится — будет глупцом.
Да, прототипы можно сделать быстро и на скорую руку. Но для того, чтобы делать такие прототипы нужно уметь после окончания прототипа убедить менеджера его выбросить и написать с нуля. Обычно же менеджер соглашается: "да-да, я понимаю, не расширяемый прототип", зная, что через 3 месяца он прогнёт программиста и заставит этот мертворождённый продукт поддерживать.
ИМХО пункты 2 и 3 про одно и то же, только с разным знаком.
Решили проверить уровень интеллекта у человека и обезьяны. Подвесили вместо люстры банан и завели в комнату обезьяну, обезьяна увидела банан и начала прыгать безрезультатно пытаясь достать его тут раздается голос "думай!". Обезьяна остановилась, подумала, огляделась увидела в углу стол, придвинула стол, залезла на него и достала банан. Следом в ту же комнату завели мужика, а вместо банана подвесили бутылку водки. Мужик попрыгал, попрыгал бутылку достать не смог. Тут опять раздается голос "думай!". Мужик остановился, подумал, огляделся, почесал репу и молвил "Че тут думать? Тут прыгать надо, а не думать!"
так вот, пункт 2 про «прыгать надо», пункт 3 — «думать надо».
Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.а без юнит тестов точно бы справились?
Лучше запускаться без тестов, чем вообще не запускаться, не находите?выводы автора построены на нескольких предположениях:
1. их провал не был безусловным;
2. они бы представили достаточно рабочее решение без тестов в срок;
3. отсутствие тестов не провалило бы их проект в будущем;
4. отсутствие культуры разработки не спровоцировало бы разработчиков увольняться.
В статье автор не приводит основания своих предположений. А теперь с точки зрения разработчика, что лучше — проработать год на проекте с чистым кодом, или тянуть три года в проекте с велосипедами из костылей?
проработать год на проекте с чистым кодом
Если хочется чистого кода — я бы посоветовал не идти в стартап. Процентов 70 стартапов до MVP лепится из говна и палок, остальные пишут чистый код и играются с новыми технологиями. Потом, правда, 90% таких стартапов с чистым кодом закрываются из-за того, что долго пишут или проблем с новыми технологиями.
Del
Годы спустя я вынужден признать правду: наша команда совершила огромную ошибку. Мы думали о будущем и позабыли о настоящем. Мы совершенно игнорировали обстоятельства — ограниченный бюджет и необходимость создания MVP за короткое время.
Разумеется, замечательно писать код, который ты можешь показывать другим и гордиться. Но ещё лучше успешно завершать проекты.
Да сколько можно доказывать эту чушь…
Начнем с конца: лучше успешно завершать проекты — для владельцев бизнеса и руководства — да. Программист получает зарплату за реализованный функционал через написание кода. И отвечает за корректную работу функционала и код, с которым потом могут работать другие программисты.
Хватит на плечи программистов перекладывать ответственность за бизнес!
Второе, про MVP за короткое время. Проходили, знаем. Вначале от программистов требуют только скорость разработки MVP, а потом, через год, будут искренне удивляться большому количеству багов и слов о том, что то-то и то-то надо полностью переделать, потому что работать с этим невозможно. И кого будут ругать за большое количество багов? Менеджера Петю? Это не его зона ответственности, крайним будет Вася, который писал код.
По этому любой опытный программист знает, что слова «нам по быстрому, качество на втором месте» — это развод программиста. Про качество обязательно вспомнят (если проект продолжит жить) и спросят.
В третьих. Да, бывают разные задачи, разные ситуации, и в некоторых случаях достаточно джуна, который кое-как сделает какой-то простой функционал за месяц, который будет как-то работать и все.
И эти особенности должно в первую очередь понимать руководство. Иначе, с тем же успехом, оно может нанять 1С-программиста, посадить его делать web-фронт, а потом удивляться плохому результату.
И, что важно, об условиях и задачах надо честно говорить еще на уровне собеседования. Но много ли вы видели собеседований, где вам говорили «У нас куча задач, сроки горят, на качество и техдолг мы забиваем, готовы работать?» Я вот ни разу. Зато таких подходов к работе по факту — повидал множество.
По этому уже мне, не собеседованиях, приходится предупреждать «я без авто-тестов не работаю», «я тяп-ляп не работаю» и т.д., чтобы потом у работодателей не было иллюзий, что мня можно склонить в это «давай по быстрому, сроки горят, качество не важно».
Ну и в заключение. Да, есть бизнесы, которым достаточно тяп-ляп и в продакшен, и которые заставляют своих программистов работать в таком режиме. Но, что очень важно понимать тем, кто соглашается так работать — ваше развитие будет практически стоять на месте. Клепание костылей хорошего опыта не прибавляет. И возникает ключевой момент:
Но ещё лучше успешно завершать проекты
Серьезно? Мне вот, как программисту, лучше получать большую зарплату. А для этого мне нужно уметь делать качественные, сложные, высоконагруженнные проекты, с высоким уровнем надежности.
какую ценность ты можешь принести компании
Не знаю, дорасту ли я когда-то до уровня, когда буду думать о своей ценности для компании. Пока просто за деньги делаю свою работу, как умею. Кажется, это слишком высокие концепции для формоклепателя. Что-то из мира высоких зарплат и незаменимых людей, которых единицы.
Это чем-то напоминает пирамиду А. Маслоу :)
Даже заменимый работник с небольшой зп приносит пользу и ценен. По идее, чем раньше это осознаешь, тем лучше, так как это выход на другие приоритеты, цели и, соответственно, деньги
Самая большая ошибка в нашей индустрии - считать, что тестирование замедляет разработку. Это справедливо только для кранч-проектов, которые делают очень одаренные люди в период вдохновения, если срок не больше 1-2х недель. Потом все думают как это поддерживать в рабочем состоянии...
Тестирование всегда замедляет разработку. Выгода от экономии времени возникает уже сильно потом и для стартапа это время время может не придти никогда.
Не согласен. Любые изменения кода ведут к ошибкам, тестирование быстрее идертифицирует места возникновения ошибок и экономит на этом время. Сразу. Просто эти часы тратятся явно, а не неявно, когда без тестов получилась говноархитектура - рефэкторинг, поиск проблем и мест внесения изменений. Тесты ведут к высокой модульности и простому коду с узкой специализацией, это экономит время всегда, а не потом.
Любые изменения кода ведут к ошибкам
Ну не знаю, у меня точно не ведут. Да и у многих разработчиков, которых я знаю — тоже не ведут. Разве, что при больших изменениях — могут привести, но они редко делаются, и под них можно и тесты спецом написать уже когда реально это надо.
Я сторонник теории об удержании 5+/- 2 сущностей в голове. Возможно, что вы просто уникальный молодец, к моему несчастью и 15 годам в индустрии, я в это все не верю.
Ну не знаю, у меня точно не ведут
А вы писали что-то сложнее одинаковых крудов?
25 лет вот писал одинаковые круды, ага.
Ну видимо. Меня всегда забавляли люди, которые говорят: "просто пишите код без багов". Не хватает ещё "только побыстрее, пожалуйста.
Написание теста отнимает время. Написание хорошего теста отнимает больше времени, чем написание кода, который им покрывается.
Высокя модульность, код с узкой специализацией, простота рефакторинга — все это хорошо на дистанции. Но если Вам надо накидать прототип или функционал нестабилен и часто меняется, то Вы будете тратить в 2.5 раза больше времени (написание тестов + постоянная правка уже существуюищх после изменения кода) с минимальным выигрышем (отлов пары простых багов)
Вот вы так пишите, будто речь идет о лабе - речь все же о человекомесяцах, наложенных на реальный календарь. Если все неопределено и быстро меняется, наоборот именно тесты позволят понять где что развалилось после изменений.
Как насчет MVP в 5 человеко-лет? Если вы скажете, что такое не бывает, то это говорит лишь о вашем опыте, а не о реальности.
Как насчет MVP в 5 человеко-лет?
В статье речь шла о месяцах. Для 95% стартапов MVP появляется вообще в течение года, ну 1.5 максимум. Либо не появляется вообще, опять же по причинам, указанным в статье. Несколько лет для MVP — это большая редкость.
Вы про календарь или трудозатраты? Я про человеко-месяцы.
Да, но они говорят о размере кодовой базы и полезности тестов, а если, к примеру, 5 человеколет за 6 месяцев календаря - это капец много кода, сделанного быстро, и без тестов, cicd будет тяжко.
Еще раз, я считаю, что считать, что тесты вас замедляют - заблуждение. Никакой связи с судьбой проекта это не имеет. Именно через тестирование и cicd делается современный выкат в прод хоть mvp, хоть не mvp. И это ускоряет разработку и упрощает жизнь, а не замедляет.
Сделали проект за 2 месяца — медленно, надо за месяц.
Отказались от тестов, сделали за месяц — медленно, надо за 2 недели
Стали работать по вечерам и на выходных, сделали за 2 недели — опять медленно.
И т.д.
Есть такой тип людей (в том числе и в руководстве), которым всегда мало/медленно/недостаточно хорошо. Удовлетворить таких людей невозможно, их нужно просто выявлять и прощаться с ними. Иначе потом будете пол зарплаты на врачей тратить…
Тесты тестам рознь. Есть такие, что просто проверяют, что метод был вызван, хотя по коду это и так видно. Если кто-то решит это сломать - код-ревью же есть, не вслепую пишем. Вот такими тестами можно пожертвовать. А если какая нетривиальная логика/алгоритм, валидация - там тесты это просто обязательно, я считаю. Одни говорят "не будем писать тесты", другие говорят "сейчас устроим TDD во все поля". Почему нельзя остановиться на середине и тестировать только важные вещи?
Разумеется, замечательно писать код, который ты можешь показывать другим и гордиться. Но ещё лучше успешно завершать проекты. В конце концов, программирование — это не искусство.
Как ни как, но нужен баланс. Если вы строитель и вас просят вместо гвоздей использовать изолетну дабы побыстрее сдать проект, как по мне, то нельзя спокойно соглашаться. Я не хочу быть соучастником вывода на рынок очередного говнопродукта. Если в ТЗ на MVP не было выделено бюджета на тестирование и архитектуру, то какая гарантия, что будет выделено потом?
Ловите еще истины:
- Деньги для бизнеса важнее чем люди
- Бизнесу нужны только результаты, всё остальное это bullshit
- Пользователь всегда прав
- Видение команды на продукт не значит ничего, главное это обратная связь пользователей
- Самый популярный инструмент на текущем отрезке времени – лучший, остальное кот в мешке
- Одна из лучших мотиваций работников – деньги
Истин на самом деле миллион, это лишь что первое в голову пришло.
Holy War mode on?
И вы, комментаторы, все пишите красиво, правильно… Однако, потом, после очередного посещения модной конференции или прочтения хайповой статьи, начинаете бизнесу палки в колеса вставлять своими технологическими или архитектурными экспериментами, которые годятся только чтобы на собеседованиях хвастаться… То решите прототип для стартапа сразу с микросервисной архитектуры создавать, то соберетесь Kubernetes в проект из двух стабильных сервисов внедрять, то Big Data и Machine Learning на базу данных с парой тысяч строк натравить…
Для меня эти истины были понятны еще когда я только джуном устроился, потому что до этого много лет разным мелким бизнесом занимался. Но как такое понимание может взяться у разработчика, после получение образования Computer Science в институте, и даже нескольких лет работы?.. Только после того, как его назначат управленцем в бизнес — СТО
То решите прототип для стартапа сразу с микросервисной архитектуры создавать, то соберетесь Kubernetes в проект из двух стабильных сервисов внедрять, то Big Data и Machine Learning на базу данных с парой тысяч строк натравить
Это как раз понятно и если риски контролируются, то и не страшно. В стартапы как раз многие и идут, чтобы поиграться с новыми технологиями. Это естественный рост для разработчика и возможность записать в резюме новые строки. Задача тут CTO — не допускать бардака и следовать графику.
И не поверю, что здесь ни у кого не было опыта сбора стартовавшего с микросервисов проекта в монолит, или перехода с модной NoSQL на реляционную СУБД, или переписывания реализованного, например, на GO (ничего не имею против этого ЯП) «прогрессивным» разработчиком микросервиса на родной для команды Kotlin или Java (в том случае, если не было объективной причины использовать GO на проекте, помимо желания разработчика)…
Не соглашусь.
Само определение искусства великое множество. Каждый понимает это по-своему. Искусство это то, как человек видит реальный мир, нечто такое, что приносит ему удовольствие.
Мне нравится как выглядит красивый, аккуратный код, в котором нет ничего лишнего, который минималистичный. Так же как мне нравится минимализм в интерьере или хай-тек в архитектуре.
Если мне приятно смотреть на красивый и аккуратный код и неприятно смотреть на противоположность — можно ли это назвать искусством? Лично я считаю что да!
Загуглил профиль автора.
"Angular developer" (sic!) с 4 годами опыта рассказывает про бытность СТО.
Ну, такое.
После прочтения статьи сложилось ощущение, что автор оригинала почти нигде не работал до должности CTO, статью будто бы написал школьник.
По пунктам в:
- Идиотизм пользователя выглядит не более чем личным заблуждением автора. Могу противопоставить личный 20-летний опыт работы в IT — так уж вышло что ни в одной компании, где я работал, мы никогда не исходили из того что пользователь дурак. Конечно при проектировании UI мы принимали во внимание, что UI должен быть интуитивно максимально понятен, но, согласитесь, это не равнозначно предположению, что пользователь глуп. Или, если вы разрабатываете некое API, то вы захотите добавить туда валидацию input параметров, т.к. нельзя полагаться на то, что пользователи вашего API всегда будут передавать валидные значения. Но, опять же, это другое. В общем, п.1 уже как бы намекает на незрелость автора.
- Про тесты. Тут автор попутал прототип и MVP. В первом случае тесты действительно — вопрос спорный, ведь вы хотите проверить жизнеспособность вашей идеи, поэтому вопросы engineering & operational excellence можно "отложить". Но если ваш прототип оказался вполне живучим и вы перешли к фазе MVP, то это уже вполне себе продукт, просто с минимальной функциональностью. Что плохого в тестах, кроме того что автор, видимо, слишком ленив чтобы их писать? Кроме того написание юнит тестов обладает хорошим "побочным" эффектом — обычно, если. мне не удается написать маленькие компактные тест кейсы, это почти всегда индикатор того, что мой код написан не очень удачно. Это особенно важно на стадии MVP, ведь вы планируете его расширять, поэтому увеличивать сложность кода без необходимости вам вряд ли нужно. Приведу еще одно соображение — если код пишется кое-как (а если тестов нет то обычно это так), то, скорее всего, и другие вещи в компании тоже делаются кое-как.
- С п.3 можно, пожалуй, согласиться — это действительно выглядит распространенным явлением. Правда автора противоречит сам себе. Отказ от тестов он мотивирует отсутствием времени, но на разборки с новыми движками и фреймворками, по его мнению, время есть.
- П.4 это та же история что п 1 и автор пытается проецировать свое личное заблуждение на все IT сообщество. Т.к. автор сам обмолвился, что имел терки с PM-ом, то тут, в общем, все ясно и пункт высосан из пальца.
Однако, больше всего меня повеселило утверждение, что программирование это, якобы, не искусство. Думал перевод неудачный — нет, проверил, и в оригинале дословно то же. Рискну возразить, что искусством можно сделать все — от программирования до мытья унитазов. В контексте статьи более уместным было бы утверждение "я слишком ленив, чтобы относиться к программированию, как к искусству (или просто не очень его люблю)".
Кажется, я бы не сработался с таким CTO. :)
Например, у нас такой подход за 10 лет привел к тому, что добавление новых фич стало очень медленным, т.к. 40% времени уходит на багфикс
п.3 работает, если у вас есть бюджет нанять соответствующих спецов и они есть на рынке.
Например, один из наших менеджеров очень хочет написать новую версию одного из основных модулей на с++ — потому что он быстрее с#. Это действительно так, но для успешной реализации нужны люди, очень хорошо разбирющиеся в языке (а с++ не тот язык, который можно досконально изучить за пару лет). А на рынке таких спецов очень мало, и они хотят много денег. Кроме того, т.к. у нас таких нет, мы не можем адекватно оценить кандидатов
Пользователь — это идиот
С другой стороны, "Не заставляйте меня думать" © Стив Круг.
Четыре ошибки программистов, которые я осознал, только когда стал CTO