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

Здравствуйте, дорогие читатели! В этой статье я хочу рассказать об архитектуре своего проекта, который я рефакторил 4 раза на его старте, так как не был удовлетворен результатом. Расскажу о минусах популярных подходов и покажу свой.

Привет, Хабр!

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

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

Пишем код чище, используя паттерны деструктурирования

Вы, наверное, уже знакомы с деструктурированием в JavaScript. Оно пришло к нам в 2015 году в спецификации ES6, но если вам нужно освежить знания, то на сайте Mozilla можно почитать большую подробную статью, как это всё работает.

Но знать как работает совсем не то же, что знать как использовать. Вот три паттерна, которые помогут вам сделать код чище, надёжнее и читаемее!

1. Именованные аргументы функции

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

def sum(a=1,b=2,c=3):
  return a+b+c

sum(b=5,a=10)

Видите? Порядок не важен, если вы явно указали имя параметра. Преимуществами по сравнению с позиционными аргументами является то, что:

1. Можно опустить один или несколько параметров при вызове функции
2. Порядок при передаче аргументов теперь не важен
3. Код стал читаемее 

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

function sum({a = 1, b = 2, c = 3}) {
  return a + b + c
}

sum({b: 10, a: 5}) // 5 + 10 + 3 = 18

Все цели достигнуты: можно не указывать c, порядок теперь не важен, и аргументы сопровождаются своими именами. Всё это возможно именно благодаря деструктурированию.

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

На момент написания этой статьи запрос «программирование какой язык изучать первым» выдаёт 517 миллионов поисковых результатов. Каждый из этих сайтов будет нахваливать один определённый язык, и 90% из них, в конечном итоге, порекомендуют Python или JavaScript.

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

Просто знать как кодить ещё не достаточно. Рынок настолько насыщен выпускниками институтов и курсов, что позиция джуниора практически перестала существовать*. Чтобы преуспеть в сегодняшнем мире, вы должны и кодить, и иметь продвинутое фундаментальное логическое мышление.

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

Мой первый урок информатики

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

«Сегодня мы будем дегустировать самостоятельно приготовленные пломбиры. Но с одним условием: вы должны составить список конкретных инструкций, как приготовить десерт, а я — буду им следовать»

На ваш суд скорее статья-вопрос, статья-рассуждение и местами — недоумение. С одной стороны нам презентовали авторитетное мнение Лесли Лэмпорта "Programming Should Be More Than Coding", расставляющее программирование и кодирование в импровизированном табеле о рангах. С оппонирующей стороны — я, не обладающий статусом достаточным для споров с мэтром и легендарным ВУЗом, который он представляет… но отказать себе в таком удовольствии и риске я не могу. Надеюсь, более опытные товарищи поправят мои огрехи в рассуждениях.

Умом я понимаю, что кодирование в современном мире принято воспринимать как низшую ступень инженерной деятельности, которая на эволюционном графике скорее ближе к шимпанзе, чем к программисту. И, возможно, в этом кроется наша большая ошибка, поскольку код — он как ДНК. Всего четыре нуклеотида, а какая пёстрая биомасса в продуктовой линейке.

Как опытные инженеры, мы — мастера абстракций. Поэтому для нас не составит труда представить условного программиста по имени Лесли Лэмпорт (все имена и совпадения не случайны) и его основной инструмент — машину Тьюринга. Он — мастер своего дела, во многом благодаря железному дао:

Краткая предыстория

def test_dist():
    p1 = (0, 3)
    p2 = (4, 0)
    assert dist(p1, p2) == 5

def test_dist():
    p1 = random_point()
    p2 = random_point()
    assert dist(p1, p2) >= 0

Single responsibility principle, он же принцип единой ответственности,
он же принцип единой изменчивости — крайне скользкий для понимания парень и столь нервозный вопрос на собеседовании программиста.

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

В лесу нас разделили на группы по 8-9 человек в каждой и устроили соревнование — какая группа быстрее выпьет бутылку водки при условии, что первый человек из группы наливает водку в стакан, второй выпивает, а третий закусывает. Выполнивший свою операцию юнит встает в конец очереди группы.

Случай, когда размер очереди был кратен трем, и являлся хорошей реализацией SRP.