Обновить
64K+

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

Как Макконнелл завещал

59,81
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

В анализаторе все должно быть прекрасно: и функциональность, и интерфейс… Изучаем новый интерфейс Solar appScreener 3.1

Время на прочтение10 мин
Охват и читатели9K
imageКак говаривал Генри Форд, все можно сделать лучше, чем делалось до сих пор. Вот и мы так подумали, когда приступили к работе над версией 3.1 нашего анализатора защищенности приложений. Нам ОООЧЕНЬ хотелось сделать наш продукт не только самым крутым по функциональности: например, реализовать поддержку максимального количества языков программирования. Но и наиболее эргономичным, удобным, эстетически привлекательным… – ну чтобы прям глаз не оторвать! И так мы увлеклись своей задумкой, что даже название продукту поменяли. В общем, выложились по полной. А результатами своих усилий решили поделиться с вами в этом обзоре.
Читать дальше →

Черновик FAQ: Почему стандарты С++ выходят каждые три года?

Время на прочтение11 мин
Охват и читатели11K

У WG21 есть строгий график (см. P1000) выпуска стандарта каждые три года. И никаких задержек.

В течение каждого цикла мы регулярно получаем вопросы «ну почему так строго?», особенно от новых участников комитета, которые не знакомы с его историей и причинами текущего положения вещей. И во время предварительной телеконференции с администрацией Кёльна несколько человек порекомендовали описать, почему мы так делаем и как принималось решение о принятии этого графика.

Всё это я расписал в виде вопросов и ответов для следующего черновика Р1000, и разослал копию участникам комитета, направлявшимся в Кёльн. Этот материал будет опубликован в следующей публичной версии Р1000, её мы разошлём через несколько недель начиная с текущего момента.

Однако и черновик FAQ может быть интересен публике, поэтому предлагаю вашему вниманию его копию. Надеюсь, он будет для вас по большей части полезен, в чём-то просветит, и, возможно, даже немного развлечёт.

Читать дальше →

С++, определен ли тип: предварительное декларирование нужных объектов

Время на прочтение4 мин
Охват и читатели4.2K
В прошлый раз, мы использовали SFINAE, чтобы понять, есть ли у типа определение, и мы использовали это в сочетании с if constexpr и универсальными лямбда-выражениями, чтобы код мог использовать тип, если он определен, при этом все еще принимаясь компилятором (и отбрасываясь) если тип не определен.

Однако в этом применении существует несколько проблем:

  • Каждый раз нужно писать struct.
  • Если тип не существует, то при присвоении ему имени этот тип вводится в текущее пространство имен, а не в пространство имен, в котором вы хотели, чтобы тип был.
  • Нужно использовать struct с неквалифицированным именем. Нельзя использовать его для проверки типа, который вы не импортировали в текущее пространство имен.

Мы можем исправить все три проблемы с помощью одного решения: предварительно объявить тип в нужном пространстве имен.

Читать дальше →

TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development

Время на прочтение13 мин
Охват и читатели163K

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



  • TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
  • BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
  • TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
  • DDD — bound contexts, ubiquitous language, domain...
  • FDD — да сколько можно?
  • MDD — cерьезно, на основе диаграмм?
  • PDD — ...

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


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

Читать дальше →

Custom refactoring tool: Swift

Время на прочтение10 мин
Охват и читатели7.9K
Любой инженер стремится сделать процесс своей работы максимально оптимизированным. Нам, как мобильным разработчикам iOS, очень часто приходится работать с однообразными структурами языка. Компания Apple улучшает инструменты разработчиков, прилагая много усилий, чтобы нам было удобно программировать: подсветка языка, автодополнение методов и многие другие возможности IDE позволяют нашим пальцам успевать за идеями в голове.



Что делает инженер, когда необходимый инструмент отсутствует? Верно, сделает всё сам! Ранее мы уже рассказывали о создании своих кастомных инструментов, теперь поговорим о том, как модифицировать Xcode и заставить его работать по твоим правилам.
Читать дальше →

Автоматизация импортов в Python

Время на прочтение7 мин
Охват и читатели23K
До После
import math
import os.path

import requests

# 100500 other imports

print(math.pi)
print(os.path.join('my', 'path'))
print(requests.get)
import smart_imports

smart_imports.all()

print(math.pi)
print(os_path.join('my', 'path'))
print(requests.get)
Так получилось, что аж с 2012 года я разрабатываю open source браузерку, являясь единственным программистом. На Python само собой. Браузерка — штука не самая простая, сейчас в основной части проекта больше 1000 модулей и более 120 000 строк кода на Python. В сумме же с проектами-спутниками будет раза в полтора больше.

В какой-то момент мне надоело возиться с этажами импортов в начале каждого файла и я решил разобраться с этой проблемой раз и навсегда. Так родилась библиотека smart_imports (github, pypi).

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

Например, не надо будет писать import math чтобы обратиться к math.pi — мы и так можем понять, что в данном случае math — модуль стандартной библиотеки.

Smart imports поддерживают Python >= 3.5 Библиотека полностью покрыта тестами, coverage > 95%. Сам пользуюсь уже год.

За подробностями приглашаю под кат.
Читать дальше →

Как придумывать содержательные имена для вашего кода

Время на прочтение4 мин
Охват и читатели14K
Перед вами перевод статьи из блога Better Programming на сайте Medium. В ней программист Daan делится простыми правилами, следуя которым вы сможете давать хорошие имена функциям и переменным.



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

Так как мы проводим столько времени присваивая имена, очень важно делать это качественно. В данной статье я расскажу вам о нескольких простых правилах, следуя которым вы сможете создавать хорошие имена. Ведь это целое искусство!
Читать дальше →

Я нашёл отличного программиста по имени Стив Возняк

Время на прочтение2 мин
Охват и читатели40K
Давным-давно, когда компьютеры были большими, а бизнес скучным, произошло нечто неожиданное. Молодые хакеры нашли способ собрать персональные компьютеры на дешёвых микропроцессорах от телетайпов и светофоров. Одним из них был Стив Возняк. Эти ребята восприняли ограничения своих компьютеров как вызов, сели и заставили эти крошечные чипы делать удивительные вещи. Вот что публиковал Dr Dobb's Journal в августе 1976 года:



Это набор арифметических процедур на действительных числах. Микропроцессор (6502, такой же, как в Apple I и II) мог работать только с байтами, то есть целыми числами между 0 и 255. Хуже того, он мог только складывать и вычитать их. Но с помощью этой библиотеки вы можете вычислить $1.2627-1099.56$, или даже взять квадратный корень из пи. Удивительно, но автор программы по имени Стив Возняк уместил основные функции (сложение, вычитание, умножение и деление) в 239 байт, используя всего 127 инструкций.
Читать дальше →

Как писать код, чтобы коллеги тебя не материли

Время на прочтение2 мин
Охват и читатели6.6K
Представьте себе одну единственную вещь, которая сделает ваш код более понятным, а так же поможет вам намного легче разбираться в чужом коде и вы будете меньше «обсирать» чужой код, который был написан еще до того, как вы пришли в компанию. А самое лучшее вы всегда будете понимать, стоить ли его изменять или лучше не прикасаться к нему. Представили?!
Читать дальше →

Чистая архитектура решения, тесты без моков и как я к этому пришел

Время на прочтение6 мин
Охват и читатели16K

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

Читать дальше →

Application Security Manager. Разработчик или безопасник?

Время на прочтение6 мин
Охват и читатели7.4K
Большинство успешных атак организации реализуется через уязвимости и закладки в софте. К счастью, сканер уязвимостей ПО уже рассматривается компаниями не как что-то экзотическое, а как необходимый элемент инфраструктуры защиты. Если при небольших объемах разработки можно использовать сканер as is, то когда объемы большие, приходится автоматизировать процесс. Но кто должен им управлять? Решать, как часто проверять релизы? Заниматься верификацией уязвимостей? Принимать решение, наложить ли вето на релиз и отправить код на устранение уязвимостей? И отвечать на многие другие вопросы. Вот тут на авансцену выходит Application Security Manager — менеджер по безопасной разработке ПО.

image

Но где сыскать такую редкую птицу или как вырастить самим? Артем Бычков, менеджер по безопасности приложений АО «Райффайзенбанк», и Даниил Чернов, руководитель направления Solar appScreener компании «Ростелеком-Солар», рассказывают, какие требования к Application Security Manager диктует практика разработки в российских компаниях.
Читать дальше →

Типичные ошибки при логгировании

Время на прочтение7 мин
Охват и читатели12K

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


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


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

Читать дальше →

10 принципов самодокументируемого кода

Время на прочтение6 мин
Охват и читатели44K
Привет! Сегодня я хочу поделиться советами по написанию совершенного понятного кода, взятые из книги Питера Гудлифа «Ремесло программиста // Практика написания хорошего кода».

Конечно, неплохо было бы прочитать эту занимательную книгу каждому кто пишет код, но для особо ленивых, но желающих перестать меньше мучить и вводить коллег в заблуждение (совесть имейте) представляю под катом 10 принципов самодокументируемого кода:
Читать дальше →

Ближайшие события

Избыточная сложность

Время на прочтение3 мин
Охват и читатели3.8K
Слышал такое выражение, что для того чтобы стать программистом, нужно быть ленивым. Но иногда лень в программировании приводит к возникновению ужасного технического долга. В своей заметке об SRP я упоминал, что нарушение этого принципа может привести к увеличению сложности или даже к умножению ее. Один из моих коллег произвел на свет интересный пример, и я решил с его помощью продемонстрировать как это выглядит.



Давайте определимся, что же такое эта избыточная сложность. Но для начала поговорим о ее противоположности, о сложности исходящей от требований. Для примера есть требования посчитать зарплату сотрудника из почасовой ставки и отработанных часов. И, если сотрудник работает в компании больше пяти лет, начислить бонус. Это «если» исходит из требований, и избежать его нельзя. В той или иной форме оно станет элементом сложности в коде приложения, скорее всего в виде условного оператора «if». Но иногда сложность не исходит из требований, а вытекает из подхода разработчика к решению задачи.
Читать дальше →

Python не запрещает вызов private/protected методов потому, что любит тебя :-)

Время на прочтение3 мин
Охват и читатели14K
Много копий сломано в обсуждениях того, почему питон эдакий бяка — не запрещает вызывать непубличные методы. И конечно, не раз звучали объяснения в духе «мы все тут взрослые люди», но похоже их было недостаточно, мне кажется, я наконец понял, как это объяснить более понятно, надеюсь, что это действительно так.

Напомню, что для private методов питон всего-лишь динамически изменяет имя и никак не ограничивает доступ к нему, а для protected не делает и этого, это просто соглашение об именовании методов, для тех кто не очень в курсе, есть дополнительные материалы тут и тут.
Читать дальше →

3 практических примера использования деструктурирования в JavaScript

Время на прочтение2 мин
Охват и читатели8.8K

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



Вы, наверное, уже знакомы с деструктурированием в 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, порядок теперь не важен, и аргументы сопровождаются своими именами. Всё это возможно именно благодаря деструктурированию.

Читать дальше →

Чему я научился на своём горьком опыте (за 30 лет в разработке ПО)

Время на прочтение22 мин
Охват и читатели118K
image

Это циничная, клиническая коллекция того, чему я научился за 30 лет работы в разработке программного обеспечения. Повторюсь, некоторые вещи весьма циничны, а остальное — результат долгих наблюдений на разных местах работы.
Читать дальше →
982 слайда Фридмана на тему производительности во фронтенде, обсуждение Yandex Database, мониторинг Postgres, взгляд на свой продукт глазами инвестора под руководством Морейниса, новая конференция по качеству, слет DevRel'ов, текучка кадров, оценка вклада сотрудника, польза от факапов — все это в небольшом фоторепортаже с площадки РИТ++, где мы наблюдали за происходящим глазами участника. А также о программе фестиваля, гиковских играх, призах и о прочих интересных моментах.
Подробности – под катом

Один язык чтобы править всеми

Время на прочтение6 мин
Охват и читатели28K

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



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


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


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


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


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


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


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

Читать дальше →

Стоит ли высокое качество ПО затрат на его разработку?

Время на прочтение12 мин
Охват и читатели29K

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

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

Несмотря на то, что основная целевая аудитория статьи это разработчики, для её понимания не требуется специальных знаний. Мне бы хотелось чтобы эта статья принесла пользу всем, кто так или иначе связан с процессом разработки, а особенно менеджерам, которые формируют вектор развития продуктов.
Читать дальше →