По мнению наших студентов, одна из самых сильных черт Хекслета – проекты. Это специальные задачи, приближенные к реальной жизни, выполняемые вне среды Хекслета на собственном компьютере.
В этой статье расскажем, как устроены проекты, сколько времени нужно на их выполнение и почему плохой код не пройдет. В тексте приведены впечатления наших студентов о процессе работы над проектом.
Студенты Хекслета постоянно подчеркивают уникальность его программ обучения. Особенно те, кто пробовал разные форматы и курсы, которых сейчас очень и очень много. Основной тезис: «Хекслет дает сильную базу и учит думать». Что это значит и как это влияет на конечный результат? Ниже вся правда о курсах Хекслета.
В скриптовых языках, подобных JavaScript, внутри файлов (но вне определений) можно писать любой код: определения функций, вызовы функций, определения и изменения переменных. Такая свобода упрощает разработку, например, создание одноразовых скриптов для каких-то простых или не очень задач. С другой стороны, при неаккуратной разработке появляются ошибки, значительно усложняющие код и его поддержку. Они так часто встречаются в продакшен коде, что об этом нужно поговорить отдельно.
Стоит или не стоит ставить библиотеки ради нескольких простых функций? Не проще ли их написать самим? Эти вопросы регулярно возникают у начинающих разработчиков. На Хекслете их задают практически все кто проходят проекты. Давайте разбираться.
В этой статье я расскажу про неочевидные примеры неправильного проектирования аргументов функций. Про необязательные параметры в JavaScript, передачу флагов, нарушениях интерфейсов и использовании оператора rest не по назначению.
Программисты каждый день пользуются сторонними библиотеками в своих программах, например, http-клиентами или парсерами. Помимо выполнения основных функций, все эти библиотеки как-то обрабатывают возникающие ошибки. Причем чем больше в библиотеке побочных эффектов — сетевое взаимодействие, работа с файлами — тем больше внутри кода, отвечающего за ошибки, и тем он сложнее.
В некоторых языках, таких как Python или JavaScript, переменные или константы, определенные на уровне модуля, могут быть импортированы в других частях программы. С одной стороны, это открывает больше возможностей по сравнению с языками, где любые данные должны находиться внутри функций, классов и так далее. С другой стороны, становится гораздо легче писать плохо поддерживаемый код.
В динамических языках есть два основных подхода при проектировании входных параметров функций: первый – использовать явные, позиционные аргументы, и второй – передавать структуру, внутри которой должно находиться все то, что ожидает функция. Явный и неявный способы передачи одинаково часто встречаются в реальном коде и, при этом, не всегда понятно, какой способ стоит предпочесть для конкретной функции. Именно об этом мы и поговорим.
Кроссплатформенность — способность программы запускаться на разных платформах, например, разных операционных системах. Это довольно важное качество для программ, которые нужно запускать и в Windows, и в Linux. Причем как со стороны пользователей (все хотят кроссплатформенный фотошоп), так и со стороны разработчиков. Последнее часто встречается в веб-разработке, где часть команды может использовать одну операционную систему, а часть другую.
Кроссплатформенность программы зависит от разработчиков. В статье мы разберем несколько типичных ошибок программистов, которые ухудшают кроссплатформенность или вообще убирают ее.
Нормализация данных — подход, с помощью которого можно не только упростить логику кода, но и сделать сам код короче. Его принцип работы состоит в приведении данных к общему виду перед основным алгоритмом обработки этих данных. Посмотрим, как это работает на простом примере.
Свитч — очень простая конструкция, которую изучают программисты в самом начале своего пути. Она ни у кого не вызывает вопросов, но с ней связана одна интересная деталь, которую очень часто упускают из виду и, в итоге, используют свитч неправильно. Это дефолтное поведение.
Веб-программирование насквозь состоит из манипулирования строковыми данными. Данные в базе, данные в JSON (который тоже строка), данные в коде (SQL-запросы, списки). Часть этих строк на код не влияет, это просто данные, которые гоняются из базы пользователю и обратно. Другие данные задействованы в логике приложения и серьезно влияют на устойчивость к ошибкам и скорость их обнаружения.
У каждого из нас есть представления о том, как должно происходить обучение. Они основываются на нашем прошлом опыте, рассказах других людей и неких идеальных образах.
Зачастую эти представления не совпадают с тем, как на самом деле работает механизм становления хорошего разработчика. Студенту может казаться, что его учат неправильно или грузят ненужными знаниями. Подобные ситуации случались с каждым и в школе и в университете. Они встречаются и у нас на Хекслете. В этой статье я объясню некоторые теоретические основы процесса обучения, которые позволят по-другому взглянуть на происходящее вокруг. Это поможет качественнее учиться и проще справляться с трудностями.
К написанию кода можно подходить с двух позиций: сверху-вниз (нисходящее) и снизу-вверх (восходящее). В первом случае сначала реализуется высокоуровневая логика, затем идет погружение в детали. Во втором – наоборот, сначала реализуются детали, затем общая логика.
В книгах эти подходы часто противопоставляются. Считается, что если выбран один подход, то второй исключен. Но это не так — в статье я объясню, почему следование только в одном направлении приводит к проблемам.
В динамических языках файлы с кодом могут выполнять две разных роли: быть исполняемым скриптом, либо быть модулем. В зависимости от роли на эти файлы накладываются разные ограничения, они по-разному устроены и ведут себя тоже по-разному.
Создавать функции легко, но создавать их правильно — гораздо сложнее, чем кажется. Плохо спроектированные функции плохо тестируются, с трудом адаптируются под новые требования и часто переписываются. В этой статье мы пройдёмся по ключевым подходам создания удобных функций: научимся правильно разделять ответственности, строить цепочки функций и проектировать их сигнатуру. Материал статьи базируется на ошибках, которые совершают студенты Хекслета на проектах.
Программисты любят компактный код. Если он реализован грамотно, то такой код легко читается и не содержит частей, которые заставляют думать о нем больше, чем нужно.
Есть такой код, который я называю "код, который заставляет себя переписывать". Этот код не выглядит плохо и про него нельзя сказать сразу, что он делает что-то плохое. Проблемы проявляются позже — в тот момент, когда нужно внести изменения либо отладить его.
Изначально этот материал планировался, как урок в PHP курсе по полиморфизму. Но он, в конце концов, перерос сам урок, и я решил сделать из него отдельную статью. В ней практически ничего PHP-специфичного, поэтому рекомендуется для прочтения всем без исключения.
Ниже представлена подборка типичных ошибок, которые допускают программисты при именовании переменных и функций в своём коде. Примеры взяты из проектов учеников Хекслета. В качестве языка для демонстрации я использую JavaScript, как наиболее универсальный, но сами примеры никак не связаны с тем, какой язык используется. Эти ошибки встречаются везде в одинаковых пропорциях.
