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

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

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

Сложность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Compexity & Scope

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

Требования

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

Недостаток CCMU

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

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

Сфера Creep

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

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

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

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

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

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

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

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

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