15 ознак того, що розробник має поганий код і поради щодо написання чистого коду

15 ознак того, що розробник має поганий код і поради щодо написання чистого коду

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

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

Занадто загальне

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

Професійна порада

Найкращий спосіб виправити це за допомогою отримати точнішу інформацію про те, що ви намагаєтеся зробити з кодом.

Наприклад, якщо у вас є функція, яка виконує щось дуже загальне, наприклад, друкує «Hello World!», можливо, настав час розбити її на менші функції, кожна з яких виконує певне завдання.

Якщо функція роздруковується Привіт Світ!можливо, має бути одна під назвою “Роздрукуйте Hello World!”. Це гарантує, що ваш код можна буде легко використовувати повторно, а інші знатимуть, що вони отримують, перш ніж використовувати його.

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

Дублюється всюди

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

Професійна порада

По можливості слід уникати дублювання коду.

Шукайте повторювані блоки тексту та подумайте про рефакторинг коду, щоб він міг використовувати функції, цикли чи інші конструкції для запобігання дублюванню.

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

Без тестування

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

Професійна порада

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

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

Використання довгих методів і функцій

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

Професійна порада

Завжди краще розбити проблему на більш дрібні частини й працювати лише над одним аспектом одночасно. Якщо ви неодноразово повертаєтеся до частини коду, можливо, вам слід зробити її окремою функцією.

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

Хорошим емпіричним правилом для методів є те, що якщо він займає більше 20 рядків (за винятком коментарів), його слід рефакторингувати у свій клас із певною функціональністю.

Залежності неправильні або відсутні

Залежності це пакети або бібліотеки, на які покладається ваш код. Якщо вам не вистачає залежності або її потрібно налаштувати, ваш код працюватиме не так, як очікувалося.

Помилка буде приблизно така Модуль не знайдено в module_name. Ось деякі загальні ознаки проблем із залежністю

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

помилки

Однією з найпоширеніших ознак того, що ви пишете шкідливий код, є наявність помилок.

У програмній інженерії a помилка це помилка або збій у комп’ютерній програмі, яка спричиняє невірний або неочікуваний результат.

Професійна порада

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

Крім того, важливо відійти від проблеми, намагаючись виправити ці помилки. Наприклад: якщо ви помітили, що кінцевий результат вашої програми не відповідає очікуванням, вам слід спробувати відстежити, де вхідні дані помиляються, і внести відповідні виправлення.

Іноді для цього процесу розробники використовують такі засоби налагодження, як налагоджувачі та реєстратори.

Надто складний код

Однією з найпоширеніших помилок програмістів є написання надто складного коду. Найпростіше рішення часто є найкращим і згодом спричинить менше головного болю.

Професійна порада

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

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

Жодних заходів безпеки

Однією з найбільших проблем із заходами безпеки, які не реалізовані в коді, є те, що їх надто легко зламати. Це особливо вірно, коли код має відому вразливість.

Хакери будуть шукати ці вразливості та використовувати їх якомога швидше. The чим популярніша система, тим легше буде її знайти хакерамщо означає, що вам потрібні заходи безпеки, перш ніж ваш продукт стане популярним.

Якщо ви не хочете впроваджувати жодних заходів безпеки або витрачати час на розробку з нуля, доступні деякі служби, які надають механізми автентифікації та авторизації користувачів.

Код порушується під час зміни

Код повинен бути гнучким і стійким. Якщо ви вносите будь-які зміни – зламайте програму, ви повинні виправити це якомога швидше. Інакше ці тендітні частини продовжуватимуть збільшуватись у розмірі та ускладнюватися.

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

Іноді частини вашої програми непросто протестувати за допомогою модульних тестів. Або вони надто довго виконують усі тести. Крім того, крихкий код важко перевірити.

Коли це трапляється, у розробників виникає велика спокуса почати додавати додаткові оператори if та умови, щоб вони точно знали, коли щось піде не так під час тестування, замість того, щоб виправляти основну проблему.

Однак це зрештою робить ваш код ще крихкішим, ніж раніше – тепер у вас є помилка в одному рядку, але все працює в іншому!

Немає місця для покращень

Здається, що це занадто багато? Це може бути тому, що він робить занадто багато речей одночасно. Часто буває важко зрозуміти, чого ви намагаєтеся досягти за допомогою певного фрагмента коду.

Професійна порада

Спробуйте розбити код на дрібніші частини, кожна з яких працює над одним завданням.

Також може бути важко зрозуміти, як взаємодіють різні частини вашого коду. Один із способів вирішити цю проблему — розділити різні області та впорядкувати їх, щоб їх було легше читати.

Забагато умов IF

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

Професійна порада

Якщо ви використовуєте оператор IF із більш ніж двома чи трьома умовами, подумайте про розбиття його на два або три окремі оператори. Компроміс полягає в тому, що у вашому файлі буде більше рядків, але всі окремі твердження будуть коротшими та легшими для розуміння.

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

Різниця полягає в тому, що циклу однієї людини легко слідкувати, тоді як іншій потрібно набагато більше часу, щоб зрозуміти, що відбувається.

Пам’ятайте, що простота завжди перемагає коли справа доходить до читабельності. Намагайтеся, щоб петлі не перевищували 15 рядків щоб кожен міг стежити за тим, що відбувається.

Забагато відділень у структурах управління

Як розробник, ви щодня пишете тонни рядків коду; вищі шанси, що деякі будуть поганими.

Рефакторинг передбачає зміну внутрішньої структури вашого коду без зміни зовнішньої поведінки. Це допомагає зберегти ваш код чистим і легким для читання.

Інший спосіб запобігти поганим звичкам програмування – це уникати поширених пасток у розробці програмного забезпечення, такі як складність і надмірне використання умовних операторів (розгалуження). Це два способи, на які розробники часто потрапляють, коли пишуть поганий код, але у них є вихід.

Багато магічних чисел

Магічне число це буквальне число без значення поза контекстом.

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

Магічні числа неправильні з двох причин:

  • значення не можна змінити;
  • назва змінної не надає жодної інформації про те, що вона представляє.

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

Немає коментарів

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

Наприклад, 3-5-й рядки повідомляють нам, що робити з кодом:

Професійна порада

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

Без коду DRY

Принцип коду “Не повторюйся” (DRY). стверджує, що кожна частина знання повинна мати єдине, недвозначне, авторитетне представлення.

Якщо є два фрагменти коду для однієї функції, вам слід видалити один із них.

Отже, що це означає?

Це означає, що коли ви копіюєте та вставляєте фрагменти коду та називаєте це алгоритмом, ви створюєте програмне забезпечення низької якості. Ваш метод складається з трьох частин, але коли щось змінюється у другій частині, це вплине не лише на третю; це також вплине на першу частину. Звичайно, помилка з’являється в останньому місці, де ви очікували.

Висновок

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

Якщо вас цікавить послуга “сайт візітка”, заказати можна тут, в веб-студії filandor. Студія працює багато років та надає комплексні послуги.

Джерело: https://crocoblock.com/blog/writing-clean-code-tips/

Related posts