Быстрое и медленное создание программ (код): в чём разница и суть?

Категория: Технические советы

– Автор: Игорь (Администратор)

Существует как минимум два известных подхода для создания кода программ: быстрый и медленный. При этом в первые моменты быстрый код кажется более существенно привлекательным (особенно клиентам), чем медленный, который к тому же почему-то и стоит выше (по этому поводу ещё отдельно отмечу моменты). И только с опытом понимаешь почему это так. В этом обзоре рассмотрим что это за подходы, в чём их суть и разница.

Быстрое и медленное программирование (код): что это?

Быстрое программирование (код) - это подход, при котором код пишется в туже минуту, когда возникла потребность, с минимальной оценкой рациональности (поддержка кода, последующее расширение и т.д.). Чаще всего выражается в большом количестве копипаста, неоптимизированности, использовании ненужных конструкций и тому подобного. Но со стороны выглядит это как активная бурная деятельность, что обычно нравится клиентам.

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

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

Быстрый и медленный код: в чём суть?

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

Допустим, вам нужно создать какой-то документ (инструкцию, описание и т.д.). Что обычно делают, когда хочется быстро "сварганить писульку" и поползти заниматься чем-то более увлекательным? Правильно, просто пишут в стиле "лишь бы был текст" (вода, повторяющийся текст, порой даже целые разделы, отсутствие форматирования, плохо выраженные мысли и тому подобное). Каждый в своей жизни читал подобные литературные творения. И каждый помнит как это удобно - искать что-либо в чём-то подобном.

Когда же создаётся полноценный документ, то это сразу заметно. Подача мысли структурирована. Тексты выверены и подразумевают удобное форматирование. Нужные разделы всегда легко найти. Мысли легко усвоить. И тому подобное. И каждый в жизни сталкивался с такими документами и обращал внимание, как сильно отличается качество.

Быстрое и медленное программирование (код): какова разница в плюсах и минусах?

Проще всего выразить разницу между быстрым и медленным созданием программ (кода) в плюсах и минусах.

Плюсы быстрого программирования:

1. Решение максимально быстро (если это возможно). Код пишется сразу и без проволочек.

2. Дешевле в момент создания. Правда не всегда, но такое бывает. Код пишется без какой-либо задней мысли, поэтому и требования к такому коду меньше.

Минусы быстрого программирования:

1. Быстрый код во время создания может дойти до ситуации, когда программу нужно переписывать или долго отлаживать. Так как оценка рациональности минимальна, то легко может произойти ситуация, когда в коде очень сложно разобраться, а также найти и исправить какие-либо возникшие ошибки (в некоторых ситуациях ошибки вообще нереально исправить без полноценной переделки).

2. Дороже в последствии. Исправлять какие-то ошибки или дописывать функции в подобном коде - обычно дело непростое, хотя чаще всего кажется, что раз код писался быстро, то и дальше также быстро будет (но обычно это не так). Соответственно, это и выливается в повышенный объём времени и сил.

Плюсы медленного программирования:

1. Код обычно меньше и грамотнее. Скажем, вполне нормальное явление, что программа в 10 тысяч строк (созданная быстрым подходом) может быть сжата до 2 тысяч строк (в медленном подходе). Просто потому что код пишется не абы как, а вдумчиво.

2. Поддержание и расширение такого кода обычно дешевле, чем при быстром подходе. Код понятнее и грамотнее, поэтому и расширять его чаще всего дешевле.

Минусы медленного программирования:

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

2. Не каждый сможет корректно расширить код. Обычно люди, которые используют медленное программирование, уже с опытом. Поэтому и используемые конструкции в коде могут быть более сложными (и сами алгоритмы, взаимосвязи и т.д.), что требует определённых знаний и умений от того, кто будет дальше этот код расширять.

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

Примечание: Естественно, существуют различные варианты в стиле "что-то быстро, что-то медленно" и так далее, но в данном обзоре речь про общий смысл подходов.

Также вам могут быть интересны следующие обзоры:

1. Почему в ИТ мелочи могут требовать много времени и сил?

2. Что такое объектно-ориентированное программирование (ООП)?

3. Правила написания кода: сложные или простые конструкции использовать?

4. Универсальное или уникальное решение: что лучше?

5. Когда универсальность не подходит.

6. Оценка интерфейса или о чем говорит внешний вид.

7. Почему очевидные решения не всегда подходят?

8. Сочетание функциональности и интерфейса.

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!