¿Deben usarse siempre las mejores prácticas de codificación [cerrado]

Al codificar software, ¿la arquitectura siempre debe ser las mejores prácticas o prácticas prácticas con respecto a la aplicación que se está creando?

Si estoy creando una aplicación web de dos páginas que podría vivir 5 años y tener 2 mejoras durante esos 5 años, ¿debería codificar en inyección de dependencia, patrones de diseño, modelo-vista-controlador con modelos de vista, etc.

¿Deben usarse siempre las mejores prácticas de codificación?

¿Siempre? No, eso es tonto.

Las mejores prácticas son pautas. Para la mayoría de las personas, para la mayoría de las situaciones, si se implementan con cierta delicadeza, obtendrán los mejores resultados. Son donde comienzas cuando consideras soluciones. Pero habrá lugares donde las mejores prácticas pueden y deben ignorarse, porque hay mejores soluciones.

El problema es que los humanos no pueden ver el futuro. Y los principiantes (y un grupo de no principiantes) inevitablemente piensan que están en ese escenario especial donde las reglas no se aplican a ellos. En caso de duda, utilice las mejores prácticas. Años de debate y experiencia en toneladas de ingenieros más inteligentes que usted o yo han encontrado que producen resultados consistentemente buenos. Pero ninguno (o casi ninguno) de ellos conoce su problema particular tan bien como usted. Ocasionalmente, se topará con casos excepcionales en los que las reglas se pueden doblar.

Sí. Eso es evidente por sí mismo. ¿Por qué no harías lo que es mejor?

Sin embargo, ese no es el problema. La parte difícil es descubrir cuál es la mejor práctica, porque para responder eso necesitas saber exactamente qué requisitos tienes y cómo es probable que el proyecto evolucione a lo largo de los años, y eso es endiabladamente difícil.

Sin embargo, una buena regla general: NO es la mejor práctica, nunca, tomar los nombres de un montón de patrones de diseño y simplemente juntarlos sin pensar.

Aparte de eso, su pregunta realmente no puede ser respondida. Descubrir exactamente qué es la "mejor práctica" para una situación dada es de lo que se trata ser ingeniero de software. Tendrás que reducirlo para obtener mejores respuestas.

La mejor práctica es la que cumple de manera más efectiva los requisitos funcionales y no funcionales de su software para funciones, capacidad de mantenimiento, rendimiento, etc. Si esa práctica se alinea con algún "estándar de la industria", eso es increíble. Pero si no es así, el pragmatismo gana.

Donde actualmente trabajo, estamos construyendo una nueva interfaz de usuario web para nuestro producto desde cero. No será RESTful de ninguna manera; utiliza POST exclusivamente. No es de varios niveles, no usa ningún microservicio y no usa una base de datos NoSQL. No tiene ningún tipo de arquitectura como Enterprise Java.

En otras palabras, no es nada moderno.

Pero sí incorpora un marco HTML5 de última generación . que presenta un enlace de datos similar a Angular, escala automática a diferentes tipos de dispositivos como dispositivos móviles y de escritorio, integración con la interfaz de usuario Kendo de Telerik para hacer todo el trabajo pesado, y un cifrado completo y seguro canal de datos

Lo mejor de todo, se hará en 30 días, una hazaña que tomaría un ejército de desarrolladores de Java en una arquitectura Enterprise al año para lograrlo. El código es ES6 / Typecript; Es uno de los códigos más limpios que he visto.

No se . Las mejores prácticas son cosas que generalmente se consideran lo mejor que se puede hacer el 99% del tiempo, pero eso no significa que siempre se apliquen a cada situación.

Como desarrollador, su trabajo es conocer y utilizar esas mejores prácticas, pero también saber cuándo es seguro descartarlas.

Se supone que esto no es autopromoción, pero recientemente escribí una publicación de blog relacionada con mi trabajo en la plataforma Salesforce.com que detallaba una de estas ocasiones . Una de las reglas de oro es "Nunca haga una consulta dentro de un bucle", pero recientemente, por primera vez en 7 años de trabajo en la plataforma, tuve una razón perfectamente válida para no cumplir con esa regla.

La esencia es que la plataforma tiene límites en el número de consultas que puede realizar en un contexto de ejecución determinado, pero en este caso tuve que consultar dentro de un bucle para evitar quedarse sin espacio de almacenamiento dinámico y sabía que estaría bien dentro de la consulta límite.

Por lo tanto, es raro, pero hay momentos en que las mejores prácticas no son relevantes para un escenario, por lo que si no encajan, no las fuerce.

Supongo que por "mejores prácticas" te refieres a una lista de reglas que alguien escribió en un libro. Por supuesto, si te refieres a la frase literalmente, por supuesto, siempre debes escribir el mejor código que puedas.

¿Debo señalar que no existe un conjunto único de "mejores prácticas" universalmente aceptado? Para cualquier regla promovida por un experto, casi siempre puede encontrar otro experto con credenciales iguales que diga algo diferente.

Pero al punto: respuesta corta: generalmente, pero no siempre.

Cada campo tiene sus "mejores prácticas" y "soluciones de libros de texto". Estos representan la experiencia acumulada y la sabiduría de muchas, muchas personas durante muchos, muchos años, y no deben ser ignorados. ¡PERO! Siempre hay circunstancias especiales, casos marginales, etc. La persona verdaderamente capaz en cualquier campo sabe cuándo seguir las reglas y cuándo romperlas.

Yo diría en general: comience siguiendo las reglas del libro de texto. Cuando seguir las reglas del libro de texto genera problemas (complejidad innecesaria, bajo rendimiento, lo que sea), considere si romper esta regla esta vez podría no ser una mejor idea.

Si ignoras las reglas y vas a donde tu capricho del momento te lleve, es probable que tu código sea un desastre. No importa lo inteligente que seas, no eres el primer programador del mundo. Tiene sentido aprender de la experiencia de los demás. En nuestra vida diaria, esta es la razón por la que tenemos padres, maestros y predicadores: para que no tengamos que repetir cada error estúpido nosotros mismos para aprender que es un error estúpido.

Pero si sigues servilmente una lista de reglas de algún libro el 100% del tiempo, a menudo te encontrarás martillando una clavija cuadrada en un agujero redondo. Es posible que las personas que escribieron el libro de reglas no se hayan encontrado con un caso como el suyo. E incluso si lo han hecho, si es bastante raro, pueden haberlo ignorado. Una regla que funciona el 80% del tiempo es una regla excelente, siempre que comprenda que funciona el 80% del tiempo y no el 100% del tiempo.

Escribí un libro sobre diseño de bases de datos que incluye muchas reglas que aconsejo a los diseñadores de bases de datos que sigan. (Me abstendré de dar el título para que no parezca que me estoy deslizando descaradamente en la autopromoción). Ciertamente animo a cualquiera que quiera diseñar una base de datos para leer un libro como el mío y aprender todo lo que pueda de él. . Pero, por supuesto, hay momentos en los que debe romper las reglas que enumero.

Una vez escribí un documento de estándares de programación para un equipo de desarrolladores que dirigí en ese momento. Y la última regla fue algo como esto: "Si tiene una buena razón para romper una de las reglas anteriores, continúe, PERO debe incluir un comentario en su código que explique por qué rompió la regla. Si no puede venir con una buena razón, entonces siga la regla. Si escribir el comentario es más problemático que seguir la regla, entonces siga la regla ". Solo tuvimos un puñado de veces que alguien descubrió que romper una regla valía la pena tener que explicar por qué.

Por mejores prácticas , supongo que se refiere a "reglas informales que la comunidad de desarrollo de software ha aprendido con el tiempo que pueden ayudar a mejorar la calidad del software" y no una especie de mejor manera literal de hacer una tarea específica.

Sí, hasta que tenga una razón para no hacerlo. Debe ser una buena razón por la que ha considerado seriamente y aplicado las circunstancias y limitaciones de la tarea en cuestión. Eso significa que comprende completamente la práctica y puede aplicarla. No entremos en esta noción de que si no lo entiendes, entonces no debe ser el mejor tipo de pensamiento. Ver la definición.

No siempre vas a hacer lo mejor. Cuando el jefe te dice: "¡Envía este pedazo de basura o te despiden!" Lo enviarás y probablemente buscarás otro trabajo, pero igual lo enviarás. A veces te encontrarás haciendo algo que es lo suficientemente bueno. Por supuesto, no quieres acostumbrarte a esto, pero a veces tienes que poner en marcha los carros y no puedes preocuparte por la ceguera de los caballos.

Algunas cosas son importantes, otras no.

Debe adaptar su elección de idioma y estilo al problema en cuestión.

Por ejemplo, una "Mejor práctica" para el manejo de excepciones podría ser capturar siempre excepciones y registrarlas, pero cuando se crea una prueba unitaria, la mejor práctica es a menudo dejarlas descartar para que el marco de pruebas unitarias pueda informarlas correctamente.

Por otro lado, considere la regla "SECO". Luchar por un código que no se repita siempre es bueno, no solo por las razones obvias, sino también porque cuanto más codifique de esa manera, mejor se convertirá en un codificador: es una excelente manera de flexibilizar sus habilidades de codificación / pensamiento en lugar de sus habilidades de escritura y copia / pegado, y a la larga, generalmente se sentirá mejor revisando su código (incluso cuando esperaba que fuera un código desechable) si seguía algunas reglas sensatas.

En resumen, sea flexible, pero no solo codifique basura ilegible porque cree que es un código desechable.

Trataré de ver desde una perspectiva diferente.

Los marcos modernos de hoy hacen que sea muy fácil configurar un proyecto básico con mvc, inyección de dependencias, arquitectura en capas, etc. (amante de arranque de primavera aquí). Yo diría que comience con una base generada y use las herramientas proporcionadas por usted, hasta que encuentre algo que requiera una solución hecha a mano. Entonces puede cortar esquinas de esas mejores prácticas.

No es más difícil usar algo como Spring Boot para la aplicación web de 2 páginas, luego rodar sus propios servlets, consultas jdbc y otras cosas.

En mi experiencia, solo hay una mejor práctica que considero obligatoria:

Mantenlo simple, estúpido (BESO)

En otras palabras: cualesquiera que sean las herramientas, API, arquitecturas, etc. que elija, si lo mantiene simple, es más probable que sea fácil trabajar en el futuro, tenga menos errores, sea rápido, eficiente en memoria y todo lo demás que desee.

Todas esas otras cosas de las que habla la gente: Principios, patrones, prácticas, etc., considero como una paleta de herramientas que puedo elegir, seleccionando las que mejor se adaptan al proyecto en el que estoy trabajando. Todos proporcionan técnicas e ideas para resolver problemas. El truco es descubrir si tienes esos problemas en primer lugar.

Las mejores "Mejores prácticas" siempre contienen una sección en la que debe usar su inteligencia y experiencia para identificar cuándo los elementos del manual son inapropiados. También pueden contener una sección sobre revisión, aprobación y documentación de tales excepciones y hacerlas parte de las "mejores" prácticas.

Al codificar software, ¿la arquitectura siempre debe ser las mejores prácticas o prácticas prácticas con respecto a la aplicación que se está creando?

En teoría, sí.

En el mundo real, [todavía] sí, siempre y cuando puedas permitirte hacerlo.

Lo cual, por supuesto, significa "No".

Las presiones de tiempo y dinero siempre intentarán empujarlo hacia el camino de una solución "rápida y sucia", ya que ofrece un "mejor" valor para el cliente. Cómo se implementa eso no es de interés para el cliente o sus contadores. Si puedes hacer un trabajo [mal] en dos días o perfectamente en tres meses, ¿qué crees que te van a pedir?

La brecha entre los dos, la mejor práctica y con lo que debe "salirse", se denomina "Deuda técnica"; es perfectamente aceptable, siempre y cuando tenga un plan para "pagarlo", es decir, para volver y mejorar las cosas más tarde. De nuevo, no es algo para lo que siempre (¿alguna vez?) Obtienes el presupuesto.

Una táctica es lanzar una versión beta temprana con la solución "rápida", pero asegurarse de que las mejoras arquitectónicas necesarias tengan prioridad antes del lanzamiento "completo". De nuevo, no es algo que siempre (¿alguna vez?) Llegas a hacer.