Nous sommes stupides. Acceptons le.
Vous êtes stupide
Arrêtez de prétendre que vous ne l'êtes pas. Nous sommes tous stupides . Nous faisons des erreurs, nous oublions des choses, nous utilisons mal les outils, nous croyons des mensonges. Acceptez-le simplement, reconnaissez-le, admettez-le. Nous sommes stupides, et alors?
Embrasser la bêtise
Maintenant que vous savez que vous êtes stupide, agissez comme tel. Écrivez du code comme un dummy pour qu'un autre dummy le lise, car ce dummy sera vous dans une heure, un jour, une semaine, des mois ou des années à venir.
Ne présumez pas que vous comprendrez votre code, vous ne le comprendrez pas. Eh bien, du moins pas immédiatement. Cela prendra du temps, beaucoup de temps, tellement que vous oublierez ce que vous avez compris au début.
Si vous prenez ce code:
def format(n, *, b = 1024, p = '', s = 'B'):
if not n:
return f'0{s}'
if not isinstance(n, int):
raise TypeError(f'Invalid num type = {type(n)}')
if not isinstance(b, int):
raise TypeError(f'Invalid base type = {type(b)}')
x = '-' if n < 0 else ''
n = abs(n)
try:
m = int(math.floor(math.log(n, b)))
except OverflowError:
m = 99
val = float(n / math.pow(b, m))
if m > 7:
val = f'{val:.0f}' if val.is_integer() else f'{val:.1f}'
return f'{x}{val}{"Y"}{p}{s}'
val = f'{val:.0f}' if val.is_integer() else f'{val:3.1f}'
return f'{x}{val}{["", "K", "M", "G", "T", "P", "E", "Z"][m]}{p}{s}'
Il est mauvais. Et l’écrire de cette façon est une mauvaise idée. Car comme il s’agit d’un mauvais code, aucun dummy ne comprendra, nous devons donc le réécrire.
Choisissez des noms significatifs : qu'est-ce que cela formate ? que contiennent les variables?
Ajoutez des types (si votre langue n'est pas strictement typée) .
Ajoutez des commentaires , mais n'en faites pas trop . Nous sommes stupides, nous oublions de changer les commentaires, nous mentons dans les commentaires. Si vous le pouvez, évitez les commentaires, mais sachez que vous êtes stupide.
def format_amount(num: int, *, base: int = 1024, prefix: str = '', suffix: str = 'B') -> str:
"""
Humanize any amount to string
format_amount(0) == "0B"
format_amount(1750) == "1.7KB"
format_amount(1234567890) == "1.1GB"
format_amount(2000, base=10, suffix='r') == "2Gr"
:param num: numeric amount
:param base: how much does the step takes (default 1024 as for bytes)
:param prefix: type prefix (default '')
:param suffix: type suffix (default B as for bytes)
:return: Formatted amount string
:raise TypeError:
"""
if not num:
return f'0{suffix}'
if not isinstance(num, int):
raise TypeError(f'Invalid num type = {type(num)}')
if not isinstance(base, int):
raise TypeError(f'Invalid base type = {type(base)}')
sign = '-' if num < 0 else ''
num = abs(num)
try:
magnitude = int(math.floor(math.log(num, base)))
except OverflowError:
magnitude = 99
val = float(num / math.pow(base, magnitude))
if magnitude > 7:
val = f'{val:.0f}' if val.is_integer() else f'{val:.1f}'
return f'{sign}{val}{"Y"}{prefix}{suffix}'
val = f'{val:.0f}' if val.is_integer() else f'{val:3.1f}'
return f'{sign}{val}{["", "K", "M", "G", "T", "P", "E", "Z"][magnitude]}{prefix}{suffix}'
Maintenant, je peux voir ce qui se passe du premier coup d'œil, des années après.
Ne pas optimiser, ne pas refactoriser
Vous êtes stupide . Vous ne pouvez pas optimiser, vous ne pouvez pas écrire de code parfait. Soyez stupide et écrivez simplement ce que vous devez.
Vous avez l'impression que le code est lent ? Ne vous inquiétez pas, écrivez-le simplement.
Vous pensez qu'il devrait y avoir une abstraction? Non, ne le faites pas. Vous êtes stupide.
Nous sommez très, TRÈS mauvais en estimation.
Nous ne pouvons pas estimer combien de temps la tâche prendra
Nous ne pouvons pas estimer la performance du code
Nous ne pouvons pas estimer quand les abstractions sont nécessaires
Nous ne pouvons pas prédire comment un projet va tourner.
Ne le force pas. Ne le précipite pas. Faites juste en sorte que ça fonctionne. Une fois que vous avez terminé, vous serez encore stupide. Oubliez l'optimisation, oubliez le refactoring. Assurez-vous de comprendre ce que vous avez fait et assurez-vous que vous le comprendrez plus tard.
Fait?
Il est maintenant temps d'optimiser.. NON ! Vous êtes stupide. Ne l’oubliez pas!
Une fois que vous avez fini d'écrire du code stupide pour des personnes stupides qui dirigent l'entreprise stupide , une fois que vous l'avez couvert de tests , vous pouvez enfin l'optimiser et le refactoriser. Mais cela ne signifie pas que vous devriez.
Est-ce vraiment lent ? À quel point est-il lent ? Le savez-vous? Assurez-vous que vous savez vraiment à quel point les choses sont lentes avant de l'optimiser, sinon vous ne sauriez pas si c'est mieux. Et rappelez-vous, vous êtes stupide, alors ne devinez pas, écrivez une référence ou quoi que ce soit.
Ne faites pas d’abstractions, à moins que cela fasse ~20 fois que vous écrivez la même chose. Même alors, vous devriez le reconsidérer. La plupart du temps, les abstractions sont simplement fausses ou changent si fréquemment que vous feriez mieux de vous en passer.
Vous n’êtes pas ingénieur
Arrêtez de prétendre que vous êtes ingénieur, architecte ou autre. Vous ne l’êtes pas. Vous êtes un singe stupide. N'inventez pas des choses, d'autres personnes moins stupides ont tout fait pour vous.
Vous avez besoin de stocker des données ? utilisez la base de données, n'essayez pas d'écrire une solution maison à un problème qui n'existe pas.
Vous avez besoin de stocker des fichiers ? utilisez des stockages, n'essayez pas d'écrire une solution maison à un problème qui n'existe pas.
Vous avez besoin d'intégrer des services externes ? utilisez des API, des SDK, n'essayez pas d'écrire une solution maison à un problème qui n'existe pas.
Vous avez besoin de savoir qu'un numéro de téléphone ou un e-mail est correct ? envoyez-lui un message et vérifiez si ça fonctionne, n'essayez pas d'écrire une solution interne à un problème qui n'existe pas.
Je pense que vous avez compris l'essentiel. Ne résolvez pas des problèmes qui n'existent pas. Ne les cherchez pas. Il n'y a pas de problèmes, juste une tâche que vous devez faire. Faites-le et rien d'autre.
Pas de suppléments
SOLID ? Plutôt STUPIDE . Il n'y a pas de code propre, il n'y a pas de solution parfaite. Seulement des compromis.
Ne vous contentez pas d'appliquer chaque style de code ou modèle de programmation que vous avez appris. Cela ne fonctionnera pas.
Utiliser le linter et le formateur par défaut.
S'il n'y en a pas, recherchez la « valeur par défaut » tierce qui est acceptée par la communauté.
Pour JavaScript/TypeScript, avec eslint ce serait plus joli
Pour Python s'en tenir au PEP-8 par défaut
Pour Golang, utilisez par défaut go fmt
Il n'y a pas besoin de Google Approved Best Recommended Style Guide 9000 . Vous ne ferez que vous faire du mal. Ne comptez sur eux que si votre équipe le fait déjà.
Écrivez un code simple, stupide et sans modèle.
Vous pouvez identifier et appliquer des modèles plus tard , mais ne les forcez pas.
N'essayez pas d'ajouter des singletons, des commandes, des engines, etc., simplement parce que vous les connaissez et que quelqu'un vous a dit de le faire.
Votre code doit fonctionner et être lisible et… stupide. La plupart des modèles viendront naturellement au fur et à mesure que vous l'écrivez, ou seront d'une évidence obscène une fois que vous aurez terminé. Si ce n'est pas le cas, ce n'est pas le moment de les ajouter.
La même chose s'applique au code stupide. Le modèle de conception KISS (keep it simple, stupid) n'implique pas que vous deviez écrire du mauvais code laid. Écrivez simplement et naturellement pendant que votre cerveau crache des idées sur la façon d'accomplir votre tâche.
Écrire un code de blocage à un seul thread.
Vous ne pouvez pas écrire un bon code multithread. Pas au début, et peut-être même pas plus tard.
Le code multi-thread est difficile . Tellement dur, en fait, que l'async existe. Et il le fait pour une raison. Rappelez-vous simplement que l'asynchrone est en fait à un seul thread (à l'exception des goroutines et autres, ils peuvent et essaieront d'utiliser autant de cœurs que vous pouvez leur donner).
Utilise ta tête
Votre tête est vide . Remplissez-le avec quelques connaissances. Lisez des articles, regardez une vidéo, assistez à une conférence, lisez un livre.
N'arrête pas d'apprendre, parce que tu es stupide. Tu ne peux pas devenir intelligent, mais tu peux être moins stupide.
Apprenez chaque jour quelque chose de nouveau. Répétez ce que vous avez appris. Faites en sorte que votre cerveau s'en souvienne. Mais ne vous contentez pas de vous souvenir.
Analysez. Tout ce que vous lisez, entendez ou voyez - analysez .
Est-ce vraiment le cas ?
Dois-je le savoir, m'en souvenir ?
Comment puis-je savoir si c'est vrai?
Comment puis-je prouver que ce n'est pas le cas ?
Quelle est mon opinion là-dessus ?
Comment cette connaissance m'affecte-t-elle ?
Utilisez votre tête quotidiennement. Ne comptez pas sur les autres. Ne demandez pas aux autres, ils sont stupides. Vous l'êtes aussi, mais au moins utiliser votre propre cerveau vous permettra de l’être moins.
Mensonges, doux mensonges
Ne faites jamais confiance à personne, pas à moi, pas même à vous-même. Comme je l'ai dit, nous sommes stupides et nous mentons.
Parfois, nous ne savons même pas quand nous mentons. Certains ont peut-être entendu une chose à la télévision ou de la part de leurs parents et ont cru que c'était vrai toute leur vie et maintenant ils la partagent avec vous. Ce sont vos meilleurs amis, bien sûr ils ne mentiraient pas, n'est-ce pas ? NON!
Ils ne le comprennent peut-être pas, mais ils peuvent mentir et mentiront de temps en temps. Nous le faisons tous .
Dites non
Dites non à toutes les idées stupides que vous, votre collègue ou votre patron avez. C'est stupide et tu le sais.
N'ayez pas peur de dire non à des trucs stupides. L'accepter pour "l'esprit de commandement" ou "l'humilité" est tout simplement mauvais et rendra votre vie misérable.
J'ai dit des idées stupides. Cela ne signifie pas que vous devez refuser toutes les tâches qui vous ont été assignées. Assurez-vous simplement que ce n'est pas stupide.
Et ne forcez pas . Si vous devez, vous devez. L'informatique est une entreprise, une entreprise stupide dirigée par des humains stupides.
La plupart des choses que j'ai écrites s'appliquent en fait à d'autres choses dans la vie. Certains diront peut-être que certaines d'entre elles ne concernent même pas la programmation, mais c'est faux .
Les humains et l'interaction humaine sont une partie ÉNORME de l'informatique. Les humains écrivent du code que d'autres humains utilisent. Les humains écrivent des articles sur la programmation et tout ce qui l’entoure. Les humains lisent le code, pas l'ordinateur. L'ordinateur ne lit pas le code. Il le scanne pour des bits et des octets et des trucs.
La plupart des problèmes dans la base de code viennent des humains. Améliorez-vous, améliorez vos compétences et rappelez-vous que vous êtes stupide .
Si j'oublie quelque chose ou si vous pensez le contraire, ne vous gênez pas pour commenter. Je suis stupide. Je ments. On le fait tous.
Merci de me lire.