Hay algunos criterios que un aprendiz de programador no siempre toma en cuenta, por desconocimiento;
o peor aún: que un programador "experimentado" no toma en cuenta por
Según creo, estos criterios necesitan ser enseñados explícitamente a los newbies y amateurs, aunque también son aprendidos y comprobados durante la práctica; para finalmente, ser aplicados
1. Desarrollar código fácil de entender.
Así, se hace código comprensible trascendiendo el tiempo; y no tener que deducir tantas las líneas de código.
Pero eso no es suficiente:
No comentar todo (cada declaración de variables, cada abrir y cerrar de llaves, cada conexión a BD), porque demasiados comentarios irrelevantes quitan atención a los comentarios importantes.
Un buen complemento a los comentarios también es el hacer un código claro y bien definido, no redundante ni aglutinado.
 |
| Tal vez cause gracias, pero siendo objetivos: Es egoísta e inmaduro. |
2. No complicar el código.
Muchas veces solucionamos algún problema de la forma más enredada por dar una impresión de "soluciones complejas desde una mente compleja".
O peor aún: porque no queremos dedicarle más tiempo para simplificar la solución.
El arte de la programación está en la abstracción de desarrollar soluciones sencillas para problemas complicados.
Debemos buscar la forma más simple de resolver las cosas. Esto ayudará a entender el código mejor y a mantenerlo* de una manera más eficiente, haciéndolo menos propenso a errores.
3. "Menos es más" no es siempre bueno.
Muchos lenguajes de programación permiten concatenar funciones y muchas veces queremos hacer varias cosas a la vez en una línea. Esto dificulta la lectura y la lógica del código; así como su posterior mantenimiento*.
 |
| Disculpando la palabra, y la ortografía. |
4. Evita el hard coding.
Usar constantes, así, al necesitar cambiar ese valor, sólo habrá que hacerlo en un único lugar: la constante; y no en cada línea del código donde se utiliza dicho valor.
Si ese valor cambiará a lo largo de la vida del programa, es mejor usar ficheros externos de configuración (XML, propiedades, procedimientos y funciones de base de datos, etc), de esta forma no tenemos que modificar el código, recompilar y redistribuir/publicar la nueva versión.
"Valores en bruto es característico de programadores brutos".
5. No reinventes.
Aprovechar los métodos y clases del código, procedimientos y funciones de la base de datos, los frameworks existentes y de los patrones de diseño. Están ampliamente probados.
Reutilización de código es fácilmente manejable en la POO, pero no es el único paradigma que lo permite.
6. Interfaz de usuario.
El aspecto del GUI (interfaz de usuario), la forma de navegar por el mismo y la comodidad a la hora de usar el mismo, influirán en la aceptación y el éxito de tu aplicativo.
Debemos mantener el mismo estilo en todo el programa, respeta los estándares previamente definidos, valida cuidadosamente los clics y datos a ingresar por el usuario, escoge cuidadosamente el título de las ventanas, etiquetas de texto, mensajes de error, etc. (Inspírate en el diseño de otros sistemas ampliamente aceptados)
"Interfaces APB: Apta para burros".
7. Documentación.
Es una tarea pesada y tediosa, y en el momento en el que estamos trabajando en un proyecto todo tiene sentido y es fácil de seguir.
Pero al darle mantenimiento* ya nada es tan tan obvio como inicialmente fue desarrollado.
8. Unidades de testeo.
Es una muy buena y recomendada práctica que debemos hacer siempre.
Esto nos ayudará a verificar rápidamente que nuestras funciones trabajarán como deben.
Ahorrará mucho tiempo en el futuro (al darle mantenimiento* a esas funciones); y es otra de las tácticas que ayudará a reducir el número de errores en nuestro programa.
9. Calidad, no cantidad.
Es mejor un programa con las funciones básicas bien desarrolladas, a un programa lleno de funciones y que se ponga lento o se cuelgue, o no funcione como debería hacerlo.
Particularmente para este inciso, influyen mucho el cumplir cabalmente con los incisos del 1 al 5.
Por lo menos, estos 9 principios son obligatorios, aunque por el momento puedo estar olvidándome de algunas.
(*) Mantenimiento: Deben considerar tanto que ustedes mismos podrán realizar dicho mantenimiento/cambio/mejora del código, como la posibilidad de que se roten los proyectos entre los desarrolladores, y las salidas de la empresa del personal.
La idea de facilitar el mantenimiento no se aplica sólo a uno mismo; sino al resto de personas que revisarán el código en el corto y el largo plazo.
PD: Un plus para los programadores en Java:
/* Cuidado con los prints y la concatenación de Strings */
Normalmente tendemos a escribir prints por todo el programa, con la intención de depurar nuestra aplicación; Esto puede afectar seriamente el rendimiento de la aplicación.
Usa algún tipo de mecanismo para que esos prints sólo se ejecuten en la fase de desarrollo.
La concatenación de String puede ser otra de las operaciones que afectan al rendimiento del programa.
Si vas a hacer muchas operaciones de concatenación, en Java la clase String es inmutable, por lo tanto cada vez que haces una concatenación estás desreferenciando los Strings que estas concatenando y creando un nuevo String. En Java tienes disponibles 2 clases que aumentan drásticamente el rendimiento para este tipo de operaciones. StringBuffer y StringBuilder.
StringBuilder es incluso más rápido que StringBuffer, ya que éste no es thread-safe.
Por lo tanto: si el código donde estás haciendo las concatenaciones no es multihilo, usa StringBuilder; sino, usa StringBuffer.
Artículos relacionados:
Fuentes:
- Hard coding.
Recibe en tu correo electrónico las últimas actualizaciones de este blog:
También me encuentras en facebook.También en twitter.
También en tumblr.
No hay comentarios.:
Publicar un comentario