¿Cuáles son las peores cosas en las que los desarrolladores inexpertos se olvidan de pensar? [cerrado]

Como desarrollador joven, me sería útil obtener algunos consejos sobre cosas en las que pensar para desarrollar una aplicación de alta calidad. En mis cursos universitarios, la mayoría de los maestros enfatizaron la validación de entrada y algunos hablaron sobre preocupaciones de seguridad, pero nadie cubrió la importancia de ciertas otras cosas, como el registro, por ejemplo.

¿Cuáles son algunos errores que los desarrolladores inexpertos tienden a cometer que podrían generar frustración para los desarrolladores más experimentados?

Creo que lo principal que los nuevos desarrolladores olvidan es que en el mundo real a menudo trabajan como parte de un equipo. Esto se muestra como ...

• Incorporando código que rompe la compilación
• No reutilizar el código que ya está allí
• Hacer las cosas a su manera y no de la misma manera que los demás, lo que hace que el mantenimiento sea costoso

Eso no quiere decir que su código no esté a la altura de forma aislada, pero ya no funcionan de forma aislada.

1. Pruebas
2. Pruebas
3. Más pruebas
4. Fuente de control
5. Impuestos apropiados para cualquier programa al que se dirija.

En Windows, estos impuestos son :

• Manejo de entornos de DPI alto
• Perfiles de usuarios itinerantes
• Cambio rápido de usuario
• Escritorio remoto (p. Ej., No desea utilizar el almacenamiento en búfer doble cuando RDP está en vigor
• Jugar bien con la gestión de almacenamiento jerárquico
• Monitores múltiples
• Windows de 64 bits

En casi todas las plataformas, tendrás que lidiar con:

• Unicode
• Localización
• Administración de poder

En mi experiencia, lo único que casi todos los desarrolladores inexpertos no tienen en cuenta es que (casi siempre) está trabajando en un entorno comercial. Tu código tiene que ser bueno, pero no perfecto. Lo más importante no es la perfección, es que tu código se envía.

Dicho de otra manera, entregar el código perfecto tres meses después de que su empresa se arruine no es bueno para nadie.

En mi opinión, esta es una de las formas más significativas en que el desarrollo en el mundo real difiere del desarrollo que se enseña en la universidad.

Pregunta realmente amplia; contestar en detalle es ... múltiples libros.

Aquí hay una lista de verificación general de definición de sistemas para comenzar:

• ¿Cuáles son los recursos críticos en el sistema y cómo podrían cambiar sus demandas?
• ¿Cuáles son las capacidades de rendimiento del sistema y cómo podrían necesitar crecer?
• ¿Qué áreas de requisitos podrían volverse innecesarias y removibles?
• ¿Existe la posibilidad de tener diferentes versiones del sistema con diferentes capacidades?
• ¿Cuáles son las implicaciones en la mano de obra y los recursos informáticos si se producen los cambios identificados?
• ¿Qué impacto tendrá el nuevo sistema en los sistemas operativos existentes?
• ¿Qué áreas de función tienen la mayor posibilidad de requerir cambios a la luz de la experiencia con el sistema?
• ¿Quiénes son los futuros usuarios del sistema?
• ¿Cuáles son los futuros mantenedores del sistema?
• ¿Cuáles son las mejoras futuras que los futuros usuarios del sistema pueden identificar como posibles?
• ¿Cómo encaja el sistema en los planes generales del usuario y cómo se espera que se desarrolle?

El desacoplamiento limpio del sistema en la máquina de desarrollo de uno y la máquina de destino, para que uno no termine con situaciones de "Bueno, funciona en mi máquina".

¿Y qué tan rápido puede reconstruir su máquina de desarrollo?

• ¿Sabes qué paquetes necesitas?
• ¿Tiene una solución de botón para reconstruir su base de datos?
• ¿Tiene una solución de botón para probar la integridad del código fuente?

Creo que probablemente sea diseño, es decir, el enfoque de pensar en lo que vas a hacer antes de hacerlo.

A demasiados codificadores inexpertos (recuerden cuando comenzaron) les gusta saltar y poner algo en marcha, luego agregue un poco más y anuncie un poco más y agregue un poco más. Este enfoque puede funcionar si ha planeado hacerlo de esa manera (después de todo, cada bit se puede probar a medida que avanza), pero la mayoría de los codificadores inexpertos solo se centran en la parte que están escribiendo ... por lo que todas las adiciones tienden a ser pirateadas en la parte superior. ¡Y todos hemos visto código que ha evolucionado así!

La organización es lo siguiente, a menudo están demasiado centrados en el código que han escrito para recordar cómo lo hicieron y lo que se requería. Entonces se olvidan de agrupar o documentar una dependencia que se requiere. También tienden a poner las cosas donde caen, tuve que criticar a un junior la semana pasada que revisó su código en el directorio raíz, incluidos 3 wsdls, 2 de los cuales eran el mismo archivo y un conjunto de archivos de terceros que cometió en un subdirectorio y el directorio raíz. El código no estaba formateado para ningún estándar que se pudiera imaginar, y había varias funciones que estaban presentes pero que nunca se llamaron.

Obviamente lo hizo funcionar, pero no estaba ordenado, y eso significaba que la instalación y el mantenimiento habrían sido problemáticos.

Creo que las mayores diferencias están en la técnica de codificación. Todos tienen un enfoque ligeramente diferente, pero los desarrolladores sin experiencia tienden a producir código que:

• no maneja casos límite
• es mucho más largo de lo necesario
• tiene malas características de rendimiento en escenarios relevantes
• tiene poca separación de preocupaciones
• carece de técnicas de autoprotección como el uso de const, sellado, solo lectura, etc.
• formas extrañas de devolver datos y colecciones de datos
  • esto demuestra más inexperiencia con una plataforma

Debido a que preguntaste lo peor, entonces mi respuesta es la siguiente:

1. Se me olvidó pensar en desinfectar la máquina de desarrollo de spywares, malwares y virus troyanos.
2. Olvidé pensar en hacer una copia de seguridad regular guardada en almacenamientos seguros que se encuentran en diferentes ubicaciones geográficas.

Mi mayor es recordar planificar la flexibilidad. En las clases, los requisitos casi siempre se establecen al principio y nunca cambian. En el software, a menudo sucede lo contrario: obtienes un conjunto vago de requisitos, y cambian a menudo (incluso a diario). Lo mejor que puede hacer para ayudar con esto es codificar de manera flexible: acoplamiento flexible, funciones pequeñas que se pueden usar de manera confiable en múltiples situaciones y evitar la codificación de las cosas lo más posible.

Con el tiempo, es probable que aprenda a) qué cosas tienen más probabilidades de cambiar y, por el contrario, qué probablemente no cambiará, yb) cómo anticipar las solicitudes de cambio y planificarlas.