principales - Estoy manteniendo una clase de Java que tiene 40K líneas de largo... ¿problema?
no se encontraron clases principales netbeans (12)
50K líneas de código? Pensé que KLOC era una métrica del tamaño del proyecto, no del tamaño del archivo. Eso es como todo nuestro código base (incluidas las pruebas).
Estoy trabajando con JavaScript, por lo que no es directamente comparable, pero solo tenemos pocos archivos de más de 500 líneas, y estos son los altamente problemáticos.
Esta puede ser una pregunta subjetiva que lleve a la eliminación, pero me gustaría recibir algunos comentarios.
Recientemente, me mudé a otro proyecto empresarial muy grande en el que trabajo como desarrollador. Me quedé horrorizado al encontrar que la mayoría de las clases en el proyecto tienen una longitud de 8K a 50K con métodos que son de 1K a 8K líneas. Es principalmente lógica de negocios que trata con tablas de bases de datos y administración de datos, llena de sentencias condicionales para manejar los casos de uso.
¿Las clases son tan comunes en los grandes sistemas empresariales? Me doy cuenta de que sin mirar el código es difícil tomar una decisión, pero ¿alguna vez has trabajado en un sistema con clases tan grandes?
Además de los problemas de mantenimiento del software descritos en otras respuestas, tenga cuidado con el límite técnico de que un método Java compilado no puede exceder los 64k bytes . (La cantidad de líneas de código que corresponda dependerá de las líneas mismas).
Aquí están las diez clases más grandes en el JDK 6 por línea de 7209 archivos .java. Estas clases incluyen una cantidad significativa de comentarios que podrían ser más largos que el código.
4495 ./javax/sql/rowset/BaseRowSet.java
4649 ./java/awt/Container.java
5025 ./javax/swing/text/JTextComponent.java
5246 ./java/util/regex/Pattern.java
5316 ./javax/swing/JTree.java
5469 ./java/lang/Character.java
5473 ./javax/swing/JComponent.java
9063 ./com/sun/corba/se/impl/logging/ORBUtilSystemException.java
9595 ./javax/swing/JTable.java
9982 ./java/awt/Component.java
Estoy de acuerdo en que una página impresa es lo suficientemente larga para un método. Realmente no debería haber una necesidad de clases de más de 10K líneas de IMHO.
Como programador joven todavía recuerdo que mi maestro nos dijo que dividiéramos las funciones importantes y trabajáramos en un buen diseño de OO antes de escribir el código.
Entonces, a menos que haya una buena razón en su diseño para imponer 40k líneas (lo cual dudo mucho), entonces ya tiene su respuesta: su clase es demasiado grande.
Citaré a mi esposa (que es química y no programa): "¡40k líneas de código, hay algo realmente mal!"
He tenido amigos que emprenden proyectos en sus compañías que eran muy antiguas, que fueron lanzadas de un programador a otro y lo que todos acordamos es que una clase de ese tamaño simplemente significa:
-parche y arregle: las personas tenían que hacer pequeños cambios aquí y allá y no querían / no tenían tiempo para hacerlo correctamente.
en el tiempo de ejecución puede que no haya ningún problema con ese código, todo funciona, pero generalmente ocurren problemas cuando se desea realizar cualquier tipo de modificación:
lleva años encontrar algo
cuando hay un error no se puede identificar fácilmente
...
En conclusión, me gustaría replantearme el diseño de oo de su proyecto y reestructurarlo (al menos en clases de 1k ~ 5k líneas para comenzar), sé que es molesto hacer bu generalmente a largo plazo es mejor
Creo que su horror está calificado :) No puedo imaginar que el programa esté correctamente OOPified. Las clases son un poco más difíciles de clasificar, pero los métodos son fáciles: 1 comportamiento por método (eso no es una regla, pero debería serlo). Los comportamientos no pueden ser ni siquiera cerca de 1k líneas de código. Al menos, en cuanto a mi imaginación me llevará.
Las clases, por otro lado, pueden representar muchas cosas pero deberían representar algo . Si es difícil saber qué representa la clase, entonces tiene un problema.
Ahora, casi me imagino que estás al tanto de estos conceptos y estoy predicando al coro. Entonces, fingiré que no salí de una tangente y responderé tu pregunta directamente:
Sí. Lamentablemente, es muy común que los proyectos de grandes empresas tengan un código tan vago. He trabajado en proyectos casi tan grandes (el tuyo filma todo lo que he visto fuera del agua) y mi primera tendencia es comenzar a dividir las cosas en componentes lógicos, especialmente en lugares donde pretendo hacer cambios. No puedo manejar ese tipo de espagueti, es demasiado irritante.
En 12 años de desarrollo de Java, puedo decir honestamente que esto es inusual.
De hecho; Nunca he encontrado archivos o clases de ese tamaño en ningún idioma en más de 25 años de desarrollo.
¡Rompe las herramientas de refactorización!
Esto definitivamente no está bien. Un método no debe contener más código que suficiente para una sola unidad de trabajo. Una clase no debe contener más métodos que los relacionados con el estado de la instancia de la clase.
Esto es demasiado como el antipatrón de Dios Objeto . Yo personalmente dejaría el proyecto y buscaría otro.
Oh, creo que es una señal terrible, y no tengo que mirar el código para decirlo. Parece que se necesita un esfuerzo masivo de refactorización.
Déjeme adivinar, usted tampoco tiene pruebas de unidad para el sistema como están escritas. Tienes mi simpatía.
Sé que alguna sección del código debe dividirse cuando tengo problemas para intentar averiguar qué hace y cómo. O si es más grande que una captura de pantalla.
Normalmente lo refactorizo si me hace sentir mal. No me gusta sentirme mal :-(
Sospecho que el código se salió de control porque la administración solo quería correcciones de errores / funciones y nada más, y poco a poco empeoró.
Refactorizar el código para facilitar el trabajo de los programadores probablemente no fue muy alto en su lista de prioridades. La gerencia siempre quiere sus correcciones de errores / características ayer :-(
También es obvio que un programa de trabajo es mejor que uno que se rompió, y dividir un código tan grande sin pruebas unitarias terminaría en desastre. Así que todas las pruebas tendrían que hacerse antes de tocar el código. Otra razón por la que la gerencia no lo permitiría.
Sin mirar el código, en realidad sigue siendo bastante fácil hacer una determinación. Nunca una clase debe ser de 40K líneas, y nunca un método debe ser incluso 1K. Por lo general, si no puedo imprimir un método en una hoja de papel y veo los corchetes inicial y final, encuentro una manera de dividirlo.
Debo preguntar, ¿están usando los principios de la POO o están tratando de usar Java más como un lenguaje funcional o de procedimiento? No puedo imaginar un verdadero proyecto de OOP con una clase de línea de 40K.
Una campana de alarma comenzó a sonar cuando leí esto:
Es principalmente lógica de negocios que trata con tablas de bases de datos y administración de datos, llena de sentencias condicionales para manejar los casos de uso.
Si este código no está en la capa de datos y no hay abstracción con respecto a cómo se accede a la base de datos, algo está mal. También tengo la sensación de que algunos de estos métodos no están directamente relacionados con las clases en las que se encuentran. El comentario sobre las declaraciones condicionales y los casos de uso tampoco suena bien. Me haré eco del comentario de Duffymo de que se necesitaría algo de refactorización.
Una pequeña cosa a la que hay que prestar atención es la diferencia entre lines , lines of code y statements . Si analiza su proyecto con, por ejemplo, Sonar, puede ver fácilmente la diferencia entre ellos.
Sin embargo, cualquiera que sea la medida exacta, 40k líneas de código de negocio es horrible .
En el módulo de negocios de una aplicación empresarial que desarrollo, el número más alto es 444 líneas de código. Esto es para un servicio bastante grande. La mayoría de las clases de servicio están entre 200 y 100 líneas de código. Las entidades (objetos modelo) están en nuestra situación principalmente entre 40 y 100 loc.
En otra parte de esta misma aplicación tenemos una clase que es 1224 líneas de código (2477 líneas en total, 706 declaraciones). Esta clase es odiada casi universalmente dentro del equipo debido a su tamaño. Se percibe como hinchado, complicado y haciendo demasiado.
Ahora, si un equipo entero piensa en una clase que solo tiene un total de 2477 líneas, esto puede darle una perspectiva sobre qué tipo de abominación es una clase de 40k líneas.