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.

¡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:

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.

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 ...

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.

¿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.

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.

¿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.

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.

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.

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?)

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.