¿Cómo reaccionaría si alguien le dijera que su código es un desastre?

La verdad es que probablemente en 2 años cuando vea su código actual, estará de acuerdo en que fue un desastre. Aprender a programar es un proceso que nunca termina y siempre habrá alguien que sea mejor que tú.

Entonces, si la persona que dijo que su código es un desastre no solo es mala y no es otro caso de "yo lo haría mejor" enfermedad común entre los programadores, debería preguntarle qué es exactamente lo que está mal con su código y ¿Cómo puedes mejorarlo?

No te sientas orgulloso de lo bien que codificas. Siéntete orgulloso de lo bien que aprendes. Luego, saber que su código necesita mejoras le brinda la oportunidad de demostrar lo bueno que es aprendiendo, en lugar de parecer una crítica de lo mal que es un programador.

Lea enlace si no tiene idea de lo que estoy hablando.

Después de más de 20 años, sé que parte de mi propio código sigue siendo un desastre. Todo se reduce a tomar una decisión entre escribir el mejor código posible y escribir lo que se requiere para hacer el trabajo. Hacer el trabajo dentro de un período de tiempo acordado supera la búsqueda interminable de la perfección técnica cualquier día.

El truco es aprender a aceptarlo. Aprende a aceptar que podrías hacerlo mejor. Aprende a vivir con los defectos. Aprenda a aceptar que no lo va a conseguir perfecto esta vez, y probablemente también la próxima, y que es una elección deliberada porque la alternativa no es ofrecer. Y eso es peor.

Descargo de responsabilidad: nada de esto debe leerse como "el código incorrecto está bien".

El código de todos es un desastre y no hay buenos programadores.

Hay:

• programadores que se envían rápidamente,
• programadores que siempre envían código semánticamente correcto,
• programadores que siempre encuentran la solución óptima y el algoritmo más rápido,
• programadores cuyo código es fácil a la vista.

Casi nunca terminan siendo la misma persona.

Y hay programadores de Butthurt que necesitan crecer y:

• pregunte qué está mal,
• no haga comentarios personalmente, como medida de su valor como ser humano;
• tenga en cuenta que hay pautas de sintaxis en los equipos, y que deben seguirse, y que son arbitrarias, por lo que no deben discutirse ad nauseam , ya que no hay una solución óptima, ni una palabra final;
• mejorar su comentario de su código;
• mejora en comentar su código; (sic)
• encuentre soluciones más fáciles de depurar, menos inteligentes, para tareas simples y mundanas;
• tome una clase en SQL
  (enviaría a la mitad de la población de este mundo a tomar una clase en SQL, solo para estar en el lado seguro)

No es arte, es un oficio.
Damos por sentado que eres inteligente: estás programando computadoras, maldita sea.
Aún así, AMD64 y x86 no están obligados por el poder de tu prosa. Mantener las cosas simples.

Bueno, una persona que dice que tu código es un desastre no es constructivo, incluso si tienen razón. ¿Te dieron razones por las que es un desastre? Al igual que, los métodos son demasiado largos, las responsabilidades se mezclan, la bifurcación, etc. Sinceramente, cualquier código que escribí hace un año, diría que es una mierda completa porque he aprendido mucho desde entonces. Así que no te sientas mal por eso. Me preocuparía más si todavía te gustara leer el código que escribiste hace mucho tiempo.

Cuanto más limpia sea su base de código, menos tiempo pasará luchando contra la base de código para resolver un problema dado. Un año es un gran punto para estar porque puede sentir los dolores de cualquier decisión de diseño que haya tomado anteriormente en el proyecto.

En mi proyecto actual, lo hemos refaccionado varias veces a medida que nos sentimos más cómodos con nuestra pila de tecnología. Esto debe ser alentado y debe tomar nota de las tareas que llevan más tiempo del que deben debido a la base de código actual.

¿Ha revisado algunas de las partes más antiguas del código que escribió? Probablemente puedas ver cosas que querrías hacer de manera diferente ahora o refactorizar.

También cuando mencionas la falta de pruebas, esto siempre es algo a lo que hay que mirar. En nuestro proyecto no tuvimos pruebas automatizadas y, como resultado, muchos códigos altamente acoplados. Incluso si no escribe pruebas de unidad / integración / lo que sea con regularidad, hacerlo durante un tiempo le dará la costumbre de hacer que su código sea más modular (y, en consecuencia, menos complicado).

  

Me siento tan triste y herida. Realmente me encanta programar y hacer que digan   Algo así me duele mucho. Tengo muchas ganas de superarme.

Eso es bueno. Eso es un lote mejor que tener una reacción como "mi crítico no tiene idea de lo que está hablando", "mi crítico es demasiado exigente" o simplemente "mi crítico no me quiere" e ignorarlo ellos. Esta actitud es algo bueno.

  

Pero parece que no soy un genio programador como en las películas.

No estoy seguro de qué tipo de películas ves, pero el 90% de los programadores en las películas son tan falsos que tengo lágrimas al final de la secuencia.

  

¿Me puede dar consejos sobre cómo mejorar?

Lee y practica. Consulte libros como Code Complete o El programador pragmático . Busque en Amazon para libros similares.

  

¿Alguna vez ha experimentado algo que critica su código y se siente   realmente lastimado ¿Qué haces en esos eventos?

¿Por qué te sientes herido? Me siento decepcionado conmigo mismo por ser un imbécil en primer lugar. Utilizo esa motivación para limpiar mi código y me aseguro de no volver a cometer el mismo error . Lo último que yo quiero hacer es no aprender de ello. Te han dejado una vez, no dejes que vuelva a suceder por la misma razón.

Ningún programador nace perfecto, ni siquiera cerca. Cuanto más código escriba, más revisiones obtendrá y las que proporcione proporcione , lo convertirá en un mejor programador.

Una de las mejores cosas para mí acerca de ser un desarrollador es que cada día es un proceso de aprendizaje. Siempre habrá alguien ahí fuera que no sepa algo que tú haces, y siempre habrá alguien que sabe algo que tú no sabes. Ciertamente, no me consideraría en ningún otro lugar que no sea el nivel de ingreso / junior, pero aprecio cualquier crítica que pueda recibir siempre y cuando esté justificada y se dé con respeto.

Una analogía que podría ser adecuada se relaciona con un período de tiempo en el que fui tutor de escritura en una universidad, así como cuando participé en cursos de escritura creativa. Escribir código, para todos los efectos, es como escribir un poema, un ensayo, un cuento o una novela. Cada individuo tiene su propia manera de hacerlo, pero al mismo tiempo, incluso los mejores escritores (o, en este caso, los desarrolladores) cometen errores o dejan que las cosas se deslicen. A menudo podemos dejar de notar estas cosas porque nos acostumbramos tanto a nuestra propia voz (o, de nuevo, en este caso, al estilo de código).

Al igual que en cualquier campo, hay quienes se consideran expertos. Si esa gente no existiera, no tendríamos a nadie de quien aprender. Suponiendo que este individuo en cuestión es realmente un experto, escucharía lo que dice y le preguntaría qué sugeriría que hiciera para mejorar su código. Sin embargo, nunca olvide que él no es el único que puede brindar su ayuda; Tenemos la suerte de que existe una gran cantidad de recursos como SE / SO.

El desorden es bastante subjetivo. Lo mejor que puedes hacer es preguntarle a esa persona (o al informe de revisión): ¿por qué está desordenado? (desde su punto de vista)

Están obligados a responderle y usted podrá:

• Argumento en contra de esto (si tiene una buena razón para hacerlo, por supuesto)
• Siéntase muy feliz, porque acaba de aprender algo nuevo y su código futuro seguramente será más asombroso, ya que ahora sabe cómo hacerlo menos desordenado gracias a sus consejos.

El hecho de que estés preocupado es una buena señal. Vamos a empezar con eso. Usted menciona que le encanta programar, pero ¿le encanta ser un programador profesional? Hay una gran diferencia entre un entusiasta y un profesional. Como profesional, usted estará bajo un escrutinio constante de su producto de trabajo.

Our team is composed of 5 programmers, and 4 of us are new

El hecho de que hayas trabajado dos años sin ningún tipo de confrontación me dice que estás trabajando en un trabajo muy relajado, lo cual no es tan bueno si realmente quieres avanzar como profesional. Eso sí, algunos de los mejores programadores del mundo trabajan para la base de Linux y pueden estar seguros de que no reciben un trato amable cuando cometen errores marginales ... y mucho menos 'código desordenado'.

Para una revisión rápida de algunas pautas de codificación bastante estándar, Estándares de Contribuyentes de la Comunidad Linux debe darle una idea del nivel de responsabilidad que debe aspirar para su producto. Consulte OBTENER EL CÓDIGO DERECHO.

Para promover esa afirmación, debe aprender a adoptar la revisión, ya que la mayoría del software bueno se revisa a fondo. Esto es compatible con Ley de Linus que indica ...

  

"Si hay suficientes revisores, todos los problemas son fáciles de resolver".

Personalmente, he visto a desarrolladores altamente capacitados, responsables y confiables obtener el hacha por algo tan simple como olvidarse de dejar comentarios ... así que si alguien te dice tus códigos a lío entonces probablemente es ... Supéralo ... Refactorizando. Es parte del concierto.

I feel so sad and hurt. 

Vaya a hacer una aplicación de tristeza para evaluar qué tan molesto se siente cuando no se aplica.

  

Has respondido a tu problema ... ¡No pruebas!

Después de ver un comentario que hiciste indicando que eres un desarrollador de Java, casi me enojé. Entonces, si lo entiendo correctamente, dice que usted y su equipo de desarrollo están trabajando en una tienda java y no tienen un marco de prueba para sus aplicaciones ...

  

Ahí está el problema

     

"Implementamos nuestro programa en el programa sin realizar pruebas exhaustivas".

Cribbing UML Creator Grady Booch ...

  

El ingeniero de software amateur está siempre en busca de magia,   algún método sensacional o herramienta cuya aplicación promete   Procesamiento de software trivial. Es la marca del   ingeniero de software profesional para saber que no hay tal panacea   existe.

Alistair Cockburn proporciona una gran cantidad de información en su sitio sobre el uso de metodologías ágiles para aumentar el rendimiento y la calidad para usted y su equipo.

Uno de los aspectos más importantes de la programación {y la vida} es conocer tus fortalezas y debilidades. Si no trabajas en tus debilidades, no tendrás un conjunto de habilidades completo.

Outro ... Estás bien, pero no te quejes. Avanza en el desarrollo de tu oficio y deja que tu pasión por la programación te mantenga en movimiento. Buena suerte :-)

No permita que sus emociones se interpongan en el camino de mejorar su código. El objetivo de una revisión de código es encontrar problemas, por lo que no debería sorprenderse si hay algunos. Dicho esto, tampoco se supone que sean una sesión de codificación de codificadores.

También no deberían simplemente estar diciendo 'Ewwww' y dejarlo así. Siempre hay una razón por la que algo está mal en la programación. Por ejemplo, está mal dejar un montón de código comentado en todo el lugar, pero está mal porque agobia el código y hace que sea más difícil de leer, no porque alguien lo haya dicho en un libro.

Tu código no eres tú. Recuérdalo.

Voy a ser la polla aquí y aconsejaré sobre la base de ... bueno, lo obvio. Obviamente, tu código ES un desastre o la pregunta que harías es "¿POR QUÉ alguien dice que mi código es un desastre?" Pero no estás desafiando la suposición. Simplemente estás actuando mal y, francamente, podría haber llanto, pero no hay sensación cuando se trata de justificar la programación.

Pero realmente, ¿por qué lo preguntas? Sabes que tu código apesta o estarías haciendo una pregunta diferente. Si alguien me dijera mi código web de back-end apestaba, me reiría y diría "está bien, ¿qué tiene de malo?" Si me dijeran mi apestoso de JavaScript, les daría al programador social el equivalente a un labio gordo y nunca pediría consejos sobre cómo reaccionar porque las perritas están claramente mal. @ # $ Ing.

Ser dueño de lo que eres bueno. Y realmente me refiero a asumir la responsabilidad por ello. porque solo hace falta una tontería por algún imbécil para adivinar. No pidas permiso para ser bueno. Sólo sé tus cosas. El fin.

Recuerda esto: ¡El peor código que verás es el tuyo!

Jeff Atwood de codinghorror.com escribió mucho sobre el tema, es posible que desee comenzar aquí: enlace

Si quieres mejorar, comienza a leer cosas sobre el estilo de codificación, los patrones, los flujos de trabajo, básicamente todo lo que puedas entender. También aprender más lenguajes de programación, ver cómo hacen las cosas. Si estás haciendo OOP, lee esto: enlace

También hable con otros programadores y haga programación de pares o vea el código de otros.

Cometer errores es inevitable, repetirlos es.

La mayoría de las veces debes decir "Gracias" a la persona que te dijo esto.

Lo más probable es que se preocupen por su profesión, se preocupen por su trabajo, se preocupen por su equipo y se preocupen por usted.

Puede ser difícil tomar críticas. No te enojes por eso. Piense en lo que están tratando de decirle y no permita que sus emociones lo superen.

He estado programando por mucho tiempo (30 años) y mi estilo y código están mejorando todo el tiempo (espero). La única forma en que sé que está mejorando es cuando otras personas me lo dicen o si vuelvo y reviso mi código.

Intenta mirar el código que escribiste al comienzo de tu carrera. ¿Qué te parece ahora? ¿Se ve tan bien como pensabas cuando lo escribiste?)

En primer lugar, debe comprender que la programación es un proceso iterativo, al igual que escribir un artículo o un libro. Primero, escribe un "borrador" de tu programa, solo para que funcione. En esta etapa, su código será un desastre. Así que refactorizas para hacer el código limpio. Luego haces un perfil y ves lo que necesitas optimizar para hacerlo rápido. El truco es refactorizar continuamente, de lo contrario el desorden crecerá. Debe limpiar su código regularmente, al igual que tiene que limpiar su casa.

Las revisiones de código son absolutamente esenciales. Debe hacer que su código sea examinado por al menos otro par de ojos. Cuando pasas incontables horas mirando tu código, te acostumbras a él y fácilmente puedes pasar por alto un olor o un olor de código que tu compañero de trabajo podría notar al instante.

Además, el hecho de explicar su código a otra persona es una excelente manera de ver si se ha perdido algo. Esto es como leer un papel que estás escribiendo en voz alta. Su cerebro procesa información de audio y visual de diferentes maneras, y puede encontrar fallas en su razonamiento al cambiar de modalidad. Además, si le explica su código a un compañero de trabajo, y algo no tiene sentido para ella, es una buena indicación de que debe refactorizar su código.

Al hacer una revisión del código es muy importante que tanto el autor como el revisor revisen sus egos en la puerta. El objetivo es mejorar el código. Así que el revisor debe ser respetuoso, y el autor debe mantener una mente abierta. Recuerde, sus compañeros de trabajo son quienes deberán mantener su código, por lo que debe ser claro para ellos. Si el revisor no entiende lo que hace una variable, cámbiele el nombre. Si el revisor no puede entender lo que hace un bloque de código, refactorícelo en una función con un nombre descriptivo. Independientemente de lo que pueda pensar, si sus compañeros de trabajo no pueden entender su código, no es bueno.

Hablando de refactorización, absolutamente debe tener un marco de prueba de unidad, porque sin él, no puede refactorizar.

Finalmente, recomiendo encarecidamente leer "Código limpio" de Robert C. Martin. Le dirá por qué su código es un desastre y qué puede hacer para limpiarlo.

  

¿Me puede dar consejos sobre cómo mejorar?

La respuesta de Jay que recomienda libros es buena, sin embargo, parece que ya estás en un punto de inflexión en el trabajo.

Pasado:

  

Nuestro equipo está compuesto por 5 programadores, y 4 de nosotros somos nuevos, 1 tiene más   de 3 años de experiencia. Hemos estado trabajando para un programa por casi un año.   año y nadie ha revisado mi código y me dieron una página para trabajar   con.

Presente:

  

Ahora está ajustado y necesitamos una aprobación y una revisión del código antes de realizar cambios en el código.

Parece que su empresa / equipo / departamento está aprendiendo como un todo, en términos de gestión de proyectos y equipos, así como de programación. Comenzar a revisar el código es una excelente oportunidad para mejorar en casi todas las áreas si se le presta la atención adecuada.

Usa esto como una oportunidad; Suponiendo que esté realizando revisiones por pares (con los otros desarrolladores de su equipo) sugiérales que este proceso es importante y que todos pueden aprender de él.

En la línea de base será una revisión rápida con el resultado "sí, se ve bien". Con un poco más de esfuerzo enfocado, puedes intercambiar ideas, "sí, eso funciona, pero podrías haberlo abordado de esta manera, lo que hubiera aclarado tu objetivo ...". Tome notas para el futuro, incluso si el código se considera correcto para implementar.

Si esto va a ser exitoso, necesita poner a su equipo y gerente de lado, lo que a menudo significa explicarles los beneficios. Para los otros desarrolladores esta es una oportunidad para aprender. Para su gerente, esta es la oportunidad de mejorar las habilidades del equipo a un bajo costo, por lo tanto, crear salidas a) con más valor o b) más rápido c) con menos costos de mantenimiento (¡generalmente un gran problema!).

Este es un cambio de cultura, que no puedes forzar solo, ¡pero puedes ayudar a mover las cosas en la dirección correcta!

No se olvide, este es un tipo de cambio cultural que puede ser enormemente beneficioso para las organizaciones; los buenos gerentes reconocerán que estás trabajando para mejorar a todo el equipo, algo que vale la pena recompensar.

  

¿Me pueden aconsejar sobre cómo ser mejor? ¿Alguna vez has experimentado algo que critica tu código y te sientes realmente herido? ¿Qué haces en esos eventos?

La respuesta a esto se puede encontrar en las compañías de nueva generación. He estado en compañías como Google y FaceBook y veo que si sigues el proceso de Agile / Scrum religiosamente, puedes escribir mejor código y mejorarlo en cada sprint.

How to be better? 

La respuesta es refactorización continua. Las herramientas de desarrollo modernas como Visual Studio tienen muchas herramientas que lo ayudan en este proceso. Si sigues el proceso de desarrollo del software Scrum y luego, por ejemplo, escribiste un código incorrecto en el ciclo de sprint 1 y alguien señaló que durante la revisión es malo, entonces en sprint 2 tienes la oportunidad de refactorizar el código.

Estos problemas están ocurriendo en primer lugar debido a la falta de un buen proceso. Entonces, la solución es crear un buen proceso de desarrollo de software para su equipo y practicar la refactorización continua.

Les agradecería la retroalimentación y luego les pediré que expliquen qué lo hace malo y cómo debería mejorarse.

Si está de acuerdo en que la persona que brinda los comentarios tiene sentido, considere realizar cambios en el futuro. Pero recuerda, solo porque alguien diga que no significa que sea verdad.

¿Puede dar ejemplos específicos de lo que se ha llamado "un lío"?

Primero, alguien que dice que tu código es un mess es muy vago y subjetivo. Puede significar diferentes cosas para diferentes personas. Este es el por qué; Hay dos cosas diferentes que deben ser consideradas.

Estructura

La estructura de su código se rige por el idioma, los estándares de la industria y los estándares de la compañía, por nombrar algunos. Obviamente, también hay otros factores.

Estos son los tipos de errores que las pelusas, herramientas de prueba y productos similares están diseñados para identificar. Están bien definidos y usted o sus herramientas pueden tomar decisiones objetivas en cuanto a su validez / corrección.

Style

A pesar de la estructura / reglas estandarizadas para el código, cada desarrollador tiene un cierto estilo en la forma en que escribe y aborda un problema o tarea. Realice el mantenimiento del código en cualquier entorno de equipo y, con el tiempo, podrá hacer una conjetura educada sobre quién escribió el código según el estilo. También desarrollarás tu propio estilo y cambiará a medida que ganes experiencia y aprendas tu oficio.

Entonces, cada vez que alguien diga que su código es un mess debe comprender si está hablando de la estructura o del estilo . Son dos cosas muy diferentes; la estructura es objetiva, mientras que el estilo es absolutamente subjetivo.

Dicho esto, cualquier comentario constructivo de otros programadores puede ser muy valioso para usted. Todo depende de ti y de cómo tomes las críticas. Con el tiempo, aprenderá la opinión de quién debe tomarse en serio y quién debe tomar un grano de sal.

A medida que avance en su carrera, volverá a mirar su propio código y verá cosas que podría hacer de manera diferente, mejor, más limpia y más rápida. Todo es parte del proceso de aprendizaje y ver tus propios errores pasados es una verdadera indicación de que estás perfeccionando y mejorando tu habilidad.

No dejes que un poco de crítica apague tu espíritu. Tome lo que pueda de él y si es significativo y valioso, agréguelo a su almacén de conocimientos.

Si bien es importante reconocer cuando su propio código es un desastre (una sensación muy típica entre los programadores, especialmente a medida que adquieren más experiencia y su código más antiguo) es incluso más importante para escuchar cuando otras personas te lo dicen.

Solo hay tantos problemas que puedes reconocer en tu propio código, ya que se produjo debido a las limitaciones de tus conocimientos actuales de programación.

La revisión del código es una oportunidad de aprendizaje esencial porque probablemente lo exponga a un conocimiento nuevo que no tenía mientras trabajaba en el código (de lo contrario, lo usaría y no habría problemas).

Creo que hay dos partes en el procesamiento de comentarios negativos.

1. Determine la naturaleza de los problemas planteados y lo que debe aprender de ellos

Cuando reviso o hago revisar mi código, ordeno la información sobre los problemas del código en aproximadamente tales grupos:

• viola los requisitos tecnológicos difíciles
  • llano incorrecto (no funciona ni cumple con los requisitos)
  • fallará en otras circunstancias (cambio de entorno / configuración)
  • utiliza una funcionalidad en desuso y se interrumpirá en un futuro previsible
• viola las mejores prácticas de la industria, careciendo de cosas como
  • utilizando un enfoque comprobado para un problema específico
  • rendimiento
  • compatibilidad con versiones anteriores
  • facilidad de mantenimiento
  • estilo de codificación
  • documentación
• viola las mejores prácticas en el lugar de trabajo
  • igual que la industria, pero más específico para la compañía / colegas y puede diferir de la industria en detalles
• no en línea con la experiencia personal
  • se puede mejorar de alguna manera, en opinión de la persona que revisa

Tenga en cuenta que esto va desde cosas muy objetivas ("se romperá cuando se implemente en nuestro servidor de producción") a cosas muy subjetivas ("No me gusta cómo nombró las variables").

2. Determine qué cambios (si los hay) se realizarán en el código como resultado de la revisión

Después de procesar la información, llega la decisión si es procesable y si se debe cambiar el código. Esta no es necesariamente su decisión, su opinión puede o no ser importante dependiendo de las partes involucradas y los detalles de su situación (antigüedad, etc.). Pero los posibles resultados son aproximadamente:

• problema de dirección completo
  • arreglo roto
  • formato al estilo de codificación requerido
  • y así sucesivamente
• llegar a un acuerdo si el problema se debe abordar en parte o en su totalidad, ya que puede haber
  • sin recursos (como tiempo o presupuesto)
  • no es necesario (solo logrará mejoras insignificantes, comprometerá la estabilidad, etc.)
• llegar a comprender que el problema planteado no es válido
  • los comentarios (especialmente de la categoría de opinión subjetiva) pueden ser absolutamente perjudiciales y no deben tomarse en cuenta ciegamente

Ha aprendido que es doloroso recibir una respuesta negativa y puede ser muy doloroso cada vez en el futuro. Sin embargo, ha aprendido cómo es una oportunidad de aprendizaje importante y cómo el proceso lo ayuda a mejorar profesionalmente y en su lugar de trabajo para lograr una mejor base de código.

Bueno, no te sientas roto. Eventualmente aprenderás de los errores. Una vez que hayas terminado con el tema, puedes hablar con un chico para que sienta que deseas mejorar. Intenta escuchar más y discutir menos.

He pasado por esta situación y puedo entender.

TL;DR

  

¿Cómo reaccionarías si alguien te dijera que tu código es un desastre?

Mi sencillo, "demasiado tiempo no se leyó (todas las respuestas: disculpas, espero que encuentre tiempo para más tarde y lo edite / corrija si es necesario)" respuesta / consejo:

• Buena vieja revisión por pares. Solicite diferentes equipos con diferentes mentalidades colectivas, niveles de experiencia y / o niveles de agresividad para revisar su código.
• Solo para elaborar un poco sobre lo que quiero decir con grupos "diferentes": la diáspora StackExchange es probablemente el grupo más profesional, estimado y apreciado debido a la dificultad relativa para convertirse en parte de él comparado con, digamos, Reddit. Reddit tiende a ser muy agresivo en los subreddits más populares, pero, por extraño que parezca, los subreddits de programación son bastante amigables (por lo que he experimentado).

Un buen ejemplo, quizás el mejor, del tipo agresivo, de mentalidad de pandillero, es la multitud de XDK Forums, y el peor de los peores trofeos entregados a CyanogenMod para los foros de Android / la población del canal IRC.

Eso fue un poco más largo de lo que pretendía; se suponía que mi punto de vista era: obtén revisiones variadas, pero concéntrate en obtener una crítica honesta de las personas que conocen su oficio, y en saber cuál es la crítica constructiva . Ah, y ser capaz de tomar cualquier forma de crítica sin dejar que esto te desanime. Regla general: si comienza a escuchar comentarios similares relacionados con algo que puede ser mutuo con respecto a los comentarios, realice una introspección más completa.