c# - qué - ¿Cuál es el conocimiento mínimo de CLR que un programador de.NET debe tener para ser un buen programador?
qué es un desarrollador net (7)
Cuando hablamos del mundo .NET, CLR es de lo que depende todo lo que hacemos. ¿Cuál es el conocimiento mínimo de CLR que un programador de .NET debe tener para ser un buen programador? ¿Puedes darme uno / muchos de los que piensas que son / son los temas más importantes: GC ?, ¿Dominio de aplicación ?, ¿Subprocesos ?, ¿Procesos ?, ¿Ensambles / Fusión?
Apreciaré mucho si publican enlaces a artículos, blogs, libros u otros sobre el tema donde se puede encontrar más información.
Actualización: Noté por algunos comentarios que mi pregunta no estaba clara para algunos. Cuando digo CLR no me refiero a .Net Framework. NO se trata de memorizar bibliotecas .NET, sino de comprender cómo funciona el entorno de ejecución (en el que esas bibliotecas viven en tiempo de ejecución).
Mi pregunta fue inspirada directamente por John Robbins, el autor del libro "Depurar aplicaciones para Microsoft® .NET" (que recomiendo) y un colega de aquí citado Jeffrey Richter en Wintellect. En uno de los capítulos introductorios está diciendo que "... cualquier programador de .NET debería saber qué es lo que está sondeando y cómo se cargan los ensamblajes en el tiempo de ejecución". ¿Crees que hay otras cosas así?
Última actualización: después de haber leído los primeros 5 capítulos de "CLR a través de C #", debo decir a cualquiera que lea esto. ¡Si todavía no has leído este libro!
Debe saber sobre la gestión de la memoria, los delegados
La respuesta de Jon es buena. Esas son áreas bastante básicas pero importantes que muchos desarrolladores no entienden bien. Creo que conocer la diferencia entre el valor y los tipos de referencia se relaciona con una comprensión básica de cómo se comporta el GC en .NET, pero, lo que es más importante, una buena comprensión del patrón Dispose es importante.
El resto de las áreas que menciona son conocimiento muy profundo sobre el CLR en sí mismo o conceptos más avanzados que no se usan ampliamente (todavía). [.NET 4.0 comenzará a cambiar parte de eso con la introducción de las extensiones paralelas y MEF.]
Actualizado: leyendo las partes relevantes del libro CLR a través de C # por Jeffrey Richter ... este libro puede ser una buena referencia.
La mayoría de ellos son mucho más profundos que el tipo de cosas en las que muchos desarrolladores caen en mi experiencia. La mayoría de los aspectos incomprendidos (e importantes) en mi experiencia:
- Tipos de valores frente a tipos de referencia
- Variables vs objetos
- Pase por ref vs pase por valor
- Delegados y eventos
- Distinguir entre idioma, tiempo de ejecución y marco
- Boxeo
- Recolección de basura
En el frente "variables vs objects", aquí hay tres afirmaciones sobre el código
string x = "hello";
- (Muy mal)
xes una cadena con 5 letras - (Un poco mejor)
xes una referencia a una cadena con 5 letras - (Correcto) El valor de
xes una referencia a una cadena con 5 letras
Obviamente, los primeros dos están bien en una conversación "casual", pero solo si todos los involucrados entienden la situación real.
La respuesta de Jon parece ser bastante completa para mí (más delegados), pero creo que lo que separa fundamentalmente a un buen programador de un medio es responder a las preguntas sobre por qué y no cómo. Es genial saber cómo funcionan las recolecciones de basura y cómo funcionan los tipos de valores y los tipos de referencia, pero es un nivel completamente diferente para comprender cuándo usar un tipo de valor frente al tipo de referencia. Es la diferencia entre hablar en un idioma o dar un discurso en un idioma (se trata de cómo aplicamos el conocimiento que tenemos y cómo llegamos a esas decisiones).
Un gran programador no se puede medir por la cantidad de cosas que sabe sobre el CLR. Claro que es un buen comienzo, pero también debe saber OOP / D / A y muchas otras cosas como Patrones de diseño, Mejores prácticas, conceptos de O / RM, etc.
El hecho es que diría que un "gran programador de .Net" no necesita saber mucho sobre el CLR en absoluto, siempre y cuando tenga un gran conocimiento sobre la teoría y los conceptos generales de programación ...
Preferiría contratar a un "gran desarrollador de Java" con gran conocimiento general y experiencia en Java para un trabajo de .Net y luego un "maestro" en .Net que tenga poca experiencia y piense que O / RM es un ticker de acciones y los procedimientos almacenados son un gran forma de "abstraer la base de datos" ...
He visto a profesores profesionales en .Net fallar por completo en hacer cosas realmente simples sin romperse la espalda debido a la falta de "conocimiento general" mientras que al mismo tiempo "saben todo" que hay que saber sobre .Net y el CLR. .
Una cosa que puede ser realmente difícil de comprender es la ejecución diferida y los gustos.
¿Cómo se explica cómo funciona un método que devuelve un IEnumerable? ¿Qué hace realmente un delegado? ese tipo de cosas.