¿Cómo puede un principiante en diseño de software convertirse en profesional en el campo? Estoy estudiando ingeniería de software, pero cuando veo software serio parece complicado. Entonces, ¿cómo debo llegar al punto en que pueda diseñar un software complejo y robusto?

Existen dos metodologías populares al crear una aplicación de software grande y compleja: Waterfall y Agile .

Waterfall se trata de crear una hoja de especificaciones detalladas que cubra todos y cada uno de los aspectos de la aplicación. Piense en un proyecto único que puede tardar meses o años en realizarse de acuerdo con los requisitos del negocio.

El objetivo de un enfoque similar es definir todos los recursos por adelantado y asignarlos en consecuencia. Es común que proyectos similares se salgan de control por varias razones, pero con la planificación adecuada y un equipo profesional, la compensación no será demasiado extraordinaria.

Sin embargo, esto requiere mucha experiencia en la definición del conjunto de características, todas las capas intermedias, la infraestructura del servidor y lo que no. Es por eso que la mayoría de esos proyectos se quedan sin tiempo ni presupuesto.

El enfoque ágil es común en entornos de inicio y organizaciones más innovadoras. Se trata de mejoras iterativas. Comienza con el producto mínimo viable o el conjunto de características más pequeño para poner en marcha un proyecto. Con el tiempo, se expande por encima de los requisitos originales. No es improbable que el proyecto mute y evolucione, lo que a menudo requiere refactorizar porciones significativas de la base de código inicial.

  • La primera metodología consiste en definir los requisitos desde el primer momento.
  • El segundo requiere flexibilidad y adopción de los procesos comerciales en constante cambio y diferentes factores que convertirían un nuevo proyecto en uno complejo, como características complicadas, una gran cantidad de tráfico, incapacidad para servir ciertos tipos de medios o manejar un gran proyecto. volumen de entradas de la base de datos.

En cualquier caso, se trata de experiencia. Puede intentar aprender sistemas distribuidos y de gran escala usted mismo. Es un buen proyecto favorito, aunque cada aplicación compleja viene con su propio conjunto de problemas complejos.

En general, las aplicaciones de software robustas han comenzado de manera simple y ampliada con el tiempo. Se trata de usar patrones de diseño establecidos y paradigmas de arquitectura empresarial. Hay ciertos recursos iniciales que los ingenieros de software a menudo estudian por adelantado o durante los primeros años.

Una vez que esté familiarizado con los principales problemas de los sistemas a gran escala y los enfoques comunes para resolver problemas similares, puede comenzar a aplicar algunos de ellos en la práctica. Como desarrollador nuevo, normalmente trabajaría en una organización con más miembros del personal de alto nivel que están bien versados ​​en situaciones similares.

Nuevamente, se trata de experiencia y aprendizaje continuo. Los desarrolladores senior han estado expuestos a situaciones similares y ya probaron esos enfoques con éxito en la práctica.

Mientras lee los registros de confirmación y explora otras aplicaciones de software, comenzará a notar patrones repetitivos que ocurren en diferentes niveles. Esas son ciertas capas de abstracción que se encargan del trabajo pesado.

Sea paciente, dedique un tiempo a mejorar sus habilidades profesionales, aprenda de los desarrolladores más experimentados y digiera cuidadosamente las aplicaciones existentes. Con el tiempo, se sentirá cómodo con todos ellos y será capaz de sugerirlos e implementarlos en proyectos complejos.

La única forma de ser bueno en algo es hacerlo mucho durante mucho tiempo. La programación no es diferente en esto; Se necesitan años de experiencia práctica para ser realmente bueno en eso.

Lo sé, hay personas por ahí tratando de convencerte de que puedes convertirte en programador en poco tiempo. No funciona de esa manera. Hay muchas personas que pueden escribir algunos programas pequeños, relativamente simples. Hay muchas menos personas que pueden diseñar e implementar un sistema grande y complejo. La mayoría de estos últimos han estado desarrollando software durante años.

Entonces, ¿cómo llegas allí? Escribir programas Trabajar con desarrolladores más experimentados; intente comprender cómo piensan, por qué hacen las cosas de la manera en que lo hacen, y pídales que revisen y comenten su código. Escribe más programas. Trabaja en diferentes entornos (lenguajes, marcos, API, etc.). Escribe más programas.

Comencé a aprender a programar cuando tenía 11 años tomando un curso introductorio en el lenguaje de programación BASIC (en 1972). Me retiré porque el instructor era profesor de matemáticas y comencé a explicar las matrices en términos de vectores matemáticos y matrices. Si bien puede representar esas cosas utilizando matrices, no capturan la simplicidad de cómo funciona una matriz. Para un niño de 11 años, las matemáticas eran esotéricas y complejas. Me perdí totalmente y pensé que las matrices eran realmente complejas, difíciles de entender.

Comencé a enseñarme a programar unos meses más tarde, después de cumplir 12 años, escribiendo una simulación / juego simple del mercado de valores basado en datos históricos que encontré en la biblioteca de negocios de la universidad local. Me di cuenta de que las matrices realmente no son difíciles. De hecho, son realmente objetos bastante simples. Lo aprendí porque tenía una razón práctica para querer usarlos, lo que me motivó a profundizar, lo que me llevó a una verdadera comprensión de cómo funcionan bajo el capó.

La mayor parte del conocimiento de programación que tengo se aprendió de manera similar. Quería hacer algo, busqué recursos que lo explicaran o lo demostraran, y lo incorporé a cualquier proyecto (personal o laboral) que estaba desarrollando. La próxima vez que necesitaba hacer algo similar, pude construir sobre lo que había aprendido anteriormente, utilizando ese código como ejemplo.

Todo se reduce a la práctica. Cuanto más lo hagas, especialmente si aprendes a hacerlo bien, mejor serás.

Tuve exactamente este problema cuando estaba más fresco. Había cosas que parecían demasiado complicadas para que mi pequeño cerebro las entendiera. De hecho, rechacé la primera oferta de trabajo que recibí porque todos tenían grandes pilas de documentos impresos en sus archivadores, y supe, con toda la certeza de alguien que nunca había escrito nada grande, que mi magro cerebro simplemente no era grande. suficiente para entender un programa tan grande.

¿Entonces qué hice? Escribí código: piezas de código cada vez más grandes, hasta que ya no me intimidaron las grandes bases de código. Gradualmente adquirí las habilidades mentales y los hábitos de trabajo que hicieron comprensibles las grandes bases de código. Después de 10-15 años, sabía, con la certeza de la memoria muscular, que cualquier cosa que pudiera concebir, podría convertirme en código de trabajo, con suficientes horas.

Esto no significa que meterse en una base de código grande, desordenada e indocumentada sea particularmente fácil para mí, incluso ahora. Simplemente significa que lo he hecho, y sé cómo hacerlo, y tengo el recuerdo de tener éxito haciéndolo.

Vaya a trabajar para una empresa más grande cuando sea joven, donde haya pares más experimentados para hacer el trabajo pesado mientras aprende a ser un desarrollador de software.

Bueno, no solo inventaron el auto de la noche a la mañana. La computadora que usa ha llevado décadas de trabajo de desarrollo.

Los desarrolladores experimentados aprenden de sus errores.

El problema hoy es que las personas esperan el éxito sin fracasar. Gran parte del sistema educativo se trata de proporcionar la respuesta correcta. Este enfoque ignora los “errores” que los científicos e ingenieros cometieron para crear lo que damos por sentado.

Si fuera fácil, todos lo estarían haciendo. Pones el esfuerzo, cometes errores y te vuelves a cansar. Entonces, un día te das cuenta de que sabes más que la persona que acaba de comenzar.

Si tienes suerte 5 años después, sabes mucho más que ahora. Lo que podría haberle tomado un día descubrir ahora es solo unos segundos.

El conocimiento y las habilidades se obtienen lentamente, a menos que seas uno de esos tipos afortunados que leen algo y luego pueden hacerlo.

El software serio es complicado; Representa años de trabajo de un grupo de personas con talento. No esperes entenderlo desde el principio.

Aprender una gran pieza de software es un proceso lento. Generalmente les damos a los nuevos programadores algunos defectos para trabajar. Trazan la ejecución del problema específico que se les ha dado que resuelvan a medida que avanza por el código. De esa manera, aprenden algunas características importantes del programa. También nos gusta que los nuevos desarrolladores jueguen con el programa de trabajo, para que tengan una idea de lo que se supone que debe hacer.

Aprender el diseño a gran escala de una aplicación lo ayudará a comprender las piezas. Busque documentación de diseño para decirle qué objetos son los más importantes. También busque características en la interfaz de usuario y su código correspondiente; Esto le ayuda a ver qué acciones en la interfaz de usuario conducen a qué respuestas en el código en general.

Aprender a leer el código de otra persona es una habilidad en la que puedes trabajar mientras estás en la escuela. Encuentra un programa de código abierto que te intriga. Elija un defecto de su lista de errores e intente resolverlo. Leer el código que está allí es un trabajo duro, pero como todas las otras habilidades, se vuelve más fácil con la práctica. Arreglar algunos defectos en un proyecto de código abierto mejorará esa habilidad, y también le dará algo que puede incluir en su primer currículum, lo que le facilitará conseguir un trabajo cuando salga de la escuela.

¡La mejor de las suertes!

¡No te sientas mal si no entiendes el código fuente escrito por otros!

Las bases de código grandes son notoriamente difíciles de entender, incluso para programadores experimentados. A menudo escuchará a los programadores quejarse del código “desordenado” que heredaron de otra persona. El código no es necesariamente desordenado, pero fue escrito por otra persona, lo que dificulta su comprensión.

Aprendí la mayor parte de mi programación al:

  1. Haciendo , no leyendo .
  2. Lectura de libros y publicaciones de blog sobre conceptos de programación. El código de ejemplo en libros y blogs generalmente se despoja de todo, excepto el concepto que el autor está tratando de enseñarle, lo que hace que sea mucho más fácil de entender.

El software complejo y robusto está hecho de pequeñas piezas simples que funcionan.

Es solo una cuestión de tener una idea general correcta, desechar todo lo que no es absolutamente esencial, y luego dividir y conquistar el resto. Una vez que su primera versión esté fuera de la puerta, solo agregará características.

Cada gran sistema en el que he puesto mis ojos y que funcionó razonablemente bien comenzó como un pequeño sistema que hizo una o dos cosas bien.

El primer paso es aprender a hacer pequeñas modificaciones en grandes programas.

Hay tanta fuente abierta por ahí, que deberías buscar algo interesante en un idioma que conozcas y modificarlo. Si no puede pensar en un cambio, la mayoría de los proyectos tienen un sistema de boletos … pregunte en su lista de correo o foro o lo que sea si hay un boleto que un principiante pueda recoger.

Haga algunos de estos, y verá que comienzan a ser más fáciles, y puede comenzar a hacer cambios más grandes.

No hay ningún misterio en esto, es solo familiaridad y práctica para desarrollar la habilidad de leer códigos y comprender grandes bases de códigos.

Da un paso a la vez.

Seguir aprendiendo. No hay un punto mágico en el que puedas hacer cosas complejas y no pudiste antes.

Cada pieza de software está formada por piezas más pequeñas. A medida que adquiere experiencia, aprende a identificar las partes y cómo funcionan juntas. El software realmente complejo aún necesita ser construido a partir de piezas más simples. Reconocer cómo es parte de lo que aprendes si lo haces.

Experiencia. Los sistemas parecen complejos porque muchas veces son complejos. Pero a medida que gane experiencia mirando el código o escribiendo su propio código, comenzará a comprender las cosas que funcionarán y las que no. También comenzará a ver ciertos patrones que verá una y otra vez.

Como desarrollador sénior, puedo ver un sistema complejo y dividir ese sistema en su subsistema que le permite digerir la complejidad en fragmentos más pequeños.

Comience simple. Aprende sobre la abstracción. Me encontré con este libro electrónico hace unos días. No lo he leído todo, pero proporciona un enfoque estructurado para el diseño del programa. Podría hacer algo peor que probar lo que recomienda en algunos programas modestos. Creo que te dará buenos hábitos y perspectiva.

Cómo diseñar programas

Tenga en cuenta que tiene una base de “programación funcional”. Pero este tipo de pensamiento puede generalizarse a otras formas de hacer las cosas.

¡Buenos deseos!

Kurt Guntheroth lo clavó.

Un viaje de mil millas comienza con un solo paso.

Por lo general, de la misma manera que aprendes a nadar. Alguien (generalmente su primer jefe) lo arroja a una gran base de código indocumentada y depende de usted sobrevivir los primeros tres meses. Mi primer gran proyecto en el que me lancé fue el sistema operativo Android.

No tengo la arrogancia de suponer que puedo hacer un nuevo Android que sea bueno, pero puedo trabajar con confianza y corregir errores que surgen de manera bastante rápida y permanente.

Entonces, si desea trabajar con una gran base de código, elija una y sumérjase en ella, su cerebro desarrollará los hábitos que necesita para manejarla. Te sentirás estúpido e inútil durante el primer mes, pero durante el próximo año te sentirás crecer exponencialmente.