Si alguien le ofrece una declaración no verificada con respecto a las prácticas de desarrollo de software, ¿responde con "cita requerida"? [cerrado]

El problema con este tipo de afirmaciones es que incluso si tuviera evidencia empírica que respalde la afirmación, sería muy difícil determinar si el estudio que condujo a la evidencia aplicada a su situación actual.

Casi todo en la profesión tiene una advertencia, o varias, por lo que cada mejora en un lugar tiene la posibilidad de ser perjudicial en otro lugar.

La gente que está en las trincheras conoce la diferencia a través de la experiencia y, en general, no tiene la financiación / tiempo / recursos para tratar de demostrarla a través de un estudio científico.

La gente que intenta probarlo a través de un estudio científico obviamente tiene recursos para dedicarse a dichos estudios y, por lo tanto, es muy probable que le vendan algo, así que le diría que debería aplicar su propia experiencia personal a cualquier cosa. que afirma estar respaldado por una investigación empírica.

Si alguien te dijera "Si más del 2% del código necesita refactorización, es más rápido reescribirlo" sabrías que es falso tanto como si alguien te dijera "Sólo si más del 98% del código necesita Refactorizando, es más rápido reescribirlo ". La ubicación del número real depende de lo que esté haciendo y de lo ideal que sea el código actual.

La idea de que después de un cierto punto es más fácil hacer un refactor nuclear es obviamente cierta en muchos casos, pero el porcentaje real es más un ejemplo que debe considerar a través de la lente de la experiencia propia de su (equipo) y situación actual.

Si alguien le ofrece una declaración no verificada con respecto a las prácticas de desarrollo de software, ¿responde con "cita requerida"?

No, lo publico aquí y veo si recibe algún voto positivo. ¡La prueba social es mejor que ninguna prueba!

Muchos desarrolladores basan sus decisiones de momento a momento en la experiencia en las trincheras que trabajan con el código y los clientes a los que sirve ese código.

Cuando una clase o método se ha fragmentado tanto por las correcciones de errores y las solicitudes de cambio de los clientes que no se puede mantener, un desarrollador a veces toma la decisión de reescribirlo en lugar de refactorizarlo, bajo la teoría de que ahorrará tiempo y esfuerzo. A largo plazo, porque el código resultante será de mayor calidad.

Este tipo de experiencia en inteligencia es lo que los departamentos de recursos humanos llaman "capital humano". Es una de las cosas que hace que los desarrolladores experimentados sean valiosos, y una de las razones por las que las buenas empresas hacen cosas para intentar preservar la longevidad de su gente.

No parece justo ni práctico pedir a los desarrolladores experimentados que presenten un estudio y datos empíricos como prueba de que sus técnicas son válidas. La experiencia no funciona de esa manera. Por el contrario, la experiencia es algo así como una "sensación sentida". En el mundo de la refactorización, a menudo lo llamamos "olor".

En última instancia, una declaración como "Si más del 25% del código necesita refactorización, es más rápido de reescribirlo" no se puede probar que funcione en todas las circunstancias, por lo que la declaración [cita requerida] es realmente una manera de informar al programador dogmático que busca forzar su opinión sobre los demás de que no siempre es "a su manera o la autopista".

Creo que con algo que nunca sabes hasta que lo intentas. Incluso con la prueba para respaldar una declaración, siempre es posible doblar los hechos en beneficio de su punto. Dicho esto, no deberías probar cada cosa nueva que llegue a las interwebs. Haz tu mejor juicio Recuerde, si algo es demasiado bueno para ser verdad, probablemente lo sea. Siempre pregúntate, ¿por qué necesitas adoptar algo? ¿Qué tienes para ganar? ¿Tiene sentido desde una perspectiva de negocio? Nunca cegado excepto algo sobre la fe.

El ejemplo de la conferencia es una heurística, una regla de oro y nada más. Eso debería ser implícitamente obvio.

Las heurísticas son como cualquier otra cosa: están sujetas a un cierto contexto y dependen de cualquier número de supuestos no declarados, y su utilidad puede ser muy no determinista. Tanto el juicio arbitrario para encontrarlos como para formularlos en primer lugar.

¿Eso significa que están sin valor? No lo diría en absoluto.

Los heurísticos son uno de los enfoques que podemos tomar para abordar los problemas de NP-completa, y en muchos aspectos, la ingeniería de software es en sí misma un problema de NP-completa.

Depende. :) Cuando la declaración de alguien contradice la experiencia repetida, reflexionada y verificada personalmente, entonces sí, me gustaría ver algún tipo de referencia de un estudio. Por otro lado, si alguien se hace eco de una idea que has visto y vivido muchas veces, no hay mucha reacción provocada (no significa que la idea sea infalible).

Como ejemplo, el libro "Código Completo" cita decenas de estudios en cada capítulo para señalar sus puntos, a veces sobre asuntos aparentemente pequeños (como sangría y espaciado, o longitud del nombre variable). Recuerdo a algunos desarrolladores (más jóvenes) a quienes presenté el libro para pensar que ese nivel de detalle y evidencia era tonto. Pero unos meses más tarde, con más experiencia en codificación de producción y después de algunas revisiones de código, algunos de los mismos desarrolladores tuvieron la honestidad de admitir que sí, incluso la cantidad de espacios en la sangría sí importa. Los buenos comentarios importan. La encapsulación importa. etc. etc.

En el otro extremo, cuando un proveedor afirma que un nuevo IDE es 50% más productivo, mi primera reacción es el toro $% ^ & amp ;!

¿No es eso algo que depende de muchas variables intangibles (variables que no tienen forma de ser medidas científicamente)?

En mi opinión, están hablando de un método empírico para medir las emociones. Algo que ni siquiera Spock podría lograr. =)