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

І це проливає світло на проблему, яка здається досить поширеною: як зрозуміти за якими ознаками код Flutter розробника "добрий" або "поганий". Щоб дати деякі натяки на це, ми збираємося зібрати у цій статті що "робити" та "не робити" у Flutter розробці. Залишайтесь з нами, якщо вам цікава така тема, ми плануємо час від часу оновлювати її новими кейсами. Давайте почнемо з: 

Робити:

Хороший зразок коду #1: Використовуйте централізований метод для ініціювання мережевих викликів: У цьому прикладі вище ми бачимо єдиний метод обгортання для виконання виклику і обробки відповіді від нього. #2 Тут також див ‘debugPrint’, який використовується для отримання print на консоль тільки в режимі налагодження. Деякі  nubies використовують метод direct print, який приносить багато сміття у production  будує вихідні дані. 
Приклад #3: Використовуйте інтерфейс, а не ім'я класу для звернення до методів служб: Sample #4: Використовуйте клавіші для звернення до віджету для оновлення, коли вам потрібно перебудувати тільки його, а не все дерево віджетів: Введіть ключ у стан віджета: І коли віджет створений зробіть це за допомогою ключа: Доступ до методів або полів цього конкретного віджета здійснюється наступним чином
Приклад #5: Використовуйте властивості для їх змін, щоб реагувати на оновлення: Розширення класів PropertyChangeNotifier Екземпляр цього класу в допоміжному класі: І нарешті використання в UI віджеті: Тут ми також знайдемо хороший зразок #6: використання null-aware ?? оператор, який дає значення за замовчуванням'' до змінної _avatarUrl у випадку NetworkHelper.user.avatarUrl - null.

а тепер давайте згадаємо деякі з них

Не робити:

Приклад #1: Використовуйте примусову затримку при роботі з ансихронними викликами, щоб "переконатися, що виклик виконаний":
Приклад #2: Відсутність unit ам UI тестів, введених в проект, безумовно свідчить про низький рівень навичок кодування або відстуність відношення до нього