¿Cómo escriben las personas más de 10,000 líneas de código por sí mismas? ¿Qué clase de proyecto individual podría necesitar eso? ¿Cuáles son los desafíos que enfrentan los programadores mientras codifican un sistema tan grande? ¿Cuánta habilidad se necesita para alcanzar este nivel?

Answer 1

Ellos usan Java.

Más seriamente, solo lo hacen gastando una buena cantidad de tiempo en un proyecto y teniendo una arquitectura decente. Siempre que hayas pensado un poco en ello, es bastante fácil escalar una base de código sin tener que mantener todo en tu cabeza de una vez. En ese punto, solo se convierte en una cuestión de tiempo y dedicación.

Además, muchos proyectos tienen lo que yo considero una “gran área de superficie pero bajo volumen”. Es decir, tienen una gran cantidad de código que hace cosas pequeñas, en su mayoría sin relación, sin una estructura profunda o complejidad conceptual. Construir miles de líneas de código como esto es a menudo fácil e inevitable.

Considere, por ejemplo, muchas GUI: tienen capas completas de menús, diálogos y asistentes. Todo ese código de UI requiere muchas líneas de código (¡especialmente en versiones anteriores de Java con sus clases internas anónimas!). Pero esas líneas de código no hacen mucho. Por ejemplo, cada elemento del menú necesita una línea que declare su nombre, que especifique a qué menú se dirige y que le vincule una función; está viendo 2 o 3 líneas por elemento, incluso para los triviales como “ayuda” o “salir” .

Por ejemplo, aquí hay un simulador de física en el que trabajé con un amigo en la escuela secundaria. ¿Ver los pequeños menús y ventanas emergentes y herramientas? ¡Cada uno de ellos toma un montón de líneas, y no está relacionado con la física real de la cosa en absoluto !
Algo así como la mitad del código para esto, miles de líneas, es simplemente configurar los elementos de la interfaz de usuario y convertir la simulación física real en 2D en un programa GUI.

Por supuesto, esto es parcialmente culpa de Java. Me tomó 10 líneas de código para cada botón que ves en el lado izquierdo:

rectangleButton = new JButton(rectangleTool); rectangleButton.setPreferredSize(new Dimension(25, 25)); rectangleButton.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { parent.addRectangle(); } }); rectangleButton.setOpaque(false); add(rectangleButton); 

Más código es mejor código, ¿verdad? ¡Esa es la forma de Java!

Si está haciendo una aplicación web, tiene lo mismo: necesitará cientos de líneas solo para configurar todos los parámetros, configurar una consola de administración, configurar el manejo de errores correctamente … etc. Eso es antes de que tenga alguna lógica. ¡Específico para el núcleo de lo que estés trabajando!

De hecho, muchas aplicaciones, especialmente las que no se centran en la investigación, tienen mucho más código como este que el código algorítmico carnoso que hace algo interesante.

En última instancia, solo significa que las líneas de código son en realidad un proxy bastante malo para el tamaño, la complejidad, la dificultad o la capacidad de un proyecto. Hay demasiada variación dependiendo de lo que estés haciendo y del idioma que estés usando. He escrito código Haskell que no es de GUI que tiene más contenido real en 500 líneas de código que en 4000 líneas de Java que había escrito anteriormente. (El código de Haskell también tenía una propiedad entrañable de acortarse cuando agregué nuevas funciones porque era muy fácil refactorizar y generalizar).

Así que lo más probable es que los proyectos de línea de 10k en los que trabajaron fueran exactamente de este tipo: área de superficie alta pero volumen bajo.

Answer 2

¿Cómo la gente construye rascacielos?

Un piso a la vez.

¿Cómo construyen un piso?

Un ladrillo a la vez.

Ahora, por supuesto, señalaría que los rascacielos son construidos por muchas personas, y hay clases de tareas involucradas en la construcción de un rascacielos que requiere que algunas personas hagan cosas juntas al mismo tiempo.

Aunque el principio es el mismo, construyes una unidad pequeña, luego construyes otra unidad pequeña y luego las conectas.

Repetir.

Puede hacerlo más rápido con más personas si se hace correctamente, aunque una persona productiva puede llegar muy lejos.

Así que no es tan difícil escribir mucho código.

También señalaría que a veces puede ser mucho más difícil escribir 50 líneas de código denso que escribir muchos miles de líneas de código fácil (aunque este último es, por supuesto, típicamente más lento), así que hágalo cuando Es necesario pero no lo veas como una indicación de habilidad.

Answer 3

Creo que Tikhon ha definido la respuesta bastante bien, pero también creo que hay un lado diferente de las cosas y podría estar más relacionado con la biología que con la informática.

He hecho un montón de “ciencia informática”, lo que significa que la mayor parte del código es un sistema diseñado para realizar cálculos con respecto a un proyecto científico. Lo he hecho tanto en proyectos informáticos como en bioinfomática. Estos tipos de proyectos son de baja GUI (o incluso UI) y alta arquitectura. Debido a que estos sistemas computacionales son muy especializados, muchas de las herramientas generales disponibles no son adecuadas.

Por ejemplo, un proyecto fue recolectar el seguimiento de 500 proteínas diferentes en una colonia de bacterias, que requieren múltiples muestras por minuto, de generación en generación. Esto fue fácilmente 5 millones de registros por minuto durante más de 10 días para un número total de registros de 72 billones por experimento y este experimento se realizó más de diez veces. Esto era demasiada información para una base de datos relacional de propósito general y la universidad (o mi subvención) no cubrió el costo de un clúster de Hadoop. Para resolver este problema, creé una arquitectura para almacenar estos datos en formato sin procesar que también realizó múltiples niveles del procesamiento de datos que necesitaba para realizar los cálculos y correlaciones eventuales para crear el conjunto de datos de resultados finales. Esto significaba que escribí un sistema especializado de recuperación y almacenamiento de bases de datos solo para facilitar una forma de escribir todos los demás códigos en el sistema. Este sistema solo tenía más de 110k líneas de código y eso era solo para arrancar el proyecto con el fin de realizar el trabajo previsto real. Esto requería una API para ese sistema de almacenamiento que también era un código adicional. Así es como un solo proyecto puede necesitar tales líneas de código. Ahora para la parte de biología.

Algunos programadores pueden mantener las arquitecturas muy complejas en sus cabezas mucho más fácilmente que otras y esto les permite reducir la complejidad de sus cabezas para escribir desde una perspectiva de abajo hacia arriba sin tanto trabajo con lápiz y papel (especificaciones de diseño). Mientras estén cerca del proyecto (trabajando todos los días) tienen poco problema con su metodología. Simplemente escriben pequeños fragmentos de código que se utilizan en la siguiente capa superior que se utiliza para escribir la siguiente capa, etc., hasta que el proyecto esté terminado. Habiendo trabajado también en el espacio comercial y contratado a muchos programadores, he descubierto que no todos los programadores poseen esta capacidad. Para mí es natural, así es como trabajo y no requiere mucho esfuerzo por mi parte. Es simplemente cómo funciona mi cerebro. Para otros, esto no es tan fácil, pero pueden diseñar una pequeña interfaz resbaladiza sin muchas especificaciones, lo cual es una habilidad que se me escapa. He encontrado una relación entre el pensamiento espacial y la codificación compleja y luego determiné que era lo que muchos llaman “pensamiento visual”. El pensamiento visual es pensamiento no verbal. Un pequeño porcentaje de la población tiende a usar el pensamiento visual sobre el pensamiento verbal y los que he encontrado que son “codificadores de poder” tienden a usar el pensamiento espacial y visual. (ver pensamiento visual)

Ahora al otro punto de Tikhon: tiempo y dedicación. Tengo varios proyectos que llevo escribiendo más de veinte años. Tengo un sistema de enseñanza que utiliza el código C para emular el hardware de varias computadoras simples diseñadas para enseñar a otros cómo funcionan las computadoras. Este es un código que emula hardware como CPU, circuitos de video, discos duros, interfaces de unidades de disquete (¿qué son?), Generadores de sonido, teclados, decodificadores de memoria, etc. Estos se “enganchan” para crear una serie de sistemas que aumentan en complejidad, desde algo tan simple como un sistema tipo PDP-11 hasta tan complejo como un sistema 80386 que ejecuta MS-DOS v5. Cada uno de estos sistemas tiene software escrito en el ensamblaje nativo de las computadoras virtuales, o un compilador de C escrito en el ensamblaje que se usó para reescribir el sistema operativo nativo en C, etc. Esto significa que hay un código C en el código nativo (x86_64), virtual El ensamblaje del sistema, un compilador de C en el ensamblaje virtual (o Forth, BASIC, Logo o APL), el código C que compila el ensamblado de los sistemas virtuales, etc.

El propósito de este proyecto es permitir que mis alumnos vean el proceso completo de cómo se crearon las computadoras utilizando una serie de seis computadoras virtuales. Ahora imagine la cantidad de código que se necesita para emular el hardware de seis computadoras diferentes, el lenguaje ensamblador utilizado para escribir el primer sistema operativo bootstrap, el “BIOS”, los controladores de hardware, etc. Cuando agregue todo el código, incluido el código subyacente C y todo el código virtual, es más de 25 millones de líneas de código. Todo este código fue escrito por mí. Pero empecé el proyecto en 1991. Solía ​​levantarme y escribir código antes del trabajo, escribir código en el trabajo, luego volver a casa y escribir código hasta que me acostaba. Comencé a codificar en BASIC y luego en el ensamblaje 6809 a la edad de 12 años. Todo esto es una ventaja para mí, creo que es más difícil para los niños más pequeños aprender computadoras, ya que ahora son tan complejos. Es por eso que desarrollé el sistema de máquinas de enseñanza simples descritas. encima. Una vez que estudias el sistema 1, el sistema 2 no es tan desalentador. Entonces el sistema 3 puede ser entendido. Así es como aprendí las computadoras.

Así es como los grandes proyectos pueden ser escritos por individuos.

Answer 4

He estado desarrollando un motor de juego desde hace algún tiempo , actualmente tiene 24,846 líneas de código, incluidos los sombreadores que he escrito, etc.

Repasaré sus preguntas una por una, de la misma manera que escribo líneas de código.

¿Cómo escriben las personas más de 10.000 líneas de código por sí mismas?
Como dije … uno por uno, no hay atajos. Sin embargo, suficiente dedicación y una actitud orientada hacia el objetivo pueden hacer que parezca un código de 1000 líneas.

¿Qué tipo de proyecto individual podría necesitar tanta dedicación?
Si se asume que cada proyecto es un sistema, incluso si está hecho de un solo componente, cuantos más componentes necesite un sistema para brindar funcionalidad, mayores serán las posibilidades de que este sea uno de los proyectos de los que está hablando. Pueden ser cualquier cosa en realidad, incluso una calculadora puede ser matemática, si es necesario.

¿Cuáles son los desafíos que enfrentan los programadores mientras codifican un sistema tan grande?

• Diseño, eso es obvio. Un diseño que favorezca el rendimiento, la legibilidad y la capacidad de mantenimiento es lo suficientemente difícil de lograr en proyectos más pequeños, y mucho menos en proyectos grandes. Es un proceso doloroso que no se puede evitar, lo único que se debe evitar es la complejidad innecesaria.
• Aprendiendo sobre la marcha. Un gran proyecto contendrá muchas cosas con las que no estará familiarizado. No importa cuán cómodo se sienta con un área en particular, siempre habrá un caso en el que tendrá que hacer una investigación seria antes de siquiera pensar en escribir una sola línea de código.
• Disciplina. Trabajar en grandes proyectos durante largos períodos de tiempo sin perder interés, mientras que al mismo tiempo es altamente eficiente, requiere mucha disciplina.

¿Cuánta habilidad se necesita para alcanzar este nivel?
Solo un poquito, solo necesitas lo básico para que puedas escribir un código decente. Sin embargo, cuanto más sepa, mejores serán sus posibilidades de hacerlo más rápido y / o mejor.

Honestamente creo que cualquiera puede hacerlo, siempre y cuando haya algo de dedicación.

Aquí está el código fuente completo: PanosK92 / Directus3D

Answer 5

Bueno, estoy creando un proyecto llamado Iris por casi un año.

Estas son las últimas estadísticas del código.

El total es 1 758 243 líneas de código por año. Casi 2 millones. 56 veces la Biblia

Y este no es un gran proyecto. Es poca aplicación para protección ocular escrita en C ++ en su mayoría. Hay un código AI y UI que no estoy contando.

Digamos que he escrito 1 millón de líneas , porque sabes que he usado algunas bibliotecas gratuitas para el análisis JSON, por ejemplo.

No se trata del proyecto , se trata del objetivo . Quiero hacer el mejor software para la salud y la productividad. Quiero hacer capas sobre el sistema operativo y trabajo en esto todos los días. Todos los días durante el último año.

Cuando era desarrollador de juegos, nuestra base de código era de 8 0 millones de líneas de código. Para un solo juego.

No soy tan buen programador también. Tengo 20 años y llevo 5 años programando .

El reto es mantener el código limpio . Para llegar a 1 millón de líneas de código, he escrito y refaccionado más de 10 millones de líneas de código.

Puedes escribir 10,000 líneas de código con printf () , pero sabes que no será un programa increíble.

No necesitas ser un programador increíble. Te conviertes en un programador increíble con código de escritura. Todos los días me digo:

Una línea por día todos los días. Puedes hacerlo.

Cada mañana cuando me levanto. Termino escribiendo 1000 o 2000 líneas de código por día. Pero escribo mucho. Este es mi objetivo. Este es mi sueño. Por eso me levanto por la mañana. Para que esto suceda .

En el momento el software se ve así.

No es algo complejo . Se ve super básico y super fácil de hacer.

Las personas no siempre aprecian cuántas horas y líneas de código ponemos como programadores para hacer incluso algo tan simple como un cuadro de texto o un nuevo tipo de algoritmo .

Pero nosotros, como programadores, sabemos esto. Sabemos lo difícil que es hacer algo .

No necesitas ser un buen programador. Necesitas escribir código . Todos los días. Y nunca te rindas .

Answer 6

Si escribes solo diez líneas de código al día.
Habrás escrito cien líneas en diez días.
Habrás escrito 10.000 líneas en mil días.
Lo que significa que podrás escribir tu línea de 10,000
Programa en menos de tres años.

Tres años no es tan largo dado el promedio
Vida útil de los seres humanos. Y, por supuesto, si tú.
Escribe más de 100 líneas de código al día,
Terminarás tu programa mucho más rápido.

Trabajo como desarrollador a tiempo completo, y probablemente
Escribe un promedio de 500 líneas de código al día.
¿Eso suena como mucho? Bueno, el día de trabajo es
Ocho horas de duración. Si escribo una línea de código cada uno
minuto, eso es 60 en una hora. Que es de 480 en un día.

La verdad es que a menudo escribo más de una línea por minuto.
No me toma un minuto escribir esto:

var x = 2;
var y = x + 10;

En cualquier caso, dadas 500 líneas de código al día,
eso es 2.500 a la semana, lo que significa que cada
Mes escribo unas 10.000 líneas de código.

Eso no es impresionante. Es solo hacer un trabajo
día tras día. Estoy seguro de que el fontanero promedio
Arregla un número enorme de baños cada año.

Este post tiene 29 líneas de largo. Me tomó cerca de dos
Minutos para escribir y otros dos para editar. Así que eso es
Cuatro minutos en total. A ese ritmo, podría
extender esto a 3,480 en una longitud media
dia de trabajo Pero te ahorraré.

Answer 7

Piense en escribir 10.000 líneas de código como escribir un capítulo en un libro. Pocas personas necesitan escribir tanto para una tarea dada en la escuela. Sin embargo, si les gusta escribir y lo hicieron antes de su clase, podrían haber contribuido un capítulo a un libro, o tal vez incluso haber escrito un libro por sí mismos.

Lo mismo con la codificación. Si está codificando por su cuenta, en un programa más grande puede golpear de cinco a diez mil líneas con relativa facilidad. No tiene que ser una interfaz de usuario, incluso puede ser una programación científica. Por ejemplo, escribiendo un simulador de flujo de carga para calcular la presión de vapor en diferentes lugares en una red de distribución de vapor. Escribiendo una aplicación en red con su propio formato de paquete.

Si trabaja en una gran compañía de software, puede escribir 10,000 líneas en un año o dos como parte de un proyecto más grande. Por ejemplo, la mayoría de los equipos en los que estuve en Windows NT consistían en 3-5 desarrolladores que poseían un pequeño componente de Windows. El SDK Peer-to-peer era algo así como 125,000 líneas cuando terminamos, y esa fue la salida de <10 desarrolladores.

Competencia: yo diría que podría comenzar a hacerlo con solo un par de cientos de horas de experiencia en programación. Sería un programa de línea UGLY 10,000 pero podría hacerlo. Tu trabajo se ve mejor y se vuelve más lógico cuantas más veces lo haces.

En mi opinión, lo más importante para escribir parte de un programa grande es la capacidad de diseñar interfaces (como en, interfaces de clase C ++) y de descomponer los problemas grandes en un conjunto de problemas más pequeños separados lógicamente. La disciplina en el seguimiento de los recursos y el manejo de los casos de falla se vuelve muy importante. También es importante comprender dónde ya se realizó el procesamiento específico (por ejemplo, verificar entradas de manera segura) y solo hacerlo de manera intencional.

Answer 8

Tengo una biblioteca que representa alrededor del 90 por ciento de mi trabajo en los últimos 7 años. Contiene casi 100K líneas de código. No es que las líneas de código sean una medida precisa de complejidad o valor. Pero hay marcos individuales allí que son 10K líneas de código por sí mismos.

Un programador experimentado puede mantener la estructura de 30-50K líneas de código en una base de código en la que están trabajando activamente. Honestamente, 10K líneas es una aplicación pequeña a mediana. En la mayoría de los casos, comienza a perder la capacidad de ver la imagen completa del código más allá de las líneas de 50K.

El software evoluciona y crece. Alcanzar un cierto número de líneas de código depende del problema que se resuelva. Los marcos de línea de 10 K que menciono son marcos de automatización. Trabajan mucho, tienen muchas capacidades incorporadas, un montón de conversión de datos y funciones de reglas. En realidad, son intérpretes de lenguaje de mini-programación (también conocido como “lenguaje específico de dominio”). Vale la pena el tamaño por el tiempo que ahorran al quitar el trabajo manual a los desarrolladores en tareas comunes en mi entorno.

Y tengo otros marcos que son de 500 a 1000 líneas de código que son hermosos y elegantes y contienen una increíble cantidad de energía en un paquete tan pequeño. Y tampoco una compleja. El código es eminentemente legible y comprensible.

El desafío con cualquier base de código es mantener el foco en el problema que se está resolviendo y organizar por escrito y empaquetar dicho código. Haciéndolo comprensible. Tiene que hacerlo ya que probablemente regresará para mantenerlo después de un año o dos cuando esa imagen de detalle que tiene en su cabeza ha sido reemplazada por otra cosa.

¿Competencia? Eso depende. Los aficionados y los desarrolladores inexpertos a menudo pueden generar muchos códigos. No significa que sea un buen código. Un montón de repetición de cortar y pegar, complejidad excesiva y similares. Refactorizar una base de códigos trufada y trenzada de varios años en algo magnífico y elegante a la vista, requiere mucha habilidad. En el orden de nivel experto, 5000-10000 horas de habilidad.

Los mejores programadores, que te encontrarás algún día, persiguen la elegancia, no el tamaño. Es lo que hace el código y cómo lo hace lo que importa. Estoy más orgulloso de mi hermoso marco de mapeo de datos de 800 líneas que de mi marco de líneas 10K en un rol diferente. Simplemente por cómo y qué hace el marco de 800 líneas. Muy pocas bases de código que escribas en tu carrera lograrán el título de “elegante” y ese es un cumplido que perseguimos como el Santo Grial. Un verdadero signo de respeto y dominio profesional en el campo.

Answer 9

Es un buen número, 10,000 . Se supone que es la cantidad de horas necesarias para convertirse en un experto. Como experto, el código fluirá sin problemas de las manos de un creador.

¿Cómo debo dividir mis 10,000 horas de tiempo de programación?

O tal vez no. Cuestiono la premisa de que las líneas de código son una buena cantidad de tamaño. Una línea puede ser solo un espacio en blanco o una llave. Y, un mejor programador puede hacer más con menos líneas.

Answer 10

Esto no es muy inusual. Escribí aproximadamente 5,000 líneas en una aplicación Scala (lenguaje de programación) durante los fines de semana del año pasado. Eso fue alrededor de 420 horas en 110 días de fin de semana, con un promedio de 4 horas por día: dado que este recuento de líneas y el tiempo total que se toma ahora el proyecto está básicamente terminado, estimo alrededor de 50 líneas “depuradas y refactorizadas” por día. Estaba aprendiendo el idioma, el marco y el adaptador de base de datos al mismo tiempo.

Mi proyecto personal más grande es de aproximadamente 10,000 líneas, escrito en C. No puedo decir cuántas horas estuvieron involucradas, pero el desarrollo tuvo lugar durante 9 años, aquí y allá. Tal vez 1,000-2,000 horas? Dado que un trabajo típico a tiempo completo es aproximadamente 2,000 horas por año en papel, eso da un campo de juego.

Así se puede hacer. Para hacerlo con éxito hay que ser persistente y organizado. Mencionaría el control de versiones, refactorización, documentación interna, compilaciones automatizadas, todo lo que también ayuda a la productividad del equipo.

Answer 11

Su percepción de lo que es un gran proyecto necesita ser “redimensionada”.

10.000 líneas de código no es en absoluto un gran proyecto.

Durante 1991 todavía estaba en la escuela (16 años: incluso antes de la universidad / universidad) cuando escribí desde cero una biblioteca de interfaz gráfica de usuario para MS / DOS en Turbo Pascal. Fue muy inspirado por AmigaOS … pero en realidad le permitió escribir programas que usaban elementos gráficos que hoy puede dar por sentado, como ventanas, menús, botones, cuadros de texto, controles deslizantes, barras de desplazamiento, etc. Pero en esos momentos el sistema operativo ( ms / dos) tenía soporte CERO para los gráficos. Acabo de usar los primitivos gráficos básicos proporcionados por Turbo Pascal (tenía comandos básicos simples como “dibujar una línea recta desde el punto A al punto B usando este color”).

Puedo decirles que solo el código responsable de implementar un “cuadro de texto” desde cero superó las 4.000 líneas de código. Y me refiero a un simple cuadro de texto como el que escribe su nombre de inicio de sesión, sin ningún efecto visual elegante de gradiente / sombra / hot track: ni siquiera me ocupé de hacer que el cursor del texto parpadeara.

En un escenario real, las cosas se complican con mucha facilidad: este es el código fuente de una “vista de árbol” con todas las funciones (como la que muestra la estructura de carpetas de un disco en Windows) https://raw.githubusercontent.co …

En el proyecto de software en el que he estado trabajando durante los últimos 15 años, puedo decirle que solo el código responsable de calcular el precio de un producto es más de 6000 líneas: tiene que considerar muchos factores como diferentes monedas, diferentes posibles Descuentos de precios que se pueden aplicar (configurables por varios parámetros), precios que cambian según la cantidad pedida, la hora del día (o el día de la semana) en el método de pago, la forma en que envió su pedido, etc.

10.000 líneas no es un gran proyecto: puede escribir fácilmente esa cantidad de código en un par de semanas si ya tiene una idea de la arquitectura que desea implementar.

Conseguir la idea de la arquitectura (una idea de cómo puede resolver el problema) es la parte difícil, y su dificultad no está necesariamente relacionada con la cantidad de código que tiene que escribir. Por ejemplo: la codificación para aplicaciones “orientadas a los negocios” requiere mucho código, pero en la mayoría de los casos es tedioso y repetitivo.

Answer 12

10.000 líneas parece un poco extremo para los principiantes no programadores y absolutos.

En mis días nuevos como programador, incluso 1000 líneas me parecieron mucho. Cada vez que programaba más de 1000 líneas, me sentía profesional. (Buenos tiempos). Por el momento, las líneas de código que escribí para cada programa aumentaron vigorosamente.

Recientemente escribí un juego de rol en 2D en C ++ (SDL) dentro de las dos semanas del período que tiene alrededor de 14.000 líneas de código.

Para responder tu pregunta :

“ ¿Cuánta habilidad se necesita para alcanzar este nivel?”

No se trata simplemente de escribir el mismo código una y otra vez. Se trata de pensar y reflejar tu imaginación en la programación en sí misma. Cuanto más piensas y codificas, mejor obtienes. Las líneas de código no tienen significado si el programa no es funcional y / o está lleno de errores. Para programadores dedicados, las líneas de código de 10k son simplemente un pequeño desafío.

Answer 13

A finales de la década de 1970, diseñé un sistema que tenía 53,000 líneas de código en lenguaje ensamblador. Le tomó dos semanas. En el uso inicial, tenía 6 defectos que fueron detectados y reparados en una semana. El sistema fue utilizado durante varios años sin mantenimiento. ¿Por qué?

1. El sistema no estaba conectado a Internet y nunca migraría a otra plataforma computacional. Fue celestial.
2. Hice el análisis y diseño. Tuve acceso inmediato a todas las partes involucradas. Entonces, sabía lo que el sistema debía hacer.
3. Comprendí los métodos de diseño, algoritmos, lógica, sistemas, lenguajes de programación y máquinas virtuales (sí, no es nuevo).
4. Yo podria programar Tuve que programar en lenguaje ensamblador para obtener el rendimiento y el ajuste. Reutilicé código y macros confiables.
5. Podría quedarme en la zona. No había distracciones más que el sueño. Nadie intentó administrar mi tiempo o revisar mi progreso. No hubo informes. Tenía recursos ilimitados, Coca-Cola y pizza, 24–7.
6. Tenía 29 años. Quería volver a casa con mi esposa e hijos y reanudar mi vida como profesor.
7. Después de terminar, recibí el cheque y nunca quise o tuve que contestar el teléfono sobre el mantenimiento. Estaba en el contrato.
8. Fue divertido. (Mover a la posición 0)

Con las herramientas y los marcos de lenguaje modernos, puede hacer mucho más. Sin embargo, su profesor quiere que descienda a un nivel de competencia que lo haga realmente valioso para los demás y para usted mismo. Suelta tus inhibiciones y codifica como JS Bach.

Answer 14

En realidad, al igual que escribir ficción o ensayos, no es difícil escribir mucho, es difícil escribir algo conciso e inteligible. El primer borrador puede tener decenas de miles de líneas, pero las reescrituras subsiguientes se vuelven cada vez más cortas hasta que usted haya dicho (o implementado) tan poco como pueda hacer el trabajo.

Acabo de echar un vistazo rápido a mi proyecto actual. El código principal es 12.6 líneas de Scala, 19.1 líneas de Python, las pruebas son 11.6 líneas de Scala, 9.1 líneas de Python y la documentación es de 124 páginas. Este es mi segundo borrador, que comenzó en algún momento de febrero y se escribió principalmente entre las 10 de la noche y las 3 de la mañana todos los días. (No tengo un buen registro en el primer borrador.)

En un proyecto antiguo (@svgfig), en realidad cité el número de líneas en la página de inicio para cada reescritura sucesiva: pasó de 9 klines a 11 klines a 4 klines a 2.3 klines en cuatro borradores.

Lo pequeño es hermoso. Solo se necesita mucho trabajo para llegar allí.

Answer 15

Bueno, mis programas son del orden de cientos de miles de líneas de código ahora.

Casi toda esa complejidad tiene que ver con el manejo de la interfaz de usuario. Tenga muchos controles y formas en que los usuarios pueden interactuar con el software, y necesita mucho código para manejarlo, todo lo que pueden hacer.

Es una mezcla de la edición de la interfaz de usuario en un generador gráfico de interfaz de usuario, y luego escribir el código para manejar todos los eventos.

Luego, otro código es para el dibujo de gráficos para la interfaz de usuario.

Escribo en el nivel bajo C, por lo que probablemente deberías dividir el número de líneas por aproximadamente 10 para obtener el equivalente en C ++.

De todos modos, cuando empiezas a manejar la interfaz de usuario, si la aplicación es compleja, no es demasiado difícil de alcanzar 10k, habría pensado.

Implica una gran cantidad de reutilización del mismo código, y al reutilizarlo más a fondo, puede obtener un programa más pequeño y más fácil de leer.

Entonces, no es realmente una señal de logro construir un programa que tenga muchas líneas de código en particular. Puede que solo signifique que eres descuidado en tu codificación y que sigas escribiendo lo mismo una y otra vez de diferentes maneras, en lugar de escribir una rutina o clase elegante y ordenada que encapsule la funcionalidad principal que deseas y que la uses.

Como otros han dicho aquí, si continúan codificando durante varios años en el mismo proyecto, esto es lo que sucede. Digamos que escribes cien líneas de código al día; eso significa que, en tres años, has escrito cien mil líneas de código. Para un programador de C de bajo nivel, eso no es mucho código.

Si escribe diez líneas de código al día, en tres años son diez mil líneas de código.

Por lo tanto, si tiene un proyecto que lleva varios años en completarse, es poco probable que se sitúe por debajo de los 10,000 LOC y que pueda ir más allá.

Si escribe 100 líneas de código por día, o aproximadamente 12 líneas de código por hora, se completará un proyecto de 10,000 líneas en 100 días.

(Algunos días, por supuesto, escribo un número negativo de líneas de código porque encuentro una forma mejor de hacer las cosas, más elegante, o encuentro algún trabajo que hice, fue innecesario, etc.)

Answer 16

“El secreto para crear aplicaciones grandes nunca es crear aplicaciones grandes. Divida sus aplicaciones en partes pequeñas. Luego, reúna esas piezas comprobables y de pequeño tamaño en su gran aplicación” – Justin Meyer, autor JavaScriptMVC

Si construyes de forma modular esas 10,000 líneas no parecen mucho, 5 aquí, 20 ahí, lo que necesites para hacer que una pequeña función funcione. Depurar 100 funciones pequeñas es mucho más fácil que depurar una masiva.

Lectura sugerida (si está interesado en js): Patrones para la arquitectura de aplicaciones de JavaScript a gran escala

Answer 17

En los años 90, escribí un convertidor FORTRAN-> Object Pascal para un proyecto de conversión que era un código tan complejo (modelado de transporte) que tuve que automatizar las conversiones para tener la esperanza de completar el proyecto.

Había aproximadamente 5,000 líneas de código que proporcionaban el equivalente de las declaraciones de E / S con formato FORTRAN para los archivos.

Creo que el convertidor fue más de 20,000 líneas de Object Pascal.

Fueron 3 meses intensivos y terminé perdiendo el uso de mi brazo derecho durante unas semanas debido a una tendinitis. Es por eso que ahora estoy completamente ambidiestro con los ratones.

Según Ohloh, mis Frameworks OOFILE suman aproximadamente 89,000 líneas de código C ++.
Todo esto se escribió entre 1992 y 1998 y, en su mayoría, en dos grandes partes: la base de datos central y luego los marcos de GUI e informes. Tuve algunos empleados que escribieron bits: un amigo escribió el back-end de dBase y un encantador checo (hola Elemir) escribió los puertos de Windows de la representación del informe y la integración de MFC. Sin embargo, escribí al menos 60,000 lociones de ese total.

Todos estos ejemplos se escribieron con buenos IDE: el excelente entorno Think Object Pascal y la mayoría de OOFILE utilizando una combinación de CodeWarrior y el editor de OO al estilo Smalltalk de ObjectMaster.

También se escribieron en una arquitectura limpia y con un método de diseño estricto, aunque simple. Fueron desarrollados de forma incremental en base a los comentarios de los usuarios o en contra de un régimen de prueba estricto. El convertidor de FORTRAN tenía un montón de programas que tuve que convertir y luego probar con datos de entrada e informes conocidos.

Answer 18

Hice muchos proyectos por mi cuenta, así que puedo darte algunas estadísticas.
He enumerado a continuación solo los proyectos que percibí como desafiantes.

Debo decir que los proyectos que hice como junior, fueron percibidos por mí como divertidos, y sabía muy poco acerca de la “programación real” para molestarme con cosas como “desafíos” o “arquitectura”. He seguido escribiendo y escribiendo tratando de averiguar qué ejemplos escritos en inglés significa MSDN o DirectX SDK y mi pensamiento se dirigió principalmente a “qué otras cosas geniales me gustaría que hiciera el tiburón en la pantalla” en lugar de “cómo estructurar el código y qué interfaces debo hacer público”. La ignorancia era una dicha. Descubrí reflejos de agua, animaciones de hueso + piel, LOD, joystick de 5 ejes, conexión TCP / IP, etc., pero el código es un desastre que aún no sé cómo contar las líneas.

Durante mis estudios de CS, el desafío estaba principalmente en la parte algorítmica. Los dos proyectos que enumeré a continuación me obligaron a pensar principalmente en algoritmos (o ecuaciones físicas). Una vez más, la arquitectura del código no era tan importante para mí en ese momento.

Solo después de que empecé a trabajar “en la industria”, y me convertí en arquitecto de software, me di cuenta de que el problema ya no me sirve para leer especificaciones o descubrir algoritmos, sino para escribir el código para poder entiéndalo después de 2 años, o invitar a colegas para que me ayuden con esto.

Estos proyectos fueron realizados por mí durante Hi School (~ 17-18 años):

Proyecto 1: (un cliente de IRC / IM extensible con complementos)
Más de 10000 líneas de código en VB, pero hoy no estoy seguro de cómo contarlas, ya que muchas de ellas fueron generadas por las herramientas GUI.

Proyecto 2: (un juego multijugador 3d usando DirectX)
7000 líneas de VB, con los mismos problemas con el conteo anterior.

Proyecto 3: (un servidor de chat multiusuario)
5300 líneas de C ++
2000 líneas de VB para cliente.

Estos proyectos fueron realizados por mí durante los estudios de ciencias de la computación:

Proyecto 1: (un juego de conducción 3d con física)
4000 líneas en C ++

Proyecto 2: (un intérprete de prólogo)
1000 lineas en OCaml

Los siguientes proyectos fueron realizados por mí cuando ya era un arquitecto senior de software:

Proyecto 1: (sitio web de matemáticas / educación )
Un extremo frontal (mezcla de Type Script, Javascript Templates, CSS) me llevó alrededor de 7500 + 600 + 1500 líneas.
El backend, escrito en PHP, si resta el marco, tomó 7500.
El marco, que también es mi proyecto, me llevó ~ 7000 líneas.

Proyecto 2: (tienda de internet para códigos de activación de juegos con api)
El backend, escrito en PHP, si resta el marco, 12 000 líneas.

Proyecto 3: (un juego html5 para apostar fútbol)
El backend, escrito en PHP, si resta el marco, 5500 líneas.

Proyecto 4: (una prueba html5 “friendtest”)
El backend, escrito en PHP, si resta el marco, 14500 líneas.

Project 5: (a type inference algorithm for PHP)
6700 lines of PHP

Answer 19

Running sloccount I get the results below for my current project:

cpp: 183473 (97.27%)
python: 4762 (2.52%)
perl: 308 (0.16%)
sh: 87 (0.05%)

That is more than 180000 lines not couting comments or blank lines.

This project started about two years ago and for the first year I was basically alone working on it (now we are three). Most of those lines have already changed 2 to 3 times, which means about 500000 lines changed (added removed or modified) over the project life. About 100000 lines are test code,

If I believe git diff my number of lines changed every day average 1000 (including comments and blank lines).

Really, it is not that much. As I use TDD I usually write 2 or 3 tests for every application line. Adding, changing or deleting more than 200 lines in one hour is usual. Some parts of code are easy going and won’t need deep thinking. Mrely typing 4 or 5 lines per minute is not really fast typing. Deleting 10 lines is a matter of seconds.

Some parts of code are tougher and I then I will be less productive, but it’s not most of the code. When what I’m doing is clear enough in my head it just flows out, it’s not really slower than writing an english text. This text is about 30 lines long and I spent 10 minutes to write it. Code is not so different.

But as others said, number of lines is not a very good mesure. Just don’t fear the number of lines and try hard to keep code simple (and stupid) the length will take care of itself. 10000 lines is very usual for a few months projects (say six months).

On the other hand if you don’t keep code simple and stupid, at some point you won’t be able to continue working on it. And that point may be at just a few thousand lines…

This is probably more of a difference between programmers that worked on projects of more than 10000 lines and others : they did not fail on the road.

That shows they have some level of project management skill.

Answer 20

You can write

• 10.000 lines and have just garbage that does not really do anything and you can write
• 10.000 lines and have a stunning complex physics simulation .

TL;DR down there.

There is plethora of personal projects where you can write 10.000 lines or more. With 10.000 lines you can:

• Write half an ANSI C-compiler (Trust me, its not pretty but it works) in C
• Write a good webbrowser in C
• Write a really nice 2D game in C
• Write a really, really good physically-correct raytracer in C++
• Write a simple Client-Server game in Java
• Write a simple device driver for an measurement instrument in C

I personally really like C and I program quite a lot in C in my free time (which is not that much to be honest) and C++ too (for projects where you can really make use of object-oriententation) and C is very compact.

On the other hand, if you use other languages things can add up quite quickly. I am talking about you Java!

To the challenges one might face when doing such projects:

If you start out first, things might become confusing quite quickly. There are several techniques that help to prevent or circumvent some of those problems and most of them are just down to coding style (not your style but the proper style that should be enforced by everyone on the team, that is you for personal projects):

1. Split up functionality to different modules (eg files) that handle things indenpently from each other and use some kind of fixed interface to talk to each other, so that every module can be a black box
2. Every method should deal with one thing at a time , a specific task
3. Complex methods no longer than 100 lines , Simple methods with trivial code no longer than 200 lines
4. Prevent the creation of god classes when programming object-oriented or god-methods (see 3) that knows everything and can do everything (see 2)
5. Name your methods properly, but keep it short
6. Name your variables properly, but keep it short, often buf or tmp is all you need
7. Keep source files reasonably short (not more than 500–800 lines )
8. It could also help to do a proper draft in the first place, but that is something you do not normally do for your hobby projects or projects you work on alone, but nonetheless (search for UML)
9. Do not reinvent the wheel but still try out things and understand why things there invented in a certain way to sum all those above up.

I started programming when I was 8 years old and I did not do any really large projects before I was in grade 11 or 12 (while 12 is the last in my German home state). I just wanted to mess around and learn about some things and I let it be when it was no longer that interesting. Later, when you start studying there are projects that you have to finish once you chose a topic and your perspective gradually changes. You gain a lot of consistency and you do not break up with your already-ten-months-old project lightly just because something is not working or will be much work to refactor.

With programming is a bit like with everything in life. Once you grow out of childhood you can no longer do what you want all day and mess around.

TL; DR:

You can do quite a lot with 10.000 lines and lines of code does not tell anything about how much your program does. The more experience you have the easier it will be to reach this point before you become frustrated or bored.