Psss, ¿quieres algunas historias terribles de TI?

¿Tienes miedo a la oscuridad? ¿Quizás un apocalipsis zombie o monstruos debajo de la cama? Nosotros no lo sabemos. Nosotros, los especialistas de TI, tenemos sus propias fuentes de horror: usuarios corruptos, lejos de los jefes de TI, servidores bloqueados, copias de seguridad faltantes o no realizadas, código establecido y reuniones ágiles, cuando de hecho todo el desarrollo se controla gritando "ayer", "el cliente está lanzando" , "Allí criticó el producto". En la víspera de Halloween, decidimos encontrar las historias más terribles, contar algunas de las nuestras y al mismo tiempo escuchar las suyas. Bueno, ¿estás listo para contar las historias de alma escalofriante?

Calentamiento fácil hasta la piel de gallina

Comencemos con una función muy simple. En teoría, debería verificar si el número es primo.

bool primeCheckUgly(unsigned long long int n){//good luck     ... 

Bueno, si el comentario nos deseó buena suerte, entonces definitivamente está listo para ver una captura de pantalla del código completo para esta función. Estas listo Bien?


¿Y qué hace el fragmento de código en la siguiente captura de pantalla?

Tiempo de historias de miedo con Reddit

Historia 1

El usuario vino a discutir si este código es adecuado ... para una aplicación comercial. Los comentaristas estaban al menos en estado de shock y encontraron muchos problemas:

• pesadillas amenazas de seguridad, vulnerabilidades SQL
• problemas con el soporte de código (monolito para 3.5 mil líneas)
• problemas con la escala
• trucos, funciones y organización terribles del código (el autor no se arrepintió de los espacios)
• estructura deficiente y legibilidad del código.

Los lectores severos aconsejaron irse como están y aprender una lección para los negocios (sí, nosotros, como proveedor de alojamiento, también sabemos qué tipo de clientes pobres provienen de proveedores "gratuitos" de arado). Bueno, el mejor comentario ha salpicado: "Si no fuera por el alcohol, la mayoría del código que veo también me mantendría despierto" (Si no fuera por el alcohol, la mayoría del código que vi tampoco me dejaría dormir).

Historia 2

Un tutorial en línea trata cada palabra como un elemento HTML separado, por lo que no es posible copiar y pegar más de 10 palabras por párrafo. Sin embargo, en algunos lugares Reddit es casi como Habr; por lo tanto, en los comentarios, solo unos pocos usuarios comentaron sobre el autor del código como mu ** ke, el resto dio muchos consejos sobre cómo evitar esta función y obtener todo el texto de la mejor manera posible. Si alguien necesita métodos, puede leer sobre ellos en el hilo mismo .

Historia 3

A este tipo se le pagó $ 50 por hora por dicho código, y creó (nagovnokodil) un archivo completo de más de 3000 líneas.

El cliente tiene la culpa, decidió la comunidad, porque $ 50 es un centavo, lo que significa que solo puede confiar en contratar a un "mono". Algunos decidieron que era solo una broma de mal gusto y el chico estaba poniéndose al día con su reloj. Bueno, un análisis detallado de lo que está mal en el código en el hilo .

Historia 4

Esta, por supuesto, es una historia que raya en la ciencia ficción, pero que en los albores de una hermosa juventud no hizo algo así.

El tipo era demasiado vago para seleccionar todos los archivos en el directorio y no encontró nada mejor que usar la utilidad

 rm -rf /* 

Pero algo, aparentemente, se saltó un latido en su alma y se volvió hacia su estación de servicio, ya sea que se eligiera el tren de pensamiento correcto, el tipo recibió la confirmación y ... bueno, ya entiendes. Los comentarios ofrecen el cien por ciento: "qué sabrosas son tus lágrimas", "no tiene sentido preguntarle al gerente técnico cómo eliminar archivos en Linux", "no debes sentirte muy cómodo con Linux" (creemos que todavía hay un poco de problemas con Google y sentido común) , "¡Falla!" Creemos que la historia se parece más a una bicicleta, pero fue por ella que un desafortunado escalofrío pasó por la parte posterior y de alguna manera inmediatamente quise salir de la raíz. Por cierto, también hay algunos consejos útiles .

Historia 5

Una bicicleta similar a la anterior. Un equipo :-)

 sudo rm –fr / 

La historia de nuestro amigo de su experiencia pasada.

"Año 2008. Nuestro sitio ha sido pirateado. Era un sitio normal y seguro, visitado por más de 5,000 personas por día. Y en la página principal apareció un texto con errores sobre el Pentágono y amenazas de quitarnos cien millones (por cierto, esto era solo una parte de los ingresos de la compañía). Sat-shniki en las orejas, el director en pánico, STO lavó la cuerda, los desarrolladores corrieron a por la vaselina. Nada Cerraron el sitio, colgaron 404, recibieron una ráfaga de llamadas. Al día siguiente, mamá a la Anfisa Chekhov vino con el mejor jugo y trajo a un niño completamente torturado de 16 años en vasos. Dice: "Este es mi hijo, es un hacker, llévalo al trabajo". La estación de servicio salió del circuito, tomó la pequeña por el hombro y la obligó a mostrar la pequeña chuchería (no hemos anunciado los detalles), le contaron a su madre sobre el Código Penal de la Federación de Rusia, pero le presentaron algo al tipo.

En general, el factor humano es la razón por la que cada uno de nosotros puede tener un Halloween personal en cualquier día laboral.

Cómo no convertirse en un héroe de tales historias para sus colegas

Consejos de programador

• Comente el código, especialmente si es nuevo en el desarrollo. Esto lo ayudará a usted, a sus colegas y a quienes ingresarán al proyecto mucho más tarde.
• Mejor aún, escriba un código legible. El código no es más que un lenguaje de comunicación especial para un equipo de programadores. Un buen código es autosuficiente, ten esto en cuenta. Deja que incluso aquellos que vienen al equipo después de que lo entiendas.
• Llama a variables y funciones unidades léxicas normales para que puedas entender lo que deberían hacer. FsskdQwertZeta mal MoveEmployeeFromList normal.
• Siga el estilo de código adoptado por la empresa: gracias a esto, el proyecto no solo será comprensible, sino también seguro: cualquier desarrollador del equipo podrá realizar cambios en una emergencia sin perder tiempo desentrañando la ofuscación o un mal estilo.
• No desperdicie basura en el código, módulos, proyectos. Elimine los módulos innecesarios, no arrastre el legado que no funciona con usted, si es posible, refactorice para tirar muletas y derretir bicicletas a un buen código.
• Prueba tu código, revisa los scripts del mundo real. Si no prueba el código, lo probará prod :-)

Consejos para administradores de sistemas

• Documente su trabajo para que sea más fácil para sus colegas, los trabajadores por turnos y usted mismo comprender los escenarios estándar.
• Hacer copias de seguridad. Hacer su madre, copias de seguridad!
• Automatice su trabajo, use sistemas de tickets y sistemas de monitoreo.
• Trabaje solo a pedido, para que pueda probar que está trabajando y no conduciendo a Dota, y que "simplemente recargar la base 1C" no es "simple".
• Construya un sistema de seguridad de la información en la empresa, evite las ofensas de colegas y especialmente de "usuarios avanzados" entusiastas.
• Registro, registro, mantener registros.
• Tenga un fondo de reemplazo de periféricos y hardware, administre licencias, haga un presupuesto: sea un gerente de TI y no solo un "llamado".

Obviamente, ¿no es así? Pero el cumplimiento de estos principios simples cerrará más posibles problemas que pueden convertirse en historias escalofriantes sobre Habré, Reddit y otros recursos donde su feroz fakap está listo para discutir.

Amigos, hoy, en Halloween, anhelamos historias escalofriantes y su práctica de TI. ¿Qué hizo que tus palmas sudaran, oscuras en tus ojos y frescas por dentro? Para la mejor historia (con la calificación más alta de comentarios), daremos premios. Para el primer lugar: una sudadera con capucha autografiada por thelevelord , creador de Duke Nukem:


Para el segundo lugar: stock de calcetines para todo el año :)