Статьи

Почему LOC является избыточным способом расчета производительности

Декабрь 26, 2018

На протяжении всей моей карьеры, которая начинается с 10-го года коммерческого программирования, всего 15 лет, меня всегда засыпали технические директора и «хорошие» программисты, которые хвастаются, что их продукт имеет x количество строк. Иногда 100 000, а иногда и миллионы. И наивно, я бы всегда говорил «ВАУ», это много кода. И не раз я просматривал код и думал WTF !!!

 

Эта проблема

Прежде всего позвольте мне сказать, что, комментируя строки кода, которые вы пишете для проекта, найдутся люди, которые все равно будут поражены тысячами и тысячами строк кода. Я имею в виду, что круче: «Наш продукт находится в разработке в течение 10 лет и имеет 1 миллион строк кода» или «Наш продукт находится в разработке в течение 10 лет и имеет только 100 000 строк кода».

От летучей мыши большинство из вас сказали бы, вау круто, первое намного лучше, чем второе. Но вот в чем подвох. Давайте возьмем следующие критерии.

  • Насколько сложна система. 
  • На каком языке написана система.
  • Является ли это интерфейсной или серверной системой.
  • Какие API мы используем.
  • Взаимодействует ли это с персистентностью экземпляров
  • Каков был уровень программистов, которые были вовлечены в проект на протяжении его жизни?
  • и т. д.

 

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

 

Старый мир

Много языка, служит цели. Под этим утверждением я подразумеваю, что у каждого языка есть своя цель и сильная сторона. Вы используете язык, для которого он был разработан. Я мог бы быть намечен для этого, и это ни в коем случае не очень краткий пример.

 

  • Для обработки текста используйте Perl или Python.
  • Для размера и скорости используйте C или C ++ (очевидно, ASM был бы лучше, но время разработки прошло бы через крышу)
  • Для быстрой разработки приложений и создания прототипов используйте Java или .Net.
  • Для веб-приложений используйте Ruby on Rails.
  • Для веб-сервисов Java.

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

Но тут приходит загадка. Как и большинство из этих языков не могут или не любят быть использованы друг с другом. Я имею в виду, что вы, вероятно, могли бы использовать веб-сервисы Java с Ruby on Rails и т. Д., Но это подрывает целостность программы, не говоря уже о том, что через некоторое время управление различными языками в системе становится кошмаром. Поэтому разработчики создают вызовы API, чтобы удовлетворить их потребность делать то, что делал бы другой язык. Для некоторых из этих языков потребуется 10 строк кода, чтобы сделать то, что мог сделать язык 4 поколения в 5 строк.

 

Новый мир

В последнее время был большой толчок к созданию языков, которые потребовали бы меньше кода для выполнения задачи. Это сделало программирование по большей части проще и программистам более продуктивным. Простым примером будет простая программа hello world.

Scala 

object HelloWorld extends Application {
   println("Hello, world!")
}

 

Ява 

public class HelloWorld {
   public static void main(String ... args) {
      System.out.println("Hello world!");
   }
}

 

Теперь это очень простой пример того, как сохранить некоторые строки кода, используя некоторые новые языки. Однако проблема здесь в том, что в некоторых случаях вам придется расширять новый язык, чтобы реализовать некоторые функции, которые уже есть в старых языках. Что бы добавить строки кода снова. То же самое можно сказать при преобразовании программ на C или C ++ в Java. У меня болит мозг.

 

Уровень программиста

Итак, теперь, когда мы видим, что, используя разные языки, мы можем сохранить много строк кода, следующий логический шаг в уравнении: уровень вашего кунг-фу. Являются ли разработчики, написавшие эту систему из 1 миллиона строк, лучшими из лучших?

Давайте снова возьмем простой пример. 1 способ сделать то же самое.

Новичок (только для демонстрационных целей) 

public void novice() {
        int i = 0;
        int maxLoop = 10;
        int printAt = 5;
        while (i < maxLoop) {
                String word = "";
                if (i == printAt) {
                        word = "Booyakasha";
                } else {
                        word = "Yakashaeboo";
                }
                System.out.println("Hello world : " + word);
                i++;
        }
    }

 

Средний (только для демонстрационных целей) 

public void intermediate() {
        int maxLoop = 10;
        int printAt = 5;
        for (int i = 0; i < maxLoop; i++) {
                String word = i == printAt ? "Booyakasha" : "Yakashaeboo";
                System.out.println("Hello world : " + word);
        }
    }

 

Эксперт (только для демонстрационных целей) 

public static void expert() {
        int maxLoop = 10;
        int printAt = 5;
        for (int i = 0; i < maxLoop; i++) {
                System.out.println("Hello world : " + (i == printAt ? "Booyakasha" : "Yakashaeboo"));
        }
    }

 

Пожалуйста, обратите внимание, что это не лучшие примеры, но вы понимаете суть. Более высокий уровень программиста сделает методы более простыми и использует меньше строк кода, чтобы прийти к тому же выводу для метода. В этом и заключается сложность через простоту. Поговорка, если я помню, звучит примерно так: сделать простую вещь сложной — легко, а сложной — легко. Или что-то вроде того.

 

Решение проблем

Это горячая тема прямо здесь. Во время написания кода большинство из нас потратит много времени на изучение способов реализации кода. Будь то, чтобы узнать, как работает API через чтение документов или поиск в Google, чтобы найти примеры того, как реализовать кусок кода.

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

И это, друзья мои, нельзя учесть в строках кода. Не говоря уже о том, что при написании кода, глядя на некоторые примеры, видя, что то, что вы сделали для последних 100 строк, неправильно, удаляя все это и начиная с нуля, 2 или 3 раза. Каждый раз набирает от 50 до 100 строк кода, но когда дело доходит до фактической фиксации вашего кода, это всего 20 строк. Так сколько была ваша производительность? 150 строк? 200 строк? 20 строк? Это действительно трудно вычислить, если вы не используете какой-то суперский счетчик символов, который тоже знает комментарии из реального кода, потому что комментарии на самом деле не являются кодом.

 

Вывод

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

 

43
Share: