Francamente, ¿prefieres la codificación Cowboy? [cerrado]

La mayoría de los programadores que defienden metodologías políticamente correctas como Agile, Waterfall, RUP, etc. Algunos de ellos siguen la metodología pero no todos. Francamente, si puede elegir la metodología, seguramente iría a las metodologías "correctas" o preferiría la metodología "más fácil" como la programación de vaqueros. ¿Por qué?

Sé que depende Por favor, explique cuándo usaría uno u otro. Por favor, diga qué ventajas ve en la codificación Cowboy.

Ver sobre la codificación Cowboy en Wikipedia

Creo que casi todos los programadores experimentados han pasado por tres etapas y algunos pasan por cuatro:

1. Los codificadores o pepitas de vaquero saben poco o nada sobre el diseño y lo ven como una formalidad innecesaria. Si se trabaja en proyectos pequeños para actores no técnicos, esta actitud puede ser útil por un tiempo; hace las cosas, impresiona al jefe, hace que el programador se sienta bien consigo mismo y confirma la idea de que sabe lo que está haciendo (aunque no lo sepa).

2. Los astronautas de la arquitectura han sido testigos de los fracasos de sus primeros proyectos de bola de hilo para adaptarse a las circunstancias cambiantes. Todo debe reescribirse y para evitar la necesidad de otra reescritura en el futuro, crean plataformas internas y terminan pasando 4 horas al día en soporte porque nadie más entiende cómo usarlas correctamente.

3. Los cuasi-ingenieros a menudo se confunden con ingenieros reales y capacitados porque son realmente competentes y entienden algunos principios de ingeniería. Conocen los conceptos empresariales y de ingeniería subyacentes: riesgo, ROI, UX, rendimiento, mantenibilidad, etc. Estas personas ven el diseño y la documentación como un continuo y generalmente pueden adaptar el nivel de arquitectura / diseño a los requisitos del proyecto.

   En este punto, muchos se enamoran de las metodologías, ya sean Agile, Waterfall, RUP, etc. Empiezan a creer en la infalibilidad absoluta e incluso en la necesidad de estas metodologías sin darse cuenta de que en el campo real de la ingeniería de software, son meras herramientas. , no religiones. Y desafortunadamente, les impide llegar a la etapa final, que es:

4. Los programadores de cinta adhesiva o los gurús de AKAo consultores altamente remunerados saben qué arquitectura y diseño van a utilizar dentro de los cinco minutos después de escuchar los requisitos del proyecto. Todo el trabajo de arquitectura y diseño todavía está sucediendo, pero está en un nivel intuitivo y está sucediendo tan rápido que un observador no capacitado lo confundiría con la codificación del vaquero, y muchos lo hacen .

   En general, estas personas tienen que ver con la creación de un producto que sea "lo suficientemente bueno" y, por lo tanto, sus trabajos pueden estar un poco poco diseñados, pero están a kilómetros del código de espagueti producido por los codificadores de vaqueros. Las pepitas ni siquiera pueden identificar a estas personas cuando se les dice acerca de ellas , porque para ellos, todo lo que sucede en el fondo simplemente no existe.

Es probable que algunos de ustedes piensen en este punto que no he respondido la pregunta. Eso es porque la pregunta en sí es defectuosa. La codificación de vaquero no es una opción , es un nivel de habilidad , y no puedes elegir ser un codificador de vaquero más de lo que puedes elegir ser analfabeto.

Si eres un programador de vaqueros, entonces no sabes de otra manera.

Si te has convertido en un astronauta de la arquitectura, eres física y psicológicamente incapaz de producir software sin diseño.

Si usted es un cuasi-ingeniero (o un ingeniero profesional), completar un proyecto con poco o ningún esfuerzo de diseño inicial es una elección consciente (generalmente debido a plazos absurdos) que debe sopesarse contra los riesgos obvios y emprenderse solo después de que los interesados ​​los hayan aceptado (generalmente por escrito).

Y si usted es un programador de cinta adhesiva, entonces nunca hay ninguna razón para "código vaquero" porque puede construir un producto de calidad con la misma rapidez.

Nadie "prefiere" la codificación de vaqueros sobre otras metodologías porque no es una metodología. Es el equivalente de desarrollo de software de mezclar botones en un videojuego. Está bien para los niveles de principiante, pero cualquiera que haya pasado esa etapa simplemente no lo hará. Pueden hacer algo que se parezca, pero no será lo mismo.

Si.

También prefiero dejar mis calcetines en el piso donde me los quité, mi escritorio cubierto con impresiones y viejos envoltorios de refrigerios, mi fregadero lleno de platos sucios y mi cama sin hacer.

No considero que las vacaciones planificadas con anticipación sean unas vacaciones adecuadas, una comida que se toma con la mente puesta en la nutrición, una alimentación adecuada o permanecer en senderos conocidos como caminatas adecuadas.

Me gusta divertirme, sorprenderme, aprender cosas nuevas, cometer errores y nunca estar seguro de si voy a volver. Y a veces, esa actitud es exactamente lo que se requiere para poner en marcha un proyecto ...

... pero la mayoría de las veces, es irresponsable. Cuando termina el baile, se le pagará al gaitero ... Olvídese de esto bajo su propio riesgo.

Estás exactamente en lo correcto. Este enfoque de "programación vaquera" puede hacer que la primera revisión del código se publique más rápido, pero ese ahorro de tiempo se perderá con creces gracias a:

• Errores adicionales
• Tiempo adicional necesario para encontrar los errores que habría tenido de todos modos
• Tener que aplicar ingeniería inversa a su código para recordar lo que hizo cuando necesita hacer un cambio en seis meses
• Tiempo extra dedicado a capacitar desarrolladores adicionales que necesitan trabajar en su código
• No tener un registro de revisiones para mirar hacia atrás cuando haces un cambio que rompe algo
• Al no tener módulos, puede reutilizarlos fácilmente en proyectos posteriores
• y sigue y sigue y sigue

Como Neil Butterworth mencionó en su respuesta, a veces tienes que hacer lo que tienes que hacer. Sin embargo, como práctica general, no, eliminar el código lo más rápido posible sin perder el tiempo en el control del código fuente, patrones, documentación, etc. es un mal hábito.

Es bueno para usted analizar sus compañeros de trabajo y considerar si sus hábitos son beneficiosos o perjudiciales en lugar de hacer a ciegas lo que hacen.

Esto realmente se reduce a la cuestión de si puede implementar las cosas correctamente o no sin una estructura ajustada y mucho tiempo en la planificación.

Voy a arrojar algo aquí sobre esto que puede ser realmente impopular: los clientes generalmente quieren que las cosas se manejen de manera vaquera .

Es decir, quieren solicitar que se haga algo y que alguien salte sobre él, lo ejecute y lo publique. Sin gestión de proyectos, reuniones, llamadas de conferencia o formularios. Simplemente hazlo. Nunca he tenido un cliente que diga "hey, esto se hizo demasiado rápido para nuestros gustos, le agradeceríamos que pusiera una pequeña cascada o algo allí la próxima vez".

Las metodologías y la estructura del equipo están diseñadas para nivelar el campo de juego de un proyecto y obtener diferentes niveles de desarrolladores en la misma página, trabajando para los mismos objetivos, de la misma manera.

Los exitosos "vaqueros" con los que he trabajado pueden:

• Identifique la forma más sencilla de implementar algo rápidamente
• Sepa en qué punto se romperá
• Escriba código limpio, legible y sencillo
• Predecir cómo lo usarán los usuarios, abusar de él y romperlo
• Escala / abstrae en los lugares correctos, y no te vuelvas astronauta de arquitectura
• Sepa dónde y cómo manejar casos extremos y excepciones

Las personas como esta producen resultados realmente excelentes con muy poca administración y gastos generales de estructura, pero son raros.

EDITAR: Para referencia futura, mi respuesta es para otra pregunta, que se ha fusionado en esta. Está bastante fuera de lugar aquí, pero esa no era mi decisión.

Ella es perezosa, arrogante, ignorante y extremadamente egoísta. Este comportamiento es imprudente.

Quiero decir, no es que ella use una metodología poco convencional o quizás anticuada. Ella conscientemente no usa ninguno . No hay normas Sin garantía de calidad. No, en absoluto. ¿De dónde espera que venga la calidad del software? Árboles?
Es curioso que en realidad niegue la experiencia de las personas que usted cita, cuando obviamente carece de ella. Es válido proporcionar argumentos verificables y relevantes para cuestionar sus afirmaciones. Pero tratar de desacreditarlos negando su experiencia no lo es.

Pero, el punto principal es: ¿Cuánto tiempo lleva el control de versiones?
Si no puede convencerse de que invierta los 5 segundos de vez en cuando, debe llevarlo a su jefe. El control de versiones no es opcional. Punto final.

Y una vez que la tiene usando el control de versiones, puede rastrear fácilmente qué errores introdujo. Y deja que ella los arregle. Es su desastre, ¿por qué deberías limpiarlo? Si cree que su enfoque es mejor, entonces déjelo hacerlo todo el tiempo .
Asumiendo que ella realmente puede hacerlo (dentro de un tiempo razonable), todavía tienes un problema: el trabajo en equipo con ella es casi imposible. Y esto es algo que tendrá que resolver convenciéndola (lo que parece poco probable), haciéndola irse (por el bien de su compañía) o irse (por el bien de su cordura).
Pero su fracaso en primer lugar es mucho más probable y definitivamente debería probar su punto. Y luego comenzará a adherirse a las mejores prácticas como lo hacen muchas personas con mucha experiencia.

Depende completamente de si estoy trabajando solo o en equipo.

Si trabajo en un equipo, se requieren algunas convenciones y acuerdos: todos en el equipo deben seguir algún estándar comúnmente acordado para trabajar hacia el objetivo común para que sus esfuerzos sean compatibles.

Pero si trabajo solo, entonces, por supuesto, quiero ser un vaquero. Todas las grandes creaciones en el mundo han sido inventadas por una sola mente, o como máximo dos, trabajando al estilo vaquero. Sólo para nombrar unos pocos:

• ¿Mecanica clasica? Vaquero Isaac Newton, adiciones posteriores de Leibniz, Lagrange, Hamilton.
• ¿Avión? Vaqueros Wright.
• ¿Teoría de la relatividad? Vaquero Albert Einstein.
• Ciencia fundamental de las computadoras? Vaquero Alan Turing.
• ¿Transistor? Vaqueros Walter Brattain y John Bardeen.

Los equipos son buenos para hacer mejoras incrementales y armar nuevos sistemas basados ​​en recetas comprobadas con bastante rapidez (siempre que estén bien guiados), pero es raro escuchar sobre una invención real hecha por un equipo. El trabajo en equipo y los métodos que requiere tienen sus virtudes, pero también lo tiene la codificación de vaqueros.

Depende del problema. Un buen desarrollador senior escribirá un código muy compacto, simple y robusto que sea muy estable y utilice todas las mejores prácticas sin pasar por páginas de documentación y toneladas de patrones y paradigmas diferentes. Pero también sabrá cuándo puede permitirse hacer tales cosas.

Me sorprendería si él tomara un nuevo problema y comenzara a diseñar una aplicación que requiera muchos meses desde cero. Pero si es un complemento, una herramienta simple que puede escribir en 2 horas, una función que realiza algunas conversiones y no está destinada a una reutilización, el diseño y los patrones en realidad solo son buenos para perder el tiempo.

Además, supongo que gran parte del diseño ya se procesó en un hilo de fondo en algún lugar dentro del jefe de desarrolladores senior.

Debe comenzar a preocuparse cuando el desarrollador principal comience a producir clases de un sistema complejo o nuevas aplicaciones desde cero, y sin necesidad de planificar.

Depende de las circunstancias. Por ejemplo, después de algunos escándalos comerciales desastrosos, varias bolsas de valores electrónicas insistieron en que se agregaran banderas de comercio automático a todas las transacciones. Y esto tenía que ser para todo el software comercial dentro de una semana. Quiero decir que tenía que hacerse, si la bandera no estaba allí, no se podía comerciar. En circunstancias como esa, todas las buenas prácticas son aprobadas por el consejo, solo tienes que ir (como solíamos decir) "hacky, hacky, hacky". Y en esas circunstancias, escribir código de forma rápida y precisa es clave. Particularmente porque no había sistemas de prueba disponibles.

Desde mi experiencia, la codificación de cowboy CON control de fuente es la mejor y más libre de errores para desarrollar grandes sistemas de software.

Creo que uno de los comentaristas tenía razón: todo se trata de los resultados.

Si la persona puede producir un buen producto, algo que hace lo que se supone que debe hacer y es sostenible y confiable , entonces, ¿qué importa si se siguen metodologías o procesos formales? Los procesos son excelentes para garantizar un piso de calidad, pero si alguien ya está trabajando por encima de ese piso, entonces los procesos no agregan nada a la ecuación. En la actualidad, demasiados desarrolladores parecen pensar que el objetivo de la programación es adherirse a los procesos, en lugar de producir un buen producto.

Este tipo de persona se llama hacker, y generalmente no es un término complementario del más profesional entre nosotros.

Como habrá notado, el tiempo ahorrado en diseño, organización y control se pierde en la depuración. Y a menudo para encontrar qué versión de código fue la que realmente se envió. ¡Si puedes encontrarlo!

Encuentro que este tipo de persona está demasiado envuelta en sí misma, creo que es demasiado buena para trabajar con las 'limitaciones' que otros tienen que sufrir y, por lo tanto, no se moleste con ellas, y eso pierde aún más tiempo que el resto del mundo. El equipo tiene que limpiar después de ellos. Tampoco están demasiado involucrados en el proceso de corrección de errores (esa es una tarea del desarrollador de mantenimiento, muy por debajo de las habilidades y el talento del 'l33t codificador).

Por lo tanto, podría ser un enfoque común en otros lugares, pero en mi lugar (y soy un codificador principal que tiene tendencias a este enfoque, ejem) no lo sufrimos. No es que exijamos una tonelada de procesos y procedimientos, pero sí insistimos en una cantidad mínima de organización, control del código fuente (que para ser sincero, ¡es sangriento al este y muy útil!)

Kent Beck et al, son todos profesionales que vieron que las viejas formas cargadas de procesos eran malas en sí mismas, por lo que crearon nuevas metodologías para organizar la codificación mientras la mantenían más orientada a la artesanía, y luego se lo contaron a todos los demás al publicar libros ( ¿De qué otra forma lo hiciste antes en Internet?)

Parece que tiene razón: no acepte malas prácticas solo porque alguien más no pueda piratearlas. El líder o gerente de tu equipo debería ser duro con esta 'estrella de rock', pero si no lo son ... bueno, eso aún no te impide hacer lo correcto. Simplemente no aceptes una práctica de mala calidad por parte de ella, si se equivoca (¡y lo hará!), Entonces déjala que la limpie. Se apega a las buenas prácticas (y sabe cuáles son) sin dejar que se hagan cargo en detrimento de su productividad de codificación, y será bueno para el futuro.

Aquí hay un ensayo de un escritor verdaderamente perspicaz. No soluciona su problema, pero le da algunas ideas de por qué es así y tal vez algunos consejos para tratarlo profesionalmente.

El único hecho importante son los resultados del producto a largo plazo del equipo.

Existe la afirmación de que un equipo que incluye un gran programador (o más) producirá mejores resultados que un equipo con un número aún mayor de programadores promedio que codifican a una tasa promedio.

Si el vaquero produce cosas que los programadores habituales no hacen (para un plazo determinado o una especificación), y el equipo con el vaquero incluso tiene que pasar unas pocas semanas / meses para limpiar el desorden del vaquero, aún podrían terminar con el Mejor resultado antes.

Si el equipo con el vaquero no puede limpiar (documentar, depurar, integrar, mantener) el desorden incluso después de muchos hombres meses / año, entonces cualquier avance que haya creado el vaquero no le dio al equipo una ventaja a largo plazo.

Decide cuál y optimiza la lista del equipo.

No todos los programadores trabajan (o deberían funcionar) de la misma manera, siempre que el resultado final sea bueno.

Puede encontrar alguna idea en mi respuesta a Frankly, ¿prefiere la codificación de vaquero? El problema es que "codificación de vaquero" significa cosas diferentes para diferentes personas, y no es inmediatamente obvio, para el ojo inexperto, qué versión estás viendo.

Cuando alguien puede ver un problema e inmediatamente comenzar a descifrar el código, de manera rápida y precisa, ese puede ser el signo de un ingeniero maestro que lo ha visto mil veces antes y que ya sabe la mejor manera de resolver el problema.

O puede ser el signo de un aficionado de rango.

Le diré una cosa: negarse a usar el control de versiones o escribir pruebas porque son demasiado "académicas" definitivamente no es un enfoque "senior" o incluso remotamente profesional. Nunca verás este tipo de cosas en una tienda de software importante como Microsoft o Google, y probablemente tampoco lo verás en la mayoría de las startups o equipos empresariales razonablemente maduros.

Los riesgos son demasiado grandes. ¿Qué pasa si tu PC muere de la noche a la mañana? Adiós 3 años de productividad. Bien, entonces haces copias de seguridad; entonces, ¿qué sucede cuando haces un cambio importante, te das cuenta de que estaba completamente mal y tienes que revertirlo? Esto sucede incluso para los desarrolladores más experimentados y talentosos porque los requisitos son incorrectos. Si no está ejecutando ningún tipo de control de versión, solo va a girar las ruedas en el barro. He estado allí, una vez, y nunca volvería.

Simplemente no hay excusa: se necesitan 10 minutos para configurar un repositorio y 10 segundos para realizar una confirmación. Constituye quizás el 1% de su tiempo total de desarrollo. Las pruebas, si tiene prisa, pueden reducirse fácilmente a 20-30 minutos al día y seguir siendo razonablemente útiles.

No soy fanático de las metodologías ágiles (tenga en cuenta la A mayúscula), pero a veces realmente necesita arremangarse y comenzar a escribir el maldito código. He visto personas y equipos con "parálisis de análisis" y la productividad realmente tiene un impacto visible. Pero el despido de las herramientas básicas de nuestro comercio , como el control de revisión y las pruebas, es realmente el factor decisivo para mí; esta persona no pertenece a un puesto superior.

Sí, pero debes reconocer cuándo NO hacerlo.

En cualquier cosa pequeña, probablemente estés bien, pero si tienes algo complejo, peligroso, limitado, etc., debes ser capaz de reconocer cuándo un diseño adecuado vale el tiempo extra.

También creo que definitivamente deberías pensar en la respuesta de Aaronaught. Vaquero significa cosas diferentes para diferentes personas.

Cuando pienso en metodologías "tradicionales", creo que "la gerencia no sabe cómo entender a los desarrolladores, por lo que en lugar de entrar al mundo de los desarrolladores y comprender lo suficiente como para saber qué está pasando, hacen que los desarrolladores entren en su mundo".

Básicamente, cuando pienso en "Agile", pienso que "haces lo que tienes que hacer para minimizar las ineficiencias introducidas por varias personas que trabajan juntas". Así que estoy firmemente en el campo que "no hay tal cosa como la metodología ágil , más que un conjunto de valores y principios".

En otras palabras, hay cosas que debe hacer en un proyecto muy grande, y hay cosas que debe hacer en proyectos pequeños, y hay cosas que debe hacer en ambos.

Por ejemplo, no tendría más que los retrasos más simples para un proyecto en el que estoy trabajando ... Simplemente sería una lista de tareas pendientes. Si hay dos de nosotros, probablemente tenga esa lista compartida, pero en un formato muy simple (probablemente solo una nota almacenada en nuestro repositorio de código). Una vez que tengo 3 o 4, estoy buscando algún tipo de sistema de elementos de trabajo.

Solo cuando se crean prototipos de características muy simples.

Luego, una vez hecho y considerado de la manera correcta, abandono el código y me pongo serio.

Lo hice una vez en un proyecto real (en el momento en que lo llamamos Programación Samurai, después de la serie de bocetos Samurai Tailor en Saturday Night Live), y para mi sorpresa, funcionó bien. Por supuesto, comencé con basura, por lo que había poco riesgo de empeorarla.

Sin embargo, soy un "ordenado" de corazón y no me gusta el estilo de desarrollo de disparar desde la cadera.

Por otro lado, el modus operandi muy cargado de procesos tampoco es de mi gusto. Solo me gusta planificar antes de actuar.

En general, creo que la cantidad de proceso formal que es apropiada depende en gran medida de la magnitud (tamaño del código, duración del proyecto, número de desarrolladores, tipos de requisitos, etc.) del proyecto. Quiero que se impongan rigurosos y estrictos criterios a las personas que desarrollan el software para equipos de aviónica o biomédicos, por ejemplo, para juegos, por ejemplo, hay muchos menos inconvenientes para cualquier falla, por lo que el costo y la carga de las prácticas de desarrollo rigurosas y metódicas no es realmente justificado.

Depende (en gran medida) del tamaño del proyecto. Por un lado, para obtener un resultado decente necesitas tener un diseño. Por otro lado, si el proyecto es lo suficientemente pequeño como para que pueda conceptualizar todo el diseño (de todos modos, es la mayoría) sin escribirlo, dibujar diagramas, etc., entonces probablemente esté igual de bien sin ese trabajo adicional de documentando todo lo que haces.

Casi todo el mundo ha escuchado suficientes historias de terror para darse cuenta de que tratar de saltar sin tener una idea clara de lo que está haciendo y hacia dónde van las cosas es una receta para el desastre. Lo que es mucho más raro señalar es que lo contrario puede ser igualmente desastroso. Solo por ejemplo, la mayoría de nosotros habitualmente escribimos pequeñas herramientas en el proceso de programación. Escribir una especificación completa, pruebas, documentación a menudo simplemente no vale la pena. Hay un umbral por debajo del cual la productividad no vale la pena: a las personas a menudo no les gusta reinventar la rueda, pero en algunos casos es más fácil reinventar que evitarlo.

En casos como este, lo que a menudo es vale la pena es productizing una biblioteca para hacer este tipo de tareas fáciles. Con eso, el código de front-end a menudo se vuelve tan trivial que escribir (o modificar) el código para hacer lo que desea se vuelve más fácil que resolver cómo obtener un programa completo para hacer lo que desea. Considere, por ejemplo, la sangría de ñu con sus más de 50 banderas diferentes, muchas de las cuales interactúan de varias maneras sutiles, por lo que las únicas opciones razonables son 1) no usarlo en absoluto, o 2) decidir si le gusta lo que le da en lugar de tratar de obtener lo que originalmente quería.

Parece haber dos campos: los que favorecen los resultados y los que favorecen los principios. Caigo en lo último.

Soy un programador mediocre pero posiblemente concienzudo: mi principal preocupación al codificar, más allá de hacer el trabajo, es que estoy ayudando a quien use mi código para hacer SU trabajo. No puedo decir que siempre lo haya logrado, pero eso es lo que pretendo hacer.

Claro, es posible que tengas un hotrod en tu equipo, pero ¿qué sucede cuando se toman un par de semanas y te piden que depures su trabajo o le agregues cosas? En definitiva, los programadores de vaqueros no son jugadores de equipo. Pueden hacer un gran código, pero si el equipo depende de ellos, entonces es peligroso.

Tengo la sensación de que tu disgusto por su estilo está causando que lo tergiverses un poco. Usted dice que el enfoque de vaquero se paga en la depuración : ¿es esto lo que ya está sucediendo o es su suposición de cómo se desarrollará?

Divulgación justa: yo mismo soy un desarrollador sénior y, a menudo, renuncio a un proceso formal para el diseño y la experiencia. No tener un proceso formal para alguien que tiene mucha experiencia en el dominio del problema es bastante común. Si ha resuelto un problema docenas de veces, no necesita un proceso formal para formular una solución similar nuevamente.

Un proceso formal se ocupa del diseño del código: no veo por qué deberían introducirse más errores porque falta un proceso formal. El único gran problema que leí en su cuenta es que no se está utilizando el control de revisión, lo que no solo es egoísta, sino que es totalmente imprudente en nombre del desarrollador. ¿De hecho no se está comprometiendo en absoluto, o simplemente no se está comprometiendo en un patrón que sea de su agrado?

No tener un enfoque formal del diseño no es 'codificación de vaquero' en mi libro (sin embargo, no usar el control de revisión). La experiencia debe usarse exactamente para eso: para reducir el tiempo necesario para llegar a una solución "suficientemente buena". Recuerde, tiene que resolver los problemas que tiene actualmente y hacer que el código sea fácil de cambiar, no diseñar para escenarios futuros que tal vez nunca sucedan. Con experiencia obtienes una buena idea de cómo hacerlo muy rápido.

No nunca.

Siempre hago análisis de requisitos, pienso en arquitectura, diseño los detalles y luego codifico. Incluso si trabajo solo en casa para un proyecto personal.

E instantáneamente despediría a un desarrollador en mi equipo si él / ella estuviera trabajando en un estilo vaquero. Somos ingenieros y tenemos una responsabilidad con el cliente y los usuarios.

No creo que la codificación de vaqueros sea un enfoque de alto nivel.

Como otros han dicho, existe un peligro real al descartar el control de versiones. Saltarse la documentación y el análisis también podría significar arriesgar la entrega de algo que el usuario no desea. Solo es mi opinión, pero no creo que pases de "codificador a desarrollador" si todo lo que haces es código cowboy.

Sin embargo, sí, hay excepciones como la que menciona Neil Butterworth. Y en estas situaciones, preferiría que un desarrollador senior experimentado sea el que tenga que hacer la codificación del vaquero.

La programación de vaquero es una forma bastante segura de crear una gran bola de barro . Lo cual, por desagradable que parezca, tiende a entregar ...

Creo que los programadores más nuevos tienden a hacer algunas cosas de codificación de vaquero cuando asumen aspectos de un proyecto / ámbitos con los que pueden no tener mucha experiencia o cuando intentan "simplemente hacer las cosas" debido a la presión de un jefe, etc. Sé que definitivamente he seguido este camino varias veces porque me faltaba el conocimiento del patrón apropiado para usar y simplemente "me abrí paso a través de él".

La diferencia entre yo y la persona de la que se queja es que, por lo general, poco después me doy cuenta de que podría haberlo hecho mejor y hacerlo más sostenible y, por lo general, me estimula a aprender más y mejorar mis habilidades (leyendo libros / artículos en el tema). Cuando vuelvo a depurar algunas de estas soluciones pirateadas, generalmente encuentro que es un dolor y contribuye más a mi deseo de aprender cómo hacerlo "de la manera correcta". Creo que esta persona que estás describiendo está básicamente atrapada en un nivel infantil de autorreflexión y dejar que su propio ego se interponga en la mejora de sus habilidades como desarrollador de software, no parece alguien con quien quisiera trabajar.

Me parece interesante tu publicación. A menudo he compartido puntos de vista con su sujeto, y su sensación es que los métodos excesivamente formalizados son sofocantes. Como alguien más notó, si ella es un genio y puede rastrear una multitud de notas mentales al mismo tiempo sin olvidar o confundirse, entonces es muy posible mantener un fragmento monolítico de código complicado y lograr que haga cosas increíbles con cambios completamente oscuros. . Hay una cierta felicidad mental que llega al cerebro de las personas que pueden hacer eso: es como ser un Dios de un pequeño universo en tu mente.

Sin embargo, los empleadores inteligentes han aprendido por las malas que nadie más que el autor original puede hacer algo que valga la pena con ese código. Si el programador continúa, terminan desperdiciando mucho dinero al darse cuenta de que la única opción es volver a escribir (solía pensar que eso significaba una pérdida total, pero en estos días me doy cuenta de que no destruyes el resultado intrínseco de desarrollo iterativo a nivel de funcionalidad externa).

Personalmente, no me importaría tener a alguien así en el equipo, porque en una crisis, podrían hacer algo en lo que nadie más piense.

Por otro lado, sé tu propia persona y decide por ti mismo cuál es la respuesta a tu pregunta, porque lo único seguro es que nadie lo ha descubierto cuando se trata de crear software. Es una de las cosas que lo convierte en un campo interesante ...