Top 5 tips para desarrollar mejores aplicaciones

 Muchas veces me pongo a pensar en retrospectiva, acerca de cosas que se han hecho bien y cosas que se han hecho mal. Aquí escribo un resumen de las principales cosas que recomiendo hacer para ser un programador más feliz.

1- El usuario no tiene tiempo, ni quiere leer.

Olvidense del RTFM. Nadie lo lee. Hay que imaginarse que el usuario está inmerso en un caos tremendo, teléfonos sonando, gente, alarmas, etc. Lo que menos quisiera es estar lidiando con carteles del tipo "está seguro que desea cerrar etc", o, con aplicaciones oscuras que, si bien hace lo que se debe, tienen muchos botones, radio button y demás, y que, ni el mismo desarrollador entiende sin mirar el código.
Por eso, las aplicaciones tienen que ser intuitivas, se tienen que "auto-explicar". Lo mismo se aplica para los carteles y pop-ups que requieren una decisión del usuario. Si no hay más remedio que poner un cartel, que sea corto y puntal. Por ejemplo:

¿Está seguro que desea cerrar la aplicación?
[si] [no]

Cuando se podría:

¿Salir?
[si] [no]

Mucho más corto y al pie.

Por último, recuerden la página de Google, un cuadro de texto y un botón. ¿Qué mas?

2- Refactorizar vs From Scratch.

No siempre es bueno reescribir todo, ni tampoco siempre lo es reusar. Hay que usar esto de forma inteligente. Por un lado el código viejo no es necesariamente malo o confuso. Hay que tener en cuenta que, por un lado, leer código es más dificil que escribirlo (por eso siempre es tentador el reescribir todo) y por otro, el código viejo es, muchas veces, un código ya testeado, con bugs correjidos, en fin, es tiempo de trabajo. Reescribir todo desde cero significaría, tirar todo eso a la basura.
Lo ideal es un balance entre, reescribir las partes "mal escritas" tratando de reusar lo más posible. Es significativamente menos tiempo que escribir todo desde cero, sobre todo, si tenemos en cuenta que, el código desde cero va a tener bugs nuevos.

3- Pensar en grande.


Todo buen programa tiene que empezar cómo algo simple, pero, pensado a lo grande. Esto es, pensar que en un futuro, el programa puede crecer. Por eso, hay que escribir todo de forma flexible, aunque lleve más tiempo ahora, en un futuro va a ser más facil expandir y mantener. Mucho se ha hablado de la deuda técnica.Esto es un poco lo que trato de comunicar aquí: El tiempo que se ahorra escribiendo código chapucero ahora, lo pagás mañana.

4- Keep it simple.

Muchas aplicaciones tienen varias faces de desarrollo. Esto es, se reune con el cliente, se diseña, se programa, se vuelve a ver con el cliente, se corrijen cosas, se agregan otras. Entonces, es de esperar que el cliente no sea muy lógico, que haga cambios sobre la marcha y que no tenga en cuenta el diseño general del sistema. Para eso nos paga a nosotros ¿Verdad? Por eso, siempre hay que hacer limpieza del código y del programa. Lo que no se usa, fuera (por lo menos, de la vista) Esto ayuda mucho a que se cumpla el punto 1.
Si la aplicación en si, estaba pensada con otro espiritu y luego, se modificó, tratar de quitar todo lo que sobre. A veces más es menos. Muchos botones y radio button, checks, etc, para mantener un poco la idea anterior y que conviva con la idea nueva genera más problemas que soluciones. Use it or lose it.

5- Testing

Esto es obvio, pero, no se respeta mucho. El cliente no es un beta tester. Si se programa con la idea "que tenga bugs, total lo corrijo rápido" se arriesga, primero, problemas en datos que haya que resolver (esto es tiempo) y, segundo, da la idea de que el programa anda mal.