Lanzar un proyecto de código abierto sin avergonzarse [cerrado]

He estado trabajando solo en un proyecto de código abierto bastante grande durante bastante tiempo y se está acercando al punto donde me gustaría lanzarlo. Sin embargo, soy autodidacta y realmente no conozco a nadie que pueda revisar adecuadamente mi proyecto.

Hace unos años, publiqué un pequeño fragmento de código que prácticamente se rompió (en un sentido crítico) en el foro donde lo publiqué. Aunque el código funcionó, la crítica fue precisa pero brutal. Me impulsó a comenzar a buscar las mejores prácticas para todo y, al final, creo que me hizo un desarrollador mucho mejor. He revisado todo en mi proyecto tantas veces tratando de hacerlo perfecto que he perdido la cuenta.

Creo en mi proyecto y creo que tiene el potencial de ayudar a mucha gente y siento que he hecho algunas cosas interesantes de manera interesante con él. Aún así, como soy autodidacta, no puedo evitar preguntarme qué brechas existen en mi autoeducación. La forma en que se rompió mi código la última vez no es algo que me gustaría repetir. Creo que mis dos mayores temores al lanzar mi proyecto en el que he invertido innumerables horas están completamente avergonzados porque me perdí algunas cosas evidentemente obvias debido a mi autoeducación o, lo que es peor, lanzarlo al sonido de los grillos.

¿Hay alguien que haya estado en una situación similar? No le tengo miedo a la crítica constructiva, siempre que sea constructiva y no solo una queja sobre cómo me equivoqué. Sé que hay un sitio de revisión de código en StackExchange, pero en realidad no está configurado para proyectos grandes y no creo que la comunidad sea lo suficientemente grande como para obtener buenos comentarios si publicara partes de mi proyecto por partes (yo intentado con un archivo). ¿Qué puedo hacer para darle a mi proyecto al menos una medida de éxito sin avergonzarme o ser devastado en el proceso?

A menos que el proyecto esté dirigido a desarrolladores (por ejemplo: un marco de desarrollo, en cuyo caso DESEA que lo critiquen si le hace aprender aún más), no debe preocuparse. Pero incluso entonces, hay muchos proyectos de código abierto destinados a desarrolladores que son basura, pero la gente los ama porque van al punto (piense en Codeigniter, que está muy mal diseñado, y sin embargo es el marco de php más popular)

Si se trata de una aplicación para humanos normales, probablemente solo se preocuparán por los resultados.

Tu código tiene problemas. También el mio. ¿Alguien más responde esta pregunta? Su código también tiene problemas.

A menos que sea, digamos, 10 líneas o menos, es defectuoso. Quizás trágicamente así.

Ser un desarrollador es CONSTANTEMENTE mezclarse contra los límites de sus habilidades y comprensión. Puede que no sea así para TODOS los desarrolladores, pero para mí y para los que conozco, trabajamos casi al límite de nuestra competencia en todo momento. Y lo enfrentas una y otra vez, luego pasas un buen fin de semana, luego regresas el lunes y lo haces una y otra y otra vez.

Después de haber trabajado esa vida durante 15 años, lo que he decidido es este hecho: no eres tu código . Usted ESCRIBE el código. El juicio del código NO es juicio tuyo . Su código tiene problemas, algunos los conoce y otros no. Tener eso atraído a su atención lo ayuda , a menos que todo lo que pueda hacer al respecto sea sentirse mal. Sentirse mal no mejora su código, solo lo hace sentir mal.

Escribes tu código, y lo escribes tan bien como sabes. Quizás mañana sabrás más de lo que sabías hoy, pero hoy lo hiciste tan bien como sabías. Mi consejo es: escriba el código de hoy hoy y el código de mañana mañana. Entonces tenga un buen fin de semana y regrese el lunes para escribir el código del lunes.

Como regla general, los programas de código abierto tienen tres grupos de personas que miran el código fuente.

1. Las personas que están considerando modificar el código para que el programa funcione de manera ligeramente diferente para ellos, para portarlo a una plataforma diferente o como un punto de partida para sus propios programas. Si no les gusta el código, generalmente no lo usarán, y nunca más tendrán noticias suyas.
2. Estudiantes, tratando de aprender a codificar en el idioma que usaste. Casi nunca se pondrán en contacto con usted, pero ocasionalmente puede recibir un correo electrónico preguntándole por qué hizo algo de una manera u otra. (Para ser justos, en realidad no he recibido uno de estos correos electrónicos en muchos años. Creo que los sitios web como StackExchange pueden haber reemplazado esta interacción)
3. Los investigadores de seguridad, como los muchachos de OpenBSD, intentan decidir si su herramienta es lo suficientemente segura como para ser incluida en su distribución. Si no es así, pero todavía quieren incluir su programa, se pondrán en contacto para encontrar una manera de asegurarlo. (Y si su programa se vuelve popular, imagino que probablemente también atraerá a investigadores de sombrero negro, que no se pondrán en contacto con usted sin importar lo que encuentren).

En el mundo real, la gente realmente no leerá su código fuente por ningún otro motivo que estos, porque simplemente no es necesario. Solo recibió un volumen de comentarios de este tipo antes porque publicó el código en un foro, lo que implicaba que deseaba recibir comentarios sobre el código.

No creo que realmente deba preocuparse por un torrente de abusos; las únicas personas que probablemente se pondrán en contacto con usted son las personas que desean agregar funciones o corregir errores, que ya han navegado por la base de código y no han corrido gritando por las colinas. ;)

Realmente no entiendo la psicología detrás de esta pregunta ... una mejor pregunta para hacerse sería "¿qué tengo que perder al lanzar este software"?

Incluso si su proyecto está lleno de olores de código, ¿tiene que perder algo?

Incluso si el código es horrible y alguien se toma el tiempo para escribirle un mensaje de error, adivine qué, probablemente utilizó su software lo suficiente como para querer hacerle algunos cambios y mejorarlo.

¡Deberías estar feliz por eso! Acepta las críticas y mejora tu código, pregúntale al tipo enojado que se tomó el tiempo de escribirte. ¡A él le importa!

Después de un tiempo, los correos electrónicos se detendrán, las personas seguirán usando su software, habrá aprendido de sus errores y las brechas que no sabía que existían en su educación ya no estarán allí.

Prefiero trabajar con alguien que esté dispuesto a hacer algo, admitir sus errores, corregirlos y seguir adelante que alguien que no está dispuesto a hacer nada.

Si realmente no se siente cómodo lanzando el software con su nombre, libérelo con un apodo. Si tiene éxito, reclámalo como tuyo, si no, cambia tu apodo :)

Creo firmemente no solo en el código abierto, sino también en el desarrollo abierto , donde las personas pueden ver la evolución completa de su código. Desde el prototipo con cerebro hasta el código de trabajo ... nunca debería avergonzarse. Te estás exponiendo, eso requiere agallas. Poseerlo y estar orgulloso de ello. Nadie es perfecto.

Cuanto más tiempo he estado en este juego, más me he dado cuenta de que la única medida de la calidad del código es la experiencia del cliente. Si está escribiendo una función, es la persona que llama de esa función. ¿Una biblioteca? Los desarrolladores que escriben para esa biblioteca. ¿Un marco? Los adoptantes de la misma. Un independiente? La persona o demonio que inicia el programa.

Un buen código tiene su virtud, no me malinterpreten, pero cuando se dice y se hace, la única medida es "¿Funciona?" He visto un montón de código limpio que es un desastre, y un montón de código satánico desordenado que es completamente confiable (además de buena limpieza y mala fea también :))

Entonces, si los críticos dicen que su código es feo, a quién le importa. Si dicen que no funciona, esa es la crítica útil (¡prueba los datos!) Que buscas para mejorar tu programa. ¡Aguanta, evita la población de trolls de Internet y diviértete con tu proyecto!

Estoy totalmente de acuerdo con lo que han dicho otros carteles: incluso si su código es malo y no de alta calidad, a la mayoría de las personas simplemente no les importa. Todos los que se han sumergido en el código OpenSource en un momento u otro pueden haber pensado "WTF sucedió aquí".

Pero no conozco a nadie con la motivación para criticar la base de código de un proyecto solo por el simple hecho de decir "¡amigo, su código se ve horrible!". Todos hemos estado allí y todos sabemos que cualquier código que estemos escribiendo ahora parecerá bastante aburrido para nosotros en solo unos pocos errores (el mío definitivamente lo hará).

Así que no te preocupes tanto, la gente simplemente tiene mucho mejor que hacer en su tiempo libre que analizar el código de los proyectos OpenSource.

El código real siempre está podrido y sucio, unido y mantenido de manera aproximadamente ad hoc. La limpieza se limita a documentar casos especiales y constantes especiales. Hay una falta de coincidencia de impedancia entre el código limpio y el mundo real.

También he notado que cualquier ingeniero competente puede romper el código de otra persona.

Si (1) pasa las pruebas y logra el propósito sin fallar Y (2) puede hacer cambios menores con solo una reescritura menor, es un buen código.

Algunas palabras sabias de Reid Hoffman, cofundador de LinkedIn:

"Si no está avergonzado por el lanzamiento de su primer producto, lo ha lanzado demasiado tarde".

"Lograr la participación de los miembros y ver qué es realmente importante es completamente clave ... Así que obtienes el producto mínimo viable tan pronto como puedas".

Creo que esto se aplica especialmente a proyectos de código abierto donde tener una gran idea con un comienzo prometedor alienta a las personas a contribuir y participar. Es posible que algo tan pulido que te ponga las gafas de sol no evoque tales sentimientos. Pero lo más importante sobre la liberación temprana es destruir todas sus ideas preconcebidas sobre lo que debe hacerse y comenzar a moverse en la dirección correcta.

¿Quién eres tú? ¿Eres alguien a quien la gente conoce como el programador de Dios y te preocupa que tu reputación disminuya? ¿Es usted quien va a solicitar el trabajo y le preocupa que el empleador pueda leer estas críticas y piense que es un mal programador? Lo que pregunto es por qué tienes miedo de las críticas sobre cómo te equivocas. Puedes decidir cuáles son los comentarios genuinos y cuáles son los discursos. Tome los buenos como defectos y corríjalos en la próxima versión. Solo siento que te preocupas innecesariamente por las críticas. Estás ayudando a la comunidad de código abierto, eso en sí mismo es una muy buena causa. Por favor sigan con el buen trabajo.

Si está realmente preocupado, simplemente use un seudónimo en línea al lanzar el software. Entonces no hay forma de que afecte su reputación en la vida real.

Cuando / si recibe críticas públicas, eso conducirá a mejoras en el código y lo ayudará a crecer como desarrollador. Esa es una buena cosa.

Creo que para mis proyectos, las críticas / sugerencias más constructivas se envían de forma privada en lugar de transmitirse públicamente, e incluso entonces es poco probable que reciba una avalancha de comentarios. Por lo tanto, te recomiendo que lo hagas.

Buena suerte.

No hay nada de malo en el autoestudio en sí mismo. No puede aislarse y las revisiones de código de pares pueden ayudar con eso.

También debe concentrarse en lo que está haciendo. ¿Por qué te importa si recibes comentarios negativos sobre tu trabajo? Si es porque estás asumiendo que si recibes críticas es porque el código es malo o no eres bueno para programar, eso puede o no ser cierto.

El propósito del esfuerzo es asegurar que el código funcione y obtener el mejor código posible, pero desde la experiencia práctica, tampoco todo el código comercial es estelar. A veces tienes malos requisitos, a veces no tienes tiempo para hacerlo bien. A veces los desarrolladores quieren parecer genios haciendo que otros se vean mal.

No creo que puedas aprender sin cometer algunos errores, especialmente si es algo que requiere disciplina y esfuerzo reales. Si fuera fácil, todos lo estarían haciendo. Solo trate de limitar los errores a los menores, utilizando las mejores prácticas establecidas. ¡Me doy cuenta de que eso no siempre es posible!

Si me preocupara lo que otros pensaran de mí como programador, no habría ido al campo en primer lugar. Dicho esto, mi primer comentario sobre las críticas al código es, tratar de tomarlo objetivamente y aprender de él.