¿Cuál es tu opinión de programación más controvertida?

Esto es definitivamente subjetivo, pero me gustaría tratar de evitar que se vuelva discutidor. Creo que podría ser una pregunta interesante si la gente lo trata adecuadamente.

La idea de esta pregunta surgió del hilo de comentarios de mi respuesta a "¿Cuáles son las cinco cosas que odias de tu idioma favorito?" cuestión . Afirmé que las clases en C # deberían estar selladas de forma predeterminada: 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 una base relativamente pequeña (por ejemplo, la colocación de aparatos ortopédicos), pero los ejemplos podrían incluir cosas como "las pruebas unitarias no son realmente de gran ayuda" o "los campos públicos están bien". Lo importante (para mí, de todos modos) es que tienes razones detrás de tus opiniones.

Presente su opinión y razonamiento: animo a las personas a votar por opiniones bien argumentadas e interesantes, estén o no de acuerdo con ellas.

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

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

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

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

Demasiadas personas saltan a demasiados vagones y tratan de forzar métodos, patrones, marcos, etc. en cosas que no lo justifican. Solo porque algo es nuevo, o porque alguien respetado tiene una opinión, no significa que se ajuste a todos :)

EDITAR: Solo para aclarar: no creo que la gente deba ignorar las mejores prácticas, las opiniones valoradas, etc. Solo que las personas no deberían saltar ciegamente sobre algo sin pensar en POR QUÉ esta "cosa" es tan genial, ¿ES aplicable a lo que yo estoy haciendo, y ¿QUÉ beneficios / inconvenientes trae?

"Buscar en Google" está bien!

Sí, sé que ofende a algunas personas que sus años de intensa memorización y / o gloriosos montones de libros de programación están comenzando a quedarse en el camino a un recurso al que cualquiera puede acceder en cuestión de segundos, pero no debe tener eso en contra de las personas. que lo usan

Con demasiada frecuencia escucho googlear respuestas a problemas como resultado de críticas, y realmente no tiene sentido. En primer lugar, debe admitirse que todos necesitan materiales de referencia. No lo sabes todo y tendrás que buscar cosas. Concediendo eso, ¿realmente importa de dónde obtuviste la información? ¿Importa si lo buscaste en un libro, lo buscaste en Google o lo escuchaste de una rana parlante que alucinaste? No. Una respuesta correcta es una respuesta correcta.

Lo importante es que comprenda el material, lo use como el medio para el fin de una solución de programación exitosa, y el cliente / su empleador esté satisfecho con los resultados.

(aunque si está obteniendo respuestas de ranas parlantes alucinantes, probablemente debería obtener ayuda de todos modos)

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 por nosotros mismos) y los comentarios pobres, incorrectos, desactualizados y engañosos deben estar cerca de la parte superior de la lista de los artefactos más molestos en el código.

Creo que eventualmente muchas personas simplemente los dejan en blanco, especialmente esas monstruosidades de la caja de flores.

Es mucho mejor concentrarse en hacer que el código sea legible, refactorizar según sea necesario y minimizar las expresiones idiomáticas y las peculiaridades.

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 que la siguiente línea agregue uno al estilo de comentario total de factura .

XML está muy sobrevalorado

Creo que muchos saltan al carro XML antes de usar sus cerebros ... XML para material web es genial, ya que está diseñado para ello. De lo contrario, creo que algunas definiciones de problemas y pensamientos de diseño deberían evitar cualquier decisión de usarlo.

Mis 5 centavos

No todos los programadores son iguales

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

Es políticamente arriesgado hablar de eso, pero a veces me siento con ganas de señalar que, aunque varios miembros del equipo parezcan 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 real; sin embargo, me aseguré de que obtuvieran el crédito. :)

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

Por un lado, creo que el primer lenguaje de programación debería 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 pérdidas de memoria en C / C ++ no pueden apreciar completamente lo que Java trae a la mesa.

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

Si solo conoce un idioma, no importa cuán bien 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 comenzado a aprender, eso es todo lo que necesitas. No lo creo, cada idioma que he aprendido me ha enseñado algo nuevo sobre la programación que he podido incorporar a mi trabajo con todos los demás. Creo que cualquiera que se restrinja a un 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 concuerda con las cualidades que esperaría encontrar en un programador realmente bueno.

El rendimiento sí importa.

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

Creo que está perfectamente bien depurar su código llenándolo System.out.println(o cualquier declaración de impresión que funcione para su idioma). A menudo, esto puede ser más rápido que la depuración, y puede comparar los resultados impresos 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)

Tu trabajo es dejarte sin trabajo.

Cuando escribe software para su empleador, cualquier software que cree debe escribirse de tal manera que cualquier desarrollador pueda recogerlo y comprenderlo con un mínimo esfuerzo. Está bien diseñado, escrito de manera clara y consistente, con un formato limpio, documentado donde debe estar, se construye a diario como se esperaba, se registra en el repositorio y se versiona adecuadamente.

Si lo atropella un autobús, lo despiden, lo despiden o se va del trabajo, su empleador debería ser capaz de reemplazarlo en cualquier momento, y el próximo individuo podría asumir su papel, recoger su código y levantarse. corriendo dentro de una semana como máximo. Si él o ella no pueden 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.

1) La farsa de aplicaciones comerciales :

Creo que todo el marco de trabajo "Enterprise" 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.

Tome cualquier Java ORM regular o .NET, o cualquier marco MVC supuestamente moderno para cualquiera que haga "magia" para resolver tareas tediosas y simples. Terminas escribiendo enormes cantidades de repetitivo XML feo que es difícil 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 solo se necesitan para superar la inflexibilidad de Java y C #. Simplemente no necesitamos la mayoría de eso.

¿Qué hay de 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 en las que era necesario, 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 solo unos pocos scripts locales y una interfaz web simple.

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 de dominio en lo que sea que esté haciendo y que pueda aprender rápidamente. Si necesita desarrollar 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 man y los grupos de noticias y estar al día. Algo menos y esa persona no vale lo que le pagan.

3) El currículo común de titulación de "informática"

La mayoría de las carreras de ciencias de la computación e ingeniería de 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 profundiza en la programación funcional, está incompleta. Si no puede aplicar invariantes de bucle a un bucle trivial para bucle, no vale la pena como supuesto científico de la computación. Si sale con experiencia en lenguajes x e y y orientación a objetos, está lleno de s ***. Un verdadero científico de la computación 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 sé trivial

Getters y Setters son altamente sobreutilizados

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

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

ACTUALIZAR:

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

Primero que nada: cualquiera que use campos públicos merece tiempo en la cárcel

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

Mucha gente piensa:

private fields + public accessors == encapsulation

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

Por último, permítanme 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 por capricho o impulso. ¿Por qué, entonces, tantos programadores agregan automáticamente getters y setters a sus objetos, exponiendo sus campos privados como si fueran públicos?

Los diagramas UML están muy sobrevalorados

Por supuesto, hay diagramas útiles, por ejemplo , diagrama de clase para el patrón compuesto , pero muchos diagramas UML no tienen absolutamente ningún valor.

Opinión: SQL es código. Trátelo 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 mantenible.

Odio cuando veo un código SQL descuidado con formato libre. Si grita cuando ve ambos estilos de llaves en una página, ¿por qué o por qué no grita cuando ve un SQL o SQL con formato libre que oscurece u ofusca la condición JOIN?

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, fácil de cambiar, fácil de entender. Y es de esperar que otros desarrolladores también puedan aprender algo de él.

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

Realicé algunas entrevistas el año pasado, y durante mi parte de la entrevista se suponía que debía probar cómo pensaban las personas y cómo implementaban algoritmos simples a moderados en una pizarra blanca. Inicialmente comencé con preguntas como:

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

Es un problema que debería hacerte pensar, pero no debe 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 evaluados previamente por la agencia) ni siquiera pudieron comenzar a responderlo, o incluso explicar cómo podrían hacerlo. Entonces, 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, escriba 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 pensé que los desarrolladores deberían poder escribir código. Parece que, hoy en día, esta es una opinión controvertida. ¡Ciertamente está entre los candidatos a 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 profundizar en esto aquí (esa es una pregunta completamente nueva) aparte de decir que en gran medida te estás perdiendo el punto de la publicación .

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

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

Eso debería ser lo suficientemente controvertido;)

Los patrones de diseño están perjudicando el buen diseño más de lo que lo están ayudando.

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 los patrones, especialmente en el pequeño número de patrones que las personas pueden recordar realmente, y son demasiado abstractos para que las personas realmente recuerden más que un puñado. Entonces no están ayudando mucho.

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

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

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

PHP apesta ;-)

La prueba está en el pudín.

Las pruebas unitarias no te ayudarán a escribir un buen código

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

Además, los buenos desarrolladores mantendrán baja la cohesión, lo que hará que la adición de un nuevo código no 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 malos programadores hagan demasiado daño .

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

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

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

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

A veces, un código de basura rápido y sucio es todo lo que se necesita para cumplir una tarea en particular. Patrones, ORM, SRP, lo que sea ... Lanza una consola o aplicación web, escribe algunos sql en línea (se siente bien) y elimina el requisito.

Código == Diseño

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

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

El desarrollo de software es solo un trabajo

No me malinterpreten, 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 emergente haciendo típicamente 60 horas semanales 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 mi familia, mi novia, amigos, felicidad, etc., y por debajo de otras cosas que preferiría estar haciendo si tuviera un suministro ilimitado de dinero en efectivo, como andar en moto, veleros o snowboard.

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

También creo que no hay nada de malo en tener binarios en el control de código fuente ... si hay una buena razón para ello. Si tengo un ensamblado para el que no tengo la fuente, y podría no estar necesariamente en el mismo lugar en cada máquina de desarrollo, entonces 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 hoguera por mencionar incluso "control de fuente" y "binario" en la misma oración. Incluso sé de lugares que tienen reglas estrictas que dicen que no puedes agregarlos.

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 (tal vez aún más, porque se les ha dicho una y otra vez que no necesitan preocuparse por la administración de la memoria, etc.)

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 un software. Solo las personas que realmente escriben software a tiempo completo para ganarse la vida deberían estar haciendo eso. 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í.

¿Cómo es eso de controvertido?

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

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

Me sorprende que esta sea una opinión controvertida, porque me parece 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 en realidad podría ser una minoría.

Las cosas que he visto que se promocionan como el enfoque correcto para cualquier proyecto, antes de que se conozca cualquier información al respecto, son cosas como el uso de Desarrollo impulsado por pruebas (TDD), Diseño controlado por dominio (DDD), Mapeo relacional de objetos (ORM) , Ágil (A mayúscula), Orientación a objetos (OO), etc., etc.que abarca desde metodologías hasta arquitecturas y componentes. Todo con bonitos acrónimos comercializables, por supuesto.

La gente incluso parece ir tan lejos como poner insignias en sus blogs como "I'm Test Driven" o similar, como si su estricta adhesión a un enfoque único, independientemente de los detalles del proyecto, sea realmente algo bueno .

No lo es

Elegir las metodologías y arquitecturas y componentes correctos, etc., es algo que debe hacerse por proyecto , y depende no solo 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 estás trabajando.