«Ne pas réinventer la roue» ignore-t-il les limites de la mémoire humaine?

Une chose en travaillant à Haskell et F # m'a appris que quelqu'un dans une université plus intelligent que moi a probablement déjà trouvé une abstraction pour ce que je fais. De même en C # et en programmation orientée objet, il y a probablement une bibliothèque pour "it", quoi que je fasse.

L'accent est tellement mis sur la réutilisation des abstractions dans la programmation que je ressens souvent un dilemme entre: 1) simplement coder quelque chose de court et sale moi-même ou 2) passer le même temps à trouver la bibliothèque / solution la plus robuste de quelqu'un d'autre et simplement l'utiliser.

Comme récemment, l'un des codeurs ici a rédigé un (dé) sérialiseur pour les fichiers CSV, et je n'ai pas pu m'empêcher de penser que quelque chose comme ça est probablement très facile à trouver en ligne, s'il n'est pas déjà livré avec la norme .NET Apis.

Je ne le blâme pas cependant, plusieurs fois en travaillant sur .NET, j'ai corrigé une solution basée sur ce que je sais, seulement pour réaliser qu'il y avait un appel de méthode ou un objet ou quelque chose , souvent dans la même bibliothèque, qui a fait quoi Je voulais et je n'en savais rien.

Est-ce juste un signe d'inexpérience, ou y a-t-il toujours un élément de compromis entre l'écriture de nouveaux et la réutilisation d'anciens? Ce que je déteste le plus, c'est quand je rencontre une solution que je connaissais déjà et que j'avais oubliée. J'ai l'impression qu'une personne n'est tout simplement pas capable de digérer les quantités considérables de code qui sont préemballées avec la plupart des langues de nos jours.

Tout d'abord, vous devez apprendre à identifier les «composants» suffisamment génériques / réutilisables pour qu'une bibliothèque ou une solution tierce existe probablement déjà. Une fois que vous faites cela, sachez que, même si vous êtes un bon développeur, l'expérience collective d'innombrables développeurs passant d'innombrables heures sur le même problème a probablement produit une solution meilleure que vous ne pourrez jamais le faire. Cela ne signifie pas que vous ne devriez jamais "réinventer la roue", mais si vous choisissez de le faire, vous feriez mieux d'avoir une bonne justification DAMN pour le faire.

L'accent est tellement mis sur la réutilisation des abstractions dans la programmation que je ressens souvent un dilemme entre: 1) simplement coder quelque chose de court et sale moi-même ou 2) passer le même temps à trouver la bibliothèque / solution la plus robuste de quelqu'un d'autre et simplement l'utiliser.

Il convient de mentionner que même s'il vous faut autant de temps pour trouver une bibliothèque / solution existante que pour l'écrire vous-même, n'oubliez pas que le faire vous-même signifie également que vous devrez le maintenir pour toujours . Vous n'êtes pas seulement en train de réinventer la roue, mais aussi toute l'équipe des stands pour la faire fonctionner. Bien sûr, certaines bibliothèques sont boguées ou mal entretenues, mais ce sont des choses que vous devez garder à l'esprit lorsque vous choisissez une solution tierce.

Parfois, c'est un signe d'inexpérience, que ce soit avec le langage particulier ou avec la programmation en général. Parfois, cependant, si l'ajustement n'est pas évident, il est préférable de lancer votre propre code qui fait exactement ce que vous voulez et rien de plus . Les bibliothèques génériques, bien que souvent utiles, peuvent être construites pour des besoins que vous n'avez tout simplement pas, et dans certains cas, ce niveau de généricité peut leur causer plus de problèmes qu'ils n'en valent la peine.

Exemple: Pour mes petits projets individuels, je n'utilise jamais une "vraie" bibliothèque de journalisation. J'utilise des printinstructions plus une petite configuration ad hoc. Je ne veux pas être dérangé par la mise en place et la configuration d'une bibliothèque de journalisation qui a bien plus de fonctionnalités que je n'en utiliserai jamais, lorsque les printinstructions fonctionnent bien à mes fins. Je ne veux pas non plus une autre dépendance qui pourrait ne pas être compatible avec la version du compilateur / interprète que je veux utiliser, devrait être distribuée, etc.

Bienvenue dans le monde de la programmation. Cette question fera l'objet de nombreux désaccords entre vous et vos futurs collègues. Vous avez deux options:

1. Roulez le vôtre.
2. Construisez quelque chose au-dessus de la solution de quelqu'un d'autre.

Je pense qu'il y a des moments où les deux solutions sont appropriées. Par exemple, je préférerais éviter de rouler mon propre analyseur CSV d'ORM si je peux l'éviter principalement parce que c'est un travail assez fastidieux. D'un autre côté, les bibliothèques sont souvent restreintes. Je dirais que pour chaque projet sur lequel j'ai travaillé, j'ai rencontré des bibliothèques qui résoudraient parfaitement mon problème sinon pour celui-ci. Ou parfois, une bibliothèque est exactement ce dont vous avez besoin lorsque vous commencez à faire quelque chose, mais elle est plus nuisible que d'aider une fois que vous devez apporter des modifications.

En général cependant, je déconseille d'essayer de trouver des réponses «correctes» car elles n'existent pas. En cas de doute, allez-y avec votre instinct. J'ai entendu une fois quelqu'un dire que l'expérience est définie par le nombre d'erreurs stupides que vous faites. Donc, généralement, vous apprendrez quelque chose ou vous réussirez quelque chose. De toute façon, ce n'est pas si mal.

Cela (ou une chose similaire) m'est souvent arrivé dans un emploi précédent où le cadre souffrait d'un grave effet de plate-forme intérieure.

Fondamentalement, leur base de code a évolué depuis les premiers jours de Windows C / C ++, puis a commencé à être compilée sous MFC - et les responsables ont donc commencé à mélanger MFC et leurs anciennes structures de données internes et composants de fenêtrage. La plate-forme interne n'était pas très bien documentée, mais c'était soi-disant "The Way" pour faire des choses sur ce produit, en raison de certaines installations internes qu'il fournissait. J'ai souvent trouvé plus facile et plus rapide d'écrire mes propres trucs à partir de zéro (à partir des principes fondamentaux du MFC), plutôt que de trouver comment le faire avec le cadre interne de l'entreprise.

(D'accord, cela semble donc être presque le contraire de votre point de départ - mais le principe est le même, hehe! Ouais, parfois, il est vraiment plus rapide de faire votre propre chose que de passer du temps et des efforts pour trouver un existant réutilisable Solution.)