Leyes de programación

Leyes, teorías, principios y patrones útiles para los desarrolladores.


Introducción


Traducción de repositorio github.com/dwmkerr/hacker-laws

En las discusiones relacionadas con el desarrollo de software, las personas a menudo hablan de diferentes leyes. Este repositorio almacena enlaces y descripciones de algunos de los más famosos.

Contiene explicaciones de algunas leyes, principios y leyes, pero no hay agitación a su favor. Usarlos o no siempre es un punto discutible, y todo depende de en qué estés trabajando.

Las leyes


Ley de Amdahl


La ley de Amdahl es una fórmula que demuestra el potencial para acelerar una tarea computacional que se puede lograr con un aumento en la cantidad de recursos del sistema. Por lo general, se usa en computación paralela y puede predecir los beneficios reales de aumentar el número de procesadores, teniendo en cuenta las limitaciones de paralelismo del programa.

Damos un ejemplo. Si el programa consta de dos partes: la parte A, que debe ejecutarse en un procesador, y la parte B, que puede paralelizarse, está claro que las ventajas de agregar varios procesadores al sistema que ejecuta el programa son limitadas. Potencialmente, esto puede acelerar enormemente la parte B, pero la velocidad de la parte A no cambiará.

El siguiente diagrama muestra ejemplos de posibles ganancias de velocidad:



Como puede ver, incluso si el 50% del programa puede ser paralelo, los beneficios de agregar más de 10 procesadores separados serán insignificantes. Si el programa se puede paralelizar en un 95%, las mejoras serán notables incluso después de agregar miles de procesadores.

Con la Ley de Moore disminuyendo y el procesador acelerando, la paralelización se convierte en la clave para mejorar la eficiencia. La programación gráfica es un gran ejemplo: la programación moderna basada en sombreadores le permite dibujar fragmentos de la imagen en paralelo, por lo que en las tarjetas gráficas modernas puede encontrar miles de núcleos de procesador (GPU o módulos sombreadores).

Teoría de ventanas rotas


La teoría de las ventanas rotas afirma que los signos visibles de delincuencia (o la falta de preocupación por el medio ambiente) implica un aumento en el número y la gravedad del delito (y un mayor deterioro del medio ambiente).

Esta teoría se ha aplicado al desarrollo de software, lo que sugiere que la mala calidad del código (o la llamada " deuda técnica ") puede causar la sensación de que todos los intentos de mejorar la calidad serán ignorados o subestimados, lo que conducirá a la aparición de un nuevo código incorrecto. Este efecto se desarrolla en cascada, por lo que la calidad se deteriora con el tiempo.

Ley Brooks


Agregar recursos humanos adicionales a un proyecto tardío retrasó su producción aún más.


La ley Brooks dice que, en muchos casos, los intentos de acelerar el lanzamiento de un proyecto que ya está retrasado agregando personas adicionales al mismo conducen al hecho de que el proyecto se lanza incluso más tarde de lo que podría. Sin embargo, Brooks enfatiza que esto es una simplificación excesiva del problema. Razonó de la siguiente manera: dados los costos del tiempo requerido para comisionar nuevos recursos y la comunicación de las personas entre sí, en el corto plazo la tasa de desarrollo del proyecto disminuye. Además, muchas tareas pueden no estar sujetas a separación, es decir, no se pueden distribuir fácilmente entre los recursos, cuya cantidad se ha incrementado, por lo que el aumento potencial de la velocidad no es tan significativo.

El dicho común "nueve mujeres no pueden dar a luz a un bebé en un mes" se refiere a la ley de Brooks, en particular porque algunos tipos de trabajo no pueden dividirse o paralelizarse.

Este es el tema principal del libro Mythical Man-Month.

Ley Conway


La ley de Conway dice que las limitaciones técnicas del sistema diseñado reflejarán la estructura de la organización. A menudo se lo recuerda cuando trata de mejorar la organización. La ley dice que si una organización está estructurada en muchos módulos pequeños y no relacionados, entonces el programa que crea será el mismo. Si la organización se construirá alrededor de verticales, en función de ciertas características o servicios, entonces su software reflejará este hecho.

Ley de Cunningham


La mejor manera de encontrar la respuesta correcta en Internet no es hacer una pregunta, sino publicar una respuesta deliberadamente incorrecta.


Stephen McGeady dice que a principios de la década de 1980, Ward Cunningham le dio un consejo: "La mejor manera de encontrar la respuesta correcta en Internet no es hacer una pregunta, sino publicar una respuesta deliberadamente incorrecta". McGeady lo llamó "Ley de Cunningham", aunque el propio Cunningham lo niega y dice que se le "cita incorrectamente". Aunque la frase originalmente se refería a la comunicación en Usenet, la ley se ha utilizado desde entonces para describir el trabajo y otras comunidades (Wikipedia, Reddit, Twitter, Facebook).

Número de Dunbar


El número de Dunbar es un límite en el número de lazos sociales permanentes que una persona puede mantener. Esto se refiere a las relaciones que implican el conocimiento de las características distintivas de un individuo en particular, la conexión con la que debe mantenerse, su carácter, así como su estado social y sus conexiones con otras personas.

El número exacto de tales relaciones es desconocido. Dunbar mismo sugirió que una persona puede soportar cómodamente no más de 150 de esas conexiones. Lo describió en un contexto más social: "El número de personas a las que no dudes en unirte sin una invitación a beber juntos si accidentalmente te encuentras con ellos en el bar". Por lo general, las estimaciones de este número varían de 100 a 250.

Al igual que las relaciones estables entre las personas, mantener la relación de un programador con el código requiere mucho esfuerzo. Cuando nos enfrentamos a proyectos grandes y complejos o con la propiedad de muchos pequeños, confiamos en ciertos acuerdos, políticas y procedimientos. Es importante considerar el número de Dunbar no solo al aumentar el número de empleados, sino también al determinar la escala del equipo o el momento en que el sistema debe adquirir herramientas auxiliares para el modelado y la automatización de la logística. En el contexto de la ingeniería, este es el número de proyectos (o la complejidad normalizada de un proyecto) para los que se incluiría con confianza en el grupo de soporte de código.

Ley Goll


Un sistema complejo de trabajo necesariamente proviene de un sistema simple de trabajo. Un sistema complejo diseñado desde cero nunca funciona, y es imposible arreglarlo para que funcione. Debe comenzar de nuevo con un sistema de trabajo simple.


La ley de Goll sugiere que los intentos de desarrollar un sistema muy complejo probablemente fracasarán. Los sistemas de alta complejidad rara vez se crean de una sola vez: evolucionan de los más simples.

Un ejemplo clásico es una red mundial. En el estado actual, es un sistema de alta complejidad. Sin embargo, inicialmente se identificó como una forma simple de intercambiar contenido entre instituciones. Ella superó con éxito estos objetivos y evolucionó, convirtiendo el tiempo en uno más complejo.

Goodhart law


Cualquier patrón estadístico observado tiende a colapsar tan pronto como se ejerce presión sobre él para controlarlo.


También a menudo se formula como:
Cuando una medida se convierte en una meta, deja de ser una buena medida.
Marilyn Strain


La ley establece que la optimización basada en ciertas medidas puede conducir a la depreciación de estas medidas. Las medidas excesivamente selectivas (KPI) aplicadas a ciegas a un proceso producen distorsión. Las personas se esfuerzan por optimizar el proceso localmente, "engañando" al sistema para satisfacer una determinada métrica, en lugar de prestar atención al resultado global de sus acciones.

Ejemplos:

  • Las pruebas sin reclamos satisfacen las expectativas para la cobertura del código, a pesar del hecho de que dicha métrica se creó para que el programa se haya probado bien.
  • Evaluar la efectividad del desarrollador en función del número de líneas contribuidas al proyecto conduce a una hinchazón injustificada del código.

Navaja Hanlon


Nunca atribuyas malicia a lo que se explica completamente por la estupidez.
El principio establece que las acciones que conducen a un resultado negativo podrían llevarse a cabo no con malas intenciones. El resultado negativo es más probable debido al hecho de que estas acciones y sus consecuencias no se entendieron bien.

Ley de Hofstader


Siempre lleva más tiempo completar una tarea de lo que espera, incluso si tiene en cuenta la ley de Hofstader.

Puede encontrar referencias a esta ley cuando trate con estimaciones del tiempo dedicado a un proyecto. En el campo del desarrollo de software, parece obvio que no somos muy capaces de estimar con precisión el tiempo necesario para completar el proyecto.

Cita del libro " Gödel, Escher, Bach: This Endless Garland ".

Ley hutber


La mejora es equivalente a la destrucción.

Esta ley establece que la mejora de una parte del sistema conduce a la destrucción de otras partes u oculta otros tipos de destrucción, lo que generalmente conduce a la degradación del sistema en comparación con su estado actual.

Por ejemplo, disminuir el tiempo de respuesta en una determinada parte del sistema puede conducir a un aumento en su rendimiento y, como resultado, a problemas con la capacidad en algún punto de la ruta del flujo de solicitud, lo que puede afectar a otro subsistema.

El ciclo del bombo y la ley de Amar


Tendemos a sobreestimar el impacto de la tecnología a corto plazo y a subestimarla a largo plazo.

El ciclo exagerado es una visualización del entusiasmo y el desarrollo de la tecnología a lo largo del tiempo, originalmente construida por Gartner. El gráfico lo ilustra mejor:


después del advenimiento de la tecnología, su popularidad alcanza el pico de expectativas hinchadas, luego se sumerge en la depresión, se eleva a lo largo de la pendiente de la iluminación y alcanza la meseta de la productividad.

En resumen, el ciclo argumenta que una fuente de entusiasmo generalmente surge en torno a las nuevas tecnologías y sus posibles consecuencias. Los equipos a menudo se vuelven adictos rápidamente a estas tecnologías y a menudo se sienten decepcionados con los resultados. Quizás esto se deba a que la tecnología aún no está suficientemente desarrollada o los métodos para su aplicación aún no se han pensado. Después de un cierto tiempo, aumentan las capacidades de la tecnología y aumenta el número de aplicaciones prácticas, después de lo cual los equipos pueden finalmente ser productivos.

Ley de hiram


Cuando llegue a un número suficiente de usuarios de API, no importa qué características le prometió a todos: para cualquiera de las posibles características del comportamiento de su sistema, habrá un usuario dependiendo de ello.


La ley de Hiram postula que si su API tiene suficientes usuarios, habrá un usuario que dependa de ella para cualquiera de los posibles comportamientos de su sistema (ni siquiera se describe en el contrato público). Un ejemplo trivial serían las características API no funcionales, como el tiempo de respuesta. Un ejemplo más sutil son los consumidores que confían en determinar el tipo de error aplicando la función regex a su descripción. Incluso si el contrato público no dice nada sobre el contenido del mensaje e implica que los usuarios deben usar el código de error, algunos de ellos pueden decidir usar el mensaje, y cambiar el mensaje romperá la API para estos usuarios.

Ley Kernigan


El código de depuración es dos veces más difícil que escribirlo. Por lo tanto, si escribe código hasta el límite de sus habilidades mentales, usted, por definición, no tendrá suficiente inteligencia para depurarlo.


La ley de Kernigan lleva el nombre de Brian Kernigan y está tomada de un libro escrito por él y Plauger: "Elementos de un estilo de programación".

Todos saben que el código de depuración es dos veces más difícil que escribirlo. Por lo tanto, si está haciendo todos sus esfuerzos mentales al escribir código, ¿cómo va a depurarlo?

Aunque la ley es una hipérbole, afirma que es mejor usar un código simple que complejo, ya que la depuración de cualquier problema que surja en un código complejo puede ser demasiado costosa o incluso imposible.

Ley de Metcalf


En teoría de la red, la utilidad de una red crece aproximadamente como un cuadrado del número de sus usuarios.

La ley se basa en el número de posibles conexiones por pares dentro del sistema, y ​​está estrechamente relacionada con la ley de Reed. Odlyzhko y otros argumentaron que las leyes de Reed y Metcalf exageraron el valor del sistema, sin tener en cuenta las limitaciones de la comprensión humana de la red; Ver el número de Dunbar.

Ley de Moore


El número de transistores colocados en un chip de circuito integrado se duplica aproximadamente cada 24 meses.

La predicción de Moore , que a menudo se usa para demostrar la tremenda velocidad de mejorar las tecnologías de fabricación de chips y semiconductores, fue sorprendentemente precisa y funcionó desde la década de 1970 hasta finales de la década de 2000. En los últimos años, la tendencia ha cambiado ligeramente, en particular, debido a las limitaciones físicas de la miniaturización de los componentes. Sin embargo, el progreso de paralelización y los cambios potencialmente revolucionarios en la tecnología de semiconductores y las computadoras cuánticas pueden significar que la ley de Moore puede seguir siendo cierta durante las próximas décadas.

Ley de murphy


Todo lo que puede salir mal saldrá mal.

La Ley de Murphy, escrita por Edward A. Murphy, postula que cualquier cosa que pueda salir mal necesariamente saldrá mal.

Este dicho es utilizado a menudo por los desarrolladores. A veces suceden cosas inesperadas durante el desarrollo, las pruebas o incluso en la producción. Se puede asociar con la ley de la maldad, que se usa con mayor frecuencia en Gran Bretaña [de hecho, también se conoce en Rusia / aprox. traducción]:
Si algo puede salir mal, sucederá, y en el peor momento posible.

Por lo general, estas "leyes" se usan en un sentido humorístico. Sin embargo, fenómenos como el sesgo de confirmación y el error de selección sistemática pueden hacer que las personas estén demasiado interesadas en estas leyes (en la mayoría de los casos, cuando todo funciona como debería, nadie se da cuenta de esto, pero las negativas son más notables y atraen más discusión).

La navaja de Occam


No debes multiplicar las cosas innecesariamente.

La navaja de afeitar de Occam afirma que de las pocas soluciones posibles, la solución que contiene la menor cantidad de conceptos y suposiciones será la más probable. Esta solución será la más simple y solo resolverá el problema dado sin introducir dificultades aleatorias y posibles consecuencias negativas.

Ley de Parkinson


El trabajo llena el tiempo asignado a ella.

En el contexto original, la ley se basó en el estudio de la burocracia. Pesimista, se puede aplicar al desarrollo de software, suponiendo que el equipo trabajará de manera ineficiente hasta que la fecha límite del proyecto comience a acercarse, y luego tendrá prisa por entregarlo a tiempo, lo que hace que la fecha de finalización específica sea bastante arbitraria.

Si lo combina con la ley de Hofstader, obtendrá una visión aún más pesimista: el trabajo se expandirá hasta que se complete todo el tiempo requerido para completarlo, y aún así tomará más de lo esperado.

El efecto de la optimización prematura


La optimización prematura es la fuente de todos los males.

En el trabajo de Donald Knuth "Programación estructurada con GoTo", escribió: "Los programadores pasan mucho tiempo pensando y preocupándose por la velocidad de ejecución de partes no críticas de los programas, y tratar de hacerlos más efectivos tiene un fuerte efecto negativo si piensas en depurarlos y apoyarlos. Necesitamos olvidarnos de la eficiencia sin importancia del 97% del tiempo: la optimización prematura es la raíz de todos los males. Sin embargo, en el crítico crítico 3% de los casos, no debemos perder nuestra oportunidad ".

Sin embargo, la optimización prematura también se puede describir como un intento de optimizar algo antes de que comprendamos lo que debemos hacer.

Ley Patt


El sector tecnológico está dominado por dos tipos de personas: los que entienden que no controlan y los que controlan lo que no entienden.


Por ley, Patta a menudo debería concluir que Patta:
En cualquier jerarquía técnica, con el tiempo se desarrolla una inversión de competencia.

Estas declaraciones sugieren que debido a diferentes criterios de selección y tendencias de organización grupal, siempre habrá un cierto número de personas con experiencia en los niveles de trabajo de la organización técnica, y siempre habrá personas a nivel gerencial que no tienen idea de las complejidades y problemas del trabajo que manejan.

Sin embargo, vale la pena enfatizar que tales leyes son una generalización muy cruda, y pueden ser aplicables a algunos tipos de organizaciones, y no aplicables a otros.

Ley de Reed


La utilidad de las grandes redes, especialmente las redes sociales, aumenta exponencialmente con el crecimiento del tamaño de la red.

Esta ley se basa en la teoría de grafos, donde la utilidad se escala como el número de subgrupos posibles, creciendo más rápido que el número de participantes o posibles conexiones por pares. Odlyzhko y otros argumentaron que las leyes de Reed y Metcalf exageraron el valor del sistema, sin tener en cuenta las limitaciones de la capacidad humana para comprender la red; Ver el número de Dunbar.

La ley de conservación de la complejidad (Ley de Tesler)


La ley establece que el sistema tiene una cierta complejidad, que no se puede reducir.

Parte de la complejidad del sistema puede ocurrir involuntariamente. Es el resultado de una estructura deficiente, errores o modelos fallidos del problema que se está resolviendo. La complejidad involuntaria se puede reducir o eliminar. Sin embargo, algunos tipos de complejidad son una consecuencia integral de la complejidad de la tarea misma. Esta complejidad se puede mover, pero no eliminar.

Uno de los elementos interesantes de esta ley es la suposición de que incluso con la simplificación de todo el sistema, su complejidad interna no disminuye, sino que va al usuario, que tiene más dificultades para comportarse.

La ley de las abstracciones que fluyen


Todas las abstracciones no triviales están sujetas a un cierto límite.

Esta ley establece que las abstracciones, que generalmente se usan en TI para simplificar el trabajo con sistemas complejos, en ciertas situaciones se filtran, permitiendo que los elementos de los sistemas subyacentes fluyan hacia arriba, por lo que la abstracción comienza a comportarse de manera impredecible.

Un ejemplo es descargar un archivo y leer su contenido. La API del sistema de archivos es una abstracción de los sistemas de kernel de nivel inferior, que a su vez son una abstracción de los procesos físicos asociados con el cambio de datos en una placa magnética (o en una memoria flash SSD). En la mayoría de los casos, funcionará una abstracción que represente un archivo como una secuencia de datos binarios. Sin embargo, la lectura secuencial de datos de un disco magnético irá más rápido que el acceso aleatorio a ellos, pero los SSD no tendrán tales problemas. Debe comprender los detalles que se encuentran en profundidad para manejar estos casos (por ejemplo, los archivos de base de datos de índice están estructurados para reducir el tiempo de acceso aleatorio), cuando la abstracción proporciona una filtración de detalles de implementación que el desarrollador necesita conocer.

El ejemplo anterior puede volverse más complicado al agregar nuevas abstracciones. Linux le permite acceder a archivos a través de la red, pero son visibles localmente como "normales". Esta abstracción se filtrará en caso de problemas de red. Si el desarrollador los trata como "normales", sin tener en cuenta el hecho de que son propensos a problemas con demoras y fallas de la red, su solución será subóptima y con errores.

En el artículo que describe la ley, se supone que la adicción excesiva a las abstracciones, junto con una comprensión deficiente de los procesos subyacentes, en algunos casos incluso complica el proceso de resolución del problema.

Ejemplos: inicio lento de Photoshop. Me encontré con este problemaen el pasado. Photoshop se inició muy lentamente, a veces tardó unos minutos. Aparentemente, el problema era que al inicio lee información sobre la impresora actual de forma predeterminada. Pero si esta impresora fuera una impresora de red, podría llevar mucho tiempo. La abstracción, según la cual la impresora de red es similar a la local, causó problemas al usuario en caso de mala comunicación.

Ley de la trivialidad.


La ley establece que los grupos dedican mucho más tiempo y atención a discutir cuestiones cosméticas o triviales que a cuestiones serias y extensas.

Por lo general, un ejemplo es el trabajo de un comité que aprueba los planes para una planta de energía nuclear, que en la mayoría de los casos analiza la estructura del estacionamiento de bicicletas, que los temas más importantes del diseño de la estación misma. Puede ser difícil hacer una valiosa contribución a la discusión de temas muy grandes y complejos sin tener un amplio conocimiento sobre este tema. Sin embargo, las personas quieren ser destacadas por hacer comentarios valiosos. De aquí viene la tendencia a concentrarse en pequeños detalles, de los que es fácil hablar, pero que no son necesariamente importantes para el proyecto en su conjunto.

El ejemplo ficticio dado anteriormente dio lugar al término "efecto de cobertizo de bicicleta", que describe la pérdida de tiempo en la discusión de detalles triviales. Existe un término similar, "corte de pelo de yak", que describe una actividad aparentemente no relacionada que es parte de una larga cadena de pasos preparatorios necesarios.

Filosofía Unix


La filosofía de Unix es que los componentes de software deben ser pequeños y centrarse en hacer bien una tarea específica. Esto facilita el proceso de construcción de sistemas al reclutar módulos pequeños, simples y bien definidos, en lugar de utilizar programas grandes, complejos y multifuncionales.

Las prácticas modernas, como la "arquitectura de microservicios", pueden considerarse la aplicación de esta filosofía: los servicios son pequeños, centrados en una tarea específica, lo que le permite realizar comportamientos complejos a partir de bloques de construcción simples.

Modelo de Spotify


El enfoque de la estructura y organización del equipo que promueve Spotify . En este modelo, los equipos se organizan en torno a las funciones del programa, no en torno a la tecnología.

El modelo también promueve los conceptos de tribus, gremios, ramas, otros componentes de la estructura organizacional.

Ley de Wadler


Al diseñar cualquier idioma, el tiempo total dedicado a discutir una característica de esta lista es proporcional a la potencia del número de posición de esta característica en la lista.
0. Semántica.
1. La sintaxis.
2. Sintaxis léxica.
3. La sintaxis léxica de los comentarios.

Es decir, por cada hora que se dedica a la semántica, se dedican 8 horas a la sintaxis de los comentarios.

Al igual que la ley de la trivialidad, la ley de Wadler postula que cuando se diseña un lenguaje, la cantidad de tiempo dedicado a las estructuras del lenguaje es desproporcionadamente grande en comparación con la importancia de estas estructuras.

Ley de Wheaton


No seas una cabra.

Esta ley concisa, simple y completa, formulada por Will Wheatan, tiene como objetivo aumentar la armonía y el respeto dentro de una organización profesional. Se puede utilizar en conversaciones con colegas, cuando se realiza una evaluación experta del código, en la búsqueda de objeciones a otros puntos de vista, en críticas y, en general, en la comunicación profesional entre personas.

Principios


Los principios se asocian con mayor frecuencia con consejos sobre el diseño de programas.

Principio de Dilbert


En las empresas, existe una tendencia a actualizar a los empleados incompetentes a gerentes para eliminarlos del proceso de trabajo.

Concepto de gestión desarrollado por Scott Adams (creador de los cómics Dilbert), inspirado en el principio de Peter. Según el principio de Dilbert , los empleados que no podrían considerarse competentes son promovidos a gerentes para limitar los posibles daños a la empresa. Adams explicó por primera vez este principio en un artículo para el Wall Street Journal en 1995, y luego lo describió en detalle en su libro de 1996, The Dilbert Principle.

Principio de Pareto (regla 80/20)


En su mayor parte, todo en la vida se distribuye de manera desigual.

El principio de Pareto establece que en algunos casos una parte más pequeña de la inversión es responsable de la mayoría de los resultados:

  • El 80% del programa se puede escribir en el 20% del tiempo (y el 20% más difícil toma el 80% restante del tiempo).
  • El 20% del esfuerzo da el 80% del resultado.
  • El 20% del trabajo crea el 80% de las ganancias.
  • El 20% de los errores conducen al 80% de los bloqueos del programa.
  • El 20% de las funciones se utilizan el 80% del tiempo.

En la década de 1940, un ingeniero estadounidense de origen rumano, Joseph Juran, a menudo llamado el padre de la gestión de calidad, comenzó a aplicar el principio de Pareto a los problemas de calidad.

Además, este principio se conoce, como regla 80/20, la ley de los pequeños más importantes, el principio de deficiencia de factores.

Ejemplos: en 2002, Microsoft informó que después de corregir el 20% de los errores más comunes, se solucionará el 80% de los problemas y bloqueos relacionados de Windows y Office.

Principio de Peter


En el sistema jerárquico, cada individuo tiene una tendencia a elevarse al nivel de su incompetencia.


El concepto de gestión creado por Lawrence Johnston Peter señala el hecho de que las personas que hacen un buen trabajo son promovidas hasta que alcanzan un nivel en el que ya no pueden hacer frente ("nivel de incompetencia"). Como subieron lo suficientemente alto, es menos probable que sean despedidos (a menos que creen algún tipo de tontería completa), por lo que permanecerán en esta posición, para la que carecen de las habilidades necesarias, ya que sus habilidades de comportamiento en la organización no necesariamente coinciden con las habilidades necesarias para un trabajo exitoso en este puesto.

Este principio es especialmente interesante para los ingenieros que comienzan a trabajar con roles puramente técnicos, pero a menudo desarrollan una carrera que conduce a la gestión de otros ingenieros, lo que requiere un conjunto completamente diferente de habilidades.

El principio de fiabilidad (ley de Postel)


Sea conservador sobre sus actividades y liberal sobre las contribuciones de los demás.

Este principio a menudo se aplica al desarrollo de aplicaciones de servidor. Según él, los datos que envía a otros deben ser lo más pequeños posible y lo mejor posible para cumplir con el estándar, pero usted mismo debe aceptar datos no completamente estandarizados como entrada, si logra procesarlos.

El propósito del principio es crear sistemas confiables que puedan digerir datos mal formateados, cuyo significado aún se puede entender. Sin embargo, recibir datos de entrada no estándar puede tener consecuencias asociadas con una violación de seguridad, especialmente si la recepción de dichos datos no ha sido bien probada.

Con el tiempo, la práctica de recibir datos no estándar puede llevar al hecho de que los protocolos dejarán de desarrollarse, ya que aquellos que implementan el intercambio de datos comenzarán a confiar en la liberalidad de los programas, creando nuevas funciones.

SÓLIDO


Acrónimo de los siguientes 5 principios:

S: Principio de responsabilidad única
O: Principio abierto / cerrado
L: Principio de sustitución de Liskov
I: Principio de segregación de interfaz [ Principio de separación de interfaz]
D: El principio de inversión de dependencia

Estos son los principios clave de la programación orientada a objetos. Tales principios de diseño deberían ayudar a los desarrolladores a crear sistemas que sean más fáciles de mantener.

Principio de responsabilidad exclusiva


Cada objeto debe tener una responsabilidad, y esta responsabilidad debe estar completamente encapsulada en la clase.

El primero de los principios de SOLID. El principio establece que cada módulo o clase debe hacer solo una cosa. En la práctica, esto significa que un cambio pequeño y único en la función de un programa debería requerir un cambio en un solo componente. Por ejemplo, para cambiar el procedimiento para verificar la complejidad de la contraseña, el programa debe repararse en un solo lugar.

Teóricamente, esto le da confiabilidad al código y simplifica su cambio. El hecho de que el componente que se está cambiando tiene la responsabilidad exclusiva debería significar que será más fácil probar este cambio. Cambiar el componente de verificación de la complejidad de la contraseña del ejemplo anterior solo debería afectar las funciones relacionadas con la complejidad de la contraseña. Es mucho más difícil hablar sobre lo que se verá afectado por un cambio de componente con muchas responsabilidades.

El principio de apertura / cercanía.


Las entidades deben estar abiertas a la expansión, pero cerradas al cambio.

El segundo de los principios de SOLID. El principio establece que las entidades (clases, módulos, funciones, etc.) deben permitir que su comportamiento se expanda, pero su comportamiento actual no debe cambiarse.

Un ejemplo hipotético: imagine un módulo que puede convertir un documento de marcado Markdown en un documento de marcado HTML. Si el módulo puede expandirse para que aprenda a manejar las nuevas características del formato Markdown sin cambiar sus funciones internas, entonces el módulo está abierto para expansión. Si el módulo no puede cambiar el procesamiento de las funciones actuales de Markdown, entonces el módulo está cerrado para su modificación.

El principio está especialmente relacionado con la programación orientada a objetos, donde puede diseñar objetos que son fáciles de expandir, pero no debe diseñar objetos cuyos interiores cambiarán inesperadamente.

Barbara Liskov Principio de sustitución


Debería ser posible reemplazar el tipo con un subtipo sin romper el sistema.

El tercero de los principios de SOLID. El principio establece que si un componente depende de un tipo, entonces debería ser posible usar subtipos de este tipo para que el sistema no se niegue a funcionar o no requiera detalles de este subtipo.

Por ejemplo, tenemos un método que lee un documento XML de una estructura que denota un archivo. Si el método usa el archivo de tipo base, entonces la función debería poder usar todo lo que viene del archivo. Si el archivo admite la búsqueda inversa, y el analizador XML usa esta función, pero el tipo derivado "archivo de red" se niega a trabajar con la búsqueda inversa, entonces el "archivo de red" viola este principio.

El principio está particularmente relacionado con la programación orientada a objetos, donde las jerarquías de tipos deben modelarse con mucho cuidado para evitar confusiones para el usuario del sistema.

Principio de separación de interfaz


Las entidades de software no deben depender de métodos que no utilizan.

El cuarto de los principios de SOLID. El principio establece que los consumidores de un componente no deben depender de las funciones de un componente que no utiliza.

Por ejemplo, tenemos un método que lee un documento XML de una estructura que denota un archivo. Solo necesita leer bytes, avanzando o retrocediendo a través del archivo. Si este método tiene que actualizarse debido a cambios en una estructura de archivo que no está relacionada con él (por ejemplo, debido a una actualización del modelo de control de acceso que representa la seguridad del archivo), entonces se violará este principio. Es mejor que el archivo implemente la interfaz de "flujo de búsqueda" y el método XML para usarlo.

El principio está particularmente relacionado con la programación orientada a objetos, donde se utilizan interfaces, jerarquías y tipos abstractos para minimizar las conexiones entre componentes. Este principio obliga al uso de duck typing , una metodología que elimina las interfaces explícitas.

Principio de inversión de dependencia


Los módulos de nivel superior no deben depender de los módulos de nivel inferior.

Quinto de los principios de SOLID. El principio establece que los componentes de control de niveles superiores no deben conocer los detalles de la implementación de sus dependencias.

Por ejemplo, tenemos un programa que lee metadatos de un sitio web. Presumiblemente, su componente principal debe tener en cuenta un componente que descarga el contenido de una página web y un componente que lee metadatos. Si tenemos en cuenta el principio de inversión de dependencia, entonces el componente principal dependerá solo del componente abstracto que recibe datos de bytes y, a su vez, del componente abstracto que puede leer metadatos del flujo de bytes. El componente principal no sabrá nada sobre TCP / IP, HTTP, HTML, etc.

El principio es bastante complicado, ya que invierte la dependencia esperada en el sistema. En la práctica, también significa que un componente de control separado debe garantizar la implementación correcta de los tipos abstractos (en el ejemplo anterior, algo debe suministrar el lector de metadatos del componente para descargar el archivo a través de HTTP y para leer datos de la etiqueta meta HTML).

Principio de no repetirse


Cada conocimiento debe tener una representación única, consistente y autorizada dentro del sistema.

No se repita , ni DRY, ayuda a los desarrolladores a reducir la repetibilidad del código y mantener la información en un solo lugar. Fue mencionado en 1999 por Andy Hunt y Dave Thomas en su libro Pragmatic Programmer.

Lo opuesto al principio DRY seco] debería ser el principio de WET mojado] - "Escribe todo dos veces" o "Nos gusta escribir" [Disfrutamos escribiendo].

En la práctica, si la misma información se duplica en usted en dos o más lugares, use el principio DRY, fusionándolos en un solo lugar y reutilizándolos según sea necesario.

Principio de KISS


Mantenlo simple, estúpido [No te compliques, tonto]

El principio KISS dice que la mayoría de los sistemas funcionan mejor si no son complicados; por lo tanto, la simplicidad debe ser un objetivo clave en el desarrollo y se debe evitar la complejidad innecesaria. Se originó en la Marina de los EE. UU. En 1960, y la frase se atribuye al diseñador de aviones Clarence Johnson.

Es mejor imaginarlo usando un ejemplo cuando Johnson le dio un pequeño conjunto de herramientas a un equipo de ingenieros de diseño y les indicó que diseñaran un avión para que un mecánico promedio pudiera arreglarlo en un campo de batalla usando solo este conjunto. Aquí estúpido denota la relación entre cómo se descomponen las cosas y la complejidad de las herramientas disponibles para repararlas, en lugar de las habilidades mentales de los ingenieros.

YAGNI


Acrónimo para usted no lo va a necesitar [no lo necesitará].
Siempre implemente funciones solo cuando realmente las necesite y no cuando piense que las necesita en el futuro.

El autor de programación extrema (XP) y el libro "Programación extrema instalada" Ron Jeffries sugiere que los desarrolladores solo deben implementar la funcionalidad que se necesita en este momento, y no intentar predecir el futuro, implementando la funcionalidad que pueda necesitarse más adelante.

Seguir este principio debería reducir la cantidad de código no utilizado en la base de datos, así como la pérdida de tiempo y energía en la funcionalidad que no trae beneficios.

Conceptos erróneos de computación distribuida


También conocido como las falacias de la computación en red. Esta es una lista de supuestos con respecto a la informática distribuida que puede conducir a fallas de software. Estos son los siguientes supuestos:

  1. La red es confiable.
  2. El retraso es cero.
  3. El ancho de banda es infinito.
  4. La red es segura.
  5. La topología no cambia.
  6. Solo hay un administrador.
  7. El costo de envío es cero.
  8. La red es homogénea.

Los primeros cuatro fueron listados por Bill Joy y Tom Lyon en 1991, y James Gosling los clasificó por primera vez como "Conceptos erróneos de computación en red". Peter Deutsch agregó el quinto, sexto y séptimo engaño. A finales de los 90, Gosling agregó el octavo.

Un grupo de ingenieros se inspiró en los procesos que tenían lugar en ese momento en Sun Microsystems.

Estos errores deben considerarse cuidadosamente al desarrollar código confiable. Cada uno de los errores puede conducir a una lógica incorrecta, incapaz de hacer frente a la realidad y la complejidad de los sistemas distribuidos.

All Articles