"¿Cómo hacer una revisión del código?" o "¿Cómo decirle a un compañero de trabajo que su HTML apesta?"

Question

Acabo de empezar a trabajar para una pequeña empresa web que tiene un diseñador y un programador. Soy una especie de persona intermedia con experiencia en ambos mundos.

El problema que veo ahora es que el diseñador parece establecer los estándares, aunque sus prácticas a veces son incorrectas (como html no válido: envolver elementos de nivel de bloque con elementos en línea o usar tablas para el diseño cuando hay ninguna necesidad aparente). Sé que ella tiene buenas intenciones, pero también sé que los estándares que ella está "imponiendo" están desactualizados o no son tan efectivos como deberían. A veces, es difícil comunicarse con ella porque parece no estar dispuesta a tomar ideas de otras personas.

Creo que hacer revisiones de códigos de pares podría ayudar. En un momento, sugerí que pudiéramos tener revisiones de código, pero solo somos 3, y el programador y el diseñador no siempre comparten el mismo código, entonces, ¿realmente tiene sentido hacer revisiones de código?

¿Qué debo hacer?

¿Cómo puedo influir en que mi compañero de trabajo esté más abierto a las sugerencias y/o conozca algunas de las mejores prácticas?

Actualización: Gracias a todos por todos los consejos. Descubrí que "pedir ayuda" ponía a mi compañero de trabajo de mejor humor y era mucho más agradable para trabajar y más abierto a la comunicación.

Answer 1

Simplemente también asegúrese de explicar exactamente por qué es una mierda.

Malo: Su HTML apesta.

Mejor: Su HTML aspira porque se utiliza una gran cantidad de estilos en línea en los elementos HTML

aún mejor: Su HTML aspira porque se utiliza una gran cantidad de estilos en línea, lo que hace que sea mucho más difícil realizar cambios estéticos en todo el sitio al mismo tiempo, ya que uno debe editar cada etiqueta individual en lugar de una sola regla CSS que se dirige a cada etiqueta individual. Además, los tiempos de carga de la página pueden reducirse moviéndose a un único archivo CSS, ya que el cliente podría almacenarlos en caché por separado.

Y, obviamente, evitar el lenguaje incendiario como "tu html apesta" es una buena idea también. Solo estoy usando "su HTML apesta" como marcador de posición para críticas de cualquier tipo.

Answer 2

Encuentra la justificación de por qué crees que tus técnicas son mejores. Algo como el libro Refactorización de HTML podría ser útil.

Answer 3

le dicen que usar el validador;)

mostrar sus "por qué diseño de la tabla es malo" página web etc.

http://phrogz.net/CSS/WhyTablesAreBadForLayout.html ...

Answer 4

Vamos a una máquina haga el trabajo sucio por ti . Pase el sitio web a través de los validadores w3c.

http://validator.w3.org

Como mínimo todos los sitios web deben pasar los estándares de accesibilidad.

Answer 5

El proyecto en el que estoy trabajando involucra solo a dos programadores (incluyéndome a mí), y juntos hemos desarrollado un sistema de revisión (basado en las consideraciones del "The best kept secrets of peer code review"), y esto funciona bastante bien. Aprendí bastantes trucos de programación. Conclusión: la revisión del código (si se realiza correctamente) también funciona en equipos pequeños.

Lo difícil es convencer a su colega de que la revisión del código es necesaria/útil. Un truco aquí es ejecutar su código a través del validador en www.w3.org o hacer que lea el libro. Intenta siempre ser positivo, incluso si le estás diciendo que su código apesta (en cambio, intenta algo como "hey, he visto este truco. Esto también podría funcionar para nosotros" para hacerle cambiar su código). Asegúrate de nunca decir que su código es una mierda.

Answer 6

Organice reuniones informales en las que debata sobre otros sitios web y sobre cómo pueden mejorarse, como cada semana o cada dos semanas.

No desea que un equipo pequeño se queje del trabajo de los demás. Así que una idea podría ser elegir un sitio web que te guste o disguste, y discutir con el resto del equipo qué es bueno y qué no. Asegúrese de elegir algunos sitios web con algunas ideas más modernas. Su compañero de trabajo obsoleto podría recoger una idea o dos durante la discusión.

Si tiene un equipo más grande, puede pasar fácilmente a usar mecanismos de verificación automatizados. Pero en tu caso tienes un pequeño equipo, por lo que a menudo parecerá un ataque personal. Desea evitar esa sensación porque afectará el clima de trabajo. Entonces, habla sobre el trabajo de otros. Esto también es útil para analizar lo que el resto del mundo está haciendo.

Answer 7

Usted (el equipo) primero debe ponerse de acuerdo sobre un conjunto de reglas mandadory. ¿Está prohibido el uso de tablas para el diseño? Multa. Haz una regla explícita. Sin un conjunto de "leyes", tendrá dificultades para decirle qué reglas rompe con su código.

Answer 8

Una de las preocupaciones de los diseñadores tienen es:

¿Por qué debería hacerlo usando CSS si mis mesas y estilo en línea se muestra simplemente así?

que he encontrado que muestran los diseñadores Zen Garden homepage ayuda mucho a entender sin tablas HTMLs. Zen Garden se puede personalizar utilizando solo un CSS y se ha convertido en un muy buen escaparate de hermosos diseños que se pueden lograr utilizando divs. Un extra es que puedes descargar cada CSS y estudiarla, ha sido una muy buena fuente de aprendizaje para mí.

Muchos diseñadores web dirán WOW después de mirar en la página ;-)

Answer 9

En efecto, es necesario encontrar una respuesta a la pregunta: '¿por qué aspira este html?' IMO es muy importante ser capaz de expresar los problemas usted mismo antes de enseñar otra cosa. (a este respecto, ver también h ttp://stackoverflow.com/questions/868301/how-can-i-teach-a-know-it-all-beginner-programmer/868395#868395).

Algunas pistas:

• ¿Está el crossbrowser html? ¿Deberia ser? Ahora, o tal vez en el futuro. Muéstrele qué buscadores le dan efectos extraños y muéstrele por qué su html es difícil de cambiar para poder trabajar.
• ¿Está ella mezclando la presentación y el contenido? Encuentra recursos (y hay muchos) que indican exactamente por qué.
• Acerca de mingling: ¿se puede mantener su sitio? ¿Hay una separación clara de código, estilo (css) y html?
• Está usando material relacionado con el contenido como presentación. Como posiblemente tablas, iframes ...?
• Y sobre todo: ¿Es ella adherir una norma (como XHTML). Explíquele por qué es importante un control si el estándar es útil y no obsoleto, y compruébelo con un comprobador estándar, hay muchos en la web.

Especialmente el último punto podría ser útil, ya que es un tipo de objetivo. Adherirse a un estándar no es una solución milagrosa. pero al menos su html será consistente y más legible. Y, ella se verá obligada a piensan de su codificación, que es, IMVHO (im mi muy humilde opinon) el inicio de todo.

Answer 10

Para ser productivo, el equipo debe tener acuerdos sobre cada parte del trabajo. La productividad no aumentará si encuentra la manera de obligar al diseñador a escribir como quiera y ella no. Entonces, la única manera de tener tal acuerdo es la comunicación en la cual se debe mostrar cómo se puede hacer el trabajo de manera más efectiva e interesante (espero aprender algo nuevo que siempre debe ser interesante). Si este no es el camino para ti, entonces probablemente deberías pensar en dejar ese equipo.

Answer 11

¿Le falta algo de conocimiento de CSS? Puede ser que tengas un problema de formación técnica. Muestre sus ejemplos de buen diseño. Puede necesitar leer algunos libros (pagados por su empresa) y debe ser sutil para no ofrecer su ego. Puede ser algo así como:

"Hola, XXXX, mira estos diseños que acabo de encontrar. Es muy limpio y ordenado. Y mira, nos permite mantener el contenido y la presentación desacoplados. ¿Por qué no vamos en esto? De esta manera, un cambio en la presentación no necesita cambiar el código. ¿No crees que valdrá la pena invertir algo de tiempo para aprender cómo lo han logrado? ".

Answer 12

Vender al cliente sobre el hecho de que los requisitos de accesibilidad son importantes para el proyecto. Luego indíquele que seguir sus viejas costumbres es como robar bastones de ancianos y que eso no es agradable.

A continuación, mostrar a sus clientes/jefe cuánto más fácil es mantener unos buenos estándares web compatible.

Answer 13

Nunca puede ganar una discusión típica de "su código apesta", tales discusiones son muy subjetivas.

Cuando alguien sugiere la tecnología de otro siglo, les pido que resolver el problema de la mano con la tecnología que están sugiriendo de manera tan intensa. Cuando se hace correctamente (preguntando de manera humilde: "No sé si entiendo lo que quieres decir, pero espero que puedas demostrarlo por mí"), la otra parte con suerte entenderá el punto.

Answer 14

1) Consejo de Hagakure (http://en.wikipedia.org/wiki/Hagakure): hablar de su propio código de succión, algo. como "Hice esta tabla fea bla bla aquí, pero no estoy satisfecho con ella. ¿Tienes alguna idea de cómo mejorarla?" Nadie se siente criticado.

2) tenga paciencia, los malos hábitos de larga duración no desaparecen rápidamente.

Esta es la mentalidad principal. Todas las otras respuestas se aplican también. Esto debería hacer el truco ...

Answer 15

Tiene que haber alguien más arriba en la empresa que piensa que los sitios web no se actualizan correctamente y/o en un plazo de tiempo razonable.Si sus prácticas 'sucky' no han llevado a nadie a este punto, no deben ser tan malos.

Consigue algunos comentarios de los usuarios. Ofrezca una solución al problema de otra persona que tenga más autoridad que usted.

Answer 16

Para aquellos que son difíciles en sus formas, hablar es barato. Creo que lo mejor que puedes hacer es demostrar tu punto. Pero no la embosque con todas las cosas mal con su código. En cambio, solo elige un detalle fundamental. Si puede mostrarle una mejor manera de hacer una cosa que cambie por completo su enfoque, entonces ella comenzará a abrir sus ideas.

Entonces ... diga que encuentra una forma de reducir el HTML de la página de inicio en 5 KB mediante un mejor uso de CSS. Luego puedes continuar para demostrar cómo lo hiciste.

He estado en ambos extremos de esto. Y la única constante es que generalmente se necesita una prueba para convencer a alguien de cambiar la forma en que hace las cosas.

Answer 17

En una línea similar a lo que AmmoQ sugirió (No tengo suficiente karma para comentar sobre su publicación) - En lugar de "leyes", hemos documentado "Estándares de código". Es mucho trabajo, pero una forma no conflictiva de lograr que todos se unan a la red con una mejor calidad de código. Si tiene un código de proveedor de baja calidad, utilícelo como una excusa para necesitar estándares de código documentados. De lo contrario, solo use algo como "reforzar nuestro compromiso con el código de alta calidad". Una vez que las personas sean receptivas, investigue, escriba el documento y luego revíselo con sus colegas. Puede incluir citas para respaldar los estándares, para mostrar que no son subjetivas, sino las "Mejores prácticas" reales.

Además, podría sugerir un poco de "educación continua", un club de lectura a la hora del almuerzo que comienza con el libro CSS Zen Garden.

Su compañero de trabajo puede estar desinformado y ella sabe que lo que hace "funciona". No querer perder el tiempo con algo que funciona es bastante comprensible. Use la psicología para su ventaja: empareje "sus métodos están desactualizados" entre "usted tiene mucha experiencia" y "puedo aprender mucho de usted". Etc.

Answer 18

Siempre he encontrado que ir primero es una buena manera de comenzar. Envíe un correo electrónico al grupo diciendo: "Las revisiones de códigos son una buena forma de aprender y desarrollar las mejores prácticas en una empresa y descubrir formas de mejorar nuestro código. Una vez a la semana, hagamos una revisión del código donde uno de nosotros traiga algo que hayan escrito y todos lo revisaremos juntos. Iré primero esta semana ".

De esta manera, tienes la puerta abierta y parece mucho menos amenazante. Preséntela a su código y su forma de hacer las cosas de esa manera. Prepárese para hacer una copia de seguridad de su estilo de codificación con documentación ("Utilicé esta etiqueta en particular en lugar de una tabla porque es semánticamente correcta" o "Este trozo de CSS era complicado, pero nos ahorra el uso de gráficas espaciadoras en todo el lugar, lo que acelera el sitio y mejora la experiencia del usuario ").

Configure sus revisiones de código con muchos "buenos ejemplos" de su código o en otro lugar. No tengas miedo de pasar las primeras críticas en sitios populares ("veamos lo que hace Google en sus páginas de resultados de búsqueda y habla sobre por qué lo hicieron" o "esta semana, veremos CSS zen"). jardín y pensar cómo podemos aplicarlo a nuestro sitio "). Caliéntelos con buenos ejemplos para algunas revisiones y será mucho más probable que participen del proceso y señalen fallas en su código (y tal vez incluso en el suyo).

Answer 19

No creo que las reseñas sean el lugar para debatir este tema en particular. Lo que he visto hacer a otros es seleccionar otro sitio, o conjunto de sitios, que sea el "enemigo" o el "héroe" de su sitio.Su sitio quiere derribarlos en su propio juego o ser como ellos (la diferencia es mínima dependiendo de cómo compita su empresa). A continuación, realiza un seguimiento de los cambios que han realizado o están realizando y sigue con la forma en que sus tendencias de tráfico parecen verse afectadas (por ejemplo, con Alexa). Debería ser fácil encontrar que 10/10 de estos usan un estilo basado en bloques más mínimo. Efectivamente se convierte en su estándar para imitar entonces. Sin embargo, podría ser que su diseñador esté usando un conjunto donde 10/10 sitios tienen HTML que se parece al suyo. Ahora debe averiguar quién está convencido de que esos son los sitios que debe mirar y cómo va a cambiar de opinión.

¿Alguna vez ha notado que aproximadamente everybagmanufacturer tiene una página de producto que imita la de eBags.com? Ni siquiera estoy seguro de que eBags tampoco esté imitando a los demás. Muestras de color como cajas pequeñas más pequeñas que un ícono de 32x32, haga clic para ampliar, desplácese a una vista estándar para cambiar la imagen principal. Belkin compite en un mercado diferente y no solo fabrica bolsos, por lo que no coincide con el aspecto del grupo. Oh no, Jansport rompió con la regla de volcadura y la regla de zoom. Mira cómo esta publicación se vuelve obsoleta a medida que las ondas de imitación/investigación; Northface también usa ese estilo de acercamiento ya. (Esos enlaces están en una página de producto aleatorio. Ilustran la similitud de la página del producto. También hay similitud de página de categoría. En realidad, no estoy respaldando ninguno de estos artículos o compañías).

De todos modos, mi punto es que este estilo y casi todos los demás, ya sean visibles o en HTML o CSS, se basan en la propagación por imitación. Algo así como la audacia de los patrones de prueba de T.V. en la barra de colores, donde fue popular entre las portadas de los diseñadores alemanes & hace 5 años, pero notablemente ausente en otros grupos de idiomas de las páginas de inicio de los diseñadores. Por lo tanto, cambie quién está siendo imitado, o (si su HTML luce excelente) enfatice que el HTML subyacente contiene tantos secretos comerciales, y señálelos.