TL; DR
Nunca lo sabrás todo. Casi siempre hay más profundidad y amplitud en torno a cada "cosa" individual que puedes conocer. Aprende sobre la marcha. Aplique las "mejores prácticas" que considere relevantes ahora. Cometer errores. Solo trata de evitar cometer errores realmente costosos . Encuentre mentores si su proyecto puede conducir a errores costosos.
Y ahora la respuesta larga ...
1. "El software de trabajo es la medida principal del progreso". ( Manifiesto ágil )
Si puede ver los límites de su conocimiento, ¡eso es increíble! ¡Persigue los bordes! ¡Seguir aprendiendo! Pero tenga en cuenta que podría aprender y analizar para siempre .
Construye algo.
2. Aprender y cometer errores; pero no hagas los "malos". *
Sigue empujando los límites de tu conocimiento / habilidad. Usted va a cometer errores. Puedes aprender de ellos. Pero, no necesitas ser imprudente .
El tiempo que pasa buscando y trabajando con desarrolladores y mentores más experimentados debe aumentar en proporción al valor comercial y al perfil de riesgo del proyecto.
Si está haciendo una pequeña CLI para usted : haga que funcione como quiera.
Si está escribiendo el portal web de un banco: Rodéese de desarrolladores muy experimentados.
3. Las "mejores prácticas" deben escribirse entre comillas y hablarse con un guiño.
Las "prácticas" se promueven a "mejores prácticas" cuando se observa que tienen éxito en lograr X en al menos algunos casos. Alguien reconoce el beneficio de la Práctica A para lograr el Beneficio X y declara que la práctica es una "mejor práctica" en Internet. Otros están de acuerdo, a menudo por una buena razón. Pero, a partir de ese momento, generalmente perdemos de vista por qué algunas prácticas son "mejores prácticas" y otras son "antipatrones" o "apestosas".
El problema es que una "mejor práctica" nunca es egoísta. Los "antipatrones" no son en realidad diabólicos en sí mismos. Y, incluso un "hedor" solo a veces proviene de la podredumbre. A veces, ese olor es solo un queso delicioso y delicioso ...
No practica cosas como "inyección de dependencia" (DI) porque la "inyección de dependencia" es inherentemente valiosa para el negocio. Ni siquiera es remotamente esencial para construir un producto que funcione. Logra algo que quizás desee en su producto final. Pero, también podría hacer que su trabajo tarde más sin ningún beneficio ...
Hmm ...
Entonces, ¿debería seguir las "mejores prácticas"? ¿Incluso si no los entiendes? ... Err ... sí. Quiero decir, no. Pero si. Pero, solo los que realmente se aplican a usted y su software y su propósito.
¡ Invoca al POAP ! (Sí. Mi blog).
Los principios, patrones y prácticas no son propósitos finales.
Por lo tanto, la buena y adecuada aplicación de cada uno está inspirada y limitada por un propósito superior y más final. ¡Necesitas entender por qué estás haciendo lo que estás haciendo!
(El POAP no está exento del POAP).
Por lo tanto, es posible que no comprenda todos los matices de DI, por ejemplo. Pero, si comprende la intención, sabrá si "debería" usar DI, y entenderá implícitamente mejor DI.
Y, una vez que haya lanzado el producto, puede reflexionar sobre si DI (o lo que sea) fue realmente beneficioso. Si es así, articule por qué por escrito. Si no, articule por qué por escrito ...
Lectura adicional / Algo relevante:
La parálisis de análisis es una cosa. Necesitas analizar y aprender; pero, también necesitas hacer cosas. Equilibrar.
Siempre puedes sentirte como un codificador de vaqueros .
* En realidad se va a hacer grandes errores si lo hace notar nada. Pero, eres humano, supongo. Entonces, te perdonamos por adelantado ... O, al menos, lo hago. Tal vez. ... Bueno ... ya veremos.