Estoy haciendo esta pregunta a los programadores de C ++ porque: a) Solo un programador de C ++ puede juzgar los méritos técnicos de los ejemplos; b) Solo un programador tendrá una idea del temperamento de otro programador que escriba código como este.
Recursos Humanos y los directores son conscientes de que hay un problema simplemente porque ven evidencia en el campo. Es mi decisión si le damos más tiempo al programador en cuestión. Muchos de los errores están en un nivel muy básico: mi pregunta (para los programadores) es si alguien que profesa ser un desarrollador senior de C ++ debería beneficiarse de una duda basada en muestras de su código actual. Los que no son programadores, incluso las personas que están fuera de la programación en C ++, no pueden juzgar esto.
Por antecedentes, me asignaron la tarea de administrar desarrolladores para una empresa bien establecida. Tienen un único desarrollador que se especializa en toda su codificación C ++ (desde siempre), pero la calidad del trabajo es abismal. Las revisiones y pruebas de código han revelado muchos problemas, uno de los cuales es la pérdida de memoria. El desarrollador nunca ha probado su código en busca de fugas, y descubrí que las aplicaciones podrían perder muchos MB con solo un minuto de uso. Los usuarios informaron grandes desaceleraciones, y su opinión fue: "no tiene nada que ver conmigo; si dejan de fumar y se reinician, todo vuelve a estar bien".
Le di herramientas para detectar y rastrear las fugas, y me senté con él durante muchas horas para demostrar cómo se usan las herramientas, dónde ocurren los problemas y qué hacer para solucionarlos. Estamos 6 meses en el camino y le asigné a escribir un nuevo módulo. Lo revisé antes de que se integrara en nuestra base de código más grande, y me consternó descubrir la misma codificación incorrecta que antes. La parte que encuentro incomprensible es que parte de la codificación es peor que la de un aficionado. Por ejemplo, quería una clase (Foo) que pudiera poblar un objeto de otra clase (Bar). Decidió que Foo haría una referencia a Bar, por ejemplo:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};Pero (por otras razones) también necesitaba un constructor predeterminado para Foo y, en lugar de cuestionar su diseño inicial, escribió esta gema:
Foo::Foo() : m_bar(*(new Bar)) {}Entonces, cada vez que se llama al constructor predeterminado, se filtra una barra. Para empeorar las cosas, Foo asigna memoria del montón para otros 2 objetos, pero no escribió un destructor o un constructor de copias. Por lo tanto, cada asignación de Foo realmente filtra 3 objetos diferentes, y puede imaginar lo que sucedió cuando se copió un Foo. Y - solo mejora - repitió el mismo patrón en otras tres clases, por lo que no es un error único. Todo el concepto está mal en muchos niveles.
Me sentiría más comprensivo si viniera de un novato total. Pero este tipo ha estado haciendo esto durante muchos años y ha recibido capacitación y consejos muy centrados en los últimos meses. Me doy cuenta de que ha estado trabajando sin tutoría o revisiones por pares la mayor parte del tiempo, pero empiezo a sentir que no puede cambiar. Entonces mi pregunta es, ¿persistirías con alguien que está escribiendo un código tan obviamente malo?