¿Me he sobre extendido con este proyecto?

Question

Actualmente estoy reescribiendo la aplicación de base de datos de nuestra compañía, que es una interfaz de Access-VBA para un back-end SQL Server (Express).

He estado administrando la aplicación durante 4 años aproximadamente y ahora, cuando comencé aquí, era un único * .MDB-file en una red compartida (que se corrompía semanalmente).

Desde entonces, cambié el DB a un multiusuario * .MDE, luego migré los datos a un servidor SQL Express como * .ADE.

Desde entonces la aplicación se ejecuta sin problemas y es muy confiable.

Pero, por supuesto, hay algunos inconvenientes al usar Access (sin control fuente, dependiente de la versión de Office, etc.), así que sugerí a mi jefe que reescribiera la interfaz en C# & WPF.

Hice un poco de Java y C++ hace unos años, pero eso es todo. Ahora he estado trabajando en este proyecto durante 3 meses más o menos y la marcha es muy difícil. Solo para tareas tan simples como llenar un cuadro combinado, tengo que buscar en la red y leer muchas cosas.

Realmente quiero aprender C# (y también he aprendido muchas cosas desde que comencé!) Y encuentro que esta es una gran oportunidad, pero tal vez me he sobreexcitado, comenzando con una aplicación LOB real como soltero, junior ¿desarrollador?

Answer 1

Escoger una tecnología para un proyecto porque desea aprender que siempre es un riesgo. También me preocupé por WPF. Por un lado, no es una tecnología probada (en el mismo sentido en que lo es Winforms). Todavía es bastante nuevo. El segundo es que pone límites potencialmente problemáticos en qué sistemas se puede ejecutar. Vista/Win7 o creo que XP SP3. Eso puede o no ser un problema.

La buena regla general es que debe enviar con anticipación y enviar con frecuencia. Romper una pieza de funcionalidad y entregar eso. Durante un tiempo, puede hacer que los usuarios usen ambas aplicaciones para diferentes tareas. Estás mucho mejor haciendo eso que tratando de tragar todo de una vez.

Además, y creo que está descubriendo esto, las reescrituras completas casi siempre son un error. Es mucho trabajo por poco aumento, te estás dando muchas oportunidades para introducir errores en cosas que ya funcionan y pierdes un montón de conocimiento del dominio (y código de trabajo).

Answer 2

Casi siempre estoy de acuerdo con Cletus, pero voy a jugar en ambos lados y decir ¿dónde se dibuja la línea? ¿sigues manteniendo ese proyecto que te fue entregado a finales de 1903? ¿Cuándo se debe morder la bala y reescribir el sistema? Creo que cuando se le presente un proyecto tan desarticulado como el que está describiendo, debe fragmentar el sistema en características, hitos que debe alcanzar y probar la prueba de prueba, pruebas que validan la función que está reescribiendo.

Answer 3

Obviamente no te conozco, pero creo que deberías ser capaz de manejarlo. En un nivel abstracto, puede mantener mucho de la aplicación anterior (como: diseño general, qué formas hace qué, etc.) lo que hace que sea mucho más fácil no perderse por completo en un bosque en crecimiento. También puede usar eso para evaluar su progreso: ¿Cuántos formularios (procedimientos, etc.) contiene la aplicación anterior, cuántos de ellos ya se han reescrito?

Claro, al principio tienes problemas con los detalles (como los combo-boxes mencionados) pero una vez que superas eso y obtienes algo de rutina (y algunos archivos fuente para copiar y pegar), no será más difícil para ti que para cualquier otra persona

Answer 4

buque temprano y el buque a menudo.

Estoy de acuerdo con cletus() en esto. "¡Envíalo!" es una lectura rápida con algunos buenos consejos sobre este tema.

El gran riesgo de trabajar en una reescritura es que pasa mucho tiempo en ella y luego el proyecto se cancela antes de que esté casi terminado o se envía con el 100% de la funcionalidad en un 50% de trabajo estado. Si su reescritura está en manos de algunos usuarios, es menos probable que se cancele el proyecto y los usuarios controlarán la funcionalidad que necesitan a continuación. Puede suceder que la aplicación anterior tenga muchas funcionalidades que no se usan mucho, de modo que usted puede obtener la mayor parte del valor en manos de los usuarios en mucho menos tiempo de lo que lleva una reescritura completa.

Una vez que el código está en producción se sentirá más feliz y ser aún mejor motivados, y esto le ayudará a trabajar más rápido.

Sólo para tareas tan simples como llenar un cuadro combinado tengo que buscar en la red y leer un montón de cosas.

¿Está insatisfecho con su tasa de progreso (o "velocidad" en Agile-speak)?

Obviamente, si pudiera producir más todos los días, la tarea podría parecer menos abrumadora. Existe una gran diferencia de productividad entre los mejores programadores y el promedio (consulte Peopleware o el Mes del hombre mítico), por lo que cualquier cosa que pueda hacer para convertirse en un mejor programador podría marcar una diferencia significativa.

En su caso, me pregunto si algún entrenamiento podría ayudar? Normalmente no soy un gran admirador de la capacitación en el aula, pero si no tienes muchas personas con experiencia para aprender, esto te dará un buen comienzo. Si la capacitación no es una opción, ¿tiene un grupo de usuarios C# local? Si hay más desarrolladores experimentados en su empresa, ¿podría acudir a ellos en busca de consejo? ¿O simplemente elige sus cerebros en el enfriador de agua?

Un gran problema con el trabajo por su cuenta es que a veces se queda atascado en algo muy simple, que alguien más podría detectar de inmediato. A veces, solo explicarle un problema a otra persona te ayuda a verlo de una manera que te ayude a resolverlo. Si pudiera trabajar con otra persona aunque sea por poco tiempo todos los días, esto podría ayudar a su productividad.

¿Tiene (y usa) todas las herramientas que necesita? El mínimo absoluto es: a. Un sistema de control de versiones. b. Una base de datos de seguimiento de errores. c. Un buen entorno de desarrollo, p. Visual Studio d. ¡Un mejor entorno de desarrollo que Visual Studio! p.ej. Resharper.

Ver link text para una mejor lista.

¡Buena suerte!

Answer 5

Yo diría chuck lo que sea que haya hecho en C# y vuelva a su aplicación de acceso.

Está construyendo una interfaz de la base de datos para un servidor SQL Server. El acceso es perfecto para eso: esa es toda la razón para existir.

Para control de código fuente, hay Visual SourceSafe (aunque yo no entiendo muy bien por qué se necesitaría para un proyecto de una sola persona). En cuanto a la dependencia de la versión de Office, ya no es tanto un problema desde Access 2000, aunque los ADP dependen mucho de la versión porque no se comportan igual en todas las versiones de Access. Y para el caso, MS ha estado desaprobando los ADP durante los últimos años a favor de la interfaz de usuario MDB/MDE vinculada a SQL Server a través de ODBC.

creo que has tirado al bebé junto con el agua del baño y debe volver a Access para la parte delantera. ¿Quieres una aplicación que funcione? ¿O quieres decir que eres un desarrollador de C#?

¿Se puede cuantificar el rendimiento real de la inversión para volver a escribir la parte delantera? Si es así, creo que encontrará que quedarse con Access va a tener un valor mucho mejor que una reescritura mayorista.

Answer 6

Si quieres aprender una nueva e importante tecnología no le aconsejan comenzar con una reescritura importante de un sistema de misión crítica. Eso es casi un error estereotípico, el tipo de cosa que termina obteniendo 250 votos aquí en Stackoverflow bajo una pregunta como "¿Cuál es el error más grande que haya visto al actualizar una aplicación comercial?"

Usted haría mejor que hacer su propio proyecto en .NET en primer lugar, por pequeño que sea. Por ejemplo, para mojarme los pies con jQuery, recientemente escribí el juego de la Memoria (donde das la vuelta a dos fichas a la vez buscando las imágenes que combinan). Podría hacer algo así, o un simple programa de talonario de cheques.

Si tiene que hacer un trabajo empresarial real en la aplicación principal de su empresa como un proyecto de aprendizaje, seleccione una unidad de trabajo pequeña y discreta (separada del resto de la aplicación) y hágalo como proyecto de prueba. No debe interrumpir la aplicación existente, solo agrega una pieza de funcionalidad independiente. Con base en ese experimento, usted y su jefe pueden decidir si vale la pena avanzar con la siguiente unidad de trabajo, un poco más grande.

Answer 7

Puede utilizar SourceSafe con MS Access, se integra muy bien. Yo recomendaría esto si este es un proyecto de una sola persona o no, se guardó mi tocino un par de veces ...

No estoy seguro de que WPF sea una opción adecuada para una primera aplicación, es una curva de aprendizaje empinada y los beneficios para una aplicación de línea de negocio no son convincentes en mi opinión. C# o VB.Net con enlace de datos puede ser poderoso y rápido de compilar, pero no tengo claro qué ofrecería eso más allá de tu aplicación actual que ya es 'muy confiable'. El uso de SQL Server como back-end elimina muchas de las objeciones (rendimiento, escalabilidad, etc.) planteadas sobre el uso de Access para una aplicación crítica para el negocio, de hecho tenemos front-ends de acceso a bases de datos de SQL Server con cientos de usuarios simultáneos que trabaja bien.

Me ahorro el .Net para la siguiente aplicación .....