extensibility - ¿Qué tan extensible debería ser el código?

(7)

Al diseñar su código, debe tener en cuenta las posibles formas de ampliarlo o solicitarle una nueva funcionalidad, y debe esforzarse por hacerlo lo suficientemente modular como para que sea posible agregar una nueva funcionalidad. Si hay un punto en el que una decisión lo hará más flexible o extensible, mientras que otra decisión lo hará más rígido, si hay poco o ningún costo en ser más flexible, entonces tiene sentido ir con eso. Sin embargo, si el costo de la ruta más flexible es significativo, entonces no lo hagas. A menos que sepa con certeza que necesitará esa función y que los costos están justificados, no debe volverse loco al tratar de agregar dicha funcionalidad; Si lo haces, lo más probable es que gastes mucho para nada.

Acabo de comenzar un nuevo trabajo y una de las cosas de las que mi nuevo jefe me habló fue la longevidad del código.

Siempre he codificado para hacer que mi código sea infinitamente extensible y adaptable. Pensé que si alguien iba a cambiar mi código en el futuro, entonces debería ser fácil de hacer.

Pero realmente nunca tuve una idea clara de qué tan lejos debería ser el futuro.

Así que mi nuevo jefe me dijo que no me molestara en codificar nada más que 3 años en el futuro y su razonamiento era que los cambios tecnológicos, los programas expiran, etc.

Al principio, me sorprendió un poco y pensé que era un trabajo de locura, pero cuanto más lo pienso, más me entiendo al concepto.

¿Alguien más tiene una opinión sobre qué tan lejos debe codificar en el futuro?

Cada vez que estoy codificando algo, me pregunto ...

¿Es necesario? Si no lo necesitas, ¿por qué lo estás codificando?

Me parece que me ayuda a evitar que agregue código innecesario. Código innecesario es un drenaje. Se toma tiempo lejos de otras actividades. Se suma al tamaño y complejidad del código. Agrega $$$ al proyecto, especialmente si el código base tiene que pasar por un proceso de certificación.

Codifique bien, y busque solo el siguiente entregable. El código bien escrito es infinitamente refactorable / extensible ya sea escrito con esto en mente o no. El código mal escrito que se pretende que sea extensible rara vez está en la práctica.

Debes codificar a las especificaciones, nada más, nada menos. Si las especificaciones hacen provisiones por 30 años, usted codifica por 30 años. Si la especificación establece provisiones por 3 meses, se aplica lo mismo.

Sin embargo, recuerde que también debe codificar para su propia cordura. Todo el código que crees debería lograr 3 cosas:

Código para ser reemplazable - Esta es solo una buena práctica en mi opinión. Cuanto más reemplazable esté en su codificación, mejor será el código que produzca. Esto proporciona un poco de una situación inversa: cuanto más reemplazable haga su código, más valioso será usted mismo.
Código para ser productivo - Reutilizar, reutilizar, reutilizar.
El código debe estar bien escrito: esto no necesita ser explicado.

Si realmente quieres un programa de larga duración, dispara para asegurarte de que tus fechas se puedan manejar más allá de 2038 (ese es el próximo "Y2K").

Dejando de lado las fechas, ¿cómo se puede codificar exactamente durante un año a partir de ahora en lugar de dentro de diez años? O escribes código mantenible o no; no puede especificar exactamente cuánto tiempo transcurre hasta que caduque el cambio.

Supongo que se podría argumentar que el siguiente estándar de su idioma desaprobará el método Foo , pero si un método va a ser desaprobado, eso es más una cuestión de calidad de código y mantenibilidad que de código para fechas futuras.

Si está siguiendo las metodologías ágiles de la letra, debe codificar el problema actual. Esto también se conoce como el principio YAGNI (No lo vas a necesitar).

La idea es que no sabes lo que viene a la vuelta de la esquina, por lo que no tiene sentido intentar codificarlo.

Sin embargo, no creo que este enfoque sea particularmente sensato.

Incluso si se encuentra en un entorno Agile, tiene una idea de lo que quiere que el código pueda hacer varias iteraciones en la línea y, por lo tanto, debe codificarlo.

Si bien los programas caducan y las tecnologías cambian, si escribes esa aplicación "asesina", estará disponible por más de 3 años.

Uno de los juicios difíciles de lograr es cuán extensible sea. Como jefe, estoy realmente irritado cuando asigno a alguien una tarea de 2 horas y tres días después todavía están trabajando en ello, porque decidieron que debería ser más extensible, así que agregaron entradas al archivo de configuración y columnas a las tablas y tuvieron para cambiar 4 o 5 otros objetos para acomodar eso y ahora el documento de instalación está desactualizado y el script de implementación tiene que cambiar y el probador tiene que poner uno o dos días probando todas las combinaciones y permutaciones para que podamos saber que el código es incluso trabajando Pero también estoy realmente irritado cuando alguien más, dado que la tarea de dos horas la convierte en una tarea de media hora al codificar todo, incluso la dirección de correo electrónico a la que se envía, y no comprende cuándo se queja el resto del equipo.

Si hubiera una regla simple y rápida, todo el mundo podría ser un programador senior el día que compilen un código. Requiere experiencia y juicio, y es probablemente el juicio más importante que adquirirás. ¿Y sabes cómo obtienes buen juicio? Experiencia. ¿Y sabes cómo obtienes experiencia? Mal juicio