Me he encontrado con mi parte de código hermosamente escrito, sobre-ingenierizado... un momento estoy pensando “Esa es una forma interesante de hacer eso” y el siguiente minuto te estás preguntando “¿qué diablos está pasando aquí!”. • El El principio de (No vas a necesitarlo) es una buena manera de contrarrestar el exceso de ingeniería: las funcionalidades sólo deben implementarse cuando lo necesites, no sobre la posibilidad de que lo necesites. Ahora YAGNI Ahora En términos muy simples, la over-engineering está haciendo que el diseño de software / sistema sea más complejo de lo necesario; esto suele suceder porque desea agregar funcionalidad adicional a su componente para simplificar la implementación de A, solo para agregar la funcionalidad para B más tarde. Tenemos esta base de código para gestionar invitaciones; es una base de código heredada, heredada con deuda técnica que acumula interés. Cuanto más intentes trabajar en el código heredado, más algo en otro lugar se rompe. Tienes que revertir en la mayoría de los casos y comenzar todo. Trabajar alrededor del código heredado termina acumulando interés en la deuda técnica; en un principio, esto parecía arriesgarse a romper características en toda la aplicación o agregar más deuda técnica a la base de código. La tercera solución que encontramos fue la abstracción. Teníamos que encontrar maneras de modularizar nuevas características o mejoras a la aplicación, y exponer y compartir datos cuando fuera necesario. En un principio, esto parecía como un Hail Mary. Finalmente, podemos trabajar en esta base de código mangled con efectos secundarios mínimos. Estáb Cuando se colabora con varias personas en una base de código (lo que es casi siempre el caso), y para las empresas que están más interesadas en las características de envío que en la calidad del código, las revisiones de código siempre sufren. Para problemas como la sobreingeniería y la sobreabstracción, las revisiones de código tradicionales de línea por línea a menudo pierden estos problemas sistemáticos. Comprobar un componente creado hace unas semanas para apoyar la integración de una función, siguiendo el principio de DRY, y darse cuenta de que ahora hay 10 características interconectadas/similares que dependen del componente. Spaghetti en código seco Vivimos con el evangelio DRY (No te repitas) porque simplifica el trabajo, y los desarrolladores son inherentemente perezosos (de una buena manera).El principio DRY funciona bien con sistemas ortogonales: pequeños componentes autosuficientes combinados para formar un sistema. . Los sistemas deben estar compuestos por un conjunto de módulos cooperativos, cada uno de los cuales implementa la funcionalidad independientemente el uno del otro. Alıntılar - El programador pragmático: de viajero a maestro Kitap.Guru. Debe haber más énfasis en los sistemas ortogonales y en el código DRY; es más fácil combinar las funciones reutilizables que crea entre sí y escalarlas a medida que el repositorio progresa cuando no están hinchados y abstractos, en cuyo punto termina con un sistema rígido entrelazado tanto entre sí que será complicado conectar qué aspectos del código que no cumplen con una regla exacta, se encontrará duplicando el código porque hacer que funcione para una nueva conexión rompe un sistema viejo. Componentes complejos Sus componentes no deben centrarse únicamente en evitar la repetición, sino también en ser pequeñas abstracciones del sistema en general; de lo contrario, acabarán con componentes tan complejos que pueden romper fácilmente con un solo cambio a un componente conectado. Al crear código reutilizable, el enfoque debe ser escribir código que no depende de ningún otro bloque de código para funcionar de una manera determinada. La reutilizabilidad debe ser utilizada como una herramienta y no el objetivo; cuando tiene componentes de UI reutilizables con lógica de negocio o API en el mismo componente, se encuentra en una autopista hacia la abstracción excesiva. Comienza pequeño, y antes de darse cuenta de lo que está sucediendo, la enfermedad se ha infestado en todo su repositorio. Ahora no puede reutilizar el componente en una página diferente con Modelos para evitar la abstracción y la ingeniería excesiva Modularidad Modularidad Modularidad Modularidad Modularidad La modularidad implica descomponer su sistema en códigos/componentes más pequeños e independientes llamados módulos. Por favor, preste atención a la palabra "más pequeño"; es posible tener un módulo hinchado con más código de lo necesario, lo que crea una abstracción excesiva y debe evitarse. La abstracción excesiva es realmente solo un intento fallido de modularidad. Sus módulos deben ser capaces de funcionar independientemente de otros módulos, exponendo sólo los datos requeridos. Primera funcionalidad Un buen enfoque para construir sistemas ortogonales y evitar fácilmente la sobreabstracción es construir con funcionalidad primero, luego características; esto se alinea bien con la arquitectura basada en componentes (separación de componentes de la interfaz de usuario de los componentes estatales). La etapa de funcionalidad se centrará en las unidades más pequeñas de código reutilizables que se montan para implementar la característica. Una función de inicio de sesión consistirá en las siguientes funciones: recoger nombre de usuario y contraseña (UI), validar datos de usuario, redirigir al perfil de usuario / rechazar los datos de usuario recopilados. No hay medallas para el código demasiado sofisticado Después de escribir cada implementación de código, pregúntese si hay una forma más fácil o más sencilla de lograr el mismo resultado.La mayoría de nosotros hemos escuchado historias sobre código que puede ser editado o trabajado por sólo una persona en la empresa, lo que no es un hecho de orgullo.Escribir código que solo puede ser mantenido por usted probablemente significa que es demasiado sofisticado o emplea procedimientos no ortodoxos.Un gran ejemplo de codificación usando procedimientos no ortodoxos es el Hard Drives de Gilfoyle del artículo: Un antiguo empleado de una empresa es conocido por no revisar el código y por tener programas y partes de la base de código en su disco duro (imagínese el superávit para mantener ese producto!). “Hemos salido de las columnas” – La mejor, peor base de código de Jimmy Miller Me he encontrado escribiendo código demasiado sofisticado porque quiero usar una nueva tecnología / paquete / biblioteca que acabo de aprender, sin considerar si es la herramienta más simple para el trabajo. Finales En la búsqueda de escribir códigos perfectos que expliquen todos los posibles casos de futuro y viajes en el tiempo, terminas con una base de códigos sobre-ingenierizada. Deberías renunciar a ella porque no es posible escribir código perfecto, buscar lo suficientemente bueno como para satisfacer todos tus requisitos inmediatos. El principio DRY es fundamental; la repetición es todavía un pecado en el desarrollo de software. El principio DRY debe aplicarse a un sistema ortogonal para crear una base de códigos que se desconecta, con cada módulo independiente e intercambiando datos en un punto de reunión separado (modulo de característica). Estos te ayudarán a crear sistemas que son fáciles de mantener y deshabilitar. Recuerda que el simple siempre es mejor en el desarrollo de software.
