2010-02-19 14 views
11

Antecedentes¿Cómo construyo algo cuando sé que me equivocaré?

tengo un proyecto personal que he estado tratando de construir durante unos 5 años. En esencia, es un juego en línea: una aplicación web. No es un "generador de dinero", simplemente es algo que realmente quiero construir, por lo que es muy poco probable encontrar el financiamiento para contratar un equipo calificado.

He creado dos prototipos totalmente funcionales a lo largo de los años, ambos exitosos desde una perspectiva de prueba de concepto/usuario, pero ambos fallas espectaculares desde una perspectiva arquitectónica; el código era un desastre, no se podía mantener ni desarrollar, y tuvo que descartarse.

Tomó un buen par de años para adquirir las habilidades necesarias para construir el cliente, que es rico/con estado y bastante complejo. Alineé mi carrera y estudios hacia este lado de la brecha del desarrollo. Finalmente, estoy en un punto en el que puedo construir un cliente sofisticado y de arquitectura digna que pueda crecer y no necesite ser expulsado 6 meses después. Hay mucho trabajo por hacer en ese frente, pero al menos sé que puedo hacerlo y hacerlo razonablemente bien. El back-end es otra historia.

Hasta ahora he reconstruido el back-end al menos 11 veces con varias combinaciones de PHP, SQL, Ruby, CouchDB, MongoDB, FriendlyORM, NodeJS, etc. No suelo llegar muy lejos antes de descubrir alguna gran error con mi enfoque y comienzo de nuevo: RPC a REST, relacional a documento impulsado. Soy consciente de que la optimización prematura es la raíz de todo mal, pero la aplicación es muy dependiente de los datos dinámicos y de rápido movimiento. Diseño RESTful API, escalado, fragmentación, almacenamiento en caché, autenticación, replicación: no tengo mucha experiencia con esto, y no puedo esperar ser remotamente decente en el corto plazo. Estas cosas requieren años de estudio y experiencia.

Tiene más sentido encontrar un experto en este campo, pero sin financiación, siento que necesito implementar con éxito otro prototipo para atraer a la persona adecuada. Entonces, tendré que construirlo lo mejor que pueda.

La pregunta

Suponiendo que sin embargo yo construyo, la arquitectura de fondo va a estar mal y tendrá que ser reconstruido, ¿cuál es la mejor manera de proceder con la construcción de "lo suficiente" para continuar desarrollo de la aplicación cliente? Incluso si es desagradable, ¿hay alguna manera de "juntar" un servicio web JSON? Ruby con Sinatra y MongoDB? Django? ¿Hay algún desarrollador de servicios web fuera de la caja? No es necesario un marco web de pila completa ya que no hay capa de presentación, solo datos. Cualquier consejo sería muy apreciado.

+0

@ Franky-D: _ "Soy consciente de que la optimización es la raíz de todo mal" _. ¿Por qué? –

+0

¿Quizás quiso decir la optimización * premature *? – FrustratedWithFormsDesigner

+0

@ Franky-D Es la optimización ** prematura ** que es la raíz de todo mal - vea http://c2.com/cgi/wiki?PrematureOptimization –

Respuesta

2

Mi opinión: Demasiado énfasis en la tecnología y no lo suficiente en sentarse y hacer los diseños adecuados.

  1. Comience con un diseño de alto nivel.
  2. Identifique las diferentes piezas principales implicadas. Dedique un poco de tiempo de calidad para el paso n.º 1 & 2.
  3. Vea qué componentes comerciales se pueden usar para ayudar a implementar las diferentes piezas rápidamente. Considere que más adelante puede arrancar estos componentes para otra cosa (incluida su propia solución).
  4. Revisit # 1 & # 2
  5. Elija una pieza o dos y comience a codificar un prototipo funcional para las piezas involucradas.
  6. Después de haber hecho el trabajo preliminar, comience nuevamente desde el paso n. ° 1 y vea qué ha cambiado para que pueda compensar en consecuencia.
3

No necesita construir ningún tipo de back-end de web para poder continuar con el prototipado de la aplicación cliente. Simplemente haga que la aplicación del cliente llame a las funciones que devuelven datos ficticios.

+0

El punto más grande que Earwicker insinúa es el diseño modular. Si divide su proyecto en secciones claramente definidas y define completamente las interfaces entre ellas, entonces su proyecto se convertirá en una serie de "bloques de construcción".Si necesita reestructurar su backend, solo está rehaciendo un solo "bloque" y, siempre que se ajuste a la misma interfaz, los demás componentes ni siquiera tendrán que saber que algo ha cambiado. Volver a trabajar o volver a escribir el código es mucho más fácil en componentes pequeños. – bta

7

Haz que trabaje despacio, primero, con código limpio y modular.

Si es modular, puede reemplazar una capa o dos sin tener que desechar todo.

Si bien proporcionan modularidad, tenga cuidado con los servicios web, incluso REST, ya que tienden a ser lentos; hay mucha sobrecarga con cada conexión, por ejemplo.

+8

+1. Primero hazlo correr. Entonces hazlo correcto. Entonces hazlo rápido. * En ese orden. * –

+0

Wayne podría haberlo dicho mejor que yo. :-) –

5

Construir una aplicación grande y complicada de este tipo, especialmente una con muchas interdependencias, condiciones específicas del estado y divisiones cliente-servidor que pueden requerir el uso de idiomas incompatibles, es desalentador sin importar cómo se acerque. Según mi experiencia con otros proyectos de este tipo, estás destinado a fallar en tu primer intento, sin importar cuán cuidadoso seas. El truco es abrazar el fracaso como un paso inevitable en el camino hacia el éxito y no preocuparse por cada pequeña cosa a medida que desarrolla la aplicación.

La primera misión debe ser "trabajar" con la menor cantidad de programación posible, simplemente para obtener el efecto que está buscando, aunque sea muy aproximado, para que pueda ver cómo encaja todo. Si puede descomponer el gran problema en una serie de pequeños problemas para resolver, puede encontrar el éxito con un elemento y eso puede ser motivador para abordar problemas más grandes o diferentes.

Una estrategia útil a emplear es mantener los elementos de la aplicación ligeramente acoplados, para evitar la interdependencia excepto donde sea estrictamente necesario, para que pueda intercambiar o realizar mejoras en partes del todo sin tener una cascada de cambios consecuentes. Por ejemplo, su código de red podría ser capaz de transmitir cambios de estado entre el cliente y el servidor sin preocuparse por la naturaleza de los estados, pero su código de administración estatal no tendría que importar cómo se transmiten los estados, solo eso será.

También es útil tener un control sobre la arquitectura general de la aplicación para que no se pierda entre las malas hierbas. Desde una perspectiva de alto nivel, es posible que desee familiarizarse con el Design Patterns básico que puede ayudarlo a organizar un lío de código impenetrable en algo simple, modular y fácil de construir.

Sobre el tema de frameworks e idiomas, yo diría que evite cambiar tan a menudo. Si bien es educativo explorar un nuevo idioma para ver qué características pueden ayudar con su problema en particular, probablemente sea más productivo si se apega a uno, incluso si puede ser difícil lograr algunas cosas, porque se vuelve más efectivo con él. , mejorando su enfoque para adaptarse mejor al idioma. Mientras que Haskell podría ser un mejor ajuste para algunos problemas, incluso el antiguo PHP simple puede ser entrenado para hacer exactamente las mismas cosas con suficiente determinación.

Existe la tentación de probar cosas nuevas, ampliar el alcance del trabajo para que sea "correcto", crear nuevas funcionalidades según se te ocurra, pero para mantener el proyecto bajo control, tendrá mantener la disciplina para evitar estas actividades costosas y de distracción que a menudo, tomadas objetivamente, solo son vuelos de lujo o prematuros dado el estado general del proyecto.

Para responder específicamente a su pregunta, compártala en el marco con el que está más familiarizado, dónde se encuentran sus puntos fuertes y hágalo en incrementos más pequeños que produzcan resultados útiles.Tal vez ese sea el motor de visualización del cliente, o el componente de red, o las transiciones de estado de back-end, pero sea lo que sea, debe tenerlo en un estado "suficientemente bueno" para comenzar a conectarle otros componentes.

Resolver diez pequeños problemas puede ser tedioso y lento, pero es mucho más fácil que resolver uno gigantesco.

2

Johnny G casi lo clavó con su comentario a su pregunta original. La situación que describes incluso le sucede a la fortuna 500, créelo o no. Debe planear a fondo qué es lo que está intentando construir/lograr con su proyecto antes de elegir y desechar las tecnologías más nuevas y más frescas cada tres meses.

Creo que este artículo de Wired, "aprender a dejar ir" sobre el fracaso de duke nukem para siempre para ser enviado, lo explicará mejor que yo.

http://www.wired.com/magazine/2009/12/fail_duke_nukem/

(que también es un muy divertido/informativos leer independientemente)

0

Si su proyecto chupa y nadie lo usa, lo que va a importar lo optimizado que es? Obtenga una versión de extremo a extremo funcionando, estoy seguro de que descubrirá muchos otros problemas que aún no ha considerado, que probablemente sean de mayor importancia.

0

Me parece que hay una sola manera de completar un proyecto personal.

Código inteligente primero, plan más adelante. Desarrolla ese prototipo, pero diseñalo para que cualquier pieza individual pueda ser removida y reemplazada por otra pieza.

Si su elección de idioma es ruby, por ejemplo, construya sus clases para tener una interfaz bien definida que nunca romperá. Preocúpese de que cada función "haga" lo correcto, sin importarle realmente cómo funciona.

Luego, regrese a su prototipo construido modularmente, y repare una pieza a la vez.

Cuestiones relacionadas