Independientemente del tema, conozco personalmente a algunos desarrolladores muy talentosos que pueden crear un gran software con facilidad. Son estas personas talentosas las que hacen que los legos estén llenos de grandes expectativas para nuestra industria. Pero el hecho triste que quiero decir es: no todo el mundo es un desarrollador ninja / maestro / estrella.
No soy estas nuevas estrellas brillantes, solo soy un desarrollador mediocre. Si no eres un jugador genio, este artículo te guiará sobre cómo sobrevivir en esta industria.
Lo más simple: solo google
No recuerdo muchas cosas. Las funciones y los métodos de la biblioteca estándar, las ubicaciones de los parámetros, los nombres de los paquetes, los códigos repetitivos, etc. están fuera de mi mente.
Entonces, tengo que usar la búsqueda de Google. Hago esto todos los días. También he estado reutilizando código de proyectos antiguos. A veces, incluso copio y pego respuestas de StackOverflow o Github. Sí, mi desarrollo en realidad se puede llamar: desarrollo impulsado por StackOverflow.
Pero no estoy solo. Muchos otros desarrolladores hacen lo mismo. Hay una amplia discusión en Twitter iniciada por los creadores de Ruby on Rails.
Entonces, ¿por qué pensaste que este comportamiento era malo en primer lugar? Porque tiene varias desventajas:
- Hará que copie malas decisiones de diseño o código que sea vulnerable a otros
- Formará una mentalidad de dependencia: si no podemos buscar el contenido en Google, solo podemos pedir ayuda
- No puedo trabajar sin internet
Sin embargo, no creo que estos sean grandes problemas. Incluso puede ser tu arma secreta. Tengo algunas sugerencias para reducir sus efectos negativos.
Guía de supervivencia:
Use el IDE para obtener autocompletado y sugerencias, de modo que no tenga que buscar en Google los conceptos básicos del lenguaje de programación;
recuerde dónde resolvió este problema (no cómo). De esta manera, puede encontrar una solución allí en cualquier momento;
todo el código pegado en el proyecto debe analizarse, refactorizarse y revisarse más tarde. De esta forma, brindamos soluciones rápidamente sin dañar el proyecto.
Mantenga todo simple y claro
La máquina hace lo que decimos. Incluso si está mal, no lo dudan. Por tanto, el principal problema en el desarrollo de software no es la máquina, sino las habilidades mentales de los desarrolladores. El margen de mejora de esta cosa es muy limitado. Por lo tanto, nosotros, como desarrolladores mediocres, no podemos desperdiciar nuestro limitado poder cerebral en la creación de abstracciones complejas, algoritmos difusos o bloques de código largo ilegibles. Necesita mantener todo simple y claro.
Pero, ¿cómo determinamos si el código es simple o complejo? Usamos el método WTFs / Minute para medir la calidad del código.
Este principio es fácil de entender. Siempre que encuentres algo en el código que no entiendes, oh, es demasiado complicado. Cómo hacerlo
- Reescribe para hacer el diseño más limpio
- Proporcionar documentación
- Agrega notas a la parte más complicada. Pero recuerde, el comentario debe describir el código en sí
Cómo mantenerlo simple y claro desde cero:
- Use nombres correctos para variables, funciones y clases
- Asegúrese de que cada parte del programa solo haga una cosa
- Las funciones puras son mejores que las funciones regulares
- La función regular es mejor que la clase
- Use clases solo en alta demanda
No estoy seguro
Algunos desarrolladores demostrarán que pueden proporcionar código de alta calidad. Solo mire a la dama de la imagen: Margaret Hamilton, la ingeniera de software en jefe del programa de alunizaje de Apolo. Entonces, ¿qué es casi tan alto como el de ella? Bueno, ese es el código que escribió para la misión lunar:
Sin embargo, cada vez que escribo cualquier código, no estoy seguro. Incluso la parte más simple del proyecto, puedo estropear las cosas. Las razones para equivocarse incluyen:
- Error de idioma
- error lógico
- Error de diseño
- Error de estilo
- Error de seguridad
- Error de WTF (¡mi siempre favorito!)
No existe un libro mágico sobre "aprender a escribir código sin errores". Porque todo el software tiene errores, excepto este marco. Debemos ocuparnos de los errores cuando los encontremos.
El punto clave es: todo el mundo escribe código sin errores obvios. Sí, al menos, deberíamos trabajar para lograr este objetivo. Pero, ¿cómo protejo mi proyecto de mi destrucción? Hay muchas maneras.
Guía de supervivencia:
- Escribe pruebas. Escribe muchas pruebas. Desde pruebas de integración hasta pruebas unitarias. Ejecute la prueba en CI antes de cada solicitud de extracción. Esto puede evitar algunos errores lógicos;
- Utilice escritura estática o escritura estática opcional. Por ejemplo, usamos mypy en python y fluimos en javascript. Efectos positivos: diseño más limpio y controles de "tiempo de compilación";
- Utilice la comprobación automática de estilo. Hay muchas fichas de estilo para cada idioma;
- Utilice controles de calidad. Algunas herramientas ejecutan algoritmos heurísticos complejos en su base de código para detectar diferentes problemas. Por ejemplo, hay demasiada lógica en esta línea de código, esta clase no es necesaria y esta función es demasiado complicada;
- Revise su código. Revíselos antes de fusionarlos con el maestro. Y algún tiempo después de la fusión;
- Pague para que otra persona revise su código. ¡Este método puede tener un gran impacto positivo! Porque si los desarrolladores desconocidos vienen a ver su código, es más probable que encuentren inconsistencias y malas decisiones de diseño.
No solo para mi
Hace unos diez años, cuando mi equipo desarrolló nuestro primer proyecto de software a gran escala, lo publicamos como un archivo fuente de Java. Sin embargo, no se puede compilar en el servidor de destino. Esto es solo unas horas antes de que deba enviarse al cliente. ¡Esto es un gran fracaso! Al final, agotamos todos los medios para poder ponernos en marcha, pero es innegable que esta es realmente una experiencia inolvidable.
Esto sucede debido a las numerosas configuraciones y complejidades en la canalización de compilación. Y no podemos gestionar adecuadamente la complejidad de este sistema. Entonces, a partir de ese día, para reducir esta complejidad, intenté empaquetar mi programa en un entorno aislado. Y pruébelos en este entorno antes de que ocurra la implementación real.
En los últimos años del auge de la ventana acoplable (y generalmente los contenedores), las cosas se han vuelto más simples. Docker le permite ejecutar desarrollo, pruebas y producción en el mismo entorno aislado. Por lo tanto, nunca se perderá nada importante.
Entonces, ¿qué harías? Hablando de mí, siempre me olvido de algo al crear un servidor, configuración inicial o conexión. ¡Porque hay tantas cosas para recordar! Afortunadamente, todos podemos automatizarlos. Hay muchas herramientas diferentes para automatizar el proceso de implementación, estas herramientas son muy poderosas, como terraform, ansible y packer. Lea la información de la herramienta para averiguar cuál se necesita realmente para la tarea.
También trato de construir CI / CD lo antes posible. De esta manera, si mi compilación falla durante la prueba o la implementación, se me enviará un informe.
Guía de supervivencia:
- Automatizar cualquier contenido utilizado para la implementación;
- Utilice Docker para el desarrollo, la prueba y la implementación de aplicaciones;
- Utilice herramientas de implementación.
Después de implementar la aplicación, todavía no estoy seguro
Finalmente, mi aplicación ha entrado en la etapa de producción. Puede funcionar ahora. Puedo descansar y no debería haber ningún problema. ¡Espera no! Todo se vino abajo. Sí, no me equivoco: todo.
De hecho, existen algunas herramientas que facilitan la búsqueda y resolución de problemas existentes.
- Centinela. Cuando alguno de sus usuarios cometa un error, se le notificará. Casi todos los lenguajes de programación están vinculados;
- Utilice diferentes servicios y herramientas para recopilar registros de múltiples procesos y servidores en un solo lugar;
- Monitoreo del servidor. Aquí es donde puede configurar la pantalla para CPU, disco, red y memoria. Incluso puede descubrir el tiempo que debe agregarse antes de que los usuarios realmente interrumpan su servicio.
En resumen, necesitamos monitorear las aplicaciones en producción. A veces usamos todas estas herramientas, a veces solo las partes más necesarias.
El aprendizaje permanente
Las cosas que aprender son infinitas. Si queremos escribir un buen software, tenemos que aprender constantemente cómo hacerlo. No hay atajos ni magia. Haga un pequeño progreso todos los días y mejorará cada vez más.
En resumen, debemos comprender dos cosas básicas:
- Todo el mundo tiene problemas. La clave es que tenemos que estar preparados para estos problemas;
- Podemos controlar la fuente del problema a un nivel aceptable.
Estos no tienen nada que ver con su capacidad mental o mentalidad.
Los anteriores son algunos recursos de video que recopilé, que me ayudaron mucho en este proceso. Si no desea experimentar la sensación de que no puede encontrar la información durante su autoestudio, nadie responde a sus preguntas e insiste en darse por vencido durante unos días, puede unirse a nuestro grupo de deducción [313782132], que tiene varios recursos de prueba de software y discusiones técnicas.
Recomendar buenos artículos:
Los conceptos básicos de las pruebas automatizadas, ¡todo lo que sabe y lo que no sabe está aquí!
¡Acerca de las pruebas de software! Todo lo que quieres saber está aquí, ¡Xiaobai debe verlo!
Lo que necesita saber antes de realizar pruebas automatizadas
¿Qué tipo de persona es adecuada para las pruebas de software?
Conocimiento para comprender las pruebas automatizadas de Python (3)
¿Cuál es más adecuado para pruebas automatizadas, Python o Java?
El trabajo diario de los probadores de software
Aquí recomiendo a todos un grupo de intercambio de aprendizaje de arquitectura. Número del grupo de aprendizaje de comunicación: 313782132 Se compartirán algunas grabaciones de video grabadas por arquitectos senior: Spring, MyBatis, análisis de código fuente de Netty, principios de alta concurrencia, alto rendimiento, arquitectura distribuida, microservicio, optimización del rendimiento JVM, arquitectura distribuida, etc. Estos se convierten en los sistemas de conocimiento necesarios para los arquitectos.