Consejos de desarrollo de software que debe ignorar – Noticias de tecnología

Los proyectos de desarrollo de startups se ven descarrilados por consejos bien intencionados, pero terribles. A continuación se enumeran seis perlas de sabiduría que vale la pena pasar por alto.

Crear software de calidad es difícil. Y a veces, un conocimiento erróneo hace que sea mucho más difícil.

Al crear código de calidad y crear software excelente, es esencial planificar cuidadosamente su proyecto y comunicarse bien durante cada paso del desarrollo de aplicaciones web y móviles.

Aunque los buenos consejos no escasean, los malos abundan entre los no iniciados. Con eso en mente, me comuniqué con algunos de mis compañeros desarrolladores e innovadores en el espacio tecnológico para conocer su experiencia en el desarrollo de software y les pedí que compartieran honestamente el peor consejo que jamás hayan recibido. Algunas de las mejores ideas de esas conversaciones y mi «peor» consejo personal:

1. Si su cambio es lo suficientemente pequeño, no es necesario realizar la prueba.

Probar el código es crucial. Como explicó el desarrollador de Google, Charles Kong, «los ingenieros de software se enfrentan a la cuestión de cuánto tiempo se debe dedicar simplemente a escribir pruebas, y algunos podrían decir que con cambios insignificantes, las pruebas de unidades realmente son una pérdida de tiempo cuando saben que no se están ejecutando». hecho. todo es probable que se rompa. Para mí, las pruebas deben escribirse constantemente para casi cada fragmento de código, y para un cambio trivial, es mucho más rápido y fácil escribir una prueba sencilla debido a esto de todos modos. Hay una conciencia constante cada vez que cometes ese pequeño error de ortografía que sucede al compilar».

Los errores ocurren, así que no sacrifiques las pruebas de tu código, sin importar cuán trivial o pequeño pueda parecer.

2. No es necesario comentar sobre un código bien escrito.

Algunos dicen que comentar es una causa perdida. De hecho, no es.

No todo el mundo entenderá su estilo de escribir código. El desarrollador de Jawbone, Trung Le, aprendió esto de la manera más difícil. “Esto no es apropiado, siempre debes comentar tu código. La razón por la que no me gusta este consejo es porque MUCHOS hombres y mujeres no leen el código correctamente, por lo que confían en la narrativa de los comentarios para comprender cómo funciona el código».

3. Evite la deslocalización a toda costa.

Esta afirmación generalizada es una que escuchamos a menudo sobre los programadores extranjeros. Sin embargo, según mi cofundador Pratham Mittal, es una idea errónea.

«Este consejo supone una generalización incorrecta», explica. “En cualquier país encontrará desarrolladores de software buenos y malos. La subcontratación de software de Vietnam y los servicios de software de Vietnam tienen una gran reserva de talento en programadores educados y competentes”.

4. Basarse en opiniones o suposiciones frente a resultados medibles.

Según Ludo Antonov, líder técnico del equipo de crecimiento de Pinterest, se puede recurrir a un ingeniero para obtener muchos consejos. Pero cuando se trata de desarrollo de productos, dice: “El consejo más destructivo es el que te anima a construir basándose únicamente en opiniones en lugar de resultados mensurables. A menudo, se desperdician así muchas buenas horas de ingeniería”.

El desarrollo de productos no es subjetivo. De hecho, se trata de resultados.

«En Pinterest, hemos utilizado un enfoque fenomenal basado en datos y centrado en láser, que es fundamental para el éxito», dice Antonov. «Es esencial que las ideas entren en el código y se prueben. Sin embargo, confiar únicamente en opiniones es muy arriesgado cuando se trata de decidir sobre el éxito del código y su introducción como una sección permanente de un objeto, que necesita un buen soporte a lo largo del tiempo».

Los sitios con mucho tráfico deberían realizar muchos experimentos en subconjuntos de su base de usuarios y optimizarlos en función de métricas clave.

5. No toques «esa» parte del código.

Está ahí y está funcionando, así que ¿por qué tocarlo? Bueno, sólo porque esté funcionando no significa que sea bueno. Sin duda tiene que ser funcional. Y sólo porque otra persona haya escrito el código no significa que no puedas manejarlo. Comprender el código de otra persona es el punto fuerte de un buen desarrollador, explica Adnan Ali. Tienes que ser valiente.

Como arquitecto jefe de software en Financeit, Ali ha recibido muchos consejos. “Sin embargo, el peor consejo de software que he recibido es ‘No toques ese código principal. ¡Nadie toca ese código maestro!’ Era absolutamente un núcleo del sistema principal y los desarrolladores tenían miedo de tocarlo. Ignorando el consejo, lo revisé línea por línea para descubrir qué hace. Basándonos en ese entendimiento, hice un gran cambio que nos permitió obtener una ganancia de rendimiento del 20 % en cada acceso a la web. Leer y comprender el código de otras personas es una de las habilidades clave para los desarrolladores”, afirma.

6. No te preocupes por la planificación.

Estos son algunos tipos clásicos de por qué deberías cuestionar los consejos que recibes. Pero para mí, el peor consejo que he recibido es: No te preocupes por la planificación. Lo descubrirás todo a lo largo del camino. Simplemente comience a escribir el código.

Creo que la planificación es realmente una fase crítica en cualquier proyecto de desarrollo. Si bien no es necesario planificar cada detalle, planificar su producto y priorizar las funciones es esencial antes de escribir el código. La mayoría de las veces un equipo creerá que todas las funciones son absolutamente esenciales. Sin priorizar ni separar las funciones en diferentes versiones, aumenta la cantidad total de tiempo y dinero invertido en su primer producto. En su lugar, debe concentrarse en desarrollar las funciones principales necesarias y obtener comentarios de su propio cliente final.

Todos recibimos muchos consejos y siempre debemos escuchar lo que la gente tiene que decir, pero debemos revisar críticamente los comentarios que recibimos y experimentar con varias estrategias.

¿De dónde obtiene sus consejos sobre software? ¿Cuál fue el peor consejo que recibiste? Me gustaría oírlo.

Fuente: Blog tecnológico de S3