Cómo convertirse en un desarrollador de software realmente malo

Bueno, eso es bastante simple e implica exactamente dos pasos:

1. Para convertirse en un desarrollador de software realmente malo, conviértase primero en desarrollador de software. ¿Cómo logras este objetivo? Aprenda herramientas. Aprenda uno o dos idiomas, aprenda lo suficiente para poder construir software de trabajo. Una vez que sabe construir software, es un desarrollador de software. Uno malo Así que vayamos directamente al paso número dos.
2. Para convertirse en un desarrollador de software realmente malo, aprenda más herramientas, más idiomas, más marcos, sea bastante bueno en herramientas. Omita lecciones sobre mejores prácticas, SOLID, patrones de diseño, TDD, BDD, pruebas automatizadas, conceptos y arquitectura. Simplemente mejore su conjunto de habilidades de herramientas. Luego conviértete en un líder tecnológico o gerente y haz que la vida de tus colegas / subalternos sea una pesadilla.

¡Felicitaciones, ahora tu obra de arte está completa!

Por cierto, ¿podrías dejar de fumar justo antes del paso número uno? Estoy realmente harto de trabajar con esas personas y no me gustaría más en la industria. Puedes ser un guardaespaldas y experimentar los mismos sentimientos que un desarrollador de software realmente malo, con la única diferencia de que los que sufren por ti serían los delincuentes, no los desarrolladores.

1. Escribe todo tu código en una línea.
2. Nunca comentes tu código.
3. Use la menor cantidad de espacios en blanco posibles.
4. Use nombres de variables esotéricas.
5. Sé lo más ineficiente posible.

Por ejemplo, en lugar de:

while (1) {// haz algo
}

Haz esto en su lugar:

int esoteric_function (int potato) {
int i = 0;
para (i = 0; i pid_t cuchara = tenedor ();
si (cuchara> 0) {
cuchara de regreso; // ¡Déjame convertirme en zombie!
}
}
}

while (esoteric_function ((int) strlen (“yay code! \ n”))) {/ * haz algo * /
}

6. Asegúrese de que sus documentos estén escritos con poca gramática y ortografía.

7. Nunca tome el consejo de nadie, especialmente el desbordamiento de pila.

8. Siempre deje el código más desordenado que cuando lo encontró por primera vez.

La lista continúa, pero no soy muy creativo. Sin embargo, a través de la pereza, la arrogancia y la estupidez, ¡estoy seguro de que cualquiera puede convertirse en un terrible desarrollador de software en poco tiempo! ¡Buena suerte!

Nunca he conocido a nadie que quiera ser un mal desarrollador o programador de software (). ¡Pero internet es un lugar extraño!

Empecemos:-

1. No es necesario tener una discusión detallada con el cliente / cliente sobre los requisitos.
2. No es necesario tener un diseño sólido adecuado según los requisitos. Desarrollar junto con el diseño. ¡Asumir riesgos!
3. Desarrolle lo que quiera en lugar de lo que quiere el cliente / cliente. ¡Ser creativo!
4. Fase de implementación:-

• Utilice tantas herramientas / idiomas como sea posible para que no pueda integrar los productos intermedios.
• Hazlo lo más complejo posible. ¡Ten confianza!
• No trabaje en condiciones y bucles correctamente.
• Escriba su programa / código sin sangrado, lo que dificulta su comprensión y depuración.
• Sin documentación (sin comentarios). ¡Porque eres una estrella de rock!
• Declaración del mismo nombre de variable en diferentes ámbitos, lo que lo hace ambiguo.
• El desperdicio de memoria / espacio es su derecho de nacimiento. Ve a por ello.
• Nunca omptimices tu código.
• Escriba un programa con tantas líneas de código.
• El método de fuerza bruta tiene que ser tu mejor amigo.
• Nunca use fundición.
• Joder manejo de excepciones.
• Haga que la IU sea lo más compleja posible.

5. Fase de prueba: –

• No es necesario considerar todos los casos / escenarios de prueba.
• Nunca vayas por críticas. Pérdida de tiempo hombre!
• ¡No confíes en los probadores, las pruebas alfa, las pruebas beta, etc., son para débiles!

6. Nunca complete su producto antes de los plazos. ¡¡¡¡Grande, no!!!!

7. No es necesario siquiera pensar en el mantenimiento del producto.

Incluso después de todo esto, si su cliente está contento con su trabajo, amigo mío, no puede ser un mal desarrollador.

Eres demasiado bueno para algo (¿sarcasmo?)

1. Comience a codificar lo antes posible, cuando no sepa lo que necesita implementar en detalle.
2. Recuerde: cada línea de código tiene valor. A medida que pasa el tiempo, solo agregue el código. Nunca reescriba o refactorice. Comente las partes no utilizadas en lugar de eliminarlas.
3. La ifología cuenta. Especialmente anidado.
4. Lo mismo ocurre con las elaboradas declaraciones de cambio / caso.
5. Use el control de fuente solo si su gerente se lo ordena. De lo contrario, manténgase alejado de él: mantenga versiones consecutivas en diferentes directorios o simplemente sobrescriba los archivos.
6. Utilice nombres de variables / funciones / clases / métodos lo más cortos posible. No dude en usar su idioma nativo si no es inglés; particularmente importante para proyectos internacionales.
7. Utilice bibliotecas y marcos patentados tanto como sea posible. Recuerde, el software de código abierto es malo, porque más personas pueden encontrar sus errores y explotarlos. La seguridad por oscuridad es tu mejor amigo.
8. Manténgase alejado de los lenguajes populares como Python, Java, C # o incluso C. Recuerde acerca de las características que tal vez quiera usar en el futuro, así que si estaba pensando en escribirlo en C, use C ++ en su lugar.
9. Usa clases / objetos para las cosas más simples.
10. Los literales enteros son malos, las constantes son buenas. Entonces, `#define ONE 1`.
11. Apunte a una única plataforma / SO y confíe en gran medida en su API. Puntos de bonificación si no se ha actualizado durante más de diez años.

Aquí hay una combinación de algunas cosas que debe hacer. He observado estos hábitos de varios colegas a lo largo de los años.

Cómo ser un terrible programador.

• Culpe a los usuarios finales por todo porque …

• Obviamente, es su culpa.
• Arreglar el sistema hace felices a los usuarios.
• Los usuarios felices no cerrarán sesión en una reescritura completa.
• Podrías reescribir todo en un mes.

• Sería mucho mejor que el pedazo de basura que tienen ahora.

• Los desarrolladores originales eran imbéciles.
• El sistema es un POS imposible de mantener. Se tarda demasiado en hacer cambios.
• Si solo todos te escucharan, reconocerían tu genio.

• “Sr Sra. Ejecutivo “no tiene idea de cómo funciona la industria.

• Sigue teniendo que explicar cómo debería funcionar el negocio.

• Escribiste algo de ese código.

• Esas variables no se cambiaron de nombre.
• Los comentarios necesitaban más sarcasmo y agresividad pasiva.

• Oh mierda, lo hace?

• Necesita un lugar para almacenar el código al que pueda acceder desde su casa y su trabajo.
• Esa computadora portátil es pesada, no pueden esperar que lleves esa cosa a casa todos los días.
• No puede transmitir Netflix mientras está conectado a VPN.
• El manual no decía que el repositorio de GitHub tuviera que ser privado.

• Bueno … eh … el manual no menciona a GitHub en absoluto. Eso significa que no estaba violando ninguna política. Ah-ha! ¡Mate!

• Bueno, sí, los datos de prueba son de la base de datos de producción. Con datos falsos, ¿cómo sería real la prueba?
• Mantener los datos de prueba en el repositorio es simplemente conveniente. Trabaja más inteligente, no más duro, duh
• Ven uno! No es como si tuvieras un número de seguro social. Solo eran nombres de clientes, direcciones, números de teléfono, correos electrónicos y números de cuenta.
• Usted lo dice como es. La cultura de la PC sea condenada

• Sabes que las mujeres son más propensas a las falacias lógicas. Por eso no hay mujeres en TI. No tienen la lógica, a diferencia de ti.

• Estabas deteniendo tu carrera profesional trabajando allí.
• Te llamarán cualquier día para pedir ayuda. Entonces puedes remojarlos por $ 250 / hora.
• Te llevó una eternidad descubrir esos sistemas. De ninguna manera alguien más podrá resolverlo.
• Ellos llamarán pronto.
• …
• Cualquier día de éstos
• …

Solo usa todos los enfoques muy muy baratos. Como ejemplo, si desea ingresar 10 números desde la consola, hay varias construcciones de bucle para iterar varias veces y estructuras de datos para contener estos números. Pero, para realmente deteriorar tus habilidades de programación,

En lugar de

int arr [] = nuevo int [10];
para (int I = 1; I <= 10; I ++)
arr [I] = sc.nextInt ();

Utilizar,

int a, b, c, d, e, f, g, h, i, j;
a = sc.nextInt ();
b = sc.nextInt ();
c = sc.nextInt ();
d = sc.nextInt ();
e = sc.nextInt ();
f = sc.nextInt ();
g = sc.nextInt ();
h = sc.nextInt ();
i = sc.nextInt ();
j = sc.nextInt ();

Podría ser aún peor cuando generalmente tratamos con grandes cantidades de datos.

¡Eso es bastante fácil!

Todo lo que necesitas hacer es lo siguiente.

No lea los documentos, por lo tanto, escriba los programas utilizando solo las funciones de idioma que conoce.

No use las funciones / bibliotecas existentes en su base de código. Reinventa la rueda todo el tiempo.

No se tome un tiempo para comprender todo el sistema, rompa las cosas mientras agrega nuevas funciones

Simplemente copie y pegue el fragmento que encontró en Stack Overflow, sin entenderlo.

No use linters, IDE o cualquier herramienta que haga la vida de los desarrolladores más fácil, use el bloc de notas o gedit todo el tiempo.

Simplemente no discuta con sus compañeros de equipo sobre el esquema o la arquitectura antes de construir, porque todos sabemos que es capaz de cambiar todo el día antes de la implementación si es necesario.

Quemarse, de esa manera es fácil perder productividad.

¡Felicidades! usted acaba de hacer que su vida y los miembros del equipo vivan en el infierno por … ya sabes … ser un mal ingeniero de software.

Bueno, convertirse en un “desarrollador de software realmente malo” no es tan difícil. Sin embargo, aquí hay siete consejos de oro:

1. Escribe códigos que solo tú puedas entender.
2. Cubre solo los escenarios de casos promedio y no los casos extremos.
3. Di no a la documentación.
4. Di no a las pruebas y la verificación.
5. Utilice los sistemas de control de versiones de las peores formas posibles. Por ej. Mensajes de confirmación incorrectos.
6. Trabajo intenso y trabajo duro al escribir un código de espagueti.
7. Use las declaraciones ir a la mayor frecuencia posible. Descarta lo que prof. Dijkestra dice.

PD : 1,6 y 7 están correlacionados.

1. No escriba ninguna prueba unitaria
2. No siga las convenciones de nomenclatura, es decir, nombre variables como i, j, k.
3. Nombre funciones / métodos para que nadie obtenga ninguna pista por el nombre para qué sirve.
4. Declarar variables con alcance global
5. Nunca se moleste en usar patrones de diseño y cree un largo tren de si no.
6. Escriba la lógica máxima dentro de un solo método / función.
7. Capture excepciones pero no lo maneje.
8. No te preocupes por el registro
9. Nunca pienses en proteger tu código

Si sigues estas cosas definitivamente serás un mal desarrollador de software.

Aquí hay una receta para el desastre:

1. Obtenga algunas especificaciones de codificación de su analista de sistemas.
2. Hace dichos cambios de codificación
3. Agregue sus propios cambios de codificación
4. No pruebes tu código
5. Mover código a producción
6. Espere a que el código explote en producción, lo que resulta en una llamada de 3 am a la persona de guardia.
7. Espera a que todos te odien

Esto no me sucedió a mí, pero a alguien que conozco

Ser un mal desarrollador de software no es un objetivo fácil de lograr. Antes de que me olvide, no soy un desarrollador de software.

No es un camino fácil, pero el proceso se puede dividir en muchos pequeños pasos. De hecho, el primero se trata de dividir. Foget it. especialmente cuando se trata de código.

-Funciones?

-¡Nah! Principal es suficiente.

-¿Clase?

-Woot? ¿Qué hay de mi principal?

Sé que eso conducirá a un código duplicado, que no es malo per se, pero debería evitarse. Nunca cree dos variables para el mismo propósito, es decir, contadores para bucles. Su código debería verse así:

int a;
for (; a <10; a = a ++ + 1) {// hacer cosas
}
mientras que (a + 7> = 7) {
// hacer otras cosas} hacer {
// incluso más cosas} mientras
();

Tu objetivo final es escribir cosas como esas a diario. Sabes que te estás acercando a esto cuando las personas que revisan tu código son así:

¿Ves lo que dijo? Bus en llamas. Necesitas producir un autobús en llamas. Olvídate de la parte elegante de la programación. Los programadores reales no usan bucles, piensan en cada caso y les aplican una solución diferente:

if (! string == strings) // nunca use isEqual u otras cosas elegantes
{if (! string == stringss) {if (! string [56] == ‘s’)
} if (cadena [a] == ‘d’) {
// bueno, lo que sea que intentara demostrar, ya no sé qué es
// Y por cierto, nunca comentes tu código
// los programadores reales pueden entender el código con solo mirarlo
string [56] == string [a] // aquellos que no pueden hacer eso no son aptos para el trabajo, eso es todo
if (string.length> 2) {
diga “La cadena puede ser demasiado larga, pero lo manejaremos”;
int b = 0;
String ideal = “mi cadena ideal”
si (b == 0) {
cadena [0] = ideal [0];
cadena [b ++] = ideal [–b + 1];
…
cadena [z] = ideal [34];
}
}
}

Ok, podría estar llevando esto demasiado lejos. En realidad, lo único que debe hacer para ser un mal programador es usar JavaScript. Sonrisas

Hay muchas formas de ser un mal programador. Aquí están algunos

• no seguir SECO (No te repitas)

No siempre tiene que ser así y tener mucha experiencia en no repetirse tampoco te hace tan bueno. Pero el programador debe tener la sensación de no repetir su código o patrones.

• no usar bibliotecas

Crear abstracciones innecesarias sobre las bibliotecas estándar es un rasgo muy común en los programadores malos.

• no sigue los estándares

No seguir el formato / convención de un idioma es molesto para los desarrolladores experimentados en la comunidad.

• sin documentación / comentarios

Es muy malo no dar a otros programadores una idea de lo que está sucediendo. Una mala convención y esperar que todos entiendan su código es otro rasgo malo del programador.

• sin preocuparse por el rendimiento

No es el peor rasgo, especialmente durante la creación de prototipos. Sin embargo, en ciertas etapas puede ser un rasgo muy peligroso.

Jaja,

Aquí hay algunas manías mías.

1. Crea una función o clase que haga todo.
2. Crear código con ramificación excesiva.
3. Asegúrese de que su código esté lleno de pérdidas de memoria, sin manejo de excepciones y sin mensajes de error.
4. Haz que tu interfaz de usuario sea lo más complicada posible.
5. No pongas comentarios en tu código
6. No le dé nombres descriptivos a sus variables y métodos.
7. Asegúrese de que todas sus variables y métodos sean globales y públicos.
8. Finalmente, nunca trabajes en la misma compañía en la que estoy.

1- Ponga mucha documentación en su código: funciones de comentarios, líneas de código, ¡CUALQUIER COSA! es genial

Su código se mantendrá y sus comentarios NO, NUNCA, por lo que el código terminará con comentarios fuera de lugar o que sean falsos, lo que empeorará las cosas.

¿Y qué hay de 20 líneas de comentarios por cada 10 líneas de código? maravillosa manera de llenarlo de ruido !!!

2- Haz muchas cosas en cada función, por lo que te verás obligado a poner comentarios para dar una pista al próximo lector de lo que querías hacer.

llamada pública (Object obj) {
inner.prepareCaller ();

// preparar objeto para llamar al servicio
obj.setWillCall (verdadero);
obj.letSerialize (verdadero)
obj.whatever ();
…
return inner.getResponseFrom (url, obj);
}

Vs

llamada pública (Object obj) {
prepareCall (obj);
return inner.getResponseFrom (url, obj);
}

O incluso:

llamada pública (Object obj) {
inner.prepareCaller ();
obj.prepareToCall ();
return inner.getResponseFrom (url, obj);
}

Muchas cosas y muchos espacios en blanco, por favor,

3- Use muchos espacios en blanco dentro de las funciones, porque el espacio en blanco el 99,99% del tiempo significa: ‘ahora haré algo diferente en la misma función y sé que debería estar en otra función, pero soy demasiado vago para hacerlo ‘(ver ejemplo arriba)

4- Poner muchas responsabilidades en cada clase. Importante para difundir el dolor.

5- Sé eficiente: es importante ser eficiente porque así la computadora entenderá tu código mejor que tus compañeros de trabajo … La optimización prematura es la raíz del éxito de ser un mal desarrollador.

6- Copiar y pegar. Mucho, es lo más importante que puedes hacer para ver cómo tu código se convierte en un montón de mierda.

7- En cualquier momento de tu carrera piensa que no tienes nada que aprender de nadie. Debido a que los desarrolladores buenos y malos tienen algo que enseñarte sobre lo que está mal y lo que está bien, debes evitar que empeore. ¡Incluso podrían convencerte de que estás haciendo algo mal! ¡No los dejes! para ser el peor desarrollador, debes mantenerte firme en tus debilidades.

PD, dejando que el sarcasmo y siendo honesto:

Tuve que editar después de leer el comentario de David Balme porque creo que muchos otros pueden malinterpretarme:

La primera regla, la regla de oro, de cualquier buen desarrollador es que el trabajo DEBE HACERSE A TIEMPO. No tiene sentido hacer algo técnicamente perfecto si no está terminado o está fuera de tiempo y ha perdido su tren para el éxito (hubo una publicación de Joel sobre esto, The Duct Tape Programmer).

Entonces, comenzando en este punto, TODAS las Reglas y las buenas prácticas son SOLAMENTE reglas que puedes (y a veces debes) romper.

Con esa idea en mente, escribí ese punto (primero) sobre los comentarios:

La regla debe ser (¡es!) Que los comentarios son basura y que debe evitarlos.

Pero bueno, a veces estás fuera de tiempo, o no estás en tu mejor día o lo que sea, incluso sí, también encuentro buena idea comentar funciones no privadas en las clases o incluso ese extraño truco que hace que el código funcione. Puede confiar en los comentarios, pero debe conocer La regla. La Regla dice que no deberías necesitar comentarios, pero los estás usando … no hay problema con eso si sabes que generalmente no es una buena idea.

Y lo digo porque al leer algunas publicaciones, alguien puede terminar pensando que “no poner comentarios es algo que hacen los malos desarrolladores” y no, estoy totalmente en desacuerdo con eso: la regla es que no deberían ser necesarias, úselas si es necesario para usted, pero por favor no diga que no usarlos es un olor a código porque simplemente …

No lo es

Si realmente te tomas esto en serio, lee y practica lo siguiente:

Cómo escribir un código que no se puede mantener (garantizar un trabajo para toda la vida 😉)

Droogans / código no mantenible

Como sugiere el título, le brinda varias ideas comprobadas sobre cómo escribir código incorrecto y al mismo tiempo asegurar su trabajo.

Haz muchas clases / métodos que hagan cosas similares. Dales nombres similares.

Cuando no pueda determinar cuál usar, simplemente escriba otro.

Asegúrese de que haya sistemas incestuosos de llamadas interrelacionadas para que no sea fácil desenredar.

Mezcle la funcionalidad de varias capas juntas.

Jajaja está bien, hiciste esta pregunta, así que no digas que no la respondí, de todos modos …

1. Escriba sudo rm -rf en un script adjuntándolo al correo electrónico y haga que todos sus compañeros de trabajo lo abran si tienen Linux.
2. Haga su código tan ilegible que todos simplemente se vayan. p.ej

   include int string_length (char aString []); int main (int argc, char ** argv) {printf (“La cadena% s tiene% d caracteres de largo. \ n”, argv [1], string_length (argv [1])); devuelve 0; // Salida exitosa} int string_length (char aString []) {int length = 0; while ((aString [length]! = 0)) {length ++;} return length; // Regresó a la función de llamada (principal)

   (Diviértete leyendo eso: D)

3. Dígale a sus nuevos empleadores que tiene experiencia en 12 idiomas diferentes e hizo un proyecto completo en cada uno, pero realmente acaba de escribir “hola mundo”.
4. Si un compañero de trabajo dice que revise por pares su código, felicite su diseño y cuán agradables son sus variables en los comentarios y no hay comentarios verdaderos.
5. Escribe todo tu código en main sin funciones.
6. No cometer errores al manejar casos.
7. Si eres un programador en C, abre 255 bytes de memoria no requerida y no la liberes.
8. Agregue comentarios en cada línea como si sus compañeros de trabajo fueran legos en la programación.
9. Por favor, no haga nada de esto, nos enojará a todos los desarrolladores / ingenieros de software.

No hay comentarios y siempre usa el método de fuerza bruta, también conocido como bucles. Si tiene una mejor manera de hacer algo con una lista, ignore y use un bucle. Para que su solución siempre sea innecesariamente de mayor complejidad temporal. No siga ninguna convención de codificación aparente para sus nombres de variables. Y hacer esos nombres de variables al azar. Aprieta tus cosas en largas filas y no uses espacios en blanco.

Un ejemplo sería

En lugar de hacer esto:

foreach (var persona en personaLista) {

ProcessPersonRecord (persona);

}

hacer esto:

ProcessPersonRecord (persona [0]);

ProcessPersonRecord (persona [1]);

ProcessPersonRecord (persona [2]);

ProcessPersonRecord (persona [3]);

ProcessPersonRecord (persona [4]);

ProcessPersonRecord (persona [5]);

ProcessPersonRecord (persona [6]);

ProcessPersonRecord (persona [7]);

ProcessPersonRecord (persona [8]);

ProcessPersonRecord (persona [9]);

ProcessPersonRecord (persona [10]);

ProcessPersonRecord (persona [11]);

ProcessPersonRecord (persona [12]);

ProcessPersonRecord (persona [13]);

ProcessPersonRecord (persona [14]);

ProcessPersonRecord (persona [15]);

ProcessPersonRecord (persona [16]);

ProcessPersonRecord (persona [17]);

ProcessPersonRecord (persona [18]);

ProcessPersonRecord (persona [19]);

ProcessPersonRecord (persona [20]);

ProcessPersonRecord (persona [21]);

ProcessPersonRecord (persona [22]);

ProcessPersonRecord (persona [23]);

y así hasta la eternidad!