Trabajo de organización de un solo programador

El autor del material, cuya traducción publicamos hoy, dice que la mayoría de los programadores trabajan en equipo. Sin embargo, en algún momento de una carrera, un desarrollador puede necesitar trabajar solo. El alcance principal de los enfoques para la organización del trabajo en productos de software está diseñado específicamente para su uso en equipos. Estos enfoques se expresan en las reglas adoptadas por las organizaciones. Dichas reglas simplifican el trabajo, ayudan a los programadores a hacer su trabajo de manera rápida y eficiente. Algo similar sería muy útil para aquellos programadores que trabajan solos.


¿Qué pasa con el que trabaja solo? ¿En qué enfocarse, esforzándose por construir un flujo de trabajo claro y eficiente? ¿Qué principios y reglas seguir? Sugerimos buscar respuestas a estas preguntas juntos.

Sobre programadores solitarios

Aquí, hablando de "programadores solitarios", me refiero a todos aquellos que trabajan en un entorno no estructurado y no oficial. Puede ser un programador único o un pequeño grupo de personas comprometidas, por ejemplo, en su tiempo libre, con algún tipo de proyecto. Aquí hay algunos ejemplos:

• Desarrollo de un proyecto de código abierto, como un paquete o algún tipo de biblioteca.
• El proyecto personal de alguien, que puede ser comercial o gratuito.
• Independiente

Todos estos ejemplos están unidos por el hecho de que el trabajo de los programadores involucrados en algo similar generalmente no está regulado por un cierto conjunto de reglas, como las que generalmente se encuentran en las empresas.

¿Por qué un solo programador debe preocuparse por las reglas?

Las reglas, al aplicarlas al trabajo independiente de los programadores en ciertos proyectos, son importantes por varias razones. Considéralos.

▍ Reglas personales y posible trabajo en equipo.

Un programador cuyo trabajo independiente está bien organizado puede unirse a un determinado equipo. En este caso, hay muchas posibilidades de que se convierta en un miembro valioso de dicho equipo. A saber, estamos hablando de lo siguiente:

• Si se unió a un equipo que sigue las mismas reglas que él, entonces no tendrá que perder tiempo tratando de profundizar en los problemas de la organización. Él, literalmente desde el primer día, estará listo para un trabajo productivo.
• Si se convirtió en parte de un equipo, las reglas adoptadas en las cuales difieren de lo que está acostumbrado, no le llevará mucho tiempo aprender estas nuevas reglas. Después de todo, él, acostumbrado a organizar racionalmente su trabajo, se guía por ciertas ideas generales, que, con seguridad, son similares a las que subyacen en las reglas del equipo. Como resultado, puede alcanzar rápidamente un alto nivel de productividad laboral.
• Si se metió en un equipo en el que no hay reglas en absoluto, entonces, dependiendo, por supuesto, del equipo, puede ofrecerle su visión de la organización del trabajo de los programadores, que bien puede mejorar el trabajo de dicho equipo. Si los miembros de un equipo mal organizado se niegan a cambiar algo, entonces esta es una ocasión para pensar en dejar dicho equipo.

Como resultado, un programador solitario que organiza racionalmente su trabajo, en cualquier caso, es el ganador.

▍ Reglas y nivel profesional de un programador

El desarrollo de software no es solo un proceso de escritura de código. Hay muchos detalles que son responsables de convertir una idea en un proyecto terminado y luego mantenerla en condiciones de funcionamiento. La introducción de técnicas avanzadas de desarrollo de software en el flujo de trabajo personal ayudará a un solo programador a seguir con confianza el objetivo para el que se está creando el proyecto y evitar situaciones en las que todo parece tan confuso que no está claro dónde avanzar.

Si a usted, como a mí, le gusta programar, siempre estará tentado a comenzar un nuevo proyecto e inmediatamente, sin mirar atrás, se precipitará al abismo de escribir código. Pero la experiencia me dice que si tengo un cierto plan de trabajo de alto nivel, sin dañar la flexibilidad de que el desarrollo individual es diferente, ayuda a evitar muchos problemas de diferentes escalas.

Hable sobre las mejores prácticas para el desarrollo de software.

Siga las reglas que describen su flujo de trabajo.

El "flujo de trabajo" es una secuencia de pasos que debe seguir en el proceso de convertir una idea en un producto terminado. Aquí hay algunas preguntas que deben ser respondidas por las reglas que rigen el proceso de trabajar en un producto de software:

• Cuando se decide hacer un cambio en un producto, ¿cuál es el orden de su implementación?
• ¿Cómo es la transferencia de nuevas versiones del producto a los usuarios?
• ¿Cómo se rastrean los cambios de producto?
• ¿Cómo se organiza el monitoreo de mensajes de error y problemas encontrados por los usuarios?
• ¿Cuál es el proceso de planificación de nuevas características del producto?

¿Por qué regular todo esto, conducirlo a algún tipo de marco, si puede parecer que el trabajo en proyectos irá mucho más rápido sin un flujo de trabajo específico? ¿No es más fácil imaginar todo el "flujo de trabajo" de esta forma: "solo escriba el código y envíelo a la rama maestra"? De hecho, a medida que crece la complejidad del proyecto, resulta que la presencia de reglas claras simplifica la definición de lo que debe hacerse en el trabajo de este proyecto y, en consecuencia, sin pensarlo más, le permite concentrarse en estos asuntos. Cuando se trabaja en un equipo, el flujo de trabajo se convierte en algo así como una cinta transportadora que mejora la eficiencia de cada miembro del equipo.

Ahora hablemos sobre cómo organizar el proceso de trabajo en un producto de software.

▍Utilice rastreadores de tareas

Aquí encontrará útiles los mecanismos de las plataformas en las que coloca el código: GitHub, Gitlab, BitBucket y otros. Las tareas ayudan a realizar un seguimiento de los mensajes de error, las solicitudes para agregar nuevas funcionalidades al producto y organizar la información sobre cambios importantes del proyecto. Debe tenerse en cuenta que cuando ingresa el título y la descripción de la tarea, lo obliga a formular claramente los pensamientos y describir claramente el problema y las posibles formas de resolverlo. La idea de usar tareas puede desarrollarse introduciendo una herramienta de gestión de tareas como Trello o GitHub Projects en su flujo de trabajo.


Desafío

▍Utilice solicitudes de extracción

Muchos desarrolladores prefieren enviar cambios, utilizando solicitudes push, directamente a la rama principal de su proyecto, que se llama maestro. Sin embargo, el enfoque para realizar cambios en el código del proyecto mediante solicitudes de extracción tiene algunas ventajas importantes. En primer lugar, tales solicitudes facilitan el análisis de los cambios relacionados con la introducción de una nueva característica o corrección de errores en el proyecto y cómo, después de fusionarse con la base del código principal, lo afectarán. Además, si las solicitudes de extracción están asociadas con tareas del rastreador de tareas, su uso facilita la comprensión del desarrollo del proyecto, eliminando la necesidad de averiguarlo al leer el código.


Detalles de solicitud de extracción

▍ Realizar revisiones de código personalizado

La recomendación para revisar el código nativo puede sonar extraña, pero a pesar de esto, los desarrolladores deben analizar su propio código como si alguien más lo hubiera escrito. Algunos programadores aconsejan hacer una solicitud de extracción, distraer por un tiempo y luego verificarla antes de incluirla en el código. Realizar comprobaciones de código realizadas fuera del entorno habitual para el programador en forma de IDE le permite echar un vistazo nuevo al código. Esto ayuda a encontrar errores y detectar en el código algo que, en condiciones normales, puede ignorarse. Las revisiones de código, además, obligan al desarrollador a hacerse varias preguntas: “¿Por qué se implementó esta oportunidad de esta manera? ¿Qué podría hacerse mal aquí? ¿Hay alguna forma más eficiente de resolver este problema?

▍ Mantenga un historial significativo del proyecto en el repositorio

Intenta hacer commits como si estuvieras trabajando en un equipo. A saber: evite los compromisos demasiado grandes, trate de asegurarse de que los mensajes de los compromisos describan clara y claramente su significado. Al igual que en el caso de las revisiones de código, escribir mensajes de compromiso de alta calidad obliga al desarrollador a pensar cuidadosamente sobre sus acciones, haciéndose preguntas como las siguientes: “¿Qué estoy tratando de lograr con este compromiso? ¿Cómo estoy tratando de lograr esto?

Puede haber situaciones en las que puede permitirse desviarse de las reglas. Por ejemplo, puede decidir que, para no ralentizar el trabajo debido a problemas, usted, al realizar cambios muy pequeños en el código (como corregir errores tipográficos), puede, sin movimientos innecesarios, enviar una solicitud de inserción directamente a la rama maestra.

Independientemente de las reglas que subyacen a su flujo de trabajo, lo más importante es que todo lo que hace se hace intencionalmente, y no por coincidencia. Los proyectos exitosos no surgen por sí solos: se crean con amor y cuidado. Las acciones realizadas intencionalmente involucran ciertos períodos de análisis de la situación, análisis de casos complejos y reflexión sobre cómo, por ejemplo, con la ayuda de qué herramientas puede manejarlos.

Construir componentes y módulos reutilizables

Implemente los principios de SECO , SÓLIDO y PRIMERO . Cree programas a partir de pequeños componentes atómicos encapsulados adecuados para su reutilización. Mantenga estos componentes actualizados, agrúpelos en colecciones usando plataformas apropiadas como Bit . Todo esto lo ayudará a aumentar la velocidad y la calidad del trabajo.

Escribir documentación

Documentación ... Para muchos, este es un punto doloroso. Mucha gente sabe que los proyectos de software necesitan documentación. Aquellos que escriben buena documentación ya son mucho menos, y aún menos a quienes les gusta hacer esto. Después de que se haya completado la siguiente etapa fascinante de escribir código, la necesidad de documentarlo a menudo se convierte en una tarea de la que solo desea olvidarse. ¿Cómo, en forma de textos simples, expresar todas las complejidades del código del programa?

Y, por cierto, es apropiado hacer una pregunta sobre por qué todo esto es necesario. El hecho es que las personas tienden a cometer errores. Podemos olvidarnos de algo. Tenemos malos dias. O, trabajando en un determinado proyecto, simplemente podemos proceder a trabajar en otra cosa. La documentación le permite capturar conocimiento sobre el código, que, de lo contrario, estará vinculado a una determinada persona. Documentar el código también ayuda a los desarrolladores a ver el código en términos más generales de lo que está disponible al escribirlo, y a comprender más claramente los objetivos de los proyectos.

Las siguientes ideas lo ayudarán a escribir buena documentación.

• Comprenda que su documentación no es algo así como un libro. La documentación no debe constituir un ejemplo de alto arte literario. Nadie la evaluará en términos de su mérito artístico. No intentes explicar todo lo que contiene. Esfuércese por ser claro y comprensible. A veces, solo un par de oraciones son suficientes para describir algo.
• Escribir documentación antes de escribir el código. Documente las interfaces de sus módulos, describa el orden de su trabajo desde el punto de vista de un observador externo. Dicha documentación desempeñará el papel de especificaciones del producto y lo ayudará en el proceso de desarrollo.
• Escribir documentación después de escribir el código. Aquí, nuevamente, vale la pena adherirse a la posición de un "observador externo". ¿Qué es importante en el fragmento de código descrito? ¿Qué necesita saber sobre su uso (o para contribuir a su desarrollo)? Las especificaciones especificadas por la documentación creada antes de escribir el código durante el desarrollo están sujetas a cambios. Por lo tanto, es importante verificar que dicha documentación cumpla con el estado real de las cosas después de que se complete el trabajo.
• Escribir documentación en el proceso de escribir código. Este enfoque de la documentación se aplica principalmente a algo como los comentarios agregados al código durante el desarrollo. Hay muchos materiales sobre este tema, por lo que no entraré en detalles aquí.
• Documentación y "módulos". Todos los principios anteriores se aplican a los módulos. Aquí el concepto de "módulo" se usa en un sentido bastante amplio. Esto puede ser una función, una clase, una nueva oportunidad, un cambio en el comportamiento de un programa, de hecho, un determinado módulo de programa o todo el proyecto. Si documentar tales "módulos" parece un gran desafío, intente dividirlos en partes más pequeñas. O, si le resulta más fácil pensar en categorías más generales, considere escribir documentación para los bloques más grandes del proyecto.

Comuníquese con los clientes y aquellos que participan en el desarrollo de productos junto con usted.

Aquí, lo que llamamos "comunicación" se aplica principalmente a situaciones en las que un pequeño equipo desarrolla un proyecto o lo hace por encargo.

¿Por qué se necesita esto? El hecho es que la transparencia del trabajo lleva a un aumento en la responsabilidad de sus artistas. Cuando sabes que tienes que decirle algo a alguien (un miembro del equipo o un representante del cliente), te ayuda a ser más cuidadoso con lo que estás haciendo. Es por eso que muchas empresas practican la celebración de reuniones cortas en las que los empleados informan sobre su trabajo.

Además, a menudo un miembro del equipo se enfrenta a un problema que es difícil para él, que puede resolverse fácilmente simplemente discutiéndolo con un cliente o con otro miembro del equipo. Ya perdí la cuenta, recordando los casos en que realmente dejé caer mis manos, tratando de entender por qué lo que escribí no funciona. Y la razón de esto fue que otro miembro del equipo realizó cambios en el proyecto que interfirieron con mi código. Para entender esto, fue suficiente para llevar el problema a discusión pública.

Aquí hay algunas pautas para comunicarse con los clientes y con los miembros del equipo programador.

• Si encuentra un problema inesperado, informe al respecto a los miembros del equipo o al representante del cliente.
• Informar periódicamente al cliente sobre el progreso del proyecto. Al mismo tiempo, intente que esta información no esté vinculada únicamente a problemas técnicos.
• Notifique al equipo los cambios del plan.
• Intente organizar un entorno conveniente para la comunicación, que, por ejemplo, permita a cualquier miembro del equipo descubrir rápidamente qué está haciendo otra persona. Puede hacer esto usando una variedad de herramientas, digamos, puede ser WhatsApp, correo electrónico, Slack o cualquier otra cosa que se adapte a su situación.

En general, puede observarse que debe intentar asegurarse de que la interacción entre todas las partes interesadas se organice de manera conveniente y sencilla, de modo que, por así decirlo, el "ciclo de retroalimentación" funcione sin demora. Esto ayuda a organizar un ambiente de trabajo saludable y productivo.

Organizar un sistema de monitoreo.

El monitoreo en el campo del desarrollo de software es un tema muy importante. Las computadoras son propensas a fallas. Durante la implementación del proyecto, se producen errores. Los descuidos de los desarrolladores conducen al hecho de que los programas que parecen haber superado todas las verificaciones posibles y puesto en funcionamiento con éxito caen con excepciones. Es por eso que el desarrollador necesita cuidar el sistema de monitoreo del programa. Esto facilitará la resolución de los problemas que puedan surgir en las diferentes etapas del ciclo de vida del producto. Los datos de monitoreo del programa son una parte del “ciclo de retroalimentación” mencionado anteriormente. El monitoreo le da al programador una conexión con la realidad, con el entorno en el que trabajan sus programas.

Aquí hay algunas sugerencias para monitorear cómo se comportan los programas:

• Guarde registros y resultados de análisis de código automático. Siéntase libre de usar console.log () donde lo necesite. Es mejor depositar demasiada información que muy poca. Sin embargo, trate de encontrar un "punto medio" para que los registros de sus programas no contengan detalles innecesarios sobre su trabajo. Esto facilitará la búsqueda de información importante en los registros.
• Descubra a dónde van los registros de sus aplicaciones y configure los mecanismos que hacen que sea conveniente trabajar con ellos. El papel de los "mecanismos" mencionados anteriormente puede ser cualquier cosa: desde iniciar sesión en el servidor usando SSH y ver los últimos eventos grabados en el registro, hasta algo como usar la pila ELK. Lo más importante es saber dónde están formados los registros de la aplicación mediante console.log () o cualquier otro medio.
• No ignore las excepciones. Aunque cualquier desarrollador debe esforzarse por garantizar que su aplicación sea estable, es decir, podría restaurar la capacidad de trabajo en caso de error, "deshacerse" de excepciones inesperadas, simplemente "bloquearlas" en algún bloque de captura sería incorrecto. Sería mucho mejor registrar información sobre excepciones inesperadas. Por ejemplo, si usa algún tipo de API para cargar algunos datos creados por el usuario (por ejemplo, tweets), debe estar preparado para manejar el error 404. Pero aquellos errores que no procesa, debe iniciar sesión. Estaba en una situación en la que, sin registrar información sobre errores inesperados, simplemente no sabía que había agotado el límite de llamadas a un sistema. Esto llevó al hecho de que el acceso a la API correspondiente a mi programa estaba cerrado.
• Revisa los registros. La verificación de los registros generados por los resultados de las aplicaciones puede organizarse manualmente o utilizando algún medio para su análisis automático. Una vez que, sin preocuparme especialmente por el control de registros, solucioné un pequeño problema en el programa y seguí tranquilamente con mi negocio. Al final resultó que, mi corrección fue inoperante. Desde entonces, he estado atento a verificar los registros de aplicaciones después de que se implementan, lo que me permite verificar la corrección de su trabajo.

El monitoreo de la actividad de la aplicación y el seguimiento de los indicadores de desempeño pueden tomar muchas formas. En su forma más simple, esto puede generar datos sobre el programa utilizando el comando console.log (), guardar esta información en archivos de texto y analizar manualmente dichos archivos. El monitoreo también puede ser un sistema bastante avanzado, que incluye herramientas especializadas como Sentry, Bugsnag y Elastic APM. Lo principal es elegir lo que más le convenga y usarlo constantemente.

Observe el proyecto, saque conclusiones de los resultados de las observaciones y mejórelo.

Miras, pero no observas, y esta es una gran diferencia.
Arthur Conan Doyle, "El escándalo en Bohemia"

Lo que se discutirá en esta sección puede considerarse tanto una recomendación independiente como un enfoque para usar las otras recomendaciones presentadas aquí. El hecho es que no existe una fórmula universal para organizar el trabajo en un producto de software. Diferentes personas participan en el desarrollo de software de diferentes maneras, utilizan diferentes métodos de monitoreo, documentan el código de manera diferente, etc. Es por eso que, independientemente de las reglas de trabajo de los programas que haya elegido, es importante esforzarse siempre por garantizar que se supervise el proyecto, que se saquen conclusiones de los resultados del monitoreo y que, al final, todo esto conduzca a mejoras del programa.

Monitorear un programa implica un análisis crítico de su comportamiento o, por ejemplo, indicadores de su desempeño. Al observar el programa, está creando una conexión entre lo que ve y lo que sabe sobre el sistema, llegando finalmente a conclusiones lógicas sobre lo que está sucediendo. Quien trabaja solo generalmente se ve privado de la capacidad de analizar programas que se utilizan en organizaciones (como pruebas A / B o estudios del público objetivo). Como resultado, tiene que recopilar pistas sobre la vida de su programa de fuentes "informales", como comentarios de usuarios, informes de problemas en rastreadores de tareas y registros de aplicaciones.

Después de completar la siguiente fase de monitoreo del programa, es hora de sacar conclusiones y mejorarlo con base en estos hallazgos. Luego sigue la siguiente etapa de observaciones, seguida de la siguiente iteración del análisis de los datos recopilados y la mejora del programa. Pero trabajar en un programa es más que "observación - análisis - mejora".

Considere un ejemplo condicional. , , . , UTC-. , .

, UTC. , , , 5:30 pm, 5:30 pm UTC. , . , . ? , . .

, , , — , . , , , . «5 » «2 ». , , , .

. , . , , , , , . , , .

Resumen

, , — , . ( ), , , . , , ( , ), , . , , . , , , , .

Estimados lectores! , «-»?