Capstone Week 5: el know-how es inútil sin 'know-why' y Cómo aprender marcos como un ingeniero

Aprender a usar un marco en sí mismo no es ingeniería de software. Aprender los problemas que resuelve el marco en sus dominios problemáticos está más cerca de la ingeniería de software. Si el proyecto en el que está trabajando presenta desafíos que van mucho más allá de lo que un simple marco puede solucionar, eso es ingeniería de software. Facebook usa React y también la aplicación de carrito de compras de práctica que construí en uno o dos días. Facebook es una increíble hazaña de ingeniería; mi aplicación de carrito de compras no lo es.

Hay algunos aspectos del aprendizaje de una nueva herramienta o marco que disfruto y otros que no. Disfruto aprendiendo sobre los problemas que resuelven los marcos o las compensaciones planteadas por diferentes métodos de estructuración de código. Por ejemplo, el patrón de diseño Flux me parece simplemente genial. La creación de una aplicación sin Flux se vuelve increíblemente desordenada, ya que debe pasar el estado de la aplicación a través de una multitud de componentes, solo para que esos componentes secundarios invoquen una larga cadena de funciones ancestrales hasta que el componente que posee el estado sea notificado del evento en uno de sus hijos, nietos, bisnietos, etc. Flux hace que sea astronómicamente más fácil pensar en lo que está haciendo una aplicación, cómo se gestiona su estado y de qué componentes son responsables incluso cuando crece la base de código.

Esto es en lo que debe centrarse al aprender un nuevo marco: ¿qué problemas resuelve y cómo? ¿Cuál es la filosofía de la que nació la solución? ¿Cuál es la arquitectura general y qué puntos débiles presenta esta arquitectura? ¿Qué creencias prescriptivas sobre cómo se debe resolver un problema informaron la creación de esta solución en particular, y comparte estas creencias? Si no los comparte, ¿debería? Un marco es mucho más que una herramienta: es una declaración sobre la forma en que se debe resolver un problema fundamental o muchos problemas fundamentales. Cuando tengo la tarea de aprender una nueva herramienta o marco, estas son las preguntas que hago. No me importa memorizar los matices exactos de la configuración del paquete web: eso vendrá con el tiempo, y si no es así, es algo que puedo investigar fácilmente en minutos. Puedo preguntarle a google qué significa un mensaje de error. No puedo preguntarle a Google si las decisiones de diseño de un marco y las compensaciones que introducen son con las que estoy de acuerdo.

Aprender bien un marco y aprenderlo rápidamente no es mutuamente excluyente si está armado con el conocimiento de los fundamentos del dominio en el que está trabajando. También debe priorizar su conocimiento de acuerdo con una agenda preconcebida. Mi agenda es casi siempre: "Comprender el" por qué "tanto como el" cómo ". La razón es esta: siempre será más competente con una herramienta si conoce su razón de existir y la (s) razón (es) de las decisiones detrás de su diseño. "¿Cómo?" Y "¿Por qué?" No son preguntas no relacionadas, y de hecho, tener una buena comprensión del "Por qué" fortalecerá su capacidad para usar el "Cómo". Esto se debe a que si comprende por qué la herramienta tiene las características específicas que tiene, entonces no solo tiene una idea de la herramienta en sí: tiene una idea de los procesos de razonamiento, de los cuales la herramienta es una manifestación. Eso significa que cuando inevitablemente se encuentra con un desafío técnico que no es apto para un conjunto memorizado de comandos y procedimientos, puede aplicar el razonamiento detrás de la herramienta en sí y navegar hacia una solución. Esa es la diferencia entre un usuario de framework y un ingeniero.

Así que aprendimos a reaccionJS como equipo esta semana. Danos otra semana y probablemente podríamos enviar un código de calidad de producción (y de hecho, nos darán otra semana). Esto se debe a que entendemos el dominio del problema lo suficiente como para saber qué errores debemos tener en cuenta (y sabemos cómo evaluar para evitar estos errores). En otras palabras, no haremos algo como construir un intercambio de cifrado que se base completamente en la validación del lado del cliente.