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 PascalCase
y camelCase
para 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, _camelcase
para 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.
fuente
Respuestas:
Tu también dices:
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.
fuente
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.
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.
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.
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".
fuente
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.
fuente
_Customer oCust = new _Customer();
me hace sacudir la cabeza con desconcierto.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.
fuente
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.
fuente
GetFoo
método, y luego unGetFoo_WithSomethingElse
mé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.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.
fuente
¿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.
fuente
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: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()
.fuente