Рубрика «Совершенный код» - 24

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

Кстати, функциональные программисты правы. Чистые функции — это хорошо. Но есть одна проблема…

Борьба с грязными побочными эффектами в чистом функциональном JavaScript-коде - 1


Автор материала, перевод которого мы представляем вашему вниманию, хочет рассказать о том, как бороться с побочными эффектами в чистых функциях.
Читать полностью »

Мне на глаза попался документ с правилами и рекомендациями по процессу ревью кода внутри компании. Я решил, что такой полезной информацией надо поделиться с внешним миром. С благословения автора я публикую работу
Процесс ревью кода в HH.RU - 1
Читать полностью »

Сортировки выбором - 1

В чём идея сортировок выбором?

  1. В неотсортированном подмассиве ищется локальный максимум (минимум).
  2. Найденный максимум (минимум) меняется местами с последним (первым) элементом в подмассиве.
  3. Если в массиве остались неотсортированные подмассивы — смотри пункт 1.

Читать полностью »

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

Есть один важный параметр который присутствует почти всегда. Это способность других людей понимать написанный вами код. И чем проще его понять тем лучше. Это позволяет новому члену команды быстро влиться в проект, быстрее найти баг или выполнить рефакторинг. Простота позволяет тратить меньше интеллектуальных ресурсов для решения задачи, а значит и быстрее решить её с точки зрения временных затрат.
Читать полностью »

Я боролся с соблазном назвать статью как-то типа «Ужасающая неэффективность алгоритмов STL» — ну, знаете, просто ради тренировки в мастерстве создания кричащих заголовков. Но всё же решил оставаться в рамках приличий — лучше получить от читателей комментарии по содержанию статьи, чем негодование по поводу её громкого названия.

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

Алгоритмы

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

Каждый раз, когда вам хочется написать очередной for — следует сначала вспомнить, нет ли в STL (или в boost) чего-то, что уже решает эту задачу в одну строку. Если есть — чаще лучше использовать это. Нам, однако, и в этом случае следует понимать, что за алгоритм лежит за вызовом стандартной функции, каковы его характеристики и ограничения.

Обычно, если наша проблема в точности совпадает с описанием алгоритма из STL, будет хорошей идеей взять и применить его «в лоб». Беда только в том, что данные не всегда хранятся в том виде, в котором их хочет получить реализованный в стандартной библиотеке алгоритм. Тогда у нас может возникнуть идея сначала преобразовать данные, а потом всё же применить тот же алгоритм. Ну, знаете, как в том анекдоте про математика «Затушить огонь из чайника. Задача сведена к предыдущей».
Читать полностью »

Предисловие

​Все началось более 2-х лет тому назад, и я перешел на 4-й курс специальности "Бизнес-информатика" Томского Государственного Университета Систем Управления и Радиоэлектроники (ТУСУР). До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому. Вариантов тем дипломных проектов рассматривалось много: и проекты конфигураций для автоматизации производственных нужд компании и проект внедрения Документооборота своими силами на 3 территориальные единицы и более 500 активных пользователей и внедрение ЭДО. Короче много всего что было в голове, но ничего из этого не вдохновляло. А это было главное.

Читать полностью »

Вы не умеете работать с транзакциями - 1

Заголовок вышел броским, но накипело. Сразу скажу, что речь пойдет об 1С. Дорогие 1С-ники, вы не умеете работать с транзакциями и не понимаете что такое исключения. К такому выводу я пришел, просматривая большое количество кода на 1С, рождаемого в дебрях отечественного энтерпрайза. В типовых конфигурациях с этим все достаточно хорошо, но ужасающее количество заказного кода написано некомпетентно с точки зрения работы с базой данных. Вы когда-нибудь видели у себя ошибку "В данной транзакции уже происходили ошибки"? Если да — то заголовок статьи относится и к вам. Давайте под катом разберемся, наконец, что такое транзакции и как правильно с ними обращаться, работая с 1С.

Читать полностью »

Чистый код читается, как хорошо написанная проза.
Грэди Буч в книге «Чистый код»

Ребус как код

Ребусы в коде, и как их расшифровать. Тайная сила идентификаторов - 1

Что такое ребус? Это зашифрованное послание. Автор ребуса берёт обычный человеческий текст и кодирует его при помощи рисунков, чисел и букв. А мы разглядываем такую шифровку и пытаемся прочесть исходный текст.

У ребуса есть две ипостаси. С одной стороны ребус — это исходный незашифрованный текст, а с другой — шифрорисунки. Текст — это «что» ребуса, его смысл, сообщение. Рисунки — это «как»: как именно зашифровано сообщение, с помощью каких средств. Отгадывая ребус, мы переводим «как» в «что».
Читать полностью »

Автор материала, перевод которого мы публикуем сегодня, говорит, что она прямо-таки одержима написанием чистого кода. Она считает, что код надо писать так, чтобы, во-первых, с ним, в будущем, удобно было бы работать другим программистам, включая его автора, а во-вторых — с учётом возможности расширения этого кода. То есть, нужно стремиться к тому, чтобы в приложение сравнительно просто было бы добавлять новые возможности, и чтобы его кодовую базу было бы удобно сопровождать. Если бы программы писали, учитывая лишь нужды компьютеров, то, вероятно, программисты могли бы выражать свои мысли лишь с помощью нулей и единиц, больше ни о чём не заботясь. В этой статье приводится ряд рекомендаций по написанию качественного кода, проиллюстрированных примерами на JavaScript.

7 рекомендаций по оформлению кода на JavaScript - 1
Читать полностью »

Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.

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

Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня:Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js