Horario de programación para portar un programa

Question

Estoy trabajando en un programa grande que tiene una API GUI abstraída. Está muy basado en GUI, muchos cuadros de diálogo y algunas características desagradables que dependen en gran medida del flujo de mensajes de la GUI (secuencias correctas de enfoque/mouse/manejo activo, etc.) - no es fácil conectar al puerto

Ahora quiero hacer un puerto desde el FOX Toolkit actualmente utilizado hasta el Cocoa/MFC original.

Me doy un plazo de tiempo hasta el final del año, pero mi trabajo principal será continuar el trabajo de desarrollo con el kit de herramientas existente, pero no hay una versión planificada para los clientes finales antes de realizar ambas tareas.

Mi pregunta es ¿cómo debo pasar mi tiempo?

1. dejar de trabajar en el programa principal y hacer un puerto de 90% (alrededor de 3 mes) de la primera interfaz gráfica de usuario
2. Dividir todo en pequeñas sesiones de un mes cada uno.
3. Asignación de lunes/martes al proyecto GUI y el resto de la semana para la aplicación.
4. Terminando la aplicación primero, luego el puerto.

Creo que hay tres argumentos que debo equilibrar.

1. motivación, quiero ver algo que hacer en ambos proyectos
2. cerebro desbordamiento de entrada, ambas tareas requieren una gran cantidad de información detallada en mi cerebro y en ocasiones lo suficiente es suficiente.
3. Supongo que la interconexión se intercala, por lo que la transferencia también requeriría muchos cambios de código en el código existente y el nuevo código que se escribirá mientras tanto.

Answer 1

Si no hay una versión planificada para los clientes, entonces tiene el lujo de poder estructurar el trabajo exactamente como lo desea.

Mi primera impresión es que poner esfuerzo en terminar la aplicación en la plataforma actual, cuando vas a tirar ese código, es tiempo al menos parcialmente desperdiciado (obtienes algo de aprendizaje pero el código final no sirve de nada)

Personalmente aparcaré la versión existente y comenzaré de nuevo con la reescritura de Cocoa.

Primero lo dividiría en pedazos funcionales y vería cada uno como un lanzamiento de estilo ágil. Estos deberían centrarse en las funciones y tareas del usuario final, e incluir tanto la GUI como el trabajo posterior para estos.

(La razón por la que no me gusta la idea de trabajar con la GUI y la lógica de la aplicación por separado es que no están separadas. Como parte de una reescritura, puede haber oportunidades para realizar mejoras y esto es más difícil si Tengo que mantenerlos compatibles. Una reescritura es una oportunidad para hacer cambios fundamentales que a menudo no vienen, lo tomaría.

Trabaje a través de los trozos funcionales uno por uno, llevándolo a un estado completo y liberable antes de pasar al siguiente. Esto les dará a ambos el sentido de logro y la capacidad de medir el progreso. También significa que si una implementación surge de la nada, tiene fragmentos completos utilizables.

Además, al centrarse en las tareas de extremo a extremo, con un poco de suerte las cosas que se desbordan se minimizan ya que siempre se está trabajando en un área específica y no en la aplicación.

Answer 2

Terminé la aplicación primero, luego la porté. IMO, cuanto menos proyectos manejes al mismo tiempo, más efectivo serás.

Answer 3

Realmente depende de con qué se sienta cómodo.

Personalmente, comenzaría a portar ahora - un subsistema/pieza a la vez. No tiene que hacer que todo se porte de una sola vez. Puede encontrar que los fundamentos de su aplicación deben reescribirse para admitir que se transfiera. Si espera hasta terminar la aplicación para hacer el puerto, puede terminar reescribiendo porciones grandes de la aplicación de todos modos. Así que comenzaría por portar bibliotecas de soporte y funcionalidad central, y luego trabajaría lentamente hasta los bordes.

Mientras tanto, cada vez que introduzca una nueva clase en el puerto no, asegúrese de que sea portátil desde el principio.

Answer 4

Empecé con un mes para MFC, Cocoa y GTK para hacer las cosas básicas. Y después de esta semana, los ciclos entre los sistemas para obtener la capa de abstracción GUI. Aún no he tocado la aplicación.

Esto fue bastante eficiente. Incluso cuando la complejidad de MFC, Cocoa y GTK hace que el típico lunes por la mañana cuando hago el cambio sea aún peor.

Y ahora sé mucho cómo tengo que cambiar mi aplicación. Voy a portar el kit de herramientas de la GUI antes de continuar agregando funciones porque, como mencionó Jon, tendría que escribir partes dos veces.