Нам часто пишуть - розбивайте ваш код на підзадачі, і тому подібне. Зазвичай мотивують це словами: "для читабельності коду", "для того, щоб легше було писати код". Виникає питання, а на які саме підзадачі ділити?
Розпочну з причини, з історії, власного, скромного досвіду.
Виконував задачі на JavaRush, спочатку на задачу йшло 5 хв, згодом 15 і розбиття задачі на шматки не несло особливої користі. Але на 27-28 рівні стало вже досить багато задач, на які витрачалось 2 і більше години. Великої кількості вільного часу я не мав, тому деякі задачі доводилось починати виконувати одного дня, а закінчувати іншого.
І ось, ти сідаєш дописувати код вчорашньої задачі... Так-так, а на екрані перших 3 секунди "абракадабра", потім, ти починаєш бачити шматками свою программу і хвилини 3-4 листаєш вверх вниз, бо не пам'ятаєш вчорашій код!
Тому, мої особисті рекомендації - розбивати задачу на шматки, як мінімум по двом критеріям:
1. На такі підзадачі, які ти можеш виконати за мінімальний час, без перерв (на каву, інстаграм, туалет тощо).
2. Намагайся зробити так, щоб код твоєї "підзадачі"(зазвичай метод) поміщався на трохи більше ніж півсторінки(все одно, він неочікувано збільшиться до розміру сторінки).
А ще, намагайся робити так, щоб змінні які використовуються в твоїй підзадачі, по можливості було фізично видно в "підзадачі"(на одному екрані), це потрібно для того, щоб не перемикатись, не листати, а зосередитись на самому виконанні.
Ці поради зберігаюсть найдорожче - час.
+4
Комментарии (7)
популярные
новые
старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Если метод занимает пол страницы и тем более на одну страницу, то скорее всего он составлен не правильно.
Проще всего понять правильность/не правильность это посмотреть на его название и посмотреть что он делает на самом деле. Если его наименование не совпадает с тем что он делает, то значит он написан не правильно.
Например если метод называется sum() но по коду он не только суммирует, но еще и сортирует - метод составлен не правильно.
По планированию работы и разбиению на подзадачи, удобно начинать как раз с объявления методов. (еще говорят с проектирования интерфейсов)
Например есть задача "Переставить кружку" то можно сразу накидать методы в main, не реализовывая их:
//TODO - это метка, которой обычно помечают место которое нужно доработать, это удобно, сразу видно что еще не сделано.
Далее под каждый метод, начинаешь писать классы, другие методы - если нужно.
плюсую, плюс добавлю от себя,
в одном методе как правило не может быть более 1 блока try catch, да и вообще, если у вас есть блок try ...catch и еще логика, то это значит что try .. catch должен быть в отдельном методе.
Часто, если много форов, которые делают разные вещи, как Павел пишет, здесь мы сортируем, здесь суммируем, здесь что-то выводим, это все разные методы.
Плюс разбивки на методы - в дискретности, гибкости и переиспользовании.
Дискретность - это важно для джавы, представим, да простят меня строители, что есть 100500 видов кирпича, и мы в рамках строительства 1-го дома используем эти разные виды причем все, то есть каждый кирпич отличается формой, размером, материалом, тот квадратный, треугольный и тд. Потом есть разные подходы , первый этаж заливается бетоном арматура, второй сруб, третий панельки ставятся, четвертый и выше микс - треть сруба, треть арматуры и тд, и так во всем.
На выходе мы получим нужный результат, но из такого построить небоскреб к примеру будет необычайно сложное.
Дискретность же, когда сложные вещи разделяются на ПРОСТЫЕ составные части, дают возможность строить сложные сооружения, здесь дело не в разнообразии, на сложных инженерных сооружениях может быть большая номенклатура, а в том, чтобы любой самый сложный объект сводился до простого кирпича, арматуры, болта, сварочного шва и тд, до простых вещей, ими тогда леко манипулировать и делать с них сложные вещи.
Поэтому что отличает мысль синиора, техлида и джуна , одно из самых явно заметных вещей - это чем больше опыта, тем инженер делает ПРОЩЕ. Поскольку эта простота жизненно необходима для построения больших жизнеспособных систем.
Представим программу на 2 000 классов, в которой каждый метод черт голову сломает, с этим невозможно будет что-то делать.
А если составный элемент - метод, простой как двери, делает одну вещь, значит и всю программу можно понять и с ней работать как совокупностью вещей, которые можно понять.
Дальше идет гибкость.
Представим поезд, состоящий из одного вагона длиной в 3 или 5 км. Это когда все в одном методе. Зачем нам вообще те вагоны разбивать..отлили один вагон и вперед.
В начале вагона двигатель, посредине разместили пассажиров, а в конце уголь насыпали или бочки с топливом.
Но как этот поезд будет проезжать банально повороты? Как пассажирам спать возле двигателя или в обнимку с бочкой соляры? Это не гибкая система и неудобная и сложно эксплуатируемая.
Поэтому когда разбито на отдельные вагончики связанные друг с другом, система становится гибкой, можно один вагончик убрать, забрать, прицепить, поменять, повороты проходятся на ура. Это аналогия с небольшими методами.
И третий момент - реюзабельность, когда у нас есть программа, которая:
вводит с консоли строки
сортирует их
делает логику обработки
выводит на экран
и мы это все в одном методе мейн, ну вроде ок, работает, чё надо еще.
Но когда нам нужно добавить новый функционал, ввод с консоли, обработка, вывод БЕЗ сортировки, мы будем дублировать код снова и снова.
А если бы были 4 разных метода, мы бы могли просто вызывать готовые методы, это уже как наша собственная библиотека, надо ввести с кнсоли? Есть метод. надо вывести на экран? Есть метод, это очень удобно и правильно, поскольку дублирование кода приводит к тому, что если что-то меняется, нам нужно делать одни и те же изменения в разных участках кода и большой риск что-то пропустить.
Рефакторинг программы будет обходиться дороже , дольше и ошибок будет больше.
Злоупотреблять конечно тоже не стоит и по одной строке на метод, здесь как Павел писал, смотрите что код делает, не разные вещи ли, какая эта задача, насколько этот метод норм для переиспользования, называйте методы по тому, что они делают, как только там появится And, это значит что метод явно делает разные вещи.
Относительно самой же декомпозиции задачи, то делить нужно до тех пор, пока подзадачи не станут дискретными, простыми, неделимыми.
Потом есть разные подходы , первый этаж заливается бетоном арматура, второй сруб, третий панельки ставятся, четвертый и выше микс - треть сруба, треть арматуры и тд, и так во всем.
На выходе мы получим нужный результат, но из такого построить небоскреб к примеру будет необычайно сложное.
Забавная аналогия) и довольно точная
Даже если такой небоскреб можно будет построить, то эксплуатировать и ремонтировать его будет сущий ад
