Качество кода *

Здавствуйте, в этом туториале мы рассмотрим как разработать очень простую, но контролируемую форму в React, сфокусировавшись на качестве кода.

При разработке нашей формы мы будем следовать принципам «KISS», «YAGNI», «DRY». Для успешного прохождения данного туториала вам не нужно знать этих принципов, я буду объяснять их по ходу дела. Однако, я полагаю, что вы хорошо владеете современным javascript и умеете мыслить на React.

Сортировку кучей (она же — пирамидальная сортировка) на Хабре уже поминали добрым словом не раз и не два, но это всегда была достаточно общеизвестная информация. Обычную бинарную кучу знают все, но ведь в теории алгоритмов также есть:

n-нарная куча; куча куч, основанная на числах Леонардо; дерамида (гибрид кучи и двоичного дерева поиска); турнирная мини-куча; зеркальная (обратная) куча; слабая куча; юнгова куча; биномиальная куча; и бог весть ещё какие кучи…

И умнейшие представители computer science в разные годы предложили свои алгоритмы сортировки с помощью этих пирамидальных структур. Кому интересно, что у них получилось — для тех начинаем небольшую серию статей, посвящённую вопросам сортировки с помощью этих структур. Мир куч многообразен — надеюсь, вам будет интересно.

Несколько месяцев назад читая иностранный форум и увидев соревнование: создать программу "угадай число" покороче я обогнал иностранцев 1-м создав 1-строчный алгоритм "guess number" на 2-х языках

1 IF Russia = 0 THEN Russia = 2222: RANDOMIZE TIMER: num = INT(RND * 100) + 1: GOTO 1 ELSE IF Russia <> 0 THEN INPUT n: IF n < num THEN PRINT «MORE»: GOTO 1 ELSE IF n > num THEN PRINT «less»: GOTO 1 ELSE IF n = num THEN PRINT «da»: END ELSE GOTO 1 'DANILIN Russia 9-9-2019 guessnum.bas

Сердце любого современного сайта или браузерного приложения (что SPA, что PWA, что любые другие три буквы) — это его State, или состояние.

Мы можем сколько угодно спорить о том, что лучше — React, Vue, Svelte, Angular, можем продолжать пользоваться jQuery, но в действительности это не так важно. Это та часть нашего приложения, которое мы видим — его “мышцы“ и “кожа”. Но то, как вы думаете — какими терминами оперируете, какие механики используете для даже визуализации в голове того, как в вашем приложении “текут” данные — все это идет из его скелета. Из state manager-а.

Помните, пару лет назад у нас была усталость от JavaScript-а? Сейчас я вижу у огромного количества людей усталость от state manger-ов. Redux? Да, да and да. RxJS? Тоже. MobX? Если он такой простой — блин, почему у него есть в документации страница западни.html?

Ответ “почему многим так тяжело” есть, но сначала надо точно сформулировать проблему.

Выбирая state manger — мы выбираем образ мышления. Вариантов сейчас много, но самые популярные подходы бьются на 3 группы:

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

Привет, Хабр! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.

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

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

Мне нравятся разговоры на тему «мне раньше в школе/институте/родители говорили, а теперь я узнал». Если по счастливой случайности я оказываюсь хоть немного компетентен в обсуждаемом вопросе, то такие разговоры обычно сводятся к одному из трех вариантов: «где вообще ты раньше слышал такую чушь?» (если собеседник прав), «а с чего ты взял, что это так?» (если он не прав) и «ты прав, только это не противоречит тому, что тебе говорили раньше» (в подавляющем большинстве случаев). Нравятся такие разговоры мне по следующей причине: обычно их инициатор не обременен излишним предварительным знанием вопроса, что в некоторых случаях позволяет ему указать на некоторые моменты, которые принимались как очевидные, на самом деле таковыми не являясь. И одной из тем для подобных бесед оказалось функциональное программирование.

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

Насколько это соответствует истине?

От переводчика: при разработке ПО у программистов, какого бы уровня они ни были, нередко возникает желание реализовать тот или иной фрагмент программы более красиво и удобно. Когда, глядя на код, интуитивно чувствуешь: этот кусок точно можно сделать изящнее, начинаешь либо вспоминать best practice для решения таких задач, либо искать их в инете, либо придумывать своё решение. Недавно я сам столкнулся с подобной ситуацией и нашёл, казалось бы, очевидное решение, но, тем не менее, ранее я им не пользовался. Вот им бы хотелось поделиться с сообществом в представленном ниже переводе очень небольшой статьи.

Проблема огромного количества boilerplate-кода при использовании Redux известна всем, каждый ее решает как может. И мы на разных проектах использовали разные костыли и велосипеды, не теряя при этом надежду найти что-то стандартизированное и удобное. Чуть больше года назад мы отчаялись в своих поисках и всерьез взялись за решение проблемы. Что из этого получилось — описано ниже.

Привет!

Меня зовут Вьет, и больше 10 лет я с любовью пишу код. В прошлом году меня пригласили в программный комитет, в котором большие фанаты качественной разработки делали конференцию QualityConf. Мы верим, что качественная разработка не ограничивается вопросами тестирования, поэтому собрали под одной крышей доклады про различные аспекты качества продуктов.

Но нашу команду поджидали две серьезные проблемы.

^{«Чистый код» и чистый кот}

Разработчиков хлебом не корми, дай поспорить о чистоте кода: например, недавно шумиху навёл пост Дэна Абрамова «Goodbye, Clean Code».

Но при этом у самого понятия «чистый код» нет чёткого определения. Главная книга по этому вопросу — «Clean Code», где Роберт «Дядюшка Боб» Мартин сразу заявляет: «сколько программистов, столько и определений». Впрочем, из этого он делает не вывод «говорить об этом бесполезно», а вывод «стоит сравнить разные определения». Поэтому в книге он привёл мнения нескольких выдающихся программистов о том, что такое чистый код.

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

В апреле Дядюшка Боб прилетит в Петербург выступить на трёх наших конференциях, и они как раз по трём разным направлениям (про .NET-разработку, про тестирование и про JavaScript). Поэтому мы спросили нескольких спикеров этих конференций, что такое чистый код для них, чтобы сравнить мнения экспертов индустрии в 2020-м.

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

UPD: Когда мы писали эту статью, Роберт планировал приехать на наши конференции. К сожалению, ситуация изменилась. Также из-за запрета на проведение массовых мероприятий мы перенесли конференции на другие даты. Следите за обновлениями на сайте конференции. 13 марта мы обновили этот пост, чтобы он не содержал некорректную информацию.

Мне давно было интересно, как сжимаются данные, в том числе в Zip-файлах. Однажды я решил удовлетворить своё любопытство: узнать, как работает сжатие, и написать собственную Zip-программу. Реализация превратилась в захватывающее упражнение в программировании. Получаешь огромное удовольствие от создания отлаженной машины, которая берёт данные, перекладывает их биты в более эффективное представление, а затем собирает обратно. Надеюсь, вам тоже будет интересно об этом читать.

В статье очень подробно объясняется, как работают Zip-файлы и схема сжатия: LZ77-сжатие, алгоритм Хаффмана, алгоритм Deflate и прочее. Вы узнаете историю развития технологии и посмотрите довольно эффективные примеры реализации, написанные с нуля на С. Исходный код лежит тут: hwzip-1.0.zip.

Предисловие

Модульное тестирование (unit testing) применяется повсеместно. Кажется, уже никто без него не обходится, все пишут тесты, а их отсутствие в сколь-нибудь серьёзном проекте вызывает, как минимум, непонимание. Однако, многие воспринимают тестирование как некий ритуал, совершаемый для того, чтобы не разгневать "бога программирования". Мол, так надо. Почему? Потому что.

Буду говорить страшные вещи.

Не важно, что брать за единицу тестирования. Не важно, как сгруппированы тесты. Не важно, пишутся ли они до кода или после. TDD или не TDD? Всё равно. Доля покрытия? Наплевать. В конце концов, тестов может совсем не быть. Всё это совершенно не важно. Важно, чтобы выполнялись требования, предъявляемые к ПО.

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

Постойте, причём же тут наука с математикой?

Всем привет, меня зовут Константин. Я занимаюсь разработкой на Java в Tinkoff.ru и люблю SOLID. В этой статье мы сформулируем принцип подстановки Лисков, покажем его связь с принципом Открытости-Закрытости, узнаем, как правильно формировать иерархию наследования и ответим на философский вопрос о том, является ли квадрат прямоугольником.

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.

Оценивая свою работу, я недавно много размышлял о том, как мне писать хороший код. Учитывая, что никто не интересуется тем, как писать плохой код, возникает вопрос: как узнать, что ты написал на Go хороший код? Если есть какая-то шкала между хорошо и плохо, то как понять, какие части шкалы относятся к хорошему? Каковы его свойства, атрибуты, отличительные признаки, паттерны и идиомы?

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

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

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

«Человек может стать человеком только путем воспитания. Он — то, что делает из него воспитание»
И. Кант

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

Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.

Как этого можно избежать?