Cómo mejorar la calidad del código.

Answer 1

Hay muchos aspectos de la calidad del código que vale la pena mejorar.

Legibilidad

• Decisiones de diseño de documentos y algoritmos. Si su código está bien escrito, generalmente es fácil averiguar qué hace una sola función. Es menos fácil entender qué hacen las 15 funciones como grupo, cómo interactúan, etc. Los comentarios de alto nivel son críticos, ya que descubrirá si alguna vez deja de trabajar en un proyecto y luego vuelve a hacerlo 6 meses después.
• Haga que alguien codifique su trabajo. Idealmente, la persona es un desarrollador que admiras, pero casi cualquier desarrollador lo hará. Si alguien no puede entender partes de su código, eso es una bandera roja.
• Revise las revisiones de su código. Las revisiones de códigos son como los árboles en un bosque: es fácil abordar un comentario a la vez sin notar las tendencias generales. De vez en cuando, revise sus últimas 5 o 50 revisiones de códigos y vea si hay patrones. Si siempre se le recuerda que haga X, comience a hacer X antes de solicitar una revisión del código.
• Revisar el código de otras personas. Al igual que con muchas otras cosas, sus propios problemas son más difíciles de detectar que los problemas de otras personas. Mirar el trabajo de otros te ayuda a estar mejor sintonizado con cuáles prácticas funcionan bien y cuáles no. Lo bueno es que no tiene que hacer revisiones oficiales de código, solo encuentre un proyecto en GitHub y comience a buscar su fuente.
• Use nombres informativos para variables, métodos, clases, etc. Por ejemplo, use List clients en lugar de List .

Diseño

• Decisiones de diseño de documentos. (Sí, me doy cuenta de esto la segunda vez que lo digo). Es una sensación terrible cuando no recuerdas por qué diseñaste algo de la manera en que lo hiciste y, por paranoia, tienes miedo de cambiar el diseño. para el mejor. Además, a medida que establece un registro de sus decisiones, ocasionalmente puede revisar sus elecciones y ver cuáles resultaron bien y cuáles no.
• Refactorizar regularmente. De vez en cuando, simplemente elige un trozo de código con el que no estés satisfecho e intenta hacerlo mejor.
• Probar diferentes enfoques. Algunas personas prefieren pensar en un problema y hacer un montón de diseño por adelantado, a otras les gusta sumergirse y refactorizar a medida que avanzan. La calidad de su diseño podría mejorar simplemente probando el enfoque que no utilice actualmente.
• Lee algunos de los libros de diseño seminal. Específicamente, Refactoring by Fowler y Design Patterns by Gamma, et al. Piense en los ejemplos específicos, pero piense aún más en los principios generales. Por ejemplo, uno de los principios de conducción en los patrones de diseño es “identificar algo que cambia, luego encapsularlo”. Esa es una gran heurística que es útil para casi cualquier tarea de diseño.

Corrección y mantenimiento

• Escribir pruebas unitarias . En primer lugar, las pruebas revelan problemas de diseño. Si su código es difícil de probar, debe tratar de averiguar por qué, luego intente solucionar el problema. En segundo lugar, las pruebas te dan un arnés de seguridad para la experimentación, y la experimentación (y la práctica) son las que te hacen un mejor código. Es difícil jugar con diferentes diseños o diferentes implementaciones de algoritmos si tienes miedo de romper todo.
• Utilice herramientas de análisis de código, si es posible . Dependiendo del lenguaje de programación que esté utilizando, herramientas como Lint pueden analizar su código y señalar posibles errores o áreas problemáticas.
• Utilice un detector de copiar / pegar, como PMD . Cada vez que encuentre un bloque de código que se repita 3+ veces (o, idealmente, 2+ veces), intente eliminar la duplicación. Esta es una gran manera de practicar la refactorización.
• Desarrollar buenos hábitos de codificación. Con el tiempo, encontrará un conjunto de mejores prácticas que le gusten. Convierte esas prácticas en hábitos. Por ejemplo, pongo llaves alrededor de los cuerpos de las sentencias if y loops automáticamente, incluso si los cuerpos terminan siendo fragmentos de 1 línea. Otro ejemplo: cada vez que abro un archivo para leerlo, coloco el código en un bloque try / finally y cierro el archivo en la declaración finally. Cuando automáticamente haces lo correcto, tu código mejorará.

Rendimiento y escalabilidad

• No afine nada sin perfilarlo primero. El error de ajuste de rendimiento más común es pasar un día reescribiendo el código que consume una pequeña parte del tiempo total de ejecución. Si una solicitud web tarda 1 segundo en procesarse, no tiene sentido pasar un día tratando de acelerar una parte del flujo que toma 10 ms. Los ajustes de rendimiento a menudo hacen que el código sea más complejo, por lo que si realiza una sintonización prematura, la calidad del código se verá afectada.
• Lea historias sobre cómo otros resolvieron sus desafíos de escalamiento. http://highscalability.com es un buen recurso. Busca patrones. Por ejemplo, un patrón común es aislar diferentes partes de una arquitectura detrás de sus propias API, para que pueda escalar e implementar diferentes componentes de forma independiente. (Tenga en cuenta que esto recuerda al principio de patrones de diseño mencionado anteriormente).

Dos cosas finales para recordar: 1) La regla de las 10.000 horas no se trata de la práctica, sino de la práctica deliberada . Piensa en lo que estás haciendo, en lo que funciona y en lo que no. 2) Necesitas 10,000 horas para ser de clase mundial, pero solo necesitas una fracción de ese tiempo para llegar a ser muy bueno.

Answer 2

No sé cómo mejorar la calidad de su código en particular, porque no sé de qué manera su código es malo. Aquí hay algunos consejos generales:

1) Refactorización temprana y frecuente. No es inusual que reemplace todo el código de un proyecto todos los días durante los primeros días, y siempre hago un pase de refactorización después de un lanzamiento, cuando hay un poco de holgura.

2) Marque todos los códigos cuestionables. Elige una cadena de caracteres que nadie más usa. El mio es DIKEO. Póngalo en un comentario dondequiera que ponga un truco o una aproximación o cualquier cosa que no sea perfecta y canónica. Siempre que su cerebro se atasque, haga una búsqueda y limpie las cosas. Es terapeutico No use TODO o FIXME, porque la primera vez que coloque el código de otra persona en su proyecto, verá un billón de ellos.

3) Usar comentarios que prueben algoritmos. A la mayoría de las personas les lleva demasiado tiempo probar sus algoritmos, pero es una buena idea. No tienes que irte por completo, pero tienes comentarios como / * En este punto, foo debería ser 3 * /.

4) Poner en un mecanismo de error primero. No tiene que ser elegante, tal vez una función que simplemente imprime una cadena. De lo contrario, lo olvidará o tendrá un montón de printfs o algo que no podrá encontrar más tarde.

5) Poner siempre otra cosa. Si tiene un if, ponga un else, incluso si es un bloque en blanco, incluso si cree que nunca lo usará. Lo verás más adelante cuando trabajes en un error y dirás: “¡Oh, sí! Eso es todo”. ETA: Eso también significa siempre un valor predeterminado en un caso, a menos que sea una enumeración.

Answer 3

La programación es en última instancia un ejercicio de comunicación:

* Comunicarse a los mantenedores eventuales del código sobre la mejor manera de mejorarlo.
– Comenta cualquier cosa que tuvieras que derivar o aprender por ti mismo.
– Escribir mensajes de confirmación para archivar el proceso de desarrollo.
– Usar un estilo de código único
– Elegir nombres de identificadores significativos
– Organizar la estructura interna de forma que se agrupen bloques relacionados lógicamente.
– Eliminar la redundancia.

* Comunicando a los clientes de tu código cómo usarlo.
– Diseño de interfaces ortogonales.
– Arquitecto del proyecto como colección de módulos.
– Escribir un montón de pruebas unitarias y funcionales.
– Proporcionar mucha interfaz y documentación de mejores prácticas.

* Y (lo que es menos importante), comunicar una secuencia explícita de operaciones a la máquina que las ejecutará.
– Elegir algoritmos e implementaciones eficientes.
– Descomponer problemas complejos en subpartes más simples
– Reutilizar código en lugar de cortar y pegar errores potenciales

El mejor software se comunica claramente en las tres formas.

Y al igual que escribir un discurso o contar una historia, cuando escribes un código, estás
escribiéndolo para tu audiencia, no para ti mismo.

Pasar 10.000 horas escribiendo proyectos pequeños y desechables que solo utiliza usted solo le permitirá practicar la comunicación con la máquina.

En su lugar, pase 10.000 horas trabajando en un proyecto más grande que le exige a usted (e idealmente a otros desarrolladores) mantener su código desde hace mucho tiempo, donde olvidó lo que estaba pensando cuando lo escribió y donde sus usuarios solicitan nuevas funciones y aplicaciones que no tenía. originalmente considerado.

Si puede encontrar un proyecto activo de código abierto que coincida con sus intereses y tenga algunas características importantes que faltan, entonces participe y contribuya con las características usted mismo. Si no es así, inicie un proyecto usted mismo y una vez que crea que le es útil, póngalo en GitHub y anuncíelo a las comunidades que también podrían encontrarlo. Es probable que, al menos un par de otras personas lo harán.

Answer 4

Después de 40 años me hago esta misma pregunta todos los días.

Descargo de responsabilidad: no voy a dejarme atrapar por un flamígero en esta publicación. Solo publico mis creencias personales de una carrera de más de 40 años y nada más. Estoy seguro de que todos han tenido experiencias diferentes y todas son válidas. . Solo estoy expresando el mío a la OP.

Un poco acerca de dónde vengo: he trabajado en los campos de la aviación, adquisición de datos a alta velocidad (más de 5 millones de muestras por segundo), banca y finanzas y medios de comunicación … y, por lo tanto, mi respuesta se basa en esas experiencias … Francamente, no sé nada sobre 3D, animación e imágenes y otras grandes áreas de la actividad de programación, por lo que tal vez, o tal vez no, esta publicación ayude … Solo quería señalar que se necesitan diferentes habilidades para diferentes trabajos.

Esta es una pregunta tan amplia (pero importante) que creo que tiene que abordarse filosóficamente, así que aquí va para mí.

Primero, la mayoría de la programación es más una forma de arte que una actividad de ingeniería … Incluso la programación que admite dispositivos diseñados (como escribir controladores de E / S y firmware) debe considerarse más como un arte que como una ciencia … Esa es puramente mi opinión personal, y hay libros y organizaciones que pensarían que eso es indignante, pero es mi opinión. Por supuesto, hay una línea muy delgada entre el arte y la ingeniería, pero la ingeniería es más una disciplina de reproducibilidad científica, y el arte es más un proceso de creatividad. Hay mucho espacio para argumentar para expresar el acto de “programar computadoras” para que sea cualquiera de estos, pero ha sido mi experiencia personal que es más creativo que científico.

En segundo lugar, escribe tu código como si escribieras cualquier cosa que sea realmente importante … Cada línea significa algo que es de vital importancia. no es tan importante que su código sea perfecto, sino que sepa lo que hace cada línea en su código y lo que quería decir con esa línea.

Tercero, no escribas todo de una vez … escribe la primera y la más pequeña que haga algo útil, y construye a partir de eso … típicamente llamada la metodología de desarrollo “espiral”. Es la forma más rápida de progresar, especialmente con equipos pequeños.

Cuarto, use buenas herramientas … La mayoría de los IDE que existen hoy en día le permiten codificar más libremente que en el pasado … Las antiguas pautas de “notación húngara” de comenzar una variable con una “p” o “i” o lo que sea ahora son básicamente obsoleto … Solo al pasar sobre una variable en un IDE moderno, le diremos todo lo que necesita saber sobre el tipo, el alcance y la membresía; como programador, esto le permite estar más involucrado con los problemas que el código está resolviendo.

Quinto, escríbalo para que cualquiera pueda mantenerlo … usted querrá tomar vacaciones y mudarse a otros proyectos … así que si no puede describirlo a otra persona, usted no sabe lo suficiente sobre su propio código.

De todos modos, esas son mis sugerencias personales … funcionan para mí (a un nivel muy alto) y espero que funcionen para usted.

Answer 5

Mi mejor sugerencia sería comenzar poco a poco y mejorar.

La mejor manera que encontré para mejorar la calidad del código fue:

1.) Usar un IDE
Esto tendrá un efecto inmediato y evitará errores tontos.

2.) Pon a prueba tu código
Pruebas expuestas mal diseño. Expondrá rápidamente sus malas prácticas y comenzará a diseñar un mejor código. ¿Cómo reconocer el código malo?

3.) Obtenga su código revisado
Consiga que alguien más experimentado revise su código y lo discuta con ellos. Puede ser difícil a veces, pero es una de las maneras más rápidas de mejorar.

4.) Ponerse al día con SOLID (diseño orientado a objetos)
Aprende estos cinco principios y escribe todo tu código futuro siguiéndolos. Criterios de diseño

5.) Siga una guía de estilo de codificación
Mejorar la legibilidad y la consistencia de su código es una manera fácil de mejorar su calidad.

Answer 6

• Escribe el código que te gustaría leer más tarde y te sentirás orgulloso.
• Aprende nuevos métodos de resolución de problemas a diario. StackOverflow y libros como ‘Programming Pearls’ son excelentes recursos
• Lee un montón de código escrito por otras personas. ¡O introduce nuevas funciones en ese lenguaje / marco o puede emocionarte con un truco inteligente!
• Escribir pruebas, incluso para casos de borde. Te ayuda a refactorizar el código sin preocupaciones.
• Tener una noción de seguridad al escribir código. Un pequeño agujero que ignoramos intencionalmente puede causar grandes problemas en el futuro.
• Intenta escribir el código en pequeñas unidades independientes. Ayuda mientras refactoriza el futuro.
• Haga que un colega o un amigo revise su código y le dé sugerencias abiertas.
• Comparta los bits reutilizables que escribe, a menudo conduce a discusiones creativas.
• Utilice las mejores prácticas. Escuche buenos podcasts y participe en actividades de codificación social.
• Se trata de aprendizaje continuo. Creo que el deseo de mejorar la calidad del código mejora el código que escribimos

Answer 7

Bueno, intentaría responder esto a un nivel muy granular, ya que otros ya han respondido los aspectos de alto nivel de un buen código.

a) Hacer que el código fluya lo más obvio posible. Si tiene funciones con 10 declaraciones, ordénelas correctamente y mantenga los saltos de línea para que el flujo sea obvio.

Por ejemplo, leer un archivo puede ser:

// Sentencias para abrir un archivo y verificar si el puntero del archivo no es nulo

// Declaraciones para leer datos del archivo en un búfer.

// Declaraciones para cerrar el archivo.

b) Use nombres descriptivos para funciones y variables: tómese un tiempo para pensar acerca de los nombres que le da a las funciones y variables, intente usar nombres que proporcionen una buena pista sobre su posible uso y que no sean demasiado detallados. El truco es detenerse unos segundos y pensar en los nombres. ¿Son los mejores nombres que se te ocurren?

c) Cuando defina una función, asegúrese de entender el propósito de la función, ¿existe la necesidad de que exista tal función? Si es así, intente mantenerlo lo más desconectado posible del resto del código. Idealmente, una función debería ser una entidad independiente en la medida en que pueda sacarla y usarla en cualquier proyecto sin ninguna modificación (esto es difícil, pero no vale la pena hacer nada).

d) Además de (c), cada entidad debe tener el alcance mínimo posible; si define una función, ¿debe ser pública? ¿Puedes hacer eso privado? o si eso no es posible ¿puedes hacer eso protegido? ¿O puedes definir una función estática? Intente exponer lo menos posible a las interfaces externas de su código.
Si crees que algo puede ser requerido para ser público más tarde, hazlo más tarde, no ahora.

e) Re-factorear sin miedo. Si cree que un código actual se puede dividir en llamadas de funciones o flujos más simples y mejores, entonces siga adelante y hágalo, no tenga miedo de romper cosas. Pero haga una prueba adecuada para validar que no causa regresión.

f) Comentarios. Comenta lo más generosamente posible. No hay una regla que diga que no puedes escribir un gran comentario. Así que no sea codicioso con ellos, explique el propósito del flujo, las suposiciones que ha hecho y el algoritmo que ha utilizado lo más claramente posible.

g) Consistencia. Elija un estilo de codificación que le guste (llaves después de un espacio para if-else en la misma línea, o en la siguiente línea) y sea coherente con él en cada lugar, su código no debería tener ni un solo espacio adicional. Esto hace que su código sea hermoso y que todos amamos la belleza.

h) Manejar todos los casos de esquina. Debe asegurarse de que se manejen todos los posibles escenarios de error y, en ningún caso, puede haber un error que no sea manejado por su mecanismo de manejo de errores. Cada variable debe validarse independientemente del hecho de que la función que llama ya haya hecho eso (a menos que, por supuesto, exista una necesidad muy específica que deba ser comentada adecuadamente).

f) Por último, vuelva siempre al código que ha escrito, léalo nuevamente, simplemente mírelo durante un tiempo y vea si se omite alguno de los puntos anteriores, y si es así, refactorice y pula hasta que esté feliz de mirar algo hermosa en frente de ti

La programación es un arte más que una ciencia.

Answer 8

Mis sugerencias para aquellos que quieran mejorar sus habilidades de codificación:
1. Nunca deje de hacer la pregunta: “¿Cómo puedo mejorar mi código?”
2. Si uno piensa / sabe que algo es lento, llévelo a una clase / método de prueba, haga un bucle de la llamada y programe el tiempo. Experimenta para ver cómo se puede mejorar.
3. Haz lo menos repetitivo posible. Si existen dos o más bucles que pasan por los mismos elementos, reduzca y haga el trabajo en uno. Los bucles son el asesino del tiempo para la mayoría de las aplicaciones.
4. Las declaraciones de cambio, en la mayoría de los idiomas, son más rápidas que if / else if /….
5. Agrupar la funcionalidad tanto como sea posible. Esto ayudará con el mantenimiento.
6. Simplificar después de diseñar. Sobre la ingeniería matará el rendimiento tan rápido como sobre el bucle. Hay un equilibrio entre la abstracción y el rendimiento.
7. Si uno tiene los datos, páselos. La obtención de datos estáticos varias veces en el lapso de una transacción es un asesino del rendimiento.
8. Haz todo el trabajo adelantado que puedas. Un ejemplo sería “Una cadena” que se usa como un char [] en todas partes. Realice la conversión una vez, no cada vez que se utilice la matriz de caracteres de cadena.
9. Cada bit de CPU desperdiciada va hacia un rendimiento pobre. Si bien puede ser un ahorro de 10 ms o menos por transacción, 10,000,000 transacciones x 10ms es mucho tiempo.
10. Tómese el tiempo para realizar pequeñas mejoras a medida que se realicen correcciones de errores y revisiones de código. El código nunca comienza como perfecto. “Hola mundo” no cuenta (^ _-)
11. (Aplicaciones basadas en web / cliente / servidor) El cliente tiene una CPU, haga un uso de ella. El servidor apreciará esto.
12. (Lo más importante) Nunca dejes de preguntar y aprender. (^_^)

Answer 9

Aquí está mi opinión sobre esto:

• No tomes atajos. Escribe un código del que te sientas orgulloso. Si crees que tu código se ve feo, trabaja con él hasta que se vea bien, o al menos bien.
• Refactor a menudo . Si te das cuenta de que deberías haber hecho algo diferente, arréglalo. Ahora.
• Haga que alguien codifique su trabajo . Preferiblemente alguien que es realmente bueno en la codificación.
• Siéntese junto a un desarrollador que está realizando una tarea en el código “su” . Definitivamente tendrá más opiniones usando tu código que mientras solo revisa tu código. Refactoriza tu código de inmediato.
• Lee gran código .
• Leer libros blancos y referencias. Aunque puede ser realmente aburrido, aprenderás mucho.
• “Deja el campamento más limpio que la forma en que lo encontraste”. Siempre mejora el código con el que trabajas.
• Escribir pruebas unitarias. El buen código a menudo es fácil para escribir las pruebas, y usted adaptará su forma de codificación a las pruebas futuras.
• Sé predecible en tu nombre. Use las mismas convenciones de nomenclatura y estilo en todo momento, no solo para las variables, sino también para las funciones, las clases y los recursos.

Yo diría que lo más importante es intentar escribir un código del que estés orgulloso. Cuando escribo un código que es bueno, generalmente lo siento, y el código se siente como un bloque transparente de diamante. Señales de código incorrecto “Volveré y te perseguiré con errores durante los próximos años”. Escucha el código. 😀

Answer 10

Gracias por preguntar 🙂

Aquí hay algunos puntos generales a tener en cuenta :

• Utilice nombres informativos para variables, funciones y clases. No hay razón para ser astuto o astuto al nombrar cosas con un pequeño puñado de personajes.
• No coloque todo su código en un par de archivos fuente. Rompe tu código en pedazos donde tenga sentido.
• Al mismo tiempo, no cree funciones que hagan 20 cosas diferentes. Mantener las funciones enfocadas en una función particular …
• Permanezca coherente con los espacios en blanco, los nombres, los comentarios y las otras reglas que establezca.
• Escriba pruebas unitarias que cubran su modelo y luego pase a la interfaz.

Answer 11

Debe utilizar http: //danger.systems.http: //danger.systems .

Es básicamente una gema de rubí. Y trabaja durante su proceso de CI. Puede establecer reglas según sus normas. Y cuando se genera una solicitud de extracción. El código modificado será verificado según sus reglas. En cualquier error / advertencia, comenta sobre su discusión de relaciones públicas. Dale al desarrollador la oportunidad de arreglar el código según las normas estándar.

También puede refere mi blog, para pasos de implementación detallados “Peligro” entre VCS y CI: codeQuality ++ – Ramblings | SoluteLabs

Answer 12

Usted está llegando a ese punto, pero puede simplificar las cosas y hacer que su código sea más idiomático mediante el uso de la comparación de patrones.

En cualquier lugar donde se encuentre utilizando operadores como length(Any) , hd(List) o tl(List) debería pensar cómo escribir su función sin esos:

func (Lista) ->
longitud del caso (Lista) de
0 ->
cláusula0;
1 ->
cláusula1;
2 ->
cláusula2;
_ ->
cláusulaN
fin

debiera ser:

func ([]) ->
cláusula0;
func ([Elem]) ->
cláusula1;
func ([Elem1, Elem2]) ->
cláusula2;
func ([Elem1 | Rest]) ->
cláusulaN.

En lo anterior, la clauseN a menudo será algo como func(Elem1) ++ func(Rest). – No tengas miedo de la recursión, es la manera de Erlang

Answer 13

Deseche las declaraciones no utilizadas, los espacios de nombres y el código basura principalmente.
Realice la revisión del código por parte de personas que tienen más experiencia que usted y también a veces por nuevos miembros.
Haga una práctica para aprender e implementarlos y para no repetir los errores nunca más.
Manténgase actualizado sobre los últimos patrones de diseño y marcos.
Siempre habrá una mejor manera de codificar pero decidir dónde detenerse, para que no se vuelva complejo 🙂

Answer 14

Únete a un proyecto de código abierto y comienza a enviar parches. Los equipos de revisión de algunos de los proyectos más grandes son excepcionales y escribir parches es una forma de hacer que critiquen su código. Una vez que haya terminado con eso, puede unirse a un equipo que está trabajando en una función.

Answer 15

Esta es una pregunta que he estado pensando por mí mismo. Kamil dijo que parte de lo que creo que sería una buena práctica …

Publique partes de su código en los foros y solicite una opinión crítica. Resolverá el 50% de los problemas más grandes con su código.

Mi adición a su respuesta, sería tomar el consejo de ‘hacer más proyectos’ y juntarlos. Intente trabajar en su proyecto por sí mismo y cuando llegue lo suficientemente lejos como para mostrarlo, compártalo y solicite comentarios. El consejo y los comentarios que reciba aquí serán mucho más aplicables que obligarse a leer un libro sobre patrones de diseño. Pero, si alguien mira su código y dice que necesita leer sobre el ‘patrón XYZ’, estará mucho más motivado para aprender sobre él si puede mejorar SU proyecto.

Answer 16

Comience por asegurarse de que su sistema esté bien estructurado: componentes principales (base de datos, plataforma), módulos y bibliotecas, interfaces, definiciones de tablas de datos, flujos de datos, flujos de control. Romper las cosas de manera sensata, en piezas sensiblemente definidas, hace que todo el sistema sea más manejable.

Normas de codificación básicas, incluida la documentación y las pruebas, ayuda.

También preste atención al proceso (administración de configuración, prueba, integración, generación de documentos, empaquetado, administrador de sistemas), asegurándose de que sus módulos encajen en los procesos generales (por ejemplo, encabezados que admiten el proceso y la cadena de herramientas). Lo mismo ocurre con las herramientas que imponen cierta estructura en su código.

Answer 17

Primero escribe los comentarios y luego escribe el código para hacer lo que dicen tus comentarios.

Por ejemplo:
Antes de codificar una función, escriba un comentario encima de lo que debe hacer, las funciones de sus parámetros, los valores de retorno, etc. Una vez que sepa qué es exactamente la función que debe hacer, el código será mucho mejor, más simple y más claro.

Este truco me funciona muy bien.

Answer 18

Escribir pruebas. Si su código “no se puede probar”, escriba el código que puede estar en su lugar y pruébelo.

A veces, va a tener una situación en la que hay una cosa que debe ejecutarse en contexto para funcionar, luego, abstrae todo lo que pueda, pruebe las piezas y luego vuelva a ensamblar su contexto a partir de piezas buenas. Es posible que todavía tengas errores, pero es probable que estén en el código que usaste para pegar todo con cinta adhesiva y no en las partes que ya probaste.

Answer 19

Encuentre un programador que sea mejor que usted y haga que critiquen su código. E incorpora los comentarios en tu próximo proyecto.

Agrega 10,000 horas de práctica, revuelve y repite.

Answer 20

Agregaré dos enfoques a los consejos ya mencionados:

• Publique su código en Code Review Stack Exchange “Preguntas y respuestas para revisiones de código de programadores pares”. Puede solicitar algunos consejos para crear mejores algoritmos o diseños y mejorar con la retroalimentación de otros.
• Constantemente lees libros de temas que crees que ya conoces . De esta manera, siempre tropezará con diferentes técnicas para resolver tareas con las que está familiarizado e incorporará esos nuevos enfoques más rápido.