Sobre el desarrollo del pensamiento

88

He estado trabajando como desarrollador de aplicaciones durante un año y medio (no sé mucho), y me dieron mi primer gran proyecto.

No hace falta decir que no salió muy bien, por lo que busqué el consejo de un programador sénior involucrado en el proyecto sobre cómo abordarlo.

Dijo que había terminado drásticamente pensando en la tarea en cuestión, y que porque nunca antes había abordado un proyecto de esta escala, había pasado demasiado tiempo pensando en patrones de diseño. En sus sabias palabras, me dijo "F * ck el futuro, construir por ahora".

¿Es esta una tendencia que los programadores suelen seguir cuando realizan un proyecto como este? Por ejemplo, si le pidieron que hiciera un modelo de prueba de concepto, ¿es una tendencia típica simplemente mezclar un ejemplo viable lo antes posible?

Editar: a la luz del debate que esto ha provocado, me gustaría mencionar que esta situación es bastante extrema: tenemos plazos muy ajustados debido a factores fuera de nuestro control (es decir, el mercado al que apuntamos perderá interés si no lo hacemos) no les muestre algo) y su consejo resultó ser muy efectivo para esta tarea en particular.

sf13579
fuente
55
eso parece más relacionado con la codificación que con el diseño
Balog Pal
22
I + 1-ed solo para "F * ck the future, build for now". Si tiene ganas de respaldar esta declaración, me alegrará darle crédito cada vez que agregue eso a un registro de confirmación después de descartar algo que ingeniosamente diseñé (lo que sucede mucho más de lo que me gustaría).
haylem
13
Me recuerda a un viejo compañero de trabajo que siempre estaba "chapando en oro" sus aplicaciones con demasiadas características, sobredosis de diseño y cosas que no estaban en el requisito para "alardear" o "prepararse para un futuro que nunca llegaría" . Pregunta muy interesante :)
Jean-François Côté
8
@Jean: Los únicos proyectos en los que ocurre "un futuro que nunca llegará" son programas que fracasan (incluso si el proyecto se considera un éxito). Si su programa es exitoso, eso significa que se está utilizando. Si se está utilizando, los usuarios querrán más funciones. Si se adhiere a la filosofía de "compilar por ahora", obtendrá el estado actual de la mayoría del software actual. Basura absoluta, difícil de cambiar. La única razón por la que los desarrolladores pueden salirse con la suya es porque es tan frecuente. Los desarrolladores expertos desarrollarán sistemas más rápido haciéndolo correctamente para empezar y no terminarán con la basura.
Dunk
55
Preguntas como esta son como una prueba de Rorschach. El OP no proporciona suficiente información para saber si en realidad es un sobre-diseñador o si su mentor es un sub-diseñador. En ausencia de información suficiente, todos ven lo que quieren.
PeterAllenWebb

Respuestas:

112

¡Capitán obvio al rescate!

Seré el Capitán Obvio aquí y diré que hay un término medio para encontrar.

Desea construir para el futuro y evitar encerrarse en una elección tecnológica o un mal diseño. Pero no desea pasar 3 meses diseñando algo que debería ser simple, o agregando puntos de extensión para una aplicación rápida y sucia que tendrá una vida útil de 2 años y es poco probable que tenga proyectos de seguimiento.

Es difícil encontrar la distinción, porque no siempre puede predecir el éxito de su producto y si necesita extenderlo más tarde.

Construye por ahora si ...

  • el proyecto va a ser desechado
  • el proyecto tiene una corta vida útil
  • el proyecto no debe tener extensiones
  • el proyecto no tiene un valor de impacto de riesgo (principalmente en términos de imagen)

En general, los proyectos internos o algo construido para un cliente deben desarrollarse por ahora. Asegúrese de tener requisitos directos y relacionarse con ellos según sea necesario para saber qué se necesita y qué no. No quiero pasar demasiado tiempo en algo que sea "agradable tener". Pero tampoco codifiques como un cerdo.

Deje el problema general para más adelante, si alguna vez es necesario y vale la pena el esfuerzo:

XKCD: el problema general

Construir para el futuro si ...

  • el proyecto sera publico
  • el proyecto es un componente para ser reutilizado
  • el proyecto es un trampolín para otros proyectos
  • el proyecto tendrá proyectos de seguimiento o lanzamientos de servicios con mejoras

Si está construyendo para algo público, o que se va a reutilizar en otros proyectos, entonces tiene una probabilidad mucho mayor de que un mal diseño vuelva a perseguirlo, por lo que debe prestar más atención a eso. Pero no siempre está garantizado.

Pautas

Diría que adhiera a los siguientes principios lo mejor que pueda, y debe ponerse en la posición de diseñar productos eficientes y adaptables:

  • saber que YAGNI ,
  • BESO ,
  • cada vez que tenga ganas de rascarse una picazón y piense en una adición, escríbala. Revise los requisitos de su proyecto y pregúntese si las adiciones son prioritarias o no. Pregunte si agregan valor comercial primario o no.

Sé que personalmente tiendo a pensar demasiado y a diseñar demasiado. Realmente ayuda a escribir ideas y muy a menudo repensar si necesito funciones adicionales. A menudo, la respuesta es no, o "sería genial más tarde". Esas últimas ideas son peligrosas, porque permanecen en la parte posterior de mi cabeza, y necesito forzarme a no planearlas.

La mejor manera de codificar sin ingeniería excesiva y sin bloquearse para más adelante es centrarse en un buen diseño minimalista. Divide las cosas muy bien como componentes que luego puedes extender, pero sin pensar ya en cómo se pueden extender más adelante. No puedes predecir el futuro.

Solo construye cosas simples.

Dilema

Sobreingeniería

¿Es esta una tendencia que los programadores suelen seguir cuando realizan un proyecto como este?

Demonios si. Es un dilema conocido, y solo muestra que te importa el producto. Si no lo hace, eso es más preocupante. Existe un desacuerdo sobre si menos es siempre más o no y si lo peor es siempre mejor . Puedes ser un tipo de chico del MIT o de Nueva Jersey . No hay una respuesta fácil aquí.

Creación de prototipos / Quick-n-Dirty / Less es más

¿Es una tendencia típica solo mezclar un ejemplo viable lo antes posible?

Es una práctica frecuente, pero no es cómo se aborda la gran mayoría de los proyectos. Aún así, la creación de prototipos es una buena tendencia en mi opinión, pero con una desventaja media. Puede ser tentador promover prototipos rápidos y sucios para productos reales, o usarlos como base para productos reales bajo presión de gestión o limitaciones de tiempo. Es entonces cuando los prototipos pueden volver para atormentarte.

Dilbert sobre el envío de prototipos directamente a producción

Existen ventajas obvias para la creación de prototipos , pero también un gran potencial para el uso indebido y el abuso (muchas como el resultado inverso exacto de las ventajas enumeradas anteriormente).

¿Cuándo usar prototipos?

Hay pistas sobre los mejores tipos de proyectos para usar prototipos :

[...] la creación de prototipos es más beneficiosa en sistemas que tendrán muchas interacciones con los usuarios.

[...] la creación de prototipos es muy efectiva en el análisis y diseño de sistemas en línea, especialmente para el procesamiento de transacciones, donde el uso de diálogos de pantalla es mucho más evidente. Cuanto mayor sea la interacción entre la computadora y el usuario, mayor será el beneficio [...]

"Uno de los usos más productivos de la creación rápida de prototipos hasta la fecha ha sido como una herramienta para la ingeniería iterativa de los requisitos del usuario y el diseño de la interfaz humano-computadora".

Por otra parte:

Los sistemas con poca interacción del usuario, como el procesamiento por lotes o los sistemas que realizan principalmente cálculos, se benefician poco de la creación de prototipos. A veces, la codificación necesaria para realizar las funciones del sistema puede ser demasiado intensa y las ganancias potenciales que los prototipos podrían proporcionar son demasiado pequeñas.

Y si tienes un monstruo verde alrededor, solo asegúrate de mantener un prototipo dentro del presupuesto ...

Dilbert sobre la extensión de los períodos de creación de prototipos

haylem
fuente
1
No puedo enfatizar lo suficiente lo importantes que son los puntos que ha hecho sobre la creación de prototipos. No creo que esto sea realmente de lo que se trataba la pregunta (principalmente sobre cuándo está bien detenerse y diseñar, en lugar de simplemente construir como lo entiendo), pero la creación de prototipos es definitivamente una parte relevante de ese proceso. ¡Buen trabajo!
Benjamin Gruenbaum
3
Estoy bastante desconcertado de por qué obtendría un voto negativo aquí. Por favor, tenga la amabilidad de dar información sobre eso, para que pueda ver los errores de mis caminos, sensei.
haylem
77
Solía ​​trabajar con un ingeniero mecánico que lo expresaba así: ¿Desea que su producto esté mal diseñado o sobre diseñado? Estas son realmente las dos únicas opciones.
Guy Sirton
1
@SamtheBrand: gracias por la gran edición. Mucho mejor.
haylem
1
@haylem: a veces encuentro que poner ideas en el seguimiento de problemas (si su proyecto es lo suficientemente grande como para tener una) me permite eliminarlas de la parte posterior de mi cabeza. Saber que son visibles para los demás de alguna manera me hace sentir que no necesito revisarlos constantemente en mi cabeza (aunque también hay un acto de equilibrio =]).
afuzzyllama
54

Cuando comienzas a programar, todo es una prueba de concepto, incluso si es solo para ti. Hay casos en que una idea requiere algo rápido y sucio o un prototipo porque el tiempo es un factor clave. El temor masivo entre los desarrolladores es que las partes interesadas piensen que la pequeña aplicación está lista para la producción o que debería poder agregar características al mismo ritmo para siempre. Trabajas en un proyecto grande y descubres que este no es el caso.

Los proyectos grandes generalmente tienen requisitos más complejos, por lo que existe la tentación de intentar implementar diseños complejos. Pasará mucho tiempo leyendo, investigando e intentando implementarlos. Esto puede convertirse en una gran pérdida de tiempo, pero todo es parte del aprendizaje y la adquisición de experiencia. Saber cuándo usar un diseño en particular es difícil y generalmente viene con experiencia. Intenté "eso" en "este" proyecto y no funcionó, pero ahora veo que debería funcionar "aquí".

Tienes que planificar y planificar mucho, pero no lo hagas todo de una vez. Definitivamente no tiene que hacerse todo al principio. Prefiero ver a alguien crear su primer gran proyecto como este:

  1. Diseña y discute un poco.
  2. Escribe un montón de código que haga algo.
  3. Reconocer los problemas y DETENER la codificación.
  4. Tome en serio el diseño y deje de preocuparse por perder el impulso o su código-mojo e ignore al gerente del proyecto (le está haciendo un favor).
  5. Ten el proyecto bajo control. Arregla tus líos. Asegúrese de que todos entiendan el plan. Mantenga el proyecto bajo control.

A veces, usted encuentra una de esas características que realmente le preocupa cómo implementarla en la base de código existente. Este no es el momento para "hacer que funcione". Tuve un jefe que dijo: "A veces tienes que agarrar un taburete en lugar de un martillo". Me dijo esto después de que me sorprendió "pensando" en mi escritorio. A diferencia de muchos jefes, él no asumió que estaba haciendo el tonto y se aseguró de que entendía que quería que yo hiciera más. Genio.

En definitiva, su código es el diseño. Está respaldado por documentos, diagramas, reuniones, correo electrónico, debates en la pizarra, preguntas SO, argumentos, insultos, ataques de ira y conversaciones tranquilas sobre el café. Hay un punto en el que no puedes diseñar más y te arriesgas a tener que tirar más tiempo de diseño debido a las fallas que solo descubrirás al intentar escribir el código. Además, cuanto más código escriba, más posibilidades tendrá de presentar una falla de diseño de la que no pueda salir. Hora de las heces de nuevo.

JeffO
fuente
1
+1 para doing your bosses a favor, incluso si no lo creen así
superM
2
+1 Gran publicación. De hecho, es un buen gerente que reconoce que un buen diseño necesita filtrarse, ¡y esto no implica necesariamente el teclado!
Robbie Dee
¡Argg si solo leyera esta respuesta antes de comenzar! Gracias, y para alguien que recién comienza en esta industria, ¡me encantan estas locas curvas de aprendizaje!
sf13579
2
+1 paraYou have to plan and plan a lot, but don't do it all at once.
Rafael Emshoff
2
@ Geek: mojo, flujo, zona ... o cualquier término geek / trendy / hipster que uno elija para describir un estado de productividad.
haylem
24

¿Los programadores suelen construir algo que funcione ahora sin pensar en el futuro?

Si.

¿Deberían hacerlo?

No.

A primera vista, parecería que "pensar en el futuro" viola los principios de diseño establecidos como KISS y YAGNI , que afirman que no debería implementarse nada que no se requiera en este momento.

Pero en realidad no lo hace. Pensar en el futuro significa diseñar software simple, extensible y manejable. Esto es especialmente importante para proyectos a largo plazo. Se requerirán nuevas características con el tiempo, y tener un diseño sólido facilitará la adición de nuevas piezas.

Incluso si no va a trabajar en un proyecto después de completarlo, debe desarrollarlo de manera inteligente. Es tu trabajo, y debes hacerlo bien, al menos para no olvidar lo bien que se hace el trabajo.

superM
fuente
3
Aunque lo que dices tiene mucho sentido, mi experiencia personal me dice lo contrario. Por lo general, cuando los desarrolladores entran en el modo @F *** k ... simplemente envíalo @ tiende a haber una carga de código pegado copiado en todo el lugar. El resultado final es completamente imposible de mantener. Pensar en el futuro no se trata solo de extensiones y modificaciones, sino también del mantenimiento.
Newtopian
13

Los desarrolladores ágiles tienen un dicho, "No lo vas a necesitar (YAGNI)" que anima a diseñar para lo que necesitas ahora en lugar de lo que crees que podrías necesitar en el futuro. Para extender un diseño para que funcione en el futuro, la ruta recomendada es refactorizar.

El aspecto importante de esto es tener en mente los requisitos de su producto a medida que diseña y asegurarse de que no está diseñando para un conjunto de requisitos que podrían suceder en el futuro.

Hay algo que decir para los desarrolladores que pueden pensar dos o tres iteraciones por adelantado: conocen a sus clientes o al dominio tan bien que pueden anticipar las necesidades futuras con altos grados de precisión y construir para ellos, pero si no está seguro, Es mejor no pasar demasiado tiempo en cosas que usted o los clientes no necesitan.

usuario93143
fuente
1
También hay otras razones para pensar en el futuro: que la funcionalidad que está desarrollando no cabe en un sprint. Entonces, o lo divide artificialmente, o se niega a implementar cualquier funcionalidad que no pueda completar en un solo sprint.
Giorgio
+1 por mencionar refactorización. No puedo creer que ninguna de las otras respuestas hasta ahora mencione esto. YAGNI solo es viable si refactoriza.
Ian Goldby
7

¿Es esta una tendencia que los programadores suelen seguir cuando realizan un proyecto como este?

Sospecho que lo que su mentor quiso decir es que no debe incorporar ninguna complejidad adicional que la solución final no requiera.

Es demasiado fácil pensar que una aplicación debería hacer esto y aquello y desviarse masivamente.

En cuanto a los patrones de diseño, vale la pena recordar que son un medio para un fin. Si encuentra con experiencia que cierto patrón de diseño no se ajusta a pesar de su presentimiento anterior, entonces esto podría indicar un olor a código.

Por ejemplo, si le pidieron que hiciera un modelo de prueba de concepto, ¿es una tendencia típica simplemente mezclar un ejemplo viable lo antes posible?

Vale la pena obtener una dirección antes de que comience el proyecto en cuanto a qué hitos hay y si querrán ver un poco de todo (corte vertical) o solo cada parte en detalle a medida que se desarrolla (corte horizontal). Como parte del diseño inicial, considero que vale la pena abordar toda la aplicación, por lo que, aunque el código no esté escrito, puede hacer una vista en helicóptero de todo o una inmersión profunda de un área determinada.

Robbie Dee
fuente
6

Dijo que había terminado drásticamente pensando en la tarea en cuestión, y que como nunca había abordado un proyecto tan grande como este, había pasado demasiado tiempo pensando en patrones de diseño. En sus sabias palabras, me dijo "F * ck el futuro, construir por ahora".

Creo que esa es una mentalidad de vaquero del otro desarrollador. La versión moderna de un nerd duro que simplemente "lo hace ahora". Se ha convertido en un tema popular entre las nuevas empresas y no, gracias a la gente de Facebook por comenzar la frase "hacerlo es mejor que hacerlo bien".

Es atractivo. Es alentador y ofrece visiones de desarrolladores parados alrededor de una consola que aplauden mientras lanzan su gran proyecto al mundo a tiempo, dentro del presupuesto y todo porque no hicieron demasiado ingeniería.

Es una fantasía idealista y la vida no funciona de esta manera.

Un tonto se apresurará a un proyecto pensando que simplemente puede "hacerlo" y hacerlo. El éxito favorecerá al desarrollador que se prepara para los desafíos invisibles y trata su profesión como una excelente artesanía.

Cualquier desarrollador senior puede criticar, condenar y quejarse, ¡y la mayoría lo hace!

Mientras él / ella le dice que está "pensando demasiado" en el proyecto. Te felicito por realmente "pensar" primero. Has dado tus primeros pasos para ser un mejor desarrollador que el otro tipo.

¿Es esta una tendencia que los programadores suelen seguir cuando realizan un proyecto como este? Por ejemplo, si le pidieron que hiciera un modelo de prueba de concepto, ¿es una tendencia típica simplemente mezclar un ejemplo viable lo antes posible?

Eso es exactamente lo que es una prueba de concepto. Es un intento de eliminar algo lo más rápido posible para que las personas puedan dar un paso atrás y mirarlo. Se hace para evitar errores, direcciones erróneas y pérdida de tiempo / dinero.

Hay muchos tipos diferentes de prueba de conceptos. Puede construir algo que se tira a la basura cuando haya terminado, o puede construir algo que represente un punto de partida para el proyecto. Todo depende de lo que necesite y de lo cerca que esté el concepto del producto final.

También es una oportunidad para demostrar tus ideas. Ha habido momentos en que presenté un prototipo que llevó las cosas a un nivel que no esperaban.

Reactgular
fuente
1
+1 por mencionar la plaga de pseudo-mentores en Internet
FolksLord
5

El diseño generalmente es abierto, por lo que es demasiado fácil aplicar demasiado o muy poco. Y sabrá la cantidad correcta solo después de que el proyecto esté terminado o descartado. O incluso no entonces.

No existe una receta general para el éxito, pero puedes aprender a reconocer los extremos. El diseño completo de todo por adelantado casi nunca funciona más allá de cosas triviales. Está bien dejar componentes para refinar y simplemente tener la sensación de que se puede hacer, o hay una manera de descubrir problemas temprano.

Puede consultar cómo funciona el desarrollo incremental si no está familiarizado. Los métodos exitosos generalmente son iterativos en uno o más niveles, buscan comentarios estrictos y crecen en algún esqueleto.

Balog Pal
fuente
3

Hay algunas buenas razones para escuchar los consejos para dejar de planificar y comenzar a codificar;

  1. Después de solo 18 meses como desarrollador, es poco probable que pueda anticipar el futuro lo suficientemente bien como para planificarlo, sin importar el promedio de calificaciones de su universidad. Esto es algo extremadamente difícil de comprender para los desarrolladores brillantes pero sin experiencia, ya que se trata de no saber lo que no se sabe. Las viejas manos pueden haber reconocido esta debilidad en su visión, y sabiamente lo alentaron a entrar en ella y hacerlo lo mejor posible.

  2. Los desarrolladores jóvenes pueden obsesionarse con perfeccionar el diseño antes de comenzar a codificar. Pueden estar cubriendo el miedo a escribir el código (ansiedad de rendimiento), o pueden tener un bloqueo del codificador (como el bloqueo de los escritores). Se retrasan en el diseño porque no se requiere salida de trabajo. El joven desarrollador probablemente responderá con enojo a la sugerencia de que tienen "miedo" de algo. Quizás al final del proyecto se darán cuenta de que sí. El consejo de no preocuparse y obtener codificación constituye la única cura conocida para el bloqueo del codificador. Una vieja mano sabiamente puede ofrecer este consejo.

  3. En presencia de severas restricciones de programación, sus posibilidades de realizar el proyecto son limitadas. Planifique demasiado tiempo, y no importa cuán bueno sea el plan, no puede ejecutarlo a tiempo y nunca llegará al mercado. Comienza a hackear desde el principio, y tal vez tengas suerte y tengas razón la primera vez. Entrega el producto milagrosamente. O, tal vez no tienes tanta suerte, y entregas una pieza de escoria a medio cocer, pero llega al mercado a tiempo y aprendes algo. O tal vez fallas. Pero "tal vez fallas" es aún mejores probabilidades que "nunca llegaste al mercado" porque planeaste demasiado tiempo. La comprensión clave es que sus posibilidades son limitadas desde el principio, por lo que no pierde nada al piratear. Su gerente puede saber que hay pocas posibilidades de éxito y le asignó un recurso junior solo como un ejercicio de aprendizaje. Aprendemos mejor del fracaso que del éxito. Quizás has estado preguntando, "¿Cuándo puedo tener un proyecto completo?"

Se necesita un desarrollador bastante introspectivo y libre de ego para ver sus propias imperfecciones, así que medita un rato antes de leer el resto de esto, para que no tengas excusas para pasar por alto tus propias debilidades ...

No todos los desarrolladores son particularmente buenos en análisis, planificación y otras tareas que requieren reflexión. El pensamiento es duro y repulsivo. Requiere un tipo de sudor mental que te deja incómodo y exprimido después de un día de trabajo. Simplemente no es tan divertido como entrar en estado de flujo con sus dos latas de Monster y su roca sonando fuerte y codificando, codificando, codificando. Los desarrolladores a los que no les gusta pensar resistirán la idea de que planificar es una buena idea. Recomiendan metodologías de desarrollo que no requieren una planificación inicial. Les gustan las empresas y los gerentes que no enfatizan la planificación. Gravitan hacia trabajos donde el costo de no planificar no es demasiado alto. Valoran todas las sesiones nocturnas de codificación y hacen llegar ese hotfix a los clientes cuyo negocio no funciona debido a un error.

Algunos desarrolladores incluso se han dado cuenta de que hacer que algo funcione lo suficientemente bien como para hacer una demostración significa que hacer que funcione por completo y, en todas las circunstancias, puede diferirse, y tal vez incluso posponerse en otro desarrollador, mientras reciben elogios por "hacer el trabajo" inicialmente.

Hay gerentes que no pueden detectar una tendencia hasta que ya se está rompiendo en Facebook. En lugar de encontrar un trabajo administrando una tienda de neumáticos con descuento, estos gerentes hacen que sea un problema que necesiten que el código se ejecute antes del viernes. No quieren saber que necesita diseñar la API o probar si su algoritmo es escalable. Esto es solo tecnología mumbo-jumbo para ellos. Lo alentarán a codificar porque es todo lo que entendieron sobre el software cuando escribían scripts en perl para ayudar a los clientes a transferir sus archivos. (Tenían el título de "ingeniero de software" en su primer trabajo de ventas. ¿Quién sabía que el software iba a ser tan aburrido y difícil?)

SeattleCplusplus
fuente
-6

Muéstrame tu código y te diré quién eres

Su código es su tarjeta de visita. Si escribes código desordenado, ¿qué te cuenta sobre ti a las otras personas? Solo piensa en eso. Cada vez que encontramos en la oficina un fragmento de código realmente malo, nos preguntamos, ¿quién lo escribió y cómo demonios pasó por la universidad?

Te estás convirtiendo en lo que codificas

Tu código es tu programa de por vida.

Un programador que escribe un código incorrecto es como un bailarín de ballet que baila en un club de striptease

A algunas personas no les importa bailar en un club de striptease. Pero si son bailarines de talle alto, están desperdiciando sus habilidades. Si eres un bailarín pobre pero tienes buenas piernas, puedes desnudarte para muchos.

Finalmente, deberías leer la novela de Gogol 'The Portrait', y la historia del personaje principal debería advertirte. Tu amigo es similar al hombre del retrato. Te está atrayendo con dinero, pero pagarás el alto precio por ello.

La gente
fuente
44
No pedí a la gente que hiciera comentarios personales sobre mi mentor, pregunté dónde estaban los límites con respecto a los patrones de diseño de pensamiento excesivo. "Atraerlo con dinero" es una suposición estúpida e irrelevante, y en realidad no es el que me paga.
sf13579
44
Juzgar la inteligencia de alguien en base a un fragmento es ridículo. No hay un desarrollador vivo que no tenga su nombre en al menos una pieza de código desordenado.
Brian Green