#35 Uno de los principios SOLID, el primero, es Single Responsability, que dice algo así como que un clase debería tener una única responsabilidad. 6000 lineas de código en una sóla clase indica que esa clase tiene un montón de responsabilidades y que más que probablemente se pueda dividir en muchas clases con responsabilidades más concretas y mejor definidas.
6000 lineas es una exageración del video, en realidad es una autentica barbaridad, más de 200 0 300 ya deberían poner el foco sobre esa clase para revisar si el diseño es adecuado. Con 6000 lineas no es que este mal diseñada, es que no esta diseñada en absoluto, más bien es código vomitado sobre el teclado.
En 6000 lineas se viola el SRP (single responsability principle) con claridad pero no sólo eso, en tantas lineas da tiempo a violar prácticamente todos los principios de la Orientación a Objetos que se te ocurran (nivel de acoplamiento brutal con seguridad, cohesión ridícula, Open close me da la risa etc,etc). Por supuesto que es siempre evitable llegar a eso.
#57 Pues huye de ahí cómo de la enfermedad
Y ojo, que en todos lados cuecen habas: Ésta es la clase View (de la cual extienden todos los botones, textos, imágenes, layouts... de Android) https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/android/view/View.java
#44 #48 #51 Una clase una sola responsabilidad? No será un método de clase una sola responsabilidad?
Según eso, para una página que tiene varias funcionalidades en vez de tener un controller con varios métodos que mapeen cada funcionalidad debería tener uno por cada una?
En el proyecto en el que yo estoy eso sería como ver un unicornio
#102 El SRP es un principio de OO referido a clases o modulos. Aunque es muy subjetivo se suele interpretar como "que las clases sólo tengan una razón para cambiar". En tu misma pregunta te estas dando la respuesta: "para una pagina que tiene VARIAS FUNCIONALIDADES....", parece claro que en tu caso ese controlador tiene varias responsabilidades, una por funcionalidad, entendido como varias razones para cambiar, tu controlador deberá cambiar si alguien decide cambiar la funcionalidad x, y o z.
Más que pensar en que motivos tienes para separar las cosas piensa en que motivos tienen esos métodos para estar juntos, desde el punto de vista de la cohesión ¿que comparten esos métodos para que tenga sentido que estén en la misma clase? (siendo los controladores normalmente clases sin estado, es decir, que no comparten nada, sería incluso cuestionable porque hay que hacer una clase con métodos en lugar de simples funciones como controladores, aunque esto puede depender del framework/tecnología que uses que es muy posible que no permita métodos como elementos de primer nivel).
De todas formas el SRP es un principio bastante subjetivo, si por ejemplo tus controladores no hicieran nada más que transformar una request http en una petición a otra u otras clases de tu sistema y transformar la respuesta de esas clases en una respuesta Http entonces se podría argumentar que el controlador sólo tiene la responsabilidad de serializar/deserializar peticiones http y delegar en otras clases de tu sistema la verdadera funcionalidad, y probablemente sería un argumento razonable para tener varios métodos en el mismo controlador.
Eso si, si tienes un controlador con tropecientos métodos y que encima implementa sin delegar en nadie las distintas funcionalidades de tu aplicación, pues entonces no hay que hilar tan fino, eso es un lio de narices claramente mal diseñado.
#110 Muchas gracias por la respuesta.
Es un proyecto Spring, JPA, etc... Los jsp se comunican con los controller (hay uno específico para las peticiones ajax por cada jsp que lo precisa) estos con los SpringServices y estos con los dao ambos con sus correspondientes interfaces e implementaciones separados.
Además están los command que suelen ser los bean de formulario y diversos validators.
En teoría los controller solo mapean y traducen como bien dices aunque alguna ñiapa que otra contienen 
Lo que si que es cierto es que haciendo debug a veces puedes perder el hilo por la de saltos que hay entre métodos públicos y privados. Mi impresión es que la complejidad es notable pero bueno en eclipse inspeccionando los valores de los objetos y con el outline para no perder la referencia te apañas.
#120 Esas arquitecturas "empresariales" javeras..., mucho se puede hablar sobre eso y poco bueno jeje. Por lo general no son precisamente un ejemplo de buenas practicas OO. No es en la parte de los controladores donde estas arquitecturas tienen el mayor problema, la capa de servicios y los mapeos 1-1 de las clases de la dominio con tablas son un problema bastante más grave, el típico modelo anémico: http://www.martinfowler.com/bliki/AnemicDomainModel.html
Y el debuger lo carga el diablo, si lo usas mucho algo huele mal, probablemente falten test, es una herramienta para emergencias, si lo usas muy habitualmente es que entonces estas demasiado habitualmente en una emergencia, cuidao con eso que es malo para el corazón :P.
#132 Es que pruebas automatizadas nada de nada.
Sonar, Hudson y esas cosas nos las cuentan en los cursos de formación contínua...luego volvemos a mundo cruel
Gracias por el enlace, lo leeré con interés
#110 amén bro
#102 No, has leído bien: Una clase => una responsabilidad.
En tu ejemplo de la página y el controller, supongo que si la página tiene mas de una funcionalidad, deberías subdividirla en componentes con interfaces bien definidas entre sí, de esta manera puedes testear (y reutilizar) cada componente/controller por separado.
Luego creas un controller adicional que se encarga de coordinar los diferentes componentes (a través de sus controllers).
Parece un rollo, pero es que así se crea una solución mas limpia y fácil de entender y mantener.
#102 Una clase. https://en.wikipedia.org/wiki/Single_responsibility_principle
Ejemplo. CompanyContoller: funcionalidad -> gestionar las llamadas http a la entidad company.
Puede tener distintos métodos Insert, Update, Select, etc... pero la funcionalidad de insert deberá realizarse dentro de un componente diferente. Si mezclas lógica en el controller que no sea para empaquetar objetos de entrada / salida está haciendo más cosas.
Por supuesto luego se puede ser más flexible o un nazi de la ordoxia.
#125 Gracias. Bueno ese ejemplo más o menos lo cumplimos...pero un cumplimiento estricto desde luego que no.
#169 los podcast de jh jeje, anda que no a llovido desde eso.
No todo el mundo es igual ni esta en la misma situación eso esta claro, lo único que digo es que esta profesión si te gusta lo que haces puede ser muy satisfactoria y ni todo es un camino de rosas ni todo es estar explotado en una consultora. Si me pongo en la situación de alguien que este pensandose en meterse en esta profesión y lea estas cosas, sinceramente se esta llevando una idea que no es realista de la profesión como conjunto. Yo a cualquiera que tenga pasión por el desarrollo le recomendaría sin dudarlo que siguiera adelante, porque además de ser un trabajo apasionante te va a permitir vivir más que dignamente y dedicarte a lo que te gusta, y no me gustaría que alguien con esa pasión se vea desanimado por visiones tan pesimistas y que sólo reflejan una parte, la peor, de esta profesión.
#165 Pues depende de lo que busques, si eres una carnica que vendes tiempo de gente lo que te interesa es comprar ese tiempo lo más barato posible y venderlo lo más caro, es decir pagar lo menos que puedas, luego pides setecientas cosas que en realidad no hacen falta para tener "en cartera" a alguien que puedas mandar a diferentes clientes porque tiene X o Y en su curriculum, aunque luego no tenga ni idea.
Si eres una empresa que hace software, entonces lo que buscas a alguien que sepa hacer software como dios manda. En ese caso más te vale buscar gente capacitada y pagaras lo que tengas que pagar por la persona que necesitas porque sin esas personas no hay software y sin software no hay negocio.
¿Cuantas empresas hay de un tipo y de otro?, pues no lo se, no manejo estadísticas (como ese 90% que te has sacado de la manga) pero lo que si te puedo decir por que lo veo a diario es que a las empresas que están en el segundo grupo les cuesta mucho esfuerzo encontrar gente. Vamos que hay muchas formas de ganarse bien la vida con esta profesión, que es lo único que estoy diciendo.
#166 Cuantas empresas "hacen software"? las consultorias venden horas, no hacen software. Intentan hacer la cuadratura del cirulo con gente desmotivada, mal pagada pero que les saque las castañas del fuego.
Pues ya me gustaria que me dieses referencias de esas que estan en el segundo grupo. Yo lo que veo es que el que puede se va a "cliente" es decir, trabajar para una empresa con contrato en el departamento informatico de esta, no en una charcutera.
#161 No se si me contestas a mi o te has equivocado, pero no se donde he dicho que "cualquiera" pueda entrar a programar o que eso sea buena cosa. Precisamente muchas empresas, no carnicas, les cuesta realmente mucho trabajo encontrar gente verdaderamente capacitada.
#164 Cuantas empresas buscan a gente capacitada y cuantas buscan a el mas barato? Porque pedir piden hasta saber lanzar sondas a marte y 5 años de experiencia en sofware que salio hace 3 al mercado, luego se quejan de que no encuentran candidatos por el sueldo y condiciones que estan dispuestos a dar. El 90% son asi.
#165 Pues depende de lo que busques, si eres una carnica que vendes tiempo de gente lo que te interesa es comprar ese tiempo lo más barato posible y venderlo lo más caro, es decir pagar lo menos que puedas, luego pides setecientas cosas que en realidad no hacen falta para tener "en cartera" a alguien que puedas mandar a diferentes clientes porque tiene X o Y en su curriculum, aunque luego no tenga ni idea.
Si eres una empresa que hace software, entonces lo que buscas a alguien que sepa hacer software como dios manda. En ese caso más te vale buscar gente capacitada y pagaras lo que tengas que pagar por la persona que necesitas porque sin esas personas no hay software y sin software no hay negocio.
¿Cuantas empresas hay de un tipo y de otro?, pues no lo se, no manejo estadísticas (como ese 90% que te has sacado de la manga) pero lo que si te puedo decir por que lo veo a diario es que a las empresas que están en el segundo grupo les cuesta mucho esfuerzo encontrar gente. Vamos que hay muchas formas de ganarse bien la vida con esta profesión, que es lo único que estoy diciendo.
#166 Cuantas empresas "hacen software"? las consultorias venden horas, no hacen software. Intentan hacer la cuadratura del cirulo con gente desmotivada, mal pagada pero que les saque las castañas del fuego.
Pues ya me gustaria que me dieses referencias de esas que estan en el segundo grupo. Yo lo que veo es que el que puede se va a "cliente" es decir, trabajar para una empresa con contrato en el departamento informatico de esta, no en una charcutera.
#155 Se como funcionan las carnicas, que son lo peor de la profesión lo sabemos todos, y que hay alternativas también, no se puede hablar de la "profesión" y decir que todo es una mierda hablando de sólo de un caso particular de empresas.
"¿A quién le va interesar trabajar en un sector que cada vez se paga peor y no tiene un convenio que le protege?"
Cuando leo estas cosas no si es que yo vivo en una realidad paralela, ¿a quién le va a interesar trabajar en un sector que tiene un paro del 0% en un país con un 20% de paro?, ¿a quién le va a interesar trabajar en un sector donde se rifan a los buenos profesionales?, ¿a quién le va a interesar trabajar en un sector donde tus conocimientos son valorados en todo el mundo?, ¿a quién le va a interesar trabajar en un sector donde hay docenas de proyectos apasionantes?, ¿a quién le va a interesar trabajar en un sector en el que puedes hacer gran parte del trabajo desde la comodidad de tu casa?, ¿a quién le va a interesar trabajar en un sector en el que aprendes cosas nuevas día tras día?, y podría seguir un rato largo.
Llevo más de 15 años en este sector, me encanta esta profesión, disfruto con ella, y además me ha permitido ganarme la vida más que dignamente durante todos estos años, ¿y se supone que el problema por lo que esta profesión no le debería interesar a nadie es que no tenemos no se que convenio?, ahhh es verdad, que desgracia de profesión!...
Esta es una profesión cojonuda para el que le apasione, y para el que no, como cualquier otra profesión, un calvario de 8 horas diarias, y ningún convenio va a cambiar eso criaturas.
#152 Pues si, debemos tener realidades paralelas. Mi experiencia profesional ha sido siempre en pymes y la verdad es que ha sido un camino de rosas, pero he terminado en una carnica. Es verdad que tiene poco paro nuestra profesión, pero tambien es verdad que te mandan al paro muy facilmente un viernes a las 14:50 y sin tiempo para despedirte. Si, te engañan para entrar en estas carnicas con un sueldo pactado, pero cuando entras las posibilidades de ascenso o promoción son nulas, solo los pelotillas o los que le caen bien ascienden. Yo he estado en muchos proyectos apasionantes, pero no siempre es asi. Es mas, propones ideas y son tiradas a la basura, aunque fuera de este mundillo son realizables y funcionan. ¿Teletrabajo? Permitame que me ria, no existe practicamente, tenia que ser lo normal, pero prefieren tenerte en la oficina horas aunque estes desasignado. Aprendes cosas si te forman, si no tienes el buscador y arreglatelas como puedas. Es mas ese aprendizaje continuo no es valorado ni pagado.
A mi me encanta, pero te aconsejo que pises una carnica y bajes a la realidad. Lugares donde la estupidez se premia, donde las apariencia es lo que cuenta y donde la gestión del proyecto es mas importante que el proyecto, con 1.000 reuniones estupidas para justificar el sueldo de unos pocos.
Y diras... ¿por que no te vas? Estoy en ello.
#155 La has clavado. #152 No se da cuenta de que dejando que "cualquiera" entre a programar porque "hay trabajo" provoca que el sector este lleno de gente que no respeta en mi opinion esta profesion. No soy purista pero que un tio no sepa ni donde se mira la IP en su PC, donde lo que cuenta es lo que dice #155, la "gestion", el pasarse el dia moviendo hojas excel y planificando, haciendo grupitos de gente que luego en la practica todo termina "a salto de mata" y donde los responsables montan largas reuniones para justificar su trabajo y mandar un email al cliente diciendo "bueno, vosotros os aclarais que yo no os sigo, entonces lo haceis vosotros no?"
En fin... Es normal que un responsable no sea informatico y no sepa que es una base de datos? Yo creo que no.
#164 Cuantas empresas buscan a gente capacitada y cuantas buscan a el mas barato? Porque pedir piden hasta saber lanzar sondas a marte y 5 años de experiencia en sofware que salio hace 3 al mercado, luego se quejan de que no encuentran candidatos por el sueldo y condiciones que estan dispuestos a dar. El 90% son asi.
#165 Pues depende de lo que busques, si eres una carnica que vendes tiempo de gente lo que te interesa es comprar ese tiempo lo más barato posible y venderlo lo más caro, es decir pagar lo menos que puedas, luego pides setecientas cosas que en realidad no hacen falta para tener "en cartera" a alguien que puedas mandar a diferentes clientes porque tiene X o Y en su curriculum, aunque luego no tenga ni idea.
Si eres una empresa que hace software, entonces lo que buscas a alguien que sepa hacer software como dios manda. En ese caso más te vale buscar gente capacitada y pagaras lo que tengas que pagar por la persona que necesitas porque sin esas personas no hay software y sin software no hay negocio.
¿Cuantas empresas hay de un tipo y de otro?, pues no lo se, no manejo estadísticas (como ese 90% que te has sacado de la manga) pero lo que si te puedo decir por que lo veo a diario es que a las empresas que están en el segundo grupo les cuesta mucho esfuerzo encontrar gente. Vamos que hay muchas formas de ganarse bien la vida con esta profesión, que es lo único que estoy diciendo.
#166 Cuantas empresas "hacen software"? las consultorias venden horas, no hacen software. Intentan hacer la cuadratura del cirulo con gente desmotivada, mal pagada pero que les saque las castañas del fuego.
Pues ya me gustaria que me dieses referencias de esas que estan en el segundo grupo. Yo lo que veo es que el que puede se va a "cliente" es decir, trabajar para una empresa con contrato en el departamento informatico de esta, no en una charcutera.
#152 Tu caso Alfredo es un poco especial. Tu tienes un nivel muy alto (recuerdo bastantes podcasts de javahispano donde salias) donde digamos que están el 5% de profesionales tic. luego hay un 20-30% que son buenos luego ..etc
Dentro de la profesión hay niveles, no es lo mismo crear una arquitectura para una aplicación con cierta complejidad, que hacer pantallas copy-pasteando las que están creadas.
La mayoría de gente por muchos motivos no puede negociar con su talento, y todo y ser buenos profesionales, necesitan un soporte vía convenio o vía lo que sea para que el trabajo le ofrezca estabilidad, buen sueldo..etc. Si no se ponen límites esto es una jungla en que el único perjudicado es el trabajador.
También es cierto que p.ej en la provincia de Tarragona es prácticamente imposible que un alguien programando tenga un sueldo ni que se acerque siquiera al de un operador de planta químico (con un buen convenio..). Si a mi hijo le gustase programar y también le gustase trabajar con un torno haciendo piezas.. le recomendaría que hiciese un módulo de metal y no se complicará la vida..Para lo complicado que es realmente programar esta mal pagado.
Yo recomendaría sin duda estudiar programación si realmente te gusta (como es mi caso), efectivamente se puede llegar a trabajar desde casa como freelance, hay poco paro..etc. Aunque he reconocer que muchos ex compañeros de trabajo salieron por patas de España y es una pena que no se haga nada para remediarlo..
#169 los podcast de jh jeje, anda que no a llovido desde eso.
No todo el mundo es igual ni esta en la misma situación eso esta claro, lo único que digo es que esta profesión si te gusta lo que haces puede ser muy satisfactoria y ni todo es un camino de rosas ni todo es estar explotado en una consultora. Si me pongo en la situación de alguien que este pensandose en meterse en esta profesión y lea estas cosas, sinceramente se esta llevando una idea que no es realista de la profesión como conjunto. Yo a cualquiera que tenga pasión por el desarrollo le recomendaría sin dudarlo que siguiera adelante, porque además de ser un trabajo apasionante te va a permitir vivir más que dignamente y dedicarte a lo que te gusta, y no me gustaría que alguien con esa pasión se vea desanimado por visiones tan pesimistas y que sólo reflejan una parte, la peor, de esta profesión.
null pointer exception
Aparte de ser bastante mitico por las magnificas y abundantes contestaciones dadas en Stack Overflow, también su libro sobre C# es de lo mejorcito: http://www.amazon.com/C-Depth-3rd-Jon-Skeet/dp/161729134X/ref=asap_bc?ie=UTF8, muy recomendable para quien quiera no sólo aprender sino profundizar a base de bien en C#.
Lo que desde luego no tiene ningún sentido es reescribir algo que ya esta escrito. Si el problema es que el gestor de paquetes no da las garantías necesarias (básicamente garantizar la accesibilidad y la inmutabilidad de versiones publicadas) la solución no puede pasar por reescribir o hacer copy&paste del código. Hoy copio esta función, mañana aquella otra, pasado otra más y al final termino con una montaña de código a mantener en mi proyecto por que no quiero añadir dependencias, gran idea si señor.
No vendría mal de paso entender porque en la comunidad js existe la tendencia a hacer librerías pequeñas, cuando incluyes una dependencia en js el código de esa librería lo tienes que distribuir junto con tu aplicación, esto en una app cliente js implica que el tamaño de tu aplicación aumenta, así que si hacemos una librería gigantesca con montones de funciones y luego la incluimos solo para usar un par de cosas nos llevamos la librería entera y aumentamos considerablemente el peso de nuestra aplicación. Por eso es tan habitual ver esas micro-librerías en js que pueden resultar chocantes para gente que venga de otros entornos donde realmente añadir un poco más de peso a la aplicación no es tan relevante (sobre todo el entornos servidor).
Vamos, que antes de decir que le problema es que la gente no sabe programar y yo si que soy muy listo, como hace el autor del blog, no vendría mal entender un poco mejor las motivaciones que tuvieron otros programadores para hacer las cosas así.
Esta graciosete, teniendo en cuenta que mi curro consiste entre otras cosas en ir a empresas a ayudarles con desastres de este tipo, se siente uno identificado, me falta la camisa, tengo que buscarme una