¿Cuán extensible debería ser realmente el código?

Question

Acabo de comenzar un nuevo trabajo y una de las cosas de las que mi nuevo jefe me habló fue sobre 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 sería fácil hacerlo.

Pero nunca tuve una idea clara de cuán lejos en el futuro debería ser.

Así que mi nuevo jefe me dijo que no se moleste de codificación para nada más de 3 años en el futuro y su razonamiento era que los cambios de tecnología, programas expiran etc.

Al principio estaba un poco tomado por sorpresa y pensó que era un buen trabajo, pero cuanto más lo pienso, más me estoy entusiasmando con el concepto.

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

Answer 1

Debe codificar según las especificaciones, nada más, nada menos. Si las especificaciones establecen provisiones durante 30 años, usted codifica durante 30 años. Si la especificación proporciona disposiciones por 3 meses, se aplica lo mismo.

Pero recuerde que también debe codificar su propia cordura. Todo el código que cree debe 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 código producirá. Esto proporciona un poco de una situación inversa: cuanto más reemplazables haces tu código, más valioso te haces a ti mismo.

• Código para ser productivo: reutilización, reutilización, reutilización.

• El código debe estar bien escrito: esto no lo tengo que explicar.

Answer 2

Cifre bien, y mire solo al próximo entregable. El código bien escrito es infinitamente refactorizable/extensible ya sea escrito con esto en mente o no. El código mal escrito que debe ser extensible rara vez es en la práctica.

Answer 3

Si realmente desea un programa de larga duración, tirar para asegurarse de que las fechas pueden manejar 2038 pasado (que es el próximo "Y2K").

Fechas aparte, ¿cómo se puede codificar exactamente un año a partir de ahora en lugar de dentro de diez años? Usted escribe el código que se puede mantener o no; no puede especificar exactamente cuánto tiempo hasta que su cambio "caduque".

supongo que se podría argumentar que el nuevo estándar de la lengua quedará obsoleta método Foo, pero si un método va a ser obsoleto, eso es realmente más una cosa de la calidad del código y la capacidad de mantenimiento de lo que es la codificación para las futuras fechas .

Answer 4

Si está siguiendo las metodologías de Agile al pie de la letra, entonces debería estar simplemente codificando para 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, así que no tiene sentido tratar de codificarlo.

Sin embargo, no creo que esto es particularmente enfoque sensato.

Incluso si se encuentra en un entorno ágil que tenga una idea de lo que quiere que el código sea capaz de hacer varias iteraciones por la línea y, por tanto, debe codificar a eso.

Mientras que los programas se vencen y las tecnologías cambian si está escrito que "killer" de la aplicación que será de alrededor durante mucho más tiempo de 3 años.

Answer 5

Al diseñar su código, debe tener en cuenta las posibles formas en que podría ampliarse o se le podrían exigir nuevas funciones, y debería esforzarse por hacerlo lo suficientemente modular como para agregar nuevas funcionalidades. 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 para 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 haga. A menos que sepa con certeza que necesitará esa característica y que los costos están justificados, no debe enloquecer al tratar de agregar dicha funcionalidad; si lo hace, probablemente gastará mucho por nada.

Answer 6

Siempre que estoy cifrando algo, me pregunto ...

se necesita? Si no lo necesita, ¿por qué lo está codificando?

lo encuentro me ayuda a mantener la adición de código innecesario. El código innecesario es un drenaje. Toma tiempo de otras actividades. Se agrega al tamaño y complejidad del código. Agrega $$$ al proyecto, especialmente si la base de código debe pasar por un proceso de certificación.

Answer 7

Uno de la pieza dura del juicio de lograr es la forma extensible que sea. Como jefe, estoy realmente irritado cuando asignó a alguien una tarea de 2 horas y tres días después todavía están trabajando en ella, porque decidieron que debería ser más extensible, por lo que agregaron entradas al archivo de configuración y columnas a las tablas y tuvieron 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 con esa tarea de dos horas lo convierte en una tarea de media hora codificando todo, incluso la dirección de correo electrónico a la que envía, y no entiende cuando el resto del equipo se queja.

Si había una regla dura y rápida sencilla, todo el mundo podría ser un programador senior el día en que primero compilar un código. Se necesita experiencia y juicio, y es probablemente el juicio más importante que va a adquirir. ¿Y sabes cómo obtienes buen juicio? Experiencia. ¿Y sabes cómo obtienes experiencia? Mal juicio.