Код, но не тот
или на что обратить внимание в вашем тестовом задании, пет-проекте или любом другом фрагменте кода
У меня нет цели пересказать вам SOLID, ООП, внушить что-то про чистый код и тд. Просто вот 5 довольно критичных недостатков, исправив которые, вы можете сделать свой код заметно лучше.
Написано по итогам проверки десятков тестовых заданий.
1. Поддерживаемость кода.
Часто можно встретить спагетти-код, который является решением вот этого (и только этого) конкретного задания и совсем не универсален. В таком случае его сложно переиспользовать и поддерживать, его сложно понять, что на реальном проекте станет существеной проблемой.
Иными словами, хорошо бы показать, что вы умеете писать код, с которым будет удобно работать и вам, и остальным в долгосрочной перспективе.
2. Нейминг.
Тут про нейминг файлов, тестов, функций и переменных. Наименования всех этих сущностей должны быть однозначными, понятными, конкретными и тд. С примерами об этом хорошо написано, например, тут.
3. Тестирование.
Если вам требуется написать тесты на функцию, точно не стоит пренебрегать тест-дизайном и особенностями вашего фреймворка тестирования.
Лучше сначала сформулировать интересующие вас проверки и только потом написать код.
4. Переусложнение.
Задайтесь вопросом, все ли методы и конструкции, использованные в вашем коде, действительно необходимы. Нельзя ли добиться ровно той же цели встроенными методами языка или, просто убрав лишний блок кода?
5. Документация к проекту, аннотации и понятность кода.
README с минимальным описанием проекта и его особенностей точно не повредит.
А что касается аннотаций методов и переменных, в том же Python у вас есть богатый арсенал средств для повышения читабельности кода -- неплохие примеры можно найти здесь.
Замечено, что в большинство из этих пунктов не умеет ИИ, но умеет человек, который понимает зачем и что он пишет в своём коде. Think about it
>>Click here to continue<<