7.2 Algunos antipatrones organi-
zacionales
• Alcance incremental(scope creep): Permitir que el alcance de un proyecto crezca sin el control adecua- do.
• Dependencia de proveedor(vendor lock-in): Cons- truir un sistema que dependa en exceso de un com- ponente proporcionado por un tercero.
• Diseño en comité(design by committee): Contar con muchas opiniones sobre un diseño, pero adolecer de falta de una visión unificada.
• Escalada de compromiso (escalation of commit-
ment): No ser capaz de revocar una decisión a la
vista de que no ha sido acertada.
• Funcionalitis creciente(creeping featuritis): Añadir nuevas funcionalidades al sistema en detrimento de su calidad.
• Gestión basada en números(management by num-
bers): Prestar demasiada atención a criterios de ges-
tión cuantitativos, cuando no son esenciales o difí- ciles de cumplir.
• Gestión de champiñones(mushroom management): Tratar a los empleados sin miramientos, sin infor- marles de las decisiones que les afectan (mantenién- dolos cubiertos y en la oscuridad, como los champi- ñones).
• Gestión porque lo digo yo(management by perkele): Aplicar una gestión autoritaria con tolerancia nula ante las disensiones.
• Migración de costes(cost migration): Trasladar los gastos de un proyecto a un departamento o socio de negocio vulnerable.
• Obsolescencia continua (continuous obsolescence): Destinar desproporcionados esfuerzos a adaptar un sistema a nuevos entornos.
• Organización de cuerda de violín(violin string orga-
nization): Mantener una organización afinada y en
buen estado, pero sin ninguna flexibilidad.
• Parálisis por análisis (analysis paralysis): Dedicar esfuerzos desproporcionados a la fase de análisis de un proyecto, eternizando el proceso de diseño
iterandosobre la búsqueda de mejores soluciones o variantes.
• Peligro moral(moral hazard): Aislar a quien ha to- mado una decisión a raíz de las consecuencias de la misma.
• Sistema de cañerías(stovepipe): Tener una organi- zación estructurada de manera que favorece el flujo de información vertical, pero inhibe la comunica- ción horizontal.
• Te lo dije(I told you so): Permitir que la atención se centre en que la desoída advertencia de un experto se ha demostrado justificada.
• Gallina de los huevos de oro(cash cow): Pecar de au- tocomplacencia frente a nuevos productos por dis- poner de un productolegacymuy lucrativo.
7.3 Relación alfabética de otros an-
tipatrones
• Arrojar al otro lado del muro(thrown over the wall): Cuando un proyecto involucra a varios grupos de trabajo y va pasando secuencialmente de uno a otro, con escasa o nula comunicación entre ellos.
• Billete lobo(wolf ticket): Declarar compatibilidad con un estándar cuando ésta no existe, o bien cuando el estándar solo incluye recomendaciones no obliga- torias que, de hecho, no se siguen.
• Fiesta de los bocazas(Blowhard Jamboree): Cuando se intenta que las decisiones técnicas del proyecto sean las basadas en opiniones de expertos publicadas en prensa.
• Cadena sin longitud(string without length).
• Cajas de diálogos en cascada(cascading dialog bo-
xes).
• Callejón sin salida(dead end): Encontrar un proble- ma que impide continuar trabajando, pero la direc- ción no permite corregir el problema. El equipo que- da estancado.
• Caminar por un campo de minas(walking through
a mine field): Trabajar con un componente pobre-
mente probado (usualmente inestable), y por tanto poco confiable.
• Chivo expiatorio(scape goat): Ante circunstancias de crisis en un proyecto se toma la decisión de di- rigir las culpas a una persona o a un conjunto de personas concretas sin analizar si verdaderamente la naturaleza del problema se encuentra en las mismas.
• Codificación brutal: Presionar a los programadores a trabajar sobre una arquitectura sin diseñar y sin requisitos evidentes.
• Comité designado(appointed team): Crear un comi- té o grupo de trabajo para resolver un problema y no ocuparse de lograr que el grupo funcione.
• Compensación equitativa (egalitarian compensa-
tion): Compensar al personal por el trabajo indivi-
dual hecho.
• Contenedor mágico (magic container): La imple- mentación de métodos que intentan ser tan flexibles como para adaptar su comportamiento a multitud de circunstancias, sobrepasando el umbral de una man- tenibilidad adecuada del mismo.
• Cuerpos tibios(warm bodies).
• Culto al carguero (cargo cult): Consiste en copiar ciertas prácticas que podrían ser consideradas (no siempre) buenas prácticas sin saber muy bien los beneficios o ventajas que proporcionan, provocando esfuerzo innecesario en el proyecto para incorporar- las o problemas.
• Cultura del miedo(fear culture)): Ambiente en el que cada empleado tiene miedo de mostrar el resul- tado de su trabajo por miedo a ser despedido por tener errores.
• Cultura del héroe(hero culture): Se produce cuando una o pocas personas toman la responsabilidad del éxito de todo el equipo o proyecto, a menudo traba- jando sobretiempo.
• Decisión aritmética(decision by arithmetic): En lu- gar de intentar tomar una decisión con los datos dis- ponibles y basado en el conocimiento y experiencia de nuestros colaboradores y el nuestro, se trata de justificar la misma sobre la base de unos factores presuntamente objetivos.
• Desarrollo distribuido geográficamente(geographi-
cally distributed development).
• Desarrollo marcado por las herramientas(autogene-
rated stovepipe): Preferir una solución generada au-
tomáticamente sobre la mejor solución.
• Descomposición funcional (functional decomposi-
tion): Traducir un programa de un lenguaje estruc-
turado a unoOOusando una sola clase y muchos métodos privados.
• Diseñar por diseñar(design for the sake of design): Realizar un diseño excesivamente complejo sin ne- cesidad real.
• Diseño con arquitectura impuesta (architecture as
requirement): Imponer que el diseño considere, obli-
gatoriamente, el uso de herramientas o métodos no necesariamente idóneos.
• Diseño de fregadero(kitchen sink design).
• Diseñadores empíricos(architects don't code): Inca- pacidad del grupo de diseño para evaluar la comple- jidad del objeto diseñado.
• El correo electrónico es peligroso(email is dange-
rous): Peligro de olvidar que detrás de los emails re-
cibidos hay personas de carne y hueso.
• El gestor controla el proceso(manager controls pro-
cess).
• El traje nuevo del emperador(emperor's new clot-
hes): Temor a señalar los defectos de un producto o
proceso que un gerente o manager cree que funciona bien.
• El viejo gran duque de York(the grand old Duke of
York): Cuando los arquitectos o analistas no inter-
vienen (uno o los dos), dejando a los programadores (especialistas en la implementación) prácticamente todas las decisiones a nivel e ejecución de las espe- cificaciones del usuario.
• Ellos me entendieron(they understood me): Expli- car a programadores o diseñadores junior lo que se espera de ellos muy brevemente, y asumir que en- tendieron lo que se les pidió.
• Embudo de excepciones(exception funnel): Atrapar una excepción e ignorarla, sin reportarlo.
• Entrenar al entrenador(train the trainer): Contratar una formación sin haber precisado con cierta exac- titud la materia sobre la que se desea la misma. Es- to puede provocar que la formación no se enfoque de manera adecuada, tratando aspectos que no son necesarios en el proyecto o dejando fuera aspectos fundamentales. Contratar una formación sin tener referencias del formador, ya que lo mismo su nivel de conocimiento no es el adecuado a la naturaleza de la formación a impartir.
• Es un problema de operadores(it is an operator pro-
blem).
• Esconder las armas(cover your assets).
• Falsa economía (false economy): Permitir que los recortes de presupuesto afecten la eficiencia de los trabajadores (las pérdidas terminan siendo mayores que lo ahorrado).
• Falso punto final subrogado (false surrogate end-
point).
• Fechas en punto flotante(floating point times).
• Haz tu propia base de datos(roll your own databa-
se): Ante la necesidad de persistencia de datos se
utiliza una solución que no se basa en un estándar.
• Ingenieros compatibles e intercambiables (plug
compatible interchangeable engineers).
• Introducción de dificultad por analogía (analogy
breakdown): Diseñar por analogía con problemas
resueltos, posiblemente introduciendo dificultades no inherentes al problema, o descuidando dificulta- des propias del nuevo caso que se maneja.
7.3. RELACIÓN ALFABÉTICA DE OTROS ANTIPATRONES 19
• Invocar a constructores con nulos(passing nulls to
constructors).
• La disputa familiar(the feud): Cuando existiendo un conflicto entre gestores de proyectos no se le busca una solución definitiva al mismo.
• La experiencia mata el diseño(architecture by im-
plication): Descuidar el diseño por confiar excesiva-
mente en la experiencia previa.
• Los clientes son tontos(customers are idiots): Pensar que uno sabe más que el cliente, y por tanto no es necesaria una investigación con el cliente.
• Maníaco del control (control freak): El deseo de control lleva a la microgestión y ésta a su vez a una pérdida importante de la capacidad de autogestión del equipo, ya que todos los pasos se miden milimé- tricamente.
• Máquina de Rube Goldberg(Rube Goldberg machi-
ne): Realizar implementaciones muy complejas para
tareas sencillas.
• Matar al mensajero(shoot the messenger).
• Matar dos pájaros de un tiro(kill two birds with one
stone).
• Matrimonio sumarísimo (sumo marriage): Suele ocurrir en cualquier situación en la que exista una dependencia de un elemento o de una serie de facto- res que dificultan el mantenimiento o evolución del sistema.
• Mazorca de maíz(corn cob): Mantener personas en el proyecto que resultan difíciles, conflictivas o que funcionan de manera absolutamente al margen de lo que es cualquier trabajo en equipo o de un compor- tamiento solidario y que rompen con la armonía del grupo.
• Mecanismos de recompensa discordantes (discor-
dant reward mechanisms): Un equipo recibe reco-
nocimiento por ser el que más trabajo ejecuta sobre la base de criterios objetivos que no son válidos para medir el nivel de productividad o calidad.
• Mezclador de software(software merger).
• Miedo al éxito (fear of success): Permitir que las únicas razones de que los trabajos no se completen sean de índole social.
• Moneda en punto flotante(floating point currency): Utilizar una representación en punto flotante para valores que representan dinero, lo que puede provo- car pérdida de precisión.
• Morir planificando(death by planning): Invertir más esfuerzo (y tiempo) del necesario para establecer un plan que después puede ser destruido por las propias
contingencias del proceso de desarrollo, o cuando no se es flexible ante una planificación inicial, conser- vándose a lo largo del proyecto pese a que se pueda apreciar que resulta absolutamente irreal.
• Nacionalismo(national ism).
• Navaja suiza (swiss army knife): Intentar crear un producto que solucione varios problemas poco rela- cionados entre sí.
• No es mi trabajo(Not my job): No solucionar algún problema evidente argumentando que es problema o fallo de otro.
• No especificar(specify nothing).
• No inventado aquí(not invented here): Cuando la or- ganización o uno se niega a utilizar soluciones, me- todologías, prácticas, herramientas, etc. externas só- lo porque no se nos ocurrió previamente.
• Otra reunión más lo resolverá(yet another meeting
will solve it): Ante un problema en la planificación
del proyecto, se convocan reuniones para intentar dar una solución al problema. En éstas reuniones participan los miembros del equipo de proyecto que tendrán que dejar su trabajo habitual, produciéndo- se nuevos retrasos.
• Otro programador más(yet another programmer).
• Presunto heredero(heir apparent): Cuando vemos que los posibles huecos que podrían quedar para se- guir progresando en nuestra organización tienen ya nombres y apellidos (cuando además sus méritos son más que discutibles), provocará la salida de la orga- nización en busca de otras alternativas o se produci- rá una pérdida de motivación que impactará direc- tamente en la productividad.
• Proceso a prueba de idiotas(idiot proof process).
• Programador discordante (net negative producing
programmer): Hay proyectos donde el rendimiento
de uno o más miembros del equipo es muy inferior al esperado, hasta el punto de ser su productividad neta en el proyecto negativa (el proyecto mejoraría con el simple hecho de prescindir de estas personas, sin necesidad de sustituirlas por otra)
• Proyecto del día de la marmota(ground hog day pro-
ject): Discutir los mismos temas en todas las reunio-
nes, sólo para llegar a la conclusión de que “algo debe hacerse”.
• Prueba incompleta(asynchronous unit testing): Des- cuidar en la etapa de pruebas, algunas unidades en todos los casos, o todas las unidades en algunos ca- sos.
• Quiero estimaciones ahora(give me estimates now): Dar estimaciones sin tener suficientes datos para ha- cerlas.
• Requisitos esparcidos por la pared(requirements tos-
sed over the wall): Existe un desorden general en los
requisitos: se encuentran en distinto grado de termi- nación, no hay priorización de los mismos o es muy general como para poder hacer una ordenación ade- cuada por ese criterio, etc. Esto normalmente es pro- vocado por una colaboración inadecuada por parte del área usuaria.
• Requisitos ocultos(Hidden requirements): El equipo de proyecto conocedor de la dificultad de implemen- tar un determinado requisito lo obvia dentro del ca- tálogo de requisitos, le asigna una prioridad muy ba- ja o lo engloba dentro de un requisito de mayor nivel quedando difuminado en el mismo. El área usuaria no especifica un requisito o no lo especifica de ma- nera adecuada, solicitando explicaciones a posterio- ri por la no implementación de ese requisito o por su comportamiento incorrecto.
• Si funciona, no lo toques(if it is working don't chan-
ge):.
• Somos tontos(we are idiots): Pensar que el conoci- miento interno del problema es peligroso (por riesgo de que sea pobre o equivocado), y pedir validación del cliente para cada característica o decisión ma- yor.
• Tarjetas CRCI (CRCI cards): Cuando se usa la técnica de tarjetas CRC, se aprovecha e incluye en la misma la implementación de la clase, convirtiéndose automáticamente la tar- jeta CRC (Class-Responsibility-Collaboration) en CRCI (Class-Responsibility-Collaboration- Implementation).
• Tormenta de reproches (blame storming): En un equipo de proyecto se llega a la conclusión de que la mejor forma de analizar las causas de la no con- secución de los objetivos es que se discuta quiénes internamente han tenido la culpa.
• Torre de vudú(tower of voodoo):Se tiene un código que se sabe que funciona (aunque generalmente no se sabe muy bien cómo) y se pretende añadir algún tipo de funcionalidad adicional, en ocasiones no muy cohesionada con la ya implementada y se le coloca un envoltorio (wrapper) proporcionando una nueva interfaz de acceso a ese nuevo componente.
• Trampa para osos (bear trap): Invertir mucho en una herramienta poco adaptada o factible, de ma- nera que después es imposible deshacerse de ella.
• Único punto de salida de función(single function exit
point).
• Valor por defecto indefinido(zero means null): Es- coger un valor arbitrario para representar la indefini- ción, sin garantizar que ese valor no puede realmente ocurrir.
• Violencia intelectual(intellectual violence): De ma- nera interna en un equipo de trabajo o en una reunión con el cliente y/o con usuarios se utilizan términos, generalmente técnicos, que no son com- prendidos o conocidos por la mayoría de los inter- locutores.
7.4 Véase también
• Patrón de diseño • Crisis del software • Hediondez del código • No hay balas de plata
7.5 Enlaces externos
• C2.com (antipatrones) Portland Pattern Reposi- tory's Wiki
Capítulo 8
Archivo de cabecera
Se denomina header file, alespañolfichero/archivo (de) cabecera, o include file, al español fichero de inclu- sión, en ciencias de computación, especialmente en el ámbito de los lenguajes de programaciónC y C++, al
archivo, normalmente en forma decódigo fuente, que el
compiladorincluye de forma automática al procesar al- gún otro archivo fuente. Típicamente los programadores especifican la inclusión de los header files por medio de
pragmasal comienzo (head o cabecera) de otro archivo fuente.
Un header file contiene, normalmente, una declaración directa de clases, subrutinas, variables, u otros
identificadores. Aquellos programadores que desean declarar identificadores estándares en más de un archivo fuente pueden colocar esos identificadores en un único
header file, que se incluirá cuando el código que contiene
sea requerido por otros archivos.
Labiblioteca estándar de C y la biblioteca estándar de C++tradicionalmente declaran sus funciones estándar en
header files.
8.1 Motivación
En la mayoría de lenguajes de programación modernos, los programadores pueden dividir losprogramasen com- ponentes de menor tamaño (como pueden ser clases y
subrutinas) y distribuir esos componentes entre muchas unidades por traducir (típicamente en forma dearchivos), que el sistema puedecompilarde forma autónoma. Si una subrutina se tiene que usar al margen de la unidad por traducir donde ha sido definida, se tiene que introducir el concepto de declaración directa oprototipos de funcio- nes. Por ejemplo, una función definida así en un archivo fuente:
int add(int a, int b) { return a + b; }
puede declararse (con un prototipo de función) y ser re- ferida desde un segundo archivo fuente como sigue: int add(int, int); int triple(int x) { return add(x, add(x, x)); }
Sin embargo en esta simple ilustración se requiere que el programador mantenga la declaración de la función de add en dos sitios ̶en el archivo que contiene su imple- mentación y en el archivo que usa la funcionalidad. Si la definición de la función llega a alterarse, entonces el programador debe actualizar todos los prototipos repar- tidos a lo largo del programa. Esto es necesario porque la implementación de ambos, C y C++ han de diagnosti- car todas las violaciones de lo que en C++ se llama "one definition rule" (ODR), al español “regla de una única definición”. De hecho, la mayoría de ellos se sirven de unenlazador para realizar esta labor. El enlazador, sin embargo, suele conocer, de forma muy limitada los tipos usados en los programas. Por ello, algunas de las viola- ciones de ODR no se detectan a la hora de implemen- tar el lenguaje. Como resultado, es responsabilidad del programador el mantener la coherencia de todas las de- claraciones que cruzan las fronteras de una unidad por traducir. Buscar todas estas declaraciones de una entidad externa y verficar que son compatibles de forma manual es una tarea ardua. (Nótese que C no define el término “one definition rule”̶es específico del lenguaje C++. Si declaraciones de la misma entidad en muchos archivos fuentes de C son diferentes, la función no funcionará de forma adecuada y puede llegarse a uncomportamiento impredecible, independientemente de la regla que se esté violando.)
Para entender una violación ODR, considérese el siguien- te código (correcto):
/* File print-heading.c */ #include <stdio.h> void print_heading(void) { printf(“standard heading\n”); } /* File main.c */ void print_heading(void); int main(void) { print_heading(); return 0; }
La unidad por traducir representada por el archivo fuen- te main.c referencia a la función print_heading() que está definida en otra unidad por traducir (print-heading.c). De acuerdo con las reglas deC99, los programadores deben declarar una función externa antes del primer uso. Para cumplir con este requisito el archivo main.c declara la función en la primera línea. Esta versión del código fun- ciona de forma correcta.
Posteriormente, el programador que mantiene el archivo
fuente print-heading.c puede decidir hacer la función más flexible y dar soporte a cabeceras a gusto del usuario. Una posible implementación podría ser la siguiente:
/* File print-heading.c */ #include <stdio.h> void print_heading(const char *heading) { printf("%s\n”, heading); }
Si el programador olvida actualizar la declaración en main.c, se pueden dar resultados devastadores. La fun- ción print_heading() espera un argumento y hace uso del valor del mismo, sin embargo la función main() no pro- vee ningún valor. Al ejecutar este programa se produce un comportamiento impredecible: la aplicación puede im- primir basura, terminar de forma inesperada o dar pie a resultados impredecibles en la plataforma en la que es eje- cutado.
¿Por qué se puede compilar y enlazar este código sin pro- blema alguno? El motivo es que el compilador se guía por la declaración en main.c a la hora de compilar la unidad por traducir main.c. Y esa declaración se ajusta con la for- ma de la función. Más tarde, cuando el enlazador combina las unidades de traducción ya compiladas main.c y print- heading.c (en la mayoría de implementaciones represen- tadas como archivos main.o o main.obj), probablmente podría detectar la inconsistencia ̶pero no en C. Las implementaciones en C referencian las funciones por el nombre al nivel de archivo objeto y archivo binario, esto no incluye el valor de retorno o la lista de argumentos. El enlazador encuentra una referencia a print_heading() en main.o y una función adecuada en print-heading.o. Lle-