¿Cuáles son los “errores” más comunes que los programadores inexpertos hacen en sus primeros sitios web / aplicaciones?

Olvidarse de desactivar el modo de depuración en producción. Los marcos web muestran trazados de pila para errores HTTP 500 en modo de depuración para facilitar la depuración. El indicador de depuración a menudo se establece en verdadero de forma predeterminada en un archivo de configuración. Cuando un desarrollador no puede cambiar esto cuando se implementa en producción, expone serias vulnerabilidades de seguridad.

En una nota relacionada, algunos marcos web tienen una clave secreta predeterminada codificada en el archivo de configuración, generalmente con un comentario arriba que le recuerda al desarrollador que esto no es seguro. Te sorprendería saber cuántos sitios web no pueden cambiar esto del valor predeterminado o cambiarlo, pero lo dejan codificado en el archivo fuente (que es de código abierto en git).

He sido víctima de estos:

1. Ignorando comentar creyendo que recordarás lo que hiciste.
2. No romper el código a los módulos (métodos, funciones y clases).
3. Reinventar la rueda. Hay muchas bibliotecas por ahí que
qué están intentando hacer los nuevos programadores. A menos que estén tratando de hacer una mejor versión.
4. No iniciar sesión adecuadamente.
5. No validando y limpiando la entrada.

No comentar y documentar su propio código. Documentar el código no solo es útil para otras personas. Es ante todo ser útil para usted en el futuro.

Una de las sensaciones más engañosas cuando comienzas a programar es que, obviamente, después de pasar tanto tiempo o energía diseñando un software, recordarás cómo funciona por un tiempo. No lo harás Por alguna extraña razón, la mente del programador promedio no funciona de esa manera. Si deja de trabajar en un código, es muy probable que haya olvidado la mayoría de los detalles técnicos después de algunas semanas o meses. Si estructuró su código correctamente y escribió alguna documentación, no es un gran problema, ya que podrá volver a profundizar en él bastante rápido. Si no lo hizo, probablemente perderá mucho tiempo y se maldecirá mucho.

He estado trabajando en un gran proyecto científico durante aproximadamente un año. Sobre todo escribí tres módulos para ello. Hay uno en el que estoy trabajando actualmente, lo sé muy bien y puedo explicarlo. Otro que escribí principalmente entre octubre y enero pasado; Todavía tengo una comprensión aproximada de cómo funciona, pero tengo que leer los comentarios para realizar tareas de mantenimiento y mejoras (que es bastante frecuente). El tercero que escribí hace un año; Apenas recuerdo la estructura general. Tuve que depurar un problema bastante desagradable con ese código hace dos meses, pasé 2 horas en él. Si no hubiera comentado mi código, probablemente me hubiera llevado el doble de esa vez, o más. Y no tengo ni idea de cómo funciona el código que escribí hace un año y medio mientras trabajaba en otro proyecto; Probablemente podría volver a hacerlo ya que está comentado, pero en este momento podría decirte lo que hace pero no cómo.

• No me refiero a que deba documentar absolutamente cada función, clase o módulo de una manera integral y estandarizada, especialmente si es probable que sea el único encargado de mantener ese software. Simplemente escriba cosas que serían útiles para usted si otra persona intentara explicarle ese software. En mi código, generalmente toma la forma de tres cosas:
• Un breve documento general que describe una arquitectura general (las jerarquías de clases y cómo interactúan los diferentes objetos para la programación OO, los flujos de eventos para el código controlado por eventos, etc.)
• Al menos comentarios mínimos para todas las clases y funciones no triviales, especialmente cuando hay algo complicado o específico en los argumentos o valores devueltos. Por lo general, es solo una línea, o unas pocas para las clases, pero ocasionalmente puede ser 5-10.
• Cada vez que hay algunas cosas algorítmicas complejas y serias, comentarios extendidos que explican qué hace esa pieza específica de maquinaria computacional y cómo lo hace (a menudo línea por línea).

Pero la conclusión es: si escribe algún software que tenga la más mínima posibilidad de ser mantenido por usted u otra persona, escriba al menos la documentación básica. Si alguna pieza de software comienza su vida como “solo una prueba” pero se vuelve más, tómese el tiempo para escribir alguna documentación antes de continuar.

Algunos de los programadores son nuevos en el lenguaje pero tienen muy buena lógica o aptitud, algunos tienen muy buen control del lenguaje pero no tienen poder lógico / de análisis.

Algunas organizaciones tienen un conjunto de reglas específicas para hacer comentarios de código, utilizar el proceso adecuado de entrega de errores y revisión de código, incluso si los Freshers son siempre nuevos, no tienen experiencia laboral real, podrían cometer errores y crecer.

Errores mas comunes
1) Olvidé manejar el error o iniciar sesión por error
2) No usar biblioteca de código reutilizable (funciones comunes)
3) errores comunes de validaciones, por ejemplo, verificación duplicada, validaciones de fecha
4) si el proyecto es nuevo, no siguen ningún patrón de diseño o arquitectura de código
5) Más enfoque en la interfaz de usuario en lugar de la funcionalidad y el logro del objetivo comercial.

1. Centrándose en los aspectos técnicos interesantes e ignorando el producto y el mercado en general . Pasé una parte importante de un año y medio de mi vida desarrollando mi propio motor de juego para mi propio juego de estrategia en tiempo real. Estaba muy emocionado por escribir mis propias API, algoritmos y jerarquías de objetos. Al final, el prototipo se veía hermoso, pero no fue divertido . En este punto, me di cuenta de que tomaría otra gran cantidad de tiempo arreglar esto, donde debería haberlo diseñado en primer lugar con la diversión en mente. Es un * juego * para llorar en voz alta.
2. Lo que me lleva al siguiente número. No entender la escala del producto y la línea de tiempo . Como principiantes, a menudo subestimamos enormemente cuánto tiempo lleva terminar un producto pulido y listo para el mercado. Esto probablemente lleva a más proyectos muertos que nunca ven la luz del día que cualquier otra cosa. Era demasiado ambicioso para la escala de mi juego, y entre invertir un par de años para hacerlo divertido y funcional frente a mis costos de oportunidad, decidí desechar mi 1.5 años de arduo trabajo al final. No ayudó que fuera técnicamente difícil terminar mi base de código. ¿Por qué?
3. Porque a lo largo del camino, reinventaba la rueda para todo . Oh, déjame escribir mi propio cargador de imágenes genial. Déjame escribir mi propio renderizador de sprites. Déjame escribir mi propia IA. Lo más probable es que exista una biblioteca que haga lo que desee, y lo haga mucho mejor y con muchos menos errores. Parte de la razón por la que lo detuve fue porque no me di cuenta de lo difícil que era hacer mi propia administración de memoria sin perder el tiempo en algún lugar y gastar para siempre para depurarlo. Es mucho mejor usar bibliotecas que han existido durante mucho tiempo, escritas por un equipo de profesionales y que tienen una base de usuarios establecida.

Dicho esto, fue una experiencia de aprendizaje fantástica, ¡y no me arrepiento de nada! 🙂

Android ha crecido hasta convertirse en el sistema operativo móvil más versátil. Con las posibilidades de transferir aplicaciones de Android a Chromebooks y Smart TV, el desarrollo de aplicaciones de Android ya no es una broma. Con más y más personas entrando en el ámbito de los desarrolladores, el error que comete un desarrollador comienza a volverse poroso. Es por eso que decidí crear esta publicación: ¡10 errores comunes que los desarrolladores de aplicaciones de Android cometen para que los desarrolladores tengan un mayor alcance y menores desinstalaciones! ¡Vamos a empezar!

10 errores comunes que cometen los desarrolladores de aplicaciones de Android

1. Registros directos: este es el más grande. Tan pronto como un usuario abre una aplicación, le solicita que se registre. Esto no es aconsejable. Entonces, ¿qué debería hacer? Después de todo, quieres más usuarios registrados. La solución es realmente simple. Proporciona algunas funciones a usuarios no registrados y luego bloquea una función interesante y dice algo como: “Estás a solo unos segundos de distancia”. Además, NO olvide agregar opciones para iniciar sesión a través de Google+ y Facebook. Además, puede obligarlos a registrarse para usar su aplicación tal como se abren por primera vez solo si está creando una aplicación de red social como Instagram o Snapchat.
2. Sonidos: Bueno, puedes adivinar por qué el sonido termina en errores. He usado aplicaciones cuyos desarrolladores querían pasar su tiempo inútilmente. Reproducir un sonido cada vez que se abre, actualiza o toca la aplicación realmente irrita a los usuarios y mutila la experiencia general del usuario. A menos que sea necesario, no lo use. La mayoría de las aplicaciones no requieren sonidos, excepto las notificaciones push y, a veces, cuando la aplicación se encuentra con algún tipo de error.
3. Complicación sobre la contraseña: ahora, la mayoría de los desarrolladores de aplicaciones no están construyendo un sistema de pago que se pueda operar a través de dispositivos móviles y, sin embargo, los desarrolladores querrán que el usuario tenga una contraseña que tenga alfabetos en minúscula, alfabetos en mayúscula, símbolos y números . Ahora esta estrategia tenía dos problemas. Primero, el usuario se irritará si la aplicación no acepta su contraseña en 2-3 intentos. En segundo lugar, las contraseñas complicadas son lo que los usuarios tienden a olvidar. Y, ¿qué crees que hará el usuario después de eso? Haga clic en ¿olvidar contraseña? No, a menos que sea un desarrollador de la aplicación de Twitter. Establezca un límite de 8 caracteres y permítales elegir la contraseña que quieran.
4. Comentarios: habrá usuarios que no estarán completamente satisfechos con su aplicación. Ahora, quieren que se corrija algo que les encantaría si hubiera una opción en la aplicación para proporcionar comentarios y no exigirlos a Google y luego recopilar su correo electrónico para decirle que algo debe modificarse en su aplicación. Incluso si menos personas brindan retroalimentación, una opción disponible para hacerlo brinda tranquilidad.
5. Navegación: casi todas las aplicaciones tienen capas de pestañas o un conjunto de opciones navegables. Por ejemplo, la aplicación Gmail tiene varias capas de opciones como Bandeja de entrada, Abrir correo electrónico, correo enviado, etc. Lo que es realmente importante es que proporcione a los usuarios que vuelvan a la pantalla principal o cualquier otra pantalla. Hay varias formas de hacerlo, como las pestañas horizontales o verticales, pero la forma más fácil y atractiva sería usar el menú “sandwich” como se ve en aplicaciones como Gmail que se puede arrastrar desde la izquierda o tocando un icono de tipo sandwich en la parte superior esquina derecha de la pantalla.
6. Falta de experiencia: esta realmente molestará a los usuarios. Lo que algunos de los desarrolladores harán es que crearán numerosos botones flotando en la pantalla. Ahora, ese nivel de experiencia se vería increíble en Galaxy Note, pero a los usuarios de dispositivos como Moto E no les gustaría, ya que más botones significarán botones más pequeños y harán que la IU sea ilegible en esos dispositivos.

Para los 10 errores, visite: 10 errores comunes que cometen los desarrolladores de aplicaciones de Android – CrayonPaper

Fue en mi experiencia inicial con la base de datos, que creé dos conexiones a la misma base de datos. El que se insertó se retrasó 5 milisegundos antes de que el segundo intentara hacer una operación en la fila que aún no se había creado y terminó sin hacer nada. Seguí haciendo intentos estúpidos durante 3 largas horas. Como novato que era, solo pude resolver el problema con la ayuda de mi amigo.

El hecho de que se construya sin errores / advertencias no significa que sea “correcto” o incluso “bueno”.

No imagino que alguien más eventualmente trabajará en su código.

El hecho de que funcione no significa que sea correcto.