Me refiero a TDD, DDD, Integración Continua, Patrones de Diseño, SOLID etc a un nivel profesional.
Al menos un nivel por el cual una empresa que lo pide como requisito no te descarte por ello porque me imagino que haber hecho una calculadora con TDD no sirve como "se programar siguiendo TDD" 
Eso es todo mentira (TDD/DDD), solo lo hacen 4 bichos raros. Lo que tienes que hacer es leerte en wikipedia lo que se supone que es, y si cae en la entrevista te inventas historias donde explicas lo bien que lo usasteis.
Las buenas prácticas: currando, informándote y aprendiendo de gente buena (remarco este último adjetivo). Luego verás que en el 95% de los sitios ni TDD ni DDD ni hostias, y el Agile suele ser una versión degenerada del agile "teórico". Si hay tests unitarios y de integración, de puta madre. Si encima tienes end to end / canaries / regresión / etc. ya cremita.
Patrones Solid y otros patrones de programación => a buscar en wikipedia, entenderlos y practicar. No te queda otra. A no ser que busques proyectos que los usen y aprendas de ellos, pero te llevará más tiempo.
Pd: en programación, por lo general, lees en lo que consiste algo y lo utilizas. Todo lo que sea intentar no practicar o no picártelo te va a dar un conocimiento más superficial. En la mayoría de los casos, cuando aprendes e interiorizas un patrón es cuando lo necesitas, lo aplicas, ves las partes que no entiendes o no te encajan, y lo implementas bien. Seguramente las horas que te dé eso no te lo va a dar leer código en GitHub ni un artículo. En los artículos y en GitHub "todo compila".
Como todo, la practica hace al masilla maestro, montate alguna projecto intentando seguir los patrones, buscate un framework opinionado que implemente alguno de estos paradigmas para hacerte alguna idea.
Mirate algun cursillo de udemy youtube y ojea algunos repos en github que implemente estas architecturas en tus leguajes para entender mejor como funciona todo.
Y poco más, pica codigo hasta que cerebero lo asimile
#1Pizzelio:Al menos un nivel por el cual una empresa que lo pide como requisito no te descarte por ello
no te rayes por que en la descripción del las ofertas te lo pongan como que son lo más top en cuanto a prácticas de desarrollo, a la hora de la verdad en la mayoría de sitios la gente hace lo que le sale sale de las pelotas y los repositorios de código en las empresas son una fiesta
Por si te sirve de ayuda... yo TDD lo uso rara vez y si lo uso es cuando me viene un cliente con un pete 'funcional'. En ese caso trato de reproducir el error mediante un test, una vez lo tengo reproducido cambio el código para que pase el test que he creado. Punto y final.
Ya te han dicho, no te preocupes por no tener todos los conceptos super claros y asimilados. Al final del día el único principio que realmente valoramos todos es el de KISS (Keep It Simple Stupid).
#4 Raves bien gordas se montan algunos.
Las ofertas son copia pega unas de otras, te piden de todo lo que quieren hacer en su roadmap invent.
Nadie hablando de CI cuando da la vida hacer un push y que ya este el deploy en los entornos que corresponda
Piensa que las entrevistas van en dos direcciones: pregunta al entrevistador cómo aplican TDD/DDD, qué sistemas de CI/CD usan (Teamcity, Jenkins, etc) y a ver con qué cara te contesta.
#8 no, mejor encontrarte en una empresa donde te dicen que hacen CI/CD el desplegar directamente en producción sin test ni validación ni pollas. Eso sí que da gusto. Encima etiquendo y subiendo las imagenes docker como latest, ahí con dos cojones.
Ojalá empresas sin chapuzas
Joder pues vaya chasco, prácticamente no hay empresa que no lo pida y yo como un parguela diciendo que no lo sé, en fin
#12 Existir existen, pero por lo general son pequeñas empresas. En la que estoy te aseguro que no piden gilipolleces. Usamos metodologías y tal... pero no lo van pidiendo como requisito indispensable... en 2 semanas de uso te lo aprendes para ser útil... como para bloquear un candidato por tan gran gilipollez.
Es como no contratar a un gran piloto por que no te sabe decir la composición de un neumático que no ha usado en su puta vida.
#13 joder, flipo de verdad. hice una prueba técnica en la que incluso me pedían que usara TDD. Y yo sin tener ni puta idea hice una ñapa importante jajaja
#14 cuando te piden eso, lo mínimo es saber hacer testing, cuatro test unitarios y arreando. Pero de ahí a seguir a rajatabla el decálogo del TDD o DDD hay un trecho XD
Lo único que tienes que hacer en ese caso es asegurarte tener una cobertura del 100%. Es decir, que TODA la lógica que hayas escrito esté testeada en un sitio u otro. Con eso vas que ardes, les dices que has aplicado TDD y a correr.
#14 Ya te digo que son temas "asusta-viejas"... yo creo que lo hacen para medirte psicológicamente, como respondes cuando no sabes... ¿preguntas o tiras balón hacia delante haciendo mierda a ver si cuela hasta que la cosa te explota en la cara? Se prefiere al primero que al segundo... y es muy fácil caer en ser de los segundos.
Pero si prácticamente todas las empresas que piden TDD/DDD/${RANDOM_COOL_PARADIGM} son un pufo que flipas.
Nada de lo que dices son buenas practicas de desarrollo.
Una buena practica de desarrollo es utilizar la herramienta y metodologia de trabajo adecuada para tu problema.
