Puedo escribir programas pequeños pero no puedo escribir programas complejos grandes. ¿Qué tengo que hacer?

Answer 1

Eso es normal, todos comienzan de esa manera. En realidad, suena mejor de lo normal, ya que la mayoría de las personas no pueden escribir programas en absoluto.

Los programas grandes son realmente muchas características pequeñas unidas.

Mis proyectos actuales son aproximadamente 160,000 líneas de código, pero no lo piense como un gran bulto, no lo es, piense en programas de 160 x 1000 líneas o en programas de 1000 x 160 líneas.

Claro, algunos de esos programas son más complejos que otros, algunos son realmente simples, algunos no tanto, pero eso es solo parte de la experiencia de aprendizaje, llegarás allí.

Si puede escribir un pequeño programa de 160 líneas, puede hacerlo 1000 veces, y eso es lo que son las aplicaciones complejas.

Hay una habilidad realmente importante en la programación que la mayoría de la gente no entiende, la mayoría piensa que la programación se trata de aprender idiomas, aprender marcos o recordar documentación, no lo es.

Se trata de dividir un problema en muchos problemas pequeños.

Si puede escribir proyectos pequeños, puede escribir proyectos grandes, simplemente no lo sabe todavía.

Answer 2

Los pequeños problemas son fáciles de resolver, pero los grandes programas complejos requieren mucha planificación. Primero debe estudiar los patrones de diseño, estos lo guiarán a través del diseño de programas de alta calidad, gran rendimiento, robustos y fáciles de mantener. También leyendo un poco más sobre análisis y diseño de software.

Todos tendemos a querer saltar el arma sin suficiente planificación, así que también da un paso atrás haz tus ERD (sé que no es lo más emocionante) haz tus diagramas de clase y justifica todo esto a continuación, esto te permite pensar completamente acerca de por qué y cómo.

Answer 3

¡Escribe pequeños programas! Escribe muchos de ellos. Vuelva a visitarlos y elimine los errores o agregue nuevas funciones (y luego elimine los nuevos errores).

De esta manera, aumentará gradualmente la complejidad de sus programas, así como su capacidad para comprenderlos. Se han desarrollado muchos sistemas complejos a través de la acumulación, es decir, el comienzo con un núcleo funcional relativamente pequeño y luego se les agregan nuevas características a medida que pasa el tiempo. He visto sistemas más complejos como este que sistemas complejos que se diseñaron completamente por adelantado y luego se construyeron en un proyecto continuo. No tengo números concretos y mi experiencia puede no ser típica, pero eso es lo que he visto.

Vale la pena tener en cuenta un par de cosas que mi compañero acaba de mencionar. Le ayudará si aprende a pensar a nivel arquitectónico. Si eres bueno escribiendo programas pequeños, entonces puedes estar acostumbrado a pensar a un nivel algorítmico, como saber cómo implementar un ordenamiento rápido versus un tipo de burbuja. Pero si está pensando en un nivel arquitectónico, puede mirar sistemas más grandes. Familiarizarse con los patrones de diseño arquitectónico; Hay docenas de libros sobre el tema.

Además, compartimente su código. Admito que este es un paso con el que tengo muchos problemas. Pero si puede mantener su código pequeño, digamos, no más de 120 líneas por archivo / clase / rutina, contribuirá en gran medida a mantener las piezas individuales del programa pequeñas y fáciles de entender. Eso hace que la comprensión de todo el sistema sea más manejable.

Answer 4

Probablemente tendrá que dar un poco más de detalles sobre lo que quiere decir en específico. ¿Dónde exactamente tienes problemas para escribir programas bi-complejos?

Sin embargo, en general, si tiene problemas para visualizar y armar un proyecto grande. Entonces, una solución es trabajar en componentes. Comience por simplificar las cosas comunes que hace creando una biblioteca de funciones comunes utilizadas. Esto simplificará el desarrollo general en grandes proyectos a medida que reutilice el código.

No reinvente la rueda, hay muchos marcos y módulos que ya pueden hacer parte de lo que hace. Si faltan cosas, modifíquelas usted mismo para adaptarlas a sus necesidades. (Uno de mis primeros errores en la programación fue construir mis propios marcos, me llevó mucho tiempo. Hoy en día uso marcos preconstruidos y hago modificaciones y, a veces, contribuyo con esos cambios en el caso de los marcos de código abierto)

Luego divida el gran proyecto en hitos, comience con las cosas fáciles primero y cree una estructura básica. Luego agregue características a través de módulos a su proyecto. A diferencia del enfoque de planificación anticipada, esto se volverá complicado ya que te encontrarás retrocediendo mucho. Como notará conflictos y cosas que no funcionan de manera eficiente o necesitan cambios. Pero eso está bien porque crea experiencia. La razón principal por la que una persona tiene problemas con grandes proyectos es la falta de experiencia. La falta de experiencia no significa falta de experiencia en la codificación, la experiencia le permite ver las posibles direcciones de un código e ir y crear espacio para modificaciones y expansión. Hacer el código más modular y reutilizable y etc.

Answer 5

Respuesta corta: más información. Consigue más experiencia.

Respuesta corta alternativa: nadie escribe (o debería escribir) “programas grandes y complejos”, nadie debería siquiera intentarlo.

Respuesta más larga:

Los programas grandes y complejos no son programas, son sistemas. Si se propone escribir un “gran programa complejo”, está haciendo algo mal.

Usted se propuso desarrollar un sistema, no un “gran programa complejo”. Si es realmente grande y complejo, entonces probablemente esté compuesto por una combinación de hardware, software, redes, personas y procesos, todos involucrados en operaciones y mantenimiento. Si solo se trata de código, que se ejecuta en una sola máquina (por ejemplo, un sistema operativo, un administrador de base de datos), entonces podría considerarse un “sistema de software”.

• Primero comprende y resuelve el problema en cuestión, que requiere un amplio conocimiento y experiencia en el dominio de la aplicación.
• Luego, hace arquitectura: concepto de operaciones, selección de tecnología / plataforma, componentes principales, flujos de datos, flujos de control, interfaces. Esto requiere un gran conocimiento y experiencia en ingeniería de sistemas y software.
• Luego comienza a escribir componentes de software: pequeños programas, módulos, definiciones de bases de datos, etc. Quizás las habilidades básicas de programación sean suficientes aquí, con suficiente dirección, supervisión y apoyo.
• Luego integra, prueba, depura. Finalmente, empaqueta e implementa. Entonces lo configuras. Y luego administras y mantienes. Nuevamente, esto requiere una buena cantidad de conocimiento y experiencia en ingeniería de software, junto con la administración de sistemas y las habilidades de DevOps.
• En el camino, realiza una gran cantidad de gestión de procesos (estándares de diseño, control de configuración, procedimientos / herramientas / sistemas de construcción y prueba, y documentación. Las habilidades arquitectónicas, de gestión de proyectos y DevOps son importantes aquí.
• Solo después de que escribe e integra todas las piezas, parece un “programa grande y complejo”. E incluso entonces, solo se ve como un “gran programa” si agrega todas las líneas de código. En realidad, es más probable que haya muchas piezas pequeñas que se cargan en diferentes lugares en el disco y en la memoria.

Más allá de eso, los grandes sistemas son un deporte de equipo. A menos que sea el arquitecto, diseñador principal o gerente de proyecto, usted (como individuo) se enfoca en componentes más pequeños del sistema (aunque ayuda a conocer y comprender el panorama general). E incluso si está liderando el esfuerzo, un buen diseño suele ser un esfuerzo de equipo, realizado frente a pizarras, no a teclados.

Answer 6

Te daré una explicación muy simplificada, pero tal vez esto te ayude a comenzar.

Analice el problema y córtelo en problemas más pequeños. Divida esos problemas más pequeños en problemas aún más pequeños, lo suficientemente pequeños como para que pueda escribir código para cada problema. No pierda la supervisión de cómo todos los problemas se conectan en la imagen más grande (escriba todas las conexiones entre los problemas mientras analiza). Comience con el problema ‘principal’ en la parte superior y ramifique los problemas secundarios debajo de eso como una especie de árbol.

Si tiene este panorama general, avance lentamente (comenzando con el problema principal) hasta que haya programado todos los problemas y subproblemas en el árbol.

Esto también se conoce como un enfoque ‘de arriba hacia abajo’. También hay un enfoque llamado programación ‘de abajo hacia arriba’, que, lo has adivinado, es lo opuesto al enfoque de arriba hacia abajo. Cuál de los dos es mejor depende del problema.

Si desea conocer más detalles, simplemente busque en Google ‘programación de arriba hacia abajo’ o ‘programación de abajo hacia arriba’.

Answer 7

En mi adolescencia hice mucha programación competitiva. Esto fue muy divertido y gratificante, pero con el tiempo desarrollé un cierto sesgo mental: pensé que si no puedo escribir este programa en las 3-5 horas que se dan en una competencia, significa que no vale la pena escribirlo. Me devolvió el golpe cuando me dirigí hacia una programación más general y luché incluso con proyectos iniciales que tomarían más de un fin de semana de principio a fin.

Lo que debe hacer es escribir programas de tamaño mediano . Comience con algo pequeño. Luego, agregue una nueva característica. Y otro. Y otro más. Arregla un error aquí. Código de limpieza allí. Vea cómo la base de código crece orgánicamente. Con el tiempo, desarrollará experiencia y confianza para mantener grandes programas.

Otro ejercicio que puede hacer es tomar el código fuente de un proyecto maduro existente y ver cómo funciona, cómo está construido y por qué está construido de esa manera.

Y leer libros también. Los patrones de diseño, la refactorización y el código limpio serán útiles, pero aún así nada supera la experiencia práctica.

Answer 8

Si puede escribir programas pequeños, entonces lo mismo se usa para escribir los programas complejos grandes. Encuentre un caso de estudio, divídalo en partes más pequeñas por HLD y LLD, y luego escriba los códigos más pequeños para resolverlo paso a paso. En algún momento te darás cuenta de haber escrito con éxito un código complejo más grande. Algunos de mis tutoriales de YouTube pueden ser de alguna ayuda: