Atascado debido a "saber demasiado" [cerrado]

Observe más discusión en http://news.ycombinator.com/item?id=4037794

Tengo una tarea de desarrollo relativamente simple, pero cada vez que intento atacarla, termino en espiral en pensamientos profundos: ¿cómo podría extender el futuro, qué van a necesitar los clientes de segunda generación, cómo afecta "no funcional"? aspectos (por ejemplo, rendimiento, autorización ...), cómo sería mejor diseñar un arquitecto para permitir el cambio ...

Me recuerdo hace un tiempo, más joven y, tal vez, más ansioso. El "yo" que era entonces no habría pensado en todo eso: él habría seguido adelante y escribió algo, luego lo reescribió, luego lo reescribió nuevamente (y otra vez ...). El "yo" de hoy es más vacilante, más cuidadoso.

Hoy me resulta mucho más fácil sentarme, planificar e instruir a otras personas sobre cómo hacer las cosas que seguir adelante y hacerlas yo mismo, no porque no me guste codificar, ¡al contrario, me encanta! - Pero porque cada vez que me siento al teclado, termino en ese mismo lugar molesto.

¿Esto esta mal? ¿Es esta una evolución natural, o me metí en una rutina?

Divulgación justa: en el pasado era desarrollador, hoy mi puesto de trabajo es "arquitecto de sistemas". Buena suerte imaginando lo que significa, pero ese es el título.

Guau. Sinceramente, no esperaba que esta pregunta generara tantas respuestas. Trataré de resumirlo.

Razones:

1. Parálisis de análisis / Sobre ingeniería / baño de oro / (cualquier otro "pensar demasiado por adelantado puede lastimarte").
2. Demasiada experiencia para la tarea dada.
3. No centrarse en lo que es importante.
4. No hay suficiente experiencia (y darse cuenta de eso).

Soluciones (no coincidentes con los motivos):

1. Prueba primero.
2. Comience a codificar (+ por diversión)
3. Uno para tirar (+ una API para tirar).
4. Establecer restricciones de tiempo.
5. Retira la pelusa, quédate con las cosas.
6. Haga un código flexible (un poco opuesto a "uno para tirar", ¿no?).

Gracias a todos. Creo que el mayor beneficio aquí fue darme cuenta de que no estoy solo en esta experiencia. En realidad, ya comencé a codificar y algunas de las cosas demasiado grandes se han caído, naturalmente.

Como esta pregunta está cerrada, aceptaré la respuesta con la mayoría de los votos a partir de hoy. Cuando / si cambia, intentaré seguirlo.

Pensar en estas cosas es definitivamente bueno, pero no dejes que detenga tu progreso.

Un enfoque que funciona realmente bien (especialmente con el desarrollo iterativo) es implementar una solución simple y luego refactorizar según sea necesario más adelante. Esto mantiene el código lo más simple posible y evita la ingeniería excesiva. La mayoría de los cambios de rendimiento o arquitectura que está contemplando probablemente no serán necesarios de todos modos, así que no se moleste en escribirlos hasta que sean oficialmente necesarios. Por ejemplo, no se preocupe por el rendimiento hasta que un generador de perfiles le haya dicho que es hora de mejorar el rendimiento.

Una cosa que puede hacer para ayudarlo a ajustar es establecer un límite de tiempo difícil en cuanto tiempo piensa en algo antes de escribir el código. La mayoría de las veces, el código resultará mejor si lo piensa un poco, lo escribe, se da cuenta de sus errores y luego los repara refactorizando.

Hay un equilibrio para ser alcanzado aquí. No deberías saltar de cabeza y no pensar en las consecuencias, sino que tampoco deberías tratar de manipular demasiado tu código.

Wikipedia lo llama "Parálisis de análisis" en software. La receta es apegarse a metodologías ágiles. Lo que significa que cualquier actividad o acción individual tiene mucho más valor que el intento de establecer prácticas o políticas. Cada contribuyente en el equipo es valioso, no importa cuán bien o mal se adapten las habilidades de la persona a los ideales arquitectónicos. En ágil, los individuos, los egos son los primeros, las políticas son las últimas.

Mi respuesta favorita es "Arquitectura es un verbo". Deja de pensar, comienza a actuar, no importa cuán imperfectas e ineficientes se sientan tú y el equipo. Quizás las primeras acciones pueden ser desmantelar políticas inapropiadas.

Hace 40 años, Fred Brooks escribió sobre este "Escribe uno para tirar, de todos modos lo harás". Nada ha cambiado........

¿Esto esta mal? ¿Es esta una evolución natural, o me metí en una rutina?

Depende. Esto tiende a ser un paso común en el camino de un desarrollador.

1. Comience a tirar basura juntos, muerda el culo por eso
2. Comience a diseñar en exceso el infierno de todo, date cuenta de que YAGNI
3. Acomódese en un punto medio pragmático donde las cosas fáciles se unen y las cosas difíciles / probables de cambio reciben suficiente ingeniería para que sea fácil trabajar con / cambiar.

Es solo una rutina si te quedas en el número 2.

Una de las cosas que siempre me gusta tener en cuenta es el dicho "el futuro no es lo que solía ser".

Con una cierta cantidad de experiencia se vuelve tentador creer que puedes predecir el futuro, pero no puedes. Es fácil imaginar características que futuros clientes / usuarios / lo que quieran, pero eso no significa que las van a querer de inmediato. Tampoco significa que los van a querer sobre alguna otra característica conflictiva. Entonces, realmente necesita limitar la cantidad de tiempo que pasa hoy planificando para el futuro. Especialmente necesita limitar la cantidad de tiempo que pasa construyendo cosas hoy que solo serán de utilidad en el futuro.

La pregunta que hago que me mantiene en el camino correcto es "¿cuánto más difícil será desarrollar esta característica más tarde que generar soporte para esa característica ahora?" Por lo general, la respuesta es que el esfuerzo futuro es casi el mismo o quizás el doble de lo que sería hacerlo ahora. En ese caso, como no puedo predecir el futuro, no tengo ningún problema en no construirlo ahora. Si la respuesta llega a 10 veces o más, entonces comenzaré a preguntar acerca de qué tan probable la gente piensa que vamos a necesitar esto en el próximo año o dos. Incluso entonces, a menos que haya un acuerdo generalizado, simplemente me limitaría a asegurarme de que no sea necesario deshacer las cosas que estamos haciendo hoy para lograr ese objetivo en el futuro.

Por ejemplo, trabajé en algunos proyectos en los que pasamos mucho tiempo abstrayendo el hecho de que estábamos usando Hibernate como acceso a datos más tarde. (Nunca había visto que el proyecto construido sobre Hibernate dejara de usarlo, así que para empezar fue una pérdida de tiempo, pero dejemos eso de lado). Incluso si hubiera sido una posibilidad razonable de que quisiéramos cambiarlo más tarde, porque también estábamos usando un patrón de objeto de acceso a datos, no habría sido más difícil construir la flexibilidad para cambiar Hibernate y cambiarlo al mismo tiempo cuando lo necesitábamos que construir la flexibilidad desde el principio. Frente a una situación como esa ahora, simplemente pospondría tener esa flexibilidad hasta que realmente la necesitáramos.

A menos que esté haciendo una planificación estratégica para una gran corporación, apenas vale la pena pensar en cuestiones arquitectónicas a más de dos o tres años de distancia, porque la tecnología está cambiando muy rápidamente. La característica que puede estar pensando construir hoy puede estar disponible gratuitamente en código abierto en dos o tres años. Es casi seguro que el análisis de costo-beneficio habrá cambiado.

Limítese a construir un sistema que haga lo que necesita hoy, de lo que esté orgulloso, y que estará encantado de trabajar en unos meses, sea lo que sea lo que traiga la próxima ronda de cambios. Realmente eso es lo mejor que puedes hacer.

Aquí está mi proceso personal de eliminación de diseños increíblemente increíbles que (en su primera versión) pueden terminar siendo poco prácticos y dañar un proyecto desde la perspectiva comercial.

1. Identifique el epicentro : piense en su proyecto como un puesto de perritos calientes, el epicentro serían los perritos calientes. Puede sacar cualquier otra especia / aderezo / verdura de su puesto y aún así puede vender perritos calientes. ¿Cuál es el objetivo principal de su software? Aísle cualquier otra adición y / o valor agregado y concéntrese primero en el epicentro.
2. Siga repitiéndose a sí mismo "hacerlo más tarde significa hacerlo mejor" : vea dónde tiene sentido y ponga una pequeña nota "para más adelante". Si lo haces bien y piensas en su uso en el mundo real, terminarás con el mismo diseño pero priorizado en una hoja de ruta.
3. Disminuir-desacoplar-descartar : cualquier diseño de módulo que tenga lo hace lo más simple / esencial / puro / universal que pueda (a veces esto se puede lograr sin siquiera eliminar las funciones). Cuando no pueda simplificarlo aún más, comience a desacoplar elementos que puedan vivir solos y tengan un propósito. Al final, si todavía tienes algo de grasa allí, podrás cortarlo.
4. Separe el "código de biblioteca" del "código de producción" : siempre habrá código que no se puede reutilizar, pero siempre agrega ruido al diseño. Este código es el que contiene las reglas comerciales. Encontrará que a veces algunas reglas comerciales son más fáciles y rápidas de cambiar ( extremadamente importantes ) que con un diseño robusto. Encontrará un código en el que puede confiar y el código que el cliente necesita cambiar o reimplementar en el futuro. Querrás que se mantengan lo más separados posible.

Y por cierto, el paso 0 es: "enloquece con el diseño". Esto me ayuda a sacarlo de mi sistema y a menudo encontrar nuevas implicaciones, requisitos ocultos e incluso características emergentes.

Tomé 1 y 2 de Rework .

Escribe las pruebas. Ya terminaste cuando todas las pruebas pasaron: no antes, y ciertamente no mucho después durante una fase épica de sobre ingeniería. Tener un conjunto de pruebas para el código que está escribiendo le dará un observador independiente e imparcial que le dirá cuándo puede detenerse.

Cuando eres joven, no ves riesgo (posiblemente la razón por la que los políticos junior dan miedo), pero a medida que envejeces, tus malas experiencias te paralizan en cada oportunidad (posiblemente la razón por la que los políticos de alto rango están estancados). Adopte el enfoque guiado por una navaja de afeitar de Occam: busque la solución que tenga la menor cantidad de necesidades y luego evolucione desde allí.

Solo hay dos cosas que realmente debe tener en cuenta al escribir y diseñar software: mantenibilidad y corrección.

La corrección es lo más importante a corto plazo y puede demostrarse fácilmente mediante pruebas.

La mantenibilidad ayudará más adelante en el desarrollo, pero es más difícil de precisar.

Mi estrategia actual es obtener primero una prueba de concepto monolítica y luego separar la interfaz de usuario del modelo (asegurando que el modelo no sepa nada sobre la interfaz de usuario) una vez que esté seguro de que es viable. Si esperara demasiado este paso, obtendría algo imposible de mantener. Si empiezo con las capas separadas, parece que no puedo comenzar ya que me quedo atascado en lo que la IU necesita saber sobre el modelo.

Cuando me quedé atrapado en situaciones como estas, descubrí que es útil imaginar tercamente que soy un usuario final que usa el programa hipotético para hacer algo razonablemente trivial. Luego trato de concentrarme en cuáles serían los puntos de entrada programáticos necesarios para respaldar esas acciones, intentando en la medida de lo posible ignorar otros aspectos del sistema. A partir de aquí, a menudo es posible construir una (pequeña) lista de características del sistema terminado, y escribir un código poco realista que comience a implementar eso. Después de ese ejercicio, generalmente empiezo y el resto del sistema comienza a aclararse. Se trata del punto de entrada, y el punto de entrada de la gran mayoría de todo el software son las acciones iniciales de los usuarios finales con un programa.

Creo que es un síndrome que las tareas que estás haciendo son demasiado fáciles para ti.

Hace unos años, el desafío para ti era escribir un código que lograra la tarea dada. Esto fue lo que atrajo completamente tu mente. Ahora, su mente (su experiencia, etc.) está trabajando de manera más efectiva y hacer la misma tarea requiere solo una parte de la energía que antes se necesitaba. Es por eso que terminas en esa espiral de pensamientos profundos. Tu mente se defiende de la rutina y lucha por el desafío.

Creo que deberías considerar cambiar tu trabajo. Tal vez deberías aprender un nuevo lenguaje de programación.

Tuve el mismo problema hace 15 años. Quería escribir un código perfecto, reutilizable, universal ... que hiciera la solución mucho más complicada de lo necesario. Hoy veo esto como chapado en oro . Lo que me ayudó mucho fue un consejo de un colega:

• si tiene una idea de lo que podría mejorar la funcionalidad, hágalo más universal ... escriba esta idea en un archivo de texto separado "ideas.txt" pero no implemente esto ahora .
• seguir implementando las tareas urgentes.
• después de seis meses, revise su "ideas.txt" y analice cuáles de estos cambios realmente habrían beneficiado el proyecto.

Esto es simplemente parálisis por análisis. Le sucede a muchas personas en muchos campos. Puedes atravesarlo.

La respuesta es: SOLO COMIENCE CON ELLA ;-)

Publico en un foro de fitness y muchas veces la gente publica sobre diferentes rutinas, tratando de encontrar la perfecta para ellas. Entonces les decimos que solo comiencen a entrenar y trabajen a medida que avanzan. Desea fortalecerse, hacer algunos ejercicios de fuerza y ​​luego ajustar las cosas a medida que avanza.

Cuando tienes un programa grande y tu cerebro trabaja horas extras, solo codifica los casos simples primero. Inicialmente, el programa debe ejecutarse, luego debe recibir información, etc.
Su desafío es dejar las cosas fáciles de actualizar y refactorizar más adelante, pero el código NO DEBE ser más complicado de lo que debe ser para realizar la tarea en cuestión.

Recuerde que en el futuro está bien refactorizar el código para cumplir con nuevas prioridades. No puedes predecirlos todos por adelantado, así que no lo intentes.

Código para la siguiente tarea: SOLO. El código es simple y bueno, por lo que es fácil refactorizar si es necesario. Asegúrate de que el programa funcione. Repetir.

Dado que se está "atascando" al pensar demasiado en los posibles escenarios de casos de uso del usuario final, hay algo que considerar aquí si va a publicar una API y espera que personas desconocidas la utilicen. Una vez que se publica una API, debe continuar admitiéndola, aunque luego se dé cuenta de lo mala que es su primera versión, o tenga que descifrar el código de todos, posiblemente desconocidos para usted, que han escrito en su contra, arriesgándose a alienarse ellos para todo el tiempo futuro.

La solución estándar es publicar con la estipulación de que la API podría cambiar de cualquier manera en cualquier momento hasta que tenga una idea de lo que necesitan sus usuarios y de lo que están haciendo los consumidores de API.

En esa solución, creo que es tu propia solución. Escribe una cosita que haga una o dos cosas, tal vez las haga bien, manteniéndote entendido de que todo lo que hagas puede cambiar en el futuro.

No es posible hacerlo bien, o en algunos casos, incluso CUALQUIERA de las cosas bien, cuando comienzas porque el diseño es realmente un viaje de descubrimiento; Es lo último que emerge, no lo primero que se hace.

No puede diseñar una API de inmediato y nunca tener que compartirla con sus consumidores. Entiendes por qué es eso. Del mismo modo, no puede escribir software y no tiene que tirarlo todo y comenzar de nuevo con un nuevo enfoque.

No creo que tengas un problema en el sentido de que has evolucionado accidentalmente en algo menos creativo, productivo o deseable. Creo que tienes altos estándares que accidentalmente estás aplicando mal a tu situación, un error común al pensar que todos cometen.

La experiencia nunca cuenta en su contra a menos que se convierta en un cínico sabelotodo, hecho todo, y eso realmente suena como lo opuesto a su situación.

Tengo un par de imágenes que tengo en mente cuando voy a lo grande. Una es jugar con Lego. Lo armé y lo desarmé a voluntad. Lo que empiezo a hacer puede no ser lo que termino haciendo. Estoy navegando y aprovechándome de las posibilidades que se me ocurren a medida que avanzo, a menudo recreando mis objetivos por completo en un instante de inspiración ... eso es la creatividad.

La otra imagen es una analogía que escuché que describe hacer ciencia real. Estás buscando en un cuarto oscuro un gato negro que puede no estar allí. Es desconcertante solo si te consideras un fracaso por no encontrar a ese gato. No hay otra forma de encontrar gatos negros. Esa es la única actividad que los localiza. Cualquier otra cosa es alguna forma de tener lo que supuestamente estás buscando.

No sabes demasiado; no sabes lo suficiente! Y solo recientemente te has dado cuenta de eso.

No piense en sus elecciones de diseño como algo que tiene que hacer "bien", porque no hay "correcto" - hay muchos "errores", pero también hay compensaciones (en velocidad de ejecución, tiempo para completar la codificación) tarea, extensibilidad, etc.). El código que escriba si está bien concebido aún tendrá varias fortalezas y debilidades.

El objetivo debe ser llegar al punto en que comprender estas fortalezas y debilidades en el contexto del uso y mantenimiento actuales y futuros no sea dramáticamente más difícil que escribir código en primer lugar.

Así que no evites pensamientos profundos, pero recuerda que necesitas experiencia, no solo pensamiento, para convertirte en un maestro en este tipo de diseño. Piensa hasta que llegues a un punto en el que no estés seguro de una elección en particular, luego implementa lo que esperas que sea la mejor, pruébalo y aprende cómo fue.

Practica la codificación. Proponga ejercicios o búsquelos en línea e intente terminarlos correctamente lo más rápido posible. Cuando aumente su velocidad, agregue consideraciones como la capacidad de mantenimiento y el rendimiento. Te darás cuenta de que es refrescante codificar cosas que no entrarán en producción y puede ayudarte a salir de tu miedo a la codificación.

Codifique en su tiempo libre, como lo hizo hace 10 años, con menos preocupaciones y diversión.

Conviértase en un gerente de equipo y dirija a los desarrolladores más jóvenes, que ahora están en el mismo estado mental que usted hace 10 años.

No, todavía no sabes lo suficiente.

Enriquezca su conocimiento, por ejemplo, mediante estas simples reglas:

• BESO: Mantenlo pequeño y simple.
• YAGNI: No lo vas a necesitar.
• Peor es mejor: algunas soluciones peores en realidad son mejores en términos de mantenibilidad.

No sobrediseñe. Prepárese para el cambio teniendo habilidades de refactorización, pero no codifique todos los cambios posibles en el código. Si ve que con el tiempo, una clase o función crece demasiado, cámbiela. Divide y conquistaras. Use interfaces, use más funciones. Si siente que se ha dividido demasiado (es decir, de alguna manera se hizo más elegante, pero menos legible), deshaga su último cambio.

En resumen: haga que su código sea lo suficientemente flexible, pero no más. En cambio, flexibilícese, compre un libro sobre refactorización.

Dos cosas:

1. No es suficiente saber mucho. Tienes que tener opiniones sobre lo que vale la pena implementar. Personalmente, veo TDD como una muleta que permite una mala arquitectura. Dada la gran cantidad de opinión popular que funciona en mi contra en esto, probablemente me equivoque, pero si implementar TDD en JavaScript no es un problema en el que haya pensado, porque la depuración nunca ha sido un gran dolor de cabeza para mí y oye, No sería la primera vez que la opinión popular en la comunidad de desarrollo fue vista como defectuosa años más tarde. Así que aprende a ser un pinchazo arrogante. Al menos por dentro. Puede estar equivocado, pero al menos se está comprometiendo con cosas que funcionan para usted en lugar de pensar demasiado en cosas que podrían no funcionar.

2. Parece que estás comenzando con micro. Comience con macro. Primero, las herramientas que necesitas para hacer lo que tu aplicación necesita hacer. Esa parte debería venir fácilmente. Luego comience con las preocupaciones de arquitectura / interfaz. La forma en que se conecta la tubería y a qué se conecta realmente debería ser solo los fragmentos débiles en la parte superior de todo lo que puede deslizar a un lado y reemplazar por capricho. Del mismo modo con los detalles de cómo se hacen las cosas. Envuelto adecuadamente, estos pueden ser reemplazados / editados con facilidad.

pero cada vez que intento atacarlo, termino en espiral en pensamientos profundos

No hay nada malo. Solo ha notado que es hora de mejorar su proceso: en este caso, su proceso de pensamiento.

Muchas personas se pierden en el análisis o se desvían de otras formas y nunca lo notan. Te has dado cuenta para que puedas cambiar tu proceso de pensamiento para mantenerte encaminado.

Hay muchas soluciones para esto, y la mejor que he visto anteriormente es establecer una restricción de tiempo. Antes de comenzar, decida cuánto tiempo (¿1 hora?) Dedicará a analizarlo y pensarlo. Establecer un temporizador.

Luego, cuando se apaga el temporizador, comience la codificación. Si vuelve a pensar en las cosas durante demasiado tiempo, simplemente tome una decisión instantánea. Lo que decidas en ese momento es la decisión correcta. Siempre puede realizar cambios y mejoras más adelante.

Además, nuestro entorno siempre está cambiando. A menudo necesitamos actualizar nuestro código para manejar nuevos requisitos, nueva tecnología, nuevo hardware, actualizaciones de idioma y sistema, etc.

Sí, este horror de codificación me sucede incluso a mí. Ser golpeado con Stack Overflow. Codificación en detalle para una pequeña aplicación. Pero cuando se trata de un proyecto subcontratado, no consume mucho tiempo debido a limitaciones de tiempo. Y creo que también trabajar con un grupo de personas nuevas puede superar esto.

No eres lo suficientemente despiadado

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

Editar: El objetivo de este artículo es prestar atención a los pequeños detalles al desarrollar, pero he descubierto que ayuda abordar cualquier tarea simple o compleja con una actitud despiadada para encontrar la solución más eficiente posible y simplemente hacer el trabajo.