1. Antecedentes
En vísperas del Festival de Primavera de 2020, el equipo del proyecto planeó un applet de WeChat. El proyecto es un sorteo de lotería de sobre rojo. Los usuarios completan las tareas en el mini programa para obtener el número de sorteos de lotería, luego eligen los sobres rojos de sus estilos favoritos para la lotería y luego otorgan premios según la situación de la lotería. El proyecto en sí no tiene funciones demasiado complicadas, pero debido a que el equipo del proyecto no ha estado involucrado en el desarrollo de pequeños programas antes, el desarrollo del proyecto ha experimentado giros y vueltas debido a los cambios en los requisitos causados por las políticas. Afortunadamente, el proyecto finalmente se completó y entregó, y se encontraron muchos de ellos. El problema se resume aquí.
2. Puntos de función
La figura enumera aproximadamente los principales puntos de función incluidos en el proyecto y la lógica relacionada entre los puntos de función.
El proceso principal es: Después de que el usuario ingrese al applet de WeChat, obtenga los datos del premio en la página de configuración, siga la cuenta oficial para obtener el número de sorteos y vaya a la interfaz de sorteo para realizar el sorteo.
3. Puntos técnicos
3.1 Configurar premios
Requisito principal: proporcionar una página de configuración para configurar premios y los datos correspondientes
Este módulo funcional utiliza datos básicos para agregar, eliminar, modificar y verificar, y el diseño de la estructura de datos es más complicado.
Los datos generales se dividen en tres capas:
- Bolsa de premios: recopile todos los datos de premios
- Tema: tiene atributos independientes y recopila todos los datos del sobre rojo bajo el tema
- Sobre rojo: tiene atributos independientes y almacena todos los enlaces disponibles del sobre rojo
Debido a las limitaciones de la base de datos y el tiempo de desarrollo, no se pueden utilizar funciones como tablas relacionales o diseño de mutex. Para minimizar las anomalías de datos causadas por la simultaneidad, los datos generales se dividen en tablas para su almacenamiento en la fase de diseño de datos.
// 奖池
"Prize-Pool": {
{
// 专题列表
"themeList": [
"b29369b5-e475-4bc3-9ce1-ddfd93486301"，
"b29369b5-e475-4bc3-9ce1-ddfd93486302"
],
"otherData": {
"xxx": "xxx"
}
}
}
// 专题（Theme + 专题key）
"Theme-b29369b5-e475-4bc3-9ce1-ddfd93486301": {
// 红包列表
"packetList": [
"1611578407299",
"1611578397794"
],
"key": "b29369b5-e475-4bc3-9ce1-ddfd93486301",
"background": "xxx",
"iconUrl": "xxx",
...
}
// 红包（Packet + 红包key）
"Packet-1611578407299": {
"linkList": [
"link1",
"link2"
],
"key": 1611578407299,
"title": "212121",
"imgUrl": "xxx",
...
}
Después del sorteo de lotería, puede 专题key + 红包keyubicar un sobre rojo específico linkListpara leer y escribir un solo sobre rojo para reducir el impacto de la concurrencia.
3.2 Seguir más tiempos
Requisito principal: determinar si el usuario actual ha seguido una determinada cuenta oficial y aumentar el número de sorteos en función del estado
El proceso de juicio es más complicado y existen muchas limitaciones.
Restricción 1: confirmar la identidad del usuario
Applets y número público de micro-canales de micro-canales, cada uno correspondiente a cada usuario openId, openIdpuede identificar de forma única la identidad del usuario en la plataforma actual, pero los applets openIdy los números públicos openIdno son los mismos.
Cuando el Mini Programa y la cuenta oficial están vinculados a la misma plataforma pública, la plataforma pública generará una unionIdy la unionIdidentidad del usuario se puede confirmar de forma única en la plataforma pública.
Debido a la diferencia entre los Mini Programas WeChat y las Cuentas Oficiales, los usuarios del Mini Programa correspondiente openIdno se pueden encontrar a través de la Cuenta Oficial al seguir la Cuenta Oficial openId. Por lo tanto, es necesario pasar la unionIdinformación de usuario única asociada con el Mini Programa y la Cuenta Oficial. .
Limitación 2: Obtenga UnionId
Applet wx.getUserInfoobteniendo al usuario a unionIdtravés de la access_tokenadquisición de números públicos , access_tokendos horas cada falla, necesita actualizar regularmente.
En la adquisición por lotes unionId, algunas solicitudes no pueden obtener los datos devueltos debido a factores de red, y es necesario solicitar repetidamente obtener los datos completos.
Limitación 3: Tratar con redes ambientales
WeChat solo permite que los servidores agregados ipa la lista blanca de la ipcuenta oficial obtengan información del usuario. El servidor de la lista blanca debe ser reparado . Una vez implementado el proyecto, se implementará en varios servidores y la red externa correspondiente al servidor ipno es fija, por lo que no se puede completar en la lista blanca. En la lista.
Usando el método de proxy, la solicitud se envía a un servidor proxy, y el servidor proxy es responsable de reenviar la solicitud y exponer una red externa fija ippara la configuración en la cuenta oficial de WeChat.
Para lograr los requisitos básicos de este módulo funcional, se puede completar mediante el siguiente proceso:
- Obtenga la lista de usuarios en la interfaz de la cuenta oficial y obtenga la
openIdlista de usuarios que se han seguido - La interfaz de la cuenta oficial se obtiene en
openIdlotesunionIdy se almacena en la base de datos. - Si el subprograma
wx.getUserInfoobtiene el usuario , se buscaráunionIden la base de datos, si seunionIdencuentra significa que se ha seguido, en caso contrario no se ha seguido. - Reciba notificación de eventos después de prestar atención y
unionIdescriba en la base de datos
3.3 Lotería
Requisitos básicos: registrar el número de sorteos, llevar a cabo la lógica de los sorteos y completar la distribución de premios.
La función es relativamente simple:
- Registre la finalización de las tareas únicas y la finalización de las tareas diarias en la actividad por separado, el número de veces aumentará y el número se reducirá después de la lotería.
- Configure la probabilidad de ganar, genere un número aleatorio para determinar el tamaño
- Registre el resultado ganador y regrese al enlace del premio
3.4 Otros-Respuesta automática a la cuenta oficial
Requisito principal: respuesta automática de la cuenta pública de WeChat
La cuenta oficial tiene su propia función de respuesta automática, pero la respuesta automática no será válida después de vincular el servidor push. El servidor debe juzgar el comportamiento del usuario y responder en función de la información enviada por WeChat.
// 微信推送的是xml数据，需要进行解析
const {
ToUserName, // 开发者的openId
FromUserName, // 用户的openId
Event,
CreateTime,
MsgType } = await new Promise((resolve, reject) => {
Parser.parseString(this.req.body, (err, result) => {
if (err) reject(err)
resolve(result.xml)
})
})
// 回复，以简单的文字回复为例
xml = `
<xml>
<ToUserName><![CDATA[${
FromUserName}]]></ToUserName>
<FromUserName><![CDATA[${
ToUserName}]]></FromUserName>
<CreateTime>${
new Date().getTime()}</CreateTime>
<MsgType><![CDATA[text]]></MsgType>
<Content><![CDATA[${
content}]]></Content>
</xml>
`
return this.res.send(xml)
4. Revisión
4.1 Cambios en los requisitos del premio
El primer cambio importante: los premios del pozo de premios se almacenan en tablas separadas.
La demanda previa de premios es: solo es necesario configurar y visualizar los datos, y cada sobre rojo tiene un enlace designado, y el premio se puede emitir volviendo a este enlace.
Dado que no hay escritura de datos en este requisito, la concurrencia no afectará los datos, por lo que para acelerar el progreso, se adopta un diseño simple para almacenar todos los datos en un objeto.
Debido a los cambios en los requisitos, los datos deben leerse y escribirse al mismo tiempo, lo que resulta en un rediseño de la estructura general de datos, anulando la mayor parte de la lógica anterior 配置奖品y cambios importantes en el módulo.
4.2 Llamar la atención
El segundo gran cambio: modificar los requisitos generales de la lotería.
El requisito anterior para los sorteos de lotería era: debes prestar atención a la cuenta oficial para sacar la lotería.
Después de la finalización del desarrollo del proyecto, durante la etapa de lanzamiento del programa pequeño, la revisión falló y fue rechazada debido a la inducción de atención. El requisito de modificación es que se puede realizar una lotería gratuita. Esta versión fue aprobada en la revisión inicial, y posteriormente rechazada por la existencia de atención inducida. La lógica principal fue modificada muchas veces por inquietudes sobre la cuenta oficial, y finalmente se cambió para mostrar el grupo de intercambio y se abandonó por completo la siguiendo la lógica.
4.3 Sistema de lotería
El tercer gran cambio: abandonar la lotería y cambiar a un regalo.
La exigencia previa del evento era que los premios debían ser sorteados solo después de haber sido sorteados.
Después de que el proyecto estuvo en línea durante un período de tiempo, WeChat bloqueó oficialmente el mini programa debido a un comportamiento similar a la lotería, y luego se cambió a un regalo diario limitado, renunciando a la lógica de la lotería.
4.4 Sistema de usuario
El cuarto gran cambio: Abandonar los datos del usuario.
El requisito inicial de datos es registrar los datos y calcular la tasa de conversión de premios y la atención del usuario después del evento.
Luego de que el proyecto fue modificado hasta el final, se abandonó la atención al sistema y al sistema de lotería, y los datos anteriores ya no son significativos. Más letal es: debido a una lógica de demanda previa, los datos del usuario se unionIdalmacenan como el único valor confirmado, sin que el público preste atención al número de usuario que no existe unioinId, y finalmente se ve obligado a utilizar openIdpara identificar y migrar datos de forma única.
4.5 Otro
-
Migración del estado de inicio de sesión
Dado que el backend tiene un estado de inicio de sesión, los usuarios que no han iniciado sesión no pueden acceder al backend. En la etapa inicial del diseño del proyecto, el usuario primero obtiene el estado de inicio de sesión y luego ingresa al mini programa.
Después de una serie de cambios, el proceso de adquisición del estado de inicio de sesión se convierte en el primero en ingresar al mini programa y luego en obtener el estado de inicio de sesión. Este cambio no se alineó con todos los desarrolladores, y el estado de inicio de sesión predeterminado se usó en la etapa de desarrollo de front-end por conveniencia, de modo que el problema no se expuso en la etapa de prueba.
Después de que el proyecto se puso en línea, el estado de inicio de sesión predeterminado expiró e invalidado, lo que resultó en un acceso de usuario anormal.
-
El código no es riguroso
En el proceso de desarrollo, hay un problema con menos letras que conducen a un error, y el problema debe detectarse en el enlace de prueba. Sin embargo, debido al estado de inicio de sesión predeterminado, el problema no se expuso durante la prueba, lo que finalmente provocó un error en línea.
5. Resumen
Demanda no fija
Problema: debido a la política, los requisitos han cambiado varias veces, lo que ha provocado confusión e ineficiencia en el proceso general.
Mejora: Realice una evaluación detallada del proyecto antes del desarrollo para evitar cambios frecuentes en la lógica principal de requisitos después de que comience el desarrollo.
La comunicación no es oportuna
Problema: cuando se cambia el contenido de un módulo dependiente, la información de cambio no se sincroniza.
Mejora: Determine el proceso de interacción antes del desarrollo y notifique a todo el personal relevante cuando cambie el proceso.
Prueba incompleta
Problema: No hay función de prueba ni personal, y es imposible realizar una prueba completa.
Mejora: cree un sistema de prueba para pruebas unitarias y realice más pruebas después de que se complete la función.