¿Qué prácticas específicas podrían llamarse "artesanía de software" en lugar de "ingeniería de software"? [cerrado]

11

Aunque no es una idea nueva, parece haber habido un gran aumento en el interés en la artesanía del software en los últimos años (en particular, el título completo del libro Clean Code, a menudo recomendado, es Clean Code: A Handbook of Agile Software Craftsmanship ).

Personalmente, veo la artesanía del software como una buena ingeniería de software con un interés adicional en garantizar que el resultado final sea un placer trabajar con él (tanto como usuario final y como alguien que mantiene ese software), y también que su enfoque está más en el nivel de codificación de cosas que las cosas de proceso de nivel superior.

Para establecer una analogía: había muchos edificios construidos en los años 50 y 60 en un estilo muy moderno que tenía muy poca cuenta de las personas que vivirían en ellos o cómo esos edificios envejecerían con el tiempo. Muchos de esos edificios se convirtieron rápidamente en barrios marginales o han sido demolidos mucho antes de su vida útil esperada. Estoy seguro de que la mayoría de los desarrolladores con algunos años bajo sus cinturones habrán experimentado bases de código similares.

¿Cuáles son las cosas específicas que un artesano de software podría hacer que un ingeniero de software (posiblemente uno malo) podría no hacer?

programming-practices

— FinnNk
fuente

1

La analogía no parece encajar. Tanto la artesanía del software como la ingeniería del software tienen el mismo objetivo (e interés personal) de mejorar la utilidad a largo plazo del software.

— rwong

3

Creo que este asunto es principalmente una cuestión de si consideras "ingeniero" o "artesano" el título más genial, y las respuestas actuales parecen probarlo. El título que prefiera obviamente implica que esa persona sabe lo que está haciendo, después de todo.

— Ben Brocka

Yo diría que la diferencia entre los dos es que un artesano trabaja solo, un ingeniero trabaja como parte de un equipo. A grandes rasgos, esto parece satisfacer las descripciones principales de los dos roles, no porque ambos tengan habilidades diferentes, sino que sus enfoques provienen de posiciones diferentes.

— gbjbaanb

Simplemente suena como un título realmente pretencioso para darte a ti mismo.

— michaelsnowden

13

Yo diría que la única diferencia entre un profesional y un artesano es cuidar con un poco de pasión mezclada . No existe una práctica específica y observable que clasifique a uno como artesano, sino más bien una colección de cualidades:

Un artesano se preocupa por la calidad real de su trabajo, y no solo por la calidad percibida.
Un artesano tiene un interés en su oficio que va más allá de hacer el trabajo, y naturalmente gravita hacia su oficio.
Un artesano se preocupa por su profesión, aspira a mejorar sus habilidades y no solo a avanzar en su carrera .
Un artesano pasa una cierta cantidad de tiempo fuera de sus horas de trabajo remuneradas (incluso si es una pequeña cantidad de tiempo) haciendo algo con su oficio, ya sea discutiendo, aprendiendo o incluso pensando en ello.
Un artesano sabe lo poco que realmente sabe, y se siente humillado por ello.
Un artesano está dispuesto a enseñar a quienes están dispuestos a aprender, guiar a quienes buscan orientación y buscar esas cosas él mismo cuando las necesita.

Un poco de pasión cubre todo esto sin sudar.

— Allon Guralnek
fuente

Creo que el último es particularmente importante

— Lovis

7

Personalmente, veo la artesanía del software como una buena ingeniería de software con un interés adicional en garantizar que el resultado final sea un placer trabajar con él (tanto como usuario final y como alguien que mantiene ese software), y también que su enfoque está más en el nivel de codificación de cosas que las cosas de proceso de nivel superior.

Como dijo un profesor mío una vez (parafraseado): "Como ingeniero de software, no es solo su trabajo entregar software. Es su trabajo entregar software que haga felices a sus clientes".

¿Cuáles son las cosas específicas que un artesano de software podría hacer que un ingeniero de software (posiblemente uno malo) podría no hacer?

Nada, un ingeniero es un artesano ... pero más. La ingeniería se basa en la artesanía.

Como artesano e ingeniero, ustedes son individuos calificados, a través de una combinación de educación y experiencia. Sigue los procedimientos establecidos. También eres pragmático y te das cuenta de lo que está roto y necesita ser mejor.

Sin embargo, un ingeniero agrega preocupaciones de economía, teoría y ciencia además de eso. Le preocupa obtener el mayor beneficio al menor costo. Desea aplicar teorías de psicología, sociología, gestión, interacciones humano-computadora y ciencias de la computación para resolver sus problemas (tanto interpersonales como técnicos). Y definitivamente tienes una educación para respaldar tus experiencias.

— Thomas Owens
fuente

2

Y definitivamente tiene una educación para respaldar sus experiencias , me alegra no haber dicho "formal".

— Treecoder

@greengit En muchos lugares, para usar el título "ingeniero", debe tener educación formal. En Europa, esto significa graduarse con un título de ingeniería. Italia también agrega el requisito de aprobar un examen de certificación. En América del Norte, Texas, Florida y Canadá requieren que quienes utilizan el título de "ingeniero" (incluidos los ingenieros de software) aprueben un examen de licencia.

— Thomas Owens

Aunque eso no significa que alguien sin esta educación formal no pueda practicar ingeniería. Simplemente no pueden llamarse a sí mismos ingeniero como título profesional.

— Thomas Owens

1

No estoy de acuerdo, un ingeniero no es necesariamente un artesano.

— Nicole

2

@Renesis Por definición, la ingeniería es un oficio. Definición de oficio: "un arte, oficio u ocupación que requiere habilidad especial, especialmente habilidad manual". La ingeniería es una ocupación que requiere habilidades especiales, por lo tanto, es un oficio. Sin embargo, también es la aplicación de la teoría científica (entre otras cosas), lo que lo hace más.

— Thomas Owens

2

El movimiento de la artesanía del software se inició en reacción a las fallas y los resultados insatisfactorios de la ingeniería de software "tradicional" que (junto con el descuido de algunos desarrolladores) hoy en día llevan a la desconfianza de las partes interesadas y los usuarios hacia nuestra profesión.

Su objetivo es doble: restaurar la confianza en los programadores y, para hacerlo, elevar el nivel de calidad del software y las habilidades de los desarrolladores.

La artesanía de Sw promueve prácticas técnicas como:

Principios de diseño SÓLIDO
Patrones de diseño
TDD (metáfora de "contabilidad de doble entrada")
...

Y prácticas de equipo / organización:

Programación en pareja
Mentoring
Code katas
Dojos / retiros de código
...

Entonces, diría que la diferencia entre los 2 es clara: la artesanía del software intenta abordar una gran parte de los problemas que ha tenido la ingeniería del software en más de 40 años de existencia que hoy hacen que nuestra disciplina parezca poco confiable y esté paralizada con una historia de fallas.

— guillaume31
fuente

1

No estoy de acuerdo: la razón por la que la ingeniería de software falló es porque no tenía ingenieros, solo artesanos que pretendían ser ingenieros. ¡La NASA no envió naves espaciales a la luna usando artesanos!

— gbjbaanb

@gbjbaanb Creo que es todo lo contrario: teníamos ingenieros, y es por eso que intentaron incorporar un modelo de ingeniería tradicional y una mentalidad de otras industrias al software, pero no funcionó.

— guillaume31

Las naves espaciales no están hechas de material intangible que pueda ser remodelado, rediseñado y desplegado una y otra vez. Las leyes que obedecen difieren en gran medida de las de los programas de software.

— guillaume31

El transbordador espacial tiene refuerzos redistribuibles, al menos, y sin duda reutilizó bits (o al menos conocimiento) de cohetes anteriores. Y las naves espaciales tienen mucho software. No creo que comiencen desde cero con cada nuevo satélite o sonda, y casi nunca aplican actualizaciones una vez implementadas. La ingeniería de software puede funcionar, y obviamente funciona, pero solo si lo aborda con la mentalidad de un ingeniero, no un artesano.

— gbjbaanb

Defina "mentalidad de ingeniero", en el contexto del software.

— guillaume31

1

Yendo a http://manifesto.softwarecraftsmanship.org/ derivaría lo siguiente.

Un artesano es diferente de las percepciones tradicionales de un "ingeniero" porque

Se centran en el valor, no solo en cumplir los requisitos.
Se centran en la calidad incluso en el estilo de su código, no solo en cumplir los requisitos.
Participan en la comunidad más amplia de desarrollo de software, no solo en su lugar de trabajo.
No solo entienden que el estado del arte de hoy es la basura del mañana, sino que son activos para lograrlo en un nivel u otro.
No es solo un trabajo, son quienes son .

— desaparecido en combate
fuente

44

Honestamente, todos esos puntos describen a un buen ingeniero. Especialmente 1, 2 y 4.

— Thomas Owens

@ThomasOwens ¿Y qué hay del mal ingeniero? ¿Es también un artesano? ¿O artesano bueno contra malo?

— Eufórico el

@Euphoric No creo que puedas ser un buen ingeniero sin ser un buen artesano. Es como una puesta en escena. Debes lograr un "buen artesano" antes de lograr un "buen ingeniero". Sin embargo, puedes ser un buen artesano y no ser un buen ingeniero.

— Thomas Owens

1

El tío Bob de alguna manera insinuó que la programación es una disciplina muy joven que aún no tiene un cuerpo estable de leyes o reglas reconocidas por los gobiernos (¿o fue Frederick Brooks?). No estoy haciendo una cita literal aquí.

No puede revocar a nadie el permiso para programar debido a mala práctica. La programación carece de un conjunto de leyes y reglas que sean legalmente aplicadas por la legislación que conforma una "profesión". Un médico mata a un paciente debido a su incompetencia y se arriesga a que se le quite el título o permiso de su médico.

Un programador hace un programa defectuoso o hace que un proyecto falle debido a la incompetencia y es libre de continuar la programación.

Creo que eso es más o menos lo que hace que la programación sea un oficio. Un fabricante de ollas de barro no hace dos ollas idénticas. Tampoco has oído hablar de un fabricante de vasijas de barro obligado a retirar ollas defectuosas. La programación sigue siendo un tipo de trabajo muy manual y personal. A veces incluso se puede saber quién escribió una pieza de código a juzgar por el estilo de la misma.

— Tulains Córdova
fuente

0

Refactorización a patrones.

Es decir, cree algo que satisfaga el 90% de los requisitos de software, luego refactorice todo el proyecto en un diseño limpio y elegante.

Normalmente, la ingeniería de software le impediría hacer esto, porque cumplir el 90% de los requisitos significa que el software tiene suficiente valor comercial para el cliente que no debe modificarse de manera significativa (excepto las correcciones de errores de alta prioridad).

La ingeniería de software le recomendaría estabilizar el software en este punto.

Además, si un proyecto no comienza con ese diseño elegante desde el principio, se consideraría un proyecto mal ejecutado (independientemente del resultado del proyecto), según la ingeniería de software.

Solución de espiga.

Un diseño inspirado en una solución de punta normalmente no es aceptable de acuerdo con la metodología de ingeniería de software vigente.

Desprecio , por cualquier razón.

En ingeniería de software, se permite que ocurra cualquier tipo de desaprobación solo al final del ciclo de vida de un sistema de software. Esto debe planificarse como parte del SDLC.

En la práctica, es bastante común que las deficiencias de una parte específica de la interfaz del software se descubran unos años después de la producción, y esa parte específica se puede desaprobar en la mitad del ciclo de vida, sin invalidar el resto del software. Esto habría requerido una nueva certificación de todo el sistema de software después de la depreciación, de acuerdo con la ingeniería de software.

Al final, la artesanía del software es un esfuerzo personal para el buen juicio de los individuos, mientras que la ingeniería del software es un cuerpo de conocimiento conservador. Permitir ese buen juicio en la toma de decisiones del proyecto es lo que separa la artesanía del software de la ingeniería del software.

— rwong
fuente

-1

Yo diría que tener pruebas unitarias que cubran el 100% del código sería una buena opción. Como eso permite que se elimine el exceso de material.

A veces comparo el desarrollo de software con la escultura. No es lo que agregas, es lo que quitas.

Obviamente puedes llevar eso demasiado lejos. Nadie va a decir que una pequeña piedra brillante es una buena escultura: S

— Antony Scott
fuente

3

¿Qué tan brillante estamos hablando aquí? :-)

— Chris

1

La mayoría de las veces estoy de acuerdo con esto, pero no estoy seguro de que el 100% estricto siempre valga la pena, por ejemplo, getters / setters donde no tienen lógica. También es mejor dejar el código generado sin pruebas unitarias (aunque las pruebas de integración pueden ser apropiadas)

— FinnNk

@FinnNk: estoy de acuerdo. He usado dotCover recientemente y eso dice que un getter / setter está cubierto si se usa en otra prueba. Entonces, realmente no quise decir un método de prueba para cada captador y colocador

— Antony Scott