it-swarm-es.com

Francamente, ¿prefieres la codificación Cowboy?

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

Vea acerca de Codificación de vaquero en Wikipedia

68
Maniero

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

  1. Los codificadores Cowboy o pepitas 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. Arquitectura Los astronautas 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 ¡otro reescribir en el futuro, crean plataformas internas, y terminan pasando 4 horas al día en soporte porque nadie más entiende cómo usarlos correctamente.

  3. Los cuasi-ingenieros a menudo se confunden con ¡real, ingenieros capacitados porque son genuinamente ¡competentes y entender 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 ágiles, cascadas, RUP, etc. Comienzan a creer en la infalibilidad absoluta e incluso ¡necesidad de estas metodologías sin darse cuenta de que en el = ¡real campo de ingeniería de software, son meramente herramientas, no religiones. Y desafortunadamente, les impide llegar a la etapa final, que es:

  4. Programadores de cinta adhesiva AKA gurús o 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 sucede tan rápido que un observador no capacitado lo confundiría con la codificación de 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 mal diseñados pero están millas lejos del código de espagueti producido por los codificadores de vaqueros. Las pepitas ni siquiera pueden identificar a estas personas cuando están ¡se les cuenta sobre ellas, porque para ellos, todo lo que sucede en segundo plano 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 un ¡elecció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 astronauta de arquitectura, eres ¡incapaz física y psicológicamente 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 las partes interesadas los hayan aceptado (generalmente por escrito).

Y si usted es un programador de cinta adhesiva, entonces nunca hay ninguna razón para "código cowboy" porque puede construir un producto 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á. Podrían hacer algo que ¡parece similar pero no será lo mismo.

204
Aaronaught

Sí.

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 los senderos conocidos para realizar 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.

46
Shog9

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.

31
Warren Pena

Esto realmente se reduce a la cuestión de si puede implementar las cosas correctamente sin una estructura ajustada en su lugar y mucho tiempo gastado 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 Edge y excepciones

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

29
Brandon

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 solo usa conscientemente ninguno . No hay estándares. Sin garantía de calidad. No, en absoluto. ¿De dónde espera que venga la calidad del software? Árboles?
Es curioso que ella realmente niegue la experiencia de las personas que usted cita, cuando evidentemente le falta. 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 camino .
Suponiendo que ella realmente pueda 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.

13
back2dos

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 algunos 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 un invento real realizado 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.

11
Joonas Pulakka

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 tomara un nuevo problema y comenzara a diseñar una aplicación que requiera muchos meses desde cero. Pero si se trata de 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 planificación.

7
Coder

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 estuviera allí, no se podrí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.

6
Neil Butterworth

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.

5
jojo

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 senior 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 y otros, 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 dijeron a todos los demás al respecto: al publicar libros (¿de qué otra manera 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 no te impide hacer lo correcto. Simplemente no aceptes una práctica de mala calidad por parte de ella, si ella se equivoca (¡y lo hará!), Entonces déjala que la limpie. Usted se adhiere 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í está n ensayo de un escritor verdaderamente perspicaz. No soluciona su problema, pero le brinda algunas ideas sobre por qué es así y tal vez algunos consejos para tratarlo profesionalmente.

4
gbjbaanb

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 mantenible 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. Demasiados desarrolladores en estos días, parece que piensan que el punto de la programación es adherirse a los procesos, en lugar de producir un buen producto.

4
GrandmasterB

Puede encontrar alguna idea en mi respuesta a Francamente, ¿prefiere la codificación de vaquero? El problema es que "la 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 es el signo de un ingeniero maestro que lo ha visto todo mil veces antes y que ya sabe lo mejor manera de resolver el problema.

O puede ser el signo de un aficionado de rango.

Te diré una cosa: negarse a usar el control de versiones o escribir pruebas porque son demasiado "académicas" es definitivamente ¡no 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 están equivocados. 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.

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

3
Aaronaught

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

3
hotpaw2

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 campamento que "no existe THE Metodología ágil , solo 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 tendría 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.

2
MIA

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.

2
Bill

Tengo la sensación de que tu disgusto por su estilo está causando que lo tergiverses un poco. Usted dice 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 senior 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 para el 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.

1
Eran Galperin

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á hacer el trabajo, es que estoy ayudando a quien use mi código para hacer SU trabajo. No puedo decir que siempre he logrado eso, pero eso es lo que pretendo hacer.

Claro, usted may tiene un hotrod en su equipo, pero ¿qué sucede cuando se toman un par de semanas y se le pide que depure su trabajo o que le agregue algo? 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.

1
sunwukung

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.

1
Klaim

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 criterios estrictos y estrictos a las personas que desarrollan el software para equipos de aviónica o biomédicos, p. En el caso de los juegos, por ejemplo, las fallas son mucho menos negativas, por lo que el costo y la carga de las prácticas de desarrollo rigurosas y metódicas no están realmente justificadas.

1
Randall Schulz

Depende (en gran medida) del tamaño del proyecto. Por un lado, para obtener un resultado decente, necesita 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 vale la pena es es crear una biblioteca para facilitar tareas como esta. 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 ñ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 que le gusta lo que le da en lugar de tratar de obtener lo que originalmente quería.

1
Jerry Coffin

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, prefiero que un desarrollador senior experimentado sea el que tenga que hacer la codificación del vaquero.

0
Bernard Dy

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 demasiado formalizados son sofocantes. Como alguien más notó, si ella es una genio y puede rastrear una multitud de notas mentales al mismo tiempo sin olvidar o confundirse, entonces es muy posible mantener una porción monolítica de código enrevesada 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 ...

0
Aaron Anodide

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

0
Denis de Bernardy

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.

0
programmx10

No nunca.

Siempre hago análisis de requisitos, pienso en la 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 estuviera trabajando en un estilo vaquero. Somos ingenieros y tenemos una responsabilidad con el cliente y los usuarios.

0
CesarGon