Revisión de desafío de código: lo que prefieren la mayoría de los revisores | Ben Daniel A. | noviembre de 2021
Como era de esperar, finalmente me encontré revisando voluntariamente el código enviado por los candidatos del proyecto de Android que estaban dispuestos a trabajar con nosotros. Diré que el resultado de una decisión resultó ser una muy buena decisión.
En estoSegundo En este artículo, tengo la intención de compartir algunos consejos sobre cómo aumentar la probabilidad de que los revisores encuentren su código fácil de revisar. La mayor parte de lo que quiero decir se basa en mi experiencia en la revisión de envíos de códigos y puede contener algunos sesgos, así que no lo trate como una regla fija. Empecemos.
Configuración perfecta
Una especie de Como revisor, lo que más odio es que tengo que saltar obstáculos para lograr que el código de otras personas se compile y ejecute con éxito en mi dispositivo. La primera impresión del revisor del código base del candidato comienza con este primer paso.
En algunos casos, recomendaría usar solo versiones estables de bibliotecas y herramientas al escribir proyectos. De esta forma, puede estar seguro de que la posibilidad de error en este paso es baja.
Debo señalar que la versión experimental o inestable solo debe usarse cuando sea absolutamente necesario. Personalmente, entiendo el uso de material experimental en Jetpack Compose y Kotlin Coroutines.
Finalmente, debe estar familiarizado con la estructura del proyecto. Debería ser fácil para cualquiera saber dónde encontrar la inyección de dependencia, ver modelos o clases de IU. También estoy muy agradecido cada vez que divido un proyecto en submódulos significativos vinculados a través de dependencias modulares.
Escribir documentación
ToneladaAquí debería haber un README Archivos del proyecto. Idealmente, cada proyecto necesita uno. Incluso si no tiene ningún documento para escribir en este archivo, le recomiendo que lo cree, luego ponga la descripción de la tarea en este archivo y luego marque junto a cada objetivo de la tarea.
Si se requieren configuraciones adicionales antes de que el proyecto se pueda construir con éxito, esto debe ser README. Por ejemplo, si desea leer el valor de unTHIRD_PARTY_LIBRARY_API_KEY En un nombre local_config.properties, Esto debería estar en README documento.
Se deben proporcionar otros tipos de documentos cuando sea necesario. Por ejemplo, si la advertencia de desaprobación se suprime intencionalmente, me gustaría ver comentarios que expliquen por qué se ignoró el método recomendado.
He escrito muchos artículos sobre cómo escribir comentarios de código. Para no exagerar este artículo, recomendaré este artículo sobre las mejores prácticas para escribir comentarios de código.
Mantenlo simple, estúpido
ToneladaIntentar comprender fragmentos de código complejos puede interrumpir el proceso del revisor. Ya existen patrones arquitectónicos establecidos con los que los ingenieros de software están familiarizados. Violar este principio, al introducir una complejidad innecesaria, en lugar de dividir el código complejo en pasos más simples, no ayudará a nadie.
Cuando el código base de una persona tiene dioses, se pueden ver situaciones comunes que violan este principio. Por ejemplo, hay algo como esto:abstract BaseActivity, abstract BaseFragment, abstract BaseViewModelEtc. debe evitarse.
La razón es que se necesita un poder cerebral adicional para comprender lo que está sucediendo. BaseFooBar Antes de que pueda continuar con las clases heredadas de él. Un truco para evitar esto es apoyar la composición en lugar de la herencia al agregar comportamiento a la clase.
Muestre su conocimiento de las herramientas modernas
ustedEl uso de herramientas de programación modernas y estables es una de las mejores formas de demostrar su comprensión de los beans. ¿Qué mejor manera de impresionar a los revisores que hacer que un revisor revise un proyecto que demuestre que están sincronizados con el último proyecto? Sistema tecnico?
Por ejemplo, los proyectos de Android más nuevos deben usar Gradle Kotlin DSL + buildSrc En lugar de Groovy DSL Declare la configuración de gradle. Además, deben usarse funciones de extensión en lugar de clases de utilidad.
Hablando de funciones de extensión, conocimiento existente de funciones de extensión androidx La biblioteca es una gran ventaja. El último consejo es que puede usar propiedades de delegado como delegado de vinculación de vista para reducir el código repetitivo.
Realice controles de calidad del código
SegundoAntes de enviar el código para su revisión, es importante asegurarse de que se hayan resuelto todos los errores de pelusa.Una forma sencilla de asegurarse de que no haya errores de pelusa es configurar abortOnError Regístrate para true dentro lintOptions Configuración.
Si puedes ./gradlew clean build Su proyecto no tiene errores después de la configuración, entonces su proyecto no tiene pelusa ni polvo. Incluso puede configurar detekt & ktlint para verificar sus archivos Kotlin más a fondo.
Finalmente, no puedo exagerar la importancia de garantizar que su código tenga el formato adecuado. Según la experiencia, puede utilizar la guía de estilo kotlin proporcionada por Google de forma predeterminada.Si decide usar ktlint, Viene con un ktlintFormat Puede utilizar esta tarea para formatear rápidamente todo el archivo kotlin en el proyecto.
Prueba de escritura
Una generaciónDe hecho, cada proyecto debería tener pruebas. Hay diferentes opiniones al respecto, y creo firmemente que los ingenieros superiores y de nivel medio deberían probar en su base de código.
Qué probar es otro tema. Un consejo es mirar los objetivos de la tarea y escribir casos de prueba para estos objetivos. Descubrí que las pruebas de escritura pueden revelar algunos casos extremos no manejados.
Se siente más rápido escribir pruebas unitarias y omitir las pruebas de IU, pero recomiendo que haya algunas pruebas de IU en el proyecto.
Si decide no incluir pruebas en su proyecto, elimine src/androidTest Y src/test Carpetas del proyecto.Nada es más decepcionante que esperar ver pruebas reales en estas carpetas solo para ver las generadas automáticamente ExampleInstrumentedTest con ExampleUnitTest amable.
