c# 3.0 - versiones - ¿Hay alguna desventaja de usar las características de C#3.0?
historia de c# (10)
Me dijeron que estas características no son estándar y confusas para la mayoría de los desarrolladores y su utilidad es dudosa. Estaba restringido a usar solo las funciones de C # 2.0 y él también está considerando prohibir los métodos anónimos.
Presumiblemente se traduce aproximadamente a su jefe lo que significa ...
Estas características son confusas para mí y no las encuentro útiles porque no las entiendo.
Lo que es bastante sintomático de la paradoja de Blub (bueno, o simplemente pura pereza). De cualquier manera, no hay mérito en lo que está diciendo, y debes comenzar a buscar otro trabajo si continúa por ese camino.
Me gustan las características de C # 3.0, especialmente las expresiones lambda, las propiedades implementadas automáticamente o, en casos adecuados, también se escriben de forma implícita variables locales (palabra clave var ), pero cuando mi jefe reveló que las estoy usando, me pidió que no usara ninguna característica de C # 3.0 en el trabajo. Me dijeron que estas características no son estándar y confusas para la mayoría de los desarrolladores y su utilidad es dudosa. Estaba restringido a usar solo las funciones de C # 2.0 y él también está considerando prohibir los métodos anónimos.
Ya que estamos apuntando a .NET Framework 3.5, no puedo ver ninguna razón para estas restricciones. En mi opinión, tal vez la única desventaja es que mis pocos compañeros de trabajo y el jefe (también programador) tendrían que aprender algunos conceptos básicos de C # 3.0, que no deberían ser difíciles. ¿Qué piensa usted al respecto? ¿Mi jefe tiene razón y me estoy perdiendo algo? ¿Existen buenas razones para dicha restricción en una empresa de desarrollo donde C # es un lenguaje de programación principal?
Me gustan las características de C # 3.0, especialmente las expresiones lambda, las propiedades implementadas automáticamente o, en casos adecuados, también se escriben de forma implícita variables locales (palabra clave var), pero cuando mi jefe reveló que las estoy usando, me pidió que no usara ninguna característica de C # 3.0 en el trabajo. Me dijeron que estas características no son estándar y confusas para la mayoría de los desarrolladores y su utilidad es dudosa.
Él tiene un punto
Siguiendo esa línea de pensamiento, hagamos una regla contra las colecciones genéricas, ya que la List<T> no tiene ningún sentido (corchetes angulares? Wtf?).
Mientras estamos en ello, eliminemos todas las interfaces (¿cuándo necesitarás una clase sin ninguna implementación?).
Demonios, salgamos adelante eliminando la herencia, ya que es tan complicado en estos días (is-a? Has-a? ¿No podemos ser amigos?).
Y el uso de la recursión es motivo de despido (Foo () invoca a Foo (). ¡Seguramente debes estar bromeando!).
Errrm ... vuelve a la realidad.
No es que las características de C # 3.0 sean una confusión para los programadores, es que las características son confusas para su jefe . Está familiarizado con una tecnología y se niega obstinadamente a desprenderse de ella. Estás a punto de entrar a la Paradoja de Blub de la Zona Crepuscular :
Los programadores están muy apegados a sus lenguajes favoritos, y no quiero herir los sentimientos de nadie, así que para explicar este punto voy a usar un lenguaje hipotético llamado Blub. Blub cae justo en el medio de la continuidad abstracta. No es el lenguaje más poderoso, pero es más poderoso que el lenguaje de máquina o Cobol.
Y, de hecho, nuestro hipotético programador de Blub no usaría ninguno de ellos. Por supuesto que no lo programaría en lenguaje de máquina. Para eso son los compiladores. Y en cuanto a Cobol, él no sabe cómo alguien puede hacer nada con eso. Ni siquiera tiene x (función de Blub de su elección).
Mientras nuestro hipotético programador de Blub esté mirando hacia abajo en el continuo de poder, él sabe que está mirando hacia abajo. Los lenguajes menos poderosos que Blub son obviamente menos poderosos, porque le faltan algunas características a las que está acostumbrado. Pero cuando nuestro hipotético programador de Blub mira en la dirección opuesta, subiendo el poder, no se da cuenta de que está mirando hacia arriba. Lo que él ve son simplemente idiomas raros. Probablemente los considera equivalentes en poder a Blub, pero también con todas estas otras cosas peludas. Blub es lo suficientemente bueno para él, porque piensa en Blub.
Sin embargo, cuando cambiamos al punto de vista de un programador que usa cualquiera de los lenguajes más altos en el continuo de poder, encontramos que a su vez mira a Blub. ¿Cómo puedes hacer algo en Blub? Ni siquiera tiene y.
C # 3.0 no es difícil. Seguro que puedes abusar de él, pero no es difícil ni confuso para ningún programador con más de una semana de experiencia con C # 3.0. Las habilidades de tu jefe se han quedado atrás y quiere que el resto del equipo baje a su nivel. ¡NO LO DEJES!
Continúe usando las funciones anónimas, la palabra clave var, las propiedades automáticas y lo que tenga al alcance de su corazón. No perderás tu trabajo por eso. Si él se enoja por eso, ríete.
Algunas personas simplemente temen el cambio, porque tal vez las haga parecer estúpidas usando nuevas tecnologías sofisticadas. También podría ser que su jefe no quiera que el equipo esté aprendiendo cosas nuevas en lugar de hacer el trabajo de la manera tradicional.
La palabra clave var puede ciertamente ser abusada, pero en la mayoría de los casos reduce el código redundante. LINQ es lo principal que desea de .Net 3.5 debido al gran ahorro de tiempo en la cantidad de código que tiene que escribir. Tu jefe debería alentarte a que lo uses. Además, las bibliotecas de clase base que ahora toman los delegados son parámetros, por lo que se limitará mucho al no usarlos. Los Lambda son solo un poco de azúcar sintáctica para hacer que los delegados estén más limpios.
Le recomendaría Integración efectiva en equipos de desarrollo de software y Liderar con ejemplos . Dos artículos realmente geniales sobre cómo tratar con equipos que temen el cambio.
El jurado aún está deliberando sobre las consecuencias a largo plazo de algunas características, pero si su razón principal es "es confuso para otros desarrolladores" o algo similar a lo que yo estaría preocupado por la calidad del talento.
He tenido una experiencia similar (se me pidió que no usara Genéricos porque puede ser confuso para mis colegas).
El hecho es que ahora usamos genéricos y ninguno de mis colegas tiene problemas con ellos. Es posible que no hayan comprendido cómo crear clases genéricas, pero sí que saben cómo usarlas.
Mi opinión al respecto es que cualquier desarrollador puede aprender a usar estas características de lenguaje. Pueden parecer avanzados al principio, pero a medida que la gente se acostumbra a ellos, el impacto de la novedad disminuye.
El principal argumento para usar estas características (o cualquier nueva característica de lenguaje) es que esta es una forma simple y fácil de ayudar a mis colegas a mejorar sus habilidades, en lugar de estancarse.
En cuanto a su problema particular, no usar lambdas. Muchas de las actualizaciones del BCL tienen sobrecargas que toman a los delegados como parámetros; en muchos casos se expresan más fácilmente como lambdas, no usarlos de esta manera es ignorar algunos de los usos nuevos y actualizados del BCL.
En lo que respecta a los problemas con sus compañeros que no pueden aprender lambdas, descubrí que Jon Skeets C # analiza en profundidad cómo evolucionaron de los delegados de una manera fácil de seguir y reveladora. Te recomendaría que obtuvieras una copia para tu jefe y colegas.
Si Microsoft no definió el estándar y estas fueron características que agregaron a un idioma que no es de Microsoft, yo diría que su jefe podría tener un punto. Sin embargo, dado que Microsoft define el lenguaje y usa estas mismas funciones para implementar partes significativas de .NET 3.5 (y 4.0), diría que sería una tontería ignorarlas. Es posible que no elija usar algunos de ellos (por ejemplo, es posible que las variantes no sean aceptables en todos los entornos debido a los estándares de codificación), pero una política general de evitar nuevas funciones parece irrazonable.
La parte más complicada es cuándo debe comenzar a usar nuevas funciones, ya que pueden ser confusas y pueden demorar el desarrollo. En general, elijo usar nuevas características de lenguaje y elementos de plataforma en nuevos proyectos. A menudo evito usarlos en proyectos que están actualmente en desarrollo cuando se presenta la mejora de la característica / marco, que aplaza hasta el próximo proyecto. En un proyecto largo, podría presentarlos en un hito significativo si la cantidad de arquitectura de búsqueda es pequeña o si la característica merece los cambios. Normalmente, esperaría hasta que el proyecto tenga que realizar cambios significativos de todos modos y luego evaluaría si está justificada la refactorización de nuevas funciones.
Si el proyecto es estrictamente C # 3+ a partir de ahora, entonces no romperá la compilación al incluir estos elementos. Sin embargo, antes de usarlos debes tener en cuenta lo siguiente:
- No puede usarlos si el líder del proyecto toma la decisión y vota no.
- Aparte de eso, debe usarlos donde el código sea mucho más fácil de mantener.
- No debe usarlos de manera confusa o innecesaria en el sentido de que no mejoran significativamente la capacidad de mantenimiento del código. Esto significa que no debe usarlos cuando el código sea efectivamente el mismo o apenas mejorado.
Su jefe tendrá que entender que las mejoras en el lenguaje (y otras) están diseñadas para brindar a los desarrolladores más capacidades y hacerlas más eficientes para completar la tarea en cuestión, y que si no las va a permitir por razones desconocidas, entonces:
- El equipo de desarrollo no está produciendo en su mayor potencial.
- La empresa no se beneficia de una mayor eficiencia / productividad.
como otros han dicho, los desarrolladores no valen la pena si no pueden mantenerse al día con algunas de las últimas mejoras en el lenguaje que están utilizando a diario . Sospecho que su jefe no ha programado mucho últimamente y es su incapacidad para entender las últimas mejoras de lenguaje lo que motivó esta decisión.
Tal vez pueda hacer una presentación una vez a la semana sobre cada función para todos y obtener algunos de los desarrolladores de su lado para ayudar a convencer a la administración de los beneficios.
Hace poco me mudé de una casa de C # de vanguardia a una casa de C # que se ejecutaba principalmente en dot.Net 1.1 y algunos proyectos 2.0, y en su mayoría usaba solo funciones 1.1. Por suerte la gerencia se aleja del código. A la mayoría de los desarrolladores les encantan todas las nuevas características en los marcos más nuevos, simplemente no tienen el tiempo ni la inclinación para descubrirlas por sí mismos. Una vez que logré mostrarles cómo pueden hacer su propia vida más fácil, comenzaron a usarlos por sí mismos y hemos migrado varios proyectos para obtener las nuevas características de idioma y mejores ventajas de herramientas.
Te guste o no, si planeas usar LINQ en cualquier situación, tendrás que utilizar algunas de las especificaciones de lenguaje C # 3.0.
Su jefe tendrá que calentarse con ellos si desea utilizar los conjuntos de características que obtiene de 3.5, que son numerosos y vale la pena invertir su tiempo en ellos.
Además, por mi experiencia en liderar equipos, descubrí que el uso de las especificaciones 3.0 en realidad ha ayudado a los desarrolladores a leer y entender el código base. Hay un tiempo aproximado de una semana que pasa el desarrollador tratando de comprender lo que significa la sintaxis, pero una vez que lo consiguen, prefieren la nueva forma a la antigua.