Durante mi cada vez 'menos corta' carrera como desarrollador voy descubriendo que más allá de los frameworks, filosofías, reuniones, requisitos... lo que las personas esperan del software es, que no falle.
Cuando los programas son cerrados, el número de funcionalidades finito y fijo durante el desarrollo se pueden analizar todas las posibilidades y dar una solución que no falle, pero ésto no es así casi nunca.
La cuestión a la que llevo dando vueltas un tiempo a que lo que yo normalmente tengo en la cabeza cuando desarrollo son todo cuestiones de eficiencia, porque cuando haces desarrollos que van a tener un numero de usuarios indeterminado cada trocito de procesador o ram que ahorres es importante. Por supuesto siempre hay un control de errores... ¿Pero que puedes hacer para controlar los errores que no esperas?
Al margen de hacer un buen diseño sólo puedes controlar que las entradas y salidas sean razonables y si no lo son, mandar un correo electrónico a admin para revisarlo cuanto antes.
Es curioso como van afectando mis experiencias en el mundo de la programación al estilo de mi código e incluso de mi documentación. Cada vez me oriento más y más al error, voy buscando el fallo la brecha... con lo que la documentación se vuelve más práctica y más corta y los procedimientos se llenan de chequeos y validaciones que a simple vista parecen inútiles pero para los que siempre hay un comentario del tipo //esto es por si nos viene X con valor Y, cosa que normalmente no debería ocurrir... pero con el tiempo, seguramente ése pedazo de código tan bueno termine sirviendo para algo diferente para lo que fue concebido... y eso que nunca debía ocurrir ocurre... creedme OCURRE.
¿Vosotros habéis notado que vuestro estilo de programación varía, no sólo por cosas nuevas que aprendéis sino por cómo evolucionan vuestros conceptos, etc.?
Cuando los programas son cerrados, el número de funcionalidades finito y fijo durante el desarrollo se pueden analizar todas las posibilidades y dar una solución que no falle, pero ésto no es así casi nunca.
La cuestión a la que llevo dando vueltas un tiempo a que lo que yo normalmente tengo en la cabeza cuando desarrollo son todo cuestiones de eficiencia, porque cuando haces desarrollos que van a tener un numero de usuarios indeterminado cada trocito de procesador o ram que ahorres es importante. Por supuesto siempre hay un control de errores... ¿Pero que puedes hacer para controlar los errores que no esperas?
Al margen de hacer un buen diseño sólo puedes controlar que las entradas y salidas sean razonables y si no lo son, mandar un correo electrónico a admin para revisarlo cuanto antes.
Es curioso como van afectando mis experiencias en el mundo de la programación al estilo de mi código e incluso de mi documentación. Cada vez me oriento más y más al error, voy buscando el fallo la brecha... con lo que la documentación se vuelve más práctica y más corta y los procedimientos se llenan de chequeos y validaciones que a simple vista parecen inútiles pero para los que siempre hay un comentario del tipo //esto es por si nos viene X con valor Y, cosa que normalmente no debería ocurrir... pero con el tiempo, seguramente ése pedazo de código tan bueno termine sirviendo para algo diferente para lo que fue concebido... y eso que nunca debía ocurrir ocurre... creedme OCURRE.
¿Vosotros habéis notado que vuestro estilo de programación varía, no sólo por cosas nuevas que aprendéis sino por cómo evolucionan vuestros conceptos, etc.?
2 comentarios:
De sobra conoces mis frustraciones como desarrollador. Estoy tan estancado en copy&paste's, ingenierías inversas imposibles, en código mal documentado (o simplemente sin documentar) y chapuzas de todo tipo, que sí hoy tuviera que empezar con algo nuevo, tendría que pasar por un proceso duro de aprendizaje y de sacarme mierdas de la cabeza...
Sin embargo en algo coincido contigo, si algo he aprendido en los últimos años es a considerar los casos imposibles o poco probables en los que puede fallar un sistema... Cosa distinta es que al final te acaben despachando con un "Eso no puede pasar, hazlo de esta otra manera que es más fácil y rápido, y si no ya lo arreglaremos..."
Si la personalidad de la gente se pudiese leer en su "estilo de programación" -igual que la grafología en la firma- esto estaría lleno de psicopatas desequilibrados...
Respecto a tu frustración, tienes una alternativa: desarrolla fuera del trabajo alguna de las ideas que hemos comentado alguna vez :)
Mm, quizás psicopatas no, pero ignorantes... seguro que hay unos cuantos.
Sabes el otro día vinieron a ver una avería eléctrica que hemos tenido. En un momento de la conversación surgio el manido tema de que 'hay que hacer las cosas bien' y pronto surgió el argumento de que a veces hay que hacer lo que se puede. Lo cierto es que 'en las trincheras' a menudo no podemos hacer las cosas bien por muchos motivos. Pero lo igualmente cierto es que siempre se puede dedicar más tiempo después del parche a hacerlo bien.
La triste realidad es que ése tiempo suele significar hacer horas extra de un trabajo que luego no luce nada, porque lo que estás 'arreglando' ya funcionaba y en consecuencia no se valora, ni se paga y por todo ello, finalmente nadie lo hace.
Publicar un comentario en la entrada