Sé que hay muchos marcos de seguridad y "construir" un marco de seguridad es una mala idea.
En el proyecto reciente en el que he trabajado, usé Spring Security para asegurar la aplicación web. En el proceso, modifiqué / modifiqué algunas clases de seguridad de Spring para cumplir con mis requisitos.
Mi administración ahora quiere que "saque" las cosas que hice y las distribuya como un código reutilizable en un portal interno. Ahora, ¿es esto justo preguntar?
No es inteligente. Desafortunadamente, no sé lo suficiente sobre lo que modificó o la profundidad o la experiencia y comprensión de su gerencia. Mi conjetura es que su gestión está pensando:
'Wow, nuestro ingeniero realizó una gran mejora de seguridad en un marco establecido, que tiene que valer mucho'.
y 'Ya está escrito, solo se volverá a empaquetar un poco el paquete y las ventas'
Traté de explicarles que solo algunas clases se basan en la seguridad de Spring y nada especial. Pero están insistiendo en "crear" este marco. ¿Es este un requisito justo?
No parece sonido. Parece que hay una clara discrepancia entre su visión de lo que ha hecho y la opinión de su administración. Es probable que su administración comprenda mejor la creación de productos y negocios, y que tenga una mejor comprensión de los asuntos técnicos. Puede ser que su trabajo tenga un increíble valor de producto que su administración vea y usted no. Sin embargo, estoy más inclinado a creer que su trabajo es bueno, pero no tiene un valor significativo como producto, y su gestión está equivocada en su entusiasmo.
Déjame ponerlo de esta manera. ¿Qué tan difícil sería para un competidor tener un desarrollador de tu habilidad, y para ese desarrollador hacer un trabajo equivalente a lo que has hecho? Si la respuesta es muy difícil, siempre y cuando haya empresas que tengan un producto, ¿qué? Si la respuesta no es difícil, entonces convertir su trabajo en un producto es más sobre el volumen de ventas y los gastos generales operativos que sobre el mérito técnico.
¿Alguna idea sobre cómo empezar?
Si avanza, dedique suficiente tiempo a los requisitos y el diseño. Entienda lo que la administración espera que sea este producto y derive los objetivos de diseño de esas expectativas. Planifique la prueba, el lanzamiento, el mantenimiento, las actualizaciones y el final de la vida útil. Comuníquese continuamente con su administración. Si tiene problemas, avísele a la administración, a veces pueden ayudarlo o redirigir sus esfuerzos.
Si estoy creando esto, ¿cuáles son las funciones que debo proporcionar?
Eso dependerá de sus objetivos de diseño, que a su vez deberían depender de los requisitos o el concepto de gestión del producto.