Хекслет. Страница 3
3227
@hexlet_ru
Хекслет - это образовательная платформа для изучения языков программирования и является одной из ведущих онлайн-школ (второе место по популярности по данным карьерного портала Мой круг). Мы обучаем профессиям JS-frontend, JS-backend, PHP-программиста, Pyt
-
Хекслет
Почему Хекслет перестал делать видеокурсы и переключился на текст? Когда-то в далеком 2012 году Хекслет пытался быть Курсерой и делал видеокурсы. Спустя несколько лет мы заметили, что с видео есть немало проблем, которые мешают и пользователям, и нам как разработчикам курсов. В чем проблема видео? Начнем с того, что в целом хорошее видео — это очень круто. Проблема в том, что для создания реально хорошего видео, нужно потратить ну очень много ресурсов. Поэтому, даже если бы мы очень хотели, то не смогли бы себе позволить делать видео такого уровня, как делают некоторые каналы на ютубе. Возможно, вас это удивит, но подобные видео иногда стоят много миллионов. Так что же не так с рядовым видео? Поехали по пунктам: Устаревание. Когда курсов становится много, то доработка видео становится не просто проблемой, а постоянной попаболью, из которой невозможно выбраться. Практически все видео старше одного года надо перезаписывать, но на это просто не будет денег. В итоге в видеокурсах очень много устаревшего материала, который не меняется годами. Ошибки. Их в видео исправить практически невозможно без полной перезаписи, что еще быстрее приводит к ситуации «пора перезаписывать». В свою очередь, это приводит к тому, что запись видео дорожает, чтобы минимизировать число ошибок. По факту же ошибок будет много, потому что всего не предусмотреть. Поиск. Его просто нет, надо все помнить и ходить пересматривать. Причем, когда человек уже опытный, он хочет посмотреть по-быстрому и пойти дальше, но видео этого не даст. Все это довольно быстро привело нас к мысли попробовать текстовый формат. Признаюсь честно, мы боялись. Думали, что может совсем не зайти, так как не видели массовых примеров использования текста. Однако наши опасения быстро рассеялись, когда мы сделали первые курсы и студенты их приняли достаточно тепло. Да, при этом были люди, которые сказали, что могут смотреть только видео, но их было значительно меньше, чем мы ожидали. С тех пор мы перевели большую часть контента в текстовый формат и не пожалели. По пути оказалось, что у текста значительно больше преимуществ, чем нам виделось раньше: В создании текста и его исправлениях может принимать участие практически кто угодно, включая наших пользователей. Немало внедрилось и продолжает внедряться в эти тексты. Ошибок можно не бояться в принципе: если хорошо настроена обратная связь, то большая часть проблем устраняется буквально в день обращения. В текст не сложно добавлять интерактивные элементы в виде встроенных редакторов или других штук, типа аскинемы. Текст ускоряет анализ и потребление. Можно больше времени рассматривать или читать ту часть, которая интересна. И наоборот, можно пропускать то, что понятно и неинтересно. Возможно, у вас возникает вопрос, почему бы не объединить и не делать и текст, и видео? Ответ очень простой: стоимость. Производство хорошего видео стоит бесконечно дорого. #заметки -
Хекслет
Недавно мы с вами говорили о том, что первый язык не принципиален. Какой бы язык не был выбран, новичок встречается с одними и теми же ключевыми понятиями. Что к ним относится? Литералы, Операции, Типы данных, Переменные, Логические выражения и Логика, Циклы и Вызов и Определение Функций. Главное в этих темах не изучаемый синтаксис, он может быть разный, а сама суть вещей, которая позволяет комбинировать эти конструкции и получать нужный результат. Зная темы выше, вы уже можете делать любые вычисления, которые можно себе только вообразить. Да, это не всегда весело, но уже вполне себе настоящее программирование. На изучение этих концепций, для минимального уровня понимания, понадобится от 2 недель до месяца при условии хорошо проработанного материала как на code-basics. Как и всегда, главное в этом процессе практика, а не сухая теория. Приведу пример простой программы на нескольких языках, чтобы вы увидели похожесть. Задача состоит в том, чтобы вывести на экран yes или no в зависимости от того, больше ли пяти сравниваемое число (находится в переменной) или меньше. На псевдокоде это выглядит так: Если a больше 5 то печатай yes иначе no. Вот как выглядит этот код в разных языках: PHP $a = 9; print($a > 5 ? 'yes' : 'no'); JavaScript let a = 9 console.log(a > 5? : 'yes' : 'no'); Java var a = 9; System.out.println(a > 5 ? "yes" : "no"); Python a = 9 print('yes' if a > 5 else 'no') Небольшое отличие есть в Python, но это всего лишь синтаксис. По смыслу здесь решается та же задача и тем же самым способом. Дальше конечно различий будет уже больше, но даже они укладываются в рамки общих концепций, которые присущи всем современным языкам. Сюда входит и модульность и объектно-ориентированное программирование и работа с файлами или базой данных. #заметки -
Хекслет
Под одним из предыдущих постов был такой вопрос: “У меня всегда была проблема с математикой, не знаю её от слова совсем. Стоит ли начинать изучать какие то языки программирования без базовых знаний этого предмета или незнание математики не будет проблемой? Вот ту же JS если начать учить?” Мы обучаем программистов с 2012 года, и вопрос про математику всегда был одним из популярных. Сначала короткий ответ: Математика для прикладного программирования не нужна! Теперь чуть подробнее. Основная математика, которая есть в программировании, — это арифметика, немного логики (если A, то B), нахождение остатка от деления или проверка числа на четность. Согласитесь, не рокет сайнс? :) Даже если вы про это не знали или забыли, это легко учится в процессе. Более сложная математика бывает нужна в специфических случаях, например, создании редакторов, где встречается тригонометрия или геймдев, где встречается линейка. Сюда же относятся дата-аналитика и машинное обучение, что не совсем про программистов. Есть еще немало направлений, но все они довольно специфичные. Большая же часть разработки это создание каких-нибудь интернет-магазинов, SaaS сервисов и так далее. Когда говорят про то, что математика нужна, имеют ввиду обычно две вещи: 1. Это говорят люди с вышкой. Тут скорее история “мы потратили 5 лет на это, значит, это было не зря”. Причем такие ребята не признаются в этом никогда. Но будут всегда говорить, что математика нужна. 2. Математикам действительно проще стать программистами. Аналитическое мышление дает много плюсов при старте и последующей работе. Как правило, математики быстрее видят суть, легко вникают в абстрактные концепции, видят причинно-следственные связи и так далее. Все это правда. Но так же правда и то, что таких людей крайне мало, и для большей части реальной работы это не принципиально. Итог такой. Чтобы стать программистом, вам достаточно учиться программированию, а нужные концепции попадутся в процессе. Если вы хотите копнуть сами, то можно глянуть наше видео про математику. Видео уже 7 лет. #заметки -
Реклама
-
Хекслет
По идее я тут должен снова написать "Привет, это Кирилл", но не хочется повторяться) А давайте потренируемся. Задача с собеседования, которую мне задавали в далеком 2009 году. Сейчас такие задачи встречаются редко. Есть такая штука как бикфордов шнур. Он используется для взрыва динамита, то, что мы обычно видим во всяких вестернах. Особенность этого шнура в том, что он горит неравномерно, то быстро, то медленно. Теперь представьте: у вас есть бикфордов шнур, который горит ровно один час (не забываем, что само горение может быть то быстрым, то медленным). Вопрос: как сделать так, чтобы он сгорел ровно за полчаса. Линейки у вас нет. #заметки -
Хекслет
В предыдущем посте мы поговорили о том, что первый язык не важен, так как новички учатся вычислительному мышлению, а базовые конструкции одинаковые во всех мейнстримовых языках. Теперь поговорим о том, а как собственно выбрать этот язык. Начнем с того, что популярных языков, которые подходят новичкам достаточно мало. Вот небольшая классификация: * Массовые и базовые: java, php, js, python, c#. * Менее массовые и обычно идут как вторые языки: go, ruby * Особняком Swift для IOS * Языки обертки, построены на базе других: typescript/js, kotlin/java. Идут как дополнение при трудоустройстве * Тяжелые языки, из универской среды: c, c++ Фактически, для большей части людей, которые не имеют бекграунда и пытаются получить работу в it уже в зрелом возрасте, имеет смысл смотреть языки только из первой группы. Ну может разве что ruby и, реже, go входят в эту компанию. Дальше обычно говорят, выбирай что тебе по душе, фронтенд, мобильная разработка, геймдев или бекенд. Если вы способны на этом этапе выбрать, то действительно за каждым направлением есть более менее определенные языки: фронтенд - js/typescript, ios - swift, android - kotlin (но надо знать java), бекенд - в принципе любой из списка кроме swift. Но не все могут вот так взять и выбрать. Что делать в этом случае? На этом этапе нужно исходить из локации. Смотрите компании в своем городе их вакансии. Обычно разные города имеют разную специфику. Например в Казани много Python, а в Ульяновске много Ruby. Ну и последний критерий, когда все что выше не работает. Я предлагаю вот такую последовательность: php, js, python, java. Почему именно так? Скриптовые языки (php, js, python) значительно проще остальных. Да кто-то жалуется что с ними не копнешь базы, но надо понимать что копание базы зависит не от языка, а от программы обучения. В этом отношении у Хекслета все в порядке. Я затрону эту тему в одном из следующих постов. А почему php раньше чем js и python? В регионах это наиболее массовый язык, где большая нехватка спецов. Более 70% всех сайтов написано на PHP. JavaScript вторым, потому что это и бек и фронт. А фронт нужен везде, на каком бы языке не был бек. То есть он почти всегда присутствует как второй язык. С питоном чуть сложнее, он популярен да, но далеко не всегда для веб-разработки. Например питон используется для дата аналитики, машинного обучения и так далее. Это требует спец знаний и спец обучения. Ну а Java массовая, поэтому она в этом списке, хотя и кривая обучения у нее сильно выше. Не потому что она глубже, а потому что в самой Java много концепций и подходов специфичных только для Java или статически типизированных языков. #заметки -
Хекслет
Всем привет, на связи снова Кирилл. Расскажу про такую штуку, как ошибка выбора языка. Многие новички боятся выбрать “не тот язык”, что они потратят деньги и время в пустую, а потом придется переучиваться целиком. К счастью это не так. Когда вы только начинаете, главное не синтаксис конкретного языка, а способность решать задачи через код, что называется вычислительным мышлением. Да, при этом вы делаете это через конкретный язык, но синтаксис учится быстро, а способ решения задач долго. Поэтому большая часть времени уходит на то, а как из конструкций собрать что-то рабочее. Тут вы учитесь использовать переменные, циклы, осваиваете отладку, настраиваете среду для запуска, редактор в конце концов. Все это, почти не зависит от конкретного языка. Научившись этим вещам, вы с легкостью начнете осваивать другой язык, так как выучить синтаксис это не проблема. Да бывают языки, которые работают очень необычно, но сейчас мы говорим про массовые языки, которые в своей основе очень и очень похожи. Вывод следующий. Учиться можно начинать с чего угодно. Первое и достаточно длительное время, вы будете изучать вещи, которые совершенно универсальны и со временем практически не меняются. Переменные, условия, циклы и функции существовали 50 лет назад и с тех пор не сильно изменились. #заметки -
Хекслет
Какую последнюю книгу по программированию вы прочитали? Я иногда задаю этот вопрос на собеседовании, так как ответ на него коррелирует с тем, насколько человек увлекается программированием. Самое удивительное в ответах — то, что многие в принципе не читают книг по программированию, а предпочитают получать информацию из статей. Насколько это хорошая стратегия? Если говорить про книги по языкам, то тут я в целом согласен: после того, как какой-то язык изучен и используется в работе, читать по нему книги — это сомнительное удовольствие. Редко встречается что-то интересное, но, как правило, вы уже все это либо знаете, либо ощущаете ненужность описываемых знаний. С другой стороны, в программировании есть множество книг, которые раскрывают вопросы архитектуры, устройства языков, каких-то глубоких тем, типа устройства базы данных или принципов написания функционального кода. Плюс в книгах есть множество смежных и важных тем, например, администрирование Linux или устройство операционных систем, тестирование, проектный менеджмент, стартапы. Насколько важно читать эти книги? Если вы не знакомы с этими темами или знакомы неглубоко, то книги очень помогают. Они дают глубокое и целостное представление об этих темах. Подобное невозможно получить через статьи. Потому что статьи — это несистемные знания, которые отрывочны и которые часто создают ложное впечатление понимания темы. Если вам самостоятельно сложно выбрать конкретные книги, то можно начать с нашего списка, который содержит только самое важное для всех программистов: https://ru.hexlet.io/pages/recommended-books p.s. Как эффективно читать профессиональную литературу ru.hexlet.io/blog/po…ad-books -
Хекслет
Дал большое интервью про то как я шел к айти и вошел в него https://www.youtube.com/watch?v=iM-gFlCLcLk -
Хекслет
https://vk.com/hexlet?w=wall-54520471_16838 Ответьте на опрос) -
Хекслет
На момент моего ухода из компании в Хекслет в ульяновском филиале Undev работало около 50 программистов. Программистов, которых брал московский офис Undev, сначала отправляли к нам в командировки для обучения и погружения в культуру. Помимо этого, система обучения так показала свою эффективность, что ко мне обратилось несколько других компаний с просьбой помочь открыть им филиал у нас в городе. Туда мы перенаправили поток людей, которых уже физически не могли принять себе. Последнее время я подумываю о том, чтобы возродить аналог этого обучения, чтобы докачивать ребят до мидлов в рамках открытых проектов Хекслета. Вам было бы интересно такое? -
Хекслет
Недавно я писал пост, как поднимал IT-целину в Ульяновске. В этом посте я хочу чуть более конкретно рассказать, как мне удалось обучить под сотню Ruby-программистов за несколько лет и создать крупнейший кластер рубистов в отдельно взятом городе. Многие из тех рубистов сейчас уже являются техническими директорами и владельцами своих компаний. Исходные данные: ребята из компании Undev, в которой я работал в Москве, связались со мной и попросили помочь выстроить техническое представительство в Ульяновске. Мне предстояло собрать большую команду Ruby-разработчиков, так как именно Ruby был основным языком в компании. Засада была в том, что во всем городе было ровно 3 Ruby-разработчика. Было понятно, что для планируемого роста нужно искать перспективных ребят из других компаний, переманивать их и растить. Почти все ребята, которые ко мне попадали, приходили из маленьких компаний, в основном веб-студий, где они работали от нескольких месяцев до нескольких лет. Были и студенты последних курсов местного политеха, правда с опытом работы. С одной стороны, это уже какой-то уровень. С другой — даже те, кто работал год-два в веб-студиях, с точки зрения наших запросов, были очень слабыми. Это типичная история для студий, где тогда в основном работали с битриксом и другими CMS. Был один случай, когда человек в такой студии разрабатывал внутреннюю систему тикетов, которая хранилась в одном файле на 35 000 строк кода. Кстати, этот парень потом стал одним из лучших и сейчас руководит разработкой одного американского стартапа. Обучение я строил так. Первые две-три недели было изучение самого языка + сопутствующих технологий — например, Git, командная строка и так далее. Для этого были подобраны книги, интернет-ресурсы и различные обучающие сервисы. Не курсы, скорее это были либо специализированные тренажеры, либо Kata Почему на язык так мало времени? Тут все прост: в отличие от студентов на курсах, эти ребята пришли работать работу, и если задержать обучение, то резко падает мотивация. Им хочется быстрее переходить к задачам, и эти люди в целом способны находить проблемы и самостоятельно их решать. Поэтому доучивать язык в процессе для них совершенно естественно. Самое интересное — это то, что происходило во время этого обучения. Фактически я проводил 70% своего времени с этими ребятами, которых могло одновременно обучаться до 15 человек. Два раза в день я проверял, что происходит, направлял, подсказывал с настройкой окружения, давал дополнительные задания, если надо. Если у них были общие вопросы или какие-то затыки, мы собирались у доски и вместе разбирались с этими вопросами в бурных обсуждениях с рисованием. Как только заканчивался этот этап, мы начинали погружаться в Ruby on Rails — наш основной рабочий фреймворк. Ребята делали тестовое приложение, которое постепенно обрастало разными функциями. Здесь мы часто работали в парах и проводили время у доски. Обычно они изучали возможности фреймворка через онлайн-туториалы, затем мы обсуждали концепции и после этого приступали к реализации. Помимо этого, раз в несколько недель мы проводили воркшопы, где я учил ребят проектированию и архитектурным вещам вне фреймворка. Здесь мы за день создавали веб-сервер, event loop, тестовый фреймворк, тесты которого написаны на нем же. Вся эта работа велась только в парах, что значительно увеличивало эффективность работы и обучения. Примерно через четыре месяца они были готовы погрузиться в реальные проекты компании. Я передавал их руководителям проектов, но при этом продолжал полностью ревьювить весь код, который они писали. Это продолжалось примерно еще пару месяцев после окончания основного обучения. -
Хекслет
Где-то здесь появляются слова Agile, Scrum и Kanban, которые превращаются в конкретные процедуры того, как движется процесс разработки. Глядя на описание выше, должно быть понятно, почему бизнес хочет нанимать хотя бы мидлов, а не джунов. Они знают про тот путь, который предстоит пройти, и хотят его сократить. Особенно это касается неизбежных ошибок, которые делают любые новички. К сожалению, все это невозможно прокачать на курсах или пет-проектах. Для этого понадобится погружение в реальные проекты, имеющие реальные финансовые риски. Из-за этого организовать обучение “до мидла” достаточно сложно. Фактически, ни у кого пока это не получилось. Но есть луч надежды. Когда-то подобное обучение на продакшене было организовано в компании андев, в 2011 году. Мы сейчас работаем над тем, чтобы повторить этот опыт уже для Хекслета. p.s. В нашем блоге есть статья, дополняющая этот пост ru.hexlet.io/blog/po…ss-value -
Хекслет
Как-то здесь написали, что пет-проекты — это всё, что нужно, чтобы стать мидлом. В реальности всё чуть сложнее, поэтому пришлось встать с дивана и написать этот пост. Мидл действительно должен знать и уметь больше, чем джун. Конкретного критерия при этом нет, в одной компании ваши знания и умение работать с React будут достаточными для мидл-уровня, в другой их оценят на уровень джуна. В любом случае это самая простая часть, которая может в немалой степени быть прокачана своими проектами. Но есть другая сторона, которая намного более важная, так как прокачать ее самостоятельно не получится. Сюда входят: >> Риски и ошибки, связанные с обслуживанием приложения, которым пользуются в реальном времени Пет-проекты не несут никаких рисков. Упал сайт? Просто перезапустили. Случайно стерли базу данных? Ничего страшного. Нужно обновиться? Остановили сайт. Всё это невозможно в реальной среде, где есть настоящие пользователи. Остановка сервиса может повлечь за собой потери миллионов, уничтожение инфраструктуры — потери всего бизнеса. Здесь нужно думать о бэкапах, о том, как новые изменения отразятся на старых пользователях. Помимо прочего, реальные сервисы — это вопросы, связанные с безопасностью, нагрузкой, масштабированием, отказоустойчивостью, логами, ошибками в продакшене. Представьте себе ситуацию, пользователь наткнулся на серьезный баг, который приводит к появлению страницы 500. Как вы об этом узнаете? В этот момент сразу можно понять, новичок перед вами или нет, так как новичок даже не задумывался над такими вопросами. Опытный разработчик знает о том, как отслеживают ошибки, и команда узнает об этом через системы мониторинга и алертинга. Как говорится: «Не ронял прод, не мидл». >> Процессы разработки. Сюда входит всё, начиная от того, как совместно работать в git до выкатки в продакшен. В реальной разработке обязательно присутствует процесс непрерывной интеграции, этап тестирования на стейджинге. Сам процесс выкладки сайта на продакшен представляет из себя целую историю, которую вот так на пет-проекте не реализуешь. Про git стоит сказать отдельно. Для собеседующих это один из самых простых способов понять, насколько программист в теме. Умение с закрытыми глазами оперировать ветками, черрипикать и выполнять другие задачи в гите очень сильно коррелирует с его продакшен-опытом. В разных компаниях уровень этих процессов разный. То есть может получиться так, что джуниор попал в компанию с низкой культурой и за год не научился правильным процессам. Дальше он придет в другое место, где на собеседовании станет понятно, что он слаб в этом вопросе. В любом случае, на пет-проектах получить такой опыт не удастся. >> Взаимодействие с другими членами команды: программистами, тестировщиками, администраторами. Здесь то же самое. Пет-проект — это работа в одного. Ни с кем не надо советоваться и согласовывать технические моменты. Можно в любой момент что-то переписать, перейти на другой стиль кодирования, выкатить без проверки. Естественно, нет никакого код-ревью. В команде нужно уметь договариваться, совместно искать архитектурные решения, идти на компромисс. В этой части всегда присутствует элемент спора, а иногда конфликта. Все это помогает прокачать софт-скиллы и стать частью корабля. Кстати, на эту тему есть хорошая книга от Роберта Мартина, называется «Идеальный программист»: https://ru.hexlet.io/pages/recommended-books >> Взаимодействие с заказчиками, это могут быть как внешние люди, так и внутренние заказчики, например, продакт- и проджект-менеджеры. Только тут программист начинает понимать всю сущность бытия. Оказывается, идеального ТЗ не бывает. Никто не знает, как оно должно работать, есть только хотелки. Нужно уметь превратить их в техническое описание, нужно увидеть потенциальные проблемы, донести их до заказчика, подумать над решением. Нужно уметь отстаивать свою позицию, упрощать и предлагать более оптимальные решения, нужно погружаться в предметную область и бизнес. Нужно уметь оценивать, ставить сроки и исполнять их. На всё это накладываются инструменты проектного менеджмента, такие как jira или trello. -
Хекслет
Хекслет запустил свой онлайн-тренажер в далеком 2013 году. С тех пор мы его сильно улучшили, и на текущий момент он является одним из самых интересных элементов экосистемы Хекслета. Что он из себя представляет? Со стороны может показаться, что тренажер — это просто редактор кода, который умеет запускать его на выполнение. Это будет правдой, если мы говорим про https://code-basics.com. Там тренажер устроен действительно просто: по кнопке «запустить» написанный код отправляется на сервер, где он и запускается. Результат отправляется обратно в браузер, где уже выводится пользователю. На Хекслете тренажер устроен значительно сложнее. Он включает в себя множество элементов: Редактор, у которого есть фронтенд и бэкенд часть Фронтенд-код для взаимодействия с редактором со стороны Хекслета. Он получает от редактора различную информацию — например, успешность прохождения тестов. Сами задания, которые разрабатывает выделенная команда внутри Хекслета Бэкенд-код для обслуживания заданий внутри Хекслета. Он загружает задания внутрь системы, обновляет их, запускает и выполняет другие служебные задачи. Инфраструктуру из примерно 10 серверов, на которых запускается практика. Зачем все это нужно? Тренажер Хекслета специально создавался как универсальный инструмент, с помощью которого можно запускать практически любую задачу — от простого выполнения функций до разработки полноценных приложений с базами данных и веб-серверами. И у нас это получилось. Каждое задание на Хекслете представляет из себя мини-сервер (технически, это Docker-контейнер), который запускается при старте практики. Редактор запускается внутри этого сервера для каждой задачи. С его помощью можно не только писать код в каких-то файлах, но и получить полный доступ к внутренностям «сервера» через терминал. Кроме того, каждое задание имеет выход в интернет, через который можно выставить наружу, например, приложение, которое разрабатывается внутри. Подобная возможность доступна по кнопке «веб-доступ» в соответствующих практиках. Иногда эта возможность используется и другим способом. Например, тестировщики так получают доступ к мини-сайтам, которые им нужно проанализировать в рамках конкретного задания. Вот примеры задач, которые мы создаем для наших пользователей: Написать кусок кода в рамках приложения Разработать приложение с использованием какого-то фреймворка Научиться пользоваться командами Bash Изучить работу Git Протестировать сайт Изучить инструменты управления конфигурацией, например, Ansible Изучить команды SQL Все это позволяет автоматизировать выполнение всех задач в рамках профессий, а не только первые простые модули, как это часто бывает. -
Хекслет
Предлагаю размять мозги. Многомерная задача с несколькими уровнями ответа: Есть два стеклянных шарика и 100-этажный дом. Вы бросаете шарик с разных этажей этого дома, чтобы выяснить, при падении с какого этажа шарик начинает разбиваться (например, на пятом уже разбивается, а на четвёртом ещё нет). Вопрос: какое точное минимальное количество шагов понадобится для того, чтобы точно узнать на каком именно этаже шарики начинают разбиваться? -
Реклама
-
Хекслет
Одна из краеугольных тем в программирование это состояния системы. Тема глубокая, повсеместная и ее понимание может сильно изменить взгляд на вещи. Разберемся с ней на примере страницы курса на Хекслете. Откройте для примера этот https://ru.hexlet.io/courses/js-ddd На этой странице есть описание курса, состав уроков, отзывы, справа цена кнопка и какая-то другая полезная информация. Как вы думаете, насколько сложно создать такую страницу? На первый взгляд не сложно, но самое интересное начинается в тот момент, когда мы начинаем задумываться о том, какие состояния возможны на этой странице. Возьмем кнопку справа. Что у вас там отображается прямо сейчас? Например я сейчас вижу “зарегистрироваться”. Но если я залогинюсь, то увижу уже другую кнопку, там будет что-то другое. Причем это другое тоже будет зависеть от того, вступал ли я в этот курс или нет, платил ли я за него или нет. Все это называется состояниями и особенность состояний в том, что их нужно программировать. Каждое новое состояние любого элемента на странице это дополнительная работа, это условие в коде “если это то сделай вот это”, это дополнительная поддержка кода и это дополнительное тестирование. Кнопка о которой мы говорим имеет 5 состояний! Это значит, что даже для банальной проверки, того как она выглядит, нужно проделать множество действий. А кроме кнопки на странице множество других элементов. Если уроки пройдены, то они отмечаются специальным образом. Если пользователь вступил в курс, у него добавляется сверху блок, который показывает статистику прохождения этого курса. Суммарно все это может приводить к десяткам состояний на одной странице. С точки зрения сроков разработки, стоимости поддержки и сложности тестирования, изначальная оценка вырастает сразу в несколько раз как минимум. А может даже на порядок. Помимо самих состояний, каждый переход из одного состояния в другое это программный код: вступление в курс, оплата курса, регистрация. Все это процессы, которые переводят состояния элементов на той же странице курса. И конечно же, других страницах сайта. С состояниями связана еще одна забавная история. Профессиональные программисты видят многие состояния буквально сразу, как только им обозначили задачу. Из-за этого те кто с ними работают недоумевают как, на первый взгляд, простая задача, внезапно превращается в месяц разработки. -
Хекслет
Написал большую статью про то как организовывать доски в ноушене. Рекомендую для прочтения vc.ru/service…ne-tolko -
Хекслет
Хотел поделиться видео, в котором Саша, который делал хекслет очень много лет, показывает в прямом эфире как он разрабатывает платформу https://www.youtube.com/watch?v=SKLH1C1sl0o