La programación es relativamente una ocupación técnica altamente especializada, y hay una gran cantidad de programadores en todo el mundo. Todos los días se discute qué lenguaje de programación es el mejor, cuáles son los estándares de un buen programador, etc. A continuación, veamos las opiniones de programación más controvertidas.
1. Un programador que no programa por diversión en su tiempo libre nunca estará a la altura de aquellos colegas que disfrutan programando.
Creo que incluso la persona más inteligente y talentosa, si solo trata la programación como un trabajo, nunca se convertirá en un programador verdaderamente excelente. Quienes disfrutan programando también hacen pequeños proyectos en su tiempo libre, o experimentan con diversos lenguajes de programación e ideas de programación.
2. Las pruebas unitarias no ayudan a escribir código excelente.
La única razón para escribir pruebas unitarias es asegurarse de que el código que ya funciona no tenga problemas. Escribir pruebas primero o escribir código siguiendo las pruebas es absolutamente absurdo. Si escribes las pruebas antes que el código, ni siquiera sabes cuáles son los casos límite. Aunque puedas hacer que el código pase las pruebas, seguirá habiendo problemas en situaciones imprevistas. Además, un buen desarrollador intentará reducir el acoplamiento, por lo que es imposible que el código nuevo rompa el existente.
3. La única mejor práctica universalmente válida es "pensar con la cabeza".
Demasiadas personas persiguen tecnologías de moda y hacen todo lo posible por aplicar métodos, patrones y marcos de trabajo donde no corresponden. Las nuevas tecnologías y las opiniones de gurús famosos no equivalen a lo que es adecuado para la situación real.
4. Los comentarios en la mayoría del código son, en realidad, una manifestación perniciosa de duplicación de código.
Pasamos la mayor parte del tiempo manteniendo código escrito por otras personas (o por nosotros mismos), y los comentarios malos, incorrectos, desactualizados y engañosos son sin duda una de las cosas más frustrantes en el código. Muchos terminan eliminándolos. Se debería poner el esfuerzo en mejorar la legibilidad del código, refactorizar cuando sea necesario, y usar menos modismos y trucos ingeniosos. Además, muchos libros de texto todavía promueven que los comentarios son incluso más importantes que el código, lo que da como resultado una gran cantidad de comentarios llenos de tonterías.
5. Depender de Google no tiene nada de malo.
Esta afirmación seguramente irritará a esos eruditos archisabidos. Pero todo el mundo necesita consultar información, ¿no? La respuesta correcta es la respuesta correcta, ya sea que provenga de un manual secreto, de una transmisión privada o de una búsqueda en Google. Lo importante es entenderlo de verdad y ofrecer soluciones de programación exitosas que satisfagan a clientes y jefes.
6. Los programadores no nacen iguales.
Los gerentes suelen pensar que el programador A es igual al programador B porque tienen aproximadamente los mismos años de experiencia. En realidad, la eficacia de un desarrollador puede ser diez o incluso cien veces la de otro.
7. Realmente no puedo entender por qué Java es el primer lenguaje más adecuado para la enseñanza universitaria.
En primer lugar, creo que el primer lenguaje de programación debería centrarse en aprender el flujo de control y las variables, no en objetos y sintaxis. En segundo lugar, creo que quien no tenga experiencia depurando fugas de memoria en C/C++ no puede comprender completamente el propósito original de Java. Además, el proceso natural de desarrollo debería ir de "cómo hago esto" a "cómo encuentro una biblioteca que haga esto", y no al revés.
8. Si solo dominas un lenguaje, por muy experto que seas, sigues sin ser un buen programador.
Algunos piensan que con dominar C#, Java u otro lenguaje que hayas aprendido primero es suficiente. No estoy de acuerdo. Cada nuevo lenguaje que aprendo me enseña bastantes conocimientos nuevos de programación que pueden aplicarse a su vez en el trabajo. Cualquiera que se limite a un solo lenguaje no puede desarrollar todo su potencial. Además, la falta de curiosidad intelectual y de voluntad de explorar no son rasgos de un buen programador.
9. De vez en cuando no pasa nada por escribir código basura.
A veces, para ciertas tareas específicas, basta con un código rápido y sucio que funcione. Olvídate de patrones, ORM, SRP (principio de responsabilidad única), etc.
10. Las sentencias print son una forma válida de depuración.
Creo que está bien depurar el código con sentencias de salida como System.out.println. A menudo es más rápido que la depuración formal y permite comparar los resultados de diferentes ejecuciones. Pero debes eliminar estas sentencias antes de pasar a producción, o convertirlas en sentencias de registro.
11. Tu trabajo es hacerte prescindible.
El software que escribas debería permitir que cualquier otro desarrollador lo entienda y lo tome bajo su responsabilidad en poco tiempo. El software debe tener un diseño elegante, código claro y consistente, formato limpio, documentación adecuada, compilación diaria y una gestión de versiones apropiada. Si te atropella un coche, te despiden o renuncias, la empresa debería poder encontrar a alguien que te reemplace rápidamente. Si no puede, eres demasiado trágico. Lo interesante es que cuanto más haces esto, más valioso eres para la empresa.
Debajo de la publicación original alguien comentó: si no puedes ser reemplazado, tampoco podrás ascender.
12. Se abusa en extremo de los getters y setters.
Miles de personas dicen que los campos públicos son un pecado, que deberían ser privados y proporcionar getters y setters. Creo que en realidad no hay mucha diferencia, a menos que el programa sea multihilo, o que los métodos de acceso contengan lógica de negocio o de presentación (lo cual sería bastante extraño). No estoy a favor de los campos públicos, solo estoy en contra de que envolver con métodos de acceso o propiedades se llame encapsulación u ocultamiento de información.
13. SQL también es código, trátalo por igual.
SQL no es diferente de C#, Java u otros lenguajes orientados a objetos o procedurales; presta atención al formato, la legibilidad y la mantenibilidad del código.
14. Los diagramas UML están sobrevalorados.
Algunos diagramas son ciertamente útiles, como el diagrama de clases del patrón Composite. Pero muchos diagramas UML no tienen ningún valor.
Nota del editor de CSDN: Recuerdo que Robert Martin, al hablar de UML en "Desarrollo ágil de software (versión C#)", básicamente mostraba un diagrama y luego decía: parece que no es muy útil, yo no lo he usado mucho... Bajo la misma pregunta también hay una respuesta relacionada: código == diseño. Se considera que el código en lenguajes de alto nivel es más efectivo que los diagramas UML y la documentación.
15. La legibilidad es el aspecto más importante del código.
Incluso más importante que la corrección. El código legible también es fácil de corregir, optimizar, modificar y entender. Además, otros desarrolladores pueden beneficiarse de él.
16. XML está enormemente sobrevalorado.
Muchas personas que se subieron a este barco negro de XML por seguir la corriente no pensaron bien. XML está bien para aplicaciones web, porque para eso fue creado. Para otros problemas de definición y enfoques de diseño, debería evitarse el uso de XML en la medida de lo posible.
17. El desarrollo de software es solo un trabajo.
Amo el desarrollo de software. Actualmente trabajo en una startup, 60 horas a la semana, y el salario no es alto, solo porque el equipo es excelente y el trabajo es muy interesante. Pero visto desde una perspectiva más amplia, sigue siendo solo un trabajo. No es tan importante como la familia, mi novia, los amigos, la felicidad, etc. Si tuviera suficiente dinero, preferiría andar en moto, yate o snowboard. Muchos desarrolladores olvidan que programar no es un fin en sí mismo; solo nos proporciona las condiciones para hacer con alegría las cosas más importantes de la vida.
Nota del editor de CSDN: Esta afirmación parece contradecir un poco el punto 1.
18. Los desarrolladores deberían saber escribir código.
El año pasado hice muchas entrevistas; principalmente ponía a prueba el enfoque de las personas y cómo implementar algoritmos relativamente simples en una pizarra. A menudo empezaba con preguntas como esta:
Dado que Pi se puede calcular con la función 4 * (1 – 1/3 + 1/5 – 1/7 + …), y cuantos más términos, más preciso, escribe una función que calcule Pi con 5 decimales.
Este es un problema que se puede resolver en 10 líneas de C#. Pero muchos entrevistados no tenían ni idea. Así que tenía que seguir con preguntas como esta:
Dado que el área de un círculo es Pi multiplicado por el cuadrado del radio, escribe una función para calcularla.
Increíblemente, más de la mitad no pudo completar esta función en ningún lenguaje. Ay, los desarrolladores deberían saber escribir código; ahora hasta esto se ha convertido en una opinión controvertida...
19. Los patrones de diseño hacen más daño que bien.
El diseño de software, especialmente el buen diseño, es infinitamente variado, y no se puede resumir de manera significativa con patrones, sobre todo los pocos patrones que todos recuerdan; además, son demasiado abstractos, y en realidad pocos recuerdan muchos de ellos. Por lo tanto, los patrones de diseño no sirven de mucho. Por otro lado, hay demasiada gente fascinada por el concepto de patrones de diseño que intenta usarlos en todas partes; el resultado es que en el código a menudo apenas se encuentra diseño, aparte de algunos singletons y fábricas abstractas sin sentido.
20. Cuanto menos código, mejor.
Si el usuario no ve tu trabajo, es que lo estás haciendo bien. La gloria está en otra parte.
Otras respuestas bastante populares incluyen:
21. El rendimiento es realmente importante.
22. Las aplicaciones empresariales son ridículas. Exigir n años de experiencia es una tontería. Los programas de grado en ciencias de la computación son puro engaño.
23. Las pruebas unitarias no ayudan a escribir buen código; la mayoría de las llamadas mejores prácticas de la ingeniería de software existen para evitar que los programadores malos causen demasiados estragos.
24. Todo programador debería estar familiarizado con la arquitectura de las computadoras modernas.
25. Escribe métodos pequeños.
26. ¡PHP es una basura!
27. C++ es uno de los peores lenguajes de la historia.
28. La mayoría de los programadores profesionales son pésimos.
29. Para convertirte en programador, primero debes aprender a escribir con teclado.
30. Cuantas más reglas y procesos ajenos a la programación haya, peor será la calidad del código.
El programador de juegos veterano James Hague (del famoso blog Prog21) también vio este artículo y consideró que estas opiniones no tenían mucha controversia. Escribió una entrada de blog dedicada y propuso opiniones que él consideraba aún más controvertidas; varias de ellas aludían a otros artículos que había publicado anteriormente:
31. La especialidad en ciencias de la computación debería ofrecerse solo como especialidad secundaria.
32. Presentar la orientación a objetos a programadores novatos antes de que entiendan cómo descomponer problemas y convertir las soluciones en código es un gran error.
33. Las optimizaciones complejas del compilador casi no tienen valor, incluso si producen un código más rápido. Reducen considerablemente la velocidad de compilación y probablemente generan errores difíciles de manejar, lo que dificulta aún más la resolución de problemas de rendimiento.
34. No se debe permitir que personas sin diez años de experiencia en programación escriban bibliotecas para uso de otros. Ignorar esta regla te hará arrepentirte toda la vida.
35. No importa si el código es feo o no. El formato no tiene nada que ver con que el código funcione o sea confiable; se pueden usar herramientas automatizadas para ordenar el formato.
36. La programación puramente funcional no sirve de mucho. Pero mezclarla un poco en código imperativo funciona bastante bien.
37. El pensamiento establecido de la ingeniería de software puede obstaculizar la creación de grandes obras.