Le programme a un objectif qui est parfois oublié
Image d'un marteau allongé sur un tableau noir. Une vis était coincée dans la planche, ils y ont marqué durIl semble que les programmeurs aient oublié l'objectif du logiciel - résoudre des problèmes du monde réel.
Il y a 50 ans, en 1968, une
conférence de travail sur le génie logiciel était organisée par le Comité scientifique de l'OTAN. Puis ils ont commencé à remarquer que les logiciels devenaient un élément fondamental de la société. Et en même temps, cela devient plus difficile à comprendre. Après cette conférence, la programmation a commencé à devenir une véritable industrie. Il a commencé à perdre le contrôle de l'entreprise.
Quel que soit le sort de l'industrie, il y a toujours un problème avec la séparation du développement commercial et logiciel - ou «ingénierie», comme cela a été annoncé pour la première fois lors de la conférence. Si les programmeurs se concentrent trop étroitement sur le développement, ils peuvent manquer l'objectif pour lequel le programme est créé. Ils peuvent manquer des solutions cachées qui ne nécessitent aucun code.
Voici un exemple.
Une startup a créé un appareil qui a ouvert la porte d'une maison via Bluetooth. Interface graphique pour la communication avec l'appareil - un widget sur un écran de téléphone verrouillé. Il a un bouton appelé "Ouvrir la porte".
Lorsque l'utilisateur s'approche de la maison, il prend le téléphone, trouve le widget et appuie sur le bouton.
Quelqu'un a regardé ce mécanicien et a demandé:
Si nous utilisons Bluetooth et supposons que le propriétaire du téléphone peut entrer dans la maison, pourquoi le forcer à prendre le téléphone et à appuyer sur le bouton? Laissez la porte se déverrouiller lorsque le téléphone se trouve dans un rayon de 1 mètre. Pas besoin de perdre du temps sur la conception et le code GUI!Ceci est un excellent exemple d'une mise au point étroite: l'objectif était d'ouvrir la serrure avec un minimum d'effort. Cela n'a aucun sens de créer une interface graphique si les capteurs sont sans fil.
Si vous connaissez les défis commerciaux et les besoins des utilisateurs, vous pouvez combiner ces connaissances avec vos connaissances en technologie. Ce n'est qu'alors que vous aurez suffisamment d'informations pour trouver une meilleure solution et comprendre que le programme n'a pas besoin d'une interface.
Un excellent exemple de la façon de résoudre un problème logiciel
sans une seule ligne de nouveau code , en plus du code pour ouvrir réellement la serrure. Mais
comme le devoir technique ,
rien ne peut justifier la programmation inutile de tout le reste.
Tous les codes ne valent pas la peine d'être écrits.
Parfois, la correction d'un bug grave n'est pas la tâche principale. Si vous êtes un échange de crypto-monnaie et que le système autorise un
double dépôt , l'intervention humaine peut être la meilleure solution en termes de rapport coût-bénéfice si le coût de la solution est élevé.
Ce compromis entre importance et priorité me rappelle un modèle récemment montré par un
collègue . Il s'agit d'une matrice de priorité - un
modèle à deux dimensions qui peut être utilisé pour hiérarchiser les bogues en fonction de la gravité et du nombre d'utilisateurs affectés.
Matrice bidimensionnelle des priorités. L'axe vertical représente le nombre de «victimes» avec les valeurs «un», «plusieurs» et «toutes». L'axe horizontal représente le «sérieux» avec les valeurs «cosmétique», «inconfortable» et «cesse de fonctionner». La priorité du bug est déterminée par la position sur les axes. Par exemple, si l'erreur est cosmétique et affecte un utilisateur, la priorité est 4 (minimum). Si un bug arrête certains utilisateurs, la priorité est 1. S'il arrête tous les utilisateurs, il a la priorité la plus élevée.Le problème du double dépôt mentionné ci-dessus entre dans la catégorie des
inconvénients qui ont affecté
un utilisateur . Par conséquent, priorité 3.
Tous les bogues ne valent pas la peine d'être corrigés.
Les développeurs cherchent souvent à prévoir tous les cas. Mais certaines tâches répétitives peuvent ne pas mériter une automatisation. Il n'est pas nécessaire de perdre du temps à écrire des scripts si des connaissances importantes sur le travail de l'équipe principale sont ainsi cachées.
Il y a une différence entre l'encapsulation d'une logique complexe et l'abstraction de connaissances utiles. Parfois, seules des informations claires peuvent être comprises. Si nous l'abstrayons, nous pouvons obtenir l'effet inverse: la compréhension est difficile.
Il est plus utile d'utiliser certains types de commandes de bas niveau dans la CLI que des commandes de niveau supérieur avec des connaissances abstraites,
comme les alias Git .
Toutes les équipes ne valent pas la description.
Il y a plusieurs années, je travaillais sur un projet avec
livraison incrémentielle . Il s'agissait d'un système de vérification d'identité qui demandait à l'utilisateur de fournir certaines données personnelles pour vérification par un tiers.
Et là, l'équipe a voulu coder une fonction de validation de terrain inhabituelle. Cependant, cette validation a été repoussée sur chaque planteur à l'approche de l'échéance. Finalement, ils ont décidé que cette fonction inhabituelle n'avait aucun sens.
Et voici pourquoi: la validation est déjà forcée!
La fourniture d'informations fiables était dans l'intérêt de l'utilisateur. S'il a fourni des données incorrectes, ils ne passeront pas la vérification et il ne pourra pas utiliser le système. De plus, la plupart des navigateurs prennent en charge une assez bonne validation HTML standard.
Dans le pire des cas, si l'utilisateur ne peut pas être vérifié, il appellera le support pour une vérification manuelle.
Toutes les fonctions ne valent pas la peine d'être codées
Si vous comprenez l'essence du problème résolu, en tant que développeur, vous pouvez trouver un meilleur code, et parfois vous pouvez vous passer du code. Vous n'êtes pas un
byldoder qui est payé pour écrire des lignes pour la tâche. Vous êtes un professionnel qui est payé pour résoudre des problèmes.
Mais il n'est pas nécessaire de résoudre sans problème aucun problème avec les technologies, comme si le code de programme est une solution universelle pour tout. Sinon, vous aurez du mal à comprendre les besoins du client et à générer de bonnes idées.
Votre objectif et la tâche du code est de créer de la valeur et de rendre le monde meilleur, et non de satisfaire votre idée égocentrique de la façon dont le monde devrait être.
Il y a un dicton: "Si vous n'avez qu'un marteau, tout devient comme un clou."
Il est préférable de voir d'abord un clou pour considérer la nécessité d'un marteau.
Si vous avez vraiment besoin de marteler cet ongle.