Atascado debido a "saber demasiado" [cerrado]

Definitivamente, pensar en estas cosas es bueno, pero no dejes que esto 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 tarde. Esto mantiene el código lo más simple posible, y evita el exceso de ingeniería. La mayoría de los cambios en el rendimiento o la arquitectura que estás contemplando probablemente no serán necesarios de todos modos, así que no te molestes 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 adaptarse es establecer un límite de tiempo difícil en cuanto a cuánto tiempo piensa en algo antes de escribir el código. La mayoría de las veces, el código resultará mejor si piensa un poco, escríbalo, comprenda sus errores y luego corríjalos refactorizando.

Hay un equilibrio para ser alcanzado aquí. No solo debes saltar de cabeza y no pensar en las consecuencias, pero tampoco deberías tratar de aplicar ingeniería excesiva a tu código.

Wikipedia lo denomina "Parálisis de análisis" en el 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 intentar establecer prácticas o políticas. Cada colaborador en el equipo es valioso, sin importar qué tan bien o mal estén las habilidades de la persona en relación con los ideales arquitectónicos. En ágil, los individuos, los egos son los primeros, las políticas son las últimas.

Mi respuesta favorita es "La arquitectura es verbo". Deje de pensar, comience a actuar, sin importar cuán imperfectos e ineficientes se sientan usted y el equipo. Quizás las primeras acciones puedan ser el desmantelamiento de políticas inapropiadas.

Hace 40 años, Fred Brooks escribió sobre esto: "Escribe uno para tirar, así lo harás". Nada ha cambiado ........

  

¿Esto está mal? ¿Es esta una evolución natural, o me he metido en una rutina?

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

1. Comience a tirar basura, déjese morder por el culo
2. Comienza a sobre-diseñar el infierno viviente de todo, date cuenta de que YAGNI
3. Establézcase en un punto intermedio pragmático donde las cosas fáciles se combinen y las cosas difíciles / probables reciban ingeniería suficiente para que sea lo suficientemente 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 cierta cantidad de experiencia se vuelve tentador creer que puedes predecir el futuro, pero no puedes. Es fácil imaginar las características que los futuros clientes / usuarios / lo que quieran, pero eso no significa que vayan a quererlos de inmediato. Tampoco significa que vayan a quererlos por alguna otra característica conflictiva. Así que realmente necesita limitar la cantidad de tiempo que pasa hoy planeando para el futuro. Especialmente necesita limitar la cantidad de tiempo que dedica a la construcción de cosas hoy, que solo serán útiles en el futuro.

La pregunta que formulo para mantenerme en línea recta es: "¿cuánto más difícil será crear esta característica más tarde que construir la compatibilidad con esa característica ahora?" Por lo general, la respuesta es que el esfuerzo futuro es más o menos el doble de lo que sería hacerlo ahora. En ese caso, porque no puedo predecir el futuro, no tengo ningún problema en no construirlo ahora. Si la respuesta llega a 10x o más, entonces empezaré a preguntar acerca de qué tan probable es que la gente piense que es 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 es necesario deshacer las cosas que estamos haciendo hoy para lograr ese objetivo en el futuro.

Por ejemplo, trabajé en algunos proyectos donde pasamos mucho tiempo abstrayendo el hecho de que estábamos usando Hibernate como un acceso a datos más tarde. (Nunca he visto el proyecto construido en Hibernate dejar de usarlo, así que, para empezar, fue una pérdida de tiempo, pero dejémoslo a un lado). Incluso si hubiera habido una posibilidad razonable de que quisiéramos cambiar más adelante, porque También estábamos usando un patrón de objetos de acceso a datos, no habría sido más difícil desarrollar la flexibilidad para cambiar Hibernate y cambiarlo al mismo tiempo cuando lo necesitábamos, de lo que era crear la flexibilidad desde el principio. Ante una situación como esa ahora, simplemente pospondría esa flexibilidad hasta que realmente la necesitáramos.

A menos que esté haciendo una planificación estratégica para una gran empresa, casi no vale la pena pensar en cuestiones de arquitectura a más de dos o tres años, porque la tecnología está cambiando muy rápidamente. La característica que puede estar pensando en 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ítate a construir un sistema que haga lo que necesitas hoy, de lo que estés orgulloso, y en el que estarás feliz de trabajar en unos pocos meses, independientemente de la próxima ronda de cambios. Realmente eso es lo mejor que puedes hacer.

Este es mi proceso personal de eliminación de diseños increíbles que (en su primera versión) pueden llegar a ser poco prácticos y dañar un proyecto desde la perspectiva del negocio.

1. Identifique el epicentro : piense en su proyecto como un puesto de hot-dog, el epicentro sería los hot dogs. Puede sacar todas las demás especias / aderezos / vegetales del stand y seguir vendiendo perritos calientes. ¿Cuál es el propósito principal de su software? Aísle cada otra adición y / o valor agregado de ella y céntrese primero en el epicentro.
2. Sigue repitiéndote a ti mismo "hacerlo más tarde significa hacerlo mejor" : observa dónde tiene sentido y pon una pequeña nota "para más tarde" en él. Si lo haces bien y pensando 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 posible (a veces esto se puede lograr sin siquiera eliminar las funciones). Cuando no pueda simplificarlo aún más, comience a desacoplar elementos que podrían vivir por sí mismos y tener 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á un código que no se puede reutilizar, pero siempre agrega ruido al diseño. Este código es el que contiene reglas de negocio. Encontrará que a veces algunas reglas de negocios son más fáciles y rápidas de cambiar ( extremadamente importante ) que con un diseño robusto. Encontrará el código en el que puede confiar y el código que el cliente necesita cambiar o volver a implementar en el futuro. Querrá que se mantengan lo más separados posible.

Y por cierto, el paso 0 es: "volverte loco 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 & 2 de retrabajo .

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

Cuando eres joven, no ves riesgo (posiblemente la razón por la que los políticos jóvenes 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 superiores están estancados). Adopte un de Ocamcam : busque la solución que tenga menos necesidades y luego evolucionar desde allí.

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

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

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

Mi estrategia actual es obtener primero una prueba monolítica de concepto 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é satisfecho de que es viable. Si esperara demasiado para este paso, obtendría algo que no se puede mantener. Si empiezo con las capas separadas, parece que no puedo comenzar, ya que me quedo atascado en lo que la interfaz de usuario necesita saber sobre el modelo.

Cuando me he quedado atascado en situaciones como estas, descubrí que es útil imaginar obstinadamente que soy un usuario final que utiliza el programa hipotético para hacer algo razonablemente trivial. Luego trato de centrarme en lo que serían los puntos de entrada programáticos necesarios para respaldar esas acciones, tratando de ignorar lo más posible otros aspectos del sistema. Desde aquí a menudo es posible construir una "lista de deseos" (pequeña) de características del sistema terminado, y escribir un código poco realista que comience para implementar. Después de ese ejercicio, generalmente empiezo y el resto del sistema comienza a ser más claro. 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íntoma de que las tareas que estás haciendo son demasiado fáciles para ti.

Hace algunos años, el reto para usted era escribir un código que cumpla con la tarea dada. Esto fue lo que enganchó completamente a tu mente. Ahora, su mente (su experiencia, etc.) está funcionando de manera más efectiva y realizar la misma tarea requiere solo una parte de la energía que antes se necesitaba. Esta es la razón por la que terminas en esa espiral de pensamientos profundos. Tu mente se está defendiendo de la rutina y está luchando por un 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 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 el consejo de un colega:

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

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

La respuesta es: SOLO ENTRE CON ELLA ;-)

Publico en un foro de ejercicios y muchas veces la gente publica sobre diferentes rutinas, tratando de encontrar la perfecta perfecta para ellos. Así que les decimos que solo empiecen a entrenar y trabajen a medida que avanza. Quieres ser más fuerte, hacer algunos ejercicios de fuerza y luego modificar las cosas a medida que avanzas.

Cuando tiene un programa grande y su cerebro trabaja horas extraordinarias, primero codifique los casos simples primero. Inicialmente, el programa debe ejecutarse, luego debe tomar entrada, etc.
Tu reto 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 hacer la tarea en cuestión.

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

Código para la siguiente tarea - SOLAMENTE. El código es simple y bueno, por lo que es fácil refactorizarlo si lo necesita. Asegúrese de que el programa funciona. Repetir.

Ya que está "atorado" pensando demasiado en posibles escenarios de uso de usuarios finales, hay algo que considerar aquí si va a publicar una API y espera que personas desconocidas para usted utilicen esa API. . Una vez que se publica una API, debe continuar admitiéndola, aunque más tarde se dé cuenta de lo mala que es su primera versión, o debe descifrar el código de todos, posiblemente desconocidos para usted, que hayan escrito en su contra, lo que supone un riesgo alienante. Para todos los tiempos futuros.

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 lo que los consumidores de API están haciendo.

En esa solución creo que es tu propia solución. Escriba solo una pequeña cosa que haga una o dos cosas, tal vez las haga bien, manteniendo la comprensión de que cualquier cosa que haga puede cambiar en el futuro.

No es posible hacerlo bien, o en algunos casos, incluso CUALQUIERA de ellos, cuando empiezas porque el diseño es realmente un viaje de descubrimiento; Es lo último que emerge, no lo primero que hay que hacer.

No puede diseñar una API de inmediato y nunca debe compartirla con sus consumidores. Entiendes por qué es eso. De la misma manera, no puede escribir software y no es necesario que deseche todo y comience de nuevo con un nuevo enfoque.

No creo que tenga un problema en el sentido de que accidentalmente se ha convertido en algo menos creativo, productivo o deseable. Creo que tiene altos estándares que está aplicando erróneamente accidentalmente a su situación: un error común al pensar que todos cometen.

La experiencia nunca cuenta en tu contra a menos que te conviertas en un sabelotodo cínico, hecho todo, y eso realmente parece lo contrario a tu situación.

Tengo un par de imágenes que tengo en mente cuando voy en grande. Se trata de jugar con el lego. Lo armé y lo desarmé a voluntad. Lo que empiezo a hacer puede que no sea lo que termino haciendo. Navego y me aprovecho de las posibilidades que me vienen a la mente a medida que avanzo, a menudo recreando mis objetivos por completo en un instante de inspiración ... eso es lo que la creatividad ES.

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

No sabes demasiado; ¡No sabes lo suficiente! Y 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 "bien"; hay muchos "errores", pero también hay concesiones (en velocidad de ejecución, tiempo para completar la tarea de codificación, extensibilidad, etc.). El código que escriba si está bien concebido seguirá teniendo 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 actual y futuro no sea tan difícil como escribir código en primer lugar.

No evites los pensamientos profundos, pero recuerda que necesitas experiencia, no solo pensamiento, para convertirte en un maestro en este tipo de diseño. Piense hasta que llegue a un punto en el que no esté seguro de una opción en particular, luego implemente lo que espera que sea la mejor, pruébelo y aprenda de cómo fue.

Practica la codificación. Realice ejercicios o búsquelos en línea e intente terminarlos correctamente lo más rápido posible. Cuando obtenga su velocidad, agregue consideraciones como la capacidad de mantenimiento y el rendimiento. Te darás cuenta de que es refrescante el código que no entrará en producción y podría 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 solo la diversión.

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

No, todavía no sabes lo suficiente.

Enriquece tu conocimiento, por ejemplo. por estas simples reglas:

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

No overengineer. Prepárese para el cambio con 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. Usa interfaces, usa más funciones. Si sientes que has dividido demasiado (es decir, se ha vuelto más sofisticado, pero menos legible), deshace tu último cambio.

En resumen: haga que su código sea lo suficientemente flexible, pero no más. En su lugar, hazte flexible, compra 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 a TDD como una muleta que permite una mala arquitectura. Dada la gran cantidad de opinión popular que funciona en mi contra, 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 hey, no sería la primera vez que la opinión popular en la comunidad de desarrollo se considerara defectuosa años más tarde. Así que aprende a ser un pinchazo arrogante. Al menos en el interior. Puede que estés equivocado, pero al menos estás comprometido con cosas que te funcionen en lugar de pensar demasiado en cosas que podrían no hacerlo.

2. Parece que estás empezando con micro. Comience con macro. Primero, las herramientas que necesitas para hacer las cosas que tu aplicación necesita hacer. Esa parte debería venir con bastante facilidad. Entonces comienza con las preocupaciones de arquitectura / interfaz. La forma en que se conectan las tuberías y con qué se conectan debería ser realmente la parte débil de todo lo que se puede deslizar y reemplazar por un capricho. Igualmente con los detalles de cómo se hacen las cosas. Envueltos 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 maneras y ni siquiera lo notan. Se ha dado cuenta de que puede cambiar su proceso de pensamiento para mantenerse en el camino.

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 pensar en ello. Establecer un temporizador.

Luego, cuando se apague 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 puedes hacer cambios y mejoras más tarde.

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 ocurre incluso para mí. Ser golpeado con desbordamiento de pila. 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 también trabajar con un grupo de nuevas personas puede superar esto, creo.

  

No eres lo suficientemente despiadado

enlace

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