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

66

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

Maniero
fuente
13
Una vez se realizó un experimento con dos grupos de personas a quienes se les pidió que hicieran macetas de arcilla en un plazo fijo. Se les dijo al grupo 1 que hicieran la maceta de la más alta calidad posible, se les dijo al grupo 2 que se medirían según el peso de todas las macetas producidas. La calidad de las macetas finales del grupo 2 fue mayor que las macetas del grupo 1. Por desgracia, no he podido encontrar la fuente original de este experimento, pero el punto primordial es "cuanto mayor sea el número de iteraciones, mejor será la calidad". ¿Eran los vaqueros del grupo 2? Probablemente.
Adolf ajo
3
"Codificación de vaquero", una terrible elección de palabras, si nada más. Cuando se usa para referirse a las personas en un equipo, "vaquero" a menudo significa algo parecido a "la persona que simplemente hace lo suyo y no le importa lo que eso significa para el resto del equipo". Pero la cuestión del valor "menos estructura" es buena.
MIA
44
Creo que debería poner su definición de programación de vaquero (directamente) en su pregunta, ya que tanto la página de wikipedia como las respuestas parecen mezcladas en lo que realmente es la codificación de vaquero. ¿Te refieres simplemente a no utilizar ninguna metodología? Porque mucha gente parece pensar que la codificación de vaquero no hace diseño en absoluto. Al menos para mí, simplemente no significó ningún proceso formal, no es que saltas la codificación de inmediato. Creo que dado que usted es quien hace la pregunta, debe definirla de acuerdo con lo que desea saber.
n1ckp
@ n1ck: Gracias. Algunas personas simplemente saltan las respuestas sin entender la pregunta. Ya es demasiado tarde, cambiarlo invalidaría algunas respuestas. Lamentablemente, algún usuario no recibió la pregunta. Lo tienes.
Maniero
¿Esta persona no usa ningún tipo de sistema de control de fuente, o simplemente se niega a usar la compañía?
Thomas

Respuestas:

202

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.

Aaronaught
fuente
27
Bellamente articulado.
Brandon
44
+1 por buena contribución a pesar de la contradicción. Dijiste que un cuasi-ingeniero toma decisiones conscientes cuando es necesario. Muchas veces los programadores experimentados con conocimiento necesitan elegir romper las reglas que él conoce y cree debido a alguna restricción. Por supuesto, si un programador es muy bueno y rápido en su trabajo, no necesita elegir, pero pocos profesionales tienen esta calidad. De todos modos, la pregunta es provocativa.
Maniero
14
El problema es que muchas personas quieren ser programadores de cinta adhesiva sin ser primero Astronautas de Arquitectura y luego cuasi ingenieros, lo que significa que siempre serán Vaqueros. Por lo tanto, creo que puedo señalar esa lista y decir "parece una progresión profesional" ... lástima que los tipos de administración piensen que los AA son el pináculo.
MIA
19
Ni siquiera sé dónde estoy en esta lista: S A veces puedo escuchar sobre un proyecto y saber instantáneamente cómo voy a construirlo 4, y luego sufriré una parálisis de análisis grave y pensaré demasiado en la arquitectura, al igual que 2, a continuación, considero YAGNI y pienso en el valor del negocio y tratar de ser pragmáticos, y sentirse como una 3, y luego termino haciendo un lío como una 1.
Carson Myers
14
Debería darle -1 por insinuar que un consultor altamente pagado está en el nivel de habilidad de programador de cinta adhesiva (pista: la mayoría de ellos no lo están, ni siquiera cerca). Pero te di +1 de todos modos.
Falcon el
47

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.

Shog9
fuente
Tengo problemas con 1 para "envoltorios viejos de refrigerios, mi fregadero lleno de platos sucios y [lo más importante] mi cama sin hacer". Qué diablos, +1 porque la emoción de la codificación del vaquero y la incomodidad de no saber si puedes regresar es demasiado poderoso para perder el tiempo con UML tonto, diseño y especificaciones. Escriben sus especificaciones de mi implementación, NUNCA al revés. :: sarcasmo
Chris
31

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.

Warren Pena
fuente
66
Siempre hay excepciones. Algunos codificadores pueden ser genios, tener memoria fotográfica pero poca paciencia. Otros no son tan rápidos pero persistentes; mueven la tarea un byte a la vez hasta que se convierte en su perra. Hay muchas formas de ser un buen programador. Tal vez la programación vaquera funcione para ella. Puede que no funcione para el autor de la pregunta o para muchos otros. Sin embargo, ¿por qué exigir CÓMO alguien debería trabajar, cuando lo importante es la tasa y la calidad de los resultados? ¿Por qué aprobar una ley que prohíbe los motores de 12 cilindros, cuando simplemente puede recompensar un mpg más alto a través del crédito fiscal?
Trabajo
@ Job: estoy de acuerdo. Todos tienen un proceso diferente; Este proceso no suele ser exitoso pero puede serlo. Por mi parte, soy un notorio usuario del algoritmo Feynman , y hago el paso 3 lo más rápido posible mientras todavía estoy en la zona.
Jon Purdy
3
@ Job: a veces hay excepciones. Los porcentajes eventualmente se harán cargo. Puede haber excepciones cuando se evalúa en forma aislada del código perfecto (sin errores, sin problemas, etc.) pero eventualmente los hábitos de codificador de vaquero afectarán a su empresa (y a su equipo y a ella) en el trasero. Puedes ganar en la ruleta rusa cinco veces seguidas, pero sigue jugando y mi dinero está en la bala.
Thomas
2
@ Job: Sí, estoy de acuerdo, hasta cierto punto. Pero negarse a considerar cualquier otra cosa (que = negarse a aprender), y negarse a usar el control de fuente son dos grandes señales de alerta que me dicen: Podría ser rápido, pero un verdadero boofhead peligroso.
rapid_now
1
Seguir un proceso formal no es la única forma de escribir código de calidad, y de todos modos no garantiza un código de calidad. Tener un proceso formal es menos importante si el trabajo de una persona está "ligado" con el trabajo de otras personas. Sin embargo, el control de versiones, en todo caso, se vuelve más importante a medida que el proceso se vuelve más informal. Sobre "negarse a aprender": ¿cuántas malas experiencias ha tenido esta persona con malos procesos y malos sistemas en el pasado? Inferencia es imperfecta, pero es básicamente la única manera que tenemos de entender nada fuera de nuestras propias cabezas, y con la derecha (o más bien malas experiencias ...)
Steve314
29

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.

Brandon
fuente
99
Realmente no llamaría a tu lista final codificación "vaquero". Es más como el "programador de cinta adhesiva" por excelencia glorificado por Spolsky. La diferencia es que un codificador de vaquero simplemente comienza a lanzar código juntos sin prestar atención al diseño general; el "programador de cinta adhesiva" lo inventa a medida que avanza, pero aún tiene un plan; él solo está haciendo la mayor parte del trabajo de diseño a un nivel intuitivo (y a veces iterativo).
Aaronaught
3
Los clientes no necesariamente lo quieren al estilo vaquero, solo lo quieren barato y rápido. Depende de nosotros entregar.
@ user1249: Eso me recuerda el triángulo de gestión del proyecto: barato, rápido, bueno, elige dos.
DanMan
La suposición de que los clientes son la autoridad profesional es ridícula. Por supuesto, quiero que las cosas se manejen de una manera vaquera, es por eso que quiero que mi auto se haga rápido y sucio, que mi casa sea construida por los recién llegados que pueden pegar el cemento de manera similar a una pared, y mi comida debe estar preparada por aquellos que ignoran el riesgo para la salud en beneficio de que coma antes ...
Henry Aloni
13

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.

back2dos
fuente
2
A veces la verdad duele simple y llanamente ...
ChaosPandion
+1 por decir que el trabajo en equipo con personas tan egoístas es imposible. Incluso si son genios, los vaqueros no son jugadores de equipo; ellos son el show principal y nosotros somos el grupo de respaldo
Mawg
11

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.

Joonas Pulakka
fuente
Me di cuenta de que mencionaste algunos éxitos de vaqueros famosos al pasar por alto los fracasos de vaqueros mucho más numerosos.
Mawg
7

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.

Descifrador
fuente
99
su respuesta omite por completo la parte más reveladora de la pregunta "Tengo un programador que codifica rápidamente al descartar el control de revisión ..." cualquiera que descarte el control de revisión y promueva esta opinión entre los empleados de nivel junior es criminal.
1
@Jarrod: o no. No tiene mucho sentido cometer código incompleto / disfuncional.
Denis de Bernardy
1
@Denis: para eso es principalmente una rama. El historial de decisiones, cambios, errores, callejones sin salida, etc. durante el desarrollo de código incompleto / disfuncional es IMO como parte de la documentación de ese código, y muy importante durante el mantenimiento. Una ramificación y fusión más fáciles es una buena razón para reemplazar la subversión con un VCS distribuido.
Steve314
@steve: Eso supondría que estás buscando en los registros antes de editar una línea de código. Francamente, conozco muy pocos programadores que realmente lo hacen ... E incluso entonces (como yo ...), están mucho menos interesados ​​en por qué esto / eso se cometió en lugar de eso, que en por qué se cambió del código original
Denis de Bernardy
@steve: Para funciones simples, es más fácil usar un solo commit con comentario "Función agregada que calcula los parámetros de aceleración", que tener coomits: "Esqueleto de PaternX", "Se agregó la primera línea de código", "Se corrigió un error", "Se corrigió otro error". Es más fácil rastrear los cambios globales del proyecto si hay menos compromisos de "ruido". Y hay estantes que se pueden usar para código incompleto para evitar daños.
Codificador
6

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.

Neil Butterworth
fuente
¿Cómo se usa tu cerdo? ¿Cuál es el lenguaje para describir los diálogos?
Trabajo
@ Job Aún no está listo.
Neil Butterworth
su respuesta omite por completo la parte más reveladora de la pregunta "Tengo un programador que codifica rápidamente al descartar el control de revisión ..." Estoy bastante seguro de su ejemplo, no descartaron el control de versiones o la administración de versiones, etc.
@Jarrod Control de versiones. Bueno, tuvimos rcs. ¿Gestión de la liberación? Este fue un banco de inversión! Empujas cosas por la puerta tan rápido como lo escribes.
Neil Butterworth
dar una buena acogida.
P Shved
5

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.

jojo
fuente
2
A costa de crear una gran bola de barro (mi propia respuesta ;-))
Denis de Bernardy
4

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.

Gran maestro B
fuente
4

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.

gbjbaanb
fuente
+1 Es lamentable que 'hacker' haya cambiado para significar esto. Una breve historia de Hackerdom
Gyan alias Gary Buyn
44
Yo diría "hackear" en lugar de "hacker".
Mike Sherrill 'Cat Recall'
2
Son un vaquero, tal como lo dijo el OP, no te confundas lo que es un hacker. Deja eso a los medios.
ocodo
podría ser que son un programador "rockstar" ... demasiado lleno de ego y talento para preocuparse por las 'pequeñas cosas'. ¿Dónde está mi bañera llena de m & ms azules? ¡Lo quiero ahora!
gbjbaanb
3

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.

hotpaw2
fuente
44
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 codificando a un ritmo promedio , hasta que el gran programador se vaya y tome su silla de montar, caballo y tu código con ellos ¿Qué tan buenos se ven esos resultados entonces?
Thomas
La suposición no es necesariamente correcta. Cumplir una fecha límite de una conferencia u otra presentación de su producto también puede ser extremadamente importante.
1
@Thomas: los factores de riesgo se cortan en ambos sentidos. El tipo que financia todos los cheques de pago podría salir de la próxima ronda de financiación cuando incluso una prueba de concepto pirateada no aparece lo suficientemente pronto. ¿Qué tan bien se ven tus lentos caballos ahora? Todas las opciones de ingeniería son apuestas. Coloca tus fichas.
hotpaw2
@ hotpaw2: la apuesta es si los costos (potencialmente terminales) de la codificación del vaquero llegarán antes de que pueda obtener su financiación. En general, mi apuesta es contra la codificación del vaquero (y que llevará más tiempo). Oh, podrías vencerme 1/10 veces o incluso 1/5. Pero en total, año tras año a medida que aumentan las posibilidades, los codificadores de vaqueros le costarán más de lo que gana.
Thomas
1
@ Thorbjørn Ravn Andersen, @ hotpaw2 - Aquí hay otra dinámica en juego. Un programador que esté dispuesto a utilizar, si no persigue activamente, técnicas arriesgadas, incluso cuando esos riesgos sean innecesarios, en general tomará decisiones más arriesgadas en otros lugares. Es decir, su elección contra el control de la fuente es indicativo de un patrón de comportamiento más arriesgado que eventualmente los morderá a ellos y a su compañía. Incluso en una apuesta, a veces puedes vencer a la casa, pero eventualmente los porcentajes te derrotan.
Thomas
3

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.

Aaronaught
fuente
2

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.

Cuenta
fuente
2

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.

desaparecido en combate
fuente
1

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.

Klaim
fuente
1

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.

Randall Schulz
fuente
2
Con frecuencia debe resolver el problema para descubrir cómo resolverlo ...
1

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.

Jerry Coffin
fuente
1

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.

sunwukung
fuente
Sí, y es posible (¿probable?) Que algunos codificadores de vaqueros den un código no tan bueno.
Bernard Dy
1

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.

Eran Galperin
fuente
0

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.

CesarGon
fuente
-1: También debe actuar en el mejor interés de quien esté escribiendo su cheque de pago.
Jim G.
@ Jim: estoy escribiendo el cheque de pago. Es por eso que tengo la prerrogativa de despedir a los miembros del equipo. Tal vez tu voto negativo fue un poco apresurado. :-)
CesarGon
Somos ingenieros y tenemos una responsabilidad con el cliente y los usuarios. - A veces, el cliente exige una fecha de envío rápida. Énfasis: a veces la fecha de envío rápido no es negociable.
Jim G.
@ Jim: Lo sé muy bien, después de haber puesto en marcha tres empresas. Aún así, no hay código de vaquero nunca, muchas gracias. Como dije, tenemos una responsabilidad con el cliente y los usuarios, y siempre he podido igualar ese compromiso con prácticas de ingeniería sólidas y sin vaqueros.
CesarGon
0

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.

Bernard Dy
fuente
0

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.

programamx10
fuente
0

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

Aaron Anodide
fuente
Estoy de acuerdo, a menos que sea una solución ad-hoc que nunca necesite ser tocada de nuevo, tener algún tipo de patrón es importante porque no se trata solo de "hacer que funcione", alguien finalmente tendrá que mirar "debajo del capó" y darle sentido it
programmx10