science - theory traduccion
La explicación de programación más difícil. (26)
"Agregar un nuevo programador por un mes a esta tarea tardía lo enviará más tarde. No importa, lea este libro". (El mes-hombre mítico). Los gerentes aún no lo entienden.
Recientemente intenté explicar un código mal diseñado a mi gerente de proyecto. Todas las clases de administrador son singletons ("y es por eso que no puedo cambiar esto fácilmente") y el código usa el envío de eventos en todos los lugares donde una llamada de función hubiera sido suficiente ("y por eso es tan difícil de depurar"). Lamentablemente, simplemente salió como un torbellino de inglés.
¿Cuál es la cosa más difícil que has tenido que transmitir a una persona no técnica como programador? ¿Encontró alguna analogía o forma de explicar que lo hizo más claro?
¿Por qué no necesita un manejo correcto del índice de caracteres en la mayoría de los casos cuando usa cadenas UTF-8?
1.) SQL: Pensando en conjuntos, en lugar de hacerlo de manera procesal (¡es lo suficientemente difícil para que los programadores lo comprendamos!).
2.) ... y aquí hay un gran ejemplo de conceptos técnicos de desmitificación:
A veces me cuesta mucho explicar el concepto de covarianza / contravarianza y los problemas relacionados con ellos a los programadores compañeros.
Convencer a un amigo de que la aplicación de Facebook que desarrollé realmente no almacena sus datos personales (por ejemplo, su nombre) a pesar de que todavía los muestra.
Dedicar tiempo al diseño y dedicar tiempo a la refactorización.
La refactorización no produce ningún trabajo visible para el cliente, lo que hace que sea la tarea más difícil en el proyecto para justificar el trabajo.
Como segundo problema "no visible para el cliente", pruebas de unidad.
El concepto de recursión: algunas personas lo entienden muy duro.
Es difícil explicar por qué la mayoría del software tiene errores. Muchas personas no técnicas no tienen idea de lo complejo que es el software y de lo fácil que es pasar por alto las condiciones inesperadas. Piensan que somos demasiado perezosos para arreglar cosas que sabemos que están dañadas.
Evitar el bloqueo de puntos muertos en un entorno de subprocesos múltiples.
Me aclaré la confusión explicándola visualmente en una pizarra blanca, dibujando dos líneas paralelas y mostrando lo que sucede cuando se alcanzan los mismos puntos al mismo tiempo.
También interprete dos hilos con la persona a la que se lo explicaba y el uso de objetos físicos (libro, taza de café, etc.) para mostrar qué sucede cuando ambos intentamos usar algo a la vez.
Hay 10 tipos diferentes de personas en el mundo.
Las personas que entienden el binario y las personas que no ...
Iba a comentar en la publicación de Mikael, que algunas personas simplemente toman la programación secuencial y desafortunadamente se quedan con eso.
Pero eso realmente significa: dos conceptos muy difíciles de explicar:
- mónadas en haskell (generalmente comenzando con: "Es como una función que devuelve una función que hace lo que realmente querías hacer, pero ...")
- aplazado en twisted / python ("Eso es como ... ehhh ... Solo úsalo por un año y lo obtendrás";))
Intentando explicar por qué el código se ejecutó secuencialmente. Al parecer, esto no es del todo intuitivo para algunos que no son programadores (es decir, mi novia).
La importancia de las pruebas unitarias.
Los conceptos más difíciles de explicar a las personas que etiquetaría como programadores en lugar de desarrolladores son algunos de los paradigmas más importantes del diseño orientado a objetos. Más específicamente la abstracción, la encapsulación y el rey, el polimorfismo y cómo usarlos correctamente.
Más allá de eso está el nivel de complejidad de explicar qué es Inversión de control y por qué es una necesidad absoluta y no solo capas adicionales de código que no hacen nada.
Los mayores obstáculos se encuentran en torno a la "deuda tecnológica", especialmente sobre cómo la arquitectura era correcta para esta versión, pero debe cambiarse para la próxima versión. Esto es similar al problema de explicar "prototipo versus producción" y "versión 1.0 versus versión 2.0".
El peor error que he cometido fue hacer una maqueta de UI en los pasos de NeXT UI Builder. Se veía exactamente como se vería el producto final y tenía algún comportamiento. Tratar de explicar que quedaban 6 meses de trabajo después de eso fue muy difícil.
Me preguntaron cómo funcionaba Internet, respondí con "SYN, ACK, ACK". Sigue olvidando que es SYN, SYN-ACK, ACK ...
texto alternativo http://www.inetdaemon.com/img/internet/3-way-handshake.gif
Mi pregunta más difícil comenzó inocentemente: mi novia preguntó cómo se representaba el texto en Firefox. Respondí simplemente con algo como "motor de renderización, Gecko, analizador HTML, bla, bla, bla".
Luego se fue cuesta abajo. "Bueno, ¿cómo sabe Gecko qué mostrar entonces?"
Salió en espiral, literalmente, hacia los controladores de gráficos, el sistema operativo, los compiladores, las arquitecturas de hardware y los 1s y 0s en bruto. No solo me di cuenta de que existían lagunas significativas en mi propio conocimiento de la jerarquía de capas, sino también de cómo, al final, la había dejado a ella (¡ya mí!) Más confundida que cuando comencé.
Debería haber respondido inicialmente "tortugas hasta el fondo" y seguir con eso. :PAG
Para decirlo claramente, ¿por qué el desarrollo es el concepto más difícil jamás expuesto al tipo de hombre? No relacionado con ningún lenguaje de programación, pero en general. Y no, no estoy tratando de proporcionarme a mí mismo ni a usted un impulso de ego, las únicas limitaciones reales en este campo es su mente.
¿Por qué? No trabajamos con constantes y no hay límites, la única razón por la que una IA que piensa como un ser humano no existe todavía se debe a nuestras propias limitaciones. Todos los demás aspectos deben adherirse a algún tipo de ley, el desarrollo no se preocupa por las leyes de la física o cualquier ley para esa materia, de ahí el término desarrollo ... evolución.
Por qué el código como este es malo:
private void button1_Click(object sender, EventArgs e)
{
System.Threading.ThreadStart start =
new System.Threading.ThreadStart(SomeFunction);
System.Threading.Thread thread = new System.Threading.Thread(start);
_SomeFunctionFinished = false;
thread.Start();
while (!_SomeFunctionFinished)
{
System.Threading.Thread.Sleep(1000);
}
// do something else that can only be done after SomeFunction() is finished
}
private bool _SomeFunctionFinished;
private void SomeFunction()
{
// do some elaborate $#@%#
_SomeFunctionFinished = true;
}
Actualización : lo que debería ser este código:
private void button1_Click(object sender, EventArgs e)
{
SomeFunction();
// do something else that can only be done after SomeFunction() is finished
}
private void SomeFunction()
{
// do some elaborate $#@%#
}
Por qué tomará otras cuatro semanas poner esta aplicación en producción. Después de todo, solo tomó una semana hacer el prototipo rápido. "Funciona" (o al menos parece que lo hace), así que debería estar prácticamente terminado, ¿no es así?
Las explicaciones que involucran seguridad, calidad de código (mantenibilidad), esquemas de base de datos normalizados, pruebas, etc., generalmente aparecen como una lista de abstracciones que no tienen ningún efecto visible en la aplicación, por lo que es difícil explicar lo que realmente contribuyen a la Proyecto y por qué son necesarios. A veces las analogías solo pueden llevarte tan lejos.
Punteros c
*yo
&yo
Realmente no hay una respuesta correcta o incorrecta, adecuada para esto ... son todas las experiencias.
Lo más difícil que tuve que explicarle a una persona no tecnológica fue por qué no podía acceder a su sitio web cuando viajaba al extranjero, pero el miembro de su familia que vivía allí (con un proveedor totalmente diferente) podía obtenerlo. De alguna manera, "Falló en Finlandia" no fue lo suficientemente bueno.
Tuve un caso divertido de intentar explicar por qué un programa no se estaba comportando como se esperaba cuando algunos registros en una base de datos tenían cadenas vacías y otros eran NULL. Creo que su cabeza casi explotó cuando les dije que una cadena vacía es solo una cadena con 0 bytes, mientras que NULL significa un valor desconocido y, por lo tanto, no se puede comparar con nada.
Después tuve un dolor de cabeza desagradable.
Muchas declaraciones que comienzan con "It''s because in Oracle, ..." vienen a mi mente.
Sincronización de subprocesos y Dead-Locking.