¿Cómo debo introducir un estándar de codificación en mi equipo?

7

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

El gerente anterior nunca se tomaría el tiempo para crear 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 estándares desde que empecé). Debido a esto, los cuatro desarrolladores escribimos el código a nuestra manera: algunos seguimos las convenciones de nomenclatura de Microsoft para .NET, algunos usan la notación húngara, otros usan una mezcla (por ejemplo, mezclando PascalCase y camelCase para nombres de parámetros) , y es completamente aleatorio cuando abre un archivo de código qué estándar seguirá: casi lo único consistente 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 de forma progresiva (aunque técnicamente no soy el desarrollador más importante, el cuarto desarrollador ha estado aquí durante varios años, dos los compañeros de trabajo y el interno me consultan para recibir asesoramiento / orientación, pero no tenemos un líder de equipo). He querido hacer esto por un tiempo, pero el gerente que ahora se va 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 el apuro apresurado que tenemos actualmente.

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

Para resumir: Más allá de las convenciones básicas de nomenclatura, ¿qué debo incluir en el documento de estándares de codificación (en caso de que sea algo? (los ejemplos serían excelentes: no he podido encontrar ningún ejemplo concreto de cómo debería ser ese documento)) ¿Cómo debo presentarlo a mi equipo sin sonar como el nuevo dictador?

    
pregunta Wayne Molina 19.12.2011 - 21:31

8 respuestas

10
  

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

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 para avanzar

  

Parece que ya has comprado algo de parte de la mayoría del equipo. Haga que la creación del documento sea algo que hagan ustedes (los cuatro si es posible). Si esto consume demasiado tiempo, prepare su documento y muéstrelo como borrador a sus colegas. Una vez que todos hayan acordado y finalizado una versión, están listos para comenzar.

Un buen lugar para comenzar es mirar las diferentes reglas de stylecop : no tiene que cumplirlas. todos, pero estos le darán una idea de lo que debe contener su documento. Como un bono adicional, puede implementar fácilmente stylecop en sus soluciones e incluso integrarse en una compilación automatizada (fallando la compilación si hay violaciones).

Para resumir:

Observe las herramientas y estándares existentes para decidir lo que desea en el suyo.

Para evitar parecer un dictador, haga que el cambio sea de colaboración.

    
respondido por el Oded 19.12.2011 - 21:38
6
  

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

Nada.

Tómate tu tiempo. Ve lento. No pierdas el tiempo escribiendo. Las convenciones de codificación solo funcionan cuando forman parte de la cultura común.

Si no forman parte de la cultura, simplemente se ignoran.

  

¿Cómo debo hacer para 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 las 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 del código, puede descubrir algo mejor y cambiar realmente sus preferencias personales.

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

  

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

Mala política.

Un estándar arquitectónico es nunca algo con una adherencia del 100%. No puede ser Siempre es una descripción "progresista", 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 ni cerca del punto de idear una estrategia de refactorización.

Bien. No desarrolles uno. Con esto quiero decir "no reprimir la innovación al escribir demasiadas cosas que pueden o no ser el mejor enfoque posible".

    
respondido por el S.Lott 19.12.2011 - 23:59
4

Con algo parecido a las convenciones de codificación, diría que cualquier convención específica debe ser 100% unánime o encontrar un punto intermedio que lo haga 100% unánime.

  • Establezca una fecha límite para completar el documento, esto obligará a otros a tomárselo en serio.

  • Haga el trabajo de compilar el documento, nadie tendrá ganas de ayudarlo, pero si usted es el propietario del trabajo, entonces nadie se opondrá a él por él.

  • 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 en la que se puedan votar.

  • Nadie abandona la reunión hasta que cada convención llegue a un acuerdo 100% unánime

  • Las personas nuevas en el equipo deberán cumplir con el documento y no tendrán voz. Es como la Constitución en ese punto.

Oh y no hay notación húngara. En serio, preferiría quitarme los ojos en lugar de tener que mirar el código en notación húngara.

    
respondido por el maple_shaft 19.12.2011 - 21:45
1

Los estándares de codificación serán un desafío para ser aceptado. A algunas personas les gusta codificar en su caja de arena y simplemente hacer 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. Puedes usar los conjuntos de reglas predefinidos o escribir los tuyos. Luego, haga que todos estén de acuerdo antes de las revisiones de código (si las tiene) de que debe cumplir con la configuración.

    
respondido por el PSU_Kardi 19.12.2011 - 22:08
1

Desde un punto de vista técnico:

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

Desde un punto de vista relacional:

Si quieres involucrar al senior, inspírate en sus propias convenciones de codificación.

    
respondido por el mouviciel 20.12.2011 - 11:57
0

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

    
respondido por el Doc Brown 19.12.2011 - 21:45
0

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

Si es así, simplemente crea una página. Llámalo un documento vivo. Ponga algunos estándares no contenciosos y anime a todos los demás a colaborar. Continúe agregando artículos cada pocas semanas, aliente la discusión, pero de una manera que diga "si nadie está en desacuerdo, debemos esperar que esto se cumpla". Si puede, convenza a todos para que se suscriban a los documentos de estándares, de modo que pueda ver los cambios que hagan 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 la aplicación de estándares, y hará que todos sean iguales, no un desarrollador que dicte las reglas.

Editar en respuesta al comentario:

Puedes vender revisiones de código como una forma para que Dev # 4 difunda su sabiduría. Incluso cuando su código está siendo revisado, es una oportunidad para que la gente vea su código mágico y se sorprenda con eso. Realmente, es una forma de promover la discusión. Cuando el programador y el revisor no puedan ponerse de acuerdo, debe ir al equipo. Cuando el equipo no esté de acuerdo, se debe realizar una investigación.

Hablando de investigación, haga algunas revisiones de código. Nadie cuya opinión cuente mucho piensa que es una mala idea. Envíelo 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 no está realmente allí). Pero si no puede, un documento de Word en una unidad compartida hará el trabajo.

    
respondido por el pdr 19.12.2011 - 21:47
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 estilo malo. Sin embargo, una función VIM simple se convierte entre los dos según sea necesario.

También, piensa en los niveles de comprensión de 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 prefieren 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 salir. Lo mismo con el espacio en blanco. Necesita averiguar con qué nivel de compresión de código todos se sienten cómodos.

Finalmente, ¿cómo se recortan los proyectos nuevos y los proyectos actuales? Una clase por archivo, las funciones de utilidad siguen un esquema de nomenclatura, no hay variables globales ni fugas en el alcance, los archivos de proyectos aleatorios son ortogonales y débilmente acoplados, 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 todos los proyectos están tan interrelacionados que tengo que pasar por toda la base de código y realmente asimilar el proyecto antes de que yo haga 20% de foo() .

    
respondido por el Spencer Rathbun 19.12.2011 - 22:30

Lea otras preguntas en las etiquetas