He leído muchos libros para varios lenguajes de programación, Java, Python, C, etc. Entiendo y conozco todos los conceptos básicos de los lenguajes y entiendo algoritmos y estructuras de datos. (Equivalente a decir dos años de clases de informática)

PERO, todavía no puedo entender cómo escribir un programa que haga algo útil.

¡Todos los libros de programación le muestran cómo escribir el idioma, pero NO cómo usarlo! Los ejemplos de programación son muy básicos, como crear un catálogo de tarjetas para una biblioteca o un juego simple o usar algoritmos, etc. ¡No le muestran cómo desarrollar programas complejos que realmente hagan algo útil!

He visto programas de código abierto en SourceForge , pero no tienen mucho sentido para mí. Hay cientos de archivos en cada programa y miles de líneas de código. ¿Pero cómo aprendo cómo hacer esto? No hay nada en ningún libro que pueda comprar en Amazon que me brinde las herramientas para escribir cualquiera de estos programas.

¿Cómo pasas de leer Introducción a Java o Python de programación, o Lenguaje de programación C, etc. para poder decir realmente, tengo una idea para el programa X? ¿Es así como hago para desarrollarlo?

Parece que hay mucho más involucrado en escribir un programa de lo que puedes aprender en un libro o en una clase. Siento que hay algo.

¿Cómo puedo ser puesto en el camino correcto?

Construir programas más complejos viene con experiencia. Cuando programé por primera vez, pensé que me iba bien si tenía más de 25 líneas de largo (y tenía que usar la barra de desplazamiento). Ahora escribo cientos de líneas al día durante años en la misma aplicación de proyecto.

Puede encontrar esta página interesante "Enseñe a programar en diez años" http://norvig.com/21-days.html

Por cierto: es muy difícil iniciar un programa. Un escritor podría llamarlo "bloque de escritores". En cambio, le sugiero que comience a escribir código y lo mejore. No tenga miedo de eliminar secciones grandes que no hacen lo que necesita. Comienza de nuevo, esta vez escribirás con una mejor idea de lo que estás haciendo. Comience de nuevo y verá que no necesitaba la mitad de lo que escribió la última vez. Cuando un autor escribe una historia, lleva mucho tiempo, mucha escritura y reescritura, etc. muchas críticas y comentarios, y solo termina cuando tiene que ser publicado (publicado)

Siempre estuve abrumado por proyectos muy grandes también, como los que encuentras en SourceForge o GitHub. Me preguntaba cómo alguien, o incluso un equipo, podría entender lo que estaba sucediendo en 10 o 100 archivos, con miles y miles de líneas de código.

Nadie hace. Al menos inicialmente.

Los proyectos son cosas orgánicas. Lo que comienza como una idea realmente simple, puede expandirse rápidamente en un trabajo masivo. Esta es, creo, la razón principal para el desarrollo iterativo en lugar del clásico enfoque en cascada.

Piensa en construir un auto. Si bien parece bastante simple desde el exterior, profundizando incluso una pequeña forma en que descubres que hay una gran cantidad de consideraciones, compensaciones y casos inocentes que deben manejarse.

Ejemplo:

En el caso de un proyecto semi-grande, a menudo comienza siendo pequeño. "Quiero construir un servidor de caché". Así que pasas unos días hackeando y llegas a algo que funciona, pero que podría mejorarse dramáticamente. Entonces agregas el concepto de subprocesamiento.

Luego te encuentras con problemas de concurrencia debido a ese subproceso. Entonces arreglas cambiando a estructuras de datos concurrentes.

Ahora el proceso se ha ralentizado. Por lo tanto, cambia las estructuras de datos concurrentes a las normales, pero proporciona mecanismos de bloqueo para la sincronización.

Todo parece estar funcionando bien, excepto que los usuarios comienzan a quejarse de que las operaciones no son atómicas y que los datos se están corrompiendo.

Entonces agrega algunas operaciones atómicas clásicas, como incrementar y guardar. Esto funciona y tus usuarios están contentos. Pero alguien abre un ticket preguntando si es posible hacer operaciones de lista.

Así que pasas una o dos semanas construyendo esa característica. Aproximadamente en este momento, un amigo decide ayudarte. Trabajan juntos, lo completan y lo liberan.

Dos entradas abiertas. Hay un error en el procesamiento de la lista, y hay algunos casos raros que se estancan.

Tu amigo trabaja en el error de procesamiento de la lista, mientras abordas el punto muerto. Te das cuenta de que debe producirse una reescritura bastante significativa en las operaciones atómicas.

... y así continúa.

Esto parece bastante típico de cómo crece un proyecto. Más o menos 10 archivos han crecido a 20 en un par de semanas. Se agregan nuevas características que no estaban separadas del plan original. Se agregan correcciones de errores complicadas que hacen que el código crezca de forma poco natural.

Mi consejo:

No te abrumes. Si tiene una idea, implemente piezas de funcionalidad. Si vale la pena seguir después de eso, agregue poco a poco. Deja que tu proyecto crezca naturalmente.

Incluso el programa más grande comienza con una idea y se escribe una línea a la vez.

La mejor (quizás la única) forma de aprender a escribir programas del mundo real es comenzar a hacerlo. Cuando tienes problemas, buscas en la web o pides aquí soluciones para esos problemas. Eventualmente, ganarás experiencia y tendrás que preguntar con menos frecuencia.

Sin embargo, hay algunas cosas que debe tener en cuenta desde el principio:

• Casi ninguna gran aplicación está escrita completamente desde cero en estos días. Puede hacer mucho más en un tiempo mucho más corto si usa bibliotecas y marcos existentes de alta calidad. Comenzar con esto a menudo se siente bastante frustrante y requiere más trabajo que hacerlo usted mismo, pero eso casi nunca es cierto.
• Pensar cuidadosamente sobre cómo estructurar su programa (cómo diseñarlo) es muy importante una vez que sus programas crecen. Dedique algo de tiempo a eso y lea algunos libros sobre diseño (recomendaría especialmente "Clean Code") e ingeniería de software, así como sobre conceptos básicos técnicos.

De lo que estás hablando es de más ingeniería de software que programación. Es un poco de arquitectura, un poco de "mejores prácticas" y "patrones de diseño", un poco de trabajo con otros. Si bien hay libros que pueden ayudar, la mayor parte proviene de la experiencia. Nadie comienza a escribir, digamos, Microsoft Word.

Piense en un gran programa "real" que le gustaría escribir. Ahora piense en las diversas piezas que necesita construir para que funcione de la manera que desee. Por ejemplo, en un juego moderno en primera persona, necesitará un motor de gráficos en 3D, IA que no sea un personaje del jugador, un módulo de música / sonido, un motor de física y un módulo de nivel superior que haga cumplir las reglas del juego (sabe el "mapa", cómo interactúan los diversos personajes, etc.). Y luego está la obra de arte y el diseño de personajes y la música, ninguno de los cuales es código, pero son necesarios para que el juego se complete.

Ahora: ¿Cuál de estos construirás tú mismo y cuál obtendrás en otro lugar? La mayoría de los proyectos de software grandes no se programan desde cero. Tal vez utilizará un motor 3D y un módulo de música / sonido listos para usar y programará solo las cosas que hacen que su juego sea único. De acuerdo, debe averiguar qué módulos de terceros va a utilizar, lo que implicará factores como el costo, los idiomas con los que trabajan, las características que tienen, cómo está diseñado su API (es decir, qué tan completo está es decir, qué tan bien encaja con su estilo de programación personal, etc.). Tal vez escribirá "pruebas de concepto" o programas de prueba utilizando uno o dos candidatos para los diversos módulos de terceros para asegurarse de que harán todo lo que necesita y que sea fácil de usar.

Además, incluso el código que desea escribir puede ser un trabajo demasiado grande para que lo complete usted solo en el plazo que tiene en mente. ¿Cuántos otros programadores necesitas para trabajar en el proyecto? ¿Cómo va a dividir el trabajo? ¿Cómo se diseñarán los distintos módulos para que encajen todos aunque hayan sido escritos por diferentes personas? ¿Cómo van a trabajar todos en el mismo código fuente sin eliminar los cambios de los demás (respuesta: control de versiones, que es extremadamente útil cuando se trabaja solo, pero indispensable cuando se trabaja con otros).

Una vez que haya descubierto qué módulos desea escribir internamente, realizará el mismo proceso. Calcule las piezas de cada módulo, cómo deben encajar y cuáles escribirá usted mismo y cuáles obtendrá en otro lugar. Continúa desglosando las cosas hasta que cada pieza sea lo suficientemente pequeña como para que la tengas en mente, para que digas: "¡sí, podría escribir eso!" Y luego hazlo. Mientras lo hace, se encontrará con obstáculos imprevistos en la forma en que las diferentes partes de su programa encajan entre sí. Estos serán frustrantes, pero son oportunidades para que usted aprenda más sobre su oficio, y deben verse de esa manera.

Inicialmente, solo podrá mantener en su mente piezas muy pequeñas de su programa, por ejemplo, funciones individuales, por lo que tendrá que desglosar muchas cosas antes de comenzar a codificar. A medida que gane experiencia, pensará en funciones en lugar de tener que pensar en funciones y comenzar a pensar en objetos. Y luego pensarás en objetos y pensarás en módulos más grandes. Finalmente, estará pensando en módulos y pensando en programas completos, grandes y reales.

Y luego descubrirás que todavía tienes mucho que aprender ... pero así sigue. Si, como programador, alguna vez deja de aprender, está obsoleto y será reemplazado por un modelo más nuevo.

De todos modos, no tengas miedo y no te preocupes si esto suena ... horrible o imposible y realmente no quieres ser un programador después de todo. No es para todos. Me encanta la música y los postres, y puedo tocar un poco las teclas y cocinar algunos platos, pero no estoy dispuesto a dedicar el tiempo necesario para convertirme en un gran músico o un maestro de cocina.

Si resulta que no desea ser un programador que escribe aplicaciones de escritorio grandes y reales, existen otros tipos de trabajos de programación. Podría convertirse en un programador incorporado, por ejemplo. Hay desafíos definidos e interesantes involucrados en la escritura de programas integrados, y usted está haciendo un trabajo útil, pero generalmente los programas son bastante más pequeños que las aplicaciones de escritorio. O podrías escribir aplicaciones web. En la Web, es fácil unir pequeños trozos de funcionalidad, por lo que podría escribir (por ejemplo) un sistema de comentarios en la Web y sería útil incluso si no se trata de una aplicación web completa. También es fácil mejorar gradualmente las cosas en la Web, por lo que puede comenzar con (por ejemplo) un cliente de correo web básico y, con el tiempo, evolucionar a algo como Gmail. (Pero no hagas eso, porque entonces estarás compitiendo con Gmail).

Si no quiere ser un programador, pero aún quiere trabajar con computadoras, posiblemente podría ingresar a TI u otro campo técnico. En estos casos, conocer tanta programación como ya lo hace es muy útil, porque sus pares pueden no tener tanto. O, ya sabes, conviértete en músico si eso te atrae, porque (como la mayoría de los campos) involucra computadoras hoy en día. Escriba pequeños programas que manipulen archivos de audio o MIDI de varias maneras inteligentes, lo que lo convierte en un mejor músico. Descubrirá que cualquier habilidad de programación que tenga se puede aplicar en muchos campos para mejorar su trabajo.

No sabrá cómo programar a menos que se enfrente a una tarea real. Ninguna teoría reemplazaría una simple tarea del mundo real. Antes de comenzar a trabajar en escenarios de rw, estaba leyendo ingenuamente muchos libros, con todos los ejemplos, pero cuando me enfrenté a un problema real, simplemente no pude reunir todo mi conocimiento teórico para completar la tarea. Si es principiante, le recomiendo que obtenga las tareas desde cualquier lugar que pueda. No pienses que son inútiles a menos que los hayas resuelto. Como primer paso, intente resolver problemas de estructura de datos, como ordenar una lista vinculada, realizar DFS, BFS en árboles, gráficos, etc. No solo mejorará sus habilidades de codificación, sino que lo que es más importante, mejorará sus habilidades analíticas y algo , lo que confía en mí es un conocimiento valioso. Entonces, cuando sabrás que puedes rockear con punteros, recursión,

Línea de fondo. Se trata de practicar. Solo sigue cavando y codifica, codifica, codifica.

Comience con los juegos de computadora, como todos los demás. Un buen juego es un desafío tanto de programación como de diseño, necesita una cuidadosa reflexión sobre la estructura interna y utiliza las bibliotecas del sistema de maneras que enseñan mucho, pero no tiende a romper cosas y no requiere una "buena razón con un buen resultado". como lo hace el software "útil" real.

La regla general es que después de escribir suficientes cosas, inevitablemente sucederá algún tipo de iluminación.

Un buen punto para comenzar (si te sientes como C) es http://gamedev.net/ , especialmente http://nehe.gamedev.net/ . También hay muchos otros puntos buenos para comenzar: D

Estás viendo todo el gran programa y parece imposible. Pero todo se compone de pequeños programas estúpidos como los que estás diciendo "no hagas nada útil".

Lo que necesita es experiencia desglosando enormes tareas complejas en pequeñas tareas simples. Esa es la raíz de toda la programación. El resto es solo semántica.

Al igual que conducir o cocinar, la programación es algo que se aprende haciendo. La práctica es insustituible.

Si los ejemplos de libros de texto ya son demasiado básicos para usted, ¡eso es genial! Es hora de moverse por algo más complejo, y ya puede descubrir algunos ejercicios desafiantes para usted.

O, si tiene una idea específica en mente, divídala en pedazos. Resuelva primero un pequeño subconjunto del problema. Luego expandir. Cuando la integración del nuevo código a su código existente se vuelve difícil, entonces rediseña todo.

Escribe un guión de 200 líneas. Entonces comienza a mejorarlo.

Featuritis lo llevará a 100 archivos fuente y varios cientos de KLOC en muy poco tiempo :)

"¡No le muestran cómo desarrollar programas complejos que realmente hagan algo útil!"

Sin una definición de "útil", realmente no hay mucho que podamos hacer para llevarlo por el camino "correcto".

No sabemos cómo está fallando o qué está mal. No podemos decir en qué pista estás.

De alguna manera, tienes una idea en tu cabeza de que no te estás comunicando.

El software - programación - se trata de sacar una noción de tu cabeza a algún idioma (Python, Java, inglés, lo que sea).

Un paso importante en la programación (y hacer preguntas) es definir sus términos. ¿Qué quieres decir con "hacer algo útil"? Sea muy claro, muy completo y muy preciso.

Me hacen esta pregunta todo el tiempo, por ejemplo, cómo comenzar. Es simple de verdad. Aquí hay un paso a paso.

1. Ven con una idea. Parece que ya tienes eso.
2. Simplifique su idea a su núcleo básico, algo que cree que podría abordar
3. Coloque la interfaz de usuario en un trozo de papel o servilleta, lo que sea.
4. Pruebe y diseñe la IU en su entorno de desarrollo.
5. Si encuentra dificultades, google, google, google, haga preguntas sobre stackoverflow, use la basura de los recursos de internet para obtener ayuda. Pídale a amigos y compañeros de trabajo que sean programadores que lo ayuden con situaciones específicas. Regrese al paso 4.
6. Comience a escribir la lógica de su aplicación. Si tiene dificultades, vaya al paso anterior e intente nuevamente.
7. Muy pronto, tendrás algo funcionando pronto.

Crea algo pequeño. No te preocupes, tu programa será el número 1000 haciendo eso.

Algunas ideas:

• un reloj (primero digital, luego analógico),
• creador automático de labirynth,
• visualizador de estructura de directorio,
• álbum mp3 lister,
• etc.

Al elegir la plataforma, las herramientas son parte de la tarea.

Ok, comencemos con su idea para el programa X que hace algo útil y desglosémosla:

• Utilice software de papel, mapas mentales o diagramas para diseñar el flujo / flujo lógico (s) del programa.

• Como recién está comenzando, elija UNO de esos elementos (preferiblemente cerca del principio) y desglose aún más.

• Escriba su código para eso primero y úselo para construir sobre

¿El programa X necesita abrir un archivo, manipularlo y crear un archivo de salida? Vea si puede abrir y hacer eco del archivo como primer paso. ¿Quieres una buena interfaz de usuario? Cree uno que pueda ejecutar su programa de eco de archivos, etc. No solo creará código que puede usar en su complejo programa paso a paso, sino que también desarrollará su conocimiento del idioma al tener que buscar y buscar información.

Como dice el refrán: Gnome no se construyó en un día :-)

(ya se respondió anteriormente en los comentarios. Se sugirió enviar esto como respuesta después de que la pregunta se reabrió)

Comienzas con un problema, algo que quieres resolver, sin importar cuán complejo creas que es. Luego tomas este problema y lo escribes y comienzas a dividirlo en problemas más pequeños. Luego, desglosas esos problemas más pequeños, etc., hasta que tienes algo primitivo que ya sabes cómo resolver o puedes hacerlo con un poco de esfuerzo. Empiezas a codificar cada una de estas piezas y las organizas en diferentes funciones o diferentes clases, etc.

Luego trabajas en el siguiente subproblema. Mientras trabaja en cada problema, puede escribir pequeños casos de prueba y, de hecho, ver que su progreso se materializa. Siempre habrá desafíos en el camino, pero en ningún momento lo veremos como algo demasiado colosal para siquiera abordarlo (lo que parece estar lidiando ahora). Esto es cierto para la programación y muchos de los desafíos de la vida. La clave es romperlo.

En cuanto a qué hacer, la idea. Puede intentar inventar algo nuevo, pero también puede tomar algo que le apasione y que ya exista, pero que sea mejor o incluso diferente. Actualmente estoy escribiendo una aplicación de afinador de guitarra para Android en mi tiempo libre. Sé que ya existen muchas otras aplicaciones para afinar la guitarra, pero pensé que este sería un proyecto divertido y desafiante, así que lo asumí. Al principio parecía casi imposible, pero después de dividir el problema en pasos más pequeños, en realidad se está resolviendo muy bien. Divide y conquista y sé persistente con tus objetivos.

Una de las cosas más difíciles de hacer cuando eres un principiante es establecer objetivos realistas para lo que debe contener un ejercicio de "cómo puedo mejorar" en tu nivel actual.

Por lo tanto, le sugiero que elija practicar la resolución de ejercicios pequeños y dados, porque la capacidad de terminar un programa de acuerdo con una especificación dada es algo muy valioso para todos los que programan para ganarse la vida.

Le sugiero que eche un vistazo más de cerca a http://projecteuler.net/, que tiene muchos ejercicios y un sistema automatizado de "verificación de respuesta", que le permite trabajar a su propio ritmo. Los ejercicios están bien redactados, pero pueden requerir que pienses. Algunos incluso pueden requerir que pienses mucho, pero incluso si no los resuelves, te enseñarán algo útil.

La redacción completa del problema 1 es:

Si enumeramos todos los números naturales por debajo de 10 que son múltiplos de 3 o 5, obtenemos 3, 5, 6 y 9. La suma de estos múltiplos es 23.

Encuentra la suma de todos los múltiplos de 3 o 5 por debajo de 1000.

¿Crees que podrías resolver esto? ¡Entonces hacerlo!

¡Necesitas experiencia en el mundo real! . ¡Ningún libro puede enseñarte eso!

Tienes que aprender a leer el código de otros, cómo mantenerlo, cómo odiarlos (tanto el código como el codificador), cómo mejorarlo, cómo pensar que puedes hacerlo mejor y unos meses después gritar en voz alta . mataré a quien haya escrito este código !!! ¡Solo para descubrir en el control de la versión de origen que eras tú!

Tienes que entender que los libros son muy específicos y algunas veces para personas que ya saben cómo desarrollar software.

Así que te sugiero que encuentres un trabajo de programación. Si es necesario, solicite el nivel de entrada más básico. Probablemente no ganes tanto como crees que te mereces, pero usa unos meses para aprender cómo se desarrolla el software en el mundo real (y no siempre es tan perfecto y con todas esas hermosas mejores prácticas que leemos en la web , muchas veces, la calidad del código es muy baja, dependiendo de dónde trabaje, pero eso es parte de la experiencia)

Continúe leyendo sus libros, lo descubrirá, cada año comprende un poco más (o de manera diferente) el mismo tema, porque puede verlo con la experiencia.

Si logras conseguir un trabajo con desarrolladores talentosos, mucho mejor. Aprende de ellos, no tengas miedo de cometer errores.

Hasta que tenga que arreglar su primer error urgente de producción en vivo, ¡no sabrá qué es el error de software!

:)

Pruebe un proyecto de código abierto, vea si puede encajar. Comience descargando el código fuente y vea si puede recoger algunos boletos

Cuando quiero aprender un nuevo idioma, generalmente trato de implementar un gráfico fractal. De esa manera, tendrá comentarios inmediatos sobre si funciona y es muy gratificante. Y hay muchas maneras de mejorar un fractal. La implementación ingenua de mandelbrot es lenta como el infierno.

No es muy útil, pero aprendes mucho y es hermoso de ver.

La programación se trata de la resolución de problemas y la comunicación, no de escribir mucho código. El código es solo una necesidad, por lo general, debe intentar escribir menos código, no más.

Si no sabe por dónde empezar, ¡tal vez simplemente no tenga ningún problema!

Mire Linux y otros sistemas similares a Unix: todos consisten en muchas aplicaciones pequeñas que solo hacen una cosa, pero lo hacen bien .

Cuando necesitaba un script para encontrar 10 archivos más grandes en una carpeta en mi computadora, no estaba leyendo libros. Simplemente busqué en Google y usé una de las soluciones existentes. ¿Escribí algún código? - No. ¿El problema está resuelto? - Si. ¿Es útil este programa de una línea? - Diablos sí.

Los programas con miles de líneas de código generalmente son escritos por más de un programador. No podrá escribir sistemas operativos completos solo y no es necesario. También suelen utilizar trucos como el control de versiones y las pruebas unitarias .

Divide y conquistaras.

Es tan simple o difícil como eso.

Cuando comencé a programar, me encantaron los juegos de computadora. Así que comencé a escribir mis propios juegos, tan pronto como tuve herramientas a mano para hacerlo.

Naturalmente, mi primer juego fue una aventura de texto. Del mismo modo, podría comenzar con un cuestionario o algo, o algún tipo de juego de adivinanzas.

Además, puede comenzar con algo, como una máquina tragamonedas (realmente no necesita las animaciones, ni siquiera las imágenes. Solo use A = manzana, L = limón, S = inicio, P = Ciruela, etc.).

Esto le enseñará los conceptos básicos para manejar algunas entradas del usuario, mantener el estado del juego y generar resultados en consecuencia.

Me dirigí por este camino bastante lejos. Progresivamente aprendí cómo leer el estado del teclado o el mouse, cómo usar el código de gráficos. Aprendí más sobre el lenguaje en sí (comencé con PASCAL) y lo usé para mejorar mis juegos existentes o simplemente comencé algo nuevo.

Creo que los juegos son realmente geniales para aprender programación. Incluso con poca experiencia, puede crear pequeñas cosas que le brinden pequeños momentos de orgullo. Porque creas algo, eso es divertido. Crear aplicaciones reales no tiene sentido, porque se necesita mucho trabajo para crear algo, lo que es realmente útil, mientras que es sorprendentemente simple crear un juego pequeño, que resulta adictivo.

Es posible que desee utilizar un lenguaje educativo (en mi caso, esto era PASCAL y, en retrospectiva, creo que resultó ser una muy buena opción). Muchos de ellos están destinados específicamente a crear juegos y cosas por el estilo.

Crear aplicaciones es más que solo crear algoritmos. Debe diseñar características, debe organizar y estructurar su código en diferentes capas y módulos. A diferencia de los problemas más bien "atómicos" que se le dan en la universidad, las aplicaciones a veces se desarrollan mejor de manera incremental. Empiezas con algo y le agregas cosas encima. Por lo tanto, ya que tiene algo para comenzar (como lo haría en algunos de los idiomas enumerados en el artículo de wikipedia), se ahorra mucha frustración y comienza a crear algo de inmediato. (Un colega mío comenzó a programar escribiendo mods quake 2). En algún momento, descubrirá las limitaciones de estas herramientas fáciles de usar, pero hasta entonces, tendrá mucha más información y comprensión. Probablemente suficiente

En la universidad, había una clase llamada práctica de programación que básicamente enseñaba esta rampa. Al principio le dieron una interfaz de usuario para una aplicación de compra básica, y tuvo que codificar el backend, el último mes fue Tetris desde cero. Creo que alrededor del 50% de los nuevos estudiantes (sin volver a tomar la clase) fallaron, porque aumentar de pequeño a grande es increíblemente difícil.

Sugeriría uno o más de los siguientes:

• Descargue un proyecto de código abierto y agregue algo. No tiene que ser útil o bueno, pero tendrá que mirar la estructura, lo que le dará una idea de cuán grande se construye el proyecto.

• Simplemente diseñe su proyecto final en papel, con flechas para las dependencias. Si está haciendo una serpiente, puede tener cabeza de serpiente, cola de serpiente, comida, espacio vacío, pared, tablero, dirección actual, etc. Podría ayudarlo a darse cuenta si su proyecto es mucho más grande de lo que piensa.

• Toma un proyecto básico y hazlo cada vez más grande. Probablemente harás muchas refactorizaciones y, con suerte, aprenderás cómo hacer proyectos más pequeños que se puedan agregar fácilmente.

• Si conoce a alguien experimentado, cuénteles su idea para un proyecto y pídales que escriban sus clases + algunos métodos importantes, probablemente les tomará una hora más o menos. De esa forma, puede completar los métodos y siempre saber lo que debe hacer a continuación.

Finalmente, hagas lo que hagas, probablemente deberías usar un patrón de diseño básico MVC (Modelo, Vista, Controlador). Sin entrar en muchos detalles, coloque su vista (UI) en las clases 1+, su controlador (Entrada, salida, etc.) en las clases 1+, y su Modelo (Lógica, Datos, básicamente todo lo demás) en varias clases. Es una manera fácil de obtener una organización básica.

Recuerda, este paso es difícil. Es cierto que algunas personas simplemente no pueden programar, pero probablemente estás atrapado en esta etapa. ¡Buena suerte!

Primero, ya está cumpliendo los requisitos previos al tomar clases, leer material de referencia, mirar proyectos de código abierto y mantener la curiosidad con las preguntas. Hago hincapié en esto porque personalmente me he encontrado con preguntas similares antes de que la persona haya hecho algún trabajo de piernas por su parte (específicamente, personas que eluden las clases y esperan tomar atajos). Ahora, recuerdo cuando teníamos laboratorios sobre máquinas Turing y cómo en ese momento sentí que no era una programación real. Estas son las experiencias que mantendrá que cualquiera que tome atajos se saltee.

• Registrarse para proyectos de estudiantes. Me involucré con (CSUA) un grupo de estudiantes de ideas afines para construir un juego para el stand de carnaval en mi último año. Si continúa disfrutando y cree que quiere expandir su participación, realmente aproveche los recursos. Infórmese sobre proyectos, hable con sus compañeros de clase, sus profesores y obtenga una pasantía.

• Siéntate con un programador experimentado. Ha habido aproximadamente tres veces en mi historia cuando vi el programa de otra persona que fue realmente inspirador. Para ellos, solo estaban escribiendo código y pensando en voz alta. Sin exagerar, sentí que absorbía más escucharlos que años solo. Si encuentras más, eres mucho más rico. Tenemos la suerte de estar en una época en la que podemos ver videos, inspeccionar repositorios completos de fuentes y buscar instantáneamente una gran tienda en línea de conocimiento. No es un sustituto de la experiencia en persona, pero en ausencia de un mentor es una mejora dramática sobre el material tradicional. Sin embargo, mirar el código sin formato de otros por sí solo puede no conducir a nada. Querrá tener algo en mente y un buen depurador para entrar en la lógica. Uno de mis mejores momentos fue hacer un mod Quake y no fue el mod en sí lo que tuvo algo memorable. Estaba viendo la lógica del juego de Carmack. El mod fue solo una razón para que me sumergiera.

• Practique explicando y respondiendo preguntas formuladas por su compañero de laboratorio. Voluntario para ayudar a enseñar. Tal vez forme un grupo de estudio y requiera que cada miembro se convierta en un experto en un tema de clase. Luego asar a esa persona y hacer que te asen a la parrilla. Cuando se vea obligado a responder preguntas, estará obligado a aprender las respuestas usted mismo. Cuando puede explicar los conceptos claramente a otros, ha enriquecido su propia comprensión hasta el punto en que puede transmitirla fuera de un libro y sus pensamientos.

• Por último, no tengas miedo de aprender por las malas, ensuciarse las manos, cometer errores. Esto también se puede llamar experiencia. Como un ejemplo más práctico con respecto a su pregunta sobre proyectos con una base de código difícil de manejar y un gran número de archivos, haga este ejercicio: use un solo archivo para su trabajo. Realmente no estoy bromeando. Esta misma pregunta surgió en mi compañía actual y anterior. Aquí, otro desarrollador observó que prefiero mantener un archivo para cada clase. Esto le parecía extraño y, en un asunto relacionado, tampoco le gustaban las clases parciales. Entonces, una forma de tener una idea de cuándo o dónde es apropiado dividir la lógica en archivos separados sería comenzar con un solo archivo. Después de haber practicado la regla de un archivo en múltiples proyectos, con suerte de aumentar la complejidad, puede encontrarse con un proyecto en el que tiene tantas clases en un archivo que le resulta difícil de leer o, debido al control de versiones, se hace difícil colaborar. En este punto, desea crear archivos separados para agrupar diferentes clases. Dada su preferencia, puede decidir pronto que le gustan todas las clases de datos en un archivo. Entonces, tal vez más tarde, puede decidir que le gustan los archivos separados, incluso entre las clases de datos como grupo.

No necesitas tener una gran idea para comenzar a programar algo. Empezaría por la parte fácil. Como un programa que ya lo usas. Intenta hacer algo que ya sabes cómo funciona. Enfrenta tus problemas, por lo que lo aprenderás más rápido. Una vez que tenga más experiencia, comenzará a tener algunas buenas ideas de programas para facilitarle la vida mientras programa, o simplemente un buen programa para hacer algo que nunca antes había pensado. He estado programando Java durante casi un año y otros idiomas durante un par de años. Me tomó tiempo comenzar a hacer lo que realmente quería hacer. Acabo de empezar a hacer mis propias cosas. Gracias a StackOverflow. No lo sabía antes.

Así que hay un montón de respuestas, así que perdóname si repito mucho de lo que ya se ha dicho, pero aquí están mis 2 centavos.

Primero escoge una idea. Cualquier idea estará bien, algo simple probablemente sería mejor que grande. Los proyectos tienen una tendencia a crecer en su alcance muy rápidamente (algunos lo llaman arrastramiento de características).

Luego haz un esqueleto para el proyecto. Esto requerirá un poco de conocimiento de arquitectura y diseño y probablemente se equivoque las primeras diez veces que lo intente, lo hice. Simplemente diseñe una estructura de archivo decente y tal vez un pequeño esqueleto de código que muestre las partes importantes del sistema.

Guarde el esqueleto en su VCS (elija su veneno con este y espere cuando conduce a una guerra santa). Una vez que haya comenzado a usar VCS, usarlo constantemente para pequeños cambios se convierte en una segunda naturaleza, pero asegúrese de comenzar.

Ahora elija una característica pequeña pero importante para el sistema y hágalo. No se preocupe por asegurarse de que tiene todo encapsulado perfectamente y que tiene el "mejor" diseño (que evolucionará con el sistema). Solo consigue algo que funcione. También obtener algunas pruebas unitarias ayudará a garantizar que sepa qué sucedió cuando algo se rompe, si ejecuta las pruebas regularmente.

Construye tu sistema. Este también sería un buen momento para obtener un sistema de construcción automatizado y una integración continua. Si no sabe cuáles son, aprenda e intente, o simplemente continúe bajo su propio riesgo; De cualquier manera sigue trabajando.

Ahora elija otra función y repita y repita y repita.

Una vez que creas que funciona bien, muéstralo a un amigo. El amigo no tiene que saber programar ni siquiera saber qué hace el programa. Una te hará sentir bien al mostrarle a alguien y dos te ayudará a saber exactamente qué hace el sistema.

Si llega al punto en el que está muy seguro de lo que hizo, publíquelo en línea e intente obtener comentarios. Un centro de repositorio o el sub-reditt de programadores pueden proporcionarle algunas críticas constructivas. Intenta encontrar un profesor de CS / SE y haz que lo vea. Tal vez pregunte a un programador profesional. Simplemente obtenga otra opinión de los programadores.

Una vez que termine (o probablemente antes), se dará cuenta de que el código que escribió inicialmente es mucho peor que el que creó recientemente. Eso es perfectamente natural y nos sucede a todos. Ahora necesita encontrar un nuevo proyecto y aprender algo nuevo, tal vez una nueva estrategia de prueba o cómo usar la Arquitectura Orientada a Servicios.

Algo que puede ayudar es pensar en un problema simple que tiene día a día en el que algo que podría hacer con lápiz y papel podría ser reemplazado por un programa.

Esto le proporciona un problema relativamente simple con una solución bastante conocida que solo necesita un nivel de automatización. Tenga en cuenta que esto no necesita ser el próximo MS Word / WordPad / NotePad; solo algo que resuelve tu problema (simple).

Por ejemplo, un problema que sigo reimplementando cuando trabajo con un nuevo idioma es una simple aplicación de cronometraje. La aplicación se utiliza para rastrear horas facturables a diferentes proyectos durante un día. Un programa bastante simple con muchas pequeñas trampas, como cómo maneja los reinicios en el medio del día o cómo agrega / elimina elementos de su lista.

Creo que parte del problema es que cuando lees libros de programación, solo te enseñan el idioma. No mencionan que para programar casi cualquier cosa, necesita acceso a la programación de BIBLIOTECAS y SDKS, etc. Simplemente conocer el idioma desafortunadamente no es suficiente.

Supongo que su problema proviene de: 1. el conflicto que existe entre la teoría y la práctica, y también que ... 2. ... debe darse cuenta de que su código será ejecutado por el código de otro. 3. No puedes codificar algo si no tienes idea de lo que podrías hacer. 4. Sabes la mitad de la dificultad

1. Saber un idioma por teoría no significa que lo "hables": esa es la diferencia entre leer inglés y hablarlo. Además, la gran cantidad de herramientas diferentes disponibles para compilar, vincular y editar un código fuente hará que su cabeza gire.

2. cuando se aprende a programar, la mayoría de las veces si se usa un terminal para ingresar / emitir texto, porque esta es la forma más simple de lidiar con la programación. De hecho, los programadores usan bibliotecas (como Qt), frameworks (django, supongo) y otro código de acceso directo para ser productivos. Por supuesto, si siente que puede escribir su propia rueda, no la reinvente y lea libros sobre el diseño del compilador y el diseño del kernel: hay mucho que aprender en esto: tal vez sienta que es estúpido eliminar aplicaciones que no requieren mucho de tecnicidad.

3. Inventar algo ! Por supuesto, podría hacer un editor de texto, un juego, etc. La cuestión es que no lo hará si no ve ninguna razón para hacerlo: este programa será inútil para usted si todo lo que piensa ya se ha hecho . Personalmente, todavía sueño poder codificar un protocolo p2p descentralizado similar a Facebook con chat, mensajes fuera de línea, etc., todo en uno para que pueda usarse con dispositivos inalámbricos integrados. Internet ofrece muchas posibilidades, no te olvides de pensarlo.

4. De hecho, la teoría es necesaria para practicar, pero eso no es todo: los algoritmos y las técnicas no son parte de la teoría de la programación, hay muchos paradigmas y otras formas "estándar" de hacer su código: patrones de diseño, listas enlazadas, etcétera etcétera.

Tal vez podría elegir un lenguaje de script para comenzar. Empecé a programar con el lenguaje C. En mi opinión, el lenguaje C es fácil de comenzar, pero se necesita mucho más tiempo para conocer el algoritmo y algo sobre el sistema operativo. Y cada vez que hago ejercicio es simplemente con una GUI de DOS, eso me deprime.

Y luego elegí un lenguaje de script llamado ActionScript para comenzar. El lenguaje de secuencias de comandos es un lenguaje orientado a objetos y puede controlar el comportamiento de una película Flash. El lenguaje de secuencias de comandos es fácil para hacer un trabajo cercano al dominio del problema , al igual que trace("HelloWorld")en ActionScript para generar una cadena. Y tiene un IDE poderoso que le permite pagar si su programa funciona bien.

En una palabra, si desea comenzar a programar de manera rápida , un lenguaje de script puede ser una buena opción :-)

Escribe una especificación. ¿Qué quieres que haga tu programa? Las pantallas (si es un programa basado en UI), la lógica, la entrada / salida, etc. Mantenga el alcance limitado a lo que puede hacer en un período de tiempo razonable (¿una semana? ¿Un mes?).

Entonces constrúyelo. Cumplir con la especificación, hacer que funcione de acuerdo con lo que la especificación necesita. Seguro que se encontrará con distracciones, seguro que tendrá que investigar un poco porque nunca antes se ha enfrentado a un problema en particular, pero creará algo que desea construir. Esto es diferente de construir algo que simplemente 'puedes' construir.

Una vez que termine, refactorice su código, intente hacerlo más eficiente. Luego, si cree que su programa aún no está terminado, comience de nuevo, mejore la especificación, mejore el código y siga haciendo esto.

Recuerde, la mayoría del software comercial resuelve una necesidad. Es muy importante definir la necesidad y la solución para satisfacer esa necesidad antes de resolver el problema. Y a medida que la necesidad crece más y más, su software también crecerá con el tiempo.