1. Cuando era adolescente, en algún momento me obsesioné con escribir el código más conciso posible (piense en hacer cosas inteligentes como multiplicar por un poco de matemática en una variable booleana para aumentar o disminuir un puntero). Me tomó varias veces necesitar pasar dos horas tratando de entender el código que había escrito el día anterior para superar esta forma de presumir. Así que ese es mi punto aquí: escribir código inescrutable puede parecer alardear, pero en realidad es un signo de inmadurez. Alguien * más * tendrá que trabajar en esa cosa súper inteligente, tarde o temprano, y no apreciarán la inteligencia.
2. Uno que veo mucho es “pensar que los objetos son reales” (aquí también podría sustituir cualquier otro lenguaje de programación popular por “objetos”). En pocas palabras: una computadora ejecuta instrucciones, secuencialmente, y habla con el hardware que está proporcionando algunos bytes o recibiendo algunos bytes. Todavía es todo lenguaje de máquina, y todavía son todos bytes. Por lo tanto, no deslumbrarse con la espuma y la efervescencia que la gente inventa para adherirse a esos bytes y hardware es importante: puede hacerlo productivo, pero limitará su pensamiento.
Como una receta para la dolencia específica de “los objetos de pensamiento son reales”, mi ejercicio favorito para ayudar a los desarrolladores de Java a escapar de esa rutina es simple: escribir un servicio que utilice proxies dinámicos de Java y tome un HashMap. Debería poder recibir cualquier interfaz que contenga solo getters y setters de estilo JavaBeans, y generar una implementación de esa interfaz que lea / escriba usando HashMap. Lo que acaba de hacer es colocar su propio modelo de memoria debajo de los objetos, lo que la JVM está haciendo por usted. Y terminas dándote cuenta de que lo que acabas de hacer es todo lo que JVM está haciendo también: los objetos son una ficción útil que aprovecha los millones de años de evolución que tiene el cerebro humano para interactuar con cosas que persisten, tienen propiedades y pueden hacer cosas . No hay nada de malo en eso, pero son una herramienta para que los programadores piensen en los programas más fácilmente, eso es todo.
- ¿Por qué los villanos no solo venden su súper tecnología en lugar de pelear por ella todo el tiempo (siempre pueden hacer nueva tecnología para reemplazarla)?
- ¿Es un teléfono un dispositivo caro?
- ¿Cuál es la diferencia entre API y ASP en el dominio de viaje?
- ¿Es factible una tuneladora equipada con láser?
- ¿Qué nuevas tecnologías se utilizan en turismo?
3. Sin pensar en lo que está haciendo todo el sistema, solo en el rincón más familiar. Tuve la suerte de que me destetaron en lenguaje ensamblador Z-80; no estoy seguro de cómo llegas allí en estos días. Recientemente realicé algunas consultas de rendimiento para una compañía cuya aplicación web haría más de 2000 consultas SQL para responder una solicitud HTTP. Obtiene sistemas como ese cuando nadie piensa en el comportamiento de todo el sistema.
4. Veo grandes diferencias en los programadores más jóvenes dependiendo de si se desarrollan bajo Windows o un sistema operativo con sabor a Unix. Hay una impotencia aprendida que proviene de ser un usuario de Windows: encantamientos mágicos como reiniciar para arreglar cosas, que es una consecuencia de estar acostumbrado a un mundo donde el sistema operativo es una caja negra poco confiable que está fuera de su control (incluso si quisieras obtener el código fuente y ver qué está haciendo realmente, no puedes). Probar cosas al azar hasta que funcione es puro veneno para la buena ingeniería. Desarrollar las habilidades de uno en un entorno donde ese es con frecuencia el único recurso parece (para mí) afectar negativamente las habilidades de resolución de problemas de las personas: es como tratar de desarrollar sus habilidades para mantener un automóvil usando un automóvil que viene con el capó permanentemente soldado. La conclusión es que una computadora es una máquina, no muy diferente a un automóvil, y lo que está haciendo en un momento dado es en gran medida algo que se puede conocer. Y hay grandes beneficios cuando, al programar, te preguntas “¿Qué estoy pidiendo físicamente que haga una máquina?” y poder responder eso a una aproximación razonable. Cualquier cosa que sea una caja negra incognoscible entre usted y el hardware es un gran impedimento para desarrollar esa habilidad.
