Конечно, в идеале лучше вообще Не писать лишнего кода. А если и писать, то, как известно, нужно хорошо продумывать кости системы архитектуру системы и реализовывать мясо системы логику системы. В данной заметке мы приведем рецепты для удобной реализации последнего.
Рубрика «Совершенный код» - 27
О декомпозии кода замолвим слово: контекстное программирование
2018-06-09 в 11:16, admin, рубрики: clojure, erlang, код, Совершенный кодОчень простое объяснение принципов SOLID
2018-06-09 в 9:42, admin, рубрики: solid, ооп, ООП головного мозга, пятничный пост, Совершенный кодDisclaimer: Всем можно, ну а я чем хуже!?
SOLID — это набор принципов по организации кода. Фактически они декларируют некие правила, которые помогут вам сохранить свои и чужие нервы и время. А могут и не помочь.
Попробуем разобраться в этих принципах на пальцах, без примеров кода и СМС.Читать полностью »
Статический анализ в Go: как мы экономим время при проверке кода
2018-06-07 в 14:19, admin, рубрики: Go, open source, roistat, Блог компании Roistat, никто не читает теги, Совершенный код, статический анализ кода, управление разработкой
Привет. Меня зовут Сергей Рудаченко, я техлид в компании Roistat. Последние два года наша команда переводит различные части проекта в микросервисы на Go. Они разрабатываются несколькими командами, поэтому нам понадобилось задать жесткую планку качества кода. Для этого мы используем несколько инструментов, в этой статье речь пойдет об одном из них — о статическом анализе.
Статический анализ — процесс автоматической проверки исходного кода при помощи специальных утилит. Эта статья расскажет о его пользе, кратко опишет популярные инструменты и даст инструкции по внедрению. Её стоит читать, если вы не сталкивались с подобными инструментами вовсе или используете их несистематически.
В статьях по этой теме часто встречается термин «линтер». Для нас это удобное название простых инструментов для статического анализа. Задача линтера — поиск простых ошибок и некорректного оформления.
Психология читабельности кода
2018-05-29 в 11:32, admin, рубрики: Блог компании Инфопульс Украина, Исследования и прогнозы в IT, Программирование, Совершенный код, читабельность кодаВсё, что написано ниже, ни разу не претендует на абсолютную истину, но всё же представляет собой некоторую модель, помогающую лично мне находить способы писать немного лучший код.
Каждый программист старается писать хороший код. Читабельность — один из главных признаков такого кода. О ней написано достаточно много книг, но всё же в теме есть пробелы. Например, те самые книги сфокусированы больше на советах КАК написать читабельный код, а не на причинах того, почему один код является хорошо читабельным, а другой — нет. Книга говорит нам «используйте подходящие названия переменных» — но что делает одно название более подходящим, чем другое? Работает ли это для всех примеров подобного кода? Работает ли это для всех программистов, которым попадётся на глаза этот код? Как раз о последнем я и хотел бы поговорить чуть детальнее. Давайте погрузимся немного в человеческую психику. Наш мозг — главный наш инструмент, хорошо бы изучить специфику его работы.
Комментирование кода: хороший, плохой, злой
2018-05-07 в 12:32, admin, рубрики: IT-стандарты, Блог компании Mail.Ru Group, комментирование кода, никто не читает теги, Программирование, Проектирование и рефакторинг, Совершенный код
Вы наверняка это слышали: «Хороший код является самодокументированным».
Я больше 20 лет зарабатываю написанием кода, и слышал эту фразу чаще всего. Это клише.
И как во многих других клише, здесь есть зерно истины. Но это истиной уже столько злоупотребляли, что большинство из тех, кто произносит эту фразу, не понимает, что она на самом деле означает.
Она истинна? Да.
Означает ли она, что вы никогда не должны комментировать код? Нет.
В этой статье мы рассмотрим разные аспекты комментирования кода.
Читать полностью »
Не пишите лишнего
2018-05-02 в 12:50, admin, рубрики: codestyle, java, код, ооп, Программирование, рефакторинг, Совершенный кодВсе думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.
Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.
HoleyBeep: объяснение и эксплоит
2018-04-24 в 7:48, admin, рубрики: beep, Блог компании Mail.Ru Group, информационная безопасность, никто не читает теги, параллельное программирование, Совершенный код, Тестирование IT-систем, эксплойт
В былые времена люди использовали a для генерирования неприятных «гудков» из спикеров системных блоков. Это было особенно неудобно, если хотелось генерировать более сложные звуковые последовательности вроде 8-битной музыки. Поэтому Джонатан Найтингейл написал программу beep. Это была коротенькая и очень простая программа, позволявшая тонко настраивать звучание из спикера.
С появлением X-сервера всё стало куда сложнее.
Чтобы beep могла работать, пользователь должен был либо быть суперпользователем, либо являться владельцем текущего tty. То есть beep всегда будет работать у root-пользователя или у любого локального, но не будет работать у не-root удалённого пользователя. При этом любой терминал (например, xterm), подключённый к X-серверу, считается «удалённым», и поэтому beep работать не будет.
Читать полностью »
Проверяй входящие данные. Исходная причина уязвимости и атаки на Cisco IOS
2018-04-07 в 15:36, admin, рубрики: Анализ и проектирование систем, входные данные, доверие, информационная безопасность, переполнение буфера, Программирование, Промышленное программирование, Совершенный код, умолчания, уязвимость
В пятницу 6 апреля 2018 началась мощная атака на оборудование Cisco.
Много пишут о том, что главная причина, по которой эта атака успешна, это открытые во внешние сети сервисные порты Cisco Smart Install.
Эти порты открыты по умолчанию. А люди в массе своей оставляют то, что сконфигурировано/выбрано/настроено таким, каким оно было по умолчанию. Как видим, на примере этого случая, это касается не только домашних роутеров, но и серьёзного оборудования в крупных компаниях, где цена ошибки значительно выше.
При создании системы вы не имеете права расчитывать на то, что значения по умолчанию, которые следует изменить будут изменены, причём в нужную сторону.
Вы лишь можете заставить изменить эти значения с помощью каких либо ограничивающих использование приёмов. Чему многие будут не рады. «Защита от дурака» это один из примеров этих обязывающих ограничений.
Про выбор по умолчанию
Есть исследование 2003 года «Спасает ли жизни выбор по умолчанию?», в котором есть диаграмма
.
На русском подробнее.
В ней видно, что число тех, кто готов участвовать в программе донорства органов сильно зависит от того, какой выбор по умолчанию уже сделан в медицинской анкете.
. На русском подробнее.
В ней видно, что число тех, кто готов участвовать в программе донорства органов сильно зависит от того, какой выбор по умолчанию уже сделан в медицинской анкете.
Я хочу обратить внимание на корень самой уязвимости. В отчёте есть такая часть: Читать полностью »
Code Conventions: как мы сохраняем быстрый темп разработки PHP-проекта
2018-04-05 в 8:43, admin, рубрики: code conventions, github, open source, php, roistat, Блог компании Roistat, никто не читает теги, Совершенный код, управление разработкойПривет. Меня зовут Евгений Удодов, я сооснователь и технический директор компании Roistat. Хочу поделиться нашим опытом разработки большого и сложного продукта — системы аналитики.
TL;DR: Мы выложили на github наш Code Conventions и рассказали в статье о том, как его применять на практике.
При разработке больших продуктов существует распространенная проблема — с течением времени накапливается много legacy-кода, задачи делаются все медленнее и медленнее. Также при росте команды разработчики начинают писать код по-разному и отсутствие единых правил может приводить к конфликтам и спорам.
За 4 года существования нашего проекта мы сделали больше 20 000 Pull Request’ов (далее PR) и под катом я расскажу, как же мы решили эти проблемы.
Requiem for a Dream
2018-04-05 в 6:53, admin, рубрики: 1С, битрикс, Программирование, программисты, Совершенный код, управление персоналом, управление проектами, управление разработкойПролог
— Ты, главное, не ссы! Держись меня, делай как я, и все будет чики-пуки.
Сергея всегда бесил такой, колхозный, стиль общения, особенно у малознакомых людей. Не понятно, как реагировать. Вроде надо в лицо идиотом назвать, но мало ли, вдруг человек не всегда такой, просто не умеет эмоции словами выразить. Тем более, Сергей первый день на этой работе. На своей первой настоящей работе.
— Коль, давай посерьезнее. — Жанна строго посмотрела на круглую самодовольную рожу. Потом перевела взгляд на новенького. — Сергей, не слушай этого старого коня. Борозды он, конечно, не испортит, но и целины не поднимет.
Сергею пришлось улыбнуться — все-таки начальник пошутил, и вроде не совсем безнадежно.
— Мы на тебя возлагаем большие надежды, Сережа. Николай у нас под завязку загружен текучкой — ее очень много. Мы понимаем, что действуем неэффективно, где-то что-то упускаем, используем устаревшие технологии и подходы… Но у нас реально нет времени остановиться, подумать, посмотреть, поучиться. Как писал Кови — наточить пилу.
Сергей понимающе покивал головой. Он не знал, кто такой Кови, но метафору понял.
— Ты — молодой, целеустремленный, не обремененный обязательствами и связями, амбициозный, и очень умный программист. У тебя за плечами очная Бауманка. Мы ждем от тебя новой струи свежего вохдуха, скачка в развитии наших систем, прорыва облачных технологий. Так, и только так!
— Спасибо, Жанна Ивановна. Я буду стараться.
— Никакого отчества, просто Жанна! Велкам в нашу команду, Сережа!
Читать полностью »