Зачем разбивать код на функции, если код короткий (~30 строчек) и нет повторяющегося кода?

Question

[Zellily]

Я пишу на Питоне для себя, когда на работе требуется быстро сгенерить из одного файла другой и т.п. Случайно попался на глаза вопрос, где человек показал пример своего кода. Код копирует файлы по определённому признаку из одной папки в другую. Код короткий. Однако среди ответов есть такой:

"Код нужно разбить хотя бы на функции, а не все в одну кучу "

Зачем? Чем он станет лучше? Код написан совершенно прозрачно и понятно. Повторяющихся кусков нет. Зачем функции?

Answer 1

[sim3x]

Потому что так проще покрывать тестами

Comments

[Zellily]

У меня код маленький и сразу видно, работает он как надо или нет.

А что можно оттестировать в указанном примере? Проверить, что файл существует по указанному пути? Проверить функцию копирования и построчно сравнить файлы? Использования эксепшенов не хватит?

[sim3x]

Zellily:

примерно так и появляются проекты, написанные в стиле говнокод с костылями

Проверить, как работает функция

Ексепшены не имеют к тдд никакого отношения

[Zellily]

sim3x: А что можно проверить в копировании?

[sim3x]

Zellily: а там главная функция состояла только в копировании?
Или же в разборе путей?
Почему стоит написать чистую функцию и покрыть ее тестами
А грязную функцию, в которой будет копирование, влоб не проверить, скопировались ли файлы или нет?

[Zellily]

Как-то непонятно написано :(

Answer 2

[ozornick]

Если нет необходимости повторного использования, то незачем функции.

Comments

[DeadMemories]

Не совсем так...
Обычно в таких ситуациях созданные методы получают private/protected модификатор, так что доступ из вне - никак.
А насчет функций:
Скорее всего, код в дальнейшем будет доработан, вот и решили сразу разбить, ну или же привычка разбивать все что можно :)

Answer 3

[Vladimir Dubos]

У Вас есть программа, которая копирует файлы по определенному признаку из одной папки в другую, разбитая на функции "определение определенного признака" и "копирование в другую папку", а завтра Вам надо будет сделать программу, которая будет просто копировать файлы из одной папки в другую, Вы берете готовую функцию и не паритесь с выискиванием нужного фрагмента в коде старой программы

Comments

[Zellily]

Хм. Мне, наверное, слишком редко приходится два раза один и тот же код использовать.

[Vladimir Dubos]

Zellily: Я, как phpшник, достаточно часто использую функцию "забрать из быза данных и вывести одно за одним"

[Zellily]

А вы её копируете или выделили в отдельный файл?

[Vladimir Dubos]

Zellily: я ее копирую и помещаю в самый верх кода, не люблю, когда в папке проекта миллион файлов шатается

[Zellily]

Vladimir Dubos: Понятно :)

Answer 4

[Vitaliy]

Повысится самодокументируемость.
Не нужно будет в уме разбивать код на части, чтобы понять что они делают. Все равно как минимум 5-8 строк кода должны выполнять определенную задачу, а не только общую

Comments

[Zellily]

Ну не знаю, там код такой прозрачный был, сложно не понять, что он делает.

Answer 5

[altai2013]

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

Comments

[Zellily]

Это если он непонятный. А там ругались на отсутствие функций в совершенно прозрачном коде. Собственно там было непройденное тестовое задание, и если человек его не прошёл именно по этой причине, то надо было дать задание посложнее, чтобы необходимость в функциях возникла.

[Zellily]

А разве он не прозрачный? Я не вижу ни одного непонятного места. Другое дело, что написан криво, например:
print("Can\'t open configuration file.") у него относится не к попытке открыть файл, а относится ко всей вот этой куче действий. Поэтому такая диагностика введёт в заблуждение. Но о таких вещах ему никто не сказал.

ЗЫ Да, это он.

Answer 6

[User23]

Код нужно разбить хотя бы на функции, а не все в одну кучу

Это была моя цитата.

Зачем? Чем он станет лучше? Код написан совершенно прозрачно и понятно. Повторяющихся кусков нет. Зачем функции?

Лучше он станет тем что человек впервые увидевший код, сможет сразу разобраться что за что отвечает, и если надо будет вносить какие либо изменения то это нужно будет сделать в одном месте.
Если кусок кода понадобиться еще где то использовать необходимо будет вставить только название функции, а не копипастить экран текста.
При использование функций, в разы легче находить и исправлять ошибки.

Comments

[Zellily]

Ну, я такой человек, увидевший в первый раз, и проблем с пониманием у меня возникло.

ЗЫ Мне нравится ответ, что функции нужны для всяких юнит-тестов. Если такое реально тестируют, потому что никто не признался, что тут можно протестировать.

[User23]

Вы троллите или реально не понимаете?

[Zellily]

User23: Не троллю, просто мой код редко используется кем-то кроме меня, поэтому я, видимо, не в теме трендов.

[User23]

А какое отношение имеет ваш код к тестовому заданию в Dr Web ?
Ваш код вы можете писать так как вам нравится и как вам удобно хоть в одну строчку, но при написание тестового задания подразумевается что вы будете писать в таком же стиле на продакшене , и поэтому нужно вылизать каждую строчку, и показать как вы хорошо умеете
писать читаемый код, и разделять его на отдельные блоки.
Его нужно писать предполагая что завтра его будут дорабатывать еще 10 коллег, после завтра будут тестировать отдел тестировщиков написанием unit тестов, после после завтра будут использовать написанный вами метод или функцию в нескольких местах проекта.

[Zellily]

User23: Нет, я не могу писать в одну строчку, потому что не разберусь через полгода в написанном. И если я уволюсь, или кто-то вдруг захочет воспользоваться моим кодом, то надо, чтобы он был читаемым.

Но остальная тема про 10 коллег и юнит-тестирование для меня - тёмный лес.

Answer 7

[nApoBo3]

Задача декомпозиции упростить поддержку и развитие кода. Если поддержка и развитие не планируется, то декомпозиция не нужна.
Код еще не написан: разбить, поскольку так проще тестировать и разрабатывать.
Код уже написан, но будет развиваться: разбить, иначе очень скоро ваш код обрастет дублированием, а ошибки в нем искать будет весьма затруднительно. При большом объеме код сможете поддерживать только вы, разобраться в нем будет не просто, внесение изменений потребует глубокого понимания всего кода.
Код уже написан, работает, не содержит ошибок и не будет развиваться: не разбивать, поскольку это трудозатраты которые ничего не дадут.

Comments

[Zellily]

Тут интересный момент, этот код был ответом на тестовое задание, и нигде в этом задании не было указано, что этот код будет развиваться и поддерживаться (что логично, тестовые задания не развивают и не поддерживают). И кем-то использоваться, кроме тестируемого человека и рецензента. Авторам бы неплохо было добавить строчку о назначении кода в своём задании.

Answer 8

[Евгений]

Ответы были бы более конкретные или бы их не было бы вообще, если бы мы увидели код.
Иначе все ответы можно расценивать как "диванную аналитику".
Я считаю...

Answer 9

[Александр Тер]

Если это один криво-корявый, но работающий проект, о котором вы забутите сразу после сдачи, то можете не париться. И если вы занимаетесь только созданием такого рода проектами, то можете не читать дальше и не тратить свое время.
А вот если проект нужно будет поддерживать (по опыту могу сказать, что выполняет та или иная функция забывается уже через месяц) или над ним работают другие люди, или вы хотите уйти спокойно в отпуск, в котором вы не хотите что бы вас тревожили, то лучше конечно же писать так, чтобы в функции выполнялась одна операция или по крайней мере если их несколько, то это как-то должно отражаться в ее названии и конечно же она должна быть задокументирована (практически все IDE позволяют это делать без особого напряга).
Хороший код легко читается и понимается, а самое главное на добавление (изменение, удалении) новой функции в нем тратится гораздо меньше времени, чем в криво-корявом коде.

Конечно криво-корявый код используется повсеместно и может без проблем работать годами, до тех пор пока не надо что-то поменять ...

Comments

[Zellily]

Ой, там был такой понятный код, что хотя я и не автор, мне было сразу понятно, что он делает. Проблемы переписать или дописать его у меня бы не было.

[ManWithBear]

Zellily: а скиньте уже этот код, а то я который день читаю эти дискуссии и всё не понимаю о чем речь

[Zellily]

ManWithBear: Это отсюда, но на гите автор уже модифицировать начал:
Провалил тестовое задание DrWeb. В чем косяк?

ЗЫ Забавно, ему ответили из фирмы, куда он хотел. Первым пунктом именно то, что мне сразу бросилось в глаза, но о чём никто не написал. Вторым, в общем-то, тоже.
А вот про функции и строки ему ничего не написали.