¿Qué "mejores prácticas" populares no siempre son las mejores y por qué? [cerrado]

Las "mejores prácticas" están en todas partes en nuestra industria. Una búsqueda en Google sobre "mejores prácticas de codificación" arroja casi 1,5 millones de resultados. La idea parece traer consuelo a muchos; solo sigue las instrucciones y todo saldrá bien.

Cuando leo sobre una práctica recomendada , por ejemplo, acabo de leer varias de Clean Code recientemente, me pongo nervioso. ¿Significa esto que siempre debería usar esta práctica? ¿Hay condiciones adjuntas? ¿Hay situaciones en las que podría no ser una buena práctica? ¿Cómo puedo estar seguro hasta que haya aprendido más sobre el problema?

Varias de las prácticas mencionadas en Clean Code no me sentaron bien, pero honestamente no estoy seguro de si eso es porque son potencialmente malas, o si eso es solo mi prejuicio personal al hablar. Sé que muchas personas prominentes en la industria de la tecnología parecen pensar que no hay mejores prácticas , por lo que al menos mis dudas persistentes me colocan en buena compañía.

La cantidad de mejores prácticas sobre las que he leído son simplemente demasiado numerosas para enumerarlas aquí o hacer preguntas individuales, por lo que me gustaría expresar esto como una pregunta general:

¿Qué prácticas de codificación que se etiquetan popularmente como "mejores prácticas" pueden ser subóptimas o incluso dañinas en ciertas circunstancias? ¿Cuáles son esas circunstancias y por qué hacen que la práctica sea pobre?

Preferiría escuchar sobre ejemplos y experiencias específicos.

Creo que has dado en el clavo con esta declaración

Odiaría tomar las cosas al pie de la letra y no pensar en ellas críticamente

Ignoro casi todas las mejores prácticas cuando no viene con una explicación de por qué existe

Raymond Chen lo pone mejor en este artículo cuando dice

Los buenos consejos tienen una justificación para que pueda saber cuándo se convierten en malos consejos. Si no comprende por qué se debe hacer algo, entonces ha caído en la trampa de la programación de culto de carga, y seguirá haciéndolo incluso cuando ya no sea necesario o incluso se vuelva perjudicial.

También podría tirar esto al ring:

Premature optimization is the root of all evil.

No, no es.

La cita completa:

"Deberíamos olvidarnos de las pequeñas eficiencias, digamos alrededor del 97% del tiempo: la optimización prematura es la raíz de todo mal. Sin embargo, no debemos dejar pasar nuestras oportunidades en ese crítico 3%".

Eso significa que aprovecha las mejoras de rendimiento específicas y estratégicas a lo largo de su proceso de diseño. Significa que usa estructuras de datos y algoritmos que son consistentes con los objetivos de rendimiento. Significa que conoce las consideraciones de diseño que afectan el rendimiento. Pero también significa que no optimiza frívolamente al hacerlo, le dará ganancias menores a expensas de la mantenibilidad.

Las aplicaciones deben estar bien diseñadas, para que no se caigan al final cuando aplicas una pequeña carga sobre ellas, y luego terminas reescribiéndolas. El peligro con la cita abreviada es que, con demasiada frecuencia, los desarrolladores lo usan como una excusa para no pensar en el rendimiento hasta el final, cuando podría ser demasiado tarde para hacer algo al respecto. Es mejor desarrollar un buen rendimiento desde el principio, siempre que no se centre en las minucias.

Supongamos que está creando una aplicación en tiempo real en un sistema integrado. Eliges Python como lenguaje de programación, porque "la optimización prematura es la raíz de todo mal". Ahora no tengo nada en contra de Python, pero es un lenguaje interpretado. Si el poder de procesamiento es limitado, y se necesita realizar una cierta cantidad de trabajo en tiempo real o casi en tiempo real, y elige un idioma que requiere más poder de procesamiento para el trabajo que el que tiene, está realmente jodido, porque ahora tiene que comenzar de nuevo con un lenguaje capaz.

Un retorno por función / método.

No reinventar la rueda es un dogma muy mal utilizado. Su idea es que si existe una solución adecuada, úsela en lugar de crear la suya; Además de ahorrar esfuerzo, es probable que la solución existente esté mejor implementada (libre de errores, eficiente, probada) de lo que se le ocurriría inicialmente. Hasta aquí todo bien.

El problema es que rara vez existe una solución 100% adecuada. Puede existir una solución adecuada al 80%, y su uso probablemente esté bien. Pero, ¿qué tal un 60% adecuado? 40%? ¿Dónde se traza la línea? Si no dibuja la línea, podría terminar incorporando una biblioteca hinchada a su proyecto porque está utilizando el 10% de sus características, solo porque desea evitar "reinventar la rueda".

Si reinventa la rueda, obtendrá exactamente lo que desea. También aprenderás a hacer ruedas. Aprender haciendo no debe subestimarse. Y al final, una rueda personalizada puede ser mejor que una rueda genérica lista para usar.

"Prueba de unidad todo".

He oído decir a menudo que todo el código debe tener pruebas unitarias, un punto con el que no estoy de acuerdo. Cuando tiene una prueba para un método, cualquier cambio en la salida o estructura de ese método debe realizarse dos veces (una vez en el código, una vez en la prueba).

Como tal, las pruebas unitarias deberían ser, en mi opinión, proporcionales a la estabilidad estructural del código. Si estoy escribiendo un sistema en capas de abajo hacia arriba, mi capa de acceso a datos tendrá pruebas del wazoo; mi capa de lógica de negocios estará bastante bien probada, mi capa de presentación tendrá algunas pruebas y mis puntos de vista tendrán poca o ninguna prueba.

Siempre programe para interfaces.

A veces solo habrá una implementación. Si demoramos el proceso de extracción de una interfaz hasta el momento en que vemos la necesidad, a menudo descubriremos que no es necesario.

No use nada de código abierto (o que no sea de Microsoft para sus desarrolladores de .NET)

Si Microsoft no lo desarrolló, no lo usamos aquí. Desea utilizar ORM - EF, desea utilizar IOC - Unity, desea iniciar sesión - bloque de aplicaciones de registro empresarial. Existen muchas mejores bibliotecas, pero siempre estoy atrapado ordenando desde el menú en dólares del mundo del desarrollo. Juro que cada vez que escucho las mejores prácticas de Microsoft pienso "Pautas nutricionales de McDonald's". Claro, probablemente vivirás si los sigues, pero también estarás desnutrido y con sobrepeso.

• Tenga en cuenta que esta podría no ser su mejor práctica, pero es una práctica común en casi todos los lugares donde he trabajado.

Orientación a objetos

Existe la suposición, solo porque el código está "orientado a objetos", es mágicamente bueno. Por lo tanto, la gente sigue exprimiendo la funcionalidad en clases y métodos, solo para estar orientados a objetos.

Todo el código debe ser comentado.

No, no debería serlo. En algún momento tiene un código obvio, por ejemplo, los establecedores no deben comentarse, hasta que hagan algo especial. Además, ¿por qué debería comentar esto?

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

Metodologías, particularmente scrum. No puedo mantener una cara seria cuando escucho a los adultos usar la frase "Scrum Master". Me canso tanto de escuchar a los desarrolladores protestar que algún aspecto de la Metodología X no está funcionando para su empresa, solo que Guru So-and-So me dijo que la razón por la que no funciona es que, de hecho, no son verdaderos profesionales de Metodología X. "Scrum más duro, debes, mi alumno Padawan!"

Hay pepitas de sabiduría en las metodologías ágiles, muchas de ellas, pero a menudo están mezcladas con tanto estiércol que no puedo combatir mi reflejo nauseoso. Toma este bit de la página de scrum de Wikipedia :

Una serie de roles se definen en Scrum. Todos los roles se dividen en dos grupos distintos: cerdos y pollos, según la naturaleza de su participación en el proceso de desarrollo.

De Verdad? ¿Cerdos y gallinas, dices? ¡Fascinante! No puedo esperar para lanzar este a mi jefe ...

Mapeo relacional de objetos ... http://en.wikipedia.org/wiki/Object-relational_mapping

No quiero que nunca me abstraigan de mis datos, ni quiero perder ese control y optimización precisos. Mi experiencia con estos sistemas ha sido extremadamente pobre ... Las consultas generadas por estas capas de abstracción son incluso peores que las que he visto en off-shoring.

Escribir nombres de funciones como si fueran oraciones en inglés:

Draw_Foo()
Write_Foo()
Create_Foo()

etc. Esto puede verse bien, pero es un dolor cuando estás aprendiendo una API. ¿Cuánto más fácil es buscar un índice para "Todo lo que comienza con Foo"?

Foo_Draw()
Foo_Write()
Foo_Create()

etc.

MVC: a menudo encuentro que el problema de la creación de muchos problemas de diseño web en el enfoque MVC se trata más de hacer feliz un marco (rieles, etc.) que de la simplicidad o la estructura. MVC es un favorito de los "astronautas de la arquitectura" que parecen valorar el andamiaje excesivo sobre la simplicidad. ymmv.

OO basado en clases: en mi opinión, fomenta estructuras complejas de estado mutable. Los únicos casos convincentes que he encontrado para la OO basada en clases a lo largo de los años son los ejemplos curiosos de "forma-> rectángulo-> cuadrado" que forman el capítulo 1 de cualquier libro de OO

YAGNI

( No lo vas a necesitar )

Este enfoque me ha costado horas y horas cuando tuve que implementar características en una base de código existente, donde una planificación cuidadosa habría incluido estas características de antemano.

Las ideas mías a menudo han sido rechazadas por YAGNI, y la mayoría de las veces alguien tuvo que pagar por esa decisión más tarde.

(Por supuesto, uno podría argumentar que una base de código bien diseñada también permitiría agregar características más adelante, pero la realidad es diferente)

Para SQL

1. No uses disparadores
2. Ocultar siempre las tablas detrás de las vistas

En orden:

1. Son una característica que tiene su lugar. ¿Tiene varias rutas de actualización a una tabla o requiere una auditoría del 100%?

2. ¿Solo porque? Lo haría si estuviera refactorizando para mantener un contrato, pero no cuando he leído que la gente cambia la vista para que coincida con los cambios de la tabla

Editar:

Número 3: Evitar * con EXISTS. Prueba 1/0. Funciona. La lista de columnas no se evalúa según el estándar SQL. Página 191

Patrones de diseño en su mayoría. Están sobreutilizados y subutilizados.

El principio de responsabilidad única

^{("cada clase debe tener una sola responsabilidad; en otras palabras, cada clase debe tener una, y solo una, razón para cambiar")}

Estoy en desacuerdo. Creo que un método debería tener una sola razón para cambiar, y todos los métodos en una clase deberían tener una relación lógica entre sí , pero la clase en sí misma podría hacer varias cosas (relacionadas).

En mi experiencia, este principio con demasiada frecuencia se aplica con demasiado entusiasmo, y terminas con muchas clases pequeñas de un método. Ambas tiendas ágiles en las que he trabajado han hecho esto.

¡Imagínese si los creadores de la API .Net hubieran tenido este tipo de mentalidad: en lugar de List.Sort (), List.Reverse (), List.Find () etc., tendríamos las clases ListSorter, ListReverser y ListSearcher!

En lugar de seguir discutiendo en contra del SRP (que en sí mismo no es terrible en teoría) , compartiré algunas de mis experiencias anecdóticas:

En un lugar donde trabajé, escribí un solucionador de flujo máximo muy simple que constaba de cinco clases: un nodo, un gráfico, un creador de gráficos, un solucionador de gráficos y una clase para usar el creador de gráficos / solucionadores para resolver un problema del mundo real Ninguno fue particularmente complejo o largo (el solucionador fue, con mucho, el más largo con ~ 150 líneas). Sin embargo, se decidió que las clases tenían demasiadas "responsabilidades", por lo que mis compañeros de trabajo comenzaron a refactorizar el código. Cuando terminaron, mis 5 clases se habían ampliado a 25 clases, cuyas líneas de código totales eran más del triple de lo que eran originalmente. El flujo del código ya no era obvio, ni el propósito de las nuevas pruebas unitarias; Ahora me resultaba difícil descubrir qué hacía mi propio código.

En el mismo lugar, casi todas las clases tenían un solo método (su única "responsabilidad"). Seguir el flujo dentro del programa era casi imposible, y la mayoría de las pruebas unitarias consistían en probar que esta clase llamaba código de otra clase , cuyo propósito era igualmente un misterio para mí. Había literalmente cientos de clases donde debería haber (IMO) solo docenas. Cada clase hizo solo una "cosa" , pero incluso con convenciones de nomenclatura como "AdminUserCreationAttemptorFactory" , fue difícil distinguir la relación entre las clases.

En otro lugar (que también tenía la mentalidad de clases-debería-tener-solo-un-método ), estábamos tratando de optimizar un método que ocupaba el 95% del tiempo durante una determinada operación. Después (optimistamente) de optimizarlo un poco, volví mi atención hacia por qué se llamaba un millón de veces. Se llamaba en un bucle en una clase ... cuyo método se llamaba en un bucle en otra clase ... que también se llamaba en un bucle ...

En total, hubo cinco niveles de bucles repartidos en 13 clases (en serio). Lo que estaba haciendo cualquier clase en realidad era imposible de determinar con solo mirarlo: había que dibujar un gráfico mental de qué métodos llamaba, y qué métodos llamaban esos métodos, y así sucesivamente. Si todo se hubiera agrupado en un solo método, solo habría tenido unas 70 líneas con nuestro método problemático anidado dentro de cinco niveles de bucles inmediatamente obvios.

Mi solicitud para refactorizar esas 13 clases en una sola clase fue denegada.

Ahora que mencionó Clean Code, aunque contiene algunas buenas ideas, creo que su obsesión por refactorizar todos los métodos en submétodos y aquellos en submétodos, etc., se lleva demasiado lejos. En lugar de un par de métodos de diez líneas, se supone que prefiere veinte (supuestamente bien nombrados) frases ingeniosas. Obviamente, alguien piensa que está limpio, pero para mí parece mucho peor que la versión original.

Además, reemplazando cosas elementales simples como

0 == memberArray.length

dentro de una clase con una llamada al método propio de la clase, como

isEmpty()

es una cuestionable "mejora" en mi humilde opinión. Adición: La diferencia es que la primera verificación hace exactamente lo que dice: comprueba si la longitud de la matriz es 0. Ok, también isEmpty()puede verificar la longitud de la matriz. Pero también podría implementarse así:

return null != memberArray ? 0 == memberArray.length : true;

Es decir, ¡incluye una verificación nula implícita! Este puede ser un buen comportamiento para un método público: si la matriz es nula, entonces algo está vacío, pero cuando hablamos de elementos internos de clase, esto no es tan bueno. Si bien la encapsulación hacia el exterior es imprescindible, los componentes internos de la clase deben saber exactamente lo que está sucediendo dentro de la clase. No puede encapsular la clase de sí misma . Explícito es mejor que implícito.

Esto no quiere decir que romper métodos largos o comparaciones lógicas involucradas no sea bueno; por supuesto que lo es, pero hasta qué punto hacerlo , donde está el punto dulce, es obviamente una cuestión de gustos. Romper un método largo da como resultado más métodos, y eso no es gratis. Tienes que saltar el código fuente para ver lo que realmente está sucediendo, cuando puedes verlo de un vistazo si todas esas cosas estuvieran en un solo método.

Incluso iría tan lejos como para decir que en algunos casos un método de 1 línea es demasiado corto para merecer ser un método.

"Sé liberal con los comentarios"

Los comentarios son definitivamente algo bueno, pero demasiados son igual de malos, si no peores que insuficientes. ¿Por qué? Bueno, las personas tienden a ignorar los comentarios si ven demasiados innecesarios. No digo que pueda tener un código perfectamente autodocumentado, pero es preferible un código que necesite comentarios para su explicación.

GoTo Considerado Nocivo

Si está implementando una máquina de estado, una declaración GOTO puede tener más sentido (legibilidad y código eficiente) que un enfoque de "programación estructurada". Realmente preocupaba a algunos compañeros de trabajo cuando el primer código que escribí en un nuevo trabajo incluía no solo una, sino varias declaraciones. Afortunadamente, fueron lo suficientemente inteligentes como para darse cuenta de que en realidad era la mejor solución en este caso particular.

Cualquier "mejor práctica" que no permita excepciones sensatas y documentadas a sus reglas es simplemente aterradora.

Los sacrificios que hacemos para que el código sea comprobable

Salto muchos aros para hacer que mi código sea comprobable, pero no pretendo que no lo haría si tuviera la opción. Sin embargo, a menudo escucho a personas presionando la idea de que estas son "mejores prácticas". Estas prácticas incluyen (escrito en el idioma de .Net, pero también se aplica a otros idiomas) :

• Creando una interfaz para cada clase. Esto duplica el número de clases (archivos) a tratar y duplica el código. Sí, la programación de la interfaz es buena, pero para eso están destinados los especificadores públicos / privados.
• Cada clase no instanciada al inicio necesita una fábrica. Claramente, new MyClass()es mucho más simple que escribir una fábrica, pero ahora el método que lo crea no se puede probar de forma aislada. Si no fuera por este hecho, solo haría 1/20 del número de clases de fábrica que hago ahora.
• Haga que cada clase sea pública, lo que anula el propósito de tener especificadores de acceso en las clases. Sin embargo, no se puede acceder a las clases no públicas (y, por lo tanto, probarlas) desde otros proyectos, por lo que la única otra opción es mover todo el código de prueba al mismo proyecto (y así liberarlo con el producto final).
• Inyección de dependencia. Claramente, al tener que dar a cualquier otra clase, uso un campo y un parámetro constructor es mucho más trabajo que simplemente crearlos cuando los necesito; pero ya no puedo probar esta clase de forma aislada.
• El principio de responsabilidad única, que me ha causado tantos dolores de cabeza, lo he trasladado a su propia respuesta .

Entonces, ¿qué podríamos hacer para solucionar esto? Necesitaríamos un cambio drástico en la arquitectura del lenguaje:

• Necesitaríamos la capacidad de burlarnos de las clases
• Necesitaríamos la capacidad de probar métodos privados de clases internas, desde otro proyecto (esto puede parecer una vulnerabilidad de seguridad, pero no veo un problema si el examinado se ve obligado a nombrar sus clases de probadores) .
• La inyección de dependencia (o la ubicación del servicio), así como algo equivalente a nuestro patrón de fábrica existente, debería ser una parte central del lenguaje.

En resumen, necesitamos un lenguaje diseñado desde cero con la capacidad de prueba en mente .

Separar aplicaciones en niveles; Capa de datos, capa empresarial, capa de interfaz de usuario

La razón principal por la que no me gusta esto es que la mayoría de los lugares que siguen este método, usan marcos muy frágiles para hacerlo. IE UI Layer está codificada a mano para tratar con objetos de capa empresarial, los objetos de capa empresarial están codificados a mano para tratar con reglas de negocios y bases de datos, la base de datos es SQL y ya es bastante frágil y está administrada por el grupo "DBA" que no le gusta el cambio.

¿Por qué es esto malo? Es probable que la solicitud de mejora más común sea "Necesito un campo en la pantalla X que tenga Y". ¡Explosión! Solo tiene una nueva característica que afecta a cada capa individual, y si separa las capas con diferentes programadores, se convierte en un gran problema que involucra a múltiples personas y grupos, para un cambio muy simple.

Además, no sé cuántas veces he estado en argumentos que van más o menos así. "El campo de nombre está limitado a una longitud máxima de 30, ¿se trata de un problema de capa de interfaz de usuario, de negocio o de datos?" Y hay cien argumentos, y no hay una respuesta correcta. La respuesta es la misma, afecta a todas las capas, no desea hacer la interfaz de usuario tonta y tener que pasar por todas las capas, y fallar en la base de datos, solo para que el usuario descubra que su entrada es demasiado larga. Si lo cambia, afecta a todas las capas, etc.

Las "capas" también tienden a gotear; Si alguna capa está físicamente separada por los límites del proceso / máquina (interfaz de usuario web de IE y lógica de backend empresarial), las reglas se duplican para que todo funcione razonablemente bien. Es decir, parte de la lógica empresarial termina en la interfaz de usuario, a pesar de que es una "regla de negocios", porque el usuario necesita que la interfaz de usuario sea receptiva.

Si el marco utilizado, o la arquitectura utilizada, es resistente a pequeños cambios y fugas, es decir, se basa en metadatos y se ajusta dinámicamente a través de todas las capas, puede ser menos doloroso. Pero la mayoría de los frameworks es un problema real, ya que requiere cambios en la interfaz de usuario, cambios en la capa empresarial y cambios en la base de datos, para cada pequeño cambio, y causa más trabajo y menos ayuda de la que se supone que produce la técnica.

Probablemente me critiquen por esto, pero ahí está :)

JavaBeans

El uso de JavaBeans en Java. Vea mi pregunta ¿Por qué no debería usar POJO inmutables en lugar de JavaBeans? en StackOverflow.

Historias de usuarios / Casos de uso / Personas

Entiendo la necesidad de estos cuando está programando para una industria con la que no está familiarizado, pero creo que cuando se implementan con toda su fuerza se vuelven demasiado corporativos y se convierten en una pérdida de tiempo.

80 límites de caracteres / líneas son tontos

Entiendo que se deben hacer algunos compromisos para que coincida con el ritmo del corredor más lento en el lado de la GUI (limitaciones de resolución de pantalla, etc.) pero, ¿por qué esa regla se aplica al formato de código?

Ver ... Hubo esta pequeña invención llamada barra de desplazamiento horizontal que se creó para administrar el espacio de la pantalla virtual fuera del límite de píxeles más a la derecha. ¿Por qué los desarrolladores, que han logrado crear excelentes herramientas para mejorar la productividad, como el resaltado de sintaxis y el autocompletado, lo usan?

Claro, hay editores de CLI utilizados religiosamente por los dinosaurios * nix que siguen las viejas y cansadas limitaciones de sus terminales VT220, pero ¿por qué el resto de nosotros tenemos el mismo estándar?

Yo digo, joder el límite de 80 char. Si los dinosaurios son lo suficientemente épicos como para hackear emacs / vim todo el día, ¿por qué no deberían ser capaces de crear una extensión que envuelva líneas automáticamente o brinde capacidades de desplazamiento horizontal a sus IDE CLI?

Los monitores de 1920x1080 píxeles eventualmente se convertirán en la norma y los desarrolladores en todo el mundo todavía viven bajo las mismas limitaciones sin tener en cuenta por qué lo hacen, excepto que eso es lo que les dijeron sus mayores cuando recién comenzaban a programar.

Los límites de 80 caracteres no son una práctica recomendada, sino una práctica de nicho para una minoría de programadores y deben tratarse como tales.

Editar:

Es comprensible que a muchos desarrolladores no les guste la barra de desplazamiento horizontal porque requiere un gesto del mouse, así que ... ¿Por qué no aumentar el límite de ancho de columna a un número mayor (que 80) para aquellos de nosotros que usamos pantallas modernas?

Cuando los monitores de computadora 800x600 se convirtieron en la norma para la mayoría de los usuarios, los desarrolladores web aumentaron el ancho de su sitio web para acomodar a la mayoría ... ¿Por qué los desarrolladores no pueden hacer lo mismo?

Medida, medida, medida

Muy bien, mida, pero para aislar errores de rendimiento, la medición funciona, así como la eliminación sucesiva. Aquí está el método que uso.

He estado tratando de localizar la fuente de la "sabiduría" medida-medida. Alguien con una caja de jabón lo suficientemente alta lo dijo, y ahora viaja.

Mi maestro me exige que comience todos mis identificadores (sin incluir constantes) con letras minúsculas, por ejemplo myVariable.

Sé que parece algo menor, pero muchos lenguajes de programación requieren variables para comenzar con letras mayúsculas. Valoro la coherencia, por lo que es un hábito mío comenzar todo con letras mayúsculas.

Use Singletons

Cuando solo deberías tener una instancia de algo. No puedo estar más en desacuerdo . Nunca use un singleton y solo distribúyalo una vez y pase el puntero / objeto / referencia según sea necesario. No hay absolutamente ninguna razón para no hacer esto.

Usando unsigned int como iterador

¿Cuándo aprenderán que usar el signo int es mucho más seguro y menos propenso a errores? ¿Por qué es tan importante que el índice de matriz solo pueda ser un número positivo, que todos estén contentos de pasar por alto el hecho de que 4 - 5 es 4294967295?

Los métodos no deberían ser más largos que una sola pantalla

Estoy completamente de acuerdo con el principio de responsabilidad única, pero ¿por qué las personas perciben que significa "una función / método no puede tener más que una responsabilidad única en el nivel más fino de granularidad lógica"?

La idea es simple. Una función / método debe cumplir una tarea. Si parte de esa función / método se puede usar en otro lugar, córtelo en su propia función / método. Si pudiera usarse en otro lugar del proyecto, muévalo a su propia clase o una clase de utilidad y haga que sea accesible internamente.

Tener una clase que contiene 27 métodos auxiliares que solo se llaman una vez en el código es tonto, una pérdida de espacio, un aumento innecesario de complejidad y un sumidero de tiempo masivo. Suena más como una buena regla para las personas que quieren verse ocupadas refactorizando código pero no producen mucho.

Aquí está mi regla ...

Escribir funciones / métodos para lograr algo

Si se encuentra a punto de copiar / pegar algún código, pregúntese si sería mejor crear una función / método para ese código. Si una función / método solo se llama una vez en otra función / método, ¿hay realmente un punto en tenerla en primer lugar (se llamará con más frecuencia en el futuro)? ¿Es valioso agregar más saltos dentro / fuera de funciones / métodos durante la depuración (es decir, el salto agregado hace que la depuración sea más fácil o más difícil)?

Estoy completamente de acuerdo en que las funciones / métodos de más de 200 líneas deben ser analizadas, pero algunas funciones solo realizan una tarea en tantas líneas y no contienen partes útiles que puedan resumirse / usarse en el resto del proyecto.

Lo veo desde una perspectiva de desarrollo de API ... Si un nuevo usuario mirara el diagrama de clase de su código, cuántas partes de ese diagrama tendrían sentido dentro de la mayor parte del proyecto y cuántas existirían únicamente como ayudantes a otras partes internas del proyecto.

Si tuviera que elegir entre dos programadores: el primero tiende a escribir funciones / métodos que intentan hacer demasiado; el segundo divide cada parte de cada función / método al mejor nivel de granularidad; Yo elegiría las primeras manos. El primero lograría más (es decir, escribir más contenido de la aplicación), su código sería más fácil de depurar (debido a menos saltos dentro / fuera de funciones / métodos durante la depuración), y perdería menos tiempo haciendo un trabajo ocupado perfeccionando cómo el código se ve vs perfeccionando cómo funciona el código.

Limite las abstracciones innecesarias y no contamine el autocompletado.