¿Todavía diseñas tu código en papel antes de escribirlo en la computadora? Mucha gente en mi clase de programación orientada a objetos parece resolver el problema en su cabeza, pero uso mi cuaderno y lápiz.

A veces lo hago, sí. He estado desarrollando software durante 30 años. Tengo un bloc de papel de diseño muy grande (11 × 18? Quizás más grande) junto a mi teclado. Principalmente lo uso para esbozar diseños de nivel de arquitectura, pero ocasionalmente lo usaré para esbozar un diseño OOP si es algo complejo y necesita ser perfecto. Cuando era más joven, confiaba en esto aún más. También uso ese panel de diseño para esbozar explicaciones para las personas que acuden a mí con preguntas sobre cómo mejorar algo que han hecho. Si tuviera una pizarra blanca a mano, podría usarla, pero de alguna manera encuentro el papel más fácil. Mi garabato de pizarra es ilegible. Además, puedo arrancar la sábana y dársela a la persona para que la quite.

Tl; dr paper es una buena herramienta para el diseño de software, sin importar su nivel de experiencia.

No conozco a nadie que resuelva el problema en su cabeza. Bueno, excepto tal vez por este genio ingeniero físico ruso que se sienta a mi lado. Pero … bueno … es un caso atípico en cada métrica.

Lo que hago primero es asegurarme de que entiendo el problema.

Luego codifico una prueba unitaria que verifica si parte del problema se ha resuelto correctamente.

Esta prueba, por supuesto, no puede compilarse por completo, ya que aún no he escrito el código real.

Entonces, con la prueba en su lugar (lo que me obligó a descubrir cómo escribir un código que interactúa con el código real), eliminé las clases básicas.

El código ahora se compila, pero obviamente no pasa porque todo lo que tengo son trozos.

Entonces, relleno los talones con lo mínimo que necesito resolver, hasta que pase la prueba.

Luego escribo otra prueba y repito el proceso.

A menudo, a través de este flujo, tengo que refactorizar mi código ya que veo que es difícil de usar o demasiado complicado o demasiado monolítico.

En algún momento de esta iteración, tengo todas mis pruebas aprobadas y luego sé que he terminado.

git commit

git push

¡Dame un café!

Es una elección totalmente personal.

Preferiblemente, cuando resuelva problemas lógicos, tenga conmigo un papel o una pizarra. Pero primero, trataría de darle una oportunidad directamente a mi IDE. Trato de entender cada paso en mi cabeza. Si hay algún error o ambigüedad, tomo mi pizarra y empiezo a resolver el problema dado matemáticamente (generalmente tomando ejemplos) y luego convierto la lógica paso a paso en código.

Pero mientras hago trabajos de aplicación o diseño, primero me dirijo a bocetos y prototipos de toda mi aplicación o programa. Esto es importante para que uno pueda administrar cada funcionalidad de manera efectiva y más eficiente.

Cualquiera que sea el caso, resolver en papel y crear prototipos no trae ningún daño. En realidad, es una buena práctica y puede proporcionar menos espacio para los errores.

Créeme, depende de ti.

Hay personas capaces de resolver completamente un problema en sus mentes, otros que necesitan un contacto con el mundo externo. Personalmente pertenezco al segundo set.

Pero esto no se limita al dominio CS.

Por ejemplo, en la música clásica, WA Mozart era conocido por componer toda su música en su mente y podía escribir la partitura sin siquiera tocarla.

I. Strawinsky, por otro lado, no pudo componer sin su piano y en sus obras autobiográficas, escritas con R.Craft, se hace llamar “Homme de métier”: trabajador. Se despertaba regularmente al mismo tiempo, compuesto 4 horas por la mañana rigurosamente con su piano y 4 horas por la tarde, como escultor trabajando con mármol.

Hola..!

Compartiendo mi propia experiencia, cuando me uní a mi Ingeniería en Tecnología de la Información en 2013, el primer día vi a muchos otros nerd y personas que estaban mucho mejor que yo. Los que no requirieron papel para escribir para resolver preguntas de programación, y luego estoy yo, que solo uso papel para el programa más simple, por ejemplo: Hola mundo en C. (No sabía nada cuando ingresé en Ingeniería).

e incluso ahora, cuando puedo trabajar en tecnologías como Inteligencia Artificial, Aprendizaje automático y Aprendizaje profundo, sigo usando lápiz para resolver los programas complejos. Antes de implementar el código en mi máquina, escribo incluso el código simple en papel, desarrollo algoritmos e implemento en papel primero y luego voy con la máquina.

Lo que quiero transmitir es que no hay nada de malo si está utilizando papel para resolver el código, al final todo lo que queremos es que la salida sea perfecta o no. Pero si usa papel de lápiz, hay una ventaja: conoce el flujo por escrito si olvida algo intermedio, o puede encontrar otras ideas nuevas para implementar cualquier código o algoritmo.

Espero que esto ayude.!!

Gracias.!

Ps: puede seguir / comentar o enviar mensajes sobre cosas de programación. 🙂

Solo cuando el problema es demasiado complejo para que lo visualice en mi cabeza. Que generalmente son cosas para las que no conozco la solución, como problemas arquitectónicos que requieren días para reflexionar,

De hecho, a veces trato el papel como un truco de productividad. Por ejemplo, tenía una característica difícil de construir, pero me iba el fin de semana para un viaje y no quería usar mi computadora portátil ya que eran vacaciones. Pero también sabía que tendría unas pocas horas de viaje para perder el tiempo, así que traje un cuaderno grande y simplemente escribía ideas y pseudocódigo, flechas en recuadros, etc., haciéndome pensar más en ello. Espero que lo resuelva inconscientemente a medida que pasen los días. Terminé codificando la mayor parte de la solución en papel, y estoy bastante seguro de que me habría llevado más tiempo si lo hubiera hecho en mi IDE.

Mi conclusión es que a veces funciona bien, pero realmente no lo hago con demasiada frecuencia. Además, realmente no puedes hacer TDD en papel 😉

Si bien no tiene que ser específicamente en papel, es muy importante planificar lo que va a hacer antes de codificar, especialmente en un entorno profesional. Mis compañeros de trabajo y yo a menudo tendremos sesiones de pizarra para analizar algunos puntos de decisión en la creación de aplicaciones. Con frecuencia, estos giran en torno a principios orientados a objetos y patrones de diseño SÓLIDOS, pero también es importante ser práctico y no pasar todo el día abstrayendo todo lo posible. Estás en la universidad, por lo que la planificación no es tan crucial cuando eres el único que trabaja en la base de código y si solo se ejecutará una vez. Después de introducir una escala seria, estas cosas se volverán más importantes.

Entonces, sí, todavía diseño mi código en papel (o una pizarra, o tal vez algún software de modelado de objetos de vez en cuando). Pero creo que una de mis citas favoritas sobre el desarrollo es relevante aquí (fuente desconocida, y no es mi cita) …

“Semanas de codificación pueden ahorrarle horas de planificación”

Hay muchos estilos de pensamiento, y todos son óptimos en diferentes situaciones.

• A veces, un bolígrafo o lápiz es solo un accesorio físico para ayudar a concentrarse.
• A veces, un cuaderno es la forma ideal de esbozar una idea, en un mapa mental, un diagrama UML o simplemente un pseudocódigo para un modelo de datos, una interfaz o un algoritmo.

Algunas personas tienen que hablar para pensar. Algunas personas tienen que moverse. ¡Solo alégrate de no tener que bailar para escribir código! (Los estudiantes cinestésicos encuentran el movimiento muy poderoso). Use su cuaderno, garabato, boceto, ya que funciona para usted. Use papel en blanco, papel rayado, papel cuadriculado. Utilice post-its. Lo que sea que funcione.

No hay mejor manera de hacer nada, excepto lo que se siente y funciona mejor para usted. Observe lo que hacen otras personas, porque siempre hay cosas nuevas que aprender … pero no se preocupe por hacer algunas cosas a su manera.

Ya sea que esté trabajando en un nuevo sistema, una herramienta o una funcionalidad mejorada, necesito incorporar todo el pensamiento que pueda en la pizarra o en el papel. Prefiero el pizarrón porque es fácil borrar un segmento y expandirlo. Esto tampoco es un pseudocódigo, pero un nivel mucho más alto generalmente solo incorpora cuadros unidos a cuadros y notas. A veces me ayuda a ver qué métodos necesito implementar. A veces solo me da tiempo para concentrarme en el flujo lógico. Luego pediría a mi compañero en Washington que los revise y brinde comentarios y hablemos sobre grandes áreas del diseño que son geniales, que tienen correcciones de flujo o áreas que (con un cambio menor) nos permiten ampliar en gran medida lo que podemos hacer por el usuario. A medida que se convierte en un flujo refinado con expansiones en áreas clave, también empiezo a ver dónde necesito clases abstractas, dónde necesito interfaces y qué clases sin procesar se necesitan. A veces la vieja escuela es la nueva escuela.

Es un muy buen hábito, ¡sigue haciéndolo!

Me vuelvo al papel (o pizarra) cuando el problema es difícil para mí o cuando quiero hablar con un colega.

Es muy útil, porque le permite explorar ideas que no son compatibles con el lenguaje de programación, pero que aún son útiles para comprender. Cosas como diagramas de flujo, gráficos o diagramas.

Con el tiempo, obtendrá experiencia y algunos problemas serán tan fáciles para usted que puede escribir las soluciones de inmediato.

¡Pero siempre habrá problemas difíciles! ¡Mantenga el papel a mano!

Casi siempre dibujo la lógica del proceso de la aplicación en la que estoy trabajando antes de escribir cualquier código. A menudo comienzo a dibujar la lógica del proceso usando PowerPoint. Si la lógica del proceso resulta ser “grande”, entonces cambiaría a dibujar la lógica del proceso en papel. Más tarde, también transfiero el dibujo en papel a PowerPoint.

Utilizo una computadora portátil para el desarrollo y tiene una pantalla de 15 ″. Algunas veces había pensado en usar grandes hojas de papel para mis dibujos. Afortunadamente, logré retransmitir muchos diagramas y usar “anotaciones de alto nivel” para mantener la mayoría de mis dibujos dentro de 8.5 ″ x 14 ″. Algunas veces tuve que usar una página más grande que 8.5 ″ x 14 ″ (no sé el tamaño exacto pero es más grande que 8.5 ″ x 14 ″).

Además de los diagramas, también utilizo formularios personalizados que van junto con los diagramas para fragmentos de código. En base a los diagramas y formularios, escribo mi código.

A veces necesito representar problemas en términos matemáticos. Si trabajo con matrices, casi siempre escribo los elementos de estas matrices en papel y también trabajo los algoritmos en papel.

Me gusta escribir mis ideas en papel o en PowerPoint porque después de pensarlo y documentar mis pensamientos, siempre puedo volver a los documentos con fines de referencia. Sería un gran desafío para mí recordar los requisitos, volver a procesar los requisitos y traducir los requisitos en códigos “en mi cabeza” la primera vez. Y sin duda sería más difícil volver a hacerlos más tarde.

Sí, siempre … Bueno, no el código, sino el diseño de cómo quiero que se vea el código desde un punto de vista general. Y, de hecho, no creo que pueda codificar más sin hacerlo.

Durante la universidad y en mi licenciatura, había muchas, muchas materias en las que no entendía completamente lo que estaba codificando … y mis compañeros de clase solían encontrar la mayoría de las veces una combinación de stackoverflow, diapositivas de conferencias incompletas y prueba y error para hacer que las cosas funcionen, sin un plan real cuidadosamente pensado. Principalmente porque teníamos alrededor de 5/6 asignaturas por semestre con 6 proyectos diferentes y es difícil, si no imposible, mantener todo en nuestras cabezas … y lamento haber perdido muchos conceptos geniales debido a abordar proyectos de esa manera … pero , bueno, ahora estoy un poco mejor, creo …

La idea es que, en el momento en que comienzas con un trozo de papel en blanco y un lápiz (y un borrador tal vez 😀), el único límite para lo que puedes concebir y ver frente a ti, está limitado por tus propios objetivos / necesidades … Y eso es mucho veces más poderoso que solo el código … El código hace que una idea sea concreta y una cierta lógica simplemente “funciona”. Pero ningún sistema serio comenzó en un editor de texto, por lo que está en el camino correcto. Mantente en ello POR EL RESTO DE TU CARRERA.

Para complementar eso, tal vez esto sea algo más personal, una vez que termine de pensar con lápiz y papel, tiendo a escribir 3/4 comentarios generales de lo que quiero hacer en esa clase y solo entonces empiezo a codificar, con el comentarios orientadores como andamio, y despejarlos a medida que avanzo … Un poco como mini-objetivos. Obviamente, a veces un cierto paso en su hoja de papel puede ser difícil de hacer en la práctica, pero, si puede hacer las soluciones necesarias sin comprometer su (con suerte bueno) diseño general de P&P, entonces me atrevería a decir que es un ingeniero bastante raro. ¡¡hoy en día!!

Es bueno comenzar en papel. A menos que un problema sea trivial, comienzo a dibujar en papel imágenes del problema, diagramas de flujo y UML (menos UML en sistemas integrados). Esto le permite ver la imagen completa antes de intentar resolver un problema que no comprende. Cada uno desarrolla su propia técnica y estilo. Es el resultado final lo que importa,

Tiendo a pensar en imágenes, por lo que cualquier diseño no trivial se dibujará en papel o en una gran pizarra mientras estoy trabajando en los detalles. En general, el boceto está en el nivel de “objeto”, aunque (cuadros con líneas que los interconectan; nada tan elegante como UML). De vez en cuando escribiré un pseudocódigo si estoy trabajando en un algoritmo particularmente complicado.

Una vez que empiezo a implementar en un idioma en particular, generalmente lo haré en la computadora: los IDE modernos son demasiado útiles cuando uno se mete en el meollo de un idioma en particular.

He estado haciendo diseño de hardware y software durante más de 30 años, por lo que es poco probable que vaya a cambiar.

Todos piensan de manera diferente, así que ve con lo que funciona para ti.

Por favor, nunca dejes de hacer eso. Estoy muy seguro de que sus soluciones cubren más dimensiones que las de sus compañeros, porque cuando escribe en su cuaderno, se convierte en un muy buen amigo “externo” que nunca le mentirá. Cuando trabajas solo en tu mente, eres juez y parte, por lo que es muy difícil ser objetivo sobre tus propias decisiones.

Contestar; Nunca hago eso, mi trabajo es editor de texto.

Si eso te ayuda a planificar mejor las cosas, ¡sigue haciendo eso!

No recomendaría escribir ningún código real en papel, excepto ideas, notas rápidas y detalles del proyecto.

¿Por qué no escribir ningún código en papel?

Practica de esa manera y prueba las cosas a medida que avanza, un periódico no puede hacer eso.

He estado programando durante 25 años, me encanta hacerlo y estoy por encima del promedio. Todavía garabateo mucho, las razones principales son que mi pensamiento y mi memoria parecen estar conectados a representaciones visuales.

No escribo código en papel. Sin embargo, esbozo el código en la computadora en un editor de texto muy básico cuando estoy a punto de comenzar algo de lo que no estoy 100% seguro.

Es posible que sus colegas estén por delante de usted y lo estén haciendo mentalmente porque es un patrón o problema conocido. También podrían adaptarse a modelos más grandes en sus cerebros. No todos nacemos iguales.

Usa lo que sea que te ayude a progresar. No pienses demasiado en cómo te ves.

Si estoy abordando un problema que no he resuelto previamente, sí.

Mi enfoque del código durante bastante tiempo ha sido, “pensar bien, luego el código se escribe solo”. Realmente no me preocupo por los detalles de implementación porque sé que una vez que he definido claramente el problema y la solución Estoy buscando, puedo hacer las preguntas correctas, encontrar las “mejores prácticas”, hacer algunas pruebas y producir algo estable y útil.

Funciona bien (para mí de todos modos) porque si realmente comprende lo que está haciendo antes de comenzar a hacerlo, tiende a escribir código que sea más fácil de entender y trabajar.

Desafortunadamente, aunque este enfoque es práctico y me ha ayudado a producir código que la gente ha ejecutado durante años sin problemas, no es muy útil en las entrevistas en estos días. Cuando te dan el problema, no quieren que te tomes media hora para esbozarlo. Solo quieren que comiences a escribir código.

Entonces, aunque creo que el codificador más útil será el que primero intente comprender completamente un problema antes de escribir el código, en estos días también debe ser uno de estos tipos “competitivos” que memoriza todas las algs y puede escribir cualquier cosa de forma recursiva … incluso si nunca harás algo así en el trabajo.

Lo que sea que funcione para usted es bueno cuando se trata de diseño.

A menudo me gusta dibujar algunas cajas y flechas para llevarme a este rey en la dirección correcta. Estoy feliz si cambia a medida que codifico, si veo formas más claras.

A menudo puedo ver piezas lo suficientemente pequeñas en mi cabeza, pero eso es lo que 30 años de práctica te compra