LINUX.ORG.RU
ФорумTalks

Стоимость строки кода в разных регионах и на удалёнке

 


0

1

Вопрос в контексте Agile разработки по ТЗ, которое может изменяться по ходу проекта. Нередко используют почасовую оплату за потраченное разработчиком время, а я предлагаю вместо этого в контексте поставленной задачи осуществлять биллинг за проделанную работу с помощью учёта количества строк кода, написанного для решения задачи.

Как думаете, сколько стоит качественный отлаженный DRY код в предметной области DevOps, соответствующий всем паттернам, best practices и т.п.?

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

Преимущества учета стоимости кода по количеству написанных строк в Agile-проекте

Учет стоимости кода по количеству написанных строк – подход, который периодически обсуждается в IT-среде, в том числе и в вашем прикреплённом обсуждении. Хотя в современной разработке этот метод считается спорным и не всегда применимым, у него есть определённые преимущества, особенно если речь идёт о специфических задачах (например, DevOps-скрипты, IaC, CLI-утилиты) и при правильной постановке процесса.

1. Прозрачность и простота расчётов

  • Лёгкость измерения: Количество строк кода – объективный, легко измеряемый показатель, который можно быстро получить с помощью инструментов анализа кода.
  • Понятная метрика для заказчика: Заказчик может видеть «осязаемый» результат работы, что важно для непогружённых в детали разработки людей.

2. Мотивация к эффективности

  • Фокус на результат: Такой подход мотивирует разработчика не растягивать задачи, а выдавать конкретный, измеримый результат.
  • Возможность сравнения: Можно сравнивать производительность между разными исполнителями или командами, если задачи типовые и стандартизированы.

3. Гибкость при изменении требований (Agile)

  • Простота пересчёта стоимости: При изменении требований (что часто бывает в Agile), можно быстро пересчитать стоимость, исходя из нового объёма кода.
  • Удобство для коротких итераций: В спринтах, где задачи дробятся на небольшие части, оплата по строкам может быть удобна для микрозадач (например, написание шаблонов, конфигов, скриптов).

4. Контроль качества (при правильной постановке)

  • Возможность учёта сложности: Если в стоимость строки закладывается качество (DRY, тесты, best practices), появляется стимул писать лаконичный и качественный код.
  • Быстрая оценка вклада: В проектах с большим количеством рутинных изменений (например, поддержка DevOps-инфраструктуры), этот подход позволяет быстро оценить вклад каждого разработчика.

5. Применимость к DevOps и инфраструктурным задачам

  • Стандартизированные задачи: В DevOps часто встречаются задачи, где результат – это скрипт или конфиг, и их объём хорошо коррелирует с трудозатратами.
  • Меньше риска «раздувания» кода: Если стоимость строки высокая и есть контроль качества (ревью, автоматические проверки), разработчики заинтересованы писать компактно и эффективно.

Важно!

  • Подход не универсален: Для сложных R&D-задач, архитектурных решений, оптимизаций, где ценность кода не в количестве, а в качестве и уникальности, этот метод не подходит.
  • Риски злоупотреблений: Без контроля качества возможен «честинг» – искусственное раздувание кода, копипаст, бессмысленные строки.
  • Лучше использовать в сочетании с другими метриками: Например, с оплатой за закрытие задач, code review, покрытие тестами и т.п.

Вывод

Учет стоимости кода по количеству строк может быть полезен в узких случаях – для стандартизированных, повторяющихся задач, особенно в области DevOps и инфраструктуры, при условии жёсткого контроля качества и прозрачных критериев оценки. В рамках Agile такой подход может упростить биллинг и сделать процесс более предсказуемым для обеих сторон, однако его не стоит рассматривать как универсальное решение для всех типов проектов.



Последнее исправление: sanyo1234 (всего исправлений: 5)
Ответ на: комментарий от sanyo1234

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

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

Пусть предложит более качественное решение, в котором количество строк кода меньше в разы, а не на 10%.

Возможно не сможет предложить даже и с большим количеством строк кода.

sanyo1234
() автор топика
Ответ на: комментарий от lenin386

Зачем в разы? Почему не на 10%? Это откуда такое число взялось?

Затем, что 10% обычно ничего не решают как по количеству строк кода, так и по дедлайнам.

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

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Затем, что 10% обычно ничего не решают как по количеству строк кода, так и по дедлайнам.

А вот 10% оплаты - решают! Если я зарабатываю 100 тыщ, 90 отдаю за коммуналку, то 10 тыщ у меня остаётся на водку. А если я зарабатываю 110 тыщ, то на водку у меня останется в 2 раза больше, и я буду ужираться каждый день!

lenin386 ★★★★
()
Ответ на: комментарий от sanyo1234

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

lenin386 ★★★★
()
Ответ на: комментарий от lenin386

IMHO 10% для количества строк - показатель несущественный.

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

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 4)
Ответ на: комментарий от sanyo1234

Пусть предложит пруфы для каждого дефектного фрагмента.

Он прикладывает и помимо пруфов требует с вас оплату специалиста который потратил время чтобы предоставить эти пруфы. Те вы не только не заработали, вы еще и должны.

Obezyan
()
Ответ на: комментарий от sanyo1234

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

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

IMHO 10% для количества строк - показатель несущественный.

Падажжите, вы выше постоянно писали о КОМПАКТНОСТИ решения. А тут уже одна десятая несущественна. Вы там определитесь уже.

Obezyan
()
Ответ на: комментарий от Obezyan

Он прикладывает и помимо пруфов требует с вас оплату специалиста который потратил время чтобы предоставить эти пруфы.

Это договором определяется. Можно ревьюить рандомно (реально по RND, а не выборочно вручную) 5-10% и закладывать это в стоимость (строк кода, например) заранее.

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от Obezyan

Вот пруфы, мы вам ничего не должны за него, а вы нам должны за услуги стороннего специалиста по проверке вашего неоптимального кода.

Это определяется договором, а не сиюминутными хотелками или эмоциями.

sanyo1234
() автор топика
Ответ на: комментарий от Obezyan

Падажжите, вы выше постоянно писали о КОМПАКТНОСТИ решения. А тут уже одна десятая несущественна. Вы там определитесь уже.

Я не исключаю, что кто-то другой может делать компактнее на 10% и дороже в 2 раза, или компактнее на 50% и дороже в 10 раз.

Речь о стремлении исполнителя к компактности кода, а не его абсолютной компактности.

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

Ну очевидно же, что код:

строка1 кода;
строка2 кода;

можно переписать как:

строка1 кода; строка2 кода;

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

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

А бывает ещё, что быстрая сортировка - 20 строк кода, а пузёрык - 5 строк кода. И ты заплатишь за пузырёк, а за быструю сортировку не заплатишь.

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от lenin386

А бывает ещё, что быстрая сортировка - 20 строк кода, а пузёрык - 5 строк кода. И ты заплатишь за пузырёк, а за быструю сортировку не заплатишь.

Уже много раз упоминал, что кастом IaC код, использующий готовый CNCF стек, для которого предлагается такой биллинг, обычно является алгоритмически несложным.

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Уже много раз упоминал

Зря распинаешься перед этими недоучками.
Обращайся напрямую в профильную организацию.

frob ★★★★★
()
Ответ на: комментарий от frob

Обращайся напрямую в профильную организацию.

Ты похоже напрямую оттуда вещаешь?

sanyo1234
() автор топика
Ответ на: комментарий от frob

Совет специализда из профильной организации:

Тебе следует серьёзно рассмотреть релокацию в Таджикистан. Прекрасная страна, замечательные люди. (Знаю не понаслышке – со многими познакомился в поезде «Москва-Душанбе»).

В Средней Азии — всплеск преступности. В Таджикистане за первый квартал 2025 года количество тяжких преступлений выросло почти на треть, грабежей стало больше на 43%, мошенничеств — почти на 40%. Для республики, где в последние годы царило относительное спокойствие, это тревожный сигнал.

https://cont.ws/@krestianin/3041479

sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

А что вас смущает? Весьма скоро бОльшая часть этой публики заявится в Россию, поэтому было бы разумно поменяться местами жительства с этими «товарищами».

Mischutka ★★★★★
()
Ответ на: комментарий от Mischutka

Чем ещё можно стимулировать реллокационную движуху? Прям сплошные изобретения и инновации.

sanyo1234
() автор топика

Это уже проходили… Я часто пишу код более компактный чем тот, что делает тоже самое. Но при твоем подходе наступит полный KISS как у финнов, когда они тупо копипастят код в разные места вместо использования функций и тп

rtxtxtrx ★★★
()
Ответ на: комментарий от sanyo1234

Покажите как в договоре будет описано определение качественной строки кода. Вы походу вообще не работали по договору.

Obezyan
()
Ответ на: комментарий от sanyo1234

Ещё один клоун в дохтора записался?

Да ИТТ уже поняли что ты клоун, не напрягайся зеркалить каждый пост от которого у тебя «не бомбит».

slackwarrior ★★★★★
()
Ответ на: комментарий от Obezyan

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

lenin386 ★★★★
()
Ответ на: комментарий от lenin386

Я в курсе, потому и подвожу договор к носу так сказать.

Obezyan
()
Ответ на: комментарий от sanyo1234

Относительно примитивный синтаксис Golang с низким порогом входа для ПТУшных вкатунов, сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.

Подразумевается, что на Golang не получится строить сложные ООП абстракции так же изящно с минимальными затратами на кодирование и минимальным количеством строк кода :) как на более полноценных ООП языках.

Хотя кому-то и на сишке хорошо программируется в т.ч. и создание на ней более высокоуровневых ООП языков. Только это не значит, что писать сложные проекты, требующие ООП подхода, на сишке так же просто, как на Scala и Шарпе, IMHO GObject из GNOME/GTK является ярким примером, как делать ненужно, впрочем как и сам гном в целом.

При всём уважении к C и попыткам реализовать на нём ООП-паттерны, результат часто получается довольно многословным и трудноподдерживаемым. GObject — прекрасный пример того, как внедрение ООП-концепций в язык без встроенной поддержки может привести к созданию громоздкой, избыточной системы, которую сложно понимать и с которой трудно работать.

Для проекта, где ООП-абстракции являются важными (например, сложная доменная модель с множеством взаимодействующих сущностей), выбор Go или тем более C с самостоятельно реализованным ООП действительно может оказаться неоптимальным — придётся написать значительно больше кода с меньшей выразительностью.
sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

Но в качестве ООП языка программирования даже VB.NET намного интереснее.

Традиционный ООП — non-goal языка Go.

Is Go an object-oriented language?

Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).

Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java.

https://go.dev/doc/faq#Is_Go_an_object-oriented_language

в качестве ООП языка … VB.NET намного интереснее

И да, на основании чего сделан такой вывод?

А Golang - IMHO эффективный баш на стероидах

Ага, а Java — это баш с классами.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

сложные ООП абстракции

Абстракции не должны быть сложными. Пример хорошей и успешной абстракции — это юниксовые open, close, read, write.

Сложная абстракция с одной реализацией — это не абстракция, а второстепенная особенность какой-то части системы.

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

сложные ООП абстракции на нём строить не получится, получится в лучшем случае Кубер.

Хотя я не могу подтвердить, я слышал, что код Кубера далёк от принятых норм Го, отсюда отторжение.

Как бы там ни было, никто не читает код Кубера. Все читают стандартную библиотеку. Приведи, пожалуйста, пример неудачных «сложных абстракций» в стандартной библиотеке.

В качестве примера могу предложить database/sql.

сложные ООП абстракции на нём строить не получится

На основании каких предпосылок сделан этот вывод? Каких средств недостаточно и есть ли пример ожидаемого результата?

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 9)

учёта количества строк кода, написанного для решения задачи

if (условие0){
some_function;
}
else if (условие1){
some_function;
}
else if (условие2){
some_function;
}
else if (условие3){
some_function;
}
...
else{
some_function;
}
aiqu6Ait ★★★★
()
Ответ на: комментарий от aiqu6Ait

Это пример того, что будут сдавать.

Если и будут, то только пытаться, ибо не соответствует критериям приёмки по качеству кода. А если такое будет повторяться от определённого исполнителя регулярно, то у него исчезнет и возможность даже для попытки сдачи любого кода.

Платить лучше всего за закрытую задачу.

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

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от kaldeon

И да, на основании чего сделан такой вывод?

На основании того, что VB.NET полноценно поддерживает ООП, в т.ч. наследование классов и полноценный Access Control для членов классов?

А ещё VB.NET поддерживает Exceptions, Default Arguments, Operator Overloading в отличие от Golang.

sanyo1234
() автор топика
Ответ на: комментарий от aiqu6Ait

Это ещё что. А как тебе такое, мистер Маск :

a++; a++; a++; a++;a++; a++; a++; a++;a++; a++; a++; a++;a++; a++; 
a++; a++; a++; a++;a++; a++; a++; a++;a++; a++; a++; a++;a++; a++; 
a++; a++; a++; a++;a++; a++; a++; a++;a++; a++; a++; a++;a++; a++; 
a++; a++; a++; a++;a++; a++; a++; a++;a++; a++; a++; a++;a++; a++;
a--; a--; a--; a--;a--; a--; a--; a--;a--; a--; a--; a--;a--; a--;
a--; a--; a--; a--;a--; a--; a--; a--;a--; a--; a--; a--;a--; a--;
a--; a--; a--; a--;a--; a--; a--; a--;a--; a--; a--; a--;a--; a--;
a--; a--; a--; a--;a--; a--; a--; a--;a--; a--; a--; a--;a--; a--;

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Если и будут, то только пытаться, ибо не соответствует критериям приёмки по качеству кода.

Тебе уже 255 раз говорили. Свои критерии ты придумал сам, и сформулировать их чётко не смог. качественный отлаженный DRY код в предметной области DevOps, соответствующий всем паттернам, best practices - это не формулировка, это лозунг. Получив какую-то определённую власть, ты можешь охренеть, и заставлять людей хоть в присядку голыми плясать. Но для этого, тебе надо либо платить столько, чтобы люди плясали, либо их как-то принудить. Скажи, почему люди пойдут к тебе работать за количество строк, которые надо минимизировать, а не пойдут работать куда-то ещё, где поменьше инноваций?

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

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

lenin386 ★★★★
()
Последнее исправление: lenin386 (всего исправлений: 3)
Ответ на: комментарий от lenin386

Приемлемо!

Неплохо было бы в смету оценку качества заложить. Кстати, как там трудозатраты считать?

aiqu6Ait ★★★★
()

И через 2 дня завандалил топик AI-высером. Своих мыслей, я так понимаю, так и не появилось, позвал старшего брата.

Dimez ★★★★★
()
Ответ на: комментарий от lenin386

Бред и читерство? Осталось сделать кодогенератор? Такой исполнитель с проекта будет снят, неужели непонятно?

Сообщения про подразумеваемую порядочность исполнителя и его качественный код успешно проигнорированы?

sanyo1234
() автор топика
Ответ на: комментарий от Dimez

Своих мыслей, я так понимаю, так и не появилось,

Тролль во всей красе. Мои ответы в ветке мыслями не являются?

sanyo1234
() автор топика
Ответ на: комментарий от lenin386

Свои критерии ты придумал сам, и сформулировать их чётко не смог. качественный отлаженный DRY код в предметной области DevOps, соответствующий всем паттернам, best practices - это не формулировка, это лозунг.

Не не смог сформулировать, а пока не пытался дать полную чёткую развёрнутую формулировку, лишь формировал отдельные её фрагменты своими ответами в топике.

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

Не могу, у меня есть определённые моральные принципы.

Но для этого, тебе надо либо платить столько, чтобы люди плясали, либо их как-то принудить.

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

Только идиот согласится на такой биллинг в 2025-м.

Только идиот будет писать с квантором «все».

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

Меня такие сотрудники (жулики) не интересуют.

Скажи, почему люди пойдут к тебе работать за количество строк, которые надо минимизировать, а не пойдут работать куда-то ещё, где поменьше инноваций?

Потому что некоторым противно работать с жуликами, кто занимался бы накруткой количества строк или часов?

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Эти ответы утопические и оторваны от жизни, руководитель-бегиннер детектед. Принципы, конечно, похвальны, но они из серии «мы будем всецело доверять всем клиентским данным и никогда их не будем проверять», первый же залетевший дятел испортит тебе сразу всё. Тебе пытаются это объяснить, а ты вместо того, чтобы слушать, бежишь на любой коммент советоваться с чатгопотой. Что тоже очень показательно.

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

бежишь на любой коммент советоваться с чатгопотой.

Опять троллинг? Далеко не на любой, а только для подведения итогов.

sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

Опять троллинг? «Не полностью, а всего на пол шишечки»

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

руководитель-бегиннер детектед.

Руководителем никогда не работал.

первый же залетевший дятел испортит тебе сразу всё.

Что он испортит в проекте в контексте построчного биллинга? Как залетел, так и вылетит (причём очень быстро), только и всего.

sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

Руководителем никогда не работал.

Оно и видно. И двадцатилетний опыт работы в ПФР тоже видно.

Dimez ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)