Canso da revisión ou depuración de código interminable, ás veces pensas en como simplificar a túa vida. E despois de buscar un pouco, ou de tropezar con el accidentalmente, podes ver a frase máxica: "Análise estática". Vexamos que é e como pode interactuar co teu proxecto.
De feito, se escribes en calquera lingua moderna, entón, sen sequera darte conta, pásao a través dun analizador estático. O feito é que calquera compilador moderno proporciona, aínda que un pequeno conxunto de avisos sobre problemas potenciais no código. Por exemplo, ao compilar código C++ en Visual Studio, podes ver o seguinte:
Nesta saída vemos que a variable foi nunca se utilizou en ningún lugar da función. Entón, en realidade, case sempre usaches un simple analizador de código estático. Non obstante, a diferenza dos analizadores profesionais como Coverity, Klocwork ou PVS-Studio, as advertencias proporcionadas polo compilador poden indicar só unha pequena serie de problemas.
Se non sabes con certeza que é a análise estática e como implementala, para saber máis sobre esta metodoloxía.
Por que precisa unha análise estática?
En poucas palabras: aceleración e simplificación.
A análise estática permítelle atopar moitos problemas diferentes no código: desde un uso incorrecto das construcións da linguaxe ata erros tipográficos. Por exemplo, no canto de
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;Escribiches o seguinte código:
auto x = obj.x;
auto y = obj.y;
auto z = obj.x;Como podes ver, hai un erro na última liña. Por exemplo, PVS-Studio emite o seguinte aviso:
Considere revisar a corrección do uso do elemento "y".
Se queres meter as mans neste erro, proba un exemplo preparado no Explorador do compilador: **.
E como entendes, non sempre é posible prestar atención a tales seccións de código de inmediato e, por iso, podes sentarte a depurar durante unha boa hora, preguntándote por que todo funciona de forma tan estraña.
Non obstante, isto é claramente un erro. E se o programador escribiu un código subóptimo porque esqueceu algunha sutileza da linguaxe? Ou incluso permitiuno no código ? Desafortunadamente, estes casos son completamente habituais e a maior parte do tempo gástase a depurar códigos que funcionan especificamente que contén erros tipográficos, erros típicos ou comportamentos indefinidos.
É por estas situacións onde apareceu a análise estática. Trátase dun asistente para o programador que sinalará varios problemas no código e explicará na documentación por que non é necesario escribir deste xeito, a que pode levar e como solucionalo. Aquí tes un exemplo de como pode ser: **.
Podes atopar erros máis interesantes que o analizador pode detectar nos artigos:
Agora que leches este material e estás convencido dos beneficios da análise estática, quizais queiras probalo. Pero por onde comezar? Como integrar unha nova ferramenta no teu proxecto actual? E como presentarlle o equipo? A continuación atoparás respostas a estas preguntas.
Nota. A análise estática non substitúe nin cancela unha cousa tan útil como as revisións de código. Complementa este proceso, axudando a detectar e corrixir con antelación erros tipográficos, imprecisións e deseños perigosos. É moito máis produtivo centrarse nas revisións de código sobre algoritmos e claridade do código, en lugar de buscar un paréntese ou un paréntese mal colocado. .
0. Coñecer a ferramenta
Todo comeza cunha versión de proba. De feito, é difícil decidir introducir algo no proceso de desenvolvemento se nunca antes viu a ferramenta en directo. Polo tanto, o primeiro que debes facer é descargar .
O que aprenderás nesta etapa:
- Cales son as formas de interactuar co analizador;
- O analizador é compatible co seu entorno de desenvolvemento?
- Que problemas hai actualmente nos teus proxectos?
Despois de ter instalado todo o que necesitas, o primeiro que debes facer é realizar unha análise de todo o proxecto (, , ). No caso de PVS-Studio en Visual Studio, verá unha imaxe similar (se pode facer clic):
O feito é que os analizadores estáticos adoitan emitir un gran número de avisos para proxectos cunha gran base de código. Non hai que arranxalos todos, xa que o teu proxecto xa está funcionando, o que significa que estes problemas non son críticos. Porén, ti e corrixaos se é necesario. Para iso, cómpre filtrar a saída e deixar só as mensaxes máis fiables. No complemento PVS-Studio para Visual Studio, isto faise filtrando por niveis e categorías de erro. Para obter a saída máis precisa, deixe só Alto и xeral (tamén se pode facer clic):
De feito, 178 avisos son moito máis fáciles de ver que varios miles...
En pestanas medio и Baixo Moitas veces hai boas advertencias, pero estas categorías inclúen aqueles diagnósticos que teñen menos precisión (fiabilidade). Podes atopar máis información sobre os niveis de aviso e as opcións para traballar en Windows aquí: **.
Vale a pena ter revisado con éxito os erros máis interesantes (e corrixidos con éxito). . Isto é necesario para que as novas advertencias non se perdan entre as antigas. Ademais, un analizador estático é un asistente para o programador, e non unha lista de erros. 🙂
1. Automatización
Despois de familiarizarse, é hora de configurar complementos e integrarse en CI. Isto debe facerse antes de que os programadores comecen a usar o analizador estático. O caso é que o programador pode esquecerse de activar a análise ou non quere facelo en absoluto. Para iso, cómpre facer unha comprobación final de todo para que o código non probado non poida entrar na rama de desenvolvemento xeral.
O que aprenderás nesta etapa:
- Que opcións de automatización ofrece a ferramenta;
- O analizador é compatible co seu sistema de montaxe?
Dado que a documentación perfecta non existe, ás veces hai que escribir . Isto é normal e estamos encantados de axudarche. 🙂
Agora pasemos aos servizos de integración continua (CI). Calquera analizador pódese implementar neles sen problemas graves. Para iso, cómpre crear unha etapa separada no pipeline, que normalmente se atopa despois das probas de compilación e unidade. Isto faise usando varias utilidades da consola. Por exemplo, PVS-Studio ofrece as seguintes utilidades:
- (análise de solucións, proxectos C#, C++ en Windows)
- (seguimento da compilación)
- (análise de proxectos C++ en Linux / macOS)
- (análise de solucións, proxectos C# en Linux / macOS)
- (análise de proxectos Java)
- (conversor de ficheiros de informes)
Para integrar a análise no CI, cómpre facer tres cousas:
- Instalar o analizador;
- Executar análise;
- Entregar resultados.
Por exemplo, para instalar PVS-Studio en Linux (base Debian), cómpre executar os seguintes comandos:
wget -q -O - https://files.viva64.com/etc/pubkey.txt
| sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
sudo apt-get update -qq
sudo apt-get install -qq pvs-studioNos sistemas que executan Windows, non hai forma de instalar o analizador desde o xestor de paquetes, pero é posible implementar o analizador desde a liña de comandos:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplicationsPodes ler máis sobre a implantación de PVS-Studio en sistemas que executan Windows **.
Despois da instalación, cómpre executar a análise directamente. Non obstante, recoméndase facelo só despois de pasar a compilación e as probas. Isto débese a que a análise estática normalmente leva o dobre que a compilación.
Dado que o método de lanzamento depende da plataforma e das características do proxecto, mostrarei a opción para C++ (Linux) como exemplo:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -wO primeiro comando realizará a análise e o segundo converte o informe en formato de texto, móstrao na pantalla e devolve un código de retorno distinto de 0 se hai avisos. Un mecanismo como este pódese usar convenientemente para bloquear unha compilación cando hai mensaxes de erro. Non obstante, sempre podes eliminar a bandeira -w e non bloquees unha asemblea que conteña avisos.
Nota. O formato de texto é inconveniente. Ofrécese simplemente como exemplo. Preste atención a un formato de informe máis interesante: FullHtml. Permítelle navegar polo código.
Podes ler máis sobre a configuración da análise en CI no artigo "" (Windows) ou "" (Linux).
Está ben, configuraches o analizador no servidor de compilación. Agora, se alguén cargou código non probado, a fase de verificación fallará e poderás detectar o problema, non obstante, isto non é do todo conveniente, xa que é máis eficiente comprobar o proxecto non despois de que se fusionen as ramas, pero antes, na fase de solicitude de extracción. A.
En xeral, configurar unha análise de solicitude de extracción non é moi diferente do lanzamento habitual dunha análise sobre CI. Excepto pola necesidade de obter unha lista de ficheiros modificados. Normalmente pódense obter consultando as diferenzas entre ramas usando git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.listAgora cómpre pasar esta lista de ficheiros ao analizador como entrada. Por exemplo, en PVS-Studio isto implícase usando a bandeira -S:
pvs-studio-analyzer analyze -j8
-o PVS-Studio.log
-S .pvs-pr.listPodes obter máis información sobre a análise das solicitudes de extracción **. Aínda que o teu CI non estea na lista de servizos mencionados no artigo, atoparás útil a sección xeral dedicada á teoría deste tipo de análise.
Ao configurar a análise das solicitudes de extracción, pode bloquear as confirmacións que conteñan avisos, creando así un límite que o código non probado non pode cruzar.
Todo isto certamente é bo, pero gustaríame poder ver todas as advertencias nun só lugar. Non só do analizador estático, senón tamén das probas unitarias ou do analizador dinámico. Hai varios servizos e complementos para iso. PVS-Studio, por exemplo, ten .
2. Integración en máquinas de desenvolvemento
Agora é o momento de instalar e configurar o analizador para o seu uso diario. Ata este punto xa te familiarizaches coa maioría das formas de traballar, polo que esta pode chamarse a parte máis sinxela.
Como opción máis sinxela, os desenvolvedores poden instalar eles mesmos o analizador necesario. Non obstante, isto levará moito tempo e distraerás do desenvolvemento, polo que podes automatizar este proceso mediante un instalador e as bandeiras necesarias. Para PVS-Studio hai varios . Non obstante, sempre hai xestores de paquetes, por exemplo, Chocolatey (Windows), Homebrew (macOS) ou ducias de opcións para Linux.
Entón terás que instalar os complementos necesarios, por exemplo para , , etc.
3. Uso diario
Nesta fase, é hora de dicir algunhas palabras sobre formas de acelerar o analizador durante o uso diario. Unha análise completa de todo o proxecto leva moito tempo, pero cantas veces cambiamos o código ao longo de todo o proxecto á vez? Case non hai refactorización que sexa tan grande que afecte inmediatamente a toda a base de código. O número de ficheiros que se cambian á vez raramente supera a ducia, polo que ten sentido analizalos. Para tal situación hai . Non te alarmes, esta non é outra ferramenta. Este é un modo especial que che permite analizar só os ficheiros modificados e as súas dependencias, e isto ocorre automaticamente despois da construción se estás a traballar nun IDE co complemento instalado.
Se o analizador detecta problemas no código modificado recentemente, informarao de forma independente. Por exemplo, PVS-Studio informarache sobre isto mediante unha alerta:
Por suposto, dicirlles aos desenvolvedores que utilicen a ferramenta non é suficiente. Hai que dicirlles dalgún xeito o que é e como é. Aquí, por exemplo, tes artigos sobre un inicio rápido para PVS-Studio, pero podes atopar tutoriais similares para calquera ferramenta que prefires:
Estes artigos proporcionan toda a información necesaria para o uso diario e non levan moito tempo. 🙂
Mesmo na fase de coñecer a ferramenta, suprimimos moitos avisos durante un dos primeiros lanzamentos. Desafortunadamente, os analizadores estáticos non son perfectos, polo que de cando en vez dan falsos positivos. Normalmente é fácil suprimilos; por exemplo, no complemento PVS-Studio para Visual Studio só tes que facer clic nun botón:
Non obstante, podes facer máis que suprimilos. Por exemplo, pode informar dun problema ao servizo de asistencia técnica. Se se pode corrixir o falso positivo, en futuras actualizacións poderás notar que cada vez hai menos falsos positivos específicos para a túa base de código.
Despois da integración
Polo tanto, pasamos por todas as etapas de integración da análise estática no proceso de desenvolvemento. A pesar da importancia de configurar tales ferramentas en CI, o lugar máis importante para executalas é o ordenador do programador. Despois de todo, un analizador estático non é un xuíz que diga nalgún lugar lonxe de ti que o código non é bo. Pola contra, é un asistente que che indica se estás canso e que che lembra se esqueciches algo.
É certo que sen o uso regular, é improbable que a análise estática simplifique significativamente o desenvolvemento. Despois de todo, o seu principal beneficio para un desenvolvedor non reside tanto en buscar seccións complexas e controvertidas de código, senón na súa detección precoz. Concorda en que descubrir un problema despois de enviar as edicións para probar non só é desagradable, senón que tamén leva moito tempo. A análise estática, cando se usa regularmente, analiza cada cambio directamente no teu ordenador e informa de lugares sospeitosos mentres traballas no código.
E se vostede ou os seus compañeiros aínda non están seguros de se paga a pena implementar o analizador, suxíroche que agora comece a ler o artigo "". Aborda as preocupacións típicas dos desenvolvedores de que a análise estática ocupará o seu tempo, etc.
Se queres compartir este artigo cun público de fala inglesa, utiliza a ligazón de tradución: Maxim Zvyagintsev. .
Fonte: www.habr.com