Libérer un projet open source sans être embarrassé [fermé]

Je travaille seul depuis assez longtemps sur un projet open source assez volumineux et je suis sur le point de le publier. Cependant, je suis un autodidacte et je ne connais personne qui puisse réviser mon projet de manière adéquate.

Il y a quelques années, j'avais publié un petit morceau de code qui avait été déchiré (dans un sens critique) sur le forum où je l'avais publié. Même si le code a fonctionné, les critiques étaient précises mais brutales. Cela m'a incité à commencer à rechercher les meilleures pratiques pour tout et à la fin, j'ai senti que cela faisait de moi un développeur bien meilleur. J'ai tout passé en revue dans mon projet en essayant tant de fois de le rendre parfait que j'ai perdu de son importance.

Je crois en mon projet et pense qu'il a le potentiel d'aider beaucoup de gens et j'ai le sentiment d'avoir fait des choses intéressantes de manière intéressante. Cependant, parce que je suis autodidacte, je ne peux pas m'empêcher de me demander quelles sont les lacunes de mon auto-éducation. La façon dont mon code a été déchiré la dernière fois n'est pas quelque chose que j'aimerais répéter. Je pense que mes deux plus grandes craintes concernant la publication de mon projet, sur lequel j'ai consacré d'innombrables heures, sont absolument gênantes parce que j'ai raté certaines choses manifestement évidentes à cause de mon auto-éducation ou, pire, de le faire entendre au son des grillons.

Y at-il quelqu'un qui a été dans une situation similaire? Je n'ai pas peur des critiques constructives, pour autant que ce soit constructif et pas juste un coup de gueule sur la façon dont j'ai foiré. Je sais qu’il existe un site de révision de code sur StackExchange, mais il n’est pas vraiment configuré pour les grands projets et je ne pensais pas que la communauté était suffisamment grande pour recevoir de bons retours si je devais publier des parties de mon projet au cas par cas (I essayé avec un fichier). Que puis-je faire pour donner à mon projet au moins une mesure de succès sans être gêné ou dévasté dans le processus?

À moins que le projet ne soit destiné aux développeurs (par exemple: un framework de développement, auquel cas vous VOULEZ qu'ils le critiquent s'il vous en apprend plus), vous ne devez pas vous inquiéter. Mais même dans ce cas, il y a beaucoup de projets open source destinés aux développeurs qui sont de la merde, pourtant les gens les aiment parce qu'ils vont au but (pensez à Codeigniter, qui est très mal architecturé, et pourtant c'est le framework php le plus populaire)

S'il s'agit d'une application destinée aux humains normaux, ils ne se préoccuperont probablement que des résultats.

Votre code a des problèmes. Le mien aussi. Quelqu'un d'autre répond à cette question? Leur code a aussi des problèmes.

À moins que ce soit, par exemple, 10 lignes ou moins, c'est imparfait. Peut-être tragiquement alors.

Etre développeur, c'est se confronter constamment aux limites de ses capacités et de sa compréhension. Ce n'est peut-être pas le cas pour TOUS les développeurs, mais pour moi et pour ceux que je connais, nous travaillons presque toujours à la limite de nos compétences. Et vous faites face à cela maintes et maintes et maintes fois, puis passez un bon week-end, puis revenez lundi et recommencez encore et encore.

Ayant travaillé cette vie pendant 15 ans, la chose sur laquelle j'ai décidé est un fait: vous n'êtes pas votre code . Vous écrivez du code. Le jugement du code n'est pas un jugement de votre part . Votre code a des problèmes, certains que vous connaissez, d'autres que vous ne connaissez pas. Le fait que cela soit porté à votre attention vous aide , à moins que tout ce que vous pouvez faire à ce sujet ne vous sente mal. Se sentir mal n'améliore pas votre code, il vous fait juste vous sentir mal.

Vous écrivez votre code, et vous l'écrivez aussi bien que vous savez comment. Peut-être que demain vous en saurez plus qu’aujourd’hui, mais aujourd’hui vous le faites aussi bien que vous le saviez. Mon conseil est le suivant: écrivez le code d'aujourd'hui et celui de demain demain. Alors passez un bon week-end et revenez lundi pour écrire le code de lundi.

En règle générale, les programmes à source ouverte ont trois groupes de personnes qui consultent le code source.

1. Les personnes qui envisagent de modifier le code pour que le programme fonctionne légèrement différemment pour elles, pour le transférer sur une plate-forme différente ou comme point de départ pour leurs propres programmes. S'ils n'aiment pas le code, ils ne l'utiliseront généralement pas et vous ne les entendrez jamais.
2. Les étudiants, essayant d'apprendre à coder dans la langue que vous avez utilisée. Ceux-ci ne vous contacteront presque jamais, mais vous pouvez parfois recevoir un courrier électronique vous demandant pourquoi vous avez agi d'une manière ou d'une autre. (Pour être juste, je n'ai pas reçu l'un de ces courriels depuis de nombreuses années. Je pense que des sites Web comme StackExchange ont peut-être remplacé cette interaction.)
3. Des chercheurs en sécurité, tels que ceux d'OpenBSD, tentent de déterminer si votre outil est suffisamment sécurisé pour être inclus dans leur distribution. Si ce n'est pas le cas, mais qu'ils souhaitent toujours inclure votre programme, ils vous contacteront pour trouver un moyen de le sécuriser. (Et si votre programme devient populaire, j'imagine qu'il attirera probablement aussi les chercheurs Black Hat, qui ne vous contacteront pas, peu importe ce qu'ils trouveront.)

Dans le monde réel, les gens ne liront pas votre code source pour une raison autre que celle-ci, car ils n'en ont tout simplement pas besoin. Vous n’aviez auparavant un tel volume de commentaires que parce que vous aviez posté le code sur un forum, ce qui impliquait que vous souhaitiez recevoir des commentaires sur le code.

Je ne pense pas que vous ayez vraiment besoin de vous inquiéter d'un torrent d'abus; les seules personnes susceptibles de vous contacter sont celles qui souhaitent ajouter des fonctionnalités ou corriger des bogues, qui ont déjà parcouru le code et qui n'ont pas crié pour les collines. ;)

Je ne comprends vraiment pas la psychologie qui se cache derrière cette question… une meilleure question à vous poser serait celle-ci: «Que dois-je perdre en publiant ce logiciel?

Même si votre projet est plein d'odeurs de code, devez-vous perdre quelque chose?

Même si le code est affreux et que quelqu'un prend le temps de vous écrire un courrier à la flamme, devinez quoi, il a probablement utilisé votre logiciel assez pour vouloir y apporter des modifications et l'améliorer.

Vous devriez être heureux à ce sujet! Acceptez les critiques et améliorez votre code, demandez au gars en colère qui a pris le temps de vous écrire. Il se soucie!

Après un certain temps, les mails flammes cesseront, les gens continueront à utiliser votre logiciel, vous aurez appris de vos erreurs et les lacunes dont vous ignoriez l'existence dans votre formation ne seront plus là.

Je préférerais de loin travailler avec quelqu'un qui est prêt à faire quelque chose, à admettre ses erreurs, à le réparer et à continuer, plutôt que quelqu'un qui ne veut rien faire.

Si vous n'êtes pas vraiment à l'aise de publier le logiciel sous votre nom, libérez-le sous un pseudo. Si cela réussit, revendiquez-le comme étant le vôtre, sinon changez votre pseudo :)

Je suis un partisan convaincu non seulement de l'open source, mais également du développement ouvert , où les gens peuvent voir l'évolution complète de votre code. Du prototype aux codes de cheveux au code de travail ... vous ne devriez jamais être embarrassé. Vous vous en sortez - cela prend du courage. Le posséder et en être fier. Personne n'est parfait.

Plus je suis dans ce jeu depuis longtemps, plus je réalise que la seule mesure de la qualité du code est l’expérience client. Si vous écrivez une fonction, c'est l'appelant de cette fonction. Une bibliothèque? Les développeurs qui écrivent pour cette bibliothèque. Un cadre? Les adoptants de celui-ci. Un autonome? La personne ou le démon qui lance le programme.

Le bon code a sa vertu, ne vous méprenez pas, mais quand il est dit et fait, la seule mesure est "ça marche?" J'ai vu beaucoup de code propre qui est un gâchis buggy, et beaucoup de code sataniquement dérangé qui est complètement fiable (plus bon propre et mauvais moche aussi :))

Donc, si les critiques disent que votre code est laid, peu importe. S'ils disent que cela ne fonctionne pas - c'est la critique utile (données de test!) Que vous cherchez à améliorer votre programme. Accrochez-vous, évitez la population de trolls d'Internet et amusez-vous sur votre projet!

Je suis tout à fait d’accord avec ce que d’autres affiches ont dit: Même si votre code est de mauvaise qualité et n’est pas de grande qualité, la plupart des gens ne s’en soucient tout simplement pas. Tous ceux qui ont plongé dans le code OpenSource à un moment ou à un autre ont pu se dire: "WTF s'est passé ici".

Mais je ne connais personne qui ait la motivation nécessaire pour critiquer le code d'un projet simplement pour dire "mec, ton code est affreux!". Nous sommes tous passés par là et nous savons tous que tout code que nous écrivons en ce moment nous semblera plutôt boiteux en seulement quelques timbres (le mien le fera certainement).

Donc, ne vous inquiétez pas trop - les gens ont tout simplement mieux à faire pendant leur temps libre que de croquer le code des projets OpenSource.

Le code réel est toujours en décomposition et sale, giflé et maintenu de manière approximative. Le nettoyage se limite à la documentation des cas spéciaux et des constantes spéciales. Il existe un décalage d'impédance entre le code propre et le monde réel.

J'ai également remarqué que tout ingénieur compétent peut déchirer le code de quelqu'un d'autre.

Si (1) il réussit les tests et réalise le but sans échec ET (2) vous pouvez effectuer des modifications mineures avec seulement une réécriture mineure, c'est un bon code.

Quelques mots sages de Reid Hoffman, co-fondateur de LinkedIn:

"Si vous n'êtes pas gêné par votre première version de produit, vous l'avez publié trop tard."

"S'engager auprès des membres et voir ce qui est réellement important est une étape essentielle ... Ainsi, vous obtenez le produit minimum viable dès que vous le pouvez."

Je pense que cela s'applique particulièrement aux projets open source où avoir une bonne idée avec un début prometteur encourage les gens à contribuer et à participer. Quelque chose de si raffiné qui fait que vous portez vos lunettes de soleil n’évoque peut-être pas de tels sentiments. Mais le plus important dans la publication anticipée est de briser toutes vos idées préconçues sur ce qui devrait être fait et de commencer à aller dans la bonne direction.

Qui êtes vous? Êtes-vous quelqu'un que les gens connaissent comme le programmeur de Dieu et craignez que votre réputation ne se détériore? Êtes-vous celui qui va postuler à l'emploi et qui craint que l'employeur lise ces critiques et pense que vous êtes un mauvais programmeur? Ce que je demande, c'est pourquoi avez-vous peur des critiques sur la façon dont vous vous trompez? Vous décidez quels sont les commentaires authentiques et quels sont les diatribes. Prenez les bons comme des défauts et corrigez-les dans la prochaine version. Je sens simplement que vous vous inquiétez inutile de la critique. Vous aidez la communauté open source, qui est en soi une très bonne cause. S'il vous plaît continuez votre bon travail.

Si vous êtes réellement inquiet, utilisez simplement un pseudonyme en ligne lorsque vous publiez le logiciel. Dans ce cas, il n’y aura aucun impact sur votre réputation réelle.

Quand / si vous recevez des critiques publiques, cela conduira à des améliorations du code et vous aidera à vous développer en tant que développeur. C'est une bonne chose.

Je trouve que, pour mes projets, les critiques / suggestions les plus constructives sont envoyées à titre privé plutôt que diffusées publiquement, et même dans ce cas, il est peu probable que vous receviez un flot de commentaires. Par conséquent, je recommande de simplement y aller!

Bonne chance.

Il n'y a rien de mal à l'auto-étude en soi. Vous ne pouvez pas être isolé et les examens de code effectués par les pairs peuvent vous aider.

Vous devez également vous concentrer sur ce que vous faites. Pourquoi vous inquiétez-vous si vous recevez des commentaires négatifs sur votre travail? Si c'est parce que vous faites l'hypothèse que si vous recevez des critiques, c'est parce que le code est mauvais ou que vous n'êtes pas un bon programmeur, cela peut être vrai ou non.

Le but de l’effort est de s’assurer que le code fonctionne et d’obtenir le meilleur code possible, mais l’expérience pratique montre que tous les codes commerciaux ne sont pas stellaires. Parfois, vous avez de mauvaises exigences, parfois vous n'avez pas le temps de le faire correctement. Parfois, les développeurs veulent apparaître comme un génie en faisant en sorte que les autres aient l’air mauvais.

Je ne crois pas que l'on puisse apprendre sans commettre des erreurs, surtout si c'est quelque chose qui demande de la discipline et des efforts. Si c'était facile, tout le monde le ferait. Essayez simplement de limiter les erreurs à des erreurs mineures, en utilisant les meilleures pratiques établies. Je réalise que ce n'est pas toujours possible!

Si je m'inquiétais de ce que les autres pensaient de moi en tant que programmeur, je ne serais pas allé sur le terrain au départ. Cela étant dit, ma première critique du code est d’essayer de le prendre de manière objective et d’en tirer des enseignements.