Что делает проект большим? [закрыто]

32

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

Я строю бартерную систему и до сих пор около 1000 строк кода для входа / регистрации. Несмотря на то, что есть много LOC, я бы не стал считать это большим проектом, потому что он не такой сложный, хотя это мой первый проект, поэтому я не уверен. Как это измеряется?

Джонатан
источник
2
Да ............ Чем больше сложность, тем больше строк кода.
Роберт Харви
3
Первый KLOC самый сложный ...
Далее вам нужно спросить: «Что делает проект сложным? Строки кода? Слои абстракции?»
Стивен Эверс
Вы упоминаете 1000 строк кода как «много». Это действительно ничего не значит без контекста. Я работал над несколькими проектами, в которых было более миллиона строк кода. Я также работал над тем, что я бы назвал «маленькими» проектами, которые имеют всего 50 000 строк или около того, но из-за сложности они не будут считаться «маленькими» из-за количества ресурсов, необходимых для разработки, кодирования, и проверить. Но по своему личному опыту я не могу вспомнить ни одного случая, когда я бы посчитал, что 1000 строк - это много. Я только упомянул это, чтобы обеспечить некоторую перспективу для вашего первого проекта. Удачи!
TMarshall
Я бы сказал, что "масштабность" проекта зависит от более чем одного фактора ...
kiwixz

Ответы:

20

Сложность.

Чем сложнее, тем сложнее узнать все в проекте.


источник
5
Это похоже на тавтологию ИМО. Сложная система является синонимом большой системы; если не говорить о сложности кода, и тогда вполне может быть, что все хорошо отделено и несет единственную ответственность, и в этом случае сложность кода может быть на самом деле ниже для больших проектов. Следовательно, сказать, что сложность означает, что проект большой, на самом деле ничего не сказать.
Хенрик
... или, естественно, любая другая мера сложности.
Хенрик
@Henrik, «сложная система» не эквивалентна «большой системе».
1
Нет, это синоним.
Хенрик
@ Генрик, я не согласен. Система может быть большой, но регулярной, т. Е. Многие вещи решаются практически одинаково, где вы можете предсказать, как все это делается, исходя из вашего опыта работы с остальной частью системы, и система может быть маленькой, но все же очень сложной.
34

Грубо говоря, как бы я все согласовал - имейте в виду, что это более или менее произвольно. «Размер» проекта в сочетании с другими факторами, такими как сложность, исходные строки кода, количество функций / ценность для бизнеса и т. Д. Очень маленький продукт может принести большую ценность и т. Д. При этом говорится:

  • 2m + sloc - большой проект. Как правило, они настолько сложны, что лишь немногие, если вообще люди, свободно владеют всей системой; скорее ответственность имеет тенденцию быть модульной по структуре кода. Эти проекты часто приносят огромную ценность для бизнеса и могут иметь решающее значение. Они также иногда испытывают серьезную нагрузку технического долга и других проблем, связанных с наследием.

  • 100к - 2м слок - это проект среднего размера. Это мой средний план: проект достаточно сложен, чтобы требовать определенных экспертных знаний, и, вероятно, накопил некоторую техническую задолженность; вероятно, это также приносит определенную ценность для бизнеса.

  • 10k - 100k - это небольшой проект, но не слишком маленький, чтобы иметь достаточно сложности, чтобы вам потребовалось экспертное рассмотрение; если вы с открытым исходным кодом, попробуйте привлечь людей, которым вы доверяете, для проверки ваших коммитов.

  • Все, что меньше 10 тыс. Слоков, крошечно, правда. Это не значит, что он вообще не может принести никакой пользы, и многие очень интересные проекты имеют очень крошечный отпечаток (например, Camping, чей источник ~ 2 кб (!)). Специалисты, не являющиеся экспертами, могут, как правило, решать проблемы, связанные с ценностями - исправлять ошибки и добавлять новые функции - без необходимости слишком много знать о предметной области.

Иосиф Вайсман
источник
4
Я бы проголосовал за это дважды, если бы мог. Числа, конечно, произвольны, но я думаю, что описания того, что подразумевают различные степени «размера», точны.
Эрик Андерсон
1
@EricAnderson Определенно проще думать об этом в терминах описаний, чем мера sloc. Программа 100k sloc Erlang легко на порядок «больше», чем программа 100k sloc C ++, основанная просто на том, что она делает, независимо от того, насколько просто код читать на более высоком уровне. В определенный момент чтение кода не так сложно, как просто вспомнить, что происходит внутри системы на высоком уровне, потому что есть так много функций и логических центров.
zxq9
@ zxq9 Я не согласен. Правда, это означает, что выбор языка может сделать большой проект меньше. То, что раньше использовалось для больших компьютеров, теперь слишком медленно, а то, что раньше было для больших программных проектов, может быть тривиальным в наше время. Что является неизменным, так это стоимость / сложность проекта. Хотя SLOC не является идеальным измерением, он все же тесно связан со стоимостью и сложностью программного проекта. Так же, как большие машины не обязательно лучше, так и большие программные проекты тоже не являются. Если возможно, разделите проект на независимые компоненты и выберите правильные технологии, чтобы сделать их еще меньше.
Юнвэй Ву
14

Размер проекта измеряется степенью неосуществимости.

mojuba
источник
2
Это пессимистично: D
Хенрик
.... а что за измерение есть?
Кейси Паттон
1
@Casey Patton - это буквально стоимость обслуживания.
Моджуба
12

Сложность, которую можно оценить несколькими способами:

  1. Бюджет. Проект с бюджетом более 10 000 000 долларов США, вероятно, сильно отличается от проекта, который, например, стоит менее 10 000 долларов США. Это может включать трудовые, программные, аппаратные и другие расходы, понесенные при выполнении проекта.
  2. Человеко-часы работы для завершения проекта. Это займет миллион часов или что-то еще? Это также можно рассматривать как фактор временной линии, когда некоторые проекты могут занять годы, которые, я бы сказал, были большими по сравнению с другими, что может занять меньше недели. Обратите внимание, что человеко-часы могут вводить в заблуждение, так как кто-то может подумать, удвоив персонал, так что над проектом работает вдвое больше, чем график, который можно разделить на две части, что, на мой взгляд, редко сработает.
  3. Количество оборудования, других систем и людей, использующих то, что строит проект. Если что-то привязано к 101 системе, то, вероятно, будет сложнее, чем если оно стоит отдельно и не привязано ни к чему другому.

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

JB King
источник
11

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

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

David_001
источник
1
Это может не быть хорошей мерой: требования к компиляторам и ядрам ОС могут быть непропорционально большими по сравнению с другими типами продуктов.
Моджуба
2
@mojuba: «Большой» - это достаточно широкий термин, я бы предположил, что написание компилятора или ОС было бы «большим» проектом
David_001
@ David_001: возьмите компилятор Turbo Pascal, например, чей двоичный размер в одной точке составлял 70 килобайт, и все же TP был полноценным объектно-ориентированным языком программирования. Мы никогда не видели исходников, но исполняемый файл размером 70 КБ не может быть большим проектом.
Моджуба
@ David_001: не то чтобы я с тобой не соглашался вообще. Любое определение «большого» проекта будет столь же расплывчатым, как и само слово «большой».
Моджуба
@mojuba: Когда я использовал Turbo Pascal, он вообще не был объектно-ориентированным.
Дэвид Торнли
4

Я бы измерил размер проекта по тому, насколько сложно увидеть весь проект как одну большую картину. Например, у меня есть исследовательская / прототипная кодовая база для проблемы машинного обучения, над которой я работаю. Это всего лишь 5 тысяч строк кода, но это похоже на огромный проект. Существует множество вариантов конфигурации, которые взаимодействуют непредсказуемым образом. Вы можете найти практически все шаблоны проектирования, известные человеку где-то в кодовой базе для управления всей этой сложностью. Дизайн часто бывает неоптимальным, потому что в процессе эволюции он сильно вырос и не подвергается рефакторингу так часто, как следовало бы. Я единственный, кто работает над этой кодовой базой, но я часто удивляюсь тому, как все взаимодействует.

С другой стороны, один из моих хобби-проектов имеет примерно в 3-4 раза больше кода, и все же он чувствует себя намного меньше, потому что это в основном библиотека математических функций, которые в основном ортогональны друг другу. Вещи не взаимодействуют сложным образом, и довольно приятно понимать каждую функцию изолированно. Легко увидеть общую картину в той мере, в которой она есть, потому что ее не так много.

dsimcha
источник
3

Произвольный ответ: Насколько велик проект, насколько вы хотели бы, чтобы он был сделан с использованием источников событий и SOA с самого начала. Или что авторы системы читали книгу Эвана «DDD: борьба со сложностями в основе программного обеспечения»;)

Хенрик
источник
2

Compexity & Scope

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

Требования

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

Недостаток CCMU

CCMU - это то, что я называю « Coo Ca Moo » (Четкое полное взаимопонимание). Вы должны иметь CCMU с вашим клиентом.

Если у вас небольшой проект с плохим CCMU, вы можете завершить проект 2,3,4 или более раз. Таким образом, простая 20-часовая работа превращается в 60-часовой проект с утомленным персоналом и очень недовольным клиентом.

Сфера Creep

Это случается чаще, чем вы думаете. Заказчик решает, что, поскольку вы уже делаете A, B & C, добавить D или даже F не составит труда, если это поведение не проверено, он также может превратить небольшой проект в проект среднего размера. И в зависимости от того, как менеджер по продажам продал работу, эти ожидания могут показаться «БЕСПЛАТНЫМИ» для клиента.

Майкл Райли - AKA Gunny
источник
1

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

Кавет Керек
источник
1

Сложность - правильный ответ, но как ее оценить?

Факторами являются:

  1. Количество точек расширения
  2. Количество уровней модулей (функции, классы, системы классов, библиотеки, общие библиотеки, приложения, сетевые приложения и т. Д.)
  3. Количество зависимостей (включая платформы)
  4. Особенности взаимозависимости.
  5. Необходимые ресурсы, не относящиеся к коду (включая графику / графику, сценарии управления - например, сценарии проектирования уровней - и другие ресурсы, необходимые для завершения версии приложения).

Чем их больше, тем сложнее проект.

Klaim
источник
0

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

В конечном счете, я думаю, что "масштабность" проекта трудно определить количественно. Это все равно, что спросить, как вы определяете, большая собака или нет. Мало того, что есть несколько способов его измерения (масса, объем и т. Д.), Но я лично не нахожу это очень полезным. Реальность такова, что мои критерии, вероятно, будут примерно такими: «Какова вероятность, что я убегу от этой собаки, если увижу ее в темном переулке?»

И, к сведению, я бы вообще не считал 1 тыс. Строк кода много. Было бы значительная часть кода, но это не было бы , что много в великой схеме вещей. Конечно, я полагаю, это зависит от языка. Например, 1k строк кода гораздо меньше кода на языке, подобном C, чем на языке, подобном Pyhon.

Джейсон Бейкер
источник