Количество строк кода (англ. Source Lines of Code — SLOC) — это метрика программного обеспечения, используемая для измерения его объёма с помощью подсчёта количества строк в тексте исходного кода. Как правило, этот показатель используется для прогноза трудозатрат на разработку конкретной программы, либо для оценки производительности труда уже после того, как она написана.
Скачать файл
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP и т.д.). Поддерживаются серверные и файловые базы, управляемые и обычные формы. Может выполнять свертку сразу нескольких баз данных и выполнять их автоматически без непосредственного участия пользователя.
Решение в Реестре отечественного ПО
Инструмент, позволяющий абсолютно по-новому взглянуть на процесс разработки печатных форм. Благодаря конструктору можно значительно снизить затраты времени на разработку печатных форм, повысить качество и "прозрачность" разработки, а также навести порядок в многообразии корпоративных печатных форм.
Инструмент для написания и отладки кода в режиме «1С:Предприятие». Представляет собой консоль кода с возможностью пошаговой отладки, просмотра значений переменных любых типов, использования процедур и функций, просмотра стека вызовов, вычисления произвольных выражений на встроенном языке в контексте точки останова, синтаксического контроля и остановки по ошибке. В консоли используется удобный редактор кода с подсветкой, контекстной подсказкой, возможностью вызова конструкторов запроса и форматной строки.
Расширение позволяет без изменения кода конфигурации выполнять проверки при вводе данных, скрывать от пользователя недоступные ему данные, выполнять код в обработчиках. Не изменяет данные конфигурации, легко устанавливается практически на любую конфигурацию на управляемых формах.
Разработка Конструктор автоматизированных рабочих мест "Конструктор АРМ" реализована в виде расширения и является универсальным инструментом для создания АРМ любой сложности в пользовательском режиме.
(4) вообще то не предполагалось привязывать количество строк кода к эффективности работы программистов, есть много примеров, когда один прогер одной строчкой сделал качественнее решение, чем второй 1000ей
и вообще: "Эксперименты многократно подтвердили тот факт, что данная метрика хорошо коррелирует с трудозатратами — программы с большим количеством строк кода требуют больше времени на разработку." из ссылки в топике
"вообще то не предполагалось"
пачка перфокарт, составляющая программу, обладала вполне видимым объёмом, по которому менеджеры могли судить о производительности работы программистов
(7) такое ощущение, что это Ваша больная тема... в общем спорить не буду, я создал простенький инструмент, мне он был полезен, решил поделится... пусть каждый сам решает как им пользоваться 8-)
Разработчики очень сообразительны в этом отношении. Что бы вы ни пытались измерить, они найдут способ оптимизировать этот показатель, и вы никогда не получите именно то, чего пытаетесь добиться.
Роберт Остин (Robert Austin) в своей книге "Измерение и управление производительностью в организациях" (Measuring and Managing Performance in Organizations) пишет, что существует два этапа внедрения новой метрики для измерения производительности. Сначала вы получаете то, что хотели, потому что никто пока не понял, как обмануть систему. На втором этапе вы получаете нечто худшее, чем то, с чего начинали, потому что все будут обманывать систему, чтобы максимизировать измеряемый показатель, даже рискуя погубить компанию.
Хуже того, менеджеры, использующие экономическую мотивацию, думают, что они смогут избежать такой ситуации, просто улучшая метрики. Доктор Остин заключает, что вы не можете этого сделать. Это никогда не срабатывает. Не важно, как сильно вы стараетесь адаптировать метрики к тому, что вы хотите достигнуть, это всегда срабатывает против вас.
Самая большая проблема с управлением методом экономической мотивации, однако, в том, что это вообще не управление: это больше похоже на отречение от управления. Добровольный отказ от попытки понять, как можно сделать ситуацию лучше. Это признак того, что руководство просто не знает, как научить людей лучше работать, так что оно вынуждено заставлять сотрудников самих придумывать, как улучшить ситуацию.
Слишком сложно. Меня как-то попросили посчитать количество строк кода в конфигурации. Я задал поиск во всех текстах точки с запятой. Через 15 минут дал ответ. Всё.
Кстати, в результате моей деятельности количество строк кода в конфигурации иногда уменьшается.
(9) еще раз говорю, это не оценка производительности программиста, а оценка проекта... Ничо, что точка с запятой далеко не в каждой строчке используется?
(11) >> еще раз говорю, это не оценка производительности программиста, а оценка проекта.
Вот как раз и посчитали примерный размер проекта.
>> Ничо, что точка с запятой далеко не в каждой строчке используется?
В таком случае как ты отличаешь конструкцию
Если Петрович = Вор Тогда
СообщениеНачальству = "Петрович занимается приписьками и с этим ничего сделать не получится"
Иначе
СообщениеНачальству = "Петрович знатный работник"
КонецЕсли;
Показать
От кода
СообщениеНачальству = ?(Петрович = Вор, "Петрович занимается приписьками и с этим ничего сделать не получится", "Петрович знатный работник");
Подсчётом точек с запятой эти два фрагмента дадут один результат. Подсчётом количество строк ты в первом случае получишь 9 строк, а во втором одну строку. А функционально куски одинаковы.
Как мыслишь решать проблему? И надо ли её решать?
tango абсолютно прав говоря что подсчёт строк кода это очень условный показатель, который может сработать только раз.
Я подозреваю что 1Сники в типовых конфах специально вставляют пустые строки чтобы увеличить количество строк. Ибо читаемость кода от этого ухудшается.
(12) в твоем примере в первом коде 0 точек с запятой, во втором 1, а, нет увидел... вот тока в первом фрагменте я б 3 точки с запятой поставил
Пустые строки очень хороший инструмент для разграничения функциональных блоков в коде, я считаю, что без них читать код в разы сложнее.
если я буду планировать новый проект, то могу примерно оценить трудозатраты, оценив метрики предыдущих проектов. ни о каком показателе типа "ты написал в этом месяце меньше нормы на 100 строк, премию не получишь" речи тут не идет! Мне, например, просто нравится оценивать количество строк текущего проекта раз в месяц и сравнивать с другими моими проектами...
(13) >> в твоем примере в первом коде 0 точек с запятой, во втором 1
В обоих по одной строке. В первом фрагменте точка с запятой стоит после КонецЕсли
>> Пустые строки очень хороший инструмент
Всё хорошее хорошо в меру, а не как в некоторых типовых конфах.
Однако любой метод даёт лишь приблизительное представление о сложности. Например алгоритм рисования круга в 10 строк в институте разбирается две пары. И это правильно.
(13) "оценить трудозатраты"
ну дык...
Софтверные компании обычно премируют программистов которые (a) пишут много кода и (b) исправляют много багов. Лучший способ продвинуться в такой организации — это писать как можно больше неряшливого кода и потом исправлять все эти ошибки, вместо того, чтобы потратить время и в первую очередь подумать, как сделать грамотно. Если вы попробуете исправить эту проблему с помощью штрафа за баги, то вы создадите повод скрывать баги, или не говорить тестерам о только что написанном коде в надежде на то, что найденных багов будет меньше. Таким образом выиграть нельзя.
Я вообще считаю, что нельзя оценивать работу программиста по количеству строк кода. Это вредно для самой программы. Например, 1-й программист пишет код сразу после получения задания и выдает прогу в 1000 строк кода, который жутко не оптимизирован, при этом 2-й вначале хорошо подумает и осмыслит структуру программы и напишет 100 строк оптимизированного кода, при том, что программы будут выполнять одно и то же. Одна из моих программ в былое время претерпела 2 таких оптимизации, при этом стала быстрее работать, а количество строк кода уменьшилось раз в 15.
Не вижу пользы. Но минус пока ставить не могу. Производительность мало связана с количеством кода. Например то, что например в семерке требовалось кодировать, то в восьмерке рализвано на уровне платформы, а в 8.2 и того более - "управляемое приложение". Кодирование идет на уровне глобальных процедур и функций, их можно "просчитать" и в Конфигураторе.
Если для групповой работы, то обычно за свою подсистему - отдельный спец отвечает. Как эта обработка отслеживает подсистемы?
(24) Да ну. Может стоит тогда выгружать всё, а в таблице группировать количество строк по подсистемам. Но, повторюсь, что количество строк для писателей - оценка их труда, но никак не программистов. Внедренец вообще может не менять код, а результат - есть: довольный клиент.
(25) не вижу смысла потратить кучу времени на бесполезные фишечки, которые и так легко обходятся.
Нужно было подсчитать колво строк в проекте, я написал инструмент за 15 минут, выложил его для тех, кому он может быть пригодится, а тут срач начался по поводу производительности и эффективности...
Не понимаю, зачем нападать на автора. Он несколько раз сказал, что это подсчет строчек кода, а не расчет производительности.
Кстати, так же глупо измерять производительность в потраченном времени. По тем же причинам (возможность влиять на показатели). Но большинство ежедневно совершают эту глупость.
Оценивать трудозатраты можно по разному. Могу предложить десяток вариантов. Для кого может такой оценкой является количество выкуренных сигарет. Но это не важно.
Если программист запланировал получить за выполненную работу N рублей, он постарается ее получить. В свою очередь работодатель хочет заплатить не больше M рублей. Если N <> M люди торгуются, вот и вся хитрость.
Но есть несколько "но".
1) И тому и другому необходима начальная сумма от которой нужно начать торговаться.
2) Работодатель хочет знать порядок сумм (т.е количество ноликов) при расчете до начала работы.
Не хочу описывать все "но", только во всех случаях нужна, пусть косвенная, пусть не точная, но оценка. Большинство из вас имеет образование связанное с математикой. Есть куча мат. методов где результат получается рекурсивными методами, постоянно уменьшая погрешность. Так считайте "количество строк кода", "количество часов" или "количество выкуренных сигарет" первым приближением этой задачи. Это первое приближение может изменится в результате как в одну, так и в другую сторону. Но это уже отдельный разговор.
Любопытно. ВОт интересный показатель. Подрабатываю фрилансом на Абоненской плате (определенное количество часов) так вот поставил условие что я не озвучиваю стоимость разработок но говору примерно сколько это часов (включая обучение нововведениям) А вот поддержка (исправления переписка и иное где мог ошибится - бесплатно) (изменение функционала по просьбе заказчика не в счет). Итак я теперь трачу больше времени но чем меньше я ошибаюсь и точнее и понятнее обучаю тем меньше трачу свое время. как результат могу просто приходить порой за оплатой. Мотивацией работы должно быть именно желание писать хороший код. В человеке заложено желание меньше работать и больше получать. А менеджеров учат добиваться обратного. НО формула КАЧЕСТВО = (ВРЕМЯ* УМЕНИЯ*МОТИВАЦИЯ)/затраты на исправление ошибок (*сильно упрощено) работает и мы можем лишь изменять некоторые показатели замещать другими но результат один.
Пример наш любимый apple (традиционное качество) НО ка только попадается партия хреново зделанного рейтинг (читай качество) резко падает потому как востановление репутации - ремонт- отзыв продукции
это огромные вложения.
С другой стороны АК (автомат калашникова ну извините очень яркий пример) выносливость и простота даже с учетом хреновой точности за счет потраченного на разработку времени и знаний и умений конструктора + мотивация (патриотизм тоже мотивация- это для новейшего поколения которое в мотивациях ограничено) = очень качественный массовый продукт.
(31) Не читал чесно говоря. Но почитаем, мысли человека который придерживается той же точки зрения могут укрепить уверенность и раздуть самомнение :D .
А на самом деле вопрос программирования все таки в случаях с разработкой качественых программ должен относится к сфере творчества а не к сфере производства (ну покрайней мере для программиста).
С 1С-ке может это и "показатель" крутости, но вот в однокристальных микропроцессорах всего 64Кб памяти под программу(если повезет), и нужно очень оптимальные алгоритмы писать дабы поместится в это ограничение.