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

«лишь один из паттернов разработки объективным», суть не меняется.

Не забывай корректоры принимать. Аминазин там, вот это вот все.

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

Не забывай корректоры принимать. Аминазин там, вот это вот все.

Ты себя ещё и дохтором возомнил, буйная фантазия однако у тебя.

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

Ну я то могу быть тупым, но разве может быть тупым гугл и дипсик?

Считаешь себя тупее АИ?

А как ум связан со знаниями того или иного?

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

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

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

Девопсы не бывают инженерами?

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

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

А что такое предметная область DevOps?

  1. Написание Yaml/JSON конфигов для обеспечения СI/CD и Docker/K8s.
  2. Написание Bash скриптов для автоматизации различных действий по установке и развертыванию.

Когда девопсы гордо заявляют что используют Go они имеют ввиду что используют программы, написанные на Go: Docker, K8s, Prometheus, Helm, Terraform и тд. Сами они обычно ничего на Go не пишут.

Obezyan
()

Вернёмся к теме.
Ты спросил у ЛОРа сколько стоит.
ЛОР тебе ответил.

Лоровский аналитики пришли к консенсусу, что ТВОЙ

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

ничего не стоит.
(Мнение отдельных эстетов, что ценность твоего «продукта» отрицательная, мы исключаем из рассмотрения как избыточно богемное.
Формальная причина: не предоставлен валидируемый метод определения модуля указываемой величины.)

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

Всё это вместе является безусловными признаками опередившего свою эпоху непризнанного Гения.

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

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

Когда девопсы гордо заявляют что используют Go

Да если бы и писали, то IMHO гордиться особо нечем, потому что Golang по своим языковым возможностям не сильно лучше Bash, этакий «Bash на стероидах» ?

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

Поэтому наверно вакансии девопсов нередко называются девопс-инженерами?

Это попытка возвыситься, не более. 90% девопсов не имеют отношения ни к инженерам, ни к программистам.

Инженер это высшая техническая ступень развития ИТ специалиста. Выше девопсов, синьоров, лидов и архитектов.

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

ничего не стоит.

А кодочасы стоят?

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

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

Да если бы и писали, то IMHO гордиться особо нечем, потому что Golang по своим языковым возможностям не сильно лучше Bash, этакий «Bash на стероидах» ?

Так думает множество девопсов и это нормально, тк они не программисты. На самом деле Go в разы мощнее Bash в той сфере для которой он был написан: обработка множества конкурентных сетевых соединений при достаточно небольшой когнитивной нагрузке на разработчика. Достаточно понять горутины, контекст/defer, каналы и уже можно писать вполне себе сетевой код под неплохую нагрузку.

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

Выше … лидов и архитектов.

Смутно представляю себе таких персонажей НЕинженерами, вернее даже не представляю, по крайне мере за пределами распильного ИМБУРДе.

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

Софтовая параллельность хорошая, не спорю.

Но в качестве ООП языка программирования даже VB.NET намного интереснее. C# и Haxe тоже неплохи. А Golang - IMHO эффективный баш на стероидах, компилируемый в нативные сборки.

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

Это угол зрения девопса на текущее положение вещей.

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

Поциент свято уверен

У него собственно в профиле весь анамнез, в том числе это: «При подсчёте для биллинга написанных мной строк кода учитываются только уникальные строки кода, написанные мной самим.» (C)

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

У него собственно в профиле

Зачем я на это посмотрел...

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

Точно так же можно сказать, что недобросовестные кодеры и/или бодишопы могут накручивать кодочасы?

Будут, непременно будут. Только кодочасы - штука объективная. Методы его учёта существуют и, в случае работы в офисе, довольно надёжны. А вот что такое качественный отлаженный DRY код в предметной области DevOps, соответствующий всем паттернам, best practices(с), знаешь только ты. И только ты этот такой код пишешь.

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

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

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

Сейчас модно называть инженерами всех подряд.

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

У него собственно в профиле весь анамнез,

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

«При подсчёте для биллинга написанных мной строк кода учитываются только уникальные строки кода, написанные мной самим.»

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

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

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

И вадддовский чугуний?

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

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

Очень грустно, что я трачу своё время на общение с теми, кто не знает даже таких основ.

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

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

Сложность IaC кода намного более однородная, как можно не понять это на протяжении всего обсуждения этой ветки?

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

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

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

Набыдлокодить максимально быстро, что там внутри - вообще никого не парит.

Типичный быстломенеджер быстлободишопа для быстлопроектов в распильном быстло имбурде?

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

Там, где сложность продукта однородна - всегда рано и поздно ставится машина.

Однородность сложности - не показатель возможности полной автоматизации. Посмотри хотя бы на однородные галюны АИ в однородно простейших задачах по Terraform и Ansible.

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

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

В таком контексте, учёт строк кода — это просто механизм биллинга, а не мотивация писать больше. Если правильно настроить этот процесс, то можно создать систему, где:

  1. Качество ценится выше количества: Разработчик получит больше за меньшее количество высококачественных строк, которые решают задачу эффективно. Потому что если он будет делать некачественный код, то просто уйдёт с такого проекта на другой намного менее оплачиваемый.

  2. Компактность поощряется: Если ставка за строку кода достаточно высока и учитывает качество, инженер действительно заинтересован в написании компактного решения.

  3. Автоматизация стимулируется: Хороший DevOps-инженер, создавший эффективную автоматизацию в 50 строк вместо 200, должен получить справедливое вознаграждение за ценность, а не за объём.

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

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

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

отрицание, гнев, торг, депрессия, принятие моего способа учёта для биллинга

Несколько практических идей для продвижения такой концепции:

  1. Разработать четкие критерии качества для оцениваемого кода — возможно, через систему автоматизированных проверок и ревью

  2. Создать прозрачную формулу расчета, учитывающую не только количество строк, но и их сложность, коэффициенты переиспользуемости, покрытие тестами и т.д.

  3. Провести пилотный проект с добровольными участниками, где параллельно вести учет по часам и по строкам кода, чтобы на практике сравнить результаты

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

Особенно хорошо это подходит для стандартизированных задач в IaC, но для её принятия сообществом потребуется время и доказательство эффективности на практике. Как и с любыми инновациями, сначала идет сопротивление (как мы видим в обсуждении), и лишь затем — возможное принятие.

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

про VB.NET уязвимости годами не правились, понимаю сейчас не так, но всёравно мёртвая технология.
C# + mssql тормоз не сравнимый с php+mysql.
Golang на мелких задачах (но нагруженых) показал себя великолепно, но есть минусы.
как ты можешь Golang с bash сравнивать?
Вопрос к devops на практике ты их использовал сравнивал, или только на курсах С# изучил?

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

про VB.NET уязвимости годами не правились,

Пруфы?

C# + mssql тормоз не сравнимый с php+mysql.

Шарп генерит код, который выполняется в десятки раз быстрее пыха.

А на кой ты СУБД сюда притащил в сравнение? Пых может работать с MSSQL и шарп может работать с мускелем.

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

Разве я спорю, что на Golang получается неплохой системный софт? Я лишь акцентирую внимание на IMHO неудачном синтаксисе Golang и его относительно слабых языковых возможностях по сравнению с полноценными ООП языками типа C#, Scala, etc.

как ты можешь Golang с bash сравнивать?

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

Вопрос к devops на практике ты их использовал сравнивал, или только на курсах С# изучил?

Вопрос непонятен, он про DevOps или про C#?

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

====

Качество ценится выше количества: Разработчик получит больше за меньшее количество высококачественных строк, которые решают задачу эффективно. Потому что если он будет делать некачественный код, то просто уйдёт с такого проекта на другой намного менее оплачиваемый.

А кто оценивать будет?

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

Я имел ввиду «эффективных» менеджеров. В той истории были именно они.

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

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

  1. Кто определяет качество написанной строки?
  2. Кто определяет что код максимально компактен и эффективен?
  3. Что делать если заказчик для оценки первых двух пунктов наймет другого специалиста который не будет считать ваш код качественным и эффективным?
Obezyan
()
Ответ на: комментарий от frob

То есть, сам пишешь код, сам ставишь ему оценку? Потом отдаешь клиенту и говоришь «Вот идеальный код, плати»?)

У меня в жизни была такая ситуация один раз. Бывает, что есть какой то интересный проект и я засиживаюсь в офисе до поздна, до 1-2 часов ночи. И пару раз такое было, что приезжал генеральный и с кем то ругался по телефону. И вот один раз такой диалог был, что мол: «Мы вам заплатили, вы месяц не появлялись, а теперь прислали 20 строк кода. Вы месяц эти 20 строк писали?». Ну и всё это на повышенных тонах было. Я домой приехал, жене рассказал. А она мне говорит: «Ну если эти 20 строк полностью выполняют бизнес задачу, то че не так?».

А что такое качественный код в контексте DevOps?

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

То есть, сам пишешь код, сам ставишь ему оценку?

Нет, ты не понял.
Топик-стартер сам пишет код и сам ставит ему оценку.

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

Пруфы?

гули сам ключевые слова: посмотреть код .asp 7лет исправляли, испаравили ещё веселее стало .

А на кой ты СУБД сюда притащил в сравнение? Пых может работать с MSSQL и шарп может работать с мускелем.

Абсолютно согласен база самое слабо место, но специалист с ней сделал, и разработчик C# (ms) во всю за такую сцепку воюет-обучает (ему же лучше знать с чем лучше работать). что говорит о разработчиках и разрабатывающих на C#. И как не странно не смотря на свою кривость сцепка php+mysql по потокам, памяти, задержкам самая крутая: php может быть плох, mysql плох, но затраты на сцепку самые минимальные, тот же C# много лишних потоков семофоров при работе с mysql плодит.

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

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

Сложные ООП абстракции нужны и встречаются только в двух случаях, в разработке GUI и игр, в остальных местах за это по рукам бъют, нужное от ООП в Golang есть, хоть адепты го это отвергают, да и абстракции в принципе реализуемы. В го есть сильные недостатки, и думаю с его популярностью костыли запилят.

Я знаю, что много не знаю, и большая вероятность что вам много известно, что мне не известно. Но безаппеляционность и шаблонность характерезует.

s-warus ★★★★
()
Последнее исправление: s-warus (всего исправлений: 2)
Ответ на: комментарий от Obezyan

Что делать если заказчик для оценки первых двух пунктов наймет другого специалиста который не будет считать ваш код качественным и эффективным?

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

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

код .asp 7лет исправляли, испаравили ещё веселее стало .

ASP или ASP.NET? И причём тут ЯП VB.NET?

что говорит о разработчиках и разрабатывающих на C#.

Интересное применение квантора все. Получается, все шарповые разработчики одинаковые?

И как не странно не смотря на свою кривость сцепка php+mysql по потокам, памяти, задержкам самая крутая: php может быть плох, mysql плох, но затраты на сцепку самые минимальные, тот же C# много лишних потоков семофоров при работе с mysql плодит.

Опять же нужны пруфы.

самый простой язык это ассемблер

Простой для чего?

если уж сравнивать то с C# инфраструктура, отладка, компилируемость похожи.

Речь была о языковых возможностях в контексте ООП, наследования и т.п.

Сложные ООП абстракции нужны и встречаются только в двух случаях, в разработке GUI и игр, в остальных местах за это по рукам бъют

Почему?

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