Lo que quiero decir con eso es, ¿cómo se desarrolla en una base de código que comparte con los desarrolladores que han estado trabajando en él durante años y están muy familiarizados con él?
No quiero pisar los pies de nadie, pero no tengo quejas tan sutiles sobre la forma en que hago las cosas, ya sea cómo espacio en blanco mi código o con qué frecuencia me registro en SVN (con demasiada frecuencia). Entonces, aunque puedo cambiar esas cosas fácilmente, quiero ser un mejor desarrollador de equipo en general.
No estoy seguro de qué hacer, aparte de preguntar, pero tal vez ustedes tengan algunas ideas que podría poner en práctica.
ACTUALIZAR
No hay ninguna guía de estilo para hablar, es solo que las personas no están acostumbradas a compartir la base de código. Todos tienen su propio mundo de código en silo.
Esta es una tienda de Perl, pero estoy seguro de que esto se aplica a cualquier idioma
ACTUALIZACIÓN 2
El CTO que luego se convirtió en CEO fue un completo megalómano y fue la principal fuente de estas quejas. Si no hiciste las cosas exactamente como a él le gustaba, ya fuera usando una Mac o Emacs, o 4 espacios de tabulación en lugar de 2, o vestirte de cierta manera, eras inferior. Intenté corregir una situación horrible, pero la única respuesta correcta para mí fue irme.
Estoy convencido de que este fue un caso de intimidación en un lugar de trabajo y, posteriormente, soy más consciente de lo que podría ser una intimidación sutil y un comportamiento inapropiado en un entorno laboral.
Para cualquier desarrollador que busque respuestas a una situación como esta, retírese de inmediato. No puedes trabajar en equipo para salir de una mala situación de equipo.
Respuestas:
Pedir. Es decir, pregúntale a la gente con la que trabajas. Haz tu mejor esfuerzo para seguir el estilo establecido del código existente. Pregunte especialmente si hay una lista de documentos de estándares de codificación y sígala. Si no hay ninguno, escriba un primer borrador basado en lo que observa en el código y luego pida a los otros miembros del equipo que lo critiquen. Hará un servicio a la empresa (y a los nuevos desarrolladores que vienen después de usted) al comenzar a documentar las prácticas de codificación aceptadas. El único riesgo es posiblemente quedar atrapado en el medio si resulta que los veteranos no están de acuerdo entre sí en lo que es o no aceptable.
Además, no tengas miedo de ser tú mismo . Puede que seas el chico nuevo, pero eres miembro del equipo y tus opiniones son válidas. Si puede pensar en mejores formas de hacer algo, sugiéralo. Respeta a los otros miembros del equipo y la forma establecida de hacer las cosas, pero no dejes que te presionen. La compañía no lo habría contratado si no valorara su opinión.
Ayudará mucho si puede encontrar a alguien en el equipo que parezca amigable y particularmente dispuesto a responder preguntas. (Si se trata de un buen equipo, deberían ser todos, pero los equipos no siempre son así). Su jefe puede haber asignado a alguien para que lo ayude a comenzar. Usa a esa persona como un recurso. Escriba las preguntas que se le ocurran y luego pídale a esa persona útil que las responda de vez en cuando.
En cuanto a registrar el código "con demasiada frecuencia", ¿por qué no crear su propia rama para sus confirmaciones periódicas y luego volver a fusionarse con el tronco cuando su código esté listo? Al hacer eso, no hay daño para nadie más, y cuando tus compañeros de trabajo vean que obtienes los beneficios de SVN que les gustaría, podrían seguir tu ejemplo.
fuente
Con respecto a los espacios en blanco: solo hazlo sin embargo, el código ya lo hace. Ir con el flujo.
Con respecto a los registros de SVN: documentarlos muy claramente. Eso ayuda a las personas a comprender lo que está sucediendo en el código. (Seguimiento: ¿Cuáles son sus objeciones a los registros frecuentes?)
En general: comience a construir un documento estándar de codificación. No intentes llenarlo con 100 reglas. Simplemente agregue reglas a medida que surjan.
Además: haga preguntas a sus compañeros desarrolladores. Eso les da la oportunidad de evaluar antes de hacer algo que no les gustará. Además, construye relaciones. Además, aprende más sobre cómo funciona la tienda.
fuente
En cuanto al estilo de formato de código (espacios en blanco, tabulaciones, dónde van los corchetes, etc.), debe seguir el estándar vigente en el código. Si no hay uno, no creo que tengan mucho de qué quejarse. Cuando se trata de eso, si coloca llaves en su propia línea o no, coloca espacios alrededor de las listas de parámetros de métodos, etc., es una preferencia personal, y debe ceder al estilo predominante porque a la larga, realmente no lo hace. importa . Lo que importa es ser consistente.
Cuando se trata de registrar el código en SVN, trataría de evangelizar lo que siento es la forma correcta de hacer las cosas, en lugar de dejarme arrollar. No registro mi código a menos que genere y pase pruebas, y si estoy haciendo varios cambios no relacionados, divido mi trabajo en varias confirmaciones. Si algo se rompe por un tiempo, creo una rama y hago mi trabajo allí. Los commits reciben comentarios descriptivos. Esto funciona mejor en mi experiencia que el método de "registrar un montón de cambios el viernes a las 5:00", y parece ser la "mejor práctica" predominante de acuerdo con la mayoría de lo que he leído aquí y en otros lugares.
fuente
Primero lea su documento de convenciones de codificación (si no tienen uno, pídales que escriban uno para que pueda seguirlo)
Luego tome nota y haga un esfuerzo consciente para seguir eso y lo que dicen. Puede parecerle que están siendo duros, pero los estándares de codificación son importantes, es mejor señalar ahora qué está mal en lugar de dejar que se convierta en un problema más adelante cuando realice cambios más grandes.
Estoy seguro de que harás lo mismo en un año o dos cuando algún novato te pise los pies :)
fuente
Pregunte por los estándares del código de la compañía. Presta más atención a los detalles. Si ve que otros siguen una forma muy específica de espacios en blanco y patrones de llaves, entonces sígalos. Como padre, podría argumentar que esto es quisquilloso, pero como hijo o nuevo en un proyecto, debe demostrar que puede seguir antes de poder liderar.
Además, comprenda que cualquier desarrollador nuevo en un proyecto tendrá un tiempo necesario de "aceleración". Así que no te preocupes por eso.
fuente
Lo mejor que puedes hacer es seguir los consejos que te dan. No hay forma de decir con anticipación lo que quieren. A menos que seas psíquico.
Sin embargo, sugeriría que a medida que la gente le da consejos, lo documente. ¿Tienes una wiki? Si es así, úsalo. Si no, un archivo de texto registrado con el código fuente podría ser una buena idea. Crea una guía de programación bien organizada. Te ayudará a recordar cómo hacer las cosas, y si alguien contradice los consejos anteriores que te han dado, te da un punto de referencia para discutir la inconsistencia. Además, cuando la próxima persona se una al equipo, no tendrá que pasar por lo que tú estás pasando.
Te sugiero que no atribuyas el consejo en el documento a individuos (por lo tanto, "los bloques de código deben estar sangrados por tres espacios", no "Bill me dijo que los bloques de código deberían estar sangrados por tres espacios"). Sin embargo, si puede registrar esa información de manera discreta (por ejemplo, en el comentario de confirmación, escriba "regla agregada sobre sangría basada en el consejo de Bill"), entonces podría ser útil para resolver contradicciones, ya que puede obtener dos puntos de vista de inmediato sobre algo. Lo que estoy pensando aquí, en realidad, es que si te dan consejos contradictorios, debes evitar convertirte en un jugador de fútbol pateado por dos colegas que no están de acuerdo en algo. Es un enfoque un poco encubierto, pero puede ser prudente.
fuente
Una fácil es encontrar la guía de estilo y seguirla. La mayoría no tiene nada demasiado ofensivo en ellos, y evitará que ofendas a otros.
fuente