Что такое грязный код

Грязный, чистый, устремлённый

Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?

Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код?

Давайте сначала разберёмся с определениями.

Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.

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

Эта аналогия не вполне корректна (как и большинство аналогий), но примерно передаёт ощущения, возникающие при работе с кодом. Неважно – чужим ли, своим ли, написанном пару месяцев назад и уже прочно забытым. Код либо нравится, либо нет. Он либо красив, чист и приятен – либо волосат, уродлив и дурно пахнет.

И, конечно же, у каждого есть свои критерии «красоты кода». Свой, так сказать, вкус.

Но, тем не менее, есть какие-то общие точки, о которых если и спорят, то вяло и соглашательски. Не о сути, а об обрамлении.
Давайте попробуем их перечислить.

Легко читается и понимается Запутан, неочевиден, трудно понимаем
Легко поддаётся изменениям Закостенел в своих внутренних связях; изменить что-либо стоит неимоверных усилий и жертв
Может быть расширен, либо встроен куда-нибудь в виде отдельного модуля Для расширения требует переписывания, для встраивания – обёрток
Поддаётся автоматизированному тестированию Может быть протестирован, лишь как «чёрный ящик»

Конечно, можно начать спор о «читабельности» или «понимабельности» кода. Это совсем не формализованные термины.

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

А желательно – основательно поковырять ООП и стараться инкапсулировать логику в отдельных классах, чтобы не приходилось напрягать головной мозг ни разбором огромных «портянок» кода на десятки экранов, ни запутанными связями процедур и функций, которые к тому же (omg) оперируют кучей глобальных переменных.

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

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

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

Чистый

Теперь давайте всё-таки попробуем разобраться – зачем же он вообще нужен, этот чистый код? И так ли уж плох код грязный и волосатый?

Ну, для начала нужно сказать: it depends.
Бывают моменты, когда написать «быстро и грязно» куда важнее, чем «долго и чисто». Хотя нужно отметить, что «грязно» далеко не всегда означает «быстро». Бывает, что ровно наоборот.

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

Например

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

Такую задачу вполне можно написать как угодно грязно – лишь бы утилька работала, а написание не заняло много времени. Ведь мы решаем здесь одну сиюминутную задачу.
Решить же задачу долговременную куда как лучше, изменив систему регистрации ошибок (писать те же численные данные в базу, например).

То есть утилиту эту в идеале используют один-два раза, после чего выкинут. Чистота кода здесь совершенно не важна.

Другой пример

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

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

Если ответ – «да» или хотя бы «возможно», то стоит уделить немного внимания тому, чтобы код был понятен хотя бы самому разработчику через месяц-другой, и в то же время позволял бы как-то себя расширять.
К примеру, добавлять другие последовательности запросов, конфигурировать адрес сервера и число запросов, значения ключевых параметров и т.д.

Это ненамного замедлит разработку утилиты «здесь и сейчас» — зато, когда вновь встанет вопрос о воспроизведении последовательности запросов на сервер – утилита будет тут как тут и потребует минимального допиливания; а главное – минимального времени на вспоминание, что там к чему.

Третий пример

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

Казалось бы – модуль изолирован, интерфейсы взаимодействия с другими модулями определены. «Кручу-верчу, говнокод писать хочу». Но тут возникает серьёзное «НО».

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

Но это не весь список вопросов. А кто будет работать с этим модулем через два-три года? Тот, кто его писал, или кто-то другой?

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

Если же работать с этим кодом будет сам разработчик – то тем более. Да он через полгода уже не будет помнить: что, где и как работает! Ему придётся разбираться в этом коде так, как будто код совершенно чужой. Не враг же он самому себе?

Четвёртый пример

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

С одной стороны – code and forget, можно писать что угодно и как угодно, лишь бы работало.

С другой стороны – а что, если этот заказчик через месяц вернётся и попросит за дополнительные деньги что-то добавить или переделать? Будем плакать, колоться, но жевать кактус? Откажемся от заказа?

А что, если он обратится к другому разработчику (компании), получит негативный feedback о качестве исполнения проекта, и больше никогда не вернётся к «злым говнокодерам», да ещё своим друзьям отсоветует?

Я уже не говорю о таких вещах, как качество кармы и память потомков.

Пятый пример

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

Да что там говорить – один говнокодер способен принести вреда больше, чем вражеский агент в тылу врага!
Если команда не изолирует его, бросив на написание никому не вредящих, ни с чем не связанных, абсолютно левых утилит и мини-приложений – то его продуктивность в команде будет не то, что нулевой – она будет отрицательной!

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

А тестирование? Сопровождение? Расширение функционала??

Я мог бы написать ещё пару хулительных абзацев – но нет. Не могу.
Клавиатура выпадает из ослабевших пальцев при мысли о том, сколько вреда может принести говнокод в команде…
Это ужасно… ужасно…

Устремлённый

Итак, мы примерно понимаем, что такое грязный код и чем он плох. Мы всё ещё не вполне понимаем, что такое чистый код, но ощущаем его необходимость.
Почему же он всегда есть, этот грязный код, почему он всегда присутствует и портит жизнь всем – в том числе и своим авторам?

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

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

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

И при этом, в идеале, он всегда ощущает, что его код всё ещё недостаточно хорош, что ему ещё далеко до совершенства. И пусть его сегодняшний «говнокод» на голову выше самого лучшего, что он писал два-три года назад – всё равно есть куда расти.

В связи с этим мне вспоминается один интереснейший разговор с моим коллегой, которому, как и мне, довелось провести не одно собеседование с кандидатами на должность разработчика – возможно, даже больше, чем собеседований в качестве такового кандидата.

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

1) Хорошо работающая голова (поэтому у нас всегда есть задачки на логику)
2) Высокий уровень самокритичности (поэтому всегда есть задачки на написание кода и поиск ошибок в нём)
3) Интерес к программированию (важен в меньшей степени, задачками не определяется в принципе)

То есть понятно, что если голова работает плохо – то разработчиком не станешь при всём желании и старании. Однако, если она даже золотая и светится от разумности – это ещё далеко не гарантия.

Частенько бывает, что молодой специалист, видя, как легко ему всё даётся (особенно – в сравнении с большинством своих одногруппников, сокурсников, просто ровесников) начинает искренне считать, что круче бывают только яйца.
И, хотя наверняка к этому есть некоторые основания, но ЧСВ зашкаливает настолько, что в итоге в один прекрасный момент он просто перестаёт развиваться, считая, что «я и так умный, а кто пытается это оспорить – тот дундук».

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

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

Начинает чаще выполнять задачи «строго по спецификации», желательно – уже знакомые задачи, из знакомых сфер. Меньше уделять внимания новым языкам, платформам, концепциям.

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

Но так и не достигает вершины своего изначального потенциала.

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

Ах, как прекрасна эта картина – так и хочется смахнуть несуществующую слезу! Как прекрасен он, этот устремлённый в бесконечность молодой человек, своим духовным порывом приподнимающий самые небеса, в которые нацелен его всепроникающий взгляд!

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

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

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

И знать, что хотя бы немного, хотя бы чуть-чуть – помог, поддержал, а не стоял в стороне, застывший в своём упоении собственной важностью, не бросал презрительных взглядов – «пхе… молодёжь..»

Чистый и безопасный код — миф или реальность?

Каждый язык программирования разработан с учетом разных операционных систем, платформ, стилей кодирования и предполагаемого использования. Обычно мы слышим о языках Python, PHP, Ruby, JavaScript, Java, C, C++ и C#, а также более современных их разновидностях, такие как Rust, Swift, Hack и многих других.

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

Когда речь заходит о чистом коде, мы представляем идеально продуманные строки. Это код, который был спланирован до того, как был написан. Настолько хорошо спланирован, что при первом запуске он работает без ошибок и без изъянов.

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

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

Чистый код — это объективно хороший код. Он написан максимально лаконично и элегантно, без дублирования. Он структурирован таким образом, чтобы его было легко читать как людям, так и компьютерам. Каждый может написать код, понятный компьютеру, но только хороший программист может написать код, понятный человеку.

Небрежно написанный код стоит дорого, а на его обслуживание уходит много времени и усилий. Кроме того, код более подвержен ошибкам, которые могут привести к сбою программы.

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

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

Отладка — это исправление ошибок в коде.

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

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

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

  • Отсутствие избыточности кода

Код должен соответствовать правилу DRY (Don’t repeat yourself с англ. — «не повторяйтесь»). Это означает, что любое изменение в одном участке не должно требовать изменений в других.

  • Минимум зависимостей

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

  • Минимум расширений

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

  • Функциональность и легкочитаемость кода

Код должен быть прост, удобен и понятен, чтобы любой разработчик мог его быстро прочитать. Для этого многие разработчики используют правила KISS (keep it simple and straightforward с англ. — «сохраняйте простоту») и YAGNI (You aren’t gonna need it с англ. — «вам это не понадобится»).

  • Анализ кода

Используйте языковые инструменты статического анализа для проверки вашего кода.

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

  • Сегодня в мире разработки функциональность и скорость перевешивают безопасность. Предприятия не могут опережать конкурентов, не создавая и не выпуская новые фичи в короткие сроки.
  • Безопасность не является конкурентным отличием: потребители не думают о безопасности при использовании приложения или при покупке умного устройства, будь то умный термостат или лампочка. Вспомним инцидент из 2020, когда дрон смог взломать умные лампочки Philips Hue и вызвать вирусную реакцию.

Согласно отчету Veracode, более трех четвертей (75,8%) приложений имеют хотя бы один недостаток безопасности, а 23,7% содержат недостатки высокой степени серьезности, и исправление этих недостатков обычно занимает месяцы.

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

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

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

Список существующих уязвимостей довольно длинный, поэтому мы рассмотрим лишь некоторые из часто встречающихся, а также те, которые причиняют наибольший ущерб. Согласно исследованию одними из наиболее популярных уязвимостей являются: Information leakage (утечка информации) — 65,9%; Cross-Site Scripting (XSS, межсайтовый скриптинг) — 47,1%; SQL Injection (внедрение SQL-кода) — 27,8%.

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

В идеальном мире разработчик (самостоятельно или с привлечением специалистов) тестирует продукт на проникновение, применяя наиболее популярные и новые методы взлома, а после анализирует полученный результат и делает выводы.

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

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

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

  • «Чистый код. Создание, анализ и рефакторинг», Роберт Мартин

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

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

  • «Рефакторинг. Улучшение существующего кода», Мартин Фаулер

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

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

  • «Совершенный код» (Code Complete), Стив Макконнелл

Это высоко ценимая книга в индустрии разработки ПО. Основной посыл — «ошибки в программном обеспечении возникают из-за сложности кода». Книга была написана почти 30 лет назад, с тех пор идеи прочно вошли в сообщество разработчиков программного обеспечения.

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

Одним из недостатков является большой объем книги и то, что она, похоже, в основном ориентирована на объектно-ориентированные языки (C ++, Java) и даже более старые императивные (C, Ada и т. Д.)

  • Прочитайте дополнительно о принципах YANGI, DRY, KISS и SOLID.
    — ускоренные курсы программирования, курсы безопасности и учебные пособия по программированию. Для начинающих программистов этот канал предоставит множество полезных советов, практических примеров и сценариев. — самый оптимистичный программист на YouTube. Дэниел Шиффман, автор канала, помимо того, что является преподавателем в университете, создает массу отличного контента, в основном состоящего из учебных пособий и задач по программированию.
    — канал содержит много уроков по CSS и JavaScript, выпуски о различных нюансах и хитростях в работе с кодом. — это коллекция видеороликов, которые научат вас всему, что нужно для работы в качестве багхантера. — образовательные видео о компьютерах и компьютерных вещах. Есть серии видеороликов, связанных с темой кибербезопасности. — видеоуроки профессионального уровня почти по всем популярным языкам программирования. Тут туториалы по JavaScript, React, C++, ML, Arduino, C#, Django и по многим другим направлениям.
    — проверяет чистоту коммитов, готовность ваших проектов к выпуску и насколько хорошо ваш код соответствует цели. А если вы не попали в цель, вы сразу узнаете, что не так и как это исправить. — платформа безопасности приложений, которая автоматизирует тестирование на протяжении всего процесса непрерывной интеграции, чтобы разработчики могли быстро решать проблемы. — это инструмент статического анализа кода C/C ++, анализирующий код с целью обнаружения ошибок и с фокусом на обнаружении неопределенного поведения и опасных конструкций кода. Цель состоит в том, чтобы уменьшить количество ложных срабатываний. — инструмент автозавершения кода, основанный на искусственном интеллекте. — это средство для форматирования кода с поддержкой множества языков, которое нацелено на использование жестко заданных правил по оформлению программ. — линтер для JavaScript. Невероятно полезен, потому что JavaScript, будучи интерпретируемым языком, не имеет этапа компиляции и многие ошибки могут быть обнаружены только во время компиляции. ESLint позволяет разработчикам обнаруживать проблемы с кодом JavaScript, не выполняя его. — конфигурационный файл и набор расширений для настроек синтаксиса. Помогает поддерживать единый стиль кодирования для нескольких разработчиков, работающих над одним проектом в разных редакторах и IDE.
  • Hack the Box (HTB)

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

  • Академия Digital Security

Платформа от Академии Digital Security — бесплатная платформа по обучению кибербезопасности, которое построено на игровых механиках и нацелено на отработку практических навыков на реальных кейсах, развернутых на виртуальных машинах. Курсы разработаны действующими пентестерами и исследователями в области информационной безопасности.

Курс «Веб-безопасность» содержит обзор самых распространенных атак, ключевых мер защиты веб-приложений (корпоративных порталов, ДБО, систем электронной коммерции и т.д.) и методов аудита кода. С курсом «Безопасное программирование на Java» вы сможете развить навыки защиты, выполняя задания на эксплуатацию и исправление кода в приложениях, написанных на Java. При этом результаты будут видны сразу на живом приложении.

  • Pentestit

На платформе Pentestit есть программы практического обучения в области информационной безопасности: Zero Security: A и Corporate Laboratories. Учебный процесс включает теоретические и практические занятия, на которых опытные инструкторы Pentestit рассказывают о характере и способах обнаружения уязвимостей.

«Zero Security: A» — это программа начального обучения тестированию на проникновение Pentestit, в рамках которой стажеры осваивают различные инструменты тестирования на проникновение и изучают основы этического взлома: от разведки и сбора информации до обеспечения безопасности в системе.

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

Одна из самых известных и популярных образовательных платформ. На сегодняшний день у них есть учебники по HTML, CSS, Sass, JavaScript, Rails, AngularJS, ReactJS, Ruby, Command Line, Git, SQL и Java.

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

Миф. Следующий вопрос.

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

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

Первым на помощь пришел инструмент отмена действия — благо sublime text это делать позволяяет. Скопировал момент с ошибкой, и отменяешь анализируя или проверяяя результат.

Второй вариант, уже чуть позже, когда стал заниматься этим реже — сервис сравнить 2 текста. И здесь я видел все изменения от предыдущей точки.

Писать код без ошибок — это надо иметь тягу. Когда я начал, в один момент затянуло неслабо, я 2 ночи не спал (и дня), то есть 3 суток коддинга.

В определенный момент осваиваешь каждый раз всё новое и необходимое для развития. Это утечки, загрузка, многопоточность, умение написать полет снаряда с учетом законов физики (когда движок ничего не дает, разве что синус рассчитать может).

Потом была пауза. Армия. Вернулся, думал я сис админ.
В итоге, в свободное время стал писать игры в браузере для себя.
Позже занялся рекламой, так как всё так же сис-админил.

И только в 2017 году обнаружил, что все эти навыки ценны. Но я всё это делал для себя) Так что, кто то занимается для себя, а кто то ради другой цели, поэтому и есть всегда эта проблема "а почему код грязный?".

Как читать код, не понимая его.

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

  • во-первых, он лучше индексируется (по словам самих поисковых систем. Не то, чтобы грязный код не попадался в выдаче, но трактовать это можно так: при прочих равных условиях предпочтение будет отдано документу с более чистым кодом);
  • во-вторых, такой код значительно короче, а значит страница весит меньше и загружается быстрее;
  • ну и в-третьих, это определенным образом характеризует исполнителя. Если код грязный, с ошибками, большие куски закомментированного кода, не соблюдаются стандарты – возможно с таким верстальщиком лучше дела не иметь. Если он позволяет себе такие вольности в простых вещах, логично предположить, что в более серьезной ситуации (где более сложное программирование и вы не сможете проверить) будет все намного хуже?

В любом случае, глянуть код, стоит и я попытаюсь объяснить на какие основные моменты следует смотреть. Эта статья предназначена для новичков, которые очень плохо знают html, или вообще его не понимают.

1. Большие куски закомментированного кода.

Первое, на что вы должны обратить внимание – это куски старого неработающего кода. Выглядят они примерно так(если не знаете как посмотреть код, нажмите Ctrl+U или в любом месте кликните правой клавишей мыши и в всплывающем меню нажмите «Просмотр кода страницы»:
Закоментированный код
(все что подсвечивается зеленым – закомментированный, а по факту лишний код).
Обычно это появляется, когда на сайт вносятся какие-либо изменения. Программист, для подстраховки не удаляет старый код, а просто комментирует его (т.е. по сути код превращается в примечание, обычную текстовую заметку). Сам по себе прием безвреден, и действительно часто используется. Но это может быть только в период тестирование, или временных изменений. А вообще, в рабочей версии таких кусков быть не должно.
Правильный программист может сохранить код себе локально или под другим именем, но в рабочей версии промежуточных и тестовых вещей быть не должно. Помните, что аргумент «мне так удобней» — не оправдание. Удобней должно быть для пользователей (и для поисковых систем), но не для верстальщика.
Что допускается в коде – это короткие заметки, комментарии. Выглядят они так:
Комментарии в коде для работы
Это нормально. Убирать надо именно ненужный код, а не такие заметки.

2. Ошибки скриптов.

Тут вообще все просто. Особо думать ни о чем не надо, браузеры все продумали за вас. В Хроме или в ФаерФоксе нажмите клавишу F12, увидите консоль. Если интересуют подробности — смотрите на вкладку Console:
Ошибки скриптов в консоли
При наведении на цифру покажется сколько ошибок и предупреждений (в данном примере 8 ошибок). Тут уже разбираться должен программист. Некоторые ошибки незначительные, другие же наоборот, могут заблокировать загрузку части страницы (или постоянно перегружать ее).
Ваша задача просто посмотреть – есть ли ошибки или нет. В правильном, чистом коде их быть вообще не должно. Хотя редко когда встретишь сайт, на котором нет 2-3 ошибок скриптов. Но обратить внимание на них программиста нужно обязательно!

3. Использование стилей.

Стили – это специальный инструмент, который позволяет визуально выделять различные элементы на странице. Именно стили отвечают за то, какой размер и цвет у заголовка h1, как меняется ссылка при наведении на нее, и почему картинка именно такого размера и с такими отступами.

Прописать стили можно тремя способами, один из которых правильный, а два других – не очень.
А) Стиль указывается прямо в коде тега. Это самый старый, самый простой и, пожалуй, самый неправильный вариант назначения стилей. Выглядит он так:
Стили указаны в элементе
Чем он плох? Во-первых он значительно увеличивает код страницы, во-вторых делает ее более сложной для чтения. Ну и в-третьих, это не по стандарту. В html5 подобная конструкция уже воспринимается как ошибка. Если такое встречается несколько раз – можно закрыть глаза (например javascript может создать такой элемент, хотя изначально в коде его нет). Но если все стили так прописаны – нехорошо.

Б) Стиль указан в теле страницы. Стили можно указать прямо на html-странице:
Стиль указан в коде страницы
Так делать тоже можно и это ошибкой не считается, но по сути сохраняет все та же недостатки – увеличивает размер страницы, делает его более сложным для чтения.

В) Стили выносятся в отдельный файл. Самый логичный и правильный вариант – когда все стили собираются в специальном файле (с расширением css) и он просто подключается к странице.
Стили подключаются через css файл (правильно)
Настоятельно рекомендую использовать именно такой вариант.

4. Использование JavaScript.

Яваскрипты являются неотъемлемой частью современного сайта. Они делают страницы более динамичными и удобными. Например, плавная прокрутка к нужному месту, или переключение между табами и много чего еще.
Подключать их можно тоже двумя способами: через отдельный файл с расширением js или писать в коде html-страницы:
Варианты подключения Java-скриптов
Как и со стилями, правильный вариант – подключение через отдельный файл.
Зачем скрипты и стили подключать отдельно? Кроме описанных выше причин, отдельные файлы браузер кеширует, а если поместить их в тело страницы, то браузер будет каждый раз обрабатывать их, что замедлит скорость загрузки страницы.
Как видите, ничего сложного в этом нет, если знать, куда и на что смотреть. Некоторые ошибки исправить легко, с другими придется повозиться. Но лучше сразу уделять этому внимание. Сейчас поисковые системы не особо обращают на это внимание, но все идет к тому, что сайт должен быть максимально «идеализирован» для высоких позиций. Кроме того, делать нужно все же по стандартам.

Ну и напоследок, проверьте страницу на валидаторе: . Он выдаст ошибки верстки, если они есть.

Организовать бездокументарный, грязный код?

Я хотел бы задать вам несколько вопросов о грязном коде. Есть некоторые новички, которые закодированы в среднем проекте. Код — очень большой шар грязи. Они не продвинутые программисты. Они просто знают, как использовать клавиатуру немного о java. Они просто написали код с 12 000 строк в своем основном классе, хотя 6 000 строк принадлежат самому NetBeans.

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

Теперь у меня есть следующие вопросы:

  1. Должны ли мы восстановить код и изменить его на ООП? Теперь мы отлаживаем его.
  2. В коде нет комментариев, нет документации, нет конкретного стиля программирования и т. д. Изменение его действительно дорого и требует много времени. Что мы можем с этим сделать?
  3. Как я могу научить их следовать всем правилам (комментирование, ООП, хорошее качество кода и т. д.)?
  4. Код ошибочен и подвержен ошибкам. Что мы можем сделать? Тестирование? Мы почти пишем две или три бумаги формата А4 для коррекции, но это кажется бесконечным.

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

Шаг 0: резервное копирование в SCM

Потому что, как намечено JBRWilkinson в комментариях, контроль версий это ваша первая линия защиты от (необратимой) катастрофы.

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

Шаг 1: сначала проверьте

Затем начните с написания тестов :

  • за то, что работает,
  • и для чего не удается.

Независимо от того, что вы решите сделать, вы охвачены. Теперь вы можете:

  • запустите с нуля и перепишите ,
  • или исправить .

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

Шаг 2. Проверка и мониторинг

Настройте систему Непрерывная интеграция (в дополнение к шагу 0 и шаг 1 ) И Система непрерывного контроля (для подготовки к шаг 4 ).

Шаг 3: Встаньте на плечи гигантов

(как вы всегда должны . )

  • Refactoring to Patterns
  • Refactoring: Improve the Design of Existing Code.
  • Working Effectively with Legacy Code (as recommended by Jason Baker)

Шаг 4: Очистить

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

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

Шаг 5: Обзор

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

Шаг 6: Будущее-доказательство вашего процесса разработки

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *