Hay muchas cosas que deben considerarse al hacer un sistema, tomemos por ejemplo un sistema basado en la web donde los usuarios inician sesión e interactúan entre sí, creando y editando contenido. Ahora tengo que pensar en la seguridad, la validación (ni siquiera creo que esté 100% seguro de lo que eso implica), "asegurarme de que los usuarios no se pisen mutuamente" (¿término para esto?), Evitando errores en muchos casos, ¿asegurarse de que los datos de la base de datos no se vuelvan problemáticos a través de situaciones inesperadas ...? Todas estas cosas que no sé cómo o dónde aprender, ¿hay un libro sobre este tipo de cosas? Como dije, parece haber una gran diferencia entre escribir código y escribir el código correcto, ¿sabes a qué me refiero? Siento que mi trabajo de programación actual carece de mucho de lo que he descrito y puedo ver los problemas que causa más adelante, y luego los problemas son mucho más difíciles de resolver porque existen datos y las personas los están usando. Entonces, ¿alguien puede señalarme libros o recursos o el subconjunto adecuado de programación (?) Para este tipo de aprendizaje?
PD: no dudes en corregir mis etiquetas, no sé de qué estoy hablando.
Editar: Supongo que algunos de los ejemplos que escribí se aplican a otros tipos de sistemas también, simplemente no conozco otros buenos ejemplos porque he estado involucrado principalmente en el trabajo web.
fuente
Cuando se trata de aplicaciones web, hay más buena información compilada en esta respuesta que cualquier otro lugar que haya visto.
Pero la realidad es que hay mucho que saber para armar bien un sistema completo. Hay estudios para respaldar 10,000 horas como la cantidad de práctica necesaria para alcanzar un nivel de dominio, y el desarrollo de sistemas de información no es una excepción a eso.
fuente
Me gusta mucho la respuesta de William Pietri (+1), pero creo que es necesario agregarla. Incluso suponiendo que lo que quiere decir con sistemas comprende únicamente software.
Pero antes de entrar en detalles, no conozco un libro para ayudar. Todo lo que sigue, lo aprendí por experiencia (es decir, los tres puntos que William hizo).
De lo que está hablando abarca un mínimo de cuatro roles generales. A veces, una persona puede llenar todos esos roles, para proyectos pequeños a medianos, pero cuando comienza en proyectos grandes, necesita al menos separar esos roles. Es difícil para alguien ser experto en todos ellos de manera significativa.
Analista de negocios
Esa es la persona que habla con el cliente y traduce sus requisitos en algo que un arquitecto puede tener sentido. Básicamente una lista de requisitos formulados adecuadamente. Esto incluye los requisitos funcionales obvios (¿qué debe ofrecer este sistema?), Pero también los requisitos no funcionales (¿cuáles son las características generales que debe cumplir el sistema? Esto puede incluir seguridad, confiabilidad, disponibilidad, resistencia, capacidad, rendimiento, solidez y otros requisitos similares desde el punto de vista del usuario).
Este es el primer paso de lo que debe hacer el sistema, el comienzo de un pensamiento serio.
Sistema arquitecto
Esta persona produce el marco técnico de alto nivel dentro del cual trabajar. Dan el esquema del plan de coincidencia. Las herramientas generales, técnicas, construcciones. Desglosan todo el sistema en componentes más pequeños, cómo encajan entre sí, cómo encajan con el mundo exterior ...
Esto ayuda de muchas maneras a refinar lo que se debe pensar. Muy a menudo se descubrirán problemas en esa etapa sobre los requisitos tal como los escribió el analista de negocios. Vuelva a ellos para algunas iteraciones para mejorar su comprensión de lo que quieren y su expresión de ello.
Diseñador de sistemas
Este rol trata sobre cómo hacer que todo funcione. Esto podría ser más trabajo en equipo que un espectáculo individual. Pero es probable que haya un diseñador líder para supervisar todo el diseño del sistema. Esta persona debe profundizar en los detalles y asegurarse de que la vista del arquitecto sea algo que realmente se pueda construir.
Espere un mayor refinamiento de la arquitectura del sistema y, por lo tanto, potencialmente del análisis comercial.
Gerente de pruebas
Este papel a menudo se olvida. Pero al final del día, si no puede probarlo, ¿cómo puede probar que puede construirlo? Debe haber una revisión de los resultados de todas las etapas: análisis comercial, arquitectura y diseño por parte de alguien competente en pruebas que pueda resaltar deficiencias y, por lo tanto, permitir correcciones tempranas, mucho antes de que se escriba cualquier código.
Ese es un breve resumen.
Esos muchachos / chicas son solo la corrida general de la gente del molino en la cadena para pensar en lo que se debe pensar.
Para proyectos complejos, como grandes aplicaciones bancarias o espaciales, solo para tomar dos ejemplos (piense entre cientos y miles de días-hombre), hay muchos expertos en la materia que los llamamos para revisar y apoyar proyectos en cada etapa. Estas funciones incluyen análisis de seguridad, dimensionamiento del sistema, capacidad, rendimiento, bases de datos, agrupación en clúster y muchas otras áreas de especialización tan estrechas, incluidas áreas comerciales precisas. La variedad de roles depende del tamaño y la complejidad de los sistemas.
Todo eso para decir que no debes intentar y saberlo todo, no lo harás. Sin embargo, puede obtener una idea general de la imagen y en proyectos pequeños puede profundizar mucho más que en proyectos grandes, simplemente porque el nivel de complejidad le permite ser más completo.
Si desea saber cómo diseñar sistemas, debe comenzar a hacer preguntas pensando de manera innovadora. Póngase lo suficiente en el lugar del cliente e intente pensar qué podría salir mal, qué debe probarse. Luego, reúnanse con un cliente real y pídales que expliquen las extensiones y los límites del sistema que imaginan que necesitan. Además, cada vez que digo "cliente", debe comprender que esto abarca a varias personas muy diferentes. Está la persona que usa el sistema día a día para lo que fue diseñado para hacer. Están el operador, el soporte técnico, el gerente que necesita algún informe u otro, el auditor, el equipo de infraestructura, la parte interesada que lo pagó, el gerente de calidad que necesita medios para probar su sistema ... Pregúnteles a todos (y si son una persona pídales que se pongan todos estos sombreros uno a la vez), así que pregúnteles a todos lo que necesitan y tendrá un buen comienzo para saber cuáles son los requisitos de su sistema. A partir de ahí puede derivar la arquitectura, y desde allí el diseño.
Para sistemas complejos (ya sea solo software o para integrarse con hardware en el sentido más genérico), no solo una persona no es suficiente para cada uno de los cuatro roles que enumeré anteriormente, sino que debe gestionar el proyecto incluso la definición de lo que el sistema debe hacer, y mucho menos las otras fases.
HPH, asm.
fuente
No es "un libro". Muchos libros.
No hay camino real
Derecha.
Estás hablando de "arquitectura", programación en general.
Paso 1. Lee mucho código. Un lote de verdad. Piensa en cosas que te gustaría hacer. Encuentra proyectos de código abierto relacionados. Lee el código. Todo ello.
Paso 2. Leer más código. Mucho más.
Paso 3. Leer libros sobre arquitectura.
fuente
Para amplificar leer muchos libros ...
Ahora que sabe que tiene un problema, hay algún punto en decirle que lea estos libros. (Antes de que hayas hecho un trabajo real, no tiene mucho sentido discutir estos libros)
Patrones de diseño de Gamma, Helm, Johnson y Vlissides Pattern Languages of Program Design 1,2,3 y 4.
Pero no intente aplicar cada patrón en cualquier lugar donde vea que podría usarse
eso también es malo.
Espero que esto ayude.
fuente
La mejor manera de aprender a hacer cualquier cosa es hacerlo. Si quieres aprender a hablar francés, tienes que hablar francés, y leer francés y escribir francés y leer sobre francés e ir a Francia y hablar con los franceses en francés. Si quieres saber cómo tocar el piano, debes tocar el piano. Tienes que tocar canciones simples y aprender la estructura del piano y la estructura de la música. Tienes que aprender a leer música y cómo expresar música a través de un piano con los dedos. Tienes que aprender cómo suena la música y qué tipo de sonidos puede hacer un piano frente a lo que puede hacer una guitarra, una flauta o un saxofón.
La programación es exactamente la misma. Si quiere saber cómo diseñar una base de datos, debe diseñar bases de datos. Si desea comprender la criptografía, implemente algoritmos criptográficos y protocolos criptográficos. Si desea escribir software que pueda servir a múltiples usuarios simultáneamente, debe comprender cómo funcionan los discos IO, IO de red y los hilos. Para comprender cómo funciona, tiene un código de escritura que lee y escribe desde archivos, transmite datos a través de una red y sincroniza el acceso a los recursos. Todo eso requiere práctica.
Un "sistema" es, en general, solo una colección de cosas. Piezas que se coordinan para formar un todo. Para construir algo grande, debes construir un montón de piezas pequeñas. Entonces, si desea aprender cómo construir sistemas, simplemente comience a construir sistemas. Tome un problema, descomponga en pedazos e implemente cada pieza uno por uno. Eventualmente tendrás un "sistema" integrado. Probablemente fallarás algunas veces en el camino, pero está bien. Si no está fallando, generalmente significa que no se está esforzando lo suficiente.
Además, recomendaría ir a la escuela para estudiar Ciencias de la Computación. Eso no ayudará demasiado con la parte de "práctica". Tendrá que hacerlo por su cuenta, pero ayudará con la parte de exposición. Aprenderá mucho, sobre casi todo lo relacionado con el funcionamiento de las computadoras y los sistemas informáticos, que es difícil de aprender por sí solo.
fuente