¿Cómo obtiene coherencia en el código fuente / UI sin sofocar la creatividad del desarrollador?

7

Tenemos un pequeño equipo (2-3) de programadores que escriben un programa con muchas formas y diálogos. Tenemos un problema en el que no podemos mantener una buena coherencia en lo que escribimos o en cómo lo escribimos.

El último problema que he notado es que tenemos muchos lugares donde tenemos un rango de fechas, y usamos todo tipo de texto para indicar que este rango es Inicio / Fin o De / A o "Entre _ y _ ".

El otro lado de esto es que uno de los desarrolladores podría encontrar una mejor manera de hacer algo (como inicializar el estado de una casilla de verificación desde el archivo de configuración). Y luego tendremos todas las cosas "antiguas" escritas en la forma antigua / pobre, y las cosas nuevas escritas con un método mejor.

Trato de estar constantemente atento a lo primero, pero parece que siempre estoy encontrando nuevos fracasos.

El segundo crea una enorme carga si vamos a volver y arreglar todas las cosas viejas tan pronto como encontremos una forma ligeramente mejor de hacer algo. O eso, o ignoramos todas las cosas antiguas hasta que algo se rompe, y entonces no tenemos idea de qué diablos está haciendo el software porque está escrito de manera completamente diferente a lo que escribimos actualmente.

Una última cosa, si presionamos la carga de "arreglarlo en todas partes ahora que lo ha encontrado" en el desarrollador que encuentra la mejor solución, es contraproducente, porque es genial, es una mejor manera de hacerlo. verifique ese error, ahora repárelo en todas partes en el código.

Los jefes realmente nunca parecen preocuparse por la calidad del código, solo cuando podremos lanzar la próxima versión (pero esa es una discusión diferente).

    
pregunta David 04.05.2011 - 16:26

5 respuestas

0

Lo más importante para usted y su equipo debe ser comunicación .

Es posible que desee desarrollar una guía de estilo común que defina cosas como "cómo se debe nombrar un rango de fechas". Sin embargo, es muy importante que esta guía de estilo sea apreciada por todos en el equipo. Si alguien tiene la sensación de "oh, Dios mío, sé cómo hacer mi trabajo y ahora tengo este estúpido documento que me dice qué hacer", entonces el esfuerzo está condenado desde el principio. Por otro lado, si todos están de acuerdo, "sí, esa es una buena idea, ahora sé dónde revisar cuando no sé cómo nombrar una cosa", entonces será mucho más productivo.

Sin embargo, tal creencia común se establece mejor, cuando todos son parte del proceso de desarrollo y se sienten como "sí, contribuí a ese conjunto de pautas". Si su equipo de programación es pequeño, como escribió, entonces es la situación ideal.

El otro hecho lo buscará por el resto de su vida de desarrollo: nunca escribirá el código perfecto. Eso ya se ha dicho. Pero nunca escribirá un código, que cuando lo vuelva a visitar unas semanas más tarde, todavía le parecerá bien. Incluso si eres el único que ha tocado el código. Siempre me encuentro pensando "Dios mío, ¿qué demonios has estado pensando cuando escribiste ese pedazo de basura?". Lo gracioso es: , que tuve mis razones para hacer algo exactamente como lo hice, simplemente no puedo creerlo más.

Tienes que aceptarlo, y sí, empeora cuando trabajas con otra persona porque, seamos sinceros, el software de escritura es como conducir un auto: nadie puede hacerlo mejor que tú mismo; -)

Por lo tanto, siempre tendrá que refactorizar su software. Arregla las cosas que hiciste mal en primer lugar. Eso es algo bueno y totalmente normal.

  

A los jefes realmente nunca les importa la calidad del código, solo cuando podamos lanzar la próxima versión

Eso puede ser cierto a primera vista. Afortunadamente, no todos los jefes piensan de esa manera, pero incluso si lo hacen: la calidad del código tiene un efecto directo en la capacidad de enviar la próxima versión. El código incorrecto conduce a más errores, lleva a más tiempo necesario para reparar el producto, etc. El elemento central aquí es la comunicación, una vez más. Debe aceptar el pensamiento de que refactorizar e introducir un mejor código es una parte integral del desarrollo. Refactorizar no es solo "Oh, esto se ve mejor, tomemos algo de tiempo e implementemos el cambio", sino que hacemos que el producto se ajuste y sea sólido para las generaciones futuras. Esto podría requerir algo de backbone que le diga a otra persona "No, no podemos seguir adelante, necesitamos refactorizar la característica X", pero eso es parte del trabajo.

    
respondido por el perdian 05.05.2011 - 11:54
7
  • Use la herencia y los objetos comunes para almacenar la IU y el código comunes en un lugar, de modo que se pueda usar en toda la aplicación. De esta manera, si algo necesita ser arreglado, se arregla en un solo lugar y los cambios se aplican automáticamente en todas partes.
  • Use el análisis de código para verificar el estilo de codificación y aplicar ciertas formas de escribir código. No podrás cubrir todas las posibilidades, pero ayuda. Además, debe acordar ciertos estándares de codificación entre los miembros de su equipo y comenzar a usarlos.
  • No te preocupes por arreglar cosas en todas partes de inmediato. No debería ser de un desarrollador arreglarlo de todos modos. Todos en el equipo deben ser conscientes de la "mejor manera" de hacer algo específico y solucionarlo a medida que lo descubren mientras trabajan en otra cosa. Además, debe dejar pasar un tiempo para refactorizar su código durante su ciclo de desarrollo, que podría dedicarse a solucionar soluciones antiguas para utilizar las más nuevas ("mejores").
respondido por el Bernard 04.05.2011 - 16:34
1

Pida a los desarrolladores y diseñadores que trabajen juntos para crear una guía de estilo para su producto, y haga que los desarrolladores la sigan. Realice revisiones frecuentes a medida que se implementa el código para asegurarse de que coincida con la especificación (en general, los detalles obviamente cambiarán un poco a medida que alcance las restricciones de implementación). Actualice la especificación a medida que pase el tiempo para incorporar los cambios deseables.

En la medida de lo posible, separe la lógica y la presentación, de modo que si decide un nuevo elemento de UX (por ejemplo, "entre $ inicio y $ final" en lugar de "desde $ inicio hasta $ final"), solo tiene que cambiar una cadena en un solo lugar.

Finalmente, si 'creatividad' es realmente una forma educada de decir 'no se puede seguir la especificación', conversa sobre eso. Hay lugares para expresar creatividad y lugares para trabajar dentro del diseño; inventar nuevos elementos de interfaz sobre la marcha conduce a un producto confuso e inconsistente. Por otro lado, la consistencia es solo un objetivo uno , no el único objetivo: a veces está bien tener alguna inconsistencia.

    
respondido por el Alex Feinman 04.05.2011 - 16:32
1

Debes sentarte con todos y crear un & Styles; Guía de normas. Lo ideal es que desee un documento que contenga ciertas convenciones que sean comunes en todas las partes de la (s) aplicación (es). Puede contener estándares de denominación, estándares de diseño de interfaz de usuario, etc ...

Está preocupado por sofocar la creatividad, así que asegúrese de que la guía sea una guía y no una biblia que deba seguirse religiosamente. Ciertos tipos de pequeñas desviaciones de la guía deberían estar bien si son necesarias y el líder del equipo debería aceptarlas con una buena justificación (la decisión no debe dejarse solo al desarrollador; es necesario un poco de revisión y aceptación por parte de los superiores). Dependiendo de qué tan grande sea la desviación, es posible que desee hablar con la gerencia / QA antes de permitirlo, ya que puede indicar un área para cambios en la guía de estilo en sí (si se trata de una desviación de intento grande o recurrente).

También es importante que haya un proceso para cambiar / actualizar la guía para mantenerse al día con nuevas técnicas, nuevas ideas de diseño, nuevas marcas corporativas, etc. Sólo tenga en cuenta que cambiar la guía puede invalidar partes antiguas del sistema. así que a veces es necesario volver atrás y actualizar el programa.

    
respondido por el FrustratedWithFormsDesigner 04.05.2011 - 16:33
0

Innovación == Disrupción.

Así es como se ve la innovación ("creatividad"). Parece un código nuevo, disruptivo, no estándar, no compatible.

Aquí está la cita obligatoria:

  

Una consistencia tonta es el duende   De pequeñas mentes, adoradas por poco.   estadistas y filósofos y   divinos.

He aquí por qué es importante.

Enfoque en el valor

La consistencia simple puede no tener ningún valor.

  

tenemos muchos lugares donde tenemos un rango de fechas, y usamos todo tipo de texto para indicar que este rango es Inicio / Fin o De / A o "Entre _ y _".

¿Cómo se preocupa esto por crear valor? ¿A quién se ayuda? ¿Cuánto vale?

¿Cuánto cuesta costar dejarlo solo?

La consistencia no es un atributo de calidad directa. En el mejor de los casos, un código coherente podría facilitar el mantenimiento o la adaptación. Pero en su mayor parte, es de muy poco valor.

Esto no es realmente muy innovador, por lo que no importa mucho.

  

uno de los desarrolladores podría encontrar una mejor manera de hacer algo ... Y luego tendremos todas las cosas "antiguas" escritas en la forma antigua / pobre, y las cosas nuevas escritas con un método mejor.

¿Y?

¿Cuál es el valor en el cambio retroactivo de una gran cantidad de código?

¿El costo de buscar y reemplazar es realmente apropiado para el valor creado?

¿Qué tiene de malo cambiarlo eventualmente ?

El código va y viene. El código se vuelve a trabajar todo el tiempo. Es posible que se elimine algún código (porque ya no se usa) en lugar de cambiarlo para que sea consistente.

Innovación significa que tiene un código heredado que está evolucionando lentamente hacia la nueva forma.

Si valora la innovación, debe valorar el cambio y la interrupción asociada con la innovación.

    
respondido por el S.Lott 04.05.2011 - 17:05

Lea otras preguntas en las etiquetas