¿Cómo debo presentar un estándar de codificación a mi equipo?

8

Primero un poco de historia: mi actual gerente de desarrollo está aprovechando otra oportunidad al final de esta semana, dejando a nuestro equipo con cuatro desarrolladores a tiempo completo, un pasante a tiempo parcial y un diseñador web (que técnicamente es parte de Marketing, no AppDev). En este momento no estamos promocionando o contratando un nuevo gerente.

El gerente anterior nunca se tomaría el tiempo para idear un conjunto de estándares de codificación que cumplir (para poner esto en perspectiva: mi primer aniversario en este trabajo es en dos semanas y he estado hablando con él sobre los estándares desde Yo empecé). Debido a esto, todos los cuatro desarrolladores escribimos código a nuestra manera: algunos de nosotros seguimos las convenciones de nomenclatura de Microsoft para .NET, algunos usan notación húngara, algunos usan una mezcla (por ejemplo, mezcla PascalCasey camelCasepara nombres de parámetros), y es completamente aleatorio cuando abre un archivo de código según el estándar que seguirá; lo único coherente es que las llaves están en líneas separadas.

Dos de mis tres compañeros de trabajo se han acercado a mí para crear un documento de codificación estándar que podamos usar y aplicar en el futuro (aunque técnicamente no soy el desarrollador más veterano, el cuarto desarrollador ha estado aquí durante varios años, dos compañeros de trabajo y el interno busca consejo / guía pero no tenemos un líder de equipo). He tenido la intención de hacer esto por un tiempo, pero el gerente que ahora se marcha siempre lo pondría en un segundo plano; Su partida ahora nos da la oportunidad de tomarnos un tiempo y configurar las cosas correctamente para facilitar un entorno de software adecuado y no la mezcolanza apresurada que tenemos actualmente.

¿Cómo debo hacer esto y presentar este estándar a mi equipo sin causar fricción? No quiero que parezca que estoy "asumiendo el control", aunque si me ofrecieran el puesto de gerente lo aceptaría. Como dije, dos de los otros tres desarrolladores están a bordo conmigo creando uno, pero el cuarto (el verdadero "senior" en tiempo) puede o no aceptarlo. Planeo comenzar con las convenciones .Net de Microsoft (por ejemplo, no use la notación húngara), agregue algunas preferencias personales (por ejemplo, _camelcasepara los campos) y mencione específicamente ciertas prácticas extrañas que usamos aquí para no usarlas (por ejemplo, nombrar una clase con un guión bajo al comienzo), pero ¿qué más debo incluir? No quiero entrar en pautas arquitectónicas ya que eso causamos fricción y tenemos una base de código existente muy grande y maloliente que no se adhiere a ella, y no estamos cerca de llegar a una estrategia de refactorización.

Para resumir: más allá de las convenciones de nomenclatura básicas, ¿qué debo incluir en un documento de estándares de codificación? (Los ejemplos serían geniales; no he logrado encontrar ejemplos concretos de cómo debería ser ese documento) y cómo debo hacerlo. presentarlo a mi equipo sin sonar como el nuevo dictador.

.net coding-standards teamwork

— Wayne Molina
fuente

Además de las convenciones de nomenclatura, querrá una forma estándar de describir lo que hace el archivo en los encabezados, más posiblemente una estructura de directorios estandarizada. Consulte la guía de estilo de Google como ejemplo.

— chrisaycock

¡No tiene gerente / líder de equipo y está preocupado por los estándares de codificación!

— mattnz

Puede que no necesitemos un líder de equipo para ser honesto, la mayoría de nosotros estamos de acuerdo en las cosas y colaboramos por nuestra cuenta. Los estándares son una preocupación porque ha sido "hablemos de ellos" durante casi un año y ahora se ha asignado cero tiempo para sentarse a discutir algunos.

— Wayne Molina

2

El hecho de que no se haya sentado para una reunión de 30 minutos en casi un año me indica que realmente necesita un líder de equipo.

— mattnz

Quizás. El gerente anterior tenía prisa por descifrar el código, no por "perder el tiempo" con cosas como hablar sobre estándares o tratar de implementar CI, pruebas, revisiones de códigos o cosas similares. La única vez que tratamos de resolverlo, el desarrollador principal se puso nervioso porque la reunión estaba tomando demasiado tiempo ("¡Tengo trabajo que hacer!", Fue la cita exacta) y salió furioso, terminando abruptamente.

— Wayne Molina

10

¿Cómo debo hacer esto y presentar este estándar a mi equipo sin causar fricción?

Tu también dices:

Dos de mis tres compañeros de trabajo se han acercado a mí para crear un documento de codificación estándar que podamos usar y aplicar en el futuro.

Parece que ya tienes algo de aceptación de la mayoría del equipo. Haga que la creación del documento sea realizada por todos ustedes (los cuatro si es posible). Si esto lleva demasiado tiempo, presente su documento y muéstrelo como borrador a sus colegas. Una vez que todos hayan acordado y finalizado una versión, estarán listos.

Un buen lugar para comenzar es echar un vistazo a las diferentes reglas de stylecop : no tiene que cumplir con todas ellas, pero le darán una idea de lo que debe contener su documento. Como beneficio adicional, puede implementar fácilmente stylecop en sus soluciones e incluso integrarse en una compilación automatizada (si falla la compilación si hay infracciones).

Para resumir:

Mire las herramientas y estándares existentes para decidir qué quiere en los suyos.

Para evitar parecer un dictador, haga que el cambio sea colaborativo.

— Oded
fuente

"Para evitar parecer un dictador, haga que el cambio sea colaborativo". Tan verdadero. Aquí tiene tres rutas para el éxito: 1. use un estándar externo, de esa manera todos tienen algo que les gusta y algo que no les gusta (fxcop, stylecop o incluso cualquier .pdf que pueda encontrar en la web). 2. Generación colaborativa. 3. Eres un héroe legendario con años de experiencia y las personas acuden en masa a trabajar contigo y son amados por todos, o tal vez tu apellido es Zuckerberg, Page o Brin.

— anon

6

Más allá de las convenciones básicas de nomenclatura, ¿qué debo incluir en un documento de estándares de codificación?

Nada.

Tome su tiempo. Ve lento. No pierdas el tiempo escribiendo. Las convenciones de codificación solo funcionan cuando son parte de la cultura común.

Si no son parte de la cultura, simplemente son ignorados.

¿Cómo debo hacer esto y presentar este estándar a mi equipo?

Revisiones de código. Es un gran lugar para presentar el problema que se resuelve mediante convenciones de codificación.

La mayoría de las veces, las convenciones son simplemente una pérdida de tiempo. Cuando tiene un problema real (es decir, programas ilegibles) que puede resolver mediante convenciones de codificación, puede llegar al 100% de cumplimiento rápidamente.

Las convenciones de codificación que son meramente preferencias personales no resuelven un problema. Y, de hecho, durante una revisión de código, puede descubrir algo mejor y cambiar su preferencia personal.

No canonice demasiado en un documento de convenciones de codificación. Trabajar cooperativamente para llegar a un entendimiento común.

No quiero entrar en pautas arquitectónicas ya que eso causará fricción y tenemos una base de código existente muy grande y maloliente que no se adheriría a ella,

Mala política

Un estándar arquitectónico nunca es algo con 100% de adherencia. No puede ser Siempre es una descripción "prospectiva", hacia la cual evoluciona el desarrollo.

Toda buena idea arquitectónica conducirá a una nueva dirección arquitectónica. Y así es como se ve la innovación: un camino, no un objetivo.

y no estamos cerca de llegar a una estrategia de refactorización.

Bueno. No desarrolles uno. Con eso quiero decir "no reprimir la innovación escribiendo demasiadas cosas que pueden o no ser el mejor enfoque posible".

— S.Lott
fuente

4

Con algo así como convenciones de codificación, diría que cualquier convención específica debería ser 100% unánime o encontrar algún término medio que la haga 100% unánime.

Establezca una fecha límite para completar el documento, esto obligará a otros a tomarlo en serio.
Haga el trabajo de compilar el documento, nadie tendrá ganas de ayudarlo, pero si usted es el propietario del trabajo, nadie lo peleará.
Envíe propuestas para varias convenciones de codificación basadas en diferentes estilos que existen en la base de código ahora. Recopile comentarios y establezca una reunión donde puedan ser votados.
Nadie abandona la reunión hasta que cada convención haya llegado a un acuerdo 100% unánime.
Las nuevas personas en el equipo deberán cumplir con el documento y no tendrán voz. Es como la Constitución en ese momento.

Ah, y no hay notación húngara. En serio, prefiero cortarme los ojos en papel que mirar el código en notación húngara.

— árbol de arce
fuente

1

El húngaro es una gran cosa, y también lo son los nombres de clase de subrayado. Ver algo así _Customer oCust = new _Customer();me hace sacudir la cabeza con desconcierto.

— Wayne Molina

Asumí la tarea de compilar un nuevo conjunto de estándares de codificación para mi empresa. Afortunadamente, conté con la ayuda de un grupo de Desarrolladores Senior que también eran nuevos en la empresa y tuvimos un vicepresidente que nos respalda con la aplicación. Actualizamos el documento cada pocos meses según sea necesario. Después de la segunda gran revisión, agregué numeración de sección al documento, lo que facilitó la referencia a un estándar particular cuando un proyecto falló en la revisión del código. "Consulte la sección 5.3.4.6 sobre el uso de la función A en lugar de la función B". Durante el último año, finalmente recibimos menos revisiones de códigos fallidos.

— Adrian J. Moreno

1

Los estándares de codificación serán un desafío para ser aceptados. A algunas personas les gusta codificar en su caja de arena y simplemente hacen lo suyo a pesar de que puede causar problemas si se rompe y otras intentan solucionarlo.

Si está utilizando Visual Studio con .NET, eche un vistazo a StyleCop. Puede usar los conjuntos de reglas predefinidos o escribir los suyos propios. Luego, haga que todos estén de acuerdo antes de revisar el código (si los tiene) de que debe cumplir con la configuración.

— ist_lion
fuente

1

Desde un punto de vista técnico:

Señale las inconsistencias que son realmente un problema para el equipo y defina reglas de codificación para resolver estos problemas.

Desde un punto de vista relacional:

Si desea involucrar al senior, inspírese con sus propias convenciones de codificación.

— Mouviciel
fuente

Bueno, parte de la razón por la que queremos estándares de codificación es porque la persona mayor no sigue ninguno. Utiliza la notación húngara en todas partes, no sabe que los métodos se pueden sobrecargar (por lo que habrá un GetFoométodo, y luego un GetFoo_WithSomethingElsemétodo que tenga lo mismo pero con un parámetro adicional, con toda la lógica copiada y luego el extra bits añadidos) y no entiende el diseño de la clase más que simplemente llenar mucha lógica en un archivo de código subyacente. Al gerente que se fue no le importaba hacer cosas diferentes, así que seguí ese estilo.

— Wayne Molina

Esto es lo que yo pensaba. Parece que su proyecto tiene problemas no técnicos y que intenta resolverlos con una respuesta técnica.

— mouviciel

¿Cuál sería la forma correcta de resolver los problemas entonces? El problema es que nadie ha pensado en estas cosas desde la creación de la compañía.

— Wayne Molina

Puedo estar equivocado, pero el problema que veo es que un desarrollador senior que había escrito código durante muchos años no tiene motivos para cambiar, en particular si la solicitud proviene de un junior (no cuestiono su competencia). No veo una solución general, ya que no sé lo suficiente sobre la situación.

— mouviciel

0

Mientras no sea el nuevo gerente de su equipo, necesita consenso para tener un estándar de codificación (y si fuera el gerente, realmente debería esforzarse por lograr el consenso en el equipo antes de tomar tal decisión "desde arriba" "). Y puede sonar simple, pero solo hablar, especialmente hablar con el cuarto desarrollador, puede resolver esto.

— Doc Brown
fuente

0

¿Tienes una empresa Wiki? ¿O, en su defecto, un servidor en el que puede colocar uno?

Si es así, simplemente cree una página. Llámalo un documento vivo. Ponga algunas normas no contenciosas y aliente a todos los demás a colaborar. Siga agregando elementos cada pocas semanas, fomente la discusión, pero de una manera que diga "si nadie está en desacuerdo, entonces deberíamos esperar que esto se siga". Si puede, convenza a todos de que se suscriban a los documentos estándar, para que pueda ver los cambios que hacen sus colegas.

También intente que el equipo comience las revisiones de código. Cada trabajo pasa por dos desarrolladores. Esto fomentará la discusión y el cumplimiento de las normas, y hará que todos sean iguales, no un desarrollador dicte las reglas.

Editar en respuesta al comentario:

Puedes vender revisiones de códigos como una forma para que Dev # 4 difunda su sabiduría. Incluso cuando se está revisando su código, es una oportunidad para que la gente vea su código mágico y se sorprenda. Realmente, es una forma de promover la discusión. Cuando el codificador y el revisor no pueden estar de acuerdo, debe ir al equipo. Donde el equipo no puede estar de acuerdo, se debe hacer una investigación.

Hablando de investigación, haga algunas revisiones de código. Nadie cuya opinión cuenta mucho piensa que es una mala idea. Póngalo al equipo, incluido el CIO, en un correo electrónico con muchos enlaces. Es difícil discutir contra ellos sin parecer un idiota obstructivo.

Aquí hay algunos para comenzar:

En cuanto a un Wiki, realmente recomendaría tomarse el tiempo para configurar uno (los wikis dan la ilusión de colaboración, incluso cuando realmente no está allí). Pero si no puede, un documento de Word en una unidad compartida hará el trabajo.

— pdr
fuente

No tenemos uno es algo que (cada vez que digo "nosotros" me refiero a mí mismo y a los dos desarrolladores que me difieren - el cuarto es esencialmente un "operativo especial" y maneja las partes heredadas / complejas de la aplicación que el resto de nosotros no toca) - incluso antes de que el gerente se fuera Dev # 4 informó directamente al CIO, no al gerente) estaban hablando. Revisiones de códigos No estoy seguro si podemos hacerlo, ya que algunos podrían ofenderse si se cuestiona su código (lo más probable es que Dev # 4 tenga que cambiar la forma en que hace las cosas para adherirse a los nuevos estándares de todos modos)

— Wayne Molina

@WayneM Donde trabajo, tampoco teníamos un wiki. Fue fácil configurar un dokuwiki vm para comenzar. Puede ejecutarlo desde su caja personal si es necesario, y una vez que las cosas se ponen en marcha, es bastante fácil migrar a un servidor "real".

— Spencer Rathbun

1

@WayneM: Ver edición.

— pdr

0

Los estándares de comentarios y espacios en blanco son buenos, junto con herramientas para migrar entre diferentes estilos. Utilizo pestañas en mi código de Python, que se considera un mal estilo. Sin embargo, una simple función VIM convierte entre los dos según sea necesario.

Además, piense en los niveles de comprensión del código. El propósito de un estilo es comunicar información al programador que lee el código. Si puede entender reduce(lambda x, y: x+y, map(lambda x: x + 1, theList)), pero sus compañeros de trabajo preferirían ver:

for pos,item in enumerate(theList):
    theList[pos] = item + 1
tmp = 0
for item in theList:
    tmp = tmp + item

Entonces esto es importante para resolver. Lo mismo con el espacio en blanco. Debe averiguar con qué nivel de compresión de código todos se sienten cómodos.

Finalmente, ¿cómo se cortan los nuevos proyectos y los proyectos actuales? Una clase por archivo, las funciones de utilidad siguen un esquema de nomenclatura, no hay variables globales o pérdida de alcance, los archivos de proyecto aleatorios son ortogonales y están acoplados libremente, y así sucesivamente. Esto proporciona una base de comprensión importante para todos. No importa cuál sea el estándar de codificación, si cada proyecto está tan entrelazado que tengo que pasar por toda la base de código y realmente asimilar el proyecto antes de dar un giro foo().

— Spencer Rathbun
fuente