1.12.2. Obstáculos de la gestión

Si es gerente, su trabajo es adquirir recursos para su equipo, superar las barreras en el camino del éxito de su equipo, y en general intentar proporcionar el entorno más productivo y agradable de modo que sea más probable que su equipo realice esos milagros que se le piden siempre. Cambiar a C++ cae en las tres categorías, y sería maravilloso que además no le costara nada. Aunque cambiar a C++ puede ser más económico - dependiendo de sus restricciones [33] - que las alternativas de la POO para un equipo de programadores de C (y probablemente para programadores en otros lenguajes procedurales), no es gratis, y hay obstáculos que debería conocer antes de intentar vender el cambio a C++ dentro de su compañía y embarcarse en el cambio usted mismo.

Costes iniciales

El coste del cambio a C++ es más que solamente la adquisición de compiladores C++ (el compilador GNU de C++, uno de los mejores, es libre y gratuito). Sus costes a medio y largo plazo se minimizarán si invierte en formación (y posiblemente un mentor para su primer proyecto) y también si identifica y compra librerías de clases que resuelvan su problema más que intentar construir las librerías usted mismo. Son costes en dinero contante que se deben tener en cuenta en una propuesta realista. Además, están los costes ocultos en pérdidas de productividad mientras se aprende el nuevo lenguaje y posiblemente un nuevo entorno de programación. Formar y orientar puede minimizar ese efecto, pero los miembros del equipo deben superar sus propios problemas para entender la nueva tecnología. A lo largo del proceso ellos cometerán más errores (esto es una ventaja, porque los errores reconocidos son el modo más rápido para aprender) y serán menos productivos. Incluso entonces, con algunos tipos de problemas de programación, las clases correctas y el entorno de programación adecuado, es posible ser más productivo mientras se está aprendiendo C++ (incluso considerando que está cometiendo más errores y escribiendo menos líneas de código por día) que si estuviera usando C.

Cuestiones de rendimiento

Una pregunta común es, «¿La POO no hace automáticamente mis programas mucho más grandes y lentos?» La respuesta es: «depende». La mayoría de los lenguajes de POO tradicionales se diseñaron pensando en la experimentación y el prototipado rápido más que en la eficiencia. Por eso, prácticamente garantizaban un incremento significativo en tamaño y una disminución en velocidad. C++, sin embargo, está diseñado teniendo presente la programación de producción. Cuando su objetivo es un prototipado rápido, puede juntar componentes tan rápido como sea posible ignorando las cuestiones de eficiencia. Si está usando librerías de terceros, normalmente ya están optimizadas por sus vendedores; en cualquier caso no es un problema mientras está en un modo de desarrollo rápido. Cuando tenga el sistema que quiere, si es lo bastante pequeño y rápido, ha terminado. Si no, empiece a afinarlo con una herramienta de perfilado, buscando primero las mejoras que puede conseguir con aplicaciones sencillas de las características que incorpora C++. Si esto no le ayuda, busque las modificaciones que se pueden hacer en la implementación subyacente de modo que no sea necesario cambiar ningún código que utilice una clase particular. Únicamente si ninguna otra cosa soluciona el problema necesitará cambiar el diseño. El hecho de que el rendimiento sea tan crítico en esa parte del diseño es un indicador de que debe formar parte de los criterios principales de diseño. El desarrollo rápido tiene la ventaja de que permite darse cuenta de ello pronto.

Como se mencionó anteriormente, el número dado con más frecuencia para la diferencia en tamaño y velocidad entre C y C++ es ±10%, y a menudo la diferencia es mucho menor. Incluso podría conseguir una mejora significativa en tamaño y velocidad si usa C++ en lugar de C porque el diseño que haga para C++ puede ser bastante diferente del que haría para C.

Los datos de las comparaciones de tamaño y velocidad entre C y C++ tienden a ser anecdóticos y es probable que sigan siéndolo. A pesar de la cantidad de personas que sugieren que una compañía pruebe el mismo proyecto usando C y C++, probablemente ninguna compañía quiera perder dinero de esa forma a no ser que sea muy grande y esté interesada en tales proyectos de investigación. Incluso entonces, parece que el dinero se puede gastar mejor. Casi universalmente, los programadores que se han cambiado de C (o cualquier otro lenguaje procedural) a C++ (o cualquier otro lenguaje de POO) han tenido la experiencia personal de una gran mejora en su productividad de programación, y es el argumento más convincente que pueda encontrar.

Errores comunes de diseño

Cuando su equipo empieza con la POO y C++, típicamente los programadores pasan por una serie de errores de diseño comunes. Esto ocurre a menudo porque hay poca realimentación de expertos durante el diseño e implementación de los proyectos iniciales, porque todavía no se han formado expertos dentro de la compañía y puede haber resistencia a contratar consultores. Es fácil pensar que se entiende la POO demasiado pronto en el ciclo y se va por el mal camino. Algo que es obvio para alguien experimentado con el lenguaje puede ser un tema de gran debate interno para un novato. La mayor parte de este trauma se puede evitar recurriendo a un experto externo para enseñar y tutorizar.

Por otro lado, el hecho de que estos errores de diseño sean fáciles de cometer apunta al principal inconveniente de C++: su compatibilidad con C (por supuesto, también es su principal fortaleza). Para llevar a cabo la hazaña de ser capaz de compilar código C, el lenguaje tuvo que hacer algunas concesiones, lo que ha dado lugar a algunos «rincones oscuros». Esto es una realidad, y comprende gran parte de la curva de aprendizaje del lenguaje. En este libro y en el volumen posterior (y en otros libros; ver el Apéndice C), intento mostrar la mayoría de los obstáculos que probablemente encontrará cuando trabaje con C++. Debería ser consciente siempre de que hay algunos agujeros en la red de seguridad.



[33] Por las mejoras de productividad que aporta, aquí también debería considerarse el lenguaje Java.