project-management - software - project management steps

¿Formas de prevenir la sobreingeniería? (28)

hazlo funcionar
hacerlo mejor
quedarse sin tiempo

En ese orden.

Cuando desarrollo software generalmente me pregunto continuamente "¿Es esta la mejor manera?" "¿Hay mejor tecnología para el trabajo?" y como resultado, puse más esfuerzo en investigar e investigar diferentes patrones de diseño / tecnologías / mejores prácticas que en el hecho de desarrollarlo con herramientas que sé que funcionarán.

Una cosa común que tiendo a hacer es pensar demasiado en el futuro y preocuparme por las cosas que pueden suceder en lugar de centrarme en las cosas que sucederán. No creo que esto sea necesariamente algo malo, sin embargo, a veces me toma demasiado tiempo.

Me gustaría saber si alguien más tiene problemas similares y cómo abordan estos problemas.

Adopta una idea de XP ... YAGNI. ( No lo vas a necesitar )

Código suficiente para resolver lo que se debe hacer ahora. Haz que funcione para satisfacción de tus clientes, eso es lo que realmente importa de todos modos. Luego avance a la siguiente función.

Si encuentra que necesita refactorizar algo, que así sea, solo hágalo gradualmente.

Contratar a un grupo de arquitectos de software para formar un comité para el análisis de todos los diseños.

Los diseños se enviarán en UML para facilitar el análisis.

Todos los proyectos usarán un lenguaje basado en XML interno para evitar los detalles de un solo idioma.

También necesitará estándares de codificación detallados para evitar que los trabajadores superen las tareas de ingeniería. Esto solo debería cubrir aspectos importantes como el posicionamiento de {}

El desarrollo basado en pruebas y la refactorización en conjunto significa que no necesita tener la mejor manera por adelantado, o incluso ver cómo todos los detalles encajan ... se trata de un diseño emergente .

Leer sobre las ideas detrás de esto podría ayudarlo a preocuparse menos por el perfeccionismo: http://c2.com/cgi/wiki?EmergentDesign

Así es como aprendí a hacerlo:

Aprenda a escribir la prueba primero para una pieza de funcionalidad simple.
Luego escribe el código que satisface la prueba.
Busque elementos de repetición o cosas que pueda simplificar. ANTES de intentar simplificar / duplicar el código, asegúrese de TODO el pase de prueba para que tenga una línea base para la refactorización.
Después de refactorizar, ejecute todas las pruebas nuevamente para asegurarse de que no haya cambiado ningún comportamiento que le interese.
Verifíquelo.
Repita ... hasta que termine ...
Esto es más fácil de hacer cuando te estás pegando con alguien más ... preferiblemente alguien que ya sabe cómo hacer XP.
Después de un tiempo aprendes a confiar en ti mismo y aceptas que no necesitas controlar todos los bits de la solución con minucioso detalle por adelantado ... aunque vale la pena comenzar a trabajar en las partes riesgosas / desconocidas primero ...

En otras palabras, aprende XP ;-)

El tiempo del boxeo es lo que hacemos.

Tenemos una mirada de 3 días sobre un problema futuro, y probamos algunas cosas y escogemos una solución.

Después de que se ejecute y entregue temprano y, a menudo, después de haber mostrado algún progreso, entonces puede refactorizar si se presenta una mejor respuesta.

En mi experiencia, la forma más sencilla de evitar la sobreingeniería es la experiencia. Mientras los novatos lucharán interminablemente con sus dudas y miedos, un desarrollador sénior simplemente lo hará. Y lo harán bien (la segunda vez, si no la primera).

La segunda forma más simple es la confianza. Aquí yace un peligro, sin embargo: sin experiencia, la confianza puede ser extremadamente peligrosa.

Lo cual deja la pregunta de cómo llegar con ambos en poco tiempo. Las mentes más grandes del mundo están trabajando en eso. Mi camino es usar pruebas automatizadas. Eso mata mis miedos y dudas más rápido que cualquier otra cosa. Me permite mover el conocimiento y la experiencia de mi cerebro a la computadora, por lo que mi pequeño cerebro es libre para lo siguiente que aparece y no tengo que preocuparme por todas las cosas que ya he resuelto.

Esta es una de las cosas que una revisión con sus pares debería ayudar a determinar. Deben dejarle saber si ''usted entra en las malezas'' (y podrá justificar esa afirmación). Por otro lado, también deben informarle si no ha hecho lo suficiente y está diseñando algo quebradizo y no lo suficientemente resistente para cambiar o problemas.

Evito la ingeniería excesiva o insuficiente al tratar de equilibrar la cantidad de tiempo que gasto investigando y diseñando con lo que razonablemente puedo esperar que sea su uso y vida.

Digamos que estoy escribiendo una utilidad que solo usaré alguna vez, y la usaré rara vez o incluso solo una vez. Si tengo que elegir entre codificar tal utilidad en Bourne shell o Perl en diez minutos, se tarda una noche en ejecutarse, y tomar tres horas para escribir una versión optimizada usando algoritmos sofisticados y difíciles en C ++ que se ejecutan en un minuto ... electricidad es más barato que mi tiempo.

Por otro lado, escribí componentes clave de productos que han sido utilizados por millones de personas o que han afectado a ellos durante muchos años. En tales casos, ha valido la pena tomarse el tiempo y el esfuerzo de esforzarse mucho en investigación, investigación y diseño, utilizar las mejores herramientas y técnicas, y luego pulir el código resultante hasta obtener un brillo brillante.

No hay una manera de hacerlo, es todo juicio. Y como con todos los asuntos de juicio, la experiencia es muy útil, como acertadamente señaló Aaron Digulla.

Cuando comencé como desarrollador de software profesional hace veinticuatro años, no sabía nada acerca de cómo tomar estas decisiones. Solo escribía el código, y si era demasiado lento o demasiado defectuoso o algo así, volvería y lo arreglaría. Pero cuando hice esa corrección, trataría de pensar en cómo podría haber evitado el problema en primer lugar, y cómo podría aplicar eso en el futuro. Y también he intentado escuchar a otros programadores cuando hablan sobre los problemas que encontraron y cómo los solucionaron.

Ahora, muchas docenas de proyectos y quizás millones de líneas de código más adelante, hay muchas decisiones de diseño que puedo tomar de forma casi instintiva. Por ejemplo: "Si estás trabajando en C ++, y estás enfrentando un problema que resolverá alguna plantilla STL, y no estás obligado a evitar el uso de STL, entonces ese es el camino a seguir. Eso es porque las implementaciones modernas de STL son altamente optimizado, y cualquier mejora que pueda obtener escribiendo su propio código no valdrá la pena ".

Además, puedo ver una situación y decir: "El 10% del proyecto donde es probable que tengamos problemas está aquí, y aquí, y aquí, así que ahí es donde tenemos que concentrar nuestro esfuerzo de investigación y diseño. el otro 90%, hagamos que funcione, pero podemos hacerlo ". Y funciona bastante bien.

Así que sigue codificando y sigue mejorando tu código, y sigue aprendiendo de otros desarrolladores de software y de tu propia experiencia. Si continúas prestando atención y pensando en cosas, aumentar el dominio del diseño de software llegará con el tiempo.

Excelente pregunta Esto es lo que he encontrado, y no todo es fácil de hacer:

Hacer prototipos De esta manera, tengo una comprensión más profunda del problema de lo que podría llegar a pensar con anticipación, y nunca me comprometo con un código que no es óptimo.
Obtenga experiencia con la optimización real del rendimiento del software real porque, al menos en mi experiencia, la sobre-ingeniería de software resulta en problemas de rendimiento masivo, como en este caso . Esto le enseña qué enfoques de diseño típicos conducen simultáneamente a la complejidad y la lentitud, por lo que puede evitarlos. Un ejemplo es el énfasis excesivo en las complejidades de las clases, la estructura de datos y el estilo orientado a eventos.
(Esto es lo opuesto a la optimización prematura, en la que al tratar de resolver problemas que no existen, terminas creando problemas).
A veces, he adoptado una visión realmente inflexible de la simplicidad del software, y ha tenido el costo de ser muy extraño, al parecer, para todos menos para mí. Por ejemplo, me encontré con la técnica de Ejecución diferencial , que acorta el código de la interfaz de usuario en un orden de magnitud y lo hace muy fácil de modificar, pero al mismo tiempo crea una curva de aprendizaje que pocos han escalado.

Hay algunas maneras que me vienen a la mente:

Enfóquese en lo que se le preguntó y, cuando sea posible, haga que los requisitos sean lo más claros posible. El primero puede ser visto como pasivo-agresivo para algunos, ya que hacer exactamente lo que se les pide no es necesariamente una práctica común.
Quédate en el momento, evita jugar el juego "Qué pasa si", YAGNI.
Time-box el trabajo para que no sea un agujero negro que absorbe todo el tiempo disponible.

Un par de otras cosas para notar:

Evita castigarte por hacer el trabajo que hiciste. El pasado permanecerá en el pasado independientemente de lo que hagas.
El código perfecto para una aplicación es un mito. El enemigo de un buen plan es el sueño del perfecto.
Si bien algunos análisis son buenos, use la moderación para evitar la "parálisis del análisis"

Hay un principio seguro a seguir: primero hacer las cosas, luego ser inteligente. Debes alcanzar el primer objetivo, el segundo no.

La idea de entregables incrementales centrados en las características más críticas del Proceso Unificado fue diseñada para resolver este problema. Se necesita disciplina para implementar.

Haga una lista de características (casos de uso), priorícelas, elija la prioridad más alta y trabaje en eso como si fuera la única característica que necesitará. Cuando lo entregue en forma de trabajo, analice de nuevo y seleccione el siguiente conjunto de características para trabajar.

La mejor manera que he encontrado para evitar la sobreingeniería es asegurarme de que solo escriba código para la mayor cantidad de especificaciones que conoce actualmente. Si tiene una clase que necesita llamar a un servicio web y recuperar un tipo de datos, no se moleste en escribir un sistema increíblemente robusto que pueda manejar todos los casos posibles.

Dicho esto, esta técnica realmente REALMENTE requiere que crees un código limpio, bien escrito y fácil de comprender, y requiere que uses accessors en todas partes. Si no lo haces, terminarás con una pesadilla de refactorización.

Cuando escribe código para satisfacer solo lo que sabe que necesitará en el momento en que termina construyendo la funcionalidad rápidamente, cuando cambian los requisitos puede volver atrás y refactorizar su código para agregar la funcionalidad faltante. Cada vez que agregue una nueva característica, su código mejorará cada vez más (léase: debería).

Ciertamente, hay algunas decisiones generales de diseño que deben tomarse al comienzo del proyecto, pero esas decisiones son de muy alto nivel y no deberían afectar su capacidad de cambiar como lo hacen los requisitos.

Mientras usa esta técnica, querrá tomarse un momento antes de escribir cualquier módulo nuevo para preguntarse si es necesario para la implementación actual, si no, déjese un comentario y escriba solo lo que se necesita.

Las optimizaciones prematuras y el manejo de what ifs definitivamente pueden ser un problema.

Una idea general es asegurarse de tener un código que funcione lo mejor que pueda y esté dispuesto a adoptar mejores prácticas a medida que las aprenda.

En general, sin embargo, la respuesta más simple para resolver los problemas conocidos actuales es generalmente la mejor. Sin embargo, su código debería poder detectar los casos de error inesperados y registrarlos / exponerlos para que pueda agregar un manejo más sólido de esos casos de esquina.

Me encuentro con esto a menudo. Si necesito resolver algo en un idioma que utilizo regularmente, que hoy es JavaScript, y estoy atascado, trato de resolver el problema usando un nuevo marco. Hay algo sobre el uso de una nueva herramienta, una nueva biblioteca de códigos, incluso un navegador que no suelo usar, que me ayuda a superar el bloqueo psicológico de tratar de hacerlo bien.

Mientras cumpla su meta de tiempo, invierta tanto como pueda. Si no puede cumplir con su objetivo de tiempo ... invierta solo si cree que es crucial cumplir con los requisitos o si cree que está yendo en una dirección que será imposible corregir más adelante si está mal ...

Necesitas dos cosas: Timeboxing y Peer Review

Timeboxing es tan simple como decir que pasaré N horas investigando tecnología para hacer que esto funcione mejor.

La revisión por pares significa que usted discute el problema con otros ingenieros interesados.

Suena como si estuvieras trabajando por tu cuenta, lo que hace difícil la revisión por pares. Yo trabajo en una tienda de Scrum. Parte del proceso requiere que analicemos todos los arreglos y características, luego obtengamos el acuerdo de los otros ingenieros antes de escribir una línea de código. Esto funciona igual que ''Medir dos veces, cortar una vez''. Pasamos aproximadamente la mitad de nuestro tiempo investigando y planificando, y vale la pena la inversión.

No es tan difícil evitar la sobreinnovación, solo tienes que ser pragmático ...

obtener una historia de usuario
hacer casos de uso de la historia del usuario
escriba una prueba unitaria para la primera característica del primer caso de uso
implementar la característica
refactor si es necesario, use SRP para dividir las clases demasiado grandes
pasar a la siguiente función
pasar al siguiente caso de uso
Una vez que haya terminado, puede agregar la API (por ejemplo, REST) y la base de datos (por ejemplo, PgSQL) a su aplicación (esta parte depende del modelo de desarrollo que siga)

Al usar TDD no tiene que planear la jerarquía completa de clases o comprender todo el proyecto, solo tiene que escribir una pequeña porción de código o prueba a la vez. Esto ayuda mucho al enfocarse solo en las cosas que realmente necesita ...

Actualmente estoy experimentando con la arquitectura limpia , que es muy efectiva con TDD mediante la construcción de aplicaciones fáciles de probar, desarrollables y mantenibles.

Otro enfoque es examinar periódicamente todo lo que ha hecho y refactorizarlo: elimine todo lo que no se necesita. Repetir tanto como se necesite. Hace que el código sea más simple para la próxima iteración.

Saludos

Parece que no tienes un gerente de proyecto.

Debes robar técnicas de la famosa Debug Rubber Duck y aplicarlas a la gestión del proyecto. Imagine que Rubber Duck es su gerente de proyecto que representa al cliente principal, y explíquele que desea tomar X horas investigando una nueva tecnología o una nueva arquitectura. Ahora imagine que Rubber Duck le pregunta si cree que las nuevas características valdrían X * Y del dinero del cliente, donde Y es su salario por hora más el costo de su escritorio y sus beneficios. Luego, Rubber Duck le pregunta si cree que la nueva función vale la pena demorar la entrega del producto X horas.

Conteste honestamente las dos preguntas del pato y proceda con el desarrollo basado en su respuesta.

Incidentemente, probablemente deberías preguntar al Pato si le importa todo el tiempo que pasas en .

Plazos

Practique YAGNI (No lo va a necesitar), y su productividad puede aumentar. Posiblemente mucho.

Es posible que desee leer The Duct Tape Programmer , sin embargo, ejercite su buen juicio cuando lo haga.

Que sea simple, estúpido

Una máxima invocada a menudo cuando se discute el diseño para defenderse del progresivo dramatismo y controlar la complejidad del desarrollo

http://en.wikipedia.org/wiki/KISS_principle

Sí, he visto y experimentado este problema muchas veces. La solución número uno (para mí) es un horario. No es un cronograma del departamento de marketing que se determina al insertar Black Magic aquí . Estoy hablando de algo así como un cronograma mensual / trimestral que se inflija a usted o a su grupo en el que diga "en esta fecha, debemos tener un proyecto que funcione y que pueda armarse, que si cancelaban nuestro proyecto ese día, todavía tener algo bueno ".

Lo que hace es poner hitos reales por ahí con los que debes comprometerte. Recuerde, los hitos son rocas. Ellos no se mueven. Del mismo modo, el calendario simplemente marca. Si no puede comprometerse a llegar a una solución lo suficientemente buena a tiempo, no tendrá nada que valga la pena ese día.

Personalmente, creo que un desarrollo de tres semanas + 1 semana de integración, prueba, limpieza y preparación final es un buen arreglo para grupos pequeños y medianos. Su kilometraje variará.

Sí.

Para evitar la sobreingeniería, haz esto.

Construye la cosa más pequeña y simple que resuelva el problema.
Investigar alternativas.

Use parte de CMMI; mídese usted mismo

Encuentra una forma de mantener un recuento de cuántas veces superaste el número de veces que subdesarrollas. Averigua cuánto te cuesta menos reingeniería algo que te cuesta. Espere un año o dos, y mire hacia atrás.

Pensar más sobre esto puede ayudarlo en el corto plazo, y en el largo plazo, tendrá los datos para saber si su miedo a la sobreingeniería estaba justificado o no.

Libertad anticipada, la liberación a menudo

Incluso si no está liberando a un cliente externo, puede tener una versión interna para el propietario o probadores del producto. Este tipo de ciclo de trabajo te hace enfocarte más en la tarea que tienes entre manos y no en el futuro.

Elija la solución que funcione para usted y no intente buscar otra cosa a menos que esté limitado por la actual (Murphy: si no está roto, no lo arregle)
Crea una lista de prioridades y apégate a ella.