как писать поддерживаемый код

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

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

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

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

Давайте начнем с несколько выдуманного, но типичного кода. Это может быть класс в любом заданном фреймворке:

Этот код будет работать, но требует некоторых улучшений:

1. Этот код не тестируемый.

2. Данный код не такой поддерживаемый, каким бы мог быть.

Например, если мы изменим источник данных, нам нужно будет изменять код базы данных при каждом использовании App::db в нашем приложении. Кроме того непонятно, как быть в случае, когда мы хотим использовать не просто информацию о текущем пользователе?

Предпринятый модульный тест

Здесь приведена попытка создания модульного теста для функционала, описанного выше:

Для того чтобы этот модульный тест работал, нам нужно сделать следующее:

Что ж, давайте перейдем к тому, как это можно улучшить.

Придерживаемся принципа «Не повторяйся»

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

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

Внедрение зависимости

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

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

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

Давайте посмотрим, как выглядит модульный тест сейчас:

Я добавил кое-что новенькое в этот модульный тест: фиктивную реализацию. Фиктивная реализация позволяет нам имитировать (фальсифицировать) PHP объекты. В данном случае мы осуществляем фиктивную реализацию подключения к базе данных. С нашей « заглушкой » мы можем пропустить тестирование подключения к базе данных и просто проверить нашу модель.

Хотите узнать больше о фиктивной реализации?

Таким образом, решаются несколько проблем:

Но мы все еще можем сделать наш код гораздо лучше. С этого места начинается самое интересное.

Интерфейсы

Для дальнейшего улучшения мы можем определить и реализовать интерфейсы. Рассмотрим следующий код:

Здесь происходит несколько вещей.

Что мы имеем в результате?

А еще мы упростили наш модульный тест!

Но мы все еще можем сделать код лучше!

Контейнеры

Рассмотрим использование нашего текущего кода:

Я переместил создание модели User в одно место в конфигурации приложения. В результате:

Заключительное слово

В нашем уроке мы выполнили следующее:

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

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

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

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

Источники

Затем вы можете установить ваши зависимости, основанные на Composer, со следующими требованиями:

При использовании PHP фреймворка Laravel 4 применение контейнеров и других идей, описанных здесь, носит исключительно важный характер.

Источник

Код, который невозможно поддерживать

Вольный перевод с сокращениями первой части эссе «Unmaintainable Code». Именование переменных — довольно банальная тема (хоть и забавно изложенная), но без этой части эссе было бы неполным.

Пролог

Это самое популярное из моих эссе. Удивительно, сколько людей не понимают, что это насмешка.

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

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

Общие принципы

Quidquid latine dictum sit, altum sonatur.
Что сказано на латыни, звучит внушительно.

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

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

Именование

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

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

1. Однобуквенные имена переменных

Если вы называете свои переменные a, b, c, их будет невозможно искать в простом текстовом редакторе. Кроме того, никто не догадается, для чего они нужны. Если кто-нибудь упомянет о нарушении традиции называть счетчики циклов i, j и k, чтимой со времен FORTRAN, методом замены их на ii, jj и kk, упомяните о том, что испанская инквизиция делала с еретиками. Напротив, используйте имена i, j и k для чего угодно, кроме счетчиков циклов.

2. Креативные опечатки

Если вы вынуждены использовать описательные имена, делайте в них ошибки. Не во всех: ошибка в одном названии из логической пары (например, SetPintleOpening и SetPintalClosing) эффективно нейтрализует использование grep или поисковых средств среды разработки. Добавьте интернационализацию по вкусу: пишите tory или tori в зависимости от локализации.

3. Будьте абстрактны

Используйте абстрактные слова и понятия (it, everything, data, handle, stuff, do, routine, perform), а также цифры: routineX48, PerformDataFunction, DoIt, HandleStuff и do_args_method.

4. А.К.Р.О.Н.И.М. / псть скрщнми грзд интрсн

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

5. Синонимы

Пролистайте словарь в поисках максимально возможного количества синонимов для одного и того же действия (например, display, show, present). Используйте их, чтобы указать на то, что разница есть, когда на самом деле ее нет. Напротив, для именования существенно разных функций используйте одно и то же слово (например, print для обозначения «печать чернилами на бумаге», «запись в файл» и «вывод на экран»).

6. Избегайте написания глоссария проекта

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

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

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

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

Отлично подходят Эсперанто, Клингонский язык и вестрон. В псевдо-эсперанто множественное число образуется добавлением oj. Таким образом вы поддерживаете мир во всем мире.

8. веРхНий реГисТр

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

9. Повторное использование имен

Во всех случаях, допускаемых синтаксисом языка, давайте классам, методам, членам-переменным, параметрам, глобальным и локальным переменным одинаковые имена. Желательно повторно использовать локальные переменные внутри блоков <>. Это делается для того, чтобы сопровождающий внимательно изучил область видимости каждой переменной. В зависимости от языка возможности повторного использования варьируются, но почти всегда можно найти способ вставить в код приятную мелочь: передавая в функцию переменные A и B, в сигнатуре функции менять их местами; использовать одну переменную для разных целей или просто слегка изменять ее назначение.

10. Акцентированные буквы/расширенный ASCII

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

11. Ограничения длины имен компилятора

Если компилятор различает только первые, скажем, 8 букв имени, варьируйте окончания, например, var_unit_update() в одном случае и var_unit_setup() в другом. Компилятор будет трактовать оба названия как var_unit.

12. Подчеркивание — ваш друг

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

13. Вавилонская башня

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

14. Значащие имена переменных

Если уж приходится использовать значащие имена переменных, выбирайте такие, значение которых прочно ассоциируется с чем-то из совершенно другой предметной области. Неплохо работают названия математических символов:
openParen = ( slash + asterix ) / equals;
или имена с сильной эмоциональной окраской:
marypoppins = ( superman + starship ) / god;

15. Скажите соглашениям «нет»

Игнорируйте общепринятые соглашения, регулирующие внешний вид кода, в частности, Sun’s coding conventions и Hungarian notation. К счастью, компилятор на это не отреагирует. Кроме того, можно придумать свои собственные соглашения и обвинять всех остальных в том, что они их не используют.

16. Сходные символы

В большинстве шрифтов есть пары символов, имеющих сходное начертание: l и 1, 0 и O, g и q, m и rn и т.д. Используйте их! Исключите из обихода любые шрифты, в которых эти символы сильно отличаются.

17. Сбивающие с толку имена методов

Убедитесь, что каждый метод делает чуть меньше или чуть больше, чем обещает его название. Например, метод isValid(x) может иметь побочный эффект в виде записи x в базу данных в двоичном виде.

18. Отсылки к шедеврам мировой культуры

Вместо blue назовите константу 0x0204FB LancelotsFavouriteColour. Этот цвет выглядит точно так же, как обычный синий, и сопровождающему придется помучиться, выясняя код цвета. Конечно, только человек, свободно ориентирующийся в Monty Python and the Holy Grail, догадается, что любимый цвет Ланселота — синий. С другой стороны, если сопровождающий не способен даже процитировать фильмы Monty Python по памяти, что он вообще делает в программировании?

19. Цветные развлечения

Само собой разумеется, что вместо имен цветов должны использоваться их числовые значения. К сожалению, большинство сопровождающих уже выучили, что шестнадцатеричные коды легко расшифровываются, поэтому использовать следует десятичные коды. Ни один нормальный человек без калькулятора не расшифрует 132347 как синий цвет. В идеале нужно подбирать цвета, десятичная запись которых является шестнадцатеричной записью каких-то других цветов. Так, например, 808000 на самом деле является 0x0c5440.
Кроме того, можно поиграться с переименовыванием цветов: очень немногие люди знают, как на самом деле выглядят puce, teal и papayawhip, а это оставляет простор для переназначения цветовых констант.

Источник

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

В этом вопросе мне нравится всё!

По теме: чтобы чему-то научиться надо этому чему-то учиться. Курсы, книги, практика, семинары, лекции. Вот сегодня был митап по JS. Обсуждали ФП и прочие половые извращения. Вы на нём были? Нет? А чо?

Можно ли себя называть миддлом, если твой код говно?

Надо. Слушать. Радио Радонеж.
Надо молиться, поститься и — слушать радио Радонеж.
Вот хоть тресни! Хоть весь мир там развались! Я всегда готов молиться, поститься и слушать радио Радонеж!
Биться головой об стену, смиряясь: «Я хуже всех, я хужевсех, яхужевсех, яхужевсех, яхужевсех, яхужевсех, яхужевсех, яхужевсех, яхужевсех, яхужевсех».
Теперь нужно надеть чёрную одежду, взять в руки чётки, ничего не есть, не пить, только ходить в церковь, молиться-поститься, ни с кем не разговаривать, только знать духовника, келью и всё.
И не смей пикнуть. Читай утренние молитвы и не думай ни о чём.
Ой… Но ведь мы ещё так молоды! Ой… Ну всё! Всё грех! Всё нужно отсечь! Только вот — в церковь, молиться, поститься и слушать радио Радонеж!
Туфли на резиновой подошве, длинная чёрная юбка до пят, рюкзачок, платочек, чёточки.
Всё, значит, я не моюсь, отращиваю космы спутанные… Длинные волосы, всклокоченная борода, стоптанные башмаки, а лучше сапоги, а лучше вообще в военную форму одеться и — пугать народ.
Ты — ничтожество, жалкий грешник, урод, всё в тебе, что есть — это зло и грех, тебе приготовлены вечные муки, страшный суд, ад и погибель.
С похмелья посмотрите вокруг. Везде вот чудеса, знамения… Россия перед вторым прОиСшествием, число 666, евреи, масоны…
Я вот ненавижу евреев. Очень обеспокоен засильем масонов. Масоны ведут свою ужасную подрывную работу. Негодяи.
«Мы хорошие, все вокруг плохие». Это уже глубокая психиатрия. Как к этому можно относиться? Лечиться! Нужно посетить хорошего психотерапевта.
Пожалуйста… наместнику не говорите.

Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
For me, this is 95% of software development. Just figuring out *where* things belong.

Фундаментальные знания, вроде вышеупомянутых SOLID/GRASP, паттерны (не только классические паттерны, но и вообще, общеизвестные решения определённых задач), базовые структуры данных. Фреймворки/библиотеки всегда будут приходить/уходить, что-то будет забываться. А фундаментальные знания всегда актуальны.

Может литературу какую почитать посоветуете?

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

Можно ли себя называть миддлом, если твой код говно?

И ответ на главный вопрос.

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

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

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

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

Можно ли себя называть миддлом, если твой код говно?

Для этого сначала нужно как раз-таки погавнокодить.

Можно ли себя называть миддлом, если твой код говно?

Литература, практический любая. Но обязательная эта:
Чистый код, чистая архитектура, Идеальный программист(Роберт Мартин) и совершенный код(Стив Макконел).

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

Любой, пусть даже (вдруг!) изначально «идеально написанный код» по мере развития проекта (хорошо когда бизнес идёт успешно и развивается) может превращаться в говнокод сам по себе, потому что «он обрастает костылями» при добавлении «фич» (нового функционала). Это нормальный и естественный процесс «эволюции кода/системы». Стараться держать в актуальном состоянии юнит/интеграционные/какие_есть тесты, учиться делать рефакторинг как коду, так и тестам— это навыки, которые надо развивать. Можно на личных проектах также, потому что для вас лично они более интересны и ценны по качеству и вы обычно не жёстко лимитированы по времени. Можно «решать задачки», можно участвовать в open source проектах.

«Классические знания/труды» всегда остаются «в силе», про них написали выше, можно для развития ещё читать книги про «искусству создания эволюционирующей архитектуры» ПО. Не для того, чтобы называться сразу «архитектором», а хотя бы просто пробовать заранее планировать разработку, дизайн проекта/модуля/компонента/функции/итд в данном аспекте, оценивать возможные недостатки текущего кода/дизайна/архитектуры. Миддлу это сложно, но в получении новых знаний и навыков нет ничего плохого, если хватает свободного времени (а его всегда крайне мало). Надо понимать, что данная область знаний/профессия продолжает и будет дальше развиваться, новые языки/парадигмы/библиотеки/идеи будут появляться, поэтому самостоятельное развитие (практических) навыков и (теоретических) знаний для практики — залог успеха. Знания без практики и «умесности их применения» в том или другом случае/контексте — тоже могут быть бесполезны и/или вредны. Не надо фанатизма!

Да, иногда сложно «не костылить», да приходится идти с собой на компромисс, да ставить метки todo в коде и заносить в jira задачи «технического долга». Тех долг накапливается и если его не устранять, то рано или поздно проект становится сложно и мучительно поддерживать.

Как разработчик с опытом 18+ в данной профессии — согласен с предыдущими замечаниями. Универсального и единственно работающего рецепта «не говнокодить» нет, приходится развиваться, взрослеть по мере получения практического опыта и знаний.

Источник

Как научиться писать тестируемый и сопровождаемый код — отвечают эксперты

Как научиться писать тестируемый и сопровождаемый код — отвечают эксперты

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

директор департамента информационных решений компании РДТЕХ

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

И ещё небольшой совет: навыки написания «правильного» кода можно очень быстро «прокачать», применяя практику парного программирования (когда один код пишут и сопровождают несколько разработчиков) или поучаствовав в каком-нибудь Open Source проекте.

CTO платформы Opinion

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

Это основная проблема, с которой я сталкиваюсь, работая с начинающими программистами. Например, часто бывает так, что метод API делает всё сразу — обращается к БД, обрабатывает результаты и отгружает их дальше. Чтобы написать тест к такой функции, надо иметь копию всей экосистемы приложения исключительно для тестирования. Порой это просто невозможно. Намного лучше будет разбить такую функцию на мелкие «возьми», «распредели» и «отправь». Тогда «возьми» и «отправь» не надо unit-тестировать, потому что они не выполняют никакой логики, а «распредели» будет легко тестироваться, так как она не обращается к внешним ресурсам, и ей можно передать любые тестовые данные. Это называется «чистая функция».

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

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

Исполнительный директор «Протекшен Технолоджи»

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

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

С «тестируемым кодом» всё сложнее, так как подходы к тестированию кода могут быть весьма разнообразными. Тем не менее, когда говорят о «тестируемом коде» обычно речь идёт о написании тестов для отдельных сущностей (методов, классов, модулей) программистом, возможно, не участвующим в самой разработке. Для того, чтобы он смог написать эти тесты, тестируемая сущность должна быть ему понятна и подвластна, т. е. не должна выполнять операций неявных и таких, на которые нельзя повлиять из тестов. Отсюда возникают рекомендации по написанию тестируемого кода: следить за соответствием имён сущностей их функциональности, обеспечить возможность вставить в качестве каждой сущности заглушку, не делать неявной инициализации и т. п.

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

руководитель центра разработки департамента CRM в Navicon

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

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

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

старший инженер-программист НПК «Криптонит»

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

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

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

QA в kt.team

По вёрстке — однотипная функциональность реализовывается однотипным HTML-деревом с применением читаемых атрибутов. Возьмём для примера кнопочки на сайте.

Самые главные требования:

разработчик в компании «ФармХаб»

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

Как этому научиться? Первое, чем стоит озаботиться, — чтение соответствующей литературы. Сейчас доступно огромное количество информации, посвящённой этому вопросу: книги (например «Чистый Код» Роберта Мартина) и статьи, дающие пояснения и выжимки из этих книг. Из этих источников можно получить начальные знания, необходимые каждому разработчику. Они достаточно просты в освоении и хорошо написаны.

Следующий шаг — изучение правил стилистики языка, на котором пишет разработчик. Для каждого языка есть общие правила, которые закладываются его создателями, а крупные фирмы, такие как Google, Yandex, Airbnb, имеют свой свод правил касательно того или иного языка программирования. Полезно изучить какой-либо из предлагаемых наборов правил и придерживаться его. Во-первых, это тренирует дисциплину, во-вторых, вероятность, что придётся работать с кем-то, кто знает и использует такой же свод правил выше, чем что-то придуманное самим. И третий шаг — это подробное изучение стиля, используемого в команде, в которой работает разработчик. Скорее всего, в команде разработки, в которую он придет, уже будет сложившаяся стилистика написания кода. Чтобы не возникало конфликтов и другим коллегам было легко и удобно разбираться в коде, лучше следовать устоявшимся правилам. Если они описаны в документации — это отлично, если документации нет — можно проанализировать код написанный другими сотрудниками и делать так же.

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

Теперь перейдём к тестируемости кода. Для чего нужно тестирование и как писать тесты также описано во множестве книг и статей, углубляться в это не имеет смысла. Тестируемый код — это такой код, в котором мы можем убедиться, что любая написанная нами строчка делает именно то, что мы задумали. Для достижения этого нужно следующее:

Источник