salary - architecture software

Ponerse al día en la arquitectura moderna

Question

No tengo ninguna calificación formal en ciencias de la computación, sino que me enseñé ASP clásico en los días del boom de las puntocom y conseguí un trabajo y mi carrera se desarrolló a partir de ahí. Era un programador seguro y, creo, bastante bueno en ASP 3, pero como otros han observado, uno de los problemas con ASP clásico fue que hizo un muy buen trabajo al esconder la esencia de http para que pudiera llegar a ser bastante competente como un programador sobre la base de una comprensión relativamente pobre de la tecnología con la que estaba trabajando.

Cuando cambié a .NET al principio lo traté como ASP clásico, desarrollando aplicaciones independientes como sitios web individuales simplemente porque no sabía nada mejor en ese momento. Hice trabajos en este punto y pasé los siguientes años trabajando en un solo sitio cuya arquitectura se basaba en gran medida en objetos personalizados: en otras palabras, adquirí mucha experiencia trabajando con .NET como una herramienta de desarrollo de nivel medio utilizando una herramienta bastante antigua. enfoque de moda para el diseño de OO siguiendo las líneas del ejemplo clásico de clase de "automóvil" que se usa tan a menudo para enseñar OO. Desglosando programas en bloques de funcionalidad y basando sus clases y métodos alrededor de eso. Aunque trabajamos bajo un enfoque ágil para administrar el trabajo, toda la configuración fue clásica cliente / servidor. Eso fue lo que me convino y gradualmente empecé a familiarizarme con .NET y comencé a usarlo mucho más de la manera que debería, y empecé a ver el poder inherente a la tecnología y precisamente por qué era mucho mejor que el viejo ASP 3 .

En mi último trabajo, me encontré repentinamente en el extremo profundo con dos programadores muy jóvenes, expertos y muy avanzados. Han construido una arquitectura de sitio que se basa en un montón de cosas que son nuevas para mí y que, en verdad, tengo muchos problemas para entender. La aplicación se basa en un modelo de computación en la nube con múltiples tenencias y la arquitectura se acopla de manera flexible mediante una gran cantidad de interfaces, fábricas y similares. Ellos usan nHibernate mucho también. Poco después de unirme, ambos se fueron y ahora soy supuestamente el desarrollador principal de un sistema cuya tecnología y arquitectura realmente no entiendo y de la que no tengo a nadie a quien hacer preguntas.

Excepto tú, el internet.

Francamente, siento que me han echado en el extremo profundo y me estoy hundiendo. No estoy seguro de si esto se debe a que carezco de la formación académica para entender esto, si simplemente no tengo la matemática suficiente para la computación moderna (mis matemáticas nunca fueron excelentes; mi enfoque del diseño es a menudo simplemente depurar hasta que funciona , luego refactorice hasta que se vea limpio), o si simplemente se me ha presentado una naturaleza demasiado radical a la vez. Pero la única manera de descubrir cuál es es tratar de aprenderlo.

Entonces, ¿alguien puede sugerir algunos buenos lugares para comenzar? ¿Buenos libros, tutoriales o blogs? He encontrado una gran cantidad de material de Internet que simplemente presupone un nivel de comprensión que simplemente no tengo.

Su consejo es muy apreciado. ¡Ayuda a un entusiasta de mediana edad, atascado en el desarrollador de lodo, a que se vuelva entusástico!

¡Por favor!

Answer 1

Francamente, siento que me han echado en el extremo profundo y me estoy hundiendo. No estoy seguro de si esto se debe a que carezco de la formación académica para entender esto, si simplemente no tengo la matemática suficiente para la computación moderna (mis matemáticas nunca fueron excelentes; mi enfoque del diseño es a menudo simplemente depurar hasta que funciona , luego refactorice hasta que se vea limpio), o si simplemente se me ha presentado una naturaleza demasiado radical a la vez. Pero la única manera de descubrir cuál es es tratar de aprenderlo.

Para mí es por su falta de formación académica. Las personas que aprenden a sí mismas o en el trabajo a menudo no tienen los antecedentes necesarios para entender realmente lo que está detrás de la escena de un marco. Algunos conceptos son generales para todos los sistemas informáticos y los aprendemos en la escuela, por lo que podemos entender cómo funcionan estos conceptos en todos los idiomas ... Pareces más un programador pragmático (¿y eficiente?), Pero cometerás errores si no lo haces. No tengo ese fondo general (pero deberías saber que no estás solo en este caso ... particularmente php dev, creo que tampoco tengo este fondo).

Cómo entender la relación del código con DB, ORM como Hibernate, si no sabes exactamente qué es una transacción (supongo que sabes cómo usarlo ... (¡pragmático, dije!) Pero nunca has oído hablar de conceptos como ACID: http://en.wikipedia.org/wiki/ACID , supongo que no sabes mucho sobre el aislamiento de transacciones).

Cómo usar soa architecture con webservices, rpc, rmi, corba ... de manera eficiente y poder tener datos consistentes en su db si no conoce algunos conceptos como el 2 phaze commit http://en.wikipedia.org/wiki/Two-phase_commit_protocol

¿Cómo escribir un buen código si no conoce muchos patrones de diseño, mejores prácticas y no sabe cuándo usarlos?

Podríamos decir muchas cosas.

El hecho es que simplemente se pierde una parte del conocimiento general informático que los estudiantes de ingeniería tienen (¿normalmente?). Cuando comenzamos a trabajar después de una escuela de ingenieros, no somos expertos en estas cosas, pero la única diferencia con usted es que sabemos que existe un concepto muy importante y cuándo deben usarse. Por lo tanto, solo tenemos que leer sobre eso y aplicar lo que aprendemos de la web o de nuestro equipo (porque en la escuela apenas vemos lo básico, pero en muchos técnicos).

Realmente creo que nada es imposible para ti, solo deberías decir muchas cosas sobre conceptos generales que no conoces y de los que has escuchado mucho. Sin este conocimiento, solo tenderá a reinventar la rueda y con su pragmatismo encontrará soluciones alternativas que ciertamente funcionan pero que están un poco sucias ... Por ejemplo, su desarrollador podría funcionar pero cuando introduce una carga alta en su sistema, puede Tienen problemas de concurrencia, problemas de rendimiento. Esta falta de conocimiento no es una cuestión cuando estás en un contexto simple, pero es realmente necesario cuando tienes muchas responsabilidades en un sistema complejo ...

Answer 2

Además de muchos recursos excelentes que ya figuran en las respuestas y que probablemente se incluirán en la lista, un consejo ligeramente diferente: utilice .

Parece que eres capaz de escribir muy bien pensado, legible y me atrevo a decir buenas preguntas.

Por lo tanto, siempre que una determinada elección / patrón arquitectónico específico o una pieza de código no tenga sentido, siéntase libre de convertirlo en una pregunta SO (obviamente, idealmente, después de haber investigado un poco usted mismo).

Además, con respecto a su punto re: math:

En lo que respecta a la ingeniería de software, las únicas matemáticas que realmente necesitas la mayoría del tiempo son:

• "Matemáticas discretas": conjuntos, gráficos, árboles, etc ... y sus aplicaciones prácticas para estructuras de datos y algoritmos

• Un conjunto limitado de habilidades de álgebra involucradas en el análisis de complejidad O (n) para este último

• Idealmente, una comprensión intuitiva de estadísticas / probabilidad: como ingeniero de software genérico, no siempre tiene que ser capaz de hacer cálculos avanzados, pero una idea de "esto es más probable que tenga un impacto en mi situación en función de su probabilidad de suceder tiempos El tamaño del impacto "es a menudo una buena guía en las opciones de diseño.

Sin embargo, UNA cosa que tiene un valor incalculable en un buen ingeniero de software es lo que distingue a una persona "buena en matemáticas" de "no buena en matemáticas", aunque no esté estrictamente relacionada con las matemáticas, es la capacidad de ver patrones.

Si la razón por la que "no eres bueno en matemáticas" es que te falta esa habilidad para observar patrones, estarás en una gran desventaja. Esa es una habilidad / habilidad que debes entrenar en ti mismo sobre todos los demás para tener éxito en la arquitectura de sistemas, IMHO.

Answer 3

Aquí hay algunas sugerencias, de ninguna manera una respuesta completa o una respuesta todo en uno;

• Haga tiempo en su día de trabajo para aprender sobre las nuevas cosas. Aprovecha esta hora en tu jornada laboral porque es parte de tu trabajo. No es algo que debas hacer solo en las noches o los fines de semana. Si desea dedicar parte de su propio tiempo a aprenderlo, siga adelante, pero no deje de reconocer que el aprendizaje es parte de su trabajo y no piense que debe ocultar su ignorancia en casa o que No saberlo todo es fatal para tu carrera. Depende de usted para equilibrar el tiempo de aprendizaje y el tiempo de trabajo.

• Obtenga algunas hojas grandes de papel y una caja de lápices de colores (o MS Visio si lo prefiere). Empieza a dibujar dos tipos de diagramas:

  • Mapas mentales, para diagramar su comprensión de las nuevas tecnologías. Si no sabes qué son los mapas mentales, pulsa Wikipedia para comenzar.
  • Diagramas arquitectónicos del sistema del que eres responsable. Depende de usted si utiliza UML u otro formato ampliamente utilizado o uno de sus propios diseños.

Answer 4

Si se trata de arquitectura, siempre veo Pattern & Practices si se trata de la pila de desarrollo de Microsoft.

Tienen una gran cantidad de buenos informes / libros sobre arquitectura para todo tipo de aplicaciones.

Answer 5

También he visto casos como el tuyo en el pasado. Pero con la dedicación de la lectura diaria y la participación, parece que están funcionando tan bien como cualquier otro "programador joven y así llamado bueno". Si estuviera en tu lugar, esto es lo que haría:

• Divide mis áreas problemáticas en pedazos más pequeños.
• Buscaremos libros / artículos disponibles sobre los temas en la lista mencionada anteriormente.
• Codificaré muestras por mí mismo y experimentaré con ellas para obtener una mayor comprensión.

Dicho esto, no te preocupes por no tener una mente matemática. Soy estudiante de matemáticas y, honestamente, no hay muchas ocasiones en las que tengo que usar esas habilidades. La mayoría de las aplicaciones empresariales no requieren ese tipo de habilidades matemáticas. Además, las apis modernas del día son tan avanzadas y fáciles de usar que nunca tendría que preocuparse por escribir un orden de clasificación eficiente o algo por el estilo.

Trate de leer tanto como sea posible en los patrones de diseño. Para comenzar, "Head First Design Pattern" es un excelente libro, pero los ejemplos de código están en Java (lo que no debería importar en realidad). "UML Distilled" es otro buen libro. Hay muchos otros disponibles, solo google :). Además, revisa tu sistema existente de manera exhaustiva.

todo lo mejor..

Answer 6

Patterns of Enterprise Application Architecture es un excelente libro, Martin es una leyenda.

Answer 7

Sentado en la playa - Preparación

Haga una lista de todo lo que no entiende. En la etapa final, esta lista será su lista de verificación. Aclare su mente: comience de nuevo, "olvide" todos los confusos detalles que ya conoce sobre su arquitectura. Desentierra todos los documentos creados por los arquitectos originales. Obtenga las documentaciones para cada tecnología utilizada en su proyecto. Hacer café.

Flotando - Manejando la Complejidad

Para flotar, necesitas gestionar la complejidad. Si no maneja la complejidad adecuadamente, profundizará en los detalles cuando no sea absolutamente necesario, y no sabrá cómo y dónde detenerse, hundirse directamente en el fondo y ahogarse.

"Mi enfoque del diseño a menudo es simplemente depurar hasta que funcione, luego refactorizar hasta que se vea limpio"

Creo que solía ser como tú. Desarrollé soluciones comenzando desde cero y agregando una pieza a la vez, y finalmente contenía una estructura compleja dentro de mi cabeza. No planifiqué la arquitectura, no separé el diseño y la implementación, simplemente codifiqué, depuré y reformulé. Funcionó: como la complejidad creció lentamente, no tuve problemas para entender la arquitectura que emergió.

Este enfoque simplemente no es lo suficientemente bueno cuando se "hereda" una arquitectura compleja planificada por otros; no puede tragar toda la estructura a la vez, porque hay demasiados detalles y no puede tragar pequeños trozos al azar, porque no entenderá cómo se relacionan entre sí y nunca podrá ver el panorama general.

El software es un enigma de la gestión de la complejidad. Hay piezas muy grandes, a veces referidas como "subsistemas", que componen el panorama general. Cada uno de estos está compuesto por piezas más pequeñas, que a su vez también están compuestas por piezas más pequeñas. Cuando miras el código, todo lo que ves son las piezas más pequeñas. Así que olvídate del código por ahora, al menos hasta que veas todas las piezas más grandes.

Natación - Mapeo de la Arquitectura

El primer paso hacia la flotación es ver las piezas grandes. Para hacer eso, necesitas mapas. El mapa de las piezas más grandes es la arquitectura de más alto nivel. Si los arquitectos originales te dejaron sin dicho mapa, deberás crearlo tú mismo. Al igual que es imposible mapear una región desde el interior de un valle, no puede mapear su arquitectura desde detalles de bajo nivel. Necesitas pararte en la cima de una montaña para obtener una vista de 360 ​​grados de todos los valles, colinas y caminos. Necesitas mapear tu arquitectura desde la parte superior.

Después de tener este mapa de nivel superior, debe obtener mapas para las partes que lo componen, al igual que crea un mapa no detallado de una región completa y luego crea mapas detallados separados de subregiones. Un mapa debe describir los diferentes subsistemas. Como mínimo, debe describir las responsabilidades de cada subsistema, su interfaz externa y cómo interactúa con otros subsistemas.

Buceo - Gestión de los detalles

Hay un principio en el buceo que dice que no debes moverte entre profundidades demasiado rápido, debido a los cambios en la presión. Este principio se mantiene. Cuando pase de tratar con un subsistema a tratar con uno de sus subsistemas internos, asegúrese de sumergirse únicamente en el siguiente nivel de complejidad / abstracción. Deja que tu mente maneje un nivel a la vez.

Conceptos separados, patrones, interfaces e implementaciones. nHibernate es una solución de Mapeo Relacional de Objetos (ORM). Por lo tanto, antes de lidiar con los detalles de nHibernate, debe asegurarse de que comprende el concepto general de ORM y su lugar en el mundo. Factory es un patrón de diseño, por lo que antes de tratar con Factory, debe comprender qué son los patrones de diseño y cuál es su función.

Las tecnologías suben y bajan, pero los conceptos permanecen. Una vez que obtiene los conceptos, realmente no importa mucho, a nivel arquitectónico, cómo se manifiestan estos conceptos.

El hecho de que su arquitectura esté débilmente acoplada es en realidad algo bueno, porque significa que puede comprender el rol de un subsistema sin la necesidad de saber mucho sobre otros subsistemas. El hecho de que su arquitectura haga uso de las interfaces también es bueno: significa que puede aprender cómo los elementos interactúan entre sí sin saber cómo funcionan internamente.

Esquí acuático - Adquirir conocimiento destilado

Hay un libro que creo que es un "lectura obligada": Código completado por Steve McConnell. Cambió mi vida profesional.

Espero que esta publicación haya podido ayudarte de alguna manera y no sea un desperdicio completo de tu tiempo.