¿Qué hace que un proyecto sea grande? [cerrado]

32

Solo por curiosidad, ¿cuál es la diferencia entre un proyecto pequeño, mediano y grande? ¿Se mide por líneas de código o complejidad o qué?

Estoy construyendo un sistema de trueque y hasta ahora tengo alrededor de 1000 líneas de código para iniciar sesión / registrarme. Aunque hay mucha LOC, no lo consideraría un gran proyecto porque no es tan complejo, aunque este es mi primer proyecto, así que no estoy seguro. ¿Cómo se mide?

project Jonathan
fuente
2
Sí ... más complejidad significa más líneas de código.
Robert Harvey
3
El primer KLOC es el más difícil ...
A continuación, debe preguntarse "¿Qué hace que un proyecto sea complejo? ¿Líneas de código? ¿Capas de abstracción?"
Steven Evers
Usted menciona 1,000 líneas de código como un "lote". Eso realmente no significa nada sin contexto. He trabajado en varios proyectos que tenían más de un millón de líneas de código. También he trabajado en lo que llamaría proyectos "pequeños" que solo tienen 50,000 líneas más o menos, pero debido a la complejidad no se considerarían "pequeños" debido a la cantidad de recursos que requerían para diseñar, codificar, y prueba. Pero en mi experiencia personal, no puedo pensar en ningún caso en el que considere que 1,000 líneas son muchas. Solo menciono eso para proporcionar alguna perspectiva para su primer proyecto. ¡Buena suerte!
TMarshall
Diría que la "grandeza" de un proyecto depende de más de un factor ...
kiwixz

Respuestas:

20

Complejidad.

Mientras más complejidad, más difícil es aprender todo en el proyecto.


fuente
55
Eso es similar a una tautología imo. Un sistema complejo es sinónimo de sistema grande; a menos que hablemos de la complejidad del código y entonces es muy posible que todo esté bien desacoplado y tenga una única responsabilidad, en cuyo caso la complejidad del código podría ser menor para proyectos grandes. Por lo tanto, decir que la complejidad significa que el proyecto es grande realmente no dice nada.
Henrik
... o, naturalmente, cualquier otra medida de complejidad.
Henrik
@Henrik, "sistema complejo" no es equivalente a "sistema grande".
1
No, es sinónimo.
Henrik
@ Henrik, no estoy de acuerdo. Un sistema puede ser grande pero regular, es decir, muchas cosas se resuelven casi de la misma manera, donde puede predecir cómo se hacen las cosas en función de su experiencia con el resto del sistema, y ​​un sistema puede ser pequeño pero aún muy complejo.
34

Aproximadamente cómo acordaría las cosas: tenga en cuenta que esto es más o menos arbitrario. El "tamaño" del proyecto en una combinación de otros factores como la complejidad, las líneas de código fuente, la cantidad de características / valor comercial, etc. Un producto muy pequeño puede ofrecer una gran cantidad de valor, etc. Dicho esto:

  • 2m + sloc es un proyecto de grande a enorme. Estos son generalmente tan complejos que pocas personas, si es que hay alguna, son "fluidas" en todo el sistema; más bien, la responsabilidad tiende a modularizarse a lo largo de la estructura del código. Estos proyectos a menudo brindan un enorme valor comercial y pueden ser de misión crítica. A veces también están bajo una fuerte tensión de deuda técnica y otras preocupaciones heredadas.

  • 100k - 2m sloc es un proyecto de tamaño mediano. Este es mi punto medio: el proyecto es lo suficientemente complejo como para requerir algún conocimiento experto, y probablemente ha acumulado cierto grado de deuda técnica; es probable que también entregue cierto grado de valor comercial.

  • 10k - 100k es un proyecto pequeño, pero no demasiado pequeño para tener la suficiente complejidad como para que necesite la consideración de un experto; Si es de código abierto, considere hacer que las personas de su confianza revisen sus confirmaciones.

  • Cualquier cosa de menos de 10k de pendiente es realmente pequeña. Eso no significa que no pueda ofrecer ningún valor, y muchos proyectos muy interesantes tienen una impresión muy pequeña (por ejemplo, Camping, cuya fuente es ~ 2 kb (!)). Los no expertos generalmente pueden generar inquietudes sobre el valor (corregir errores y agregar funciones) sin tener que saber demasiado sobre el dominio.

Joseph Weissman
fuente
44
Votaría esto dos veces si pudiera. Los números son algo arbitrarios, por supuesto, pero creo que las descripciones de lo que implican los diferentes grados de "grandeza" son acertadas.
Eric Anderson
1
@EricAnderson Definitivamente es más fácil pensar en esto en términos de descripciones que en la medida de sloc. Un programa Erlang 100k sloc es fácilmente un orden de magnitud "más grande" que un programa C ++ 100k sloc, basado simplemente en lo que hace, independientemente de lo fácil que sea leer el código en un nivel superior. En cierto punto, leer el código no es tan difícil como recordar lo que sucede dentro del sistema a un alto nivel porque hay muchas funciones y centros lógicos.
zxq9
@ zxq9 Estoy en desacuerdo. Es cierto que eso implica que la elección del idioma podría hacer que un gran proyecto sea más pequeño. Lo que solía ser para las grandes computadoras ahora es demasiado lento, y lo que solía ser para los grandes proyectos de software puede ser trivial hoy en día. Lo que es invariable es el costo / complejidad de un proyecto. Si bien SLOC no es una medida perfecta, todavía está estrechamente relacionado con el costo y la complejidad de un proyecto de software. Al igual que las grandes máquinas no son necesariamente mejores, los grandes proyectos de software tampoco lo son. Si es posible, divida un proyecto en componentes independientes y elija las tecnologías adecuadas para hacerlos aún más pequeños.
Yongwei Wu
14

El tamaño de un proyecto se mide por el grado de falta de mantenimiento.

mojuba
fuente
2
Eso es pesimista: D
Henrik
.... y esa medida es?
Casey Patton
1
@Casey Patton la medida es literalmente el costo de mantenimiento.
mojuba
12

Complejidad que puede estimarse de varias maneras:

  1. Presupuesto. Un proyecto con un presupuesto de $ 10,000,000 + es probablemente bastante diferente de uno que tiene menos de $ 10,000 por ejemplo. Esto puede incluir mano de obra, software, hardware y otros costos incurridos al hacer un proyecto.
  2. Persona horas de trabajo para completar el proyecto. ¿Tomará un millón de horas o algo más? Esto también podría verse como un factor de línea de tiempo en el que algunos proyectos pueden llevar años, que diría que fueron grandes en comparación con otros que pueden llevar menos de una semana. Tenga en cuenta que las horas de la persona pueden ser engañosas como alguien puede pensar al duplicar el personal, por lo que hay dos veces más trabajando en el proyecto, entonces el cronograma se puede dividir por la mitad, lo que rara vez me funcionaría.
  3. Cantidad de hardware, otros sistemas y personas que usan lo que el proyecto está construyendo. Si algo está vinculado a 101 sistemas, entonces es probable que sea más complicado que si está solo y no se vincula con nada más.

Si bien los requisitos pueden sonar como una buena manera de medir esto, a menudo hay más requisitos que se encontrarán a medida que se realiza un proyecto asumiendo una metodología que no sea Waterfall, creo.

JB King
fuente
11

El tamaño de un proyecto probablemente se mide mejor por la cantidad de requisitos que tiene el sistema, donde los requisitos no pueden reducirse aún más.

Por supuesto, más requisitos en su mayoría significa más complejidad, pero no siempre es así.

David_001
fuente
1
Eso puede no ser una buena medida: los requisitos para los compiladores y los núcleos del sistema operativo pueden ser desproporcionadamente grandes en comparación con otros tipos de productos.
mojuba
2
@mojuba: "Grande" es un término bastante amplio, me imagino que escribir un compilador o un sistema operativo sería un proyecto "grande"
David_001
@ David_001: tome el compilador Turbo Pascal, f.ex., cuyo tamaño binario en un punto era 70 kilobytes y, sin embargo, TP era un lenguaje de programación orientado a objetos completo. Nunca hemos visto las fuentes, pero un ejecutable de 70 kb no puede ser un gran proyecto.
mojuba
@ David_001: no es que esté totalmente en desacuerdo contigo en general. Cualquier definición de un proyecto "grande" será tan vaga como la palabra "grande".
mojuba
@mojuba: Cuando usé Turbo Pascal, no estaba orientado a objetos en absoluto.
David Thornley
4

Mediría el tamaño de un proyecto por lo difícil que es ver todo el proyecto como una sola imagen general. Por ejemplo, tengo una base de código de exploración / creación de prototipos para un problema de aprendizaje automático en el que estoy trabajando. Son solo 5k líneas de código, pero se siente como un gran proyecto. Hay toneladas de opciones de configuración que interactúan de manera impredecible. Puede encontrar casi todos los patrones de diseño conocidos por el hombre en algún lugar de la base de código para administrar toda esa complejidad. El diseño a menudo es subóptimo porque la cosa creció mucho por la evolución y no se refactoriza tan a menudo como debería ser. Soy el único que trabaja en esta base de código, pero a menudo me sorprende cómo interactúan las cosas.

Por otro lado, uno de mis proyectos de pasatiempo tiene aproximadamente 3-4 veces más código, y sin embargo, se siente mucho más pequeño porque es básicamente una biblioteca de funciones matemáticas que son en su mayoría ortogonales entre sí. Las cosas no interactúan de manera compleja, y es bonito entender cada función de forma aislada. Es fácil ver el panorama general en la medida en que hay uno, porque no hay mucho que ver.

dsimcha
fuente
3

Respuesta arbitraria: qué tan grande es el proyecto, cuánto desearía haberlo hecho con el abastecimiento de eventos y SOA desde el principio. O que los autores del sistema habían leído el libro de Evan "DDD: abordar la complejidad en el corazón del software";)

Henrik
fuente
2

Compexidad y alcance

La complejidad y el alcance creo que es lo que determina qué tan grande es realmente un proyecto. Sin embargo, hay varios intangibles que también pueden afectar el tamaño de un proyecto.

Requisitos

La mayor caída que enfrenté fue la falta de requisitos. En mi situación particular, el gerente de ventas estaba determinando los requisitos. Su enfoque estaba en la venta ... tenía que conseguir la venta. En su opinión, lo que pedía el cliente no parecía tan complicado porque habíamos construido algo similar. Los requisitos vagos conducen a trabajos de bajo precio y expectativas excesivamente comprometidas.

La falta de una CCMU

CCMU es lo que yo llamo un " Coo Ca Moo " (claro entendimiento mutuo completo). Necesita tener una CCMU con su cliente.

Si tiene un proyecto pequeño con una CCMU pobre, puede terminar haciendo el proyecto 2,3,4 o más veces. Por lo tanto, un trabajo simple de 20 horas se convierte en un proyecto de 60 horas con un personal estresado y un cliente muy insatisfecho.

Alcance Creep

Esto sucede más a menudo de lo que piensas. El cliente decide que, dado que ya está haciendo A, B y C, no debería ser tan difícil agregar D o incluso F. Si este comportamiento no se verifica, también puede convertir un proyecto pequeño en un proyecto de tamaño mediano. Y dependiendo de cómo el gerente de ventas vendió el trabajo, estas expectativas de alcance pueden parecer "GRATUITAS" para el cliente.

Michael Riley - AKA Gunny
fuente
1

Es extraño, al leer muchas de estas respuestas, encuentro que veo el tamaño de un proyecto de manera muy diferente. Quizás sea mi trabajo en una gran corporación, pero tiendo a ver el tamaño de un proyecto como una escala de su visibilidad / conveniencia para sus clientes (dependiendo de su área de trabajo, estos pueden ser compañeros de trabajo o clientes reales).

Kavet Kerek
fuente
1

La complejidad es la respuesta correcta, pero ¿cómo estimarla?

Los factores son:

  1. Los puntos de extensión cuentan
  2. Recuento de capas de módulos (funciones, clases, sistemas de clases, bibliotecas, bibliotecas compartidas, aplicaciones, aplicaciones de red, etc.)
  3. Recuento de dependencias (plataformas incluidas)
  4. Cuenta con recuento de interdependencia.
  5. Recursos necesarios sin código (incluidos gráficos / artes, guiones de conducción, como guiones de diseño de nivel, y otros recursos necesarios para completar una versión de la aplicación).

Cuanto más tenga de esos, más complejo es el proyecto.

Klaim
fuente
0

LOC es notoriamente inexacto para muchas mediciones, pero creo que está tratando de medir algo que realmente no hay una forma precisa de medir. Quizás una alternativa podría ser la complejidad ciclomática .

Sin embargo, en última instancia, creo que la "grandeza" de un proyecto es difícil de cuantificar. Es casi como preguntar cómo se determina si un perro es grande o no. No solo hay varias formas de medirlo (masa, volumen, etc.), sino que personalmente no lo encuentro muy útil. La realidad es que mi criterio probablemente será algo así como "¿Qué posibilidades hay de que huya de este perro si lo veo en un callejón oscuro?"

Y para que conste, generalmente no consideraría que 1k líneas de código fueran mucho. Sería una parte considerable de código, pero que no sería que mucho en el gran esquema de las cosas. Por supuesto, supongo que depende del idioma. Por ejemplo, 1k líneas de código es mucho menos código en un lenguaje como C que en un lenguaje como Pyhon.

Jason Baker
fuente