|
|
<!--
|
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
|
{
|
|
|
"original_hash": "d0a02cb117e91a5b5f24178080068a3d",
|
|
|
"translation_date": "2025-10-24T15:48:44+00:00",
|
|
|
"source_file": "7-bank-project/3-data/assignment.md",
|
|
|
"language_code": "uk"
|
|
|
}
|
|
|
-->
|
|
|
# Завдання з рефакторингу коду та документації
|
|
|
|
|
|
## Цілі навчання
|
|
|
|
|
|
Виконуючи це завдання, ви будете практикувати основні навички розробки програмного забезпечення, які професійні розробники використовують щодня. Ви навчитеся організовувати код для зручності підтримки, зменшувати дублювання через абстракцію та документувати свою роботу для майбутніх розробників (включаючи себе!).
|
|
|
|
|
|
Чистий, добре документований код є критично важливим для реальних веб-проєктів, де співпрацюють кілька розробників, а кодова база постійно змінюється.
|
|
|
|
|
|
## Огляд завдання
|
|
|
|
|
|
Файл `app.js` вашого банківського додатку значно виріс, включаючи функціонал входу, реєстрації та панелі управління. Настав час рефакторизувати цей код, використовуючи професійні практики розробки, щоб покращити читабельність, зручність підтримки та зменшити дублювання.
|
|
|
|
|
|
## Інструкції
|
|
|
|
|
|
Перетворіть ваш поточний код `app.js`, застосовуючи три основні техніки рефакторингу:
|
|
|
|
|
|
### 1. Витягнення конфігураційних констант
|
|
|
|
|
|
**Завдання**: Створіть секцію конфігурації у верхній частині файлу з багаторазовими константами.
|
|
|
|
|
|
**Рекомендації щодо реалізації:**
|
|
|
- Витягніть базовий URL API сервера (який наразі жорстко закодований у кількох місцях)
|
|
|
- Створіть константи для повідомлень про помилки, які з'являються у кількох функціях
|
|
|
- Розгляньте можливість витягнення шляхів маршруту та ідентифікаторів елементів, які використовуються повторно
|
|
|
|
|
|
**Приклад структури:**
|
|
|
```javascript
|
|
|
// Configuration constants
|
|
|
const API_BASE_URL = 'http://localhost:5000/api';
|
|
|
const ROUTES = {
|
|
|
LOGIN: '/login',
|
|
|
DASHBOARD: '/dashboard'
|
|
|
};
|
|
|
```
|
|
|
|
|
|
### 2. Створення уніфікованої функції запиту
|
|
|
|
|
|
**Завдання**: Побудуйте багаторазову функцію `sendRequest()`, яка усуне дублювання коду між `createAccount()` та `getAccount()`.
|
|
|
|
|
|
**Вимоги:**
|
|
|
- Обробляти як GET, так і POST запити
|
|
|
- Включати належну обробку помилок
|
|
|
- Підтримувати різні URL-адреси
|
|
|
- Приймати необов'язкові дані тіла запиту
|
|
|
|
|
|
**Рекомендації щодо сигнатури функції:**
|
|
|
```javascript
|
|
|
async function sendRequest(endpoint, method = 'GET', data = null) {
|
|
|
// Your implementation here
|
|
|
}
|
|
|
```
|
|
|
|
|
|
### 3. Додайте професійну документацію коду
|
|
|
|
|
|
**Завдання**: Документуйте ваш код чіткими, корисними коментарями, які пояснюють "чому" за вашою логікою.
|
|
|
|
|
|
**Стандарти документації:**
|
|
|
- Додайте документацію функцій, яка пояснює мету, параметри та значення, що повертаються
|
|
|
- Включіть внутрішні коментарі для складної логіки або бізнес-правил
|
|
|
- Групуйте пов'язані функції разом із заголовками секцій
|
|
|
- Поясніть будь-які неочевидні шаблони коду або специфічні для браузера обхідні шляхи
|
|
|
|
|
|
**Приклад стилю документації:**
|
|
|
```javascript
|
|
|
/**
|
|
|
* Authenticates user and redirects to dashboard
|
|
|
* @param {Event} event - Form submission event
|
|
|
* @returns {Promise<void>} - Resolves when login process completes
|
|
|
*/
|
|
|
async function login(event) {
|
|
|
// Prevent default form submission to handle with JavaScript
|
|
|
event.preventDefault();
|
|
|
|
|
|
// Your implementation...
|
|
|
}
|
|
|
```
|
|
|
|
|
|
## Критерії успішності
|
|
|
|
|
|
Ваш рефакторизований код має демонструвати ці професійні практики розробки:
|
|
|
|
|
|
### Зразкова реалізація
|
|
|
- ✅ **Константи**: Усі магічні рядки та URL-адреси витягнуті у чітко названі константи
|
|
|
- ✅ **Принцип DRY**: Загальна логіка запитів консолідована в багаторазову функцію `sendRequest()`
|
|
|
- ✅ **Документація**: Функції мають чіткі коментарі JSDoc, які пояснюють мету та параметри
|
|
|
- ✅ **Організація**: Код логічно згрупований із заголовками секцій та послідовним форматуванням
|
|
|
- ✅ **Обробка помилок**: Покращена обробка помилок за допомогою нової функції запиту
|
|
|
|
|
|
### Достатня реалізація
|
|
|
- ✅ **Константи**: Більшість повторюваних значень витягнуто, залишилися незначні жорстко закодовані значення
|
|
|
- ✅ **Факторизація**: Базова функція `sendRequest()` створена, але може не враховувати всі крайні випадки
|
|
|
- ✅ **Коментарі**: Основні функції задокументовані, хоча деякі пояснення могли б бути більш повними
|
|
|
- ✅ **Читабельність**: Код загалом добре організований, хоча є області для покращення
|
|
|
|
|
|
### Потребує покращення
|
|
|
- ❌ **Константи**: Багато магічних рядків та URL-адрес залишаються жорстко закодованими у файлі
|
|
|
- ❌ **Дублювання**: Значне дублювання коду залишається між схожими функціями
|
|
|
- ❌ **Документація**: Відсутні або недостатні коментарі, які не пояснюють мету коду
|
|
|
- ❌ **Організація**: Код не має чіткої структури та логічного групування
|
|
|
|
|
|
## Тестування вашого рефакторизованого коду
|
|
|
|
|
|
Після рефакторингу переконайтеся, що ваш банківський додаток все ще працює правильно:
|
|
|
|
|
|
1. **Перевірте всі користувацькі потоки**: Реєстрація, вхід, відображення панелі управління та обробка помилок
|
|
|
2. **Перевірте API-запити**: Переконайтеся, що ваша функція `sendRequest()` працює як для створення, так і для отримання акаунтів
|
|
|
3. **Перевірте сценарії помилок**: Тестуйте з недійсними обліковими даними та помилками мережі
|
|
|
4. **Перегляньте консольний вивід**: Переконайтеся, що під час рефакторингу не було введено нових помилок
|
|
|
|
|
|
## Інструкції щодо подання
|
|
|
|
|
|
Надішліть ваш рефакторизований файл `app.js` з:
|
|
|
- Чіткими заголовками секцій, які організовують різний функціонал
|
|
|
- Послідовним форматуванням та відступами коду
|
|
|
- Повною документацією JSDoc для всіх функцій
|
|
|
- Коротким коментарем у верхній частині, який пояснює ваш підхід до рефакторингу
|
|
|
|
|
|
**Додатковий виклик**: Створіть простий файл документації коду (`CODE_STRUCTURE.md`), який пояснює архітектуру вашого додатку та як різні функції працюють разом.
|
|
|
|
|
|
## Зв'язок із реальним світом
|
|
|
|
|
|
Це завдання відображає тип підтримки коду, яку професійні розробники виконують регулярно. У промислових умовах:
|
|
|
- **Огляди коду** оцінюють читабельність та зручність підтримки, як у цьому завданні
|
|
|
- **Технічний борг** накопичується, коли код не рефакторизується та не документується регулярно
|
|
|
- **Співпраця в команді** залежить від чіткого, добре документованого коду, який можуть зрозуміти нові члени команди
|
|
|
- **Виправлення помилок** значно простіше у добре організованих кодових базах із належними абстракціями
|
|
|
|
|
|
Навички, які ви тут практикуєте - витягнення констант, усунення дублювання та написання чіткої документації - є фундаментальними для професійної розробки програмного забезпечення.
|
|
|
|
|
|
---
|
|
|
|
|
|
**Відмова від відповідальності**:
|
|
|
Цей документ був перекладений за допомогою сервісу автоматичного перекладу [Co-op Translator](https://github.com/Azure/co-op-translator). Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ на його рідній мові слід вважати авторитетним джерелом. Для критичної інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникають внаслідок використання цього перекладу. |
