¿Cómo debo validar el código cuando no hay nadie para revisar el código? [duplicar]

14

Estoy acostumbrado a trabajar en un gran entorno de desarrollo en el que el cliente revisa y prueba el código, que generalmente es una persona de TI. Ahora trabajo en una empresa muy pequeña en la que no solo soy el único desarrollador, sino la única persona de TI.

Me inclino a que mis compañeros de trabajo y / o mi jefe vean mi trabajo cada vez que termine una historia ágil, para que puedan aceptarla o rechazarla, como es el patrón al que estoy acostumbrado. Sin embargo, con demasiada frecuencia, mis compañeros de trabajo no entienden mi trabajo lo suficientemente bien como para juzgarlo o lo entienden mal y aceptan el código incorrecto o rechazan el código bueno solo por su apariencia superficial, como el color de los enlaces.

¿Entonces me pregunto cómo debería decidir cuándo aceptar / rechazar las pruebas ahora? ¿Debo tratar de evaluar mi propio código como una persona externa? ¿Debo saltarme y aceptar todo? ¿Debo intentar educar un poco a mis compañeros de trabajo y hacer que realicen las pruebas adecuadas?

    
pregunta Dylan Karr 20.01.2014 - 20:40

8 respuestas

1

Las historias de usuario deben escribirse en conjunto con el cliente.

¿Eres el cliente?

Si es así, entonces acepta tus propias historias. De lo contrario, programe un tiempo de revisión / escritura con el cliente.

    
respondido por el Steven A. Lowe 20.01.2014 - 20:57
9

Si está desarrollando un sistema en línea para su empresa, eso implicaría que alguien además de usted debe tener una idea de cómo debe funcionar al menos en el nivel de UI. Ese sería el nivel en el que otros miembros de la empresa pueden revisar su trabajo.

Desafortunadamente, eso significa que no hay nadie para revisar tu código. Una posibilidad es que puedas revisar tu propio código. Puede ser útil volver atrás y revisar su código una semana después de haberlo terminado, y ver si aún puede entenderlo. Alternativamente, puede intentar que su empresa contrate a otro desarrollador.

    
respondido por el Dima 20.01.2014 - 22:55
5

Como único desarrollador, creo que solo tienes que dejar ir (esperemos que temporalmente) algunas de las técnicas profesionales que tienen los equipos más grandes. ¡Pero PUEDES hacer algunos sustitutos!

Siempre debes usar repositorios. Probablemente debería hacer más pruebas que antes (ya que no hay otra persona que pueda detectar errores).

Si puede, haga que cada característica o adición sea un conjunto de cambios / estantería (o sucursal en git) por separado, de modo que pueda crear alguna característica, probarlo y luego ignorarlo durante 1-2 semanas (probablemente más tiempo es mejor) . A continuación, lea a través de todo el estante. Ahora: si no tiene problemas para entender cada línea de código inmediatamente, considérelo como un código revisado (como 1 persona creo que esto es lo mejor que puede hacer). Si hay partes del código en las que no comprende de inmediato todos los aspectos del código, dedique un tiempo adicional para ver si puede hacerlo más simple o más comprensible.

Mejor que todo lo anterior es hacer que tu jefe contrate a otro programador y a un compañero para que revise el código de los demás.

¡Buena suerte!

    
respondido por el Thomas N 21.01.2014 - 13:03
3

Bienvenido al mundo de la microgestión.

El lugar donde el jefe pierde dinero y los técnicos preparan café para otros

La mayoría de las técnicas de desarrollo ágil que has aprendido hasta ahora, en este momento se vuelven no aplicables. El principal problema es que, en ausencia de un equipo de desarrollo, lo que queda es quizás "programación extrema". Mi consejo es que quede claro para la compañía (sin importar el tamaño de ésta), esta situación es sostenible solo si el software se desarrolla a un nivel amateur. Esto no tiene nada que ver con su rol, puede continuar desarrollando aplicando todas las técnicas que conoce, pero solo a nivel de diseño y desarrollo de software. Continuar, quizás, desarrollar usando TDD, dibujando casos de uso en UML, etc. Pero un producto, necesita más miembros para ser desarrollado, depurado, optimizado, implementado, anunciado ...

  

No olvide que el desarrollo de un producto, debe pasar por una fuerte crítica, sobrevivir a esto, y luego tener su camino de integración continua. como programadores, no asimilamos bien las críticas de los demás y a menudo necesitamos una idea brillante de los demás, PERO cuando no están allí, nos convertimos en omnipotentes y todos los errores se convierten en nuestros.

Creo que el jefe (como se define), tiene un rechazo a la explicación de un técnico, esto normalmente lleva a la necesidad de gastar dinero, y en una compañía donde no hay un presupuesto definido para el departamento técnico, esto Puede generar conflictos entre administradores y técnicos.

  

Mi consejo es invertir en la capacitación de gerentes, sin dar muchas explicaciones e incluso en proyectos pequeños, organizar su trabajo listo para dar la bienvenida a los nuevos miembros en el equipo de desarrollo.

Algunos consejos

  1. Siempre use repositorios , tal vez un buen proyecto en github, con su código organizado como SuperProyecto
  2. Pase su tiempo por lo menos en definir cuáles son los hitos de las solicitudes que se le hacen;
  3. Organice su hito en simples hojas de cálculo en línea , ahora no necesita grandes administradores de proyectos, diagramas de Gantt, control de recursos, flujos de dinero, etc.
  4. Siempre comunique el progreso de su trabajo a través de correo electrónico , y adjunte el estado de su hito en PDF;

Creo que el método que elija hoy debe mostrar lo que hace y cuánto tiempo pasa.

última consideración

si le muestra a un jefe, 10 hitos , 3 de estos fueron código de escritura , y el otro se dividió entre, debug, design , instale, pruebe, en ese momento tiene una gran herramienta para dialogar con la administración ...

en ese momento, hablas su idioma.

    
respondido por el marcocs 20.01.2014 - 22:56
1
  

No solo soy el único desarrollador, sino la única persona de TI. Me siento inclinado a tener a mis compañeros de trabajo y / o jefe ...

A veces, en esa situación, es útil invitar a un amigo, incluso si él no sabe absolutamente nada de computadoras. Puede reunirse en su casa u otro lugar, y puede mostrarle su código, o él puede mostrarle su código. En mi experiencia, él era mi amigo, y por lo general buscaba un trozo de código, después de lo cual a menudo encontraba un error.

También puede ser un buen enfoque que simplemente intentes olvidar de alguna manera lo que hace el código. Solo duerme, ve a caminar, o incluso cambia el proyecto. Cuando olvide por completo la tarea completada, intente volver al proyecto, lea el código y reconstruya el propósito del código. Intente entender el código nuevamente, verá muchas ideas nuevas, e incluso errores en él. ¡Pero no esperes demasiado!

Este enfoque también se puede aplicar cuando escribes un artículo.

    
respondido por el Малъ Скрылевъ 23.01.2014 - 13:03
0

Para evaluar su código, puede usar herramientas automatizadas como PMD , Findbugs , Sonar , etc. ¿Cuál de estos tiene un conjunto de reglas que evalúan su código en función de las mejores prácticas? y patrones de diseño. También te permiten crear nuevas reglas para que coincidan con tus patrones y diseño de arquitectura. Puede ejecutarlas integradas en su IDE, en un servidor CI (como Jenkins ) o en un simple script por lotes.

No son perfectos, pero pueden brindar ayuda mientras no tengas otro desarrollador para revisar tu código. Son gratuitos y pueden programarse para que se ejecuten todas las noches, por lo que recibirá un informe nuevo cada mañana. :)

    
respondido por el Gustavo Coelho 24.01.2014 - 19:29
0

Si usted es el único trabajador de TI, entonces no tiene sentido que alguien a su alrededor revise el código. Nadie tendrá idea de lo que significa, y solo señalará cosas triviales como errores de ortografía.

Haga un uso extensivo de las pruebas unitarias. Preste atención a las advertencias del compilador y considere usar herramientas de calidad de código automatizadas (pero prepárese para ignorar o desactivar muchas de ellas).

Solo molestarse en preguntar a las personas que te rodean si tu código hace lo que quiere o no. Si es confuso, o no funciona para ellos, arréglalo. Si están contentos, entonces su código debe estar bien.

    
respondido por el Simon B 27.01.2014 - 13:29
0

Cuando trabajas en pequeñas empresas, es normal tener que usar varios sombreros. Tome el ejemplo más extremo, cuando la empresa se crea por primera vez, aún tiene roles de desarrollador, probador, analista, ventas, contabilidad, marketing, etc., pero probablemente solo 2 o 3 personas compartirán el trabajo.

En este caso, es bastante posible que esté haciendo el análisis de lo que se requiere, desarrollando, probando, implementando, manteniendo y dando soporte. Si bien es preferible que haya varias personas que cubran estos roles desde una perspectiva de calidad y continuidad del negocio, en una pequeña empresa que puede ser un lujo costoso.

El mejor consejo que puedo dar es que siempre tenga claro cuáles son los roles y que piense que está desempeñando cada uno de estos roles cuando realiza sus tareas en el proyecto. Con el tiempo, este proceso se volverá más fluido y se sentirá más cómodo al pensar en el futuro y manejar las responsabilidades competitivas.

Si yo fuera actualmente su gerente, me gustaría ver si puede asumir el reto y asumir la responsabilidad.

    
respondido por el Michael Shaw 27.01.2014 - 15:37

Lea otras preguntas en las etiquetas