Я знаю что «программисты хорошо получают» и в целом «востребованы на рынке труда» и поэтому я хочу стать сферическим программистом в вакууме.
Что мне начать учить? И зачем?
Имхо, с такой мотивацией вообще бесполезно что-то учить.
Если уж программировать, то только тогда, когда не можешь не программировать :-)
JS явно не очень подходит как первый язык, как минимум потому, что нет строгой типизации, человеку после js будет сложновато, на мой взгляд, перейти на тот же С, а вот наоборот — запросто.
Скажу Вам по секрету, что в С тоже нет строгой типизации.
А по существу, я бы обобщил, что любой язык со слабой типизацией плохо подходит в качестве первого.
Поддержу! Stratch, Logo и Racket для начального обучения самое то.
Кстати, Stratch в том числе хорошо решает проблему "поделиться результатом с друзьями".
Ещё очень круто выглядит Project Spark.
лучше бы начинать с какого-то языка, где всё устроено именно так, как кажется на первый взгляд.
А знаете, тут вот шутят насчёт Haskell, и я тоже раньше думал, что это очень сложный язык. Но когда начал изучать, оказалось, что он весьма простой (основной косяк, что про него любят писать заумно, но это не вина языка). После освоения нескольких базовых концепций, всё остальное выстраивается на их основе, настолько естественно, что иногда диву даёшься… Чуть ли не любую библиотечную функцию можно переписать в пару строк, потом открыть код GHC и с удивлением обнаружить, что именно так она и реализована. Я более-менее знаю больше 10 языков, но ощущение "всё устроено именно так, как кажется на первый взгляд" у меня возникло впервые именно при изучении Haskell.
Не берусь пока его советовать в качестве первого языка, но в качестве одного из первых 5 ЯП однозначно рекомендую.
Вот результат опроса, который проводился на Stack Overflow в 2016-м году. В нём участвовало 49397 разработчиков. Более половины из них используют JavaScript.
В результате множество компаний нанимают JavaScript-разработчиков, но разработчиков этих не так уж и много.
Это 5. Я понимаю, что Вы всё подгоняете, чтобы каждый пункт был в пользу JavaScript, но можно же хоть как-то согласовано это было сделать.
P.S. Если по существу, то с JavaScript имеет смысл начинать тем, кто хочет заниматься разработкой фронтенда для веб-проектов в ближайшие 5 лет. Для остальных это не лучший выбор первого языка.
Проскочили слова «TDD», «цель» и «тест» в одном предложении
Да ладно, не стесняйтесь себя процитировать: "Цель — это тест (в терминах TDD)."
На самом деле суть TDD не в тестах, суть в том, чтобы упрощать дизайн кода при помощи обкатки применения методов в тестах. И, как можно догадаться из названия, тесты — это далеко не единственный из возможных driver'ов разработки.
А вообще забавно как Вы завелись… чувствуете прилив религиозных чувств, встав на "защиту" любимой концепции? Это верный признак, что Вы её не понимаете, но верите в неё. Нет ничего универсального и идеально подходящего для любых задач. И TDD тут, само собой, не исключение.
Вспомните, чем научный подход отличается от религиозного… Первый ищет границы применимости и варианты опровержения.
Багтрекер ведь пополняется людьми
OMFG, откройте для себя Airbrake и аналогичные сервисы.
От тех репортов, которые пишут люди вас никакие тесты не защитят, потому что они все либо на тему изменения требований к коду, либо косметического характера (типа вёрстка неожиданно себя повела в Safari, хочу посмотреть как Вы это при помощи TDD решаете, чтобы не больно было))).
TDD позволяет писать код так, чтоб отдел QA находил 0 (НОЛЬ) ошибок.
Пару пруфов не затруднит предоставить? В вырожденных случаях это теоретически возможно, но на практике Вы скорее найдёте сотни статей разочарованных в TDD, которые когда-то, как и Вы, поверили в это ложное утверждение. А ведь проблема не в TDD, а в неадекватных ожиданиях… Люди, которые понимают что TDD это про дизайн кода, а не про контроль качества, прекрасно его применяют по назначению.
Не думаю, что можно считать, что большинство тех, кому приходится работать с какой-то технологией, ожидали её появления.
Это уже вторая категория… Процитирую себя же:
Тут есть 2 варианта: либо человек знает концепции, тогда новые изобретения будут для него долгожданным воплощением ожидаемого;
либо не знает и тогда они будут для него своеобразным шоком. В-первом случае даже учить не придётся, во-втором человек скорее всего будет отвергать новые технологии насколько хватит упорства.
Я поэтому и ратую за обучение концепциям… Что во времена промышленной революции, что в современном мире этого не хватает в массовом образовании.
Промышленность просто использует те истины, которые были найдены в лабораторных условиях.
У меня ощущение, что Вы меня не слышите… Я об этом тоже уже писал: "мейнстрим (промышленность) крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках (лабораториях)". Вы же утверждали, что истина рождается из практики промышленного применения, когда по факту всё наоборот, и промышленность лишь использует готовые концепции. Поэтому такая практика и не является критерием истины, она просто адаптирует готовые результаты. Обратное утверждение как раз приводит нас к луддизму, когда мы опираясь на мейнстрим пытаемся апеллировать к истине.
Который с радостью и рвением готов на пару лет дольше изучать и сдавать то, без чего и так можно найти работу.
Ну, тут вопрос приоритетов, цель "побыстрее найти работу" — это одно. Цель "стать профессионалом" — уже другое. Это похоже на типичный выбор школьника: учиться ради оценок или ради получения знаний.
Одно другому не мешает. Но первая мотивация приводит к недальновидным решениям, а вторая — удовлетворяет первую в полуавтоматическом режиме.
Ну что ж, спасибо за откровенное признание.
Пожалуйста, только это не признание, а лишь мои догадки… Т.к. я по образованию физик и вообще слабо представляю чему там на IT-специальностях учат… Но, судя по текущему состоянии IT, явно не тому, чему я тут с начала темы предлагал учить :-)
Смещение цели (Вы это ниже описали). Цель разработки — код проекта, а цель TDD — тесты.
При разработке прототипа проекта выполняется двойной объём работы: нужно постоянно менять не только код, но и тесты, что при хорошем покрытии весьма неприятно. Программистам свойственно забывать, что на уровне маркетинга тоже идёт своё проектирование и переделать поведение половины методов из-за изменившихся требований — это вполне рабочая ситуация.
Про ложное ощущение надежности я уже писал. Но стоит повторить, т.к. если, понадеявшись на TDD, сократить отдел тестирования, то можно нехило проблем огрести.
Тесты сами по себе не гарантируют хороший код. Я такие тесты видел, которые в рамках TDD писались, что охренеть можно… На них на самих тесты надо было бы писать.
Вопрос то в другом: улучшает ли TDD качество кода или нет?
Сама по себе — не улучшает. TDD может способствовать улучшению кода, если пришлась по душе конкретному программисту. В противном случае — будет соблюдаться формально, что в целом негативно скажется на проекте.
есть ли возможность в любой момент в течении секунд-минут получить тот единственный достоверный бит «работает ли код так, как надо?»
TDD тут ничем не поможет, на этот вопрос только приёмочное тестирование отвечает. И я ни разу не видел, чтобы это было в виде бита. Хорошие тестировщики всегда, как минимум, минорные недочёты находят. QA — это Вам не TDD, там реальный хардкор )))
А как иначе проверить работает ли код как надо, кроме как проверить его?
Только приёмочное тестирование согласно спецификации. К сожалению, TDD тут ничем не поможет, т.к. юнит-тесты пишет тот же человек, что и код и если он что-то неверно понял, то ошибка будет и в коде и в тестах.
Перед программером новая либа, её нужно заюзать.
В документации по-хорошему тоже есть примеры кода, которые можно тоже автоматически тестировать, чтобы гарантировать актуальность.
Так что я лично за то, чтобы смотреть в нормальную документацию. И только в запущенных случаях — в тесты/код.
Цель — это тест (в терминах TDD).
В терминах TDD — да, в терминах TLD — нет. Этим они и отличаются :-)
Ну я понял. 20% кода работает, а остальные 80% — глючат
С какой стати Вы отождествляете покрытие тестами и надёжность кода? При том, что это очевидно несвязанные вещи. О том, какая часть кода глючит Вам сообщит багтрекинг, а не тесты. Причём он Вам об этом сообщит даже если тестов написать в 10 раз больше, чем основного кода. Потому что тесты всегда будут врать, говоря что всё супер. И с другой стороны, даже если не написать ни одного теста, 80% кода глючить не будут даже если автор — зелёный джуниор.
Эх, увидев оглавление, я сначала подумал, что это подборка более развёрнутых статей на соответствующие темы. А тут как-то по верхам и местами даже мимо кассы.
Пойду я и дальше предлагать бухгалтерский учёт с арефмометром
Я имел в виду, что не придётся учить, потому что человек сам без труда освоит то, появление чего он давно ожидал. Хоть Вы и пишете про стремительную смену технологий, она не столь стремительна как человеческие ожидания.
И если закон Гука гласит, что сила пропорциональна коэффициенту упругости и реальные эксперименты (та самая практика) происходят в русле этой закономерности — то это истина
Вы уже в демагогию перешли… Экспериментальная проверка и практика какой-то промышленной деятельности — это совершенно разные вещи.
Т.е. это не та самая практика (если я программирую на X и много вакансий на Х, то X — это самая идеальная технология), о которой Вы изначально говорили.
жёлто-прессовым журналистам, профессиональная работа и рост которых как раз и основана на разжёвывании Питов и Джоулей этих :)
Даже они эту информацию всего лишь используют как объект для применения своих проф.навыков. А сами их навыки от кол-ва и содержания этой информации никак не зависят.
зачем так долго изучать вот всё-всё-всё подробненько, если для достижения своих целей хватает куда меньшего объёма инфы?
Вот! Теперь Вы гораздо больше похожи на маркетолога типичных курсов. Разумеется у них нет и не может быть цели подготовить профессионалов. У них цель — как можно больше учеников зазвать на волне интереса к программированию. А для этого придётся активно ездить по ушам. "каждый сможет научиться всего за 2 месяца/недели/дня ..."
Как же так получилось, что знали, но не предупредили?
Хз. Не могу тут по существу ничего сказать. Возможно, текущим ВУЗам в программе как раз не хватает "мостика" между концепциями и их практическим применением в мейнстриме.
Бабушка говорит внучку: «не суй пальцы в розетку — будет бобо».
Не думаю, что люди жаждат прогнозов такого уровня )))
Наоборот, они хотят точных прогнозов там, где нет чётких закономерностей.
Это именно новый подход в программировании (кажись, его в 90-хх изобрели), который решает множество проблем.
Ах, вот Вы куда вели… Безусловно, TDD — концепция, которая достойна ознакомления с ней. Но идеализировать её я бы не стал, проблем она тоже привносит немало, особенно когда применяется формально, что тоже не редкость.
А остальной код может глючить безбожно %)
Вы верны себе в манере передёргивать. Во-первых, есть принцип Парето, который в реальной разработке просто замечательно применяется, позволяя не сливать усилия, куда не надо. Во-вторых, отсутствие тестов не означает автоматическое наличие глюков. В-третьих, юнит-тесты не являются заменой ни приёмочному тестированию (которое впрочем можно частично автоматизировать, но это уже к TDD никаким боком не относится), ни документации. В-четвёртых, Вы с таким презрением пишете про "читать код", как-будто тесты это не код и как-будто в них самих не бывает багов )))
Строго говоря, 100% покрытие может нанести самый внушительный удар по проекту, если у разработчиков возникнет иллюзия, что если тесты проходят — то всё гарантировано работает как надо. По факту, так бывает только в книжках и в волшебных мирах, где единороги бегают по радугам.
А TLD — это, по сути, та же TDD с чуть ухудшенной техникой.
Не согласен. Подход совершенно иной. Ухудшенным он будет только для начинающих программистов. Впрочем да, это уже оффтопик.
Я ещё раз отмечу, что у меня нет студентов. Но я не вижу тут проблемы, мы ведь изначально школу обсуждали… Т.е. не предполагалось, что люди поголовно будут программистами и после изучения концепций сразу пойдут трудоустраиваться. А на уровне ВУЗов и ПТУ вполне можно рассмотреть как изученные в школе концепции выражены в популярных на текущий момент языках. Со знанием концепций можно влёгкую учить по языку за семестр без напряга и достаточно глубоко для трудоустройства и даже параллельно с какими-нибудь сложными концепциями, которые на уровень школы не прошли.
Но это противоречит многому, что Вы говорите о новом (что оно почти всё мусор).
В чём противоречие то? Очевидно, что "Почти всё" != "Всё".
Конечно есть развитие, есть новые знания и концепции. К сожалению, их концентрация в общем потоке информации снижается, тут не поспоришь.
Вам, как преподавателю, конечно же, вобщем, всё равно чему учить
С чего Вы взяли, что я преподаватель? Я же уже выше даже явно писал, что это так. Я занимаюсь вполне себе production разработкой веб-проектов.
Но уже на момент обучения нужно было знать не это, чтоб зарабатывать в проектировании радиоэлектроники, а какая китайская микруха что может, сколько стоит, где и в каких объёмах её можно достать.
Надеюсь, закон Ома и правила Кирхгофа от этого не пострадали? )))
Научный прогресс — очень плохо прогнозируется
Ну, так не интересно… Т.е. не ждать мне квантовый компьютер за $1000 через 5 лет, исходя из закона времени? :-D
Сколько лет понадобилось, чтобы набрать аудиторию в 50 млн
И дальше сравнение абсолютно разных технологий в разные эпохи. Даже без поправки на общее население планеты в тот период. К примеру, на момент изобретения телевидения людей в принципе на Земле было в 3 раза меньше, чем на момент изобретения интернета. Вот уж точно рукалицо. Где же Ваше критическое мышление?
К-во инет устройств
И что? Если Вы намекаете на экспоненциальный рост, то его там нет. Кол-во устройств на Земле в принципе весьма конечно и скоро уже нечего будет подключать к интернету )))
Я пишу, что жизненноважные технологии обновляются теперь по нескольку раз за период активной жизни.
Ok. Я вижу, что Вы это пишете. Но я не вижу, чтобы это по факту происходило. Возможно, дело в том, что я физик по образованию, поэтому там где Вы видете бешенный технологический прогресс, я вижу просто шлифовку тех.процессов. Это круто само по себе и заметно в повседневной жизни, но это не сильно влияет на объём знаний по физике, вот даже не то, что не удвоился за предыдущие 20 лет… он даже на 10% не прирос.
И как прикажете научить тому, что будет изобретено только через несколько лет?
Тут есть 2 варианта: либо человек знает концепции, тогда новые изобретения будут для него долгожданным воплощением ожидаемого;
либо не знает и тогда они будут для него своеобразным шоком. В-первом случае даже учить не придётся, во-втором человек скорее всего будет отвергать новые технологии насколько хватит упорства.
Но Ваша то, видимо, сама объективность? ;)
Нет конечно. Именно поэтому практика не является и не может являться критерием истины.
Люди — все субъективны, и в состоянии познать лишь какую-то конечную часть безконечной Вселенной. Так что, все люди всегда ограничены. Не ограничен — только Надмирная Реальность (Создатель).
Ох, куда Вас занесло… Во-первых, исходя из наблюдаемых явлений, Вселенная не бесконечна. А её расширение происходит подобно тому, как расширяется поверхность воздушного шарика при надувании.
Во-вторых, рекомендую почитать про теорию голографической Вселенной. Пополните свой арсенал физических концепций ;-)
И тут я говорю именно о знаниях, а не об информации.
А в чём разница?
Информация может вообще не нести знания или нести мимолётное знание (аля как там дела у Питта с Джоли). Т.е. информация может быть пустой с точки зрения профессионального, духовного и вообще какого-либо развития.
Вы думаете, что первым придумали, что если изучить что-то самое лучшее — это это будет лучше всего?
Нет конечно. Я вроде на новаторство в этом вопросе и не претендовал.
то что, все эти тонны курсов по программированию в мире (включая учебные заведения) либо не хотят денег, либо
Я где-то выше по комментам давал оценку этого объёма знаний — 7 лет. Так и представляю рекламу "приходите на наши 7-летние курсы".
Что касается ВУЗов, то некоторые всё-таки стараются обучать именно концепциям, но там свои сложности… Нужно чтобы преподаватели и хорошо владели материалом и имели желание донести его до широких масс, при этом практически без финансовой компенсации. Ну и студентов надо суметь заинтересовать, они то падки на сиюминутные тренды и зачастую только спустя много лет осознают, что вот те лекции надо было внимательно слушать.
Хорошо. Но как понять: где шум, а где полезная информация?
Критическое мышление + знание существующих концепций и фундаментальных законов.
Более детально ответ зависит от конкретики: на какую тему информация, какого она характера и т.д.
Потоянно учиться всю жизнь, чтоб быть просто актуальным специалистом — такой необходимости не было ещё до средины 20-го века.
В том то и фишка, что такой необходимости и сейчас нет.
Сейчас просто модно стало хватать по верхам, ничего толком не изучив, от этого складывается иллюзия постоянных изменений, хотя по факту они носят чисто косметический характер в абсолютном большинстве случаев.
«Всего лишь» частота обновления социально значимых технологий теперь стала выше частоты обновления поколений.
Предлагаю на примере квантовых компьютеров и помониторить насколько увеличился темп… Сейчас они находятся примерно на той стадии развития, на которой современные компьютеры были в 1950-х годах. Они большие, очень дорогие и пока не особо мощные. Потенциал ускорения — 10^300 раз.
Какие Ваши прогнозы, сколько лет займёт переход к всеобщей доступности? У обычных компьютеров он занял в районе 50 лет.
Вы утверждаете, что частота обновления технологий увеличилась… Но на сколько процентов или во сколько раз по сравнению с серединой XX века?
Желание знать будущее — это как раз и есть попытка какой ни на есть самостоятельности
Ну как сказать… Верить в то, что твоё будущее не зависит от тебя (т.е. теоретически предсказуемо извне) — это скорее фатализм.
Я не упоминал TLD. Речь была именно о первом.
Тогда возможно я не понял суть вопроса. Уточните, пожалуйста.
В целом я за то, чтобы внутренний API имел низкую связность (и как следствие был тестопригоден) и хотя бы 20% наиболее частых/важных функций были покрыты тестами.
Разве что что-то концептуальное, типа единая утилита для управления всем — mix вместо bundler и rake. И plug напоминает rack.
Но в плане деталей и реализации языки совершенно разные. А фреймворки скорее вообще противоположные по идеологии.
Лично мою ленту Вы не спамите, т.к. я на все 5 хабов подписан. Но я понимаю недовольство, которое Вам в комментариях к каждой статье высказывают по поводу неуместности хабов Ruby/RoR. На основании 2 лет программирования на Elixir, я могу сказать, что строить параллели с Ruby — это самое вредное при изучении Elixir. В этом плане Вы и себе палки в колеса вставляете и всем, кто поверит в то, что эти языки похожи.
P.S. Если Вам так хочется хаб Ruby к статье, то можно Elixir is not Ruby перевести, он там хоть упоминается ;-)
Если Вы хотите ознакомиться с полноценным ООП, посмотрите Smalltalk/Pharo.
Имхо, с такой мотивацией вообще бесполезно что-то учить.
Если уж программировать, то только тогда, когда не можешь не программировать :-)
Скажу Вам по секрету, что в С тоже нет строгой типизации.
А по существу, я бы обобщил, что любой язык со слабой типизацией плохо подходит в качестве первого.
Поддержу! Stratch, Logo и Racket для начального обучения самое то.
Кстати, Stratch в том числе хорошо решает проблему "поделиться результатом с друзьями".
Ещё очень круто выглядит Project Spark.
А знаете, тут вот шутят насчёт Haskell, и я тоже раньше думал, что это очень сложный язык. Но когда начал изучать, оказалось, что он весьма простой (основной косяк, что про него любят писать заумно, но это не вина языка). После освоения нескольких базовых концепций, всё остальное выстраивается на их основе, настолько естественно, что иногда диву даёшься… Чуть ли не любую библиотечную функцию можно переписать в пару строк, потом открыть код GHC и с удивлением обнаружить, что именно так она и реализована. Я более-менее знаю больше 10 языков, но ощущение "всё устроено именно так, как кажется на первый взгляд" у меня возникло впервые именно при изучении Haskell.
Не берусь пока его советовать в качестве первого языка, но в качестве одного из первых 5 ЯП однозначно рекомендую.
Это 5. Я понимаю, что Вы всё подгоняете, чтобы каждый пункт был в пользу JavaScript, но можно же хоть как-то согласовано это было сделать.
P.S. Если по существу, то с JavaScript имеет смысл начинать тем, кто хочет заниматься разработкой фронтенда для веб-проектов в ближайшие 5 лет. Для остальных это не лучший выбор первого языка.
Да ладно, не стесняйтесь себя процитировать: "Цель — это тест (в терминах TDD)."
На самом деле суть TDD не в тестах, суть в том, чтобы упрощать дизайн кода при помощи обкатки применения методов в тестах. И, как можно догадаться из названия, тесты — это далеко не единственный из возможных driver'ов разработки.
А вообще забавно как Вы завелись… чувствуете прилив религиозных чувств, встав на "защиту" любимой концепции? Это верный признак, что Вы её не понимаете, но верите в неё. Нет ничего универсального и идеально подходящего для любых задач. И TDD тут, само собой, не исключение.
Вспомните, чем научный подход отличается от религиозного… Первый ищет границы применимости и варианты опровержения.
OMFG, откройте для себя Airbrake и аналогичные сервисы.
От тех репортов, которые пишут люди вас никакие тесты не защитят, потому что они все либо на тему изменения требований к коду, либо косметического характера (типа вёрстка неожиданно себя повела в Safari, хочу посмотреть как Вы это при помощи TDD решаете, чтобы не больно было))).
Пару пруфов не затруднит предоставить? В вырожденных случаях это теоретически возможно, но на практике Вы скорее найдёте сотни статей разочарованных в TDD, которые когда-то, как и Вы, поверили в это ложное утверждение. А ведь проблема не в TDD, а в неадекватных ожиданиях… Люди, которые понимают что TDD это про дизайн кода, а не про контроль качества, прекрасно его применяют по назначению.
Это уже вторая категория… Процитирую себя же:
Я поэтому и ратую за обучение концепциям… Что во времена промышленной революции, что в современном мире этого не хватает в массовом образовании.
У меня ощущение, что Вы меня не слышите… Я об этом тоже уже писал: "мейнстрим (промышленность) крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках (лабораториях)". Вы же утверждали, что истина рождается из практики промышленного применения, когда по факту всё наоборот, и промышленность лишь использует готовые концепции. Поэтому такая практика и не является критерием истины, она просто адаптирует готовые результаты. Обратное утверждение как раз приводит нас к луддизму, когда мы опираясь на мейнстрим пытаемся апеллировать к истине.
Ну, тут вопрос приоритетов, цель "побыстрее найти работу" — это одно. Цель "стать профессионалом" — уже другое. Это похоже на типичный выбор школьника: учиться ради оценок или ради получения знаний.
Одно другому не мешает. Но первая мотивация приводит к недальновидным решениям, а вторая — удовлетворяет первую в полуавтоматическом режиме.
Пожалуйста, только это не признание, а лишь мои догадки… Т.к. я по образованию физик и вообще слабо представляю чему там на IT-специальностях учат… Но, судя по текущему состоянии IT, явно не тому, чему я тут с начала темы предлагал учить :-)
Смещение цели (Вы это ниже описали). Цель разработки — код проекта, а цель TDD — тесты.
При разработке прототипа проекта выполняется двойной объём работы: нужно постоянно менять не только код, но и тесты, что при хорошем покрытии весьма неприятно. Программистам свойственно забывать, что на уровне маркетинга тоже идёт своё проектирование и переделать поведение половины методов из-за изменившихся требований — это вполне рабочая ситуация.
Про ложное ощущение надежности я уже писал. Но стоит повторить, т.к. если, понадеявшись на TDD, сократить отдел тестирования, то можно нехило проблем огрести.
Тесты сами по себе не гарантируют хороший код. Я такие тесты видел, которые в рамках TDD писались, что охренеть можно… На них на самих тесты надо было бы писать.
Сама по себе — не улучшает. TDD может способствовать улучшению кода, если пришлась по душе конкретному программисту. В противном случае — будет соблюдаться формально, что в целом негативно скажется на проекте.
TDD тут ничем не поможет, на этот вопрос только приёмочное тестирование отвечает. И я ни разу не видел, чтобы это было в виде бита. Хорошие тестировщики всегда, как минимум, минорные недочёты находят. QA — это Вам не TDD, там реальный хардкор )))
Только приёмочное тестирование согласно спецификации. К сожалению, TDD тут ничем не поможет, т.к. юнит-тесты пишет тот же человек, что и код и если он что-то неверно понял, то ошибка будет и в коде и в тестах.
В документации по-хорошему тоже есть примеры кода, которые можно тоже автоматически тестировать, чтобы гарантировать актуальность.
Так что я лично за то, чтобы смотреть в нормальную документацию. И только в запущенных случаях — в тесты/код.
В терминах TDD — да, в терминах TLD — нет. Этим они и отличаются :-)
С какой стати Вы отождествляете покрытие тестами и надёжность кода? При том, что это очевидно несвязанные вещи. О том, какая часть кода глючит Вам сообщит багтрекинг, а не тесты. Причём он Вам об этом сообщит даже если тестов написать в 10 раз больше, чем основного кода. Потому что тесты всегда будут врать, говоря что всё супер. И с другой стороны, даже если не написать ни одного теста, 80% кода глючить не будут даже если автор — зелёный джуниор.
Эх, увидев оглавление, я сначала подумал, что это подборка более развёрнутых статей на соответствующие темы. А тут как-то по верхам и местами даже мимо кассы.
Я имел в виду, что не придётся учить, потому что человек сам без труда освоит то, появление чего он давно ожидал. Хоть Вы и пишете про стремительную смену технологий, она не столь стремительна как человеческие ожидания.
Вы уже в демагогию перешли… Экспериментальная проверка и практика какой-то промышленной деятельности — это совершенно разные вещи.
Т.е. это не та самая практика (если я программирую на X и много вакансий на Х, то X — это самая идеальная технология), о которой Вы изначально говорили.
Даже они эту информацию всего лишь используют как объект для применения своих проф.навыков. А сами их навыки от кол-ва и содержания этой информации никак не зависят.
Вот! Теперь Вы гораздо больше похожи на маркетолога типичных курсов. Разумеется у них нет и не может быть цели подготовить профессионалов. У них цель — как можно больше учеников зазвать на волне интереса к программированию. А для этого придётся активно ездить по ушам. "каждый сможет научиться всего за 2 месяца/недели/дня ..."
Хз. Не могу тут по существу ничего сказать. Возможно, текущим ВУЗам в программе как раз не хватает "мостика" между концепциями и их практическим применением в мейнстриме.
Не думаю, что люди жаждат прогнозов такого уровня )))
Наоборот, они хотят точных прогнозов там, где нет чётких закономерностей.
Ах, вот Вы куда вели… Безусловно, TDD — концепция, которая достойна ознакомления с ней. Но идеализировать её я бы не стал, проблем она тоже привносит немало, особенно когда применяется формально, что тоже не редкость.
Вы верны себе в манере передёргивать. Во-первых, есть принцип Парето, который в реальной разработке просто замечательно применяется, позволяя не сливать усилия, куда не надо. Во-вторых, отсутствие тестов не означает автоматическое наличие глюков. В-третьих, юнит-тесты не являются заменой ни приёмочному тестированию (которое впрочем можно частично автоматизировать, но это уже к TDD никаким боком не относится), ни документации. В-четвёртых, Вы с таким презрением пишете про "читать код", как-будто тесты это не код и как-будто в них самих не бывает багов )))
Строго говоря, 100% покрытие может нанести самый внушительный удар по проекту, если у разработчиков возникнет иллюзия, что если тесты проходят — то всё гарантировано работает как надо. По факту, так бывает только в книжках и в волшебных мирах, где единороги бегают по радугам.
Не согласен. Подход совершенно иной. Ухудшенным он будет только для начинающих программистов. Впрочем да, это уже оффтопик.
Я ещё раз отмечу, что у меня нет студентов. Но я не вижу тут проблемы, мы ведь изначально школу обсуждали… Т.е. не предполагалось, что люди поголовно будут программистами и после изучения концепций сразу пойдут трудоустраиваться. А на уровне ВУЗов и ПТУ вполне можно рассмотреть как изученные в школе концепции выражены в популярных на текущий момент языках. Со знанием концепций можно влёгкую учить по языку за семестр без напряга и достаточно глубоко для трудоустройства и даже параллельно с какими-нибудь сложными концепциями, которые на уровень школы не прошли.
В чём противоречие то? Очевидно, что "Почти всё" != "Всё".
Конечно есть развитие, есть новые знания и концепции. К сожалению, их концентрация в общем потоке информации снижается, тут не поспоришь.
С чего Вы взяли, что я преподаватель? Я же уже выше даже явно писал, что это так. Я занимаюсь вполне себе production разработкой веб-проектов.
Надеюсь, закон Ома и правила Кирхгофа от этого не пострадали? )))
Ну, так не интересно… Т.е. не ждать мне квантовый компьютер за $1000 через 5 лет, исходя из закона времени? :-D
И дальше сравнение абсолютно разных технологий в разные эпохи. Даже без поправки на общее население планеты в тот период. К примеру, на момент изобретения телевидения людей в принципе на Земле было в 3 раза меньше, чем на момент изобретения интернета. Вот уж точно рукалицо. Где же Ваше критическое мышление?
И что? Если Вы намекаете на экспоненциальный рост, то его там нет. Кол-во устройств на Земле в принципе весьма конечно и скоро уже нечего будет подключать к интернету )))
Ok. Я вижу, что Вы это пишете. Но я не вижу, чтобы это по факту происходило. Возможно, дело в том, что я физик по образованию, поэтому там где Вы видете бешенный технологический прогресс, я вижу просто шлифовку тех.процессов. Это круто само по себе и заметно в повседневной жизни, но это не сильно влияет на объём знаний по физике, вот даже не то, что не удвоился за предыдущие 20 лет… он даже на 10% не прирос.
Тут есть 2 варианта: либо человек знает концепции, тогда новые изобретения будут для него долгожданным воплощением ожидаемого;
либо не знает и тогда они будут для него своеобразным шоком. В-первом случае даже учить не придётся, во-втором человек скорее всего будет отвергать новые технологии насколько хватит упорства.
Нет конечно. Именно поэтому практика не является и не может являться критерием истины.
Ох, куда Вас занесло… Во-первых, исходя из наблюдаемых явлений, Вселенная не бесконечна. А её расширение происходит подобно тому, как расширяется поверхность воздушного шарика при надувании.
Во-вторых, рекомендую почитать про теорию голографической Вселенной. Пополните свой арсенал физических концепций ;-)
Критическое мышление + знание существующих концепций и фундаментальных законов.
Более детально ответ зависит от конкретики: на какую тему информация, какого она характера и т.д.
В том то и фишка, что такой необходимости и сейчас нет.
Сейчас просто модно стало хватать по верхам, ничего толком не изучив, от этого складывается иллюзия постоянных изменений, хотя по факту они носят чисто косметический характер в абсолютном большинстве случаев.
Предлагаю на примере квантовых компьютеров и помониторить насколько увеличился темп… Сейчас они находятся примерно на той стадии развития, на которой современные компьютеры были в 1950-х годах. Они большие, очень дорогие и пока не особо мощные. Потенциал ускорения — 10^300 раз.
Какие Ваши прогнозы, сколько лет займёт переход к всеобщей доступности? У обычных компьютеров он занял в районе 50 лет.
Вы утверждаете, что частота обновления технологий увеличилась… Но на сколько процентов или во сколько раз по сравнению с серединой XX века?
Ну как сказать… Верить в то, что твоё будущее не зависит от тебя (т.е. теоретически предсказуемо извне) — это скорее фатализм.
Тогда возможно я не понял суть вопроса. Уточните, пожалуйста.
В целом я за то, чтобы внутренний API имел низкую связность (и как следствие был тестопригоден) и хотя бы 20% наиболее частых/важных функций были покрыты тестами.
Разве что что-то концептуальное, типа единая утилита для управления всем — mix вместо bundler и rake. И plug напоминает rack.
Но в плане деталей и реализации языки совершенно разные. А фреймворки скорее вообще противоположные по идеологии.
Хех, ну хоть какое-то обсуждение… может Вы для этого лишние хабы и добавляете :-)
Лично мою ленту Вы не спамите, т.к. я на все 5 хабов подписан. Но я понимаю недовольство, которое Вам в комментариях к каждой статье высказывают по поводу неуместности хабов Ruby/RoR. На основании 2 лет программирования на Elixir, я могу сказать, что строить параллели с Ruby — это самое вредное при изучении Elixir. В этом плане Вы и себе палки в колеса вставляете и всем, кто поверит в то, что эти языки похожи.
P.S. Если Вам так хочется хаб Ruby к статье, то можно Elixir is not Ruby перевести, он там хоть упоминается ;-)