Introducción: El peor proyecto que hayas visto, ¿cuánto tiempo te llevó terminar? ¿Seis meses? ¿Un año? El extraño proyecto presentado hoy no solo fue horrible al principio, también duró más de 12 años hasta que el líder del proyecto fue arrestado y encarcelado.
¿Qué tan malo es? Decirle con los siguientes datos impactantes:
Un total de más de 6 millones de líneas de código C ++,
un total de más de 50,000 clases,
limitadas por la versión del compilador, la sintaxis de C ++ utilizada está desactualizada y solo se puede implementar
en un determinado sistema operativo (no mantenido).
Software de base de datos basado en CORBA De una empresa que quebró durante mucho tiempo
. Varias capas superpuestas conforman la interfaz de usuario, y el autor original no mantiene ninguna de estas capas. Para
ejecutar una interfaz de usuario se requieren 40-50 subprocesos comenzado
. requiere 48 sobre 32 máquinas paralelas. Compilación en horas.
Sin el uso de la biblioteca de tiempo de ejecución de la tecnología de enlace dinámico, un programa ejecutable es tan grande como cientos de megabytes. se tarda unos 15 minutos para la puesta en marcha. es
por lo general se bloquea dentro de los 30 segundos a 30 minutos.
Proyectos malos a "nivel del infierno" que nunca has visto
Hace diez años, en 2008, los fallos del proyecto de blogs de tecnología dieron la noticia. En esos años, el blogger había sido empleado de una gran empresa de tecnología francesa y participó en un proyecto de software encargado por una agencia gubernamental. El puesto era consultor. Allí, fue testigo de la mayor estupidez y locura y el terrible papel que desempeñaron en el desarrollo de software.
Diez años más tarde, este proyecto infernal se volvió a dar la vuelta, y hubo un revuelo nuevamente, y el blog projectfailures incluso publicó una reseña sobre él.
En el artículo, escribió: "Esto ya no es solo una falta de competencia profesional. El despiadado atropello de la dignidad humana en este proyecto se ha vuelto tan grave que a veces me hace sentir como si estuviera en la cárcel".
¿Qué? Es solo escribir un código, además de perder el cabello, ¡te meterás en tu vida! ? ¿Por qué este proyecto es tan aterrador?
¿Cuál es la situación con este proyecto?
Alrededor de 1996, una agencia del gobierno francés pidió a una empresa que desarrollara un software. En general, esto no debería ser demasiado complicado, pero hay algunos pequeños problemas inusuales que deben resolverse.
La Parte A pagó varios millones de euros por adelantado y el período de construcción previsto era de unos 2 a 3 años. Entonces, la empresa contrató a algunos programadores y comenzó a trabajar. Con los fondos disponibles, la empresa comenzó a contratar gente frenéticamente, duplicando el equipo cada tres meses aproximadamente.
Como resultado, 7 años después, este proyecto aún no ha tomado forma. Las multas por retrasos ascienden a varios miles de euros diarios. Entonces, la gerencia decidió agilizar el equipo y reducir los gastos del proyecto; el método específico es abrir a todas las personas que trabajan y también reclutar a algunos novatos que no tienen experiencia en desarrollo de software para trabajar.
Diez años después del inicio del proyecto, todo el proyecto ha estado sumido en el cenagal de los desastres, y está completamente compuesto de puro caos. Entonces, los gerentes de nivel medio del proyecto finalmente decidieron contratar a algunas personas con experiencia en desarrollo de ingeniería de software para sacar el lío del infierno.
Después de otros dos años, el proyecto aún persiste. La empresa solía enviar a la Parte A una factura de "cambio de diseño" con montos crecientes para compensar la multa diaria por retrasos en la construcción. ¡Todo esto es en 2008!
¿Cómo puede ser tan malo este proyecto?
- La calidad del código es terrible
En cuanto a la selección del idioma, nadie se atreve a decir que C ++ es un lenguaje simple y fácil de entender. De hecho, C ++ es probablemente el peor lenguaje de programación en términos de simplicidad. Ya sabes, es tan complicado que incluso su creador, Bjarne Stroustrup, no se atreve a decir que domina completamente el idioma.
Por supuesto, esto no se puede culpar completamente al equipo de desarrollo. Ya sabes, en ese momento, todavía había un gran mercado para pensar laberintos como C ++ con una complejidad infinita. Muchos jóvenes que desean convertirse en súper programadores están ansiosos por este lenguaje súper sonoro. De hecho, la mayoría de estos niños pobres fueron abusados por C ++ al final. Cuántos jóvenes hermosos se pasaron depurando repetidamente una gran sección de código oscuro y difícil, y se dedicaron a explorar por qué este programa no tendría ninguna razón. El colapso inexplicable ocurrió.
Las personas con cerebros normales han recurrido a otros idiomas y otros proyectos. Ya sabes, la vida es corta
Sin embargo, parece que esta empresa no ha salido de este círculo ni se ha hundido en el pozo de C ++.
Dando un paso atrás, no importa qué lenguaje de programación esté utilizando, mantener una base de código enorme no es una tarea fácil en sí misma, y la base de código de este proyecto es en realidad más de 6 millones de líneas.
Entonces, ¿cuál es el concepto de más de 6 millones de líneas de código?
En contraste con el código del kernel de Linux 3.13, excepto por el controlador y la arquitectura del kernel, el código fuente en el kernel / tiene solo unas 130.000 líneas; otro ejemplo es el famoso editor Emacs, que tiene demasiadas funciones y es demasiado grande. a menudo se queja de "falta de un sistema operativo con un buen editor", pero aun así, el tamaño total del código fuente es de sólo 1,59 millones de líneas.
Incluso si eres muy bueno, con diez líneas de un vistazo, probablemente tengas que pasar 7 días despierto frente al monitor para completar los 6 millones de líneas de código.
Así que podemos imaginarnos cuántos programadores se están volviendo locos para mantener una base de código tan grande. Eche un vistazo a los siguientes dos ejemplos, creo que si fuera programador, primero estaría loco.
Una vez, se le pidió a un programador del proyecto que corrigiera un error que decía que "al hacer clic con el botón derecho en la interfaz se congelaría toda la aplicación". Después de varios días de inspección cuidadosa y agotar incontable paciencia, descubrió que el evento de respuesta del botón Es normal, pero este proceso "normal" requiere que el programa se tome 45 minutos para generar dinámicamente cada elemento del menú a partir de una biblioteca de contenido enorme (¡estática!), y luego mostrar el menú. Si vuelve a hacer clic en el botón derecho en este momento, lo sentimos, tomemos otros 45 minutos para volver a generar el elemento del menú ...
En otra ocasión, el usuario informó un error "No se pudieron cargar los datos del CD-ROM". Los programadores pasaron varias semanas probando y analizando el código, pero al final marcaron directamente el problema como "resuelto". Porque descubrieron que la función de cargar datos desde un CD-ROM es realmente buena, el problema es que se tarda unos 7 días en leer 700 MB de datos.
Realmente pone a prueba la paciencia.
El control de versiones está desordenado
Increíblemente, el equipo trabajó durante varios años sin una herramienta de control de versiones, hasta que un miembro del equipo con la mente clara de repente pensó en usar una herramienta de control de versiones para administrar el código. Los resultados de los intentos iniciales no satisficieron a todos, por lo que el equipo cambió a otro sistema de control de versiones. Durará uno o dos años, y luego este sistema de control de versiones de alguna manera se puso al día y perdió todos los registros de cambios anteriores.
La herramienta de control de la versión final seleccionada para este proyecto es un flagelo con una interfaz gráfica de usuario, una pila de desechos electrónicos digitales importados directamente de Suecia. Tuvieron que organizar a 4 personas para formar un "equipo de control de versiones" que era responsable de mantener el funcionamiento normal del sistema de control de versiones a tiempo completo. Esto conduce directamente a las siguientes situaciones:
1) Para consultar archivos del sistema de control de versiones por primera vez, debe concertar una cita con el equipo de control de versiones. En general, puede obtener la autorización después de una semana.
2) Si desea modificar el archivo, debe pasar por la aprobación de la gerencia media. Debe enumerar los archivos que deben modificarse con anticipación, informarle a su gerente la lista y luego informar al equipo de control de versiones para solicitarlo. Este último le dará su opinión en aproximadamente dos días.
3) Cada modificación de un archivo activará una rama, lo que significa que usted mismo debe fusionar todas las modificaciones recibidas por este archivo. Puede pensar que con tantos archivos en el proyecto, las posibilidades de que dos personas cambien al mismo archivo deberían ser pequeñas. Sin embargo, de hecho, la mayoría de los cambios se concentran en los mismos alrededor de 100 archivos, por lo que cada combinación está garantizada para hacer eres infeliz.
4) Antes de enviar la modificación (verificar el archivo), también experimentará una tortura mental: el código que va a enviar será entregado a un programa de detección automática de errores para su revisión, y después de que se apruebe, se mostrará a los mandos intermedios Para enviar correctamente. No hace falta decir que esto no sirve de nada. Los insectos siguen apareciendo como brotes de bambú después de la lluvia. Es mucho más rápido de lo que todos pueden eliminar. Es más, después de analizar la cantidad de errores encontrados, se encuentra que la cantidad de errores nuevos traídos por este método de "corrección de defectos" es el doble de la cantidad de errores que corrige ...
5) La gestión de versiones es demasiado sencilla. La versión anterior es 1, la versión actual es 2 y la versión posterior es 3. Nadie puede saber exactamente qué versión se envía al cliente.
En ocasiones, la dirección establecerá un llamado plazo de entrega oficial, y este horario no tiene nada que ver con ningún tipo de plan de trabajo en el equipo. Cuando llegó la fecha de entrega programada, el cliente recibió un CD en blanco con un tutorial de instalación ... porque nadie podía crear un programa ejecutable durante varias semanas. Como resultado, el cliente descubrió que había recibido un CD en blanco y luego se quejó formalmente, y luego recibió una versión antigua del CD del programa como respuesta. La razón por la que el cliente encuentra que el programa es una versión anterior es porque la página "Acerca de" del software todavía tiene la misma fecha que la versión del año pasado ...
La composición del equipo es aún más inexplicable
El equipo está lleno de un grupo tan grande de personas sin ninguna experiencia en ingeniería de software. Si no hay muchos errores en este software, sería realmente irrazonable, ¿verdad?
Recuerde que, como se mencionó anteriormente, la gerencia una vez decidió racionalizar el equipo.
Es lógico que cualquier gerente con una mente normal encontrará que para un proyecto de ingeniería de software tan puro, el gasto de personal debe ser el gasto más importante. Sin embargo, este descubrimiento no impidió que la gerencia abriera a todos los programadores con un poco de experiencia y los reemplazara con novatos con requisitos salariales mucho más bajos. Por el contrario, todos los puestos de trabajo de los directores se mantuvieron con firmeza y no se vieron afectados en absoluto.
Parece que libros como "Aprenda usted mismo C ++ en 21 días" deben ser considerados clásicos por ellos.
No, eres demasiado ingenuo y "Aprende C ++ en 3 días".
¿Qué ha sido de este equipo? De las 55 personas, solo hay 20 programadores y las 35 restantes son gerentes. Sí, lo leíste bien, esta alineación es realmente lujosa, ¡con 1,75 administradores para cada programador!
Pocos gerentes tienen experiencia en ingeniería de software. En ese momento, sucedió que SCO tomó los derechos de autor de Unix para demandar a los usuarios de Linux. Incluso si todo fue solo un engaño, todavía era terrible para muchas personas: si un día de repente tienes que pagar por software gratuito, ¿qué tan bueno es? ¿ese?
También se carece bastante de conocimientos técnicos. Han pasado 200 veces más años. Pocas personas en este grupo tienen algún conocimiento de Internet. Los pocos que están familiarizados con Internet están viendo pequeñas películas en Internet. Si menciona lo que ha leído en Internet, solo obtendrá las risas de otras personas.
La dirección anormal del modelo de gestión administrativa
La ridícula situación anterior puede hacer reír a la gente, pero si sabes que el grupo de franceses en la dirección son como demonios alemanes en el campo de concentración de Auschwitz, probablemente no te reirás. Echemos un vistazo a estas morbosas regulaciones burocráticas:
1) Las llegadas tardías están prohibidas, todos deben estar de servicio antes de las 9 am. Un día, el gerente de recursos humanos se paró temprano en la puerta de la empresa y despidió en el acto a todos los que llegaron a la empresa después de las 9:01. Los programadores, gerentes y ventas no fueron inmunes.
2) La máquina de café se apaga de vez en cuando, lo que dura varios días. La razón, por supuesto, es que las personas que van a tomar café no son tan eficientes como las personas que se sientan y escriben código. No solo eso, cada vez que un líder llega al departamento de desarrollo para su inspección, la máquina de café se apagará, para que el líder no vea que alguien "no está trabajando".
3) Se puede decir que el nivel de inodoros sucios y desordenados es el único repugnante y aterrador en la industria. Creo que esto se debe a la política "eficiente" de la administración para evitar que todos pasen tiempo en baños pagados.
Quizás tenga que preguntarse, ¿por qué la gente viene a trabajar en una empresa tan pervertida? Lo más importante es que durante ese tiempo, la economía doméstica francesa estaba al borde del colapso (hasta ahora, Francia no ha salido completamente de este atolladero). No es fácil encontrar un trabajo que sea suficiente para hacer un vivir y las condiciones de trabajo son duras.
El final inevitable
Como comentaron los internautas, todo el proyecto está atrapado en una cadena sin fin: la falta de experiencia conduce a la ineficiencia, la ineficiencia conduce a demasiados gastos generales, ahorros de costos y despidos de personas experimentadas, lo que reduce aún más la eficiencia.
Entonces, ¿por qué la gerencia todavía se queda sentada y observa cómo esta situación empeora? En el análisis final, sigue preocupando el fracaso. Si recorta el proyecto, significa que el proyecto ha fracasado y la persona con la responsabilidad de liderazgo es usted. Si este proyecto aún persiste, luego de que lo asciendan y lo transfieran, su sucesor naturalmente limpiará el desorden.
Al final, el líder de la empresa a cargo de este proyecto fue arrestado por malversación de fondos y otros motivos, y fue a la cárcel.Este proyecto, que había estado luchando en las llamas del infierno durante más de diez años, finalmente se dio por terminado.
Como testigo de todo el asunto, el blogger de projectfailures aconseja a los jóvenes que acaban de entrar en el mundo de la programación:
1) Aprecie la vida, no se lance con C ++;
2) Preferiría tomar algunos proyectos pequeños que no son tan estables, pero que pueden aprovechar al máximo sus fortalezas y no codiciar participar en algo que parece proyecto muy altisonante;
3) La base de datos orientada a objetos no es algo bueno;
4) CORBA debería morir de dolor;
5) Esos estúpidos gerentes de producto, por favor consulte el anterior.
Finalmente, si sientes que tu trabajo actual es muy espantoso e irritante, espero que este proyecto te haga un poco feliz.
