Un poco de bicicletas

Una vez nos instalamos con un compañero de clase en 2014 para iniciar una startup. El término, el resultado y el enfoque del producto no son importantes para este texto. Lo importante es que el cliente era una aplicación Java móvil para Android y el servidor era un servicio escrito en C # que hablaba con el almacén de datos. Además, una historia de advertencia para ancianos canosos (de la programación) para divertirse, para jóvenes sin barba, para edificar.



Para asegurarme de que yo, como desarrollador del lado del servidor, tengo todo bajo control, la primera versión del servidor se escribió utilizando la clase System.Net.Sockets.Socket, como describe el artículo de Microsoft. Dado que los sockets funcionan (en principio, como todas las demás tecnologías enumeradas más allá de Microsoft, excepto WCF) en los métodos Begin / End, se escribió un pequeño contenedor que brindaba la capacidad de trabajar con el modelo basado en eventos. Este fue el primer paso, el cliente y el servidor funcionaron bien.



Dado que muy pronto necesitábamos SSL, tuvimos que pasar a un nivel superior del modelo OSI y reescribir el lado del servidor usando la clase System.Net.Sockets.TcpListener, a la que SSL estaba atornillado. Estos fueron los pasos dos y dos y medio, el cliente y el servidor funcionaron bien, el cliente ni siquiera tuvo que ser reescrito - la intercepción de paquetes mostró que todo estaba bien, nada había cambiado.



Más tarde, quería un HTTPS completo con todas sus campanas y silbidos, para lo cual el servidor se reescribió nuevamente, ahora usando la clase System.Net.HttpListener. Estos son los pasos tres y tres y medio, y nuevamente todo funciona bien, y nuevamente el cliente no necesita ser rehecho. En aras de la justicia, debe tenerse en cuenta que, además del cliente móvil personalizado, también había un cliente C # de prueba y un montón de pruebas, pero tenían que reescribirse para nada.



El cuarto paso llegó cuando comenzamos a escalar nuestro sistema en todas las direcciones, y nuestras propias envolturas se convirtieron en el cuello de botella del proyecto. Luego leí sobre WCF y en una noche (bueno, casi) reescribí toda la interacción. En el lado del cliente (y en los paquetes que se reenvían), todo sigue igual, pero el código del lado del servidor se ha reducido de media docena de clases serias a solo unas pocas líneas.



Esta historia tiene dos moralejas.

1. (obviamente) Inventar bicicletas es malo. Si acudiera inmediatamente a Google y no tuviera miedo de usar una nueva tecnología para mí, podría reducir el desarrollo de servidores en aproximadamente un tercio.
2. (y esto es lo principal) La tarea de implementar el mismo mecanismo utilizando diferentes herramientas es la mejor forma de aprender, permitiéndote lograr una comprensión profunda del tema. Cuando haces algo unas cuantas veces, lo recuerdas. Pero cuando al mismo tiempo complica (cambia) las herramientas utilizadas cada vez, entonces la habilidad se afila mucho mejor.