Предыдущий выпуск на https://medium.com/@magyar1886/100-days-of-pain-day-6-big-picture-48e275e7c6b0
Я только что закончил реализацию еще одной небольшой функции моего приложения Flask. Я сделал это на чистом Python-скрипте, и у меня все получилось довольно быстро. Мой скрипт теперь принимает файл Excel в качестве входных данных для импорта данных в SQLite, а также выполняет экспорт текущей базы данных.
Теперь есть проблема, код делает то, что я просил. Есть ли все, что мне нужно сделать? Точно нет!
Я быстро проверю некоторые принципы, взятые из книги Боба Мартина «Чистый код» в качестве справки:
Значимые имена
Имена повсюду. Теперь мой худший выбор был для индексных переменных, таких как n и m. См. также строку 225, что означают n и m и 11 или 13? Довольно неясно. Я должен оставить комментарий, но хорошим правилом будет то, что переменная раскрывает свое намерение.
У меня также есть три функции: xls_import, create_connection и create_task. Это вполне нормально и должно быть понятно, но я должен вернуться и переименовать несколько переменных.
Функции
Второй момент — функции. Здесь у нас тоже есть несколько рекомендаций:
- Они должны быть маленькими
- Они должны сделать одну вещь
- Один уровень абстракции
Функция create_connection — хороший пример, она делает только одно — подключается к базе данных. Он также имеет обработку ошибок! Подробнее позже.
Теперь проблема с моим кодом в том, что я получил много вещей, которые, возможно, можно свести к функции.
Функция main() действительно состоит из большого количества непонятного кода, рефакторинг должен хотя бы прояснить, какова последовательность действий. То, что вызывается несколько раз, должно быть сведено к функции, тогда…
Комментарии
Здесь нечего сказать, кроме того, что нам нужны хорошие комментарии, чтобы прояснить, объяснить намерение и проинформировать. Они должны быть четкими, поэтому избегайте бормотания или слишком большого количества информации.
Также не рекомендуется закомментировать код. Что я часто использую в качестве комментария, так это раздел TODO, чтобы помнить, что мне еще нужно сделать в конкретном разделе.
Форматирование
Делайте файлы как можно короче. Мой код выше составляет около 235. Это уже много для такого маленького проекта, как мой. В более крупном проекте, возможно, нецелесообразно сохранять файл таким маленьким или даже возможным….
В любом случае, есть что сказать по форматированию. Форматирование важно, и в книге «Чистый код» объясняются многие понятия, такие как плотность по вертикали, выравнивание, длина строки и т. д.
Ключевым понятием здесь является читабельность. Одна вещь, которую я часто делаю, — это разделение разделов пустыми строками и объединение связанных вещей (например, комментарий к переменной и ниже определения переменной).
Обработка ошибок
Еще один очевидный момент. В моем коде у меня может быть только одна логика обработки ошибок. Это так неправильно! В этих 235 строках может произойти многое. Просто назвать несколько:
- Имя базы данных неверно
- SQL-запросы не выполняются
- Невозможно создать файл экспорта xls
- Ссылка на имена таблиц неверна
- В каталоге, где скрипт ищет, нет файла Prologger_Import.xslx.
Поэтому мы должны добавить обработку ошибок для всех этих случаев. Важно сообщить пользователю, что не сработало.
Кроме того, ошибка может исходить и от ввода пользователем. В этом сценарии я мог бы, например, поместить неверные значения в Excel, которые должны быть импортированы, вызывая ошибки SQL. Как я могу относиться к ним?
Это самая сложная часть, то есть отследить каждый закоулок и каждую критическую ситуацию.
Тестирование
Для меня это связано с обработкой ошибок и означает, что я должен проверить ошибки, которые хочу проверить. Здесь я избегаю говорить о разработке тестовых дисков (TDD), которая является сложной темой для не кодера, такого как я.
Мне нужно просто перечислить спецификации, которые я хочу для проекта, и то, что пользователь может сделать неправильно. Я не хочу ожидать слишком многого от пользователя, но я также не хочу исправлять каждую ошибку, которую он/она делает.
Каков ваш опыт работы с плохим или хорошим кодом? Какие вещи вас волнуют?
В следующей части я расскажу о переработанном коде после «лечения» по принципам Боба Мартина.
Быть в курсе!
