¿Qué opiniones impopulares tienes sobre el desarrollo de software?

Me encanta la pregunta! Lleva a tantas respuestas geniales. Me encuentro votando incluso con los que estoy totalmente en desacuerdo. Las opiniones impopulares son mucho más constructivas que la mentalidad de rebaño que prevalece en la industria tecnológica. Así que aquí están los míos:

Windows es un buen sistema operativo para el desarrollo de software.
Sé de hecho que esta es mi opinión más impopular con diferencia. La mayoría de los desarrolladores parecen odiar a Windows con pasión. En mi opinión, esto se basa principalmente en razones emocionales, no objetivas. Cualquier cosa que pueda hacer en Linux y macOS, puede hacerlo en Windows. Además, tiene Visual Studio, que podría decirse que es el mejor IDE que existe. El argumento principal contra Windows es que no tienes bash nativo, pero adivina qué: Powershell no es inferior a bash. Esa es otra opinión impopular allí mismo.

Las bases de datos SQL son las mejores y todo lo demás apesta.
MongoDB y otros tipos de bases de datos NoSQL pueden parecer una buena idea, pero para la mayoría de las aplicaciones, usarlas voluntariamente es como orinar en los pantalones para mantenerse caliente. Nada supera la estructura de un RDBMS.

Big data es un problema, no una solución.
Todos hemos escuchado los fragmentos de marketing de cómo los grandes datos llevarán su negocio al siglo XXI y cómo todo florecerá como resultado. Bien adivina que. Si tiene grandes datos, tiene un gran problema, porque ya no puede usar las mejores herramientas para el trabajo (vea la opinión anterior). El uso de tecnologías de big data solo aliviará el problema, no lo resolverá. Más del 99% de todas las empresas no tienen big data, de todos modos.

Todo sobre el desarrollo web actual está mal.
Queremos contenido dinámico, pero estamos atascados con HTML por razones heredadas. Por eso, necesitamos usar JavaScript, que es un lenguaje horrible con el que también estamos atrapados por razones heredadas. Dado que estas tecnologías están muy desactualizadas, las personas han comenzado a inventar todo tipo de marcos y herramientas que terminan complicando las cosas. Este es el lamentable estado en que se encuentra el desarrollo web. Si pudiéramos tirar todo y recrear la web por completo, estoy seguro de que podríamos desarrollar mejores aplicaciones web en menos de la mitad del tiempo que lo hacemos ahora.

La escritura dinámica está bien, incluso en grandes proyectos.
Veo que la gente enumera exactamente lo contrario como una opinión impopular, pero estoy bastante seguro de que voy en contra de la corriente aquí. En mi opinión, no necesita interfaces Java vacías que le digan cómo implementar las cosas si tiene un equipo de desarrolladores competentes. Los lenguajes dinámicos permiten un desarrollo más rápido, iteraciones de depuración más rápidas y un código más simple. Eso supera las desventajas de no tener verificación de tipo.

Las pruebas unitarias no deben escribirse a menos que sean necesarias con certeza.
Si está ejecutando una configuración de integración continua, necesita pruebas unitarias, pero si está creando una pequeña aplicación que puede depurar fácilmente, le digo que la deje. A menudo veo que se prueban condiciones que obviamente seguirán siendo ciertas. Sí, 2 + 2 siempre se evaluará a 4. Las pruebas deben escribirse con la intención de romper el código. Deberían ser malvados.

Probablemente la mejor pregunta que he visto en Quora hasta ahora. Me gusta porque obliga al escritor a confesar sus opiniones impopulares y las opiniones impopulares son siempre muy, muy constructivas porque siempre podemos aprender algo de aquellos que ven las cosas de manera diferente.

Teniendo en cuenta que estoy en el registro aquí están algunas de mis opiniones muy impopulares sobre el desarrollo de software. Solo me enfocaré en vistas que sé que no son populares, siéntete libre de rasgar mi piel y decirme nombres.

• Java apesta, a lo grande . Un lenguaje creado para controlar los electrodomésticos se convierte en el estándar de la industria, ¿qué puede salir mal? Java es claramente el COBOL del futuro. Grande, feo y estándar. Incluso tengo miedo de pensar qué puede reemplazar a Java considerando lo que reemplazó a COBOL.
• Git es horrible Su querido y estándar sistema de administración de fuentes está mal diseñado, es oscuro y difícil de aprender. Y lo peor es que se hizo de esta manera a propósito. La idea general detrás de git es hacer que el control de versiones sea lo más difícil y oscuro posible para que sea imposible que los novatos lo adopten. CVS tuvo algunos problemas, pero fue mucho más consistente en términos de comandos y uso.
• La adopción de OOP en la industria se sostiene por el miedo . OOP se adoptó porque permite a las organizaciones contratar programadores baratos que les piden que hagan pequeñas cosas, mientras que un “arquitecto” maestro tiene el plan maestro para toda la aplicación. Esto es solo producto del miedo, muchas piezas increíbles de software fueron realizadas por un solo programador / hacker experto. A los gerentes no les gustan los programadores / hackers geniales, tienden a hacer lo que quieran y son caros. Lástima porque también tienden a producir un software increíble.
• El 95% del campo conocido como Ingeniería de software es un farol . Modelos, marcos, arquitecturas, gerentes, diseñadores, análisis, no hacen absolutamente nada. Dime una razón real para que exista UML. Hay toda una industria construida por aquellos que no pueden o no quieren codificar y la ironía es que han inventado la idea de “crecer” para detener la programación, lo cual es bastante extraño considerando que si todos “crecen” o logran la perfección, entonces el software no se va a hacer por arte de magia. Imagine un hospital donde las personas sin ninguna idea de la medicina estarían a cargo de los médicos diciéndoles lo que tienen que hacer, así es como se maneja la industria del software. Me dice que es un “diseñador” o un “analista funcional”. Escuché que no puede codificar. Período.
• No puedes discutir con el éxito . Supongamos que decide iniciar una aplicación haciendo todo lo que se supone que no debe hacer, evita las mejores prácticas, selecciona un idioma que, según dicen, utilizarían solo los humanos, decide no usar el marco popular o los métodos populares “.¿El resultado? Terminas construyendo una cosa llamada Facebook. Respeto mucho a las personas que “hacen”, y tengo mis dudas sobre las personas que comentan cómo deben hacerse las cosas. “Sé que todo esto está mal, pero me temo que podría estar bien”
• Los patrones de diseño son malvados, de verdad . Es muy difícil para mí imaginar por qué un patrón de interfaz de metal-duper-fabricante-aislador puede ser bueno. Esta locura tiene que parar. Thompson no sabía nada sobre patrones, construyó Unix.
• La optimización previa está perfectamente bien. ¿Quieres ser impopular? ¡Ve contra Donald Knuth! Realmente quiero decir esto, cuando Knuth dijo esta famosa cita no había Internet o BigData. Hoy, el escalado es con frecuencia más importante que la forma de resolver el problema. Es muy común comenzar a pensar en cómo se escalará el código incluso antes de pensar en una solución para el problema, si deja la optimización para el final, podría terminar encontrando que su hermoso código puede ejecutarse en 23 años en lugar de 207, y ahora qué ?
• La simplicidad es hermosa, la simplicidad está perdiendo. Un joven programador ingresa a una empresa, se le pide que aprenda la “arquitectura” del sistema, luego tiene que aprender las “prácticas de codificación”, el “marco”, luego las “suites de prueba”, se le presentan los “sprints” y “revisiones de código”, cuando finalmente escribe una línea de código, teme estar violando 105 políticas, rompiendo las prácticas y no haciendo uso del marco. Ahora digamos que el joven programador es Dennis Ritchie, que regresa con una máquina del tiempo, sería completamente inútil en la mayoría de las compañías de software hoy en día, no podría o no podría hacer nada. ¿Es esto correcto? No lo creo.
• Los lenguajes de programación no han progresado. C, Fortran y varios otros idiomas se desarrollaron en los años 70. En aquel entonces, la programación solo escribía una línea de código después de la otra usando un editor de texto. 40 años después, la programación es exactamente la misma. Puede decir que tiene una clase magna-composer de su marco interscalable, pero aún así escribe código con un editor de texto una línea tras otra.
• LISP sigue siendo agradable. Más de 50 años después de su creación, el lenguaje sigue siendo hermoso. Desde la simple abstracción “todo es una lista” hasta la forma en que puede cambiar todo el idioma si desea usar macros. En LISP, si tiene una elipse y establece ambos ejes a la misma longitud, el objeto puede convertirse en un círculo. ¿Por qué? Porque es un círculo. Haz eso en Java. ¡Buena suerte!

Me reservo el derecho de continuar esta lista, estoy seguro de que produciré opiniones más impopulares y leeré sus puntos de vista impopulares.

Dejaré que la sección de comentarios juzgue cuán impopulares son estos, pero aquí están algunas de mis opiniones sobre el desarrollo de software que parecen desafiar la sabiduría convencional:

La mayoría de las pruebas unitarias y los comentarios son una pérdida de tiempo.

Los programadores tienen una extraña fascinación por la integridad cuando compilan software. Cada método debe tener una prueba unitaria. Cada método debe tener un comentario que describa su propósito, sus parámetros, su valor de retorno.

Utilizamos métricas como “cobertura de prueba” para medir la calidad de nuestro software. Los IDE le darán advertencias si sus métodos no están comentados. Algunos repositorios de código están equipados con linters que ni siquiera te permitirán confirmar si no tienes suficientes comentarios sobre tu código.

Pero para todas las pruebas unitarias, el código aún se rompe. Para todos los comentarios, todavía no tengo idea de cómo usar su API.

¿Por qué?

Porque apuntamos a la integridad cuando deberíamos apuntar a la calidad . Prefiero ver una cobertura de prueba del 20% en el 20% del código que es realmente complicado y hace la diferencia entre la corrección y la basura. Prefiero usar nombres de métodos de autodescripción y tener comentarios solo para describir cosas que no se pueden inferir de la firma del método.

Aquí hay un ejemplo perfecto de un comentario que he visto en más de una ocasión que existe como víctima de esta mentalidad de “todo debe ser comentado”:

/ **
* Devuelve el ángulo entre dos puntos.
* *
* @param p1 El primer punto utilizado para calcular el ángulo.
* @param p2 El segundo punto utilizado para calcular el ángulo.
* @return El ángulo entre los dos puntos.
* /
public double getAngle (Punto p1, Punto p2);

Wow, 7 líneas enteras que no me dicen nada que no pueda inferir de la firma en sí. Quiero decir: se llama getAngle y se necesitan dos puntos . ¡Por supuesto que calcula el ángulo entre dos puntos! Pero lo más importante: ¿qué demonios son las unidades del ángulo?

Debido a que este programador se puso en esta mentalidad de que cada método necesita un comentario, se volvieron descuidados. Se olvidaron de mencionar la única cosa que no puedo inferir de la firma en sí.

Personalmente, tomaría el siguiente comentario sobre el anterior cualquier día:

/ **
* El ángulo en radianes.
* /
public double getAngle (Punto p1, Punto p2);

Éso es Todo lo que Necesito Saber. Gracias.

Mejor aún, simplemente llame al método getAngleInRadians y elimine el comentario por completo, o devuelva un objeto Angle que me permita obtener el valor en las unidades que elija.

Se puede hacer el mismo caso contra las pruebas unitarias. Es sorprendente la cantidad de pruebas que solo validan entradas / salidas básicas sin considerar cuán crítico es este comportamiento para la operación exitosa del sistema.

Cuando escribo código, suponiendo que no estoy trabajando en una API pública, dividiré, combinaré y eliminaré métodos constantemente como parte de mi refactorización. Si desea mantener la velocidad al construir algo, no puede ser tímido al hacer tales cambios.

Pero la mayoría de las pruebas unitarias existen para interponerse en ese proceso. Asumen que los métodos son un contrato. Algunos son, la mayoría no lo son. Esto parece derivarse de la mentalidad de “desarrollo basado en pruebas” que ha infectado a demasiados desarrolladores en los últimos tiempos. En caso de que no te hayas reunido hasta ahora: no soy fanático.

Ahora, permítanme advertir esto diciendo que la cantidad correcta de pruebas / comentarios depende en gran medida del tipo de software que esté desarrollando. Si es un código de misión crítica “la gente puede morir si nos equivocamos” para el Apolo 11, entonces tome todas las precauciones para asegurarse de que sea a prueba de balas, incluso si le cuesta velocidad.

Pero incluso si su objetivo es inclinarse hacia la robustez sobre la velocidad, le recomiendo que tenga cuidado de probar todo y comentar todo , ya que puede tener el costo de prestar suficiente atención a las pruebas y comentar los detalles no obvios que se pasan por alto fácilmente.

Toda la pila web es un gran error .

Todo, desde HTML a CSS, JavaScript a PHP, es simplemente terrible. El problema es que hemos tratado de adaptar una tecnología que originalmente estaba destinada a mostrar contenido estático de una manera independiente de la pantalla , para construir aplicaciones complejas en tiempo real. Y los trucos que hemos tenido que hacer para que funcione son como un castillo de naipes.

He hecho muchos juegos en mi día. Pasar de construir una interfaz de usuario en algo como Unity, donde lo que ves es lo que obtienes, a intentar representar un solo botón en un navegador, es como viajar 30 años atrás en el tiempo. Todo el concepto del DOM es como anatema para el diseño de la interfaz. El estilo en cascada (herencia) solo lo hace para que nada se represente como se esperaría la primera vez. Los marcos basados ​​en eventos de JavaScript no son adecuados para crear contenido verdaderamente dinámico. Y PHP es el peor lenguaje jamás concebido (me alegro de que siga el camino del dodo).

Cada avance reciente ha sido un intento de alejarnos de estos conceptos arcaicos hacia algo que se parezca más al desarrollo de aplicaciones tradicionales. En lugar del DOM tenemos lienzos. En lugar de JavaScript, tenemos WebAssembly. Pero wow, seguro que nos ha llevado mucho tiempo resolver esto, y todavía estamos muy lejos de la línea de meta.

El aprendizaje automático es realmente bastante simple en la práctica.

No me malinterpreten, hay mucha teoría interesante que subyace a muchos de los métodos de aprendizaje automático que damos por sentado hoy: estadísticas, teoría de optimización, etc. Y la infraestructura que se ha construido para aprovechar la afluencia de datos que ha permitido la máquina aprender a ser tan exitoso es igualmente impresionante, si no más.

Pero el trabajo real que se está haciendo en la industria con respecto al aprendizaje automático se reduce principalmente a la curación de datos y prueba y error. Hay algunos matices en el proceso de ingeniería de características: pasar de datos seleccionados a algo que su modelo realmente puede consumir como entrada. Pero más allá de eso, la complejidad es principalmente accidental, no esencial.

En otras palabras, espero que a medida que las herramientas se vuelvan más sofisticadas, gran parte del tiempo y el esfuerzo invertidos en el modelado de aprendizaje automático se automatizarán. La parte que consume más tiempo es a menudo el ciclo de entrenamiento del modelo, donde configuramos un experimento, entrenamos un modelo, esperamos una hora, luego examinamos los resultados y formulamos hipótesis sobre las formas en que podemos mejorarlo.

Pero los ejes sobre los que ajustamos nuestros modelos están muy limitados. No hay razón para que no podamos aprovechar un algoritmo para hacer la mayor parte de ese trabajo por nosotros. De hecho, el AutoML de Google ya es un paso en esa dirección.

Estas son solo algunas de las opiniones controvertidas que tengo sobre este campo. Como espero que no todos estén de acuerdo conmigo aquí, ¡me encantaría escuchar tus opiniones contrarias en los comentarios!

Las bases de datos relacionales son A-MA-ZING. La mayoría de los desarrolladores no pueden diseñar uno que valga la pena usar o escribir SQL que valga la pena ejecutar, y como resultado, la reputación de las bases de datos relacionales ha sufrido. Esa no es razón para tirar al bebé con el agua del baño. ¿Sabía que la teoría de la base de datos relacional se basa en el álgebra? Teoría de conjuntos, para ser precisos. A menudo me pregunto si la plataforma de base de datos que finalmente reemplaza al RDBMS se basará en algún otro campo de las matemáticas. Si tuviera que hacer un doctorado, ese sería mi tema.

Windows, ¿me estás tomando el pelo? ¿Alguna vez has tratado de hacer una manipulación de archivos decente con DOS? Sí, Cygwin es un gran emulador, pero no puedo respetar ningún sistema operativo que no tenga una buena herramienta de línea de comandos nativa. (Accesorios, Windows, para finalmente agregar uno, pero llegas una década o dos tarde a la fiesta).

Las preguntas de codificación, los acertijos, los cuestionarios son ridículos. Ya sabes, aquellos en los que, si no puedes hacerlos o hacerlo en X minutos, no eres un “programador real”. Ugh. El desarrollo de software es un campo muy grande en estos días. Lo que es relevante en un área rara vez se puede usar en otra.

JavaScript realmente apesta.

Unix / Linux es asombroso. No tengo razones para usarlo mucho, pero cada vez que lo hago, me sorprende su increíble utilidad. De acuerdo, esa no es una opinión impopular, pero solo tuve que inclinarme.

¡Oh muchacho, prepárate para el impacto!

• C ++ es basura. Solo es popular porque C era popular. Si está buscando un C ++ bien hecho, consulte el lenguaje de programación D.
• JavaScript es basura, pero TypeScript podría ser el futuro. TypeScript es un superconjunto de JavaScript que se compila a JS. Me encanta TS (agrega todo lo que le falta a JS: escritura estática explícita, clases, etc.) y, con un poco de esfuerzo, podríamos convertirlo en el nuevo JavaScript.
• La escritura dinámica nunca es la respuesta. Conduce a un código confuso, errores difíciles de detectar, y cualquier cosa que use la tipificación dinámica se puede reemplazar con una versión más clara que sea de tipo estático. He usado C # durante años y nunca he necesitado usar tipos dynamic . Lo mismo en Python, y el sistema de mecanografía de JS es puramente gracioso.
• OOP es bueno, pero está lejos de ser necesario. Claro que puede hacer que su código sea más limpio, pero también puede hacer que su código sea mucho más detallado. Además, puede ser muy difícil de usar si no lo usa correctamente. En varios casos, he encontrado más suerte en una atmósfera puramente procesal. Esto no quiere decir que no sé cómo usar OOP (estoy muy familiarizado con el concepto y no soy ajeno a usarlo), pero a veces simplemente no es la mejor opción.
• Con la documentación adecuada, el código de golf no es una mala opción en algunos casos. Sí, en la mayoría de los casos definitivamente es claridad sobre concisión, pero hay algunos casos donde la concisión óptima es la respuesta, incluso si la legibilidad sufre.

Bueno, ahí va mi reputación en la comunidad de programación, junto con cualquier posibilidad de conseguir un trabajo en Microsoft. ¡Espero que hayas disfrutado!

1. Los ORM son malvados:

1. Pro. Usan el mínimo común denominador de SQL (olvidando cosas avanzadas que tiene cada base de datos)
2. Contras. Por otro lado, necesita desesperadamente el generador de consultas para cualquier cosa dinámica. (O estás condenado a inventar uno tú mismo)
3. Neutral. Por lo general, terminas con algún tipo de mezcla entre cosas del generador de consultas para cosas dinámicas y consultas precodificadas para todo lo demás.

1. Pro. Probablemente no necesite la representación React + Redux + Isomorphic para su sitio web de noticias.

1. Sería 5 veces más fácil hacer su proyecto sin un complejo código frontal.
2. También tendrá optimización SEO por defecto
3. También funcionará en todas las máquinas sin muchos problemas
4. Casi todos los sitios principales (incluido usted, Quora) se pueden construir sin JS complejos en la parte frontal

1. Pro. REPL + Homoiconicity + Las estructuras de datos inmutables (Clojure) aumentarán su productividad. Es como escribir TDD pero más rápido (retroalimentación instantánea a través de REPL)
2. Contras. Las trazas de pila Clojure son malvadas. También extraño los tipos.

1. No sabemos cómo gestionar equipos. No ha habido ningún progreso real en el campo desde que “Peopleware” se actualizó en 1999, y eso en su mayoría solo confirma cosas en la edición de 1987, que solo realizó pequeños descubrimientos adicionales además de “El Mes del Hombre Mítico”, publicado en 1975. Todo lo demás que la gente dice saber sobre ingeniería de software no ha sido validado. Esto incluye todo el desarrollo ágil.
2. No hay ingenieros 10x. Hay personas que pueden programar y personas que no pueden, con experiencia y sin experiencia, expertos y no expertos, pero nadie es inmutablemente 10 veces más productivo. Lo que es cierto es que el nivel más alto de productividad reportado es 10 veces la productividad de las personas de menor rendimiento que realizan el trabajo. Sin embargo, lo que determina esto es la tranquilidad y la falta de interrupción, no las habilidades individuales.
3. Tu idioma favorito apesta. El diseño del lenguaje de programación es principalmente ad-hoc, mucho más preferencia personal que la ciencia, y siempre hay consideraciones mucho más importantes de todos modos. Independientemente del idioma que ames, hay casos en los que nunca deberías usarlo. Pero algunos idiomas nunca deberían usarse para nada. Smalltalk es un lenguaje increíble, pero casi nunca deberías usarlo. JavaScript es un lenguaje terrible, pero tienes que usarlo.
4. La abstracción en realidad se opone a la reutilización. Cuanto más abstraído es un software, menos reutilizable es porque toma decisiones inalterables que quizás no desee. Los componentes de software reutilizables tienen una alta cohesión y un bajo acoplamiento, pero esto no es lo mismo que abstraerse.
5. La habilidad de programación pura está actualmente sobrevalorada. La mayoría de las personas no pueden aprender a programar. Sin embargo, una vez que alguien demuestra que puede programar, los niveles más altos de habilidad tienen relativamente poco valor la mayor parte del tiempo. Las habilidades necesarias para aprobar la entrevista de Google, por ejemplo, son sustancialmente más altas que las necesarias para realizar la mayoría de los trabajos de programación, incluidos los trabajos de programación en Google. La experiencia en el dominio, las habilidades de comunicación, la ética laboral, etc. son mucho más valiosas que la capacidad de resolver acertijos de programación dinámica arbitraria.

Mucha gente ha comentado sobre cómo PHP es generalmente malo. Muchas otras personas han comentado sobre cómo PHP está generalmente bien.

Voy a ser más específico:

Los espacios de nombres en PHP 5.3.0 hicieron que el lenguaje saltara al tiburón.

No es el nombre inconsistente de la función, o los diversos intentos fallidos de automatizar la codificación segura, o el “Fractal del mal diseño” que arruinó PHP para mí. Eran espacios de nombres.

Problema 1: sintaxis

Usar el carácter de barra diagonal inversa (” \ “) como separador de espacio de nombres. Backslash es un metacarácter en prácticamente todos los lenguajes de programación, incluido PHP . Se supone que debe usarse en literales de cadena para escapar caracteres especiales o para secuencias de caracteres especiales como ” \n “.

El uso de la barra diagonal inversa para el separador de espacio de nombres fue un diseño tonto. Hubiera sido mejor usar ” :: ” como separador de espacio de nombres. Esto habría aprovechado la sintaxis familiar de C ++ y Perl.

Problema # 2: uso excesivo de espacios de nombres

Los desarrolladores de framework fomentan el uso de espacios de nombres para cada nivel de paquete, y los espacios de nombres se asignan directamente a directorios, como Java. No hay razón para esto. Un proyecto determinado debe tener un espacio de nombres para protegerlo de las colisiones de nombres con otros proyectos. Todas las demás clases dentro del proyecto están bajo su control, por lo que debería poder evitar nombrar clases con colisiones de nombres. No debería ser necesario que haya más de un nivel de espacio de nombres en un proyecto determinado.

PHP no es Java, y forzar una convención de un directorio por espacio de nombres está tratando de actuar como Java. Esto hace que los marcos PHP sean más caros en tiempo de ejecución, porque por convención no se pueden colocar múltiples espacios de nombres en el mismo archivo, aunque el lenguaje lo permita. Esto hace necesario que los marcos carguen docenas o cientos de archivos de clase individuales en cada solicitud. El almacenamiento en caché de Opcode ayuda, pero aún es mucho mejor concatenar todos los archivos de código de marco en un archivo grande.

Solución de ejemplo

Puede hacer un autocargador que funcione con su jerarquía de clases, tratando tanto \ como _ como separadores de directorio.

spl_autoload_register (función ($ class_name) {
$ class_name = str_replace (“\\”, “/”, $ class_name);
$ class_name = str_replace (“_”, “/”, $ class_name);
echo “(CARGANDO ARCHIVO DE CLASES $ class_name.php) \ n”; // depuración
incluye “{$ class_name} .php”;
});

// Clases en el espacio de nombres predeterminado

// Esto está en el directorio actual.
$ myClass = new \ MyClass ();
echo ‘$ myClass es un’ .get_class ($ myClass). “\ n”;

// Esto está en el subdirectorio ‘Otro’.
$ otherMyClass = new \ Other_MyClass ();
echo ‘$ otherMyClass es un’ .get_class ($ otherMyClass). “\ n”;

// Ahora clases en ‘Tu’ espacio de nombres

// Esto está en el directorio de espacio de nombres ‘Tu’
$ yourMyClass = new Your \ MyClass ();
echo ‘$ yourMyClass es un’ .get_class ($ yourMyClass). “\ n”;

// Esto está en el subdirectorio ‘Tu / Otro’
$ yourOtherMyClass = new Your \ Other_MyClass ();
echo ‘$ yourOtherMyClass es un’ .get_class ($ yourOtherMyClass). “\ n”;

Aquí están los archivos:

MyClass.php

clase MyClass {
}

Otro / MyClass.php

clase Other_MyClass {
}

Tu / MyClass.php

espacio de nombres Tu;
clase MyClass {
}

Your / Other / MyClass.php

espacio de nombres Tu;
clase Other_MyClass {
}

De esta manera, solo necesita un espacio de nombres por producto. Todo dentro de un producto dado puede organizarse por jerarquía de directorios usando _ separadores. No necesita un nuevo espacio de nombres en cada nivel de directorio.

Dónde empiezo…

***** JavaScript es un lenguaje basura.
Debes evitar usarlo si puedes. Si no puede, úselo con moderación. Utilice cualquier otro idioma en su lugar, incluidos los idiomas transpilados.

En el lado del servidor, use Ir en lugar de Nodo. Go es igual de fácil de usar y ejecutará anillos alrededor de Node. Go puede hacer girar cientos de miles de “gorutinas” o hilos sin sudar. Veamos a Node hacer eso.

***** Smalltalk es un lenguaje que todo desarrollador debe saber.
Es maravillosamente simple y elegante, lo que hace que sea fácil de aprender para principiantes. Incluso más fácil que Python. También es un lenguaje increíblemente poderoso, como lo demuestran más de tres décadas de uso comercial.

Smalltalk es extremadamente versátil, se utiliza en la web del lado del servidor, web del lado del cliente, escritorio, móvil, computación numérica, visualización de datos, aprendizaje automático, procesamiento de lenguaje natural, robótica, Internet de las cosas, ERP … la lista sigue y sigue.

***** La programación funcional no es una panacea ni una solución universal.
OOP y FP son herramientas. Tienen sus aplicaciones apropiadas. Sí, la POO ha sido abusada y utilizada en exceso durante mucho tiempo, pero eso no lo hace malo. Si hace que FP siga la misma trayectoria, también generará muchas críticas.

***** La escritura dinámica no es mala.
Podría decirse que los lenguajes de tipo dinámico son menos adecuados para escribir grandes aplicaciones (más de un cuarto de millón de líneas de código). Para todas las demás aplicaciones, que representan la gran mayoría del software , la escritura dinámica es muy ventajosa.

Los lenguajes de tipo dinámico requieren un enfoque de desarrollo de software diferente. Si intenta usar un lenguaje dinámico de la misma manera que usa un lenguaje de tipo estático, entonces puede tener problemas con los programas a gran escala. Cosas como TDD contribuyen en gran medida a mitigar problemas con grandes aplicaciones.

No es que los proyectos que usan lenguajes de tipo estático no sufran problemas de tamaño. Hay poca o ninguna evidencia de que a los proyectos dinámicos les vaya peor que a los proyectos estáticos cuando se trata de mantenibilidad. Todo lo que tenemos son algunas anécdotas. Y hablando anecdóticamente, el ejército de los Estados Unidos escribió con éxito un programa de simulación de batalla de un millón de líneas llamado JWARS en Smalltalk, un lenguaje dinámico y orientado a objetos.

En el análisis final, la capacidad de escribir programas a gran escala se reduce a la calidad de la gestión de proyectos , no a la elección del idioma ni a la escritura estática.

***** El desarrollo de software basado en archivos es antediluviano.
Durante el último medio siglo, la programación se ha realizado casi exclusivamente con archivos de texto que contienen resmas de código. En gran medida, eso se debe a que nos hemos acostumbrado a usar sistemas operativos basados ​​en archivos y carpetas. Nuestros editores de texto están basados ​​en archivos. Nuestros compiladores están basados ​​en archivos. Nuestro control de código fuente está basado en archivos. Es muy difícil para la mayoría de los desarrolladores liberarse de este modo de pensar.

Puede haber mejores formas de escribir software, pero no las descubriremos a menos que nuestras mentes sean abiertas y adaptables. No debemos seguir siendo esclavos de los archivos de texto.

Estoy de muy buen humor de trolling en estos días, así que no pude resistir el impulso. Aquí va.

La informática no es ingeniería de software, sino que está poco conectada a ella. Directamente de Wikipedia:

La ingeniería de software es un subcampo directo de ingeniería y tiene una superposición con la informática y la ciencia de gestión.

Una de las definiciones notables de la ingeniería de software:

“La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software” : Glosario estándar de la EEEE de terminología de ingeniería de software.

Sí. Porque la mayoría de los equipos de desarrollo siempre siguen enfoques de desarrollo sistemáticos, disciplinados y cuantificables …

Cuando escucho la palabra Ingeniería, me vienen a la mente imágenes de puentes, edificios, plantas de energía y barcos. Hay una diferencia algo sorprendente entre ese tipo de ingeniería y la ingeniería de software: una regulación más estricta. Si se propone levantar un edificio de 10 pisos, hay un montón de códigos y regulaciones de construcción que deberá seguir sobre incendios, plomería, mecánica, gas combustible, conservación de energía, mantenimiento de propiedades, alcantarillado y otras cosas.

Si sale y crea una aplicación web utilizada por más personas que las que usan el edificio de 10 pisos, hay muchas menos reglas a seguir. Se me vienen a la mente PCI DSS y GDPR, y el último se introdujo recientemente, pero no mucho más que se pueda aplicar a la ingeniería de software. Una gama más amplia de regulaciones es importante para los gigantes de la computadora o para algunos jugadores especializados, pero dudo que sean parte de la vida cotidiana de los desarrolladores promedio o buenos que publican código a diario. ¿Tiene una gran característica pero el código todavía tiene errores y necesita más pruebas? Diablos, envíalo allí y veamos cómo va. Las métricas de calidad, un atributo que generalmente es importante para las metodologías de ingeniería, tienen un contratiempo.

Hay un valor práctico diario en conocer y comprender cosas básicas de informática. Les pregunto a los candidatos en las entrevistas si pueden decirme la complejidad del fragmento de código que acaban de escribir. Me duele un poco cuando me encuentro con personas que escriben código aparentemente bueno pero no tienen idea de qué es la notación O grande y por qué es importante. Adivina qué sucederá cuando agreguen código a nuestro servicio REST que se llama decenas de millones de veces por día y no sabrán la diferencia entre O (log n) y O (n).

No está bien no saber un poco sobre las capas inferiores . La arquitectura típica de la computadora es poner capa sobre capa sobre toneladas de capas de abstracciones. La mayoría de las veces solo tratamos con los niveles más altos de esas abstracciones y eso es genial porque las abstracciones nos ahorran toneladas de tiempo.

Pero, ¿qué sucede cuando algo se rompe y las abstracciones no funcionan? Oh, la llamada a ese servicio web remoto no funciona. ¿Pero por qué? ¿La llamada simplemente agota el tiempo de espera y nunca se establece una conexión TCP (¿puede encontrar el desarrollador si se ha establecido una sesión TCP)? ¿El control remoto simplemente envía datos de la aplicación que se traducen como un error? ¿O las cosas se rompen en el establecimiento de la sesión porque simplemente está solicitando TLS 1.0 y el control remoto simplemente le dijo que se fuera? La diferencia entre una mirada en blanco en la cara de un desarrollador web y una persona que trabaja el problema es al menos algún conocimiento de la pila de abstracción y cómo se unen.

En realidad existen desarrolladores x10. La parte difícil aquí es definir qué significa realmente x10. Este término no indica personas que escriben 10 veces la cantidad de código de un desarrollador promedio. Para mí, denota personas que son desarrolladores 10 veces más efectivos, lo que se refiere efectivamente a la diferencia que hacen en comparación con el desarrollador promedio. Esta efectividad se manifiesta al encontrar la forma más eficiente de resolver un problema, resolver un problema rápidamente y sacar el código rápidamente, encontrar una manera de evitar resolver un problema por completo y guiar a los nuevos miembros para que puedan hacer las preguntas correctas y pensar para ellos mismos.

E iré un paso más allá: en realidad existen desarrolladores x100. Aquellos de uno en cien que pueden resolver un problema realmente difícil, aquellos que tienen la amplia experiencia para saber cómo integrar sistemas juntos, aquellos que crean desarrolladores a partir de programadores junior, aquellos que tienen epifanías lo suficientemente frecuentes y conocimiento e impulso para seguirlos y diseñar nuevos productos y nuevos enfoques de la forma en que funciona la empresa, actuando como multiplicadores para todos: estas personas marcan una gran diferencia. A veces, este proceso limita con los intangibles de la magia de la computadora, pero el resultado final está ahí y es medible. Solo necesita saber qué medir y dejar de pensar rutinariamente en los desarrolladores como meros recursos.

Lo que me lleva a una importante: las personas son más importantes que las metodologías y los procesos. Es importante contar con metodologías y procesos sólidos. Pero son las personas las que les dan vida y significado a través de su trabajo e impulso. Si no tiene personas comprometidas listas para desafiarse a sí mismas, proporcionar visión para su equipo, establecer objetivos inteligentes y luego enfocarse en la ejecución día a día, sus metodologías de sonido no lo salvarán.

Sinceramente, no sé cuán impopular es esto, pero según muchas conversaciones que he tenido, aún enfrenta mucha resistencia. Entonces aquí va:

El trabajo remoto funciona , y en muchos sentidos es ideal.

Sé que esto es probablemente bastante popular entre los desarrolladores, pero menos entre los gerentes. Parece haber una repulsión casi instintiva al concepto de permitir que sus desarrolladores trabajen de forma remota, y creo que es casi completamente irracional. Hay muchas justificaciones, pero en última instancia, creo que se reduce a la sensación de que de alguna manera está mal , que dejar que alguien trabaje desde casa es “hacer trampa”, y que finalmente invitará a la pereza y el abuso.

Nada de esto es verdad.

Por supuesto, hay, y siempre habrá, personas que hacen todo lo posible para evitar trabajar realmente. Y, por supuesto, si eres un gerente, no quieres que esas personas estén cerca de tu equipo. Pero la falla está en la suposición básica de que tener personas físicamente presentes en la misma oficina facilitará la eliminación de esas personas. La verdad es que si tiene buenas métricas para medir el progreso (control de calidad, seguimiento de tickets, comentarios de los clientes, etc.), sabrá si sus programadores están haciendo su trabajo, ya sea en el cubículo de al lado o en un Playa en Tahití. Y si no lo haces … estás bastante jodido pase lo que pase. Si su único método para determinar si las personas están trabajando es si “se ven ocupadas”, entonces pronto terminará con una compañía llena de George Costanzas, seguida en breve por ninguna compañía.

Y aquí están las buenas noticias: el trabajo remoto no solo es bueno para los empleados, también es bueno para la empresa. Si sus desarrolladores pueden trabajar desde su casa en sus propias computadoras (y no se equivoquen: son programadores. Tienen excelentes computadoras en casa), entonces no tiene que pagar por espacio de oficina, computadoras, almuerzos lujosos y sillones de masaje. , mesas de futbolín y todas las demás trampas que las compañías de software modernas se sienten obligadas a acumular en sus oficinas para verse “geniales” y “divertidas”. Sus empleados tendrán el ambiente de trabajo que desean, no le costará ni un centavo, y todos pueden concentrarse en hacer el trabajo. Ganar-ganar

Aún mejor: si su equipo no está atado a una ubicación específica (muy probablemente, una ubicación con un costo de vida escandaloso), acaba de abrirse a un enorme nuevo grupo de talentos. Puede encontrar un programador inteligente y trabajador que vive en Waco, TX, y puede trabajar para usted en este momento sin que tenga que convencerlo de que renuncie a su casa grande y cómoda por un pequeño $ 3000 / mes. apartamento en las afueras de Silicon Valley.

La mayoría de las objeciones que escucho al trabajo remoto giran en torno a cualidades intangibles: es decir, “hay cosas que puedes obtener de la comunicación cara a cara que simplemente no puedes superar en una videollamada”. Disparates. Trabajé en un entorno remoto durante años, y nunca me sentí tan desconectado de mi equipo. Tuvimos reuniones diarias y chats constantes a través de Skype (y, más tarde, Slack + Zoom) que fueron tan productivos y significativos (o tan divertidos y frívolos) como cualquier reunión cara a cara que haya tenido. Y lo mejor de todo, cuando la reunión terminó, pude finalizar la llamada y volver a concentrarme en mi trabajo sin preocuparme de que alguien simplemente “pasara” por mi oficina para “verificar mi progreso” (léase: interrumpir mi trabajo) . Es, por orden de magnitud, el mejor y más productivo entorno en el que he trabajado.

Es posible que su empresa y su equipo tarden un tiempo en adaptarse a un entorno remoto si no está acostumbrado, pero le garantizo que valdrá la pena.

Microsoft Entity Framework es malo : ni siquiera StackOverflow podría tolerarlo al crear su sitio web en ASP.NET. Entity Framework es hinchado, lento y requiere que lo extraigas cuando tengas que arreglarlo o acelerarlo. Peor aún es cuando tiene un esquema de base de datos que Entity Framework no puede representar o cuando utiliza procedimientos almacenados en abundancia. Eso lo obliga a bloquear su diseño de acceso a datos a Entity Framework que algún día podría volverse obsoleto. Luego, debe reescribir todo solo para obtener soporte del proveedor.

LINQ es malo : a lo largo de los años vi a diferentes desarrolladores en 3 equipos de desarrollo de software diferentes en 3 compañías diferentes usar LINQ. Dos de los desarrolladores tenían menos de 8 años de experiencia. El tercero, décadas de experiencia. En todos los casos, el programa se detendría porque el programa tomaría demasiado tiempo para iniciar el procesamiento de una declaración LINQ o un problema de producción tomaría mucho más tiempo para resolver descifrar una consulta LINQ de más de 40 líneas. Curiosamente, algunos de los mismos desarrolladores que aman LINQ no pueden comprender o adoptar SQL complejo en una base de datos relacional regular.

La optimización prematura es buena : si hay un consejo, que cuando se aplica en el mundo real , me lleva a dudar de lo que otros expresan como mejor práctica, es que la optimización prematura es mala. Definitivamente debe medir el rendimiento para mejorar cuando sea necesario. Simplemente hágalo muy temprano y cree estructuras de software eficientes desde el principio. Ahorra dolores de cabeza cuando o si el volumen de datos crece o los recursos informáticos ven una mayor utilización. Un buen programador a veces es flojo, pero no en este caso porque la necesidad de optimizar una solución bellamente abstracta puede llegar en un momento inconveniente.

El desarrollo rápido no siempre es apropiado : debe capturar casos extremos. Los usuarios finales los descubrirán, la realidad empresarial los creará. La codificación rápida va bien con los mejores escenarios. Cuando la salida del código escrito rápidamente coincide con la situación a un tee, eso es una victoria. De lo contrario, necesita un proceso similar a la metodología de cascada en el que verifica lo que está haciendo en varios niveles para asegurarse de que el software sea adecuado para la situación. Algunas situaciones de negocios tienen poca tolerancia para las iteraciones.

Finalmente, aprenda a escribir código en la línea de comandos : mi primer entorno de código fue un entorno de shell. Eso no hace que mi declaración sea válida. En cambio, considere lo que sucede cuando se rompe el editor de código visual. No podrá contar mientras espera que se arregle. Durante ese tiempo, no eres un programador ya que tu capacidad para codificar programas se limita a esa única herramienta. ¿Qué pasa si persisten otros problemas en esa herramienta que socava su capacidad para hacer el trabajo? Se pueden pasar horas, días reinstalando un sistema operativo simplemente para establecer las condiciones adecuadas para la instalación de un editor de texto glorificado con la finalización de la declaración. Sí, he visto que los compiladores de línea de comandos se rompen. En ese caso, descargue un compilador binario y reconstruya el compilador si es más reciente, luego ejecute su script de compilación para el programa y continúe.

Prepárense.

1. Casi cada línea de código que escriba hoy será historia en unos pocos años. No, no es usted el culpable: es lo rápido que se mueve el mundo, especialmente el mundo de TI, su código será reemplazado por un “mejor”, “dockerizado”, “sin servidor”, “microservicio”.
2. Blockchain no es una píldora mágica. Y tampoco lo es NodeJS y NoSql.
3. Al mismo tiempo, JS no es un lenguaje de basura como mucha gente cree que es. Y tampoco es Java como muchos reclutadores creen que es. Bueno, si estás buscando un script que esté escrito como Java, es maravilloso para ti, no JavaScript.
4. La ansiedad de la entrevista es algo real. La codificación es un arte. Al igual que los estilos contrastantes de Matisse y Picasso, todos tenemos nuestros propios estilos. Y todos tenemos nuestras propias zonas de confort e incluso momentos en que se escribe el mejor código. Invocar todas estas habilidades juntas para una entrevista de 2 horas es una habilidad en sí misma; no tiene nada que ver con lo bueno que eres con la programación.
5. La gente a menudo subestima el poder del desarrollo incremental. Esa gran aplicación minorista / utilitaria que hace sus cosas cotidianas no era más que una caja y dos botones hace solo un par de años.
6. El desarrollo de software es / puede ser aburrido. En un punto anterior, hice una comparación con el arte. El desarrollo de productos a gran escala no es un boceto de tamaño A3, sino un fresco a gran escala que necesita múltiples desarrolladores para converger y desarrollar conjuntamente. Esto significa que pasas mucho tiempo haciendo revisiones de código, arreglando git push, cuidando dependencias, pruebas de rendimiento, etc. No todo eso es arte.
7. Better Ux es un logro efímero. Los clientes siempre se acostumbran a su nuevo y mejor Ux y una vez que se acostumbran a un Ux, siempre se aburrirán. La fecha de Ux es mala Ux.
8. El desarrollo de software se está democratizando. Con el enfoque en los “desarrolladores e integradores ciudadanos” que aumentan cada día y que la IA se vuelve mucho más confiable de lo que nunca fue, los usuarios avanzados y las PYME pueden hacer bricolaje su software. A largo plazo, esto significa que la programación mediocre (no los programadores), cosas como el código de pegamento entre API, azúcar y marcos de referencia, habilitadores de usuario final como “Ux mejor”, no es más importante.

Yo paro.

Mis dos opciones impopulares, pero han sido probadas en mi trabajo.

1) El mejor primer lenguaje de programación para aprender es AWK.

1. AWK requiere el menor conocimiento de frente. No me gustan los otros lenguajes de programación, para comenzar con awk, no necesita saber cómo abrir un archivo, cómo leer el contenido del archivo, cómo dividir la línea en columnas, cómo analizar los datos en tipo correcto y por qué es necesario cerrar el archivo al final, etc. AWK le permitirá concentrarse en resolver su problema.
2. AWK tiene una sintaxis tipo C. Una vez que esté familiarizado con AWK, es fácil aprender el otro lenguaje de uso general (como Java, C #, Python, etc.).
3. AWK es útil. AWK es al archivo de texto estructural lo que SQL es a la base de datos relacional. AWK es potente para el procesamiento de datos, y el procesamiento de datos es la tarea de programación más común.

2) La razón por la que las personas piensan que es difícil aprender el lenguaje de programación funcional es que los libros de algoritmos que aprenden se describen mediante lenguaje estructural.

Debido a que usamos Clojure como lenguaje principal en el trabajo, descubrí que es difícil para muchas personas describir el algoritmo en estilo funcional. Por ejemplo, la ordenación rápida generalmente descrita en estilo estructural, que depende de los efectos secundarios, como intercambiar el valor de dos variables. Sin embargo, la programación funcional pura prefiere los efectos secundarios, tal vez podamos intentar describir el algoritmo de ordenación rápida de esta manera:

definir ordenación rápida (valores)
si la longitud de los valores es inferior a 2, entonces
valores de retorno
más
let pivot = el primer elemento de valores
devolver la concatenación de las listas a continuación
1. filtre los elementos en valores que sean menores que y ordénelos
2. filtrar los elementos en valores iguales a 3. filtre los elementos en valores que sean mejores que y ordénelos

Entonces, es fácil traducirlos a Clojure o cualquier otro lenguaje funcional:

(defn clasificación rápida [valores]
(si (<(valores de conteo) 2)
valores
(let [pivot (primeros valores)]
(concat (valores de clasificación rápida (filtro (parcial> pivote)))
(valores de filtro (parcial = pivote))
(clasificación rápida (valores de filtro (parcial

Por lo tanto, creo que si hay más libros de algoritmos en descripciones sin efectos secundarios, será muy útil para aprender lenguaje de programación funcional.

Gran pregunta!

1. La escritura dinámica apesta. Aunque no he probado todos los idiomas escritos dinámicamente (¿quién lo ha hecho?), Todavía puedo decir con seguridad que los idiomas escritos dinámicamente rara vez son una buena opción para algo más grande que un proyecto pequeño o un script decente. Estoy diciendo que esto ha usado algunos de los lenguajes más comunes como Python, Tcl y Groovy. Muchos defensores de estos lenguajes dicen que eliminar los tipos estáticos ayuda a la legibilidad y mejora la productividad. En mi experiencia, a medida que el proyecto se hace más grande, la legibilidad de tales lenguajes comienza a disminuir y me encuentro haciendo un seguimiento de los tipos en mi cabeza con más frecuencia para comprender lo que está sucediendo. Esto es algo que otros idiomas y sus compiladores me dan gratis.
2. Las plantillas de C ++ son increíbles. Por lo general, esto me pone muy nervioso, ya que a la gente le gusta mostrar de inmediato las plantillas locas utilizadas por Boost o los errores de plantilla emitidos por los compiladores. Si bien estos son temas razonables para quejarse, las plantillas de C ++ pueden disminuir en gran medida la cantidad de código que necesita escribir a un costo de tiempo de ejecución cero . Muchas de las plantillas más útiles no son muy difíciles de escribir, comprender y usar. Considere este ejemplo:

plantilla
// operator ++ () debe estar definido para el tipo Iter
// operador + = (T otro) debe definirse para el tipo T
vacío acumulado (Iter comienza, Iter final, T e init)
{
while (begin! = end) {
init + = * begin ++;
}
}

// caso de uso
// otra plantilla 🙂
std :: vector v {1, 2, 3, 4};

int suma = 0;
acumular (v.begin (), v.end (), sum);

std :: cout << sum << "\ n"; // salidas 10

No es muy difícil de entender pero increíblemente versátil. Ahora intente escribirlo en Java 🙂 Muy pocos programadores son metaprogramadores de plantillas y necesitan conocer todos los rincones de las plantillas para escribir plantillas de 1000 líneas. Las plantillas son a menudo muy fáciles de usar y pueden proporcionar una extrema flexibilidad en los algoritmos. Los genéricos de Java ni siquiera se acercan a ser tan potentes como las plantillas de C ++.

1. La mejor manera de aprender programación es de abajo hacia arriba. Muchos científicos informáticos y compañeros de trabajo me han dicho que la mejor manera de aprender a programar es aprenderlo de arriba hacia abajo. En lugar de implementar la búsqueda binaria, use el algoritmo de búsqueda binaria en la biblioteca. En lugar de lidiar con la memoria usted mismo, simplemente use std :: vector. Sin embargo, en mi experiencia, los mejores programadores que he conocido siempre lo han aprendido de abajo hacia arriba. Comenzaron con lenguajes como C / C ++ y aprendieron sobre modelos de memoria, referencias, punteros, tamaños de tipos de datos, administración de memoria, vida útil de objetos y más. Luego, pasar a los idiomas de nivel superior fue muy fácil. Los programadores que han dejado de aprender estos detalles en un momento posterior generalmente han luchado más y terminan por rendirse y adoptar un enfoque “más simple”. Además, creo que aprender de la ingeniería de software de modelos ascendentes en su conjunto: dedica más tiempo por adelantado para ahorrar mucho tiempo y esfuerzo más adelante.

Creo que la programación ágil absorbe la alegría del desarrollo de software . Ahí lo dije. Solo tenía que sacar eso de mi pecho.

Los scrums diarios, el estado interminable y la cinta de correr de integración continua me hacen sentir microadministrado y que, a su vez, tengo que microadministrar a mi equipo. ¿Cada maldita línea de código necesita ser “cultivada en el jardín”? ¿Qué tal si nos da un poco de espacio para respirar aquí? ¡Oh no, fui al baño por mucho tiempo, así que ahora mi “valor ganado” está en los basureros! Dáme un respiro. Y me gustan las pruebas unitarias, pero es mejor que mi cobertura de código sea superior al 96% o lo llevaremos a la leñera. ¡Y ni siquiera me hagas hablar de la estupidez de la complejidad ciclomática! ¡Quién fue el genio que equiparó cada caso en una declaración de cambio como un ciclo! ARRRRRRGGGHHHHH !!!

Ok, ok … Me siento mejor ahora. Tengo que reponerme antes de mi scrum, luego el scrum de scrums (no es broma) y luego verificar la Versión Uno, Gerrit, Jenkins, Jacoco y … antes de que pueda hacer un trabajo real … y … uh oh, ¡¡¡Siento que la rabia estalla de nuevo !!!!!!!!!!!!

ORMs are almost never useful

Most programmers try to shy away from SQL and an ORM (be it Hibernate or others) seem to be their escape ticket.

But in the end, after seeing many, many projects evolve over time, ORMs tend to more harm than good:

• prevents developers from learning SQL – at least until the performance issues arise
• trash performance – N+1 Selects, unnecessary joins, excessive eager loading, unnecessary lazy loading, lack of batch operations (unless you get stringly-typed on some ORMs) etc.
• block access to specific APIs – Full Text Search for example

The only times I’ve seen them useful is for Hello-World type samples. Things that have a simple DB model, performance really does not count and no border-line APIs are needed.

Coming super late to the party, and there are a lot of language/paradigm/practice related points that I had that have already been mentioned several times. For the sake of freshness, I’m taking a slight twist on this and focusing on our education system.

We need to stop wasting time offering so many CS degrees that are becoming outdated and less effective for 95% of developers in today’s industry. We should offer at most 10% of the current CS programs and make them very competitive…only really offered by private schools like Carnegie and Stanford and MIT and etc. and offered at most public schools for the sake of opportunity of accessibility but make the programs very small. These are the kids that will go on to work for the Googles and the Amazons and the HFT firms of the world. The other 90% study a far more practical ‘software engineering’ track that places emphasis on actually building stuff and learning industry practices and how to write maintainable code, something an overwhelming majority of college grads never learn.

We still have more than enough people to fill the very few roles (comparatively) that actually require you to know about self balancing trees, advanced graph theory, dynamic programming solutions (lol) and etc and still have a very talented (but admittedly shallower) pool to pull them from. Advanced data structures and algorithms with languages like C are still offered as electives for the ‘practical’ track, but are definitely not mandatory.

The positives are a FAR more competent and useful pool of junior-midlevel developers in industry. The fact is, a traditional CS degree makes everything think that you will have to be spending all your time rewriting decades old algorithms and building beautiful software for companies with linked lists, but this is overwhelmingly not the case. Something like 80% of software developers with CS degrees end up in Web out of college…the majority of the remaining 20% end up in application/mobile/general backend processes territory. So how does it make sense that in most public University CS programs today, it is entirely possible to receive your degree never having worked with a language outside of C/C++ and never even touched, let alone worked with, something in web or a modern IDE and/or framework??? Remember that 80% I mentioned in web? I’d wager less than half of college grads have hands on experience with databases outside of internships. It’s optional at many of the CS programs I know of FFS. This practical track helps TREMENDOUSLY with internships/coops as well…an intern who knows how to whip up a well organized REST API, query a database on the fly, and actually write code that doesn’t looks like it came straight out of a hackathon or in the last 2 hours before the deadline of an assignment is INFINITELY more useful than someone who isn’t sure how to say SQL out loud, not because there is a correct/incorrect way but because he/she has never even heard it out loud.

I know the default counterargument…it’s IMPORTANT for our future developers to know these CS fundamentals, even if many won’t use a lot of them. The amount of developers I know that could solve complex graph problems but still manage to fuck up a basic hashmap problem is way too high…probably because most CS programs spend more time on shit like linked lists and BSTs than covering data structures that not half, not 90%, but ALL developers use! (if you are a developer and have never had to use any sort of map, please PM me). I’m not saying we turn 90% of current CS degrees into bootcamps overnight…there is a TON of room to weed out a lot of extra stuff that is often never used and replace it with better material.

My final argument is purely subjective, but I feel like a revised and modernized curriculum would greatly encourage students to participate more and get immersed in their studies. I mean, what sounds more interesting to the average 19 year old? A lecture-slide based course where the coolest coding assignment you get is to is reinvent existing compression technology with Huffman Trees in a language like C, or a cool app that actually has a use in today’s world that you can showcase on a Github/portfolio?

Rule #1: Developers aren’t that smart: Lots of people answering this question think OOP is overrated. Y’know what? OOP is great. But it’s not easy to do right, and most developers aren’t capable of doing it right. So it gets a bad name.

Lots of people answering this question think Language X, methodology Y, or tool Z suck, but virtually none of them can build or even specify a better language, method, or tool. Is D a better C++, when they have 99% in common? De Verdad? And how to explain the contradictory answers in response to this question. Can both opposing opinions be right?

Premature optimization is only not evil if it doesn’t cost anything. If you spend weeks optimizing something that didn’t need it, that’s unambiguously dumb. But my thesis here is that many developers wouldn’t know a waste of time if it kept them working 60 hour weeks.

Rule #2: Most Startups fail: When I say most, I mean like 95% are abject failures, yielding no product and consuming millions of dollars. Four per cent produce products that make some amount of money, but don’t result in anything more than wages for the early team. And yes, one per cent make you rich. This is enough for venture capitalists, but for developers, going with a startup is a worse bet than putting a years’ paychecks on a single roulette number. That developers can still be convinced to sign on to low pay and high equity in a startup is ample evidence for rule number 1 above.

Have you ever met a serial entrepreneur? Why aren’t they still managing the billion-dollar empire they created? Usually they have a single success that has funded subsequent failures. Some have never succeeded in anything but fast-talking VCs out of startup money, and developers out of quitting. Know how to make a small fortune in Silicon Valley? Start out with a big fortune.

Rule #3: Business plans are harder to write than software: The reason for rule #2 is that imagination is in such short supply when creating business plans. Most startup plans fall into just a few categories

• The Internet of X, the Uber of Y, or the Facebook of Z, etc., where X, Y, and Z are randomly chosen market segments. Yeah, every now and then, you may find a winning combo at random (the Facebook of job seekers is called LinkedIn, for instance). But you have to be really fast to apply a known business model first, and there may be good reasons why no one else is in that space.
• Sell the same thing that (Microsoft, Amazon, Google, etc) sells, competing against a giant on his home turf, because we’re so smart and they’re such idiots. The weakness in this plan is thinking that giants are necessarily idiots, or that they only compete on the quality of their product offerings, and won’t try to squash you like a bug because it’s easier than competing.
• Take a low-margin business and make it better because now it’s online. Like shipping heavy boxes of cat litter UPS instead of selling it in stores, because the internet loves cats.
• Insert our company between buyers and sellers and take a taste of every transaction. If we reduce friction, we can take all of that as profit, rather than share it with customers. OK, this one works pretty well. I just hate the idea of it. Getting harder to find places to do this. There is generally a very powerful giant in this position in most industries.
• I know how to build an anti-spin reticulator (whatever that is), so lets get rich selling anti-spin reticulators. After all, there must be a tremendous unmet need for anti-spin reticulators, because I know how to build one. This plan generally fails for not checking out the size of the total worldwide market for reticulators of all kinds.