Plongée dans les meilleures pratiques de développement logiciel?: une réflexion sur un code propre

Au début de mes études sur les bonnes pratiques de développement logiciel, j'ai imaginé le "Clean Code" (Clean Code) comme un simple ensemble de règles pour garantir un code lisible. Cette perception est en partie correcte. Cependant, ces règles ne s'appliquent pas toujours à tous les types de code et ne sont certainement pas entièrement comprises par la simple lecture d'un livre.

Clean Code?: un voyage continu

Récemment, j'ai relu le classique Clean Code, de Robert C. Martin, et ma compréhension était très différente de la première lecture, il y a six ans. En tant qu’étudiant universitaire à l’époque, bon nombre des problèmes et des solutions présentés n’étaient pas tout à fait clairs. C’est la grande idée fausse?: Clean Code n’est pas pour les débutants.

"... et si vous étiez médecin et qu'un patient exigeait que vous arrêtiez tout ce lavage des mains en préparation à une opération chirurgicale simplement parce que cela prend trop de temps ? [...] il n'est pas professionnel pour les programmeurs de céder au volonté de grands managers qui ne comprennent pas les risques de générer des codes confus."

Cet article met en évidence les points pertinents de mes lectures et partage des expériences pratiques.

Fonctions : Une responsabilité unique

Une fonction bien écrite devrait avoir une seule responsabilité?: faire une chose, la faire bien, et seulement cela. Le regroupement de plusieurs responsabilités en un seul r?le rend le code difficile à lire, à tester et à maintenir.

Exemple de r?le avec plusieurs responsabilités (sauvegarde et notification des utilisateurs)?:

<code>function salvarUsuarioENotificar(usuario) {
    // Valida os dados do usuário
    if (!usuario.nome || !usuario.email) {
        throw new Error('Dados do usuário incompletos.')
    }

    // Salva no banco de dados
    bancoDeDados.salvar(usuario)

    // Envia um e-mail de boas-vindas
    emailService.enviarEmail(usuario.email, 'Bem-vindo!', 'Obrigado por se cadastrar!')
}</code>

Après refactoring, chaque responsabilité dans un r?le spécifique?:

<code>function validarUsuario(usuario) {
    if (!usuario.nome || !usuario.email) {
        throw new Error('Dados do usuário incompletos.')
    }
}

function salvarUsuario(usuario) {
    bancoDeDados.salvar(usuario)
}

function enviarEmailDeBoasVindas(usuario) {
    emailService.enviarEmail(usuario.email, 'Bem-vindo!', 'Obrigado por se cadastrar!')
}

function processarCadastroDeUsuario(usuario) {
    validarUsuario(usuario)
    salvarUsuario(usuario)
    enviarEmailDeBoasVindas(usuario)
}</code>

Désormais, chaque fonction a une seule responsabilité, ce qui rend le code plus lisible et plus facile à maintenir.

Commentaires?: donner la priorité aux noms explicites

Les commentaires sont utiles, mais privilégiez les noms explicites pour éviter les redondances. Des commentaires évidents polluent le code.

Exemple de commentaire inutile?:

<code>/** Dia do mês **/
private number diaDoMes;</code>

Améliore avec un nom plus clair et sans commentaires?:

<code>private number diaDoMesAtual;</code>

Objets et structures de données?: encapsulation et clarté

Une bonne conception orientée objet se concentre sur l'exposition des opérations et le masquage des détails de mise en ?uvre. Cela favorise l'encapsulation, réduit le couplage et facilite la maintenance.

Exemple d'encapsulation dans une classe Circulo :

<code>class Circulo implements Forma {
    private Ponto centro;
    private number raio;
    private number PI = 3.14159;

    public number calcularArea() {
        return PI * raio * raio;
    }
}</code>

évitez de réutiliser des variables dans différentes portées à des fins différentes. Utilisez des variables distinctes pour plus de clarté.

Gestion des erreurs?: des exceptions au lieu de vérifications multiples

Dans le passé, la gestion des erreurs était limitée. Aujourd'hui, l'utilisation d'exceptions rend le code plus propre et plus lisible.

Exemple de code verbeux avec plusieurs validations?:

<code>function salvarUsuarioENotificar(usuario) {
    // Valida os dados do usuário
    if (!usuario.nome || !usuario.email) {
        throw new Error('Dados do usuário incompletos.')
    }

    // Salva no banco de dados
    bancoDeDados.salvar(usuario)

    // Envia um e-mail de boas-vindas
    emailService.enviarEmail(usuario.email, 'Bem-vindo!', 'Obrigado por se cadastrar!')
}</code>

Refactoring à l'aide d'exceptions?:

<code>function validarUsuario(usuario) {
    if (!usuario.nome || !usuario.email) {
        throw new Error('Dados do usuário incompletos.')
    }
}

function salvarUsuario(usuario) {
    bancoDeDados.salvar(usuario)
}

function enviarEmailDeBoasVindas(usuario) {
    emailService.enviarEmail(usuario.email, 'Bem-vindo!', 'Obrigado por se cadastrar!')
}

function processarCadastroDeUsuario(usuario) {
    validarUsuario(usuario)
    salvarUsuario(usuario)
    enviarEmailDeBoasVindas(usuario)
}</code>

Tests unitaires?: clarté et concentration

Les tests propres doivent être clairs, simples et cohérents. Transmettez beaucoup d'informations avec peu d'expressions.

Structure générale d'un test : Build, Operate, Verify.

Cours?: SRP (Principe de responsabilité unique)

Le nom de la classe doit refléter sa responsabilité. Les classes doivent être petites et avoir un seul objectif. SRP garantit que chaque classe n'a qu'une seule responsabilité.

Conclusion?:?Le code propre est un voyage

Le Clean Code ne peut pas être appris en une seule fois. C'est un voyage continu qui nécessite de la pratique, de la réflexion et de l'évolution. La véritable compétence vient avec l’expérience et la capacité de constater des améliorations. Les règles de Kent Beck (tests, éviter les duplications, clarté, minimiser les classes et les méthodes) sont un guide précieux.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!