Hola habrahabr! En este artículo, compartiré mi opinión sobre el desarrollo de software. He estado en tecnología de la información no hace mucho tiempo, pero he desarrollado una fuerte actitud hacia el desarrollo, desde los nombres de los compromisos hasta la aclaración de los requisitos para la tarea.
Desarrollo
Cambios homogéneos
Imagine que tiene una tarea en la que primero necesita desarrollar una solución optimizada, y luego usarla en lugar de la anterior en una docena de archivos en el proyecto. Primero, obtenga la evaluación de que su enfoque para resolver el problema es correcto y luego refactorice. Decida hacer todo de una vez: puede obtener comentarios críticos y correcciones a la solución en la revisión del código. Luego tendrá que reescribir todos los archivos en los que aplicó el nuevo código.
Implementación de tareas
No resuelva el problema con un sable, no tome decisiones importantes a toda prisa, incluso si parece que su enfoque es correcto. Siga estas pautas:
- Realice un análisis de las implementaciones existentes en el proyecto o en la red, actualice los principios y los patrones de diseño en su memoria.
- No gaste más de 20 minutos resolviendo problemas típicos o demasiado complejos; esto no es efectivo. Lo más probable es que si no encuentra el enfoque correcto rápidamente, la solución no es obvia.
- Solicite ayuda de colegas, incluidos los desarrolladores principales.
- Resuelva el problema como parte de las subtareas paso a paso, no salte: "Haré lo difícil más tarde". Bien puede resultar que no hay soluciones correctas, y las existentes no son adecuadas y la tarea necesita ser revisada.
- Resuelva el problema comenzando con las cosas fundamentales, asegúrese de que las áreas conceptuales funcionen. Puede resultar que individualmente su funcionalidad sea viable, y conectarla juntos requerirá "muletas" u otro enfoque integrado, lo que tomará más tiempo.
Solicitudes de extracción
Titulo
El título debe describir la tesis de los cambios: ser conciso y conciso. Siga las reglas de diseño del encabezado:
- comenzar con una letra mayúscula
- sin un punto al final
- tener un estado de ánimo imperativo.
Ticket-295: Add base cat interface and British cat realization
Descripción
Esta sección de la solicitud de extracción debe escribirse correctamente en un idioma que sea comprensible para un especialista no técnico, dividido por la carga semántica, y revelar los cambios de la siguiente manera:
- el resultado en varias oraciones,
- que precedió a los cambios
- por qué y por qué tenían que hacerse,
- que hiciste exactamente
- ¿Cómo implementaste esto?
The base cats interface was created to provide the common cats functionality and attributes. Also the realization of the British cats was created as the individual one. Our business-analytics have provided for product owner that they want to interact with cats on out platform too, not only with docs. So developers got the tasks to design and implement basic implementation of the cats interface to describe the common patterns of the interaction with it by user. Also the goal was to create one demo cat called British cats (British Shorthair) with its great noses.
Ayuda
Finalmente, deje enlaces a los temas cubiertos en la solicitud de extracción. Si otro desarrollador necesita comprender mejor los cambios, podrá mirar allí. También algunas reglas:
- Describa brevemente hacia dónde se dirige la ayuda
- si es posible, arroje enlaces completos,
- si no, acortar con git.io y bit.ly ,
- hacer una lista
References: • British cats — https://en.wikipedia.org/wiki/British_Shorthair • Cats anatomy — https://en.wikipedia.org/wiki/Cat_anatomy
Se compromete
Compromiso de fusión
Cuando trabaja en nuevos cambios, lo hace en una rama de trabajo separada. Los commits en una rama de trabajo están documentando cambios de una línea.
$ git log --oneline 4336d35 Create cats interface 7bc2ba9 Implement Persian cat realization 5f330fd Add Persian cat documentation ...
Cuando llega el momento de realizar estos cambios en la rama predeterminada, esto se hace en una gran confirmación con un encabezado y una descripción completa de lo que se hizo y por qué. La buena práctica de combinar cambios es utilizar la interfaz web de los sistemas de almacenamiento de código fuente como
Github y
Gitlab .
$ git log --oneline d2ccf1a Ticket-299: Prevent cats graph be stopped unexpectedly (
Como resultado, la rama predeterminada se llena con confirmaciones con una descripción detallada de los cambios.
Ticket-299: Prevent cats graph be stopped unexpectedly There was a situation when cats graph is stopped unexpectedly without any verbose information and traceback. The socket connection between two web-servers (back-end and front-end) was successfully debugged and founded the socket library async latent behavior. Implemented: — Create handler for async socket connection as sync. The consumer doesnt specify a condition for ending the while loop and stream, so the application checker in Daphne cleans up the task if the protocol disconnects and the app doesnt handle it. So `channel_layer` is wrapped to `async_to_sync`. — Fix low latency between pushing the cats graph data and its output on the user interface. There was a high coupling between interface class that proxy via a few client to the realization. The separated cats graph message class was created. References: • Socket channel layers — https://channels.docs.io/channel_layers.html • Daphne handle_reply() — https://git.io/fgVzK Issue:
Siga estas pautas cuando realice confirmaciones de fusión:
- todos los cambios en una confirmación;
- el título y los bloques de texto con diferente carga semántica están separados por una línea vacía;
- Describa los cambios: por qué fueron necesarios, qué problema resuelven;
- describa cada cambio en detalle como una lista: entre en los detalles y consecuencias,
- haz obvia tu decisión;
- Deje enlaces a ayuda, documentación, foros, discusión de problemas;
- consulte temas o solicitudes de extracción si sus cambios se relacionan con ellos;
- limite la longitud de las líneas en el mensaje a 72 caracteres.
Habilidades blandas
Comunicación escrita
Todos los días, los desarrolladores realizan comunicaciones escritas sobre temas técnicos, proyectos, enfoques para resolver problemas, pero no siempre lo hacen bien. La persona con la que se está comunicando no lee sus pensamientos, no piensa de la misma manera que usted y no recuerda los detalles del tema de la propuesta que está llevando a cabo. ¿Cómo se puede mejorar este proceso?
- Siga las reglas de ortografía y puntuación para delimitar el texto en significado.
- Use saltos de línea y deje líneas en blanco entre bloques de texto no relacionados.
- Use listas para resaltar una secuencia o etiquetar oraciones.
- Use servicios para compartir parte del código o use herramientas corporativas: Pastebin , Github Gist , Codeshare o, por ejemplo, el Slack messenger tiene una función en el chat de código o fragmento de texto .
- Resalte sus propios nombres, palabras importantes y detalles con la ayuda del marcado incorporado en su messenger. Ahora cualquier mensajero moderno admite la selección de texto por el tipo de este.
- Apoye su discusión con enlaces a documentación, artículos o publicaciones en foros.
- No escriba ni muestre información innecesaria al interlocutor. Por ejemplo, no complete la captura de pantalla que acaba de tomar con el nombre en el formato de fecha Captura de pantalla 2018-06-23 a las 12.17.31 AM si la otra persona ve esta inscripción. Eche un vistazo más de cerca al tema de discusión Traceback durante el proceso de registro del usuario.jpg .
Responsabilidad
Crece como profesional no solo cuando adquiere nueva experiencia y conocimiento, sino también si:
- al resolver problemas, consulte con expertos;
- su trabajo se puede hacer mejor: mejorar;
- puedes hacer un mejor trabajo como colega; cuéntale al respecto;
- no sabes algo, reconócelo y pide ayuda;
- Mejore los procesos, traiga cosas nuevas y no ignore los problemas.
Gracias por tomarse el tiempo de publicar. Deje comentarios en mensajes privados o comentarios, estaremos encantados de discutir.