Cómo convertirse en un desarrollador backend rudo

Al escribir código y ganar experiencia. Pero, ¿cómo escribes código y ganas experiencia? Ahora toda mi respuesta se basa en el hecho de que todo lo que voy a decir, lo harás solo con dosis SALUDABLES de escribir código, cometer errores y volver a intentarlo.

Algunos hábitos que los desarrolladores “rudos” tienen, se desarrollan a través de experiencias dolorosas. Puede, por ejemplo, aprender “Desarrollo guiado por pruebas” para ganar puntos de brownie, o puede hacerlo porque es flojo y ha aprendido de la manera difícil que las funciones de escritura de forma incremental mientras arregla constantemente las pruebas, es la única forma de mantenerse cuerdo. Notarás que ninguno de los principales grandes proyectos ágiles tiene “bifurcaciones de características de un mes” que se fusionan de repente y luego intentan arreglar las pruebas o escribir pruebas.

Entonces, mientras haces las cosas que te digo que hagas, también comenzarás a darte cuenta de estos hábitos.

Esto es lo que haces:

1. Identifique un problema difícil primero. No tiene que ser único. Siempre y cuando no sea trivial.

2. Comience a escribir código para ello.

Ahora, esta es la “salsa secreta” para hacerte rudo: que te das cuenta de algunas verdades sobre el desarrollo del backend y aceptas estas verdades por ti mismo. No porque lo dije, sino porque los has probado y SABES que son ciertos.

Pregunta, luego PRUEBE sus suposiciones.

a) Te dirán que nunca debes crear muchos objetos, pruébalo. NO HE CONOCIDO UNA VEZ una persona cuyo sistema se ralentizó porque crearon demasiados objetos.

b) Se le informará que hacer demasiadas llamadas de red es “costoso”. Nunca conocí a alguien que realmente hubiera enfrentado esta realidad. Hacer el mismo trabajo una y otra vez es lo que causa el gasto. La red no tuvo nada que ver con eso. El problema raíz nunca son las llamadas de red, es que el flujo

c) Se le dirá cómo usar “las variables globales es malo y cómo no las usamos”. Le prometo a cada persona que dice que está mintiendo. 🙂 Java tiene variables estáticas que se usan PESADAMENTE. El estado compartido es lo que impide que las personas tengan una arquitectura adecuada, y ninguna cantidad de libros, sinergia, dinamismo, UML, diagramas, etc., lo solucionará. Obtendrá un turd pulido, pero tener un estado global compartido sigue siendo un turd. 🙂

EXCEPCIÓN: a menos que alguien esté usando Erlang o alguien realmente tenga procesos de sistema operativo independientes que transmitan mensajes de un lado a otro. 🙂 Si conoce a esa persona, envíeme su referencia. ¡Tienen un trabajo esperándolos en este momento!

d) Valórate en los resultados, no en el trabajo duro. El hecho de que tenga una cobertura de código del 100% línea por línea no significa que obtendrá nada de sus pruebas. Escriba pruebas SIGNIFICATIVAS que le digan algo.

e) Por el AMOR DE DIOS no optimices. Aprenda las siguientes tres reglas de desarrollo de software:

1. Primero haz que funcione.

2. Luego hazlo hermoso.

3. Luego, si es necesario, hazlo rápido.

La optimización es el resultado de la arquitectura y las decisiones algorítmicas, que no reemplazan la elegante recursión con bucles deslumbrantes dignos de la pantalla de un pirata informático. CONOZCA esta realidad. Escriba programas que hagan ambas cosas y dígame cuándo comienzan a divergir. ¿Mil millones de iteraciones? ¿Un trillón de iteraciones?

f) Usa Chaos Monkey. Todo lo que asumas NO va a salir mal: haz que salga mal y mira cómo se ocupa tu sistema. Si aprende una verdad fundamental durante esta fase, que es que sucede una mierda, y su código que asume esta realidad, es MUCHO más simple, más fácil de entender y mejor factorizado, que el código que supone que la mierda NUNCA sale mal y es perfecto. hora.

Si te das cuenta de esta verdad, hazme un ping. Tengo un trabajo esperándote.

g) El punto anterior es por qué REST se ganó a RPC (SOAP, Corba, XML-RPC, RMI, DCOM, EJB, y más …) El código REST API es más simple Y aún más confiable tanto en clientes como en servidores. Casi suena como … ¿ironía? Sí.

Aprenda de esto: hay una razón por la cual las personas que tienen que soportar miles de máquinas, prefieren pequeños servidores node.js que atienden una solicitud a la vez, pero pueden hacer girar un millón de réplicas de sí mismos en una máquina, en lugar de un gigante que requiere 20 minutos para el inicio, crea 20,000 subprocesos y luego se arrastra (ver Tautología 3: Todos han compartido el estado. El resto está mintiendo).

h) Literalmente 1 de cada 100 personas que afirman haber ejecutado “miles de máquinas” literalmente ha ejecutado miles de máquinas. Hay MUY pocas veces que necesita miles de máquinas, y los problemas que enfrenta al manejar flotas de ese tamaño son francamente extraños. El hecho de que haya superado el tamaño de 100 máquinas no significa que sepa cómo son “miles” de máquinas.

Cosas totalmente inesperadas como las memorias intermedias TCP de su máquina comienzan a utilizar más memoria que su proceso principal, porque cada conexión entre máquinas requiere una memoria intermedia. Las búsquedas en la tabla de enrutamiento le cuestan más tiempo que “crear objetos”. Todos esos esfuerzos de agrupación de objetos solo le costaron costos horribles en el bloqueo, y ni siquiera fueron sus décimos polos más largos. 🙂

Reserve 1000 máquinas en EC2 y ejecútelas detrás de un equilibrador de carga. Mira qué pasa. Sonará tan rudo y autoritario en cualquier entrevista real, se reirá en la mitad de las entrevistas cuando pretendan estar probando para “software escalable”.

Eso es todo lo que tengo. ¿Notó una clara falta de opciones tecnológicas aquí? Si es así, ya estás en un buen comienzo. Use quick-basic para todo lo que me importa, y si sigue las reglas anteriores, su programa ampliará y superará la plataforma Enterprise-Ready documentada por UML con diseño de patrón de diseño más hiper optimizado en el mercado.

De la misma manera que te vuelves rudo en todo …