Tecnocracia.net

Libros que leo - Steve McConnell

El estar titulado y el estar trabajando no significa que te sabes la última chupada del mate (que viejo dicho) ni que seas un megagurú ni nada por el estilo. Lo que si ayuda es la lectura de libros escritos por gente con mucha experiencia y mejor aún conocimiento y expertise (ya explicaré en otro post por qué lo último es más valorado).

Dentro de ellos, uno de los que estoy leyendo actualmente es Steve McConnell. Estoy terminando Code Complete en su segunda edición. Nunca tuve la oportunidad de leer la primera, pero es un libro muy ilustrativo que presenta muy buenas prácticas de desarrollo de software en diversos puntos de vista, pero enfocando principalmente a la construcción de software. Aún así es un libro recomendado no sólo para programadores, sino también para jefes de proyecto, líderes técnicos y gerentes asociado a las áreas tecnológicas.

Otro libro que recién llegó a mi hogar ha sido Rapid Development, el cual de lo poco que leido, está orientado a las buenas prácticas del desarrollo de software que ayudan a hacerlo de una forma más óptima. Pero sin fórmulas mágicas, siendo bien realista y estableciendo los distintos trade-off que pueden existir al tomar decisiones como velocidad de desarrollo v/s calidad del software. Ofrece varios casos de ejemplo para establecer el puente entre la filosofía y la práctica.

Steve McConnell tiene también un blog en el cual habla de los distintos aspectos relacionados con el desarrollo de software en todos los niveles

Tags: buenas prácticas, Code Complete, Desarrollo de Software, Ingeniería de Software, libros, programación, Rapid Development, Steve McConell

¡¡A probar Bazaar!!

Luego de escribir mi post acerca de SVN recibo una respuesta muy interesante en la cual me mencionan Bazaar y Git.

La idea principal de estos sistemas de control de versiones es que son distribuidos. Así cada uno puede mantener sus desarrollos como branches separados con los cuales se realiza el merge. Esto es útil cuando hay situaciones en las cuales ciertas modificaciones se tienen que realizar en terreno. Por ejemplo: Visitas al cliente con modificaciones en vuelo, sistemas complejos de integrar, desarrollo de software con programadores ubicados en distintos lugares del mundo sin depender de un servidor central, entre otras cosas.

La verdad hasta ahora estoy en el tema conceptual, que ya es interesante, pero ya bajé las versiones para Linux y Windows (tiene un TortoiseBzr, pero todavía inmaduro), configuraré el plugin para Eclipse y ¡¡A probar Bazaar!!.

Tags: bazaar, bzr, control de versiones, Ingeniería de Software, prácticas, scm

El problema de los estándares de códificación

No me malentiendan. ¡No estoy en contra de los estándares de codificación!. Pero hay que reconocer que son complicados de aplicar.

Donde estoy trabajando, estamos trabajando con un código compartido. Con distintas prácticas. Por un lado un veterano programador, adorador de Java y por otro lado uno no tan veterano, pero experto programador en C/C++. Ambos son Ingenieros muy secos, pero poseen formas de trabajo muy distintas. Y yo estoy al medio.

El primero, es tan adorador de Java que intenta aplicar la misma nomenclatura a C/C++. Esta bien, es una buena práctica, pero C/C++ ofrece ciertas facilidades que a veces imitar a Java no tiene sentido. Les doy un ejemplo, el escribir un archivo utilizando C estándar es bien simple. Solo hay que crear el puntero al archivo y luego para usar el archivo tenemos las siguientes funciones básicas:

• Abrir el archivo: fopen()
• Cerrar el archivo: fclose()
• Leer el archivo: fread(), fscanf(),fget(),fgets(), etc.
• Escribir el archivo: fwrite(), fprintf(), fput(), fputs(), etc.

Si quisieramos imitar el modelo Java en C/C++. Olvidando el tema de hacerlo solo con C, que se puede, pero su complejidad no lo justifica. En el caso de C++ tendríamos que implementar las clases similares a Java. Es decir: BufferedReader, InputStreamReader,  PrintWriter, BufferedWriter, FileWriter, etc. Además de la captura de excepciones. Cuando podría ser más fácil crear una sola clase que hiciera de Wrapper sobre las funciones estándar de C. Lo cual es similar a los objetos ifstream y ofstream de C++.

Por otra parte, el esquema de desarrollo de C/C++ hace que de repente aparezcan esos nombres de variables místicos. Como el clásico ejemplo del ciclo for que explica Kernighan y Ritchie:

int i, n = 10;
int a[10]:
for(i = 0; i<n; i++) a[i] = 3;

Ese tipo de código lo he visto muchas veces, nadie sabe que es i, ni n, ni mucho menos a (hasta son indistiguibles en prosa). i queda un poco claro, es un indice, pero ¿un indice de que? ¿bajo qué está normado?, n indica cantidad, pero ¿es la cantidad de elementos o el límite que se desea recorrer?, en el caso de a se pone más enredada la cosa, puede ser una lista de clientes, una lista de sueldos de empleados, una lista de valores asignados a un hardware específico. Sé que es rápido desarrollar así, pero diganme, ¿qué es más legible? ¿El código anterior o el siguiente?

int indiceEmpleado, numeroEmpleados = 5;
int sueldoEmpleados[numeroEmpleados];
int valorSueldoPorEmpleado = 3;

for(indiceEmpleado = 0; indiceEmpleado < numeroEmpleados; indiceEmpleado++)
{
sueldoEmpleados[i] = valorSueldoPorEmpleado;
}

Debo admitir que me tomó más tiempo escribir dicho loop, pero vale la pena, queda claro cuál es el objetivo, que valor es asignado. Podríamos seguir mejorando dicho loop, pero creo que captan la idea. No podemos basar una práctica de desarrollo guíandonos por estilos asociados a un lenguaje. Hay que ser un poco más prácticos y definir algún estándar general y luego tratar los temas específicos del lenguaje. Obviamente hay temas rescatables de cada lenguaje, tal como el uso de capitalización tipo Java o el agregar prefijos para distinguir los tipos de datos, las variables miembro de una clase del resto como se hace en Visual C++. Así entre otras, pero sin casarse con un determinado lenguaje.

Espero que donde estoy lleguen a un acuerdo. En otra ocasión hablaré de como los problemas de comunicación pueden contribuir a la duplicación de código y por consiguiente a la duplicación de código propenso a errores.

Tags: c, c/c++, estandarización, Ingeniería de Software, java, prácticas de codificación, programación, trabajo en equipo

Los panaderos

He escuchado un termino muy pintoresco de una persona muy pintoresca con la cual trabajo, los “panaderos”.

Generalmente el asocia este término a las personas que se dedican a hacer algo que no es su especialidad. Específicamente a todos los que no son informáticos y se dedican a la informática.

Este es un tema a discutir. Por una parte me gusta que los usuarios y gente externa al area de la Informática participen en el tema, entreguen ideas y se interioricen debido a que de esta forma puedan ver la magnitud de lo que implica desarrollar un software y así ganarnos el respeto que merecemos. Pero por otra, me molesta que empresas contraten a personas que dicen saber acerca de una tecnología, pero no conocen las buenas prácticas que involucran el desarrollo de un software. Eso produce código generalmente poco documentado, desordenado, con un muy alto acoplamiento, excesivas variables globales y mucha cohesión.

Hay muchos cargos en los cuáles legalmente se exige que los que la desarrollen tengan tal profesión o estar certificado de alguna forma. ¿Por qué no lo hacemos también en el tema de la informática?. Creo que nos hace bien a nosotros, los profesionales y a las mismas empresas ya que les damos la garantía de que se desarrollará un buen trabajo.

Tags: el trabajo, informática, Ingeniería de Software, prácticas

¿Qué tan complejo puede ser un sistema?

(Las abejas. Uno de los muy pocos sistemas complejos que conozco
que funcione a la perfección, las únicas competidoras son las hormigas
que es el otro de estos sistemas perfectos.)

Windows Vista, el sistema económico actual, Transantiago. Son muchos ejemplos de sistemas altamente complejos donde mientras el primero y el último colapsaron en forma inmediata, el segundo silenciosamente comenzó a degradar el sistema.

Esto significa entonces que un sistema malo puede mantenerse en pie por mucho tiempo, tal como un tipo mediocre a pura copia puede llegar a pasar hasta casi todos los ramos de universidad de una carrera de Ingeniería (mientras pase la valla de los ramos de ciencias).

Lo que provoca efectos como los que estamos sufriendo ahora en la actualidad es debido a la complejidad del sistema. Esto no está necesariamente relacionado con que el sistema sea más o menos grande. Hay sistemas pequeños tan complejos como un megasistema. La complejidad va en el sentido y relacionado con la modularidad y las relaciones existentes entre cada más de estos módulos. Mientras más acoplado es el sistema, más complejo es debido a que cualquier cambio, aunque sea pequeño, en alguna parte de esta puede producir efectos nocivos.

Pongamos como ejemplo la bolsa. La bolsa depende de tantas variables que cualquier otra cosa que sucede en otro país nos afecta a nosotros. Una pequeña guerra (que por más pequeña que sea siempre es devastadora), una crisis interna, endeudamientos masivos, etc. Hasta el más mínimo detalle nos afecta. Ese es un sistema altamente acoplado.

Otro tipo de acoplamiento es cuando ocurre una dependencia de una entidad central. A nivel político podemos asociarlo con el centralismo de nuestro país. Todo lo que se decida en la región metropolitana influye en los recursos del resto de las regiones y eso afecta en todos los sentidos: económico, laboral, social, etc. Por lo mismo creo cada vez más necesario que las regiones deberían desagregarse del poder central para ser más autónomas. ¡Pero con cuidado! Existe la tentación de desacoplar directamente un estado por región, lo cual es un enfoque simplista, debido a que las regiones con menos recursos siempre dependerán de las que tienen más, entonces la separación iría por otro lado: separar en zonas segun los tipos de recursos de forma que la economía interna de una zona intente no afectar al resto de las otras zonas.

Esos son algunos desafíos que involucra el desarrollar un sistema, ya sea este un software, una megaingeniería, un sistema político o uno económico. Si no se puede preveer con anterioridad cuál es la complejidad de este y no se elabora una estrategia inteligente para manejarla, siempre se repetirá la misma historia. Tal como dijo Einstein: “Haz las cosas de la forma más simple posible, pero no la más simple”.

Tags: Bolsa, Diseño, Economía, Ingeniería, Ingeniería de Software, País, política, regionalización, Transantiago