language-agnostic

language agnostic - ¿Cuál es tu opinión de programación más polémica?



language-agnostic (30)

Esto es definitivamente subjetivo, pero me gustaría intentar evitar que se convierta en argumentativo. Creo que podría ser una pregunta interesante si las personas lo tratan adecuadamente.

La idea para esta pregunta provino del hilo de comentarios de mi respuesta al "¿Cuáles son las cinco cosas que odias de tu idioma favorito?" pregunta Sostuve que las clases en C # deberían estar selladas por defecto: no pondré mi razonamiento en la pregunta, pero podría escribir una explicación más completa como respuesta a esta pregunta. Me sorprendió el calor de la discusión en los comentarios (25 comentarios actualmente).

Entonces, ¿qué opiniones contenciosas tienes ? Prefiero evitar el tipo de cosas que terminan siendo bastante religiosas con relativamente poca base (por ejemplo, la colocación de llaves) pero los ejemplos pueden incluir cosas como "la prueba de unidad no es realmente muy útil" o "los campos públicos están bien realmente". Lo importante (para mí, de todos modos) es que tienes razones detrás de tus opiniones.

Por favor, presente su opinión y su razonamiento: animaría a la gente a votar por opiniones bien argumentadas e interesantes, estén o no de acuerdo con ellas.

También creo que no hay nada de malo en tener binarios en el control de origen ... si hay una buena razón para ello. Si tengo un ensamblaje para el que no tengo la fuente, y es posible que no esté necesariamente en el mismo lugar en cada máquina devs, entonces generalmente lo pegaré en un directorio "binario" y lo referenciaré en un proyecto usando una ruta relativa .

Mucha gente parece pensar que debería quemarme en la estaca incluso por mencionar "control de código fuente" y "binario" en la misma oración. Incluso conozco lugares que tienen reglas estrictas que dicen que no se pueden agregar.

Si solo conoce un idioma, no importa lo bien que lo sepa, no es un gran programador.

Parece que hay una actitud que dice que una vez que eres realmente bueno en C # o Java o cualquier otro idioma que hayas aprendido, eso es todo lo que necesitas. No lo creo, todos los idiomas que he aprendido me han enseñado algo nuevo sobre la programación que he podido traer de vuelta a mi trabajo con todos los demás. Creo que cualquiera que se limite a un solo idioma nunca será tan bueno como podría ser.

También me indica una cierta falta de inquietud y disposición para experimentar que no necesariamente coincide con las cualidades que esperaría encontrar en un programador realmente bueno.

Unit Testing no te ayudará a escribir buen código

La única razón para tener pruebas Unitarias es asegurarse de que el código que ya funciona no se rompa. Escribir pruebas primero, o escribir código para las pruebas es ridículo. Si escribe en las pruebas antes del código, ni siquiera sabrá cuáles son los casos de borde. Podría tener un código que supere las pruebas pero que todavía falle en circunstancias imprevistas.

Y, además, los buenos desarrolladores mantendrán la cohesión baja, lo que hará que la adición de un nuevo código sea poco probable que cause problemas con las cosas existentes.

De hecho, lo generalizaré aún más,

La mayoría de las "Mejores Prácticas" en Ingeniería de Software están ahí para evitar que los programadores malos hagan demasiado daño .

Están allí para agarrar a los desarrolladores malos y evitar que cometan errores tontos. Por supuesto, ya que la mayoría de los desarrolladores son malos, esto es algo bueno, pero los buenos desarrolladores deberían obtener un pase.

"Googlearlo" está bien!

Sí, sé que ofende a algunas personas que sus años de memorización intensa y / o pilas de libros de programación estén empezando a caer en el camino de un recurso al que cualquiera puede acceder en cuestión de segundos, pero no debería sostener eso contra la gente. que lo usen

Muy a menudo escucho las respuestas en google a los problemas como resultado de la crítica, y realmente no tiene sentido. En primer lugar, se debe admitir que todos necesitan materiales de referencia. Usted no sabe todo y tendrá que buscar las cosas. Concediendo eso, ¿realmente importa de dónde obtuviste la información? ¿Importa si lo buscó en un libro, lo buscó en Google o lo escuchó de una rana parlante que alucinó? No. Una respuesta correcta es una respuesta correcta.

Lo importante es que entienda el material, lo use como un medio para finalizar una solución de programación exitosa, y el cliente / su empleador están contentos con los resultados.

(aunque si obtiene respuestas de ranas parlantes alucinatorias, probablemente debería recibir alguna ayuda de todos modos)

¡Menos código es mejor que más!

Si los usuarios dicen "¿eso es todo?", Y su trabajo permanece invisible, se hace correctamente. La gloria se puede encontrar en otros lugares.

1) La farsa de aplicaciones de negocios :

Creo que todo lo relacionado con los "Enterprise" frameworks es humo y espejos. J2EE, .NET, la mayoría de los marcos de Apache y la mayoría de las abstracciones para administrar tales cosas crean mucha más complejidad de la que resuelven.

Use cualquier ORM de Java o .NET normal, o cualquier marco MVC supuestamente moderno para cualquiera que haga "magia" para resolver tareas tediosas y simples. Terminas escribiendo enormes cantidades de feos XML que son difíciles de validar y escribir rápidamente. Tiene API masivas donde la mitad de ellas son solo para integrar el trabajo de las otras API, interfaces que son imposibles de reciclar y clases abstractas que son necesarias solo para superar la inflexibilidad de Java y C #. Simplemente no necesitamos la mayor parte de eso.

¿Qué tal todos los diferentes servidores de aplicaciones con su propia sintaxis de descriptor, la base de datos demasiado compleja y los productos de groupware?

El punto de esto no es esa complejidad == mala, es esa complejidad innecesaria == mala. He trabajado en instalaciones empresariales masivas donde algunas de ellas eran necesarias, pero incluso en la mayoría de los casos, todo lo que se necesita para resolver la mayoría de los casos de uso es una serie de scripts locales y una sencilla interfaz web.

Intentaría reemplazar todas estas aplicaciones empresariales con marcos web simples, bases de datos de código abierto y construcciones de programación triviales.

2) Los n-años de experiencia requeridos:

A menos que necesite un consultor o un técnico para manejar un problema específico relacionado con una aplicación, API o marco, entonces realmente no necesita a alguien con 5 años de experiencia en esa aplicación. Lo que necesita es un desarrollador / administrador que pueda leer la documentación, que tenga conocimiento del dominio en lo que sea que esté haciendo y que pueda aprender rápidamente. Si necesita desarrollarse en algún tipo de lenguaje, un desarrollador decente lo recogerá en menos de 2 meses. Si necesita un administrador para el servidor web X, en dos días debería haber leído las páginas de manual y los grupos de noticias y estar al día. Cualquier cosa menos y esa persona no vale lo que se le paga.

3) El currículo común del grado de "informática":

La mayoría de los grados de ingeniería informática y software son toro. Si su primer lenguaje de programación es Java o C #, entonces está haciendo algo mal. Si no obtienes varios cursos llenos de álgebra y matemáticas, está mal. Si no profundizas en la programación funcional, está incompleta. Si no puede aplicar invariantes de bucle a un trivial para bucle, no merece la pena su sal como supuesto científico informático. Si obtienes experiencia en idiomas xey, y orientación a objetos, está lleno de s ***. Un científico de la computación real ve un lenguaje en términos de los conceptos y sintaxis que usa, y ve las metodologías de programación como una entre muchas, y tiene una comprensión tan buena de las filosofías subyacentes de ambos, que elegir nuevos lenguajes, métodos de diseño o lenguajes de especificación debería ser trivial

Código == Diseño

No soy fanático de los sofisticados diagramas UML y la documentación de código sin fin. En un lenguaje de alto nivel, su código debe ser legible y comprensible tal como está. La documentación compleja y los diagramas no son más fáciles de usar.

Aquí hay un artículo sobre el tema Código como Diseño .

Cada desarrollador debe estar familiarizado con la arquitectura básica de las computadoras modernas. Esto también se aplica a los desarrolladores que se dirigen a una máquina virtual (quizás incluso más, porque se les ha dicho una y otra vez que no tienen que preocuparse por la gestión de la memoria, etc.)

El desarrollo de software es solo un trabajo.

No me malinterpretes, disfruto mucho el desarrollo de software. He escrito un blog durante los últimos años sobre el tema. He pasado suficiente tiempo aquí para tener más de 5000 puntos de reputación. Y trabajo en una empresa de nueva creación que suele durar 60 horas a la semana por mucho menos dinero del que podría obtener como contratista porque el equipo es fantástico y el trabajo es interesante.

Pero en el gran esquema de las cosas, es solo un trabajo.

Se clasifica en importancia por debajo de muchas cosas, como la familia, mi novia, amigos, felicidad, etc., y por debajo de otras cosas que preferiría hacer si tuviera un suministro ilimitado de dinero en efectivo, como andar en moto, navegar en yate o practicar snowboard.

Creo que a veces muchos desarrolladores olvidan que desarrollar es solo algo que nos permite tener las cosas más importantes en la vida (y tenerlas haciendo algo que disfrutamos) en lugar de ser el objetivo final en sí mismo.

El rendimiento importa.

El uso de la notación húngara debe ser castigado con la muerte.

Eso debería ser suficientemente controvertido;)

Escribir pequeños métodos. Parece que a los programadores les encanta escribir muchos métodos donde hacen múltiples cosas diferentes.

Creo que se debe crear un método donde se pueda nombrar uno.

Está bien escribir código de basura de vez en cuando

A veces, todo lo que se necesita para completar una tarea en particular es un código de basura rápido y sucio. Patterns, ORMs, SRP, lo que sea ... Levante una consola o una aplicación web, escriba un sql en línea (se siente bien) y elimine el requisito.

Getters y Setters son muy utilizados en exceso

He visto a millones de personas que afirman que los campos públicos son malos, por lo que los hacen privados y brindan adeptos y colocadores para todos ellos. Creo que esto es casi idéntico a hacer públicos los campos, tal vez un poco diferente si está utilizando subprocesos (pero en general no es el caso) o si sus accesores tienen lógica de presentación / negocios (algo "extraño" al menos).

No estoy a favor de los campos públicos, pero estoy en contra de hacer un getter / setter (o propiedad) para cada uno de ellos, y luego afirmar que hacer eso es encapsular o esconder información ... ¡ja!

ACTUALIZAR:

Esta respuesta ha generado cierta controversia en sus comentarios, así que intentaré aclararlo un poco (dejaré el original intacto ya que eso es lo que muchas personas votaron).

En primer lugar: cualquiera que use campos públicos merece tiempo en la cárcel.

Ahora, crear campos privados y luego usar el IDE para generar captadores y definidores automáticamente para cada uno de ellos es casi tan malo como usar campos públicos.

Mucha gente piensa:

private fields + public accessors == encapsulation

Digo (de forma automática o no) que la generación del par getter / setter para sus campos va efectivamente contra la llamada encapsulación que está tratando de lograr.

Por último, permítame citar al tío Bob en este tema (tomado del capítulo 6 de "Código limpio"):

Hay una razón por la que mantenemos nuestras variables privadas. No queremos que nadie más dependa de ellos. Queremos la libertad de cambiar su tipo o implementación en un capricho o un impulso. ¿Por qué, entonces, tantos programadores agregan captadores y definidores automáticamente a sus objetos, exponiendo sus campos privados como si fueran públicos?

La única "mejor práctica" que debe usar todo el tiempo es "Use Your Brain".

Demasiada gente saltando en demasiados carros de banda y tratando de forzar métodos, patrones, marcos, etc. sobre cosas que no los justifican. Solo porque algo sea nuevo, o porque alguien respetado tenga una opinión, no significa que se adapte a todos :)

EDITAR: Solo para aclarar: no creo que las personas deban ignorar las mejores prácticas, las opiniones valiosas, etc. Solo que las personas no deberían simplemente saltar ciegamente sobre algo sin pensar POR QUÉ esta "cosa" es tan grande, ¿es aplicable a lo que yo? Estoy haciendo, y ¿QUÉ beneficios / inconvenientes trae consigo?

La legibilidad es el aspecto más importante de su código.

Incluso más que la corrección. Si es legible, es fácil de arreglar. También es fácil de optimizar, de cambiar, de entender. Y espero que otros desarrolladores puedan aprender algo de esto también.

La mayoría de los comentarios en el código son, de hecho, una forma perniciosa de duplicación de código.

Pasamos la mayor parte de nuestro tiempo manteniendo el código escrito por otros (o nosotros mismos) y los comentarios deficientes, incorrectos, obsoletos y engañosos deben estar al principio de la lista de los artefactos más molestos del código.

Creo que con el tiempo muchas personas simplemente los dejan en blanco, especialmente esas monstruosidades de macetas.

Es mucho mejor concentrarse en hacer que el código sea legible, refactorizar según sea necesario y minimizar los modismos y la extravagancia.

Por otro lado, muchos cursos enseñan que los comentarios son casi más importantes que el código en sí, lo que lleva a la siguiente línea que agrega uno al estilo de comentario de factura total .

Las declaraciones de impresión son una forma válida de depurar código

Creo que está perfectamente bien depurar su código ensuciándolo con System.out.println (o cualquier declaración impresa que funcione en su idioma). A menudo, esto puede ser más rápido que la depuración, y puede comparar las salidas impresas con otras ejecuciones de la aplicación.

Solo asegúrese de eliminar las declaraciones de impresión cuando vaya a producción (o mejor, conviértalas en declaraciones de registro)

Los arquitectos / diseñadores de software están sobrevalorados

Como desarrollador, odio la idea de los arquitectos de software. Básicamente son personas que ya no codifican a tiempo completo, leen revistas y artículos, y luego le dicen cómo diseñar software. Solo las personas que escriben software a tiempo completo para ganarse la vida deberían hacerlo. No me importa si fuiste el mejor programador del mundo hace 5 años antes de convertirte en Arquitecto, tu opinión es inútil para mí.

¿Qué tal eso para controversial?

Editar (para aclarar): Creo que la mayoría de los arquitectos de software son grandes analistas de negocios (hablar con los clientes, requisitos de redacción, pruebas, etc.), simplemente creo que no tienen lugar en el diseño de software, de alto nivel o de otro tipo.

Los patrones de diseño perjudican al buen diseño más de lo que lo ayudan.

El diseño de software de la OMI, especialmente el buen diseño de software, es demasiado variado para ser capturado de manera significativa en patrones, especialmente en el pequeño número de patrones que las personas pueden recordar, y son demasiado abstractos para que las personas recuerden más de un puñado. Así que no están ayudando mucho.

Y, por otro lado, demasiadas personas se enamoran del concepto y tratan de aplicar patrones en todas partes; por lo general, en el código resultante no se puede encontrar el diseño real entre todos los Singletons (completamente sin sentido) y las Fábricas abstractas.

Los programadores que no programan su tiempo libre para divertirse nunca serán tan buenos como los que lo hacen.

Creo que incluso las personas más inteligentes y con más talento nunca se convertirán en buenos programadores a menos que lo traten como algo más que un trabajo. Lo que significa que hacen pequeños proyectos al lado, o simplemente se meten con muchos idiomas e ideas diferentes en su tiempo libre.

(Nota: no estoy diciendo que los buenos programadores no hacen nada más que programar, pero hacen más que programar de 9 a 5)

No entiendo por qué la gente piensa que Java es absolutamente el mejor "primer" lenguaje de programación que se imparte en las universidades.

Por un lado, creo que el primer lenguaje de programación debe ser tal que resalte la necesidad de aprender el flujo de control y las variables, no los objetos y la sintaxis.

Por otro lado, creo que las personas que no han tenido experiencia en la depuración de fugas de memoria en C / C ++ no pueden apreciar lo que Java trae a la mesa.

Además, la progresión natural debe ser desde "cómo puedo hacer esto" a "cómo puedo encontrar la biblioteca que hace eso" y no al revés.

No existe un enfoque de desarrollo de "talla única" para todos

Me sorprende que esta sea una opinión controvertida, porque me parece que tiene sentido común. Sin embargo, hay muchas entradas en blogs populares que promueven el enfoque de desarrollo de "talla única", por lo que creo que realmente puedo estar en la minoría.

Las cosas que he visto ser promocionadas como el enfoque correcto para cualquier proyecto, antes de que se conozca cualquier información, son cosas como el uso de Test Driven Development (TDD), Domain Driven Design (DDD), Object-Relational Mapping (ORM) , Agile (capital A), Orientación a objetos (OO), etc., que abarca todo, desde metodologías hasta arquitecturas y componentes. Todos con bonitas siglas comerciales, por supuesto.

Las personas incluso parecen ir tan lejos como para colocar insignias en sus blogs como "I''m Test Driven" o similar, como si su adhesión estricta a un solo enfoque, independientemente de los detalles del proyecto del proyecto, sea realmente algo bueno .

No lo es

Elegir las metodologías y las arquitecturas y los componentes correctos, etc., es algo que se debe hacer por proyecto , y no solo depende del tipo de proyecto en el que esté trabajando y sus requisitos únicos, sino también del tamaño y la capacidad. del equipo con el que trabajas.

No todos los programadores son creados iguales

Muy a menudo los gerentes piensan que DeveloperA == DeveloperB simplemente porque tienen el mismo nivel de experiencia y así sucesivamente. De hecho, el rendimiento de un desarrollador puede ser 10x o incluso 100x que el de otro desarrollador.

Es políticamente arriesgado hablar de eso, pero a veces me da la impresión de que, aunque algunos miembros del equipo parecen tener la misma habilidad, no siempre es así. Incluso he visto casos en los que los desarrolladores principales estaban "más allá de la esperanza" y los desarrolladores junior hicieron todo el trabajo, aunque me aseguré de que obtuvieran el crédito. :)

Opinión: SQL es código. Tratarlo como tal

Es decir, al igual que su lenguaje C #, Java u otro objeto / procedimiento favorito, desarrolle un estilo de formato que sea legible y fácil de mantener.

Odio cuando veo un código SQL descuidado de formato libre. Si gritas cuando ves ambos estilos de llaves en una página, ¿por qué o por qué no gritas cuando ves SQL o SQL con formato libre que oculta o confunde la condición de ÚNETE?

PHP apesta ;-)

La prueba está en el pudín.

Si eres un desarrollador, deberías poder escribir código

Hice algunas entrevistas el año pasado, y para mi parte de la entrevista se suponía que debía probar la forma en que la gente pensaba y cómo implementaban algoritmos simples a moderados en una pizarra. Al principio comencé con preguntas como:

Dado que Pi puede estimarse utilizando la función 4 * (1 - 1/3 + 1/5 - 1/7 + ...) con más términos que brindan mayor precisión, escriba una función que calcule Pi con una precisión de 5 lugares decimales .

Es un problema que debería hacerte pensar, pero no debería estar fuera del alcance de un desarrollador experimentado (se puede responder en aproximadamente 10 líneas de C #). Sin embargo, muchos de nuestros candidatos (supuestamente preseleccionados por la agencia) ni siquiera pudieron comenzar a responder, o incluso explicar cómo podrían responder. Así que después de un tiempo comencé a hacer preguntas más simples como:

Dado que el área de un círculo viene dada por Pi multiplicado por el radio al cuadrado, escribe una función para calcular el área de un círculo.

Sorprendentemente, más de la mitad de los candidatos no pudieron escribir esta función en ningún idioma (puedo leer los idiomas más populares, así que les dejo usar cualquier idioma de su elección, incluido el pseudocódigo). Teníamos "desarrolladores de C #" que no podían escribir esta función en C #.

Esto me sorprendió. Siempre había pensado que los desarrolladores deberían poder escribir código. Parece que, hoy en día, esta es una opinión controvertida. ¡Ciertamente es entre los candidatos de la entrevista!

Editar:

Hay mucha discusión en los comentarios sobre si la primera pregunta es buena o mala, y si debe hacer preguntas tan complejas como esta en una entrevista. No voy a ahondar en esto aquí (esa es una pregunta completamente nueva) aparte de decir que en gran medida no está entendiendo el mensaje .

Sí, dije que la gente no podía avanzar con esto, pero la segunda pregunta es trivial y muchas personas tampoco podrían avanzar con eso. Cualquiera que se llame a sí mismo un desarrollador debería poder escribir la respuesta a la segunda en unos segundos sin siquiera pensarlo. Y muchos no pueden.

Tu trabajo es ponerte sin trabajo.

Cuando está escribiendo software para su empleador, cualquier software que cree debe escribirse de tal manera que cualquier desarrollador pueda recogerlo y entenderlo con un esfuerzo mínimo. Está bien diseñado, escrito de forma clara y coherente, con un formato limpio, documentado donde debe estar, se construye a diario como se espera, se registra en el repositorio y se realiza la versión adecuada.

Si lo atropella un autobús, lo despiden, lo despiden o se marcha del trabajo, su empleador debería poder reemplazarlo en cualquier momento, y el próximo tipo podría asumir su rol, recoger su código, levantarse y funcionando dentro de un máximo de una semana. Si él o ella no puede hacer eso, entonces has fallado miserablemente.

Curiosamente, he descubierto que tener ese objetivo me ha hecho más valioso para mis empleadores. Cuanto más me esfuerzo por ser desechable, más valioso me vuelvo para ellos.

XML está muy sobrevalorado

Creo que muchos se suben al carro XML antes de usar sus cerebros ... XML para cosas web es genial, ya que está diseñado para ello. De lo contrario, creo que algunos problemas de definición de problemas y diseño deberían anticiparse a cualquier decisión de usarlo.

Mis 5 centavos