¿Cómo organizar un proyecto unipersonal? [cerrado]

De vez en cuando (lea: casi todos los días) se me ocurre una nueva idea, comienzo un nuevo proyecto en mi editor / IDE favorito, comienzo a codificar y al día siguiente lo borro y empiezo algo nuevo. He estado programando durante unos seis años y en esos seis años solo he completado un proyecto muy pequeño (un widget de Tablero para Pastebin.com). Aunque esto podría ser genial para aprender codificación, realmente quiero completar algo.

¿Qué cosas debo hacer antes, mientras y después de la codificación real? ¿Cuáles son los buenos recursos que me enseñan a organizar proyectos de un solo hombre?

Si es importante, quiero hacer desarrollo web o Mac.

Creo que el verdadero problema, a largo plazo, es la motivación, más que la organización.

1. Encuentra usuarios y habla con ellos. Vea su proyecto como una especie de regalo (o producto vendible) para esas personas. (Alguien con quien intercambiar ideas también es genial, incluso si en realidad no desarrollan código con usted).

   Tener esa motivación social será mucho más poderoso para mantener el proyecto interesante a largo plazo que la mera curiosidad personal.

2. Su objetivo debe ser pequeños trozos de funcionalidad útil. Póngalo en SourceForge o GitHub, y trate el proyecto como algo que necesita una posibilidad de supervivencia incluso si un meteorito lo golpea de repente.

   Esto lleva a más lanzamientos (lo que significa más comentarios y entusiasmo de los usuarios) y también a una mayor probabilidad de que otra persona decida contribuir al proyecto.

3. Elige un objetivo de aprendizaje específico para ti. ¿Qué tecnología o técnica te ayuda a aprender el proyecto? Si resulta que la técnica no es adecuada para el área del problema, ¿le interesará lo suficiente como para terminar al menos la versión 1.0 antes de dejarla de lado?

   Ejemplos de tales objetivos incluyen escribir analizadores, protocolos de red, aspectos de la IA del juego, marcos de aprendizaje o herramientas, un nuevo idioma, etc.

El peor de los casos significa perderse los tres, donde repetidamente realiza una "reescritura masiva" de una herramienta nunca lanzada que involucra código que no encuentra interesante para personas que no está seguro de que existan.

Cuando se le ocurra una idea para un nuevo proyecto mientras trabaja en un proyecto, solo anótelo en una lista de ideas de proyectos. Luego regrese al proyecto actual. Si el proyecto vale la pena, no te dejes distraer por un nuevo proyecto. Utilice los siguientes pasos solo si es una idea excelente.

Antes de comenzar nuestro proyecto, planifíquelo. Que va a hacer ¿Qué tan difícil será hacer? ¿Qué son los conocimientos y las incógnitas? ¿Qué es probable que salga mal? ¿Cuánto tiempo tardará? [Ahora puede decidir si continuar o detenerse ahora.] Mantenga su plan. [Si está trabajando en un proyecto, deje de lado el nuevo proyecto y continúe con el otro proyecto original.]

Cuando comience su proyecto, configúrelo como un proyecto separado en su IDE. (Por lo tanto, no necesita eliminarlo para comenzar su próximo proyecto). Regístrelo en algún software de control de versiones como un nuevo proyecto. (Ahora puede eliminarlo si encuentra que se interpone en el camino de otro proyecto). Verifique su proyecto siempre que lo haga haciendo algo correctamente. (Ahora puede regresar si se desvía).

Haga un seguimiento de los problemas que surgen en su proyecto. Esto se puede hacer con algunos archivos de texto dentro del proyecto. Los archivos como TODO, Changelog, README (pueden incluir errores y problemas conocidos) pueden ser apropiados.

Cuando tenga su código funcionando, etiquételo en su control de versiones. Si vale la pena compartirlo, hazlo.

Regrese a su plan y vea qué tan bien lo hizo. Haz un documento de lecciones aprendidas por ti mismo. ¿Qué aprendiste, qué tan bien calculaste? ¿Qué problemas te perdiste? ¿Qué problemas sobrestimaste? Cualquier otra cosa que consideres importante.

Cuando abandonas un proyecto, realiza el proceso de lecciones aprendidas. Agregue una nota sobre por qué abandonó el proyecto.

Revise sus lecciones aprendidas una vez al mes más o menos. A medida que pasa el tiempo, puede aumentar el intervalo entre las revisiones.

Aquí hay un enlace a " Doing Agile en un equipo de uno ". ¡Es una lectura interesante!

Además, es posible que desee considerar por qué las disciplinas de desarrollo de software que hacemos "en el trabajo" son importantes. ¿Solo son importantes si hay 10 personas en el equipo? No, son importantes porque te ayudan a pensar en tu proyecto.

¿Quién es tu público objetivo? (Si eres tú, entonces genial, pero recuerda para qué querías originalmente la aplicación)

Si está haciendo una interfaz de usuario, piense en las necesidades de su audiencia, luego haga algunas maquetas antes de comenzar el desarrollo de la interfaz de usuario.

Si está mirando su lógica de negocios, pruebe TDD o BDD. Piensa en cómo quieres que funcione tu aplicación antes de atacarla. Considere envolverlo en un arnés como Fitnesse o similar. Si desea probar su aplicación, el lugar más fácil para comenzar es al principio .

Dado su comentario, ¡deje de eliminar sus proyectos!

Por lo general, no mantengo proyectos que no estoy desarrollando activamente (o preveo desarrollar activamente en un futuro cercano) en mi computadora, pero los archivos de origen existen en un repositorio SVN y todo (incluidos los archivos de configuración IDE) está respaldado en Un disco duro externo. No responde a su búsqueda, deje de eliminar su trabajo y concéntrese en motivarse.

Si está buscando un repositorio alojado, busque en Google Code, SourceForge, GitHub y BitBucket. Cargue sus archivos, guárdelos en algún lugar y, cuando tenga un interés renovado, retírelos. Aunque puede hacerlos privados, puede hacerlos públicos si no se avergüenza de ellos. Quizás alguien esté interesado en reiniciar su trabajo o aprender de sus ejemplos (especialmente si está utilizando una biblioteca o marco interesante).

Con el tiempo, trabaja en tu motivación. Intenta concentrarte en una cosa a la vez. Es posible que no obtenga la calidad de producción de su código, pero tal vez pueda obtener la calidad de ejemplo o algo que otras personas puedan ver para ver su conjunto de habilidades, conocimiento o para aprender sobre una forma particular de hacer las cosas.

En primer lugar, hay proyectos y proyectos. Si prueba alguna tecnología o biblioteca, o algo más, probablemente cree un proyecto en su IDE, descubra si esto es interesante para usted o no, y luego elimine su proyecto. Está bien, todos hacen esto.

Otro tipo de proyecto es el software / sitios / etc. reales, que es el negocio, donde esos 'proyectos', archivos, programas son solo herramientas, y desarrollar cosas tan complejas requiere motivación y los objetivos :

• lo que desarrollas (sitio web / editor de texto / aplicación móvil / ...)
• para qué lo necesita (ganar dinero, adquirir alguna tecnología nueva / contribuir al código abierto / ...)
• cuándo lo haría (cuánto tiempo dedicará su proyecto, cuánto tiempo planea hacer eso)

Lo que desarrolles debería ser nuevo . Si desea crear solo otro editor de texto porque cree que falta alguna característica que demanda, probablemente no necesite hacerlo. Hay cientos de herramientas de código abierto, contribuyen a una de ellas.

Incluso si crea una pequeña herramienta de un solo uso como un script, debe indicar las cosas enumeradas, sería más fácil resolver el problema en sí.

Si está atascado en escribir código (por ejemplo, reescribir masivamente su código) probablemente no tenga la experiencia suficiente para hacerlo. Tome un buen libro sobre ingeniería de software, su plataforma (mac / web / etc.), lea el código escrito por desarrolladores más experimentados que hace cosas similares. Hay muchos lugares para hacerlo ahora (github, código de google, blogs de programación, stackoverflow).

No intente resolver un problema muy complejo (por ejemplo, escribir un compilador o un sistema operativo) desde cero, primero descomponerlo en tareas más pequeñas, generalmente, alguien ya ha creado bibliotecas que lo ayudan a resolver su problema.

¿Ha considerado preguntarle a un ser querido qué es lo que realmente necesita para una herramienta web y luego, realmente, hacerlo para él o ella?

Esto debería proporcionar la motivación para terminar y entregar, que es la parte difícil de esto. También obtienes el beneficio de apoyar y mantener la aplicación si es útil para tu ser querido. Si no es útil, puede aprender de la experiencia qué puede salir mal.