Вредные советы

Вступление

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

Вредный совет первый

Откажитесь от фильтрации и проверки данных на стороне сервера и клиента. Фильтрация данных приведет к появлению лишнего кода, что увеличит возможность ошибки и приведёт к удорожанию разработки. Некорректная фильтрация данных возникает в том случае, когда данные, получаемые веб-приложением от пользователей, недостаточно экранируются или недостаточно фильтруются перед непосредственным выполнением в коде. Подобные ошибки приводят к возникновению уязвимостей SQLi, RCE, XXE, XSS, и тд. Рассмотрим подробнее на примере SQL injection (далее SQLi). Допустим, есть числовой параметр id, с помощью которого веб-приложение запрашивает соответствующую запись в БД. Если код, отвечающий за этот функционал, выглядит примерно так:

$id = $_GET['id']$query = "SELECT * FROM some_table_name WHERE id=$id"

то запрос к БД будет выглядеть так:

SELECT * FROM some_table_name WHERE id=1

Если не производить фильтрацию данных или экранирование символов, которые принимаются в качестве аргумента, то при поиске уязвимости будет подставляться спецсимвол ', а в БД будет отправляться запрос типа:

SELECT * FROM some_table_name WHERE id=1'

который нарушит синтаксис запроса, и в ответе от веб-приложения атакующий получит ошибку от базы данных, которая будет маркером возможности проведения SQLi. Дальнейшая эксплуатация уязвимости приведет к полной компрометации базы данных, где может храниться не только информация о логинах и паролях пользователей, но и другая конфиденциальная информация, например, реквизиты кредитных карт или персональные данные. Однако стоит отметить, на основе информации от багтрекер-площадки HackerOne, что в период за 2019-2020 год наблюдается тенденция к снижению количества случаев эксплуатации популярной уязвимости SQLi. Это подтверждается и статистикой компании Acunetix , которая предоставила отчет веб-уязвимостей за 2019-2020 год, где SQLi были обнаружены у 8% сайтов, так что скоро можно будет спать спокойно.

Вредный совет второй

Например при работе с пользователем ваше приложение создает экземпляр класса, почему бы не хранить его на стороне пользователя, это же удобно?! При этом дополнительными настройками безопасности можно не заморачиваться, мы же доверяем нашим пользователям. Пример использования десериализации. В данном примере есть класс Injection, в котором реализован магический метод __wakeup(). Данный метод выполняется во время десереализации объекта и выполняет код, который хранится в переменной $some_data.

<?phpclass Injection {        public $some_data;        function __wakeup(){                if( isset( $this->some_data ) ){                        eval( $this->some_data );                }        }}if( isset( $_REQUEST['data'] ) ){        $result = unserialize( $_REQUEST['data'] );        // ...}?><?phpclass Injection {        public $some_data;        function __wakeup(){                if( isset( $this->some_data ) ){                        eval( $this->some_data );                }        }}$inj = new Injection();$inj->some_data = "phpinfo();";echo( serialize( $inj ) );?>

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

O:9:"Injection":1:{s:9:"some_data";s:10:"phpinfo();";}

Передав пейлоад в уязвимое веб-приложение выполнится, в нашем случае, функция phpinfo().

Вредный совет третий

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

$LINK = new mysqli($DB_HOST, $DB_USER, $DB_PASS, $DB_NAME);    $user_name = $_GET['login'];    $user_password = $_GET['password'];    $query = $LINK->prepare("select id from user where login = '$user_name' and user_password='$user_password'");    $query->execute();

Вредный совет четвертый

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

можно этот пароль усложнить спецсимволом, например вот так: $123456789 или так 123456789#. Самый надежный пароль - это длинный пароль, и этого вполне достаточно для надежной аутентификации.

Согласно официальной статистике компании NordPass, специализирующейся на разработке менеджера паролей, по-прежнему лидирует пароль 123456, на втором месте 123456789, стоит отметить, что придуманного выше пароля в статистике нет (а там более 200 паролей), значит злоумышленник хапнет горя от перебора.

Внедрение двухфакторной аутентификации имеет смысл если социальные сети и крупнейшие интернет-порталы, поэтому можно обойтись капчей и сложным универсальным паролем.

Бонус. Хотя это не связанно с парольной политикой, но все же, вспомните как часто при авторизации на сайтах, вы вводили не верные данные, а понять, где ошибка в логине или в пароле сразу сложно и приходится заполнять обе формы по новой. Раздражает, правда?!

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

Вредный совет пятый

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

• включены и используются учетные записи по умолчанию. Тут все просто, если заметите это раньше злоумышленника - лучше сразу отключить;

• включено индексирование директорий веб-приложения, позволяющее просматривать их содержимое.

Такой пример конфигурации ngnix:

http {               autoindex on;               include etc/nginx/mime.types;               default_type   application/octet-stream;

приведет к такой проблеме:

• включено отображение ошибок веб-приложения для пользователя. Это не так страшно звучит, можно подзабить;

Что делать с обновлением ПО на сервере? Практически в 90% случаев при правильной первой установке компонентов сервера, мы имеем актуальные версии пакетов. Мы рекомендуем после того как сервер будет запущен и ваше приложение уже работает, сделать резервную копию, отключить обновление и забыть навсегда о них. Многие сервера Linux работают десятилетиями без обновлений и перезагрузок. Сам же процесс обновление ПО на сервере особенно под управлением Unix подобных систем, рисковое дело - можно все сломать, а уязвимости одни латают, другие появляются - тут тоже можно пренебречь. Админы сами говорят работает не - трогай!.

Если есть необходимость временно запустить на сервере дополнительный сервис и открыть его в мир - используйте порты выше 1024. Эти порты не так популярны для сканирования у мамкиных хакеров.

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

Заключение

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

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

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

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

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

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

1. Все-все делай в одиночку

Хорошего дизайнера отличает то, что он никого не отвлекает и может выполнить все самостоятельно. Он знает все технические аспекты проекта, бизнес-логику заказчика, все паттерны проектирования. Сам напишет все тексты, нарисует все иконки. Исследования в одиночку будут, конечно же, объективными. Не важно, насколько профессионально все будет выполнено или сколько лишних часов будет потрачено, главное, что сам!

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

2. Помни, что на работе тебя всему научат

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

P.S. Очень часто новички ищут компанию, в которой их будут обучать, но это не так часто случается, поэтому даже после того, как тебе дали проект, следует учиться дальше. Хорошо, если тебе повезло, и есть дизайнер, с которым можно посоветоваться. Но если такого нет, то обучаться придется на своих ошибках, и в этом нет ничего плохого. Признавай их и исправляй. Дополнительное образование тоже идет в зачет в мире дизайна и ИТ постоянно что-то меняется.

3. Будь перфекционистом

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

P.S. Если всегда так работать, то можно много времени потратить просто на то, чтобы доводить макеты до идеального состояния. Не говоря о уже том, что такой темп работы ведет к выгоранию. Используй, например, размеры кратные 8 пикселям и просто предупреди об этом разработку. Закладывай время на возможные правки, ошибки, коммуникацию с разработчиками. Очень сложно всегда все учесть, иногда важнее показать идею команде или заказчику быстро, чтобы получить фидбек в правильном ли направлении ты движешься!

4. Правки это плохо

Если кто-то делает замечание по поводу твоих макетов воспринимай это как личное оскорбление, ведь дизайнер тут ты! Ты всегда знаешь, как лучше. Заказчик ведь совсем не разбирается в дизайне. Почему все лезут в твою работу? Ведь потом придется на собеседованиях объяснять, что заказчик настаивал на этом глупом решении.

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

5. Изобретай велосипед, придумывай новые паттерны

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

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

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

6. Используй конференции по дизайну для обучения

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

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

7. Прокачивай только хард скиллы

Как и в совете выше, не стоит распыляться на что-то, кроме изучения дизайна и инструментов. Если ты отлично проектируешь интерфейс, знаешь наизусть гайдлайны Android и iOS все двери тебе открыты. Дизайнеру не обязательно уметь искать общий язык с разработчиками и заказчиками. Дизайнер всегда знает, как должно быть красиво.

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

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

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

Правило первое будьте рациональны

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

Эксперимент!

Не верите? Попробуйте! Замените у вашего программиста стол, поставьте ему табуретку вместо стула, а стены покрасьте в другой цвет! Когда он придет в офис, по-прежнему что-то бормоча себе под нос, он просто уставится в монитор и начнет тихонько ругаться. Если прислушаться, то можно услышать что-то вроде ну кто так пишет и почему оно не компилируется, но ни слова про рабочее место!

Правило второе не отнимайте еду

А теперь попытайтесь вспомнить, смотрели ли вы когда-нибудь разработчику в глаза? Я да. И, скажу я вам, взгляд у них грустный-грустный. Я заметил, что чуточка радости во взгляде программиста появляется лишь когда он видит еду. Однажды я стал свидетелем курьезной ситуации когда программист сидел и кушал на кухне, в помещение вошла красивая девушка из отдела HR. Все остальные мужчины, которые находились на кухне, дружелюбно заулыбались и предложили ей часть своей еды, а программист отвернулся и зарычал! Так что можно добиться доверия разработчика, осторожно подкармливая его. По моим личным наблюдениям, больше всего они любят кофе и печеньки.

Правило третье дарите радость

Но что заставляет взгляд программиста действительно проясниться и загореться - так это новые железки! Но не всякие. Если вы подарите разработчику светящуюся мышь или клавиатуру, он это проигнорирует. Это геймеры любят всякие лампочки, а программисты света побаиваются. По этой причине они так любят темные темы в своих IDE. А вот если вы подарите новый процессор или оперативки побольше, то радости не будет предела! Благодарный программист будет защищать вас от других программистов, а также сможет починить вам утюг.

И я не шучу!

Однажды я стал свидетелем того, как разработчику подарили второй монитор и 32 ГБ оперативной памяти! И знаете, что он сделал? Он запустил сразу все свои программы, а на второй монитор вывел график загруженности памяти и весь день туда смотрел! Позже в этот же день я видел, как он предлагает свою еду той девочке из HR.

Правило четвертое будьте авторитетом

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

Но не ругайте его, не подняв свой авторитет, иначе он может укусить!

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

Правило пятое контролируйте

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

Лучше всего ставить задачу устно. Это уместно по той простой причине, что заставит программиста держать ваше указание в голове и постоянно о нем думать. Если задачу куда-то записать, то это быстро забудется, а листок потеряется. Как только задача поставлена, стоит спросить, в каком она состоянии и когда будет готова. Даже если вы ее поставили только что. Помните - программисты чрезвычайно сообразительны и могут решить вашу задачу моментально в уме.

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

Правило шестое будьте справедливы

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

Делается это следующим образом.

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

А затем, когда наступит квартальное ревью, напомните им об этих оценках. Это будет поводом урезать зарплату одним и увеличить ее другим. Это справедливо.

А еще себя очень хорошо зарекомендовала одна практика.

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

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

Правило седьмое не переплачивайте

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

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

Правило восьмое и последнее уважайте своих программистов!

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

Давайте жить дружно!

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

Первая встреча с джуниором

Итак, настал момент вашей первой встречи в рабочих условиях. Джуниор вышел на работу и должен приступить к должностным обязанностям. Ваша задача в этот день играть с джуниором в прятки, ведь они это так любят! Вам не стоит водить его за ручку, показывать офис и его рабочее место. Вы ни в коем случае не должны сразу же брать джуниора под свою опеку, будто нянька. Он сам должен приложить усилия и найти вас, таким образом он проявит свой навык problem solving. Кстати, в идеальном случае рабочее место не должно быть готово, чтобы джуниору пришлось немного посидеть на ресепшене и решать задачи без компьютера.

Создание учетных записей

Разумеется, учетные записи не должны быть готовы. В идеале админ Аркадий должен выпучить на вас глаза и спросить: Какой еще новый сотрудник? Мне никто ничего не говорил. Администраторам в принципе все нужно говорить в последний момент, чтобы не расслаблялись. Не лишним будет потянуть с созданием учеток пару недель и проверить, начнет ли джуниор сам спрашивать о них. Тем самым вы проверите его настойчивость и способность goals achievement.

Знакомство с командой

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

Введение в детали проекта

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

Начало работы и эстимейты

Итак, ваш молодой боец приступил к выполнению своей первой задачи. Хорошо бы ее поставить устно, но подойдет и тикет в Jira. Первое, что вы должны спросить, так это estimate. Джуниоров особенно полезно приучать к временным оценкам задач. Далее я даю вам подробную инструкцию как вести себя при оценивании:

1. Джуниор называет вам какое-то число. Допустим, восемь.

2. Вам нужно скривить рот, глубоко вздохнуть и спросить: Что восемь?

3. Слегка смутившись, джуниор вам ответит: Ну восемь часов

4. Вам следует заметить, что надо было сразу так и сказать. А то что это за магическое число такое, восемь.

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

6. Не обращая внимания на бледное лицо джуниора, уходите без каких-либо объяснений.

Такой подход настроит джуниора на рабочий лад и придаст ему настроения.

Код-ревью и разбор ошибок

Не нужно. Вы работаете в команде сильных специалистов, чей код не нуждается в ревью. Пусть джуниор к этому привыкает. Однако, скорее всего он напишет какую-нибудь чушь в своем первом коммите. Ваша задача здесь подключиться к его бранчу, молча все переписать по уму, закоммитить и смерджить в основную ветку. Главное, не ставить его в известность он должен сам все это заметить. То, как вы переписали его задачу, должно его впечатлить. Однако, он вовсе не должен понимать, как работает ваш код и чем он лучше его изначального решения. Вы авторитет, поэтому всегда переписывайте код, написанный джуниором. Если он вас однажды попросит что-то объяснить, просто ответьте: Потому никто так не пишет, Сережа. Ты еще орленок.

Менторинг

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

Поддержка

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

Учите хорошим практикам

Наверняка кто-то из вас заметил фразу зачем тебе юнит-тесты? в предыдущем пункте. Сразу дайте джуниору понять, что юнит-тесты это зло. Когда разработчик пишет юнит-тесты, он заявляет всему миру, что он в себе не уверен. Он буквально кричит: Ребята, мой код не работает!. Вы хотите работать с такими профессионалами? Вот и я тоже. Помимо юнит-тестов, у вас не должно быть всяких новомодных CI и CD, интеграционных и, прости Господи, e2e тестов. Но все это тема для отдельной статьи.

Про мотивацию

Мотивация быть должна! Но, разумеется, не материальная. Если вы поднимете джуниору зарплату, он просто расслабится и начнет писать код еще хуже, чем в самом начале. Мотивировать нужно поступками, фразами и испытаниями. Очень полезно при всех его коллегах воскликнуть: Б***ь, Сережа, ну что это за *****? Маша из бухгалтерии решит эту задачу лучше. Это разозлит джуниора, но злость эта будет положительной и правильной. Я бы даже сказал, праведной! Впредь ему захочется писать как можно лучше, чтобы даже Света из той же бухгалтерии не смогла сделать круче.

Если джуниор слишком любопытен

У джуниоров часто есть период почему. В это время они заваливают вас вопросами, но каждый из них начинается именно со слова почему. Почему класс так называется, почему метод приватный, почему база данных не монго, почему нельзя домой, почему сервис не запускается. Грамотный джуниор сам разберется во всех этих вопросах (либо найдет другую жертву). Вы можете чисто для приличия ответить на один из вопросов по вашему усмотрению, но не балуйте вашего подопечного. Пусть он проявит свой навык learnability!

Заключение

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

Да, вы не ослышались именно так! В IT-сообществе прочно укоренилось мнение, что все эти тесты вам хоть как-то помогают, но так ли это на самом деле? Вы сами пробовали мыслить критически и анализировать это расхожее мнение? Хипстеры придумывают кучу парадигм TDD, BDD, ПДД, ГИБДД лишь чтобы создать иллюзию бурной деятельности и хоть как-то оправдать свою зарплату. Но задумайтесь, что будет, если вы (либо ваши программисты) начнете все свое время уделять исключительно написанию кода? Для тестирования есть отдельное направление и целые подразделения. Вы же не заставляете программистов писать требования, так? Тогда почему они должны писать тесты? Всех согласных и несогласных прошу проследовать внутрь поста, где я вам наглядно покажу, что юнит (и интеграционные) тесты великое зло!

Откуда вообще пошло тестирование

В стародавние времена никакого тестирования не было в принципе. Не было даже такого направления, что уж и говорить про такие термины, как блочное (модульное) и интеграционное тестирование. А про всякие e2e и, прости господи, пайплайны, я вообще молчу. И все это потому, что тестировать, собственно, было еще нечего. В те годы инженеры-программисты только пытались создать первые ЭВМ.

Как нам всем известно, первые ЭВМ были гигантских размеров, весили десятки тонн и стоили дороже этих ваших Apple MacBook Pro Retina 4k 512mb RAM 1Tb SSD Touch Bar USB Type-C. И в те времена разработчики действительно боялись, что во время работы что-нибудь пойдет не так. Думаю, вам известна история возникновения термина баг (bug) если вдруг нет, то почитайте, это очень интересно. И, так как программисты боялись всего на свете, они и придумали модульное тестирование.

Времена менялись, менялись и ЭВМ. Тестирование тоже менялось. Помимо блочных тестов, возникло также и целое направление, которое впоследствии получило название Quality Assurance.

Но разработчики тоже менялись. В наше время становится смешно от мысли, что кто-то боится запустить программу, потому что от этого может загореться сервер. В 2020 году программисты не боятся запускать свои программы. А если нет страха зачем тестировать?

Современные реалии

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

На последнем хочу слегка заострить внимание. В современной разработке основная стоимость кроется не в аппаратном, а в программном обеспечении. И ошибки по-прежнему стоят дорого. Но ответственность за эти ошибки плавно перекочевала с плеч разработчиков на плечи тестировщиков. Как-никак, это они назвали себя Quality Assurance а раз проводишь проверку качества, делай это качественно \_()_/

В конце концов, отдел разработки называется Software Development, а не Unmistakable Development. Мы никому ничего не обещаем.

Хороший программист уверен в себе

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

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

Задание: Прямо сейчас скажите себе Я уверен в качестве своего кода и удалите все юнит-тесты из проекта.

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

Запомните несколько простых постулатов:

1. Хороший программист не пишет тесты, так как не сомневается в качестве своей работы.

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

3. Тщетные попытки найти ошибки в вашем коде оставьте тестировщикам.

Тесты отнимают время

Время программистов дорогое. Время тестировщиков дешевое. Какой тогда смысл заставлять программистов писать тесты? Это невыгодно даже с финансовой точки зрения.

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

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

Поэтому не будьте машиной. Не провоцируйте тестировщиков на поднятие бунта.

Парадигмы запутывают

Unit-testing, Integration Testing, End 2 End, Pipelines, CI, CD что вы еще придумаете, лишь бы не работать? Есть мнение, что когда программист выгорает и начинает прокрастинировать, он идет настраивать пайплайн.

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

Если кому-то надо настроить CI или CD пускай настраивают сами. Пусть это сделает devops, в конце концов. Если вас будут просить как-либо помочь в настройке, смело отказывайтесь и ссылайтесь на свою занятость наиважнейшими и перво-приоритетными задачами, а именно написанием кода.

Вам не нужно знать ничего лишнего. Иными словами, вы программируете. Тестировщики тестируют. Девопсы ковыряются во всяких скриптах на bash. Менеджеры ну, менеджеры есть менеджеры.

Delivery In Time

Я предлагаю ввести лишь одно простое понятие: DIT Delivery In Time. Это схоже с известной парадигмой ППКБ (Просто Пиши Код Б****), но звучит гораздо современнее и толерантнее. Парадигма ППКБ ставит программистов в центр мироздания и не считается с работой других членов команды. Это, как минимум, неуважительно. В DIT мы верим, что программисты скромные служители, единственной целью которых является написание кода. При всем этом, мы не закрываем глаза на работу других коллег и уважаем их труды. Просто мы считаем, что каждый должен быть занят своим делом: программисты программировать, тестировщики тестировать, и тд. Когда каждый будет делать то, чему обучен, сроки перестанут срываться.

Парадигма DIT предлагает сплошные бонусы заказчикам. Они могут нанять исключительно разработчиков, чтобы те ППКБ (просто писали код), и все их бюджеты будут направлены непосредственно на создание продукта. При желании заказчик может также нанять и тестировщиков. То есть, простите, Quality Assurance инженеров. А может и не нанимать и запустить тестирование в продакшене.

Я однажды слышал один забавный диалог:

Сколько человек сейчас тестирует нашу систему?
Один человек.
Мы только что выкатили ее на прод.
Ну значит, нашу систему тестирует 1000 человек.

И это правильно. Можете платить штатным тестировщикам, а можете нанять тысячи внештатных совершенно бесплатно.

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

Совет: Чтобы не срывать сроки и доставлять вовремя лучше нанять разработчиков, а тестированием заниматься на продакшене. Даже если что-то пойдет не так, вы всегда можете возразить, что соблюли сроки, как и было обговорено. А о большем и не договаривались.

Про интеграционное тестирование

С модульным тестированием вроде разобрались, настало время поговорить о тестировании интеграционном. Именно оно отнимает больше всего времени.

Когда-то я был молодым и верил в то, что тесты (юнит, интеграционные, да всякие) несут добро. Хорошо написанные тесты гарантировали отсутствие регрессии, то есть вы могли изменять и рефакторить код без боязни, что вы где-то ошиблись. Выглядит здорово, правда? Делаешь кучу правок, запускаешь тесты и смотришь, допустил ли ты ошибку.

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

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

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

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

Просто будьте собой

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

Просто будьте собой!