Кава-брейк #76. Поради щодо налагодження програм: дій як детектив. 5 корисних прийомів написання чистого коду

Поради щодо налагодження програм: дій як детектив

Джерело: About Monica Щоб ефективно налагоджувати програмне забезпечення, розробнику потрібно мати навички детектива. У міру свого професійного розвитку я не лише розширила свої знання про різні способи несподіваного виходу програм з ладу, а й відточила налагодження. У цій статті я розповім про різні підходи до розуміння того, чому комп'ютер, як здається, не робить те, що ви йому кажете.

1. Скористайтеся лінтером

Виконайте лінтинг. Чи підсвічуються якісь синтаксичні помилки? Чи не посилається ваш код на невизначену змінну? Куди частіше, ніж мені хотілося б, мій код не компілювався (локально) через червону букву «f», яку я якимось чином додала до випадкового рядка. Цей недоречний символ часто забирається під час лінтингу. Але якщо програма успішно скомпільована, а мені хочеться переглянути зміни самостійно, я користуюся Git Lens . Цей інструмент допомагає виявити, чи не виділяється щось у коді, як невідповідне. Не лякайтеся, якщо у вашому терміналі, консолі браузера або веб-сторінці висякують інші помилки. Вони можуть допомогти вам розібратися, що відбувається не так. Якщо ви поки що звикаєте до повідомлень про помилки, ознайомтеся зпорадами Нікі Мейлеман про те, як навчитися їх розуміти.

2. Змінюйте лише одну річ за раз

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

3. Перевірте всі свої припущення

Послідовно відтворюйте проблему вручну або за допомогою тестів. За яких умов система виходить з ладу? Щоб краще зрозуміти основну проблему, ви повинні визначити, в яких умовах програма поводиться несподівано. Для визначення коли саме код перестає працювати належним чином, використовуйте логи, брейкпоінти, тести, перевірки мережевих викликів і так далі. Якщо ви зрозумієте, коли трапляється помилка, це наблизить вас до розуміння того, чому вона відбувається. Чи повертає ваш API очікувані дані? Чи прив'язана проблема до середовища виконання? Чи немає пропущених змінних оточення?

4. Застосовуйте тести для підтвердження своїх припущень та перевірки потенційних рішень

Підходьте до розробки через тестування за допомогою методу "червоний-зелений-рефакторинг". Це передбачає, що для початку ви пишете тест, що включає бажаний функціонал, і ваш код його не проходить (бо коду ще немає). Далі ви пишете код, який має пройти цей тест (результат змінюється із червоного на зелений). Після цього, коли у вас є робочий код, можна зайнятися рефакторингом, не турбуючись про те, що випадково порушите функціональність коду. При використанні цього методу виключається ситуація, коли ви створюєте надто велику частину функціоналу без тестування на працездатність. Git також має команду git bisect, яку можна використовувати для швидкого пошуку проблемного комміту. З її допомогою можна швидко знайти проблему шляхом перевірки конкретних комітів з історії git. Потім, залежно від того, чи ідентифікована ця проблема до або після введення регресії програмного забезпечення, наступна фіксація відбудеться або раніше, або пізніше в історії git, доки не буде виявлено винуватця. Git bisect можна комбінувати з автоматичним тестуванням, щоб зробити процес виявлення проблемної фіксації ще ефективнішим.

5. Вивчіть ваш код рядково

Спробуйте прочитати код свіжим поглядом, навіть якщо для цього буде потрібна перерва в роботі. Буває, що наступного дня все стає набагато зрозумілішим. Вам не обов'язково постійно дивитися на екран монітора, щоб ваш мозок продовжував шукати рішення.

6. Перегляньте вихідний код стороннього пакета

Перевірте, чи немає там відкритих іссу. Можливо, хтось інший теж зіткнувся із аналогічною проблемою. Якщо помилка може бути пов'язана зі стороннім програмним забезпеченням, перегляньте його вихідний код.

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).