Кофе-брейк #76. Советы по отладке программ: действуй, как детектив. 5 полезных приемов написания чистого кода

Советы по отладке программ: действуй, как детектив

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

1. Воспользуйтесь линтером

Выполните линтинг. Подсвечиваются ли какие-нибудь синтаксические ошибки? Не ссылается ли ваш код на неопределенную переменную? Куда чаще, чем мне хотелось бы, мой код не компилировался (локально) из-за красной буквы «f», которую я каким-то образом добавила к случайной строке. Этот неуместный символ часто убирается при линтинге. Но если приложение успешно скомпилировано, а мне хочется просмотреть изменения самостоятельно, я пользуюсь Git Lens. Этот инструмент помогает выявить, не выделяется ли что-нибудь в коде, как несоответствующее. Не пугайтесь, если в вашем терминале, консоли браузера или веб-странице выскакивают какие-нибудь другие ошибки. Они могут помочь вам разобраться, что именно происходит не так. Если вы пока только привыкаете к сообщениям об ошибках, ознакомьтесь с советами Ники Мейлеман о том, как научиться их понимать.

2. Изменяйте только одну вещь за раз

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

3. Проверьте все свои предположения

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

4. Применяйте тесты для подтверждения своих предположений и проверки потенциальных решений

Подходите к разработке через тестирование с помощью метода “красный-зеленый-рефакторинг”. Это предполагает, что для начала вы пишете тест, включающий желаемый функционал, и ваш код его не проходит (потому что кода еще нет). Далее вы пишете код, который должен пройти этот тест (результат меняется с красного на зеленый). После этого, когда у вас уже есть рабочий код, можно заняться рефакторингом, не беспокоясь о том, что случайно нарушите функциональность кода. При использовании этого метода исключается ситуация, когда вы создаете слишком большую часть функционала без тестирования на работоспособность. В Git также есть команда git bisect, которую можно использовать для быстрого поиска проблемного коммита. С ее помощью можно быстро найти проблему путем проверки конкретных коммитов из истории git. Затем, в зависимости от того, идентифицирована ли эта проблема до или после введения регрессии программного обеспечения, следующая фиксация произойдет либо раньше, либо позже в истории git, пока не будет выявлен виновник. Git bisect можно комбинировать с автоматическим тестированием, чтобы сделать процесс выявления проблемной фиксации еще более эффективным.

5. Изучите ваш код построчно

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

6. Посмотрите исходный код стороннего пакета

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

7. Google — ваш лучший друг

Быстрый поиск может стать лучшим другом разработчика. Если вы используете новую функцию или пакет, попытайтесь найти пример, где они уже работают. Если вы хотите увидеть код, использующий те же API в контексте, рекомендую поискать в вашем локальном репозитории. Или можете поискать репозитории с открытым кодом при помощи grep.app.

8. Звонок другу

Советую интегрировать git blame в вашу среду разработки. Я использую плагин Git lens, который показывает, кто является автором определенных изменений файлов, прямо в этих файлах в редакторе кода. Также этот плагин показывает связанный pull request, что может быть полезно для быстрого получения большего контекста относительно решений (вы можете просмотреть этот pull request или напрямую обратиться к его автору). Эффективным способом отладки и обмена знаниями может быть парное программирование. Я уже упомянула о “волшебном” нахождении решений после сна или перерыва. Есть еще один полезный прием: “утиный дебаггинг”. Суть его в том, что простое объяснение проблемы кому-то другому (даже неодушевленной резиновой уточке) может помочь сделать решение более очевидным. Разобравшись с ошибкой, не забудьте задокументировать полученные знания. Даже если это будет всего лишь небольшая заметка для себя на будущее.

5 полезных приемов написания чистого кода

Источник: Dev.to Кто угодно может научиться писать код. Но можете ли вы писать его чисто? В этой статье я покажу вам свои методы написания чистого кода.

1. Используйте цветовую палитру

Используя цветовую палитру, вы не только напишете более чистый код, но и сможете изменить всю тему своего приложения, изменив только 6 символов кода (ссылаясь на шестнадцатеричный код). Давайте посмотрим на цветовую палитру, которую я использовал в своем проекте React Native.

// creating and exporting the color palette
export default {
  black: "#000",
  darkBlue: "#090446",
  darkGreen: "#002E27",
  green: "#00B14F",
  light: "#ede6e6",
  medium: "#6e6969",
  pink: "#fc5c65",
  purple: "#4530B3",
  white: "#FFFFFF",
};

// using the palette (default import as colors)
const styles = StyleSheet.create({
  foodName: {
    color: colors.white,
    fontSize: 22,
    fontWeight: "bold",
    margin: 5,
  },
  foodPrice: {
    color: colors.green,
    fontSize: 16,
    margin: 5,
  },
});

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

2. Сортируйте параметры и ключи по алфавиту

Это просто вопрос чистоты. Вот пара примеров:

function doSomething(anArgument, anotherArgument, bIsAfterA, cIsAfterB, moreArgument, zIsTheLastAlphabet) {
   // do something...
}

container: {
  backgroundColor: colors.darkGreen,
  borderRadius: 10,
  justifyContent: "space-around",
  margin: 10,
  padding: 10,
  width: 180,
  height: 180,
},

Делайте имена выразительными, даже если они при этом будут длинными

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

const handlePress = () => {
  // do something...
}

const handlePress2 = () => {
  // do something...
}

const handlePress3 = () => {
  // do something...
}

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

const handlePressAddButton = () => {
  // do something...
}

const handlePressCrossButton = () => {
  // do something...
}

const handlePressCircularView = () => {
  // do something...
}

4. Создавайте расширяемую структуру директорий даже для маленьких проектов

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

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

Вот пример многоразового компонента в React:

function Text({ children, style, ...otherProps }) {
  return (
    <h1 style={[styles.myCustomStyle, style]} {...otherProps}>
      {children}
    </h1>
  );
}

Здесь мы имеем полностью готовый тег h1 с дефолтными стилями. Все, что вам нужно, это использовать его в своем приложении. А благодаря последнему параметру REST у компонента Text могут быть дополнительные свойства, а могут и не быть — по вашему желанию. Но это еще не все. Стиль этого компонента написан так, чтобы быть самодостаточным, но его также можно расширять или перезаписывать (параметр style).