Piense en esto como una buena oportunidad para aprender una modularización extrema, que de todos modos es una buena idea. Supongo que eres un profesional independiente o un desarrollador pequeño e independiente. Si es así, tú y yo tenemos algunas cosas en común, ya que eso es lo que he hecho durante 25 años.
Aquí hay algunos trucos:
1. Averigüe a qué hora del día es más tranquilo (después de que los niños se hayan acostado, sus clientes se hayan cerrado por el día, etc.), y reserve un bloque de tiempo para codificar durante ese interludio pacífico. Haga de este su momento principal de codificación, pero durante el resto del día, intente hacer algo cada vez que haya pausas.
- Si un programador hace una solicitud para su uso personal, ¿prefiere construir ese programa en forma de GUI o CLI?
- ¿Qué tan bueno será usar Kotlin en el desarrollo de aplicaciones de Android? ¿Qué pasa si alguna compañía no comienza a usar Kotlin?
- ¿Cuál es considerado el mejor software legal de tiempo y facturación / gestión de documentos (combinado) que existe hoy en día?
- ¿Cuáles son las aplicaciones de IoT?
- ¿Cuál es la vida útil promedio del 'período de luna de miel' de una tecnología de software de código abierto? (es decir, antes de que una solución o paradigma alternativo quite la atención).
2. Planifique su código con cuidado; divídalo en las unidades de prueba más pequeñas y fáciles posibles. No se preocupe si tienen sentido en términos de la arquitectura “perfecta” en un entorno más estructurado. Implemente y pruebe cada segmento de código como una sola unidad. Si no eres religioso acerca de TDD y las pruebas unitarias, ahora es el momento de comenzar a desarrollar los hábitos correctos para garantizar un trabajo de alta calidad. Te encontrarás escribiendo un código más simple y más comprensible. Haz tu mejor esfuerzo para asegurarte de que ningún método requiera más de unos minutos para escribir y probar. Si no funciona para usted, divídalo en unidades aún más manejables.
3. Si practica Agile, ahora es el momento de * DROP IT. * No funcionará a menos que tenga las horas para bloquear todo lo demás. Al principio, este método puede parecer la cascada del mal, así que asegúrese de tener muy claras las especificaciones y el diseño de cada módulo antes de hacerlo. Además, si no está seguro sobre el sistema, verifique doble y triplemente para asegurarse de que funciona, pero no produzca cargas de documentación que lo encerrarán. Solo mantenga suficientes notas para recordar sus decisiones. .
4. Utilice un sistema de gestión de cambios real que servirá como una lista de verificación, asegurándose de que realmente pruebe cosas, marque todas sus i y cruce todas sus t. Esto descarta a Git, básicamente dejándolo con la opción de algo como Aegis 4.24. Es el único CMS que lo obliga a mantener las tres leyes de Miller de gestión del código fuente, que son las siguientes:
1. El número de interacciones dentro de un equipo de desarrollo es O (n!) Sin acceso controlado a la línea de base, en cuyo caso puede reducirse a cerca de O (n), siendo n el número de desarrolladores y / o archivos en el árbol de origen, el que sea más grande.
2. La línea de base DEBE estar siempre en funcionamiento.
3. El proceso de compilación / construcción del software se puede reducir a un gráfico dirigido y acíclico (DAG), también conocido como Recursivo Hacer que se considere perjudicial.