Tags

, , , , ,

La razón por la que no actualizo a diario o por lo menos con más frecuencia, es por que me la paso programando cosas para la escuela. He mencionado varias veces que estudio Ingenieria en Sistemas Computacionales y si gran parte de la carrera ha sido programación de muchas cosas (para muestra algunos posts), la segunda actividad más trascendental es el análisis y diseño de software.

Los proyectos se han venido haciendo cada vez más y más complejos mientras que los tiempos para entregarlos son cada vez menores. Recientemente he notado algunas prácticas de programación de mis compañeros, son como hábitos, mañas adquiridas a lo largo de los años de extensa codificación, quizá alguna trampa transnacional envia mensajes subliminales mediante toxinas en la Coca-cola que ofusquen el sentido común en los programadores.

El análisis y diseño de software, de algún modo te genera una visión distinta de las situaciones, digamos que para una situación dada una persona “normal” analizaría hechos poco trascendentales pero sí muy vistosos. Mientras que un analista o diseñador de software analizaría datos relevantes agrupados en categorias de acuerdo a su importancia o implicación en dicha situación.

Al punto. He notado (gracias a esa habilidad de analista) algunas prácticas de mis compañeros al momento de codificar. Costumbres y mañas que en cierta forma les resultan contraproducentes y el fin de este post es el de dar algunos consejos de las prácticas que comúnmente yo hago y que según yo son funcionales.

1. Comenta tu código.

Sé que es tedioso y que escribir cosas coherentes y lo que es más importante aún, escribir texto claro y no ambiguo, no es el fuerte de muchos, pero con que escriban brevemente qué hace algún bloque que se vea rebuscado con eso tienen.

2. Identificadores de variables semánticos.

Por favor, si vas escribir código hazlo de manera elegante, pon nombres con significado. El código por sí mismo no posee sentido al ojo humano. El significado comienza a aparecer cuando hay variables como: “movimiento” y no como “m”.

3. Indenta tu código.

Si no sabes qué es indentar, es agregar esas sangrías o espacios o tabuladores, antes de cada línea de código y conforme más separado esté del margen izquierdo, más anidamiento representa. Eso a la larga genera comódidad de lectura cuando estas revisando tu programa.

4. Salva periodicamente.

Que se te haga hábito el Ctrl+S o Ctrl+G de tu programa de codificación, nunca sabes en qué momento la entropia universal optará por hacer que algo falle y que tú no tengas guardado nada.

5. Conoce tu herramienta de programación.

Aprende de verdad a usar todo lo que te ofrece el programa dónde escribes  código. Yo ocupo gedit o SciTe, pero también escribo en el bloc de notas y por convención hay funciones que utilizan la misma combinación de teclas, en la mayoría de los programas.

6. Conoce tu teclado.

Estar habituado a un teclado que responde de tal o cual forma implica muchos menos errores al momento de teclear, úbica las teclas de función especial (en caso de lap top o netbook), aprende a usar los botones de Fin, Inicio, Av Pág, Re Pág, Insertar, Suprimir, Ctrl (izquierdo y derecho si los hay) y Shift (izquierdo y derecho).

7. Reescribe tu propio código (desde cero).

Para un proyecto mediano o grande, es bueno reescribir 1 o 2 veces toda una clase, o todo una método. Esto es porque en el momento de programar por primera vez, tu perspectiva del problema es una. Cuando reescribes tu propio código inconscientemente esás repasando lo qué debe de hacer el bloque de código que estás escribiendo y de manera natural encuentras errores y situaciones que no habías pensado.

8. Programa pensando que habrá alguien que en algún momento leerá tu código.

Aunque no sea cierto, esto te ayuda a diseñar algoritmos de manera más eficiente, puesto que si piensas que alguien leerá lo que escribes, tratarás de hacer algoritmos más elegantes, para que el otro vea el nivel de programación que manejas y que no eres un Programador Albañil.

9. Diseña tus algoritmos con calma.

No hagas las cosas precipitadamente, dedica un poco de tiempo a pensar cómo vas a hacer algún proceso o cómo resolverás un problema. Eso te ayuda a ver los puntos débiles del problema, a pensar en varias soluciones y al momento de programar ver todo más claro.

10. Siempre que puedas, lleva todo a las matemáticas.

La justificación de ésta razón es que la computadora es una máquina de hacer cálculos sobre objetos volátiles que se encuentran brevemente representados por pulsos electrónicos. En lugar de diseñar un montón de funciones, trata de hacer representaciones matemáticas de los problemas. Sé que suena medio raro, pero para ser sincero, sí. Sí es raro. Abstraer los problemas al grado de verlos como una representación matemática, geométrica, algebraíca o artimética te da una ventaja computacional en algunos casos.

11. Genera código explicativo

Si tu programa recibe parámetros de entrada mediante la consola, acostumbra a incluir un parámetro que te explique como meter estos datos; por ejemplo, hice un programa para escaneo de puerto tcp y recibe como parametros:

-if <interfaz> para usar esa interfaz de red
-ip <direccion> direccion a escanear
-hn <host> en caso de no tener una ip, se puede recurrir a un nombre de host
-r <inicial> <final> establecer el rango de puertos a escanear
-h -? muestra ayuda y sale

Esto es útil a futuro cuando revises tu programa o lo ocupes después para que no tengas que estar revisando función por función.

En general, espero que estas leves prácticas que yo llevo, le sirvan a alguno y que más que eso los puedan aprovechar en sus costumbres diarias