¿Qué es lo más importante al crear software?

Al igual que Mark Flory, agregaría la simplicidad a su lista y la clasificaría primero.

A continuación, clasificaría la Robustez suponiendo que cada método se prueba por unidad y que cualquier colaboración con servicios externos se ejerce con simulacros y se hacen afirmaciones de prueba sobre las expectativas de las cargas útiles de solicitud / respuesta.

A continuación, clasifico a Clarity porque prefiero el código que se comunica claramente a otros con métodos y variables bien nombrados (evitando la necesidad de comentarios que para mí son una señal de alerta para novatos, piratas informáticos o académicos).

A continuación, optaría por Brevity , pero solo si la brevedad implica el principio de responsabilidad única: no me gusta la brevedad cada vez que se sacrifica la claridad (por ejemplo, no estoy a favor del uso excesivo de expresiones lambda o expresiones regulares).

Dejaría la elegancia a matemáticos y físicos teóricos. Soy un pragmático centrado en el producto con láser, por lo que no podría pensar dos veces en impresionar a otros desarrolladores con algo tan pomposo como la elegancia.

Eficiencia y velocidad Clasificaría al final porque a menudo no son una consideración. Es decir, generalmente solo abordaría la eficiencia o la velocidad si las primeras versiones del producto indicaran problemas de rendimiento o de ancho de banda que degradaron la experiencia del usuario y, como tal, impulsarían algún tipo de refactorización.

Entonces para mí eso es:

1. Sencillez
2. Robustez
3. Claridad
4. Brevedad
5. Eficiencia
6. Velocidad

Me sorprende que nadie haya mencionado el requisito.

El software está construido para un propósito. ¿Quién lo va a usar? ¿Cómo se va a usar? Y un paso más allá: ¿cuál es la motivación de por qué el usuario quiere (o cree que querrá) este software en particular? Sin comprender completamente esto, el software que cree no podrá atacar el problema que debería resolver adecuadamente. En el mundo de los negocios, hay un montón de software que es feo, difícil de mantener y carece de casos de prueba adecuados, ¡pero bueno, funcionan! Y debido a que funcionan, existen durante años y años, hasta que llega un momento con requisitos que no pueden satisfacer, y luego se mejoran, se refactorizan o se reemplazan con un software que cumple mejor los nuevos requisitos.

El requisito de cumplimiento es diferente de la corrección. Hay diferentes niveles de corrección. Si se refiere a la corrección como en “sin errores”, entonces ciertamente un software sin errores puede fallar en mantener al usuario feliz si no hace lo que quiere que haga, sin embargo, está perfectamente escrito. Si se refiere a la corrección como “cumplir con la especificación de requisitos”, entonces descubrirá que lo que el usuario quiere puede no estar bien documentado o que realmente no tiene una idea clara de lo que quiere. En tales circunstancias, incluso si su software se adhiere al 100% a la especificación, aún puede cumplir con el requisito “real”. Lo que quiero decir es que al crear software, primero debe comprender al usuario. El “usuario” puede ser el cliente de su empresa, un usuario interno, su colega, su madre o usted mismo. Antes de hacer el diseño o la codificación, descubra lo que el usuario realmente necesita, empatice con él / ella, imagine que es él / ella.

Las otras cosas enumeradas son importantes (siendo la claridad la más importante, a efectos de mantenimiento continuo si el software hace su trabajo), pero su importancia varía según el contexto de los requisitos.

Personas.

Supongamos que el software resuelve el problema para el que fue creado. Si no, todo lo demás es discutible.

El software finalmente debe servir a las personas. Las personas son ante todo y por eso debemos enfatizar los factores de las personas. Optimice para los dos tipos de personas que se preocuparán por este software: sus usuarios y sus desarrolladores.

El software es una herramienta para lograr algo de manera más eficiente o efectiva que hacer algo sin él. La herramienta debe ser fácil y agradable de usar. (UX) He encontrado una y otra vez que el software que es desagradable de usar se evita y, como resultado, se vuelve menos efectivo. Para que el software sea útil, debe ser intuitivo. Si el usuario no describiera el uso del software como un placer, hay margen de mejora. Si el software tiene errores o es incorrecto, no será un placer.

El software bien escrito debe ser fácil de mantener y ampliar. Esto significa que el software crecerá para satisfacer las demandas adicionales deseadas. Mida fácilmente por la simplicidad y extensibilidad del diseño. Cuantas menos partes internas, archivos de configuración, etc., mejor. Prefiere idiomas que le permitan expresar de manera concisa lo que hace el programa sobre los que son más detallados. Esto se presta a la mantenibilidad. Esto hace que el software sea agradable de mantener y extender (DX). Cuanto más fácil sea el cambio, menos costoso será seguir creciendo y evolucionando.

Optimice primero para el usuario y segundo para el desarrollador. Optimice para la máquina solo tanto como sea necesario para permitir una buena experiencia humana. Si hace que las personas sean su prioridad y si produce código de trabajo temprano y con frecuencia (piense ágilmente) para ajustar el ciclo de retroalimentación, los demás detalles (robustez, corrección, velocidad, etc.) se ocuparán de sí mismos.

Solo trate de deleitar a todos los que entran en contacto con el software, ya sea usuario o desarrollador.

Una comprensión del software

Con el uso cada vez mayor de bibliotecas de terceros, es simple conectar y reproducir bibliotecas para proporcionar funcionalidad adicional en lugar de codificar esa funcionalidad usted mismo. Es primordial que tenga una comprensión básica de la implementación de las API dentro de la biblioteca, de lo contrario, todo es prueba y error creando fácilmente estragos.

Además, si es una funcionalidad muy mínima, es posible que esté incluyendo una gran biblioteca con varias API, de las cuales está utilizando una sola API. Esto es innecesario, ya que puede dedicar un poco más de tiempo a implementarlo usted mismo.

Para mí, en programación, claridad y simplicidad son lo mismo. Elegancia es un término de mierda, no es que no pueda existir en la programación, pero la mayoría de la gente llama a las cosas ‘elegantes’ solo porque hay menos llaves y no tienen que definir una variable. Es un término de mierda el 99% del tiempo.

La velocidad casi nunca importa, a menos que estés haciendo un juego o algo así. Importo un * bit *, en este momento estoy creando una aplicación de escritorio y no puedo entender por qué cierta acción es tan lenta, no es crítica, pero la encontraré y la arreglaré, porque está afectando la experiencia del usuario. En un par de años, el hardware me lo solucionará, y eso ha sucedido en toda la historia de la informática.

La robustez solo es importante si es importante. No es importante en la mayoría de las aplicaciones web, a nadie le importaba que el tiempo de actividad de Twitter fuera peor que un Amiga típico (exagero, pero el tiempo de actividad de Twitter ha sido históricamente malo). A nadie le importaba porque Twitter no estaba haciendo nada importante, sin embargo, si ese tiempo de actividad estuviera presente en un banco típico de la calle, la gente sería despedida.

La robustez importa si importa, no de otra manera. Puede obtener una valoración multimillonaria con el sitio web más poco confiable que pueda imaginar. Apple podría vender Mac OS 9 frente al Windows NT 4 mucho más confiable, solo importaba si importaba.

Yo diría que lo más importante en el software es realmente hacer una mierda.

Así es como los clasificaría

• Corrección: si y solo si esto significa que el programa hace lo que se supone que debe hacer.
• Claridad: el código que es difícil de leer es mucho más difícil de mantener.
• Eficiencia: si y solo si lo que esto significa es tomar decisiones inteligentes por adelantado, no decisiones “óptimamente eficientes” y luego solo optimizar más si tiene problemas. E incluso entonces asegurándose de usar herramientas para identificar los puntos problemáticos para que solo optimice lo que realmente lo necesita.
• Robustez y velocidad, aunque estos dos seguirán a los tres primeros, por lo que no es algo de lo que deba preocuparse.
• La brevedad no es algo de lo que deba preocuparse si su código es claro.
• La elegancia es una medida completamente subjetiva que es incluso menos importante que la brevedad.

Solo los tres primeros importan. Si puede hacer que eso suceda, todo lo demás se solucionará solo.

Creo que para crear varios tipos de software con éxito, lo más importante es su razonamiento lógico y su capacidad para analizar cualquier cosa desde cero. Conocer la programación es una cosa y aplicarla para crear softwares y sitios web maravillosos es otra.

Muchas compañías de desarrollo de software en Jaipur siguen los mismos principios que anteriormente y le devuelven un valor magnífico. También puede seguir su ejemplo y obtener resultados.

Los criterios importantes que hacen que un software tenga éxito es la forma en que funciona. Esto incluye la interfaz de usuario, navegación y eficiencia de cada función.

Ahí las cosas son importantes. Aparte de eso, velocidad, escalabilidad, seguridad y elegancia son los puntos a considerar.

Navaja de Occam .

Es bueno resolver problemas complejos con el código, pero trate de mantener la solución lo más simple posible. El principal problema con el código es mantenerlo y compartirlo. El código complejo es difícil de compartir y mantener.

El criterio vital que hace que una programación efectiva sea la forma en que funciona. Esto incorpora IU, navegación y productividad de cada capacidad.

Hay cosas imprescindibles. Aparte de eso, la velocidad, la escalabilidad, la seguridad y el estilo son los enfoques a considerar.

El mejor lugar para el curso de prueba de software en línea, proporcionando herramientas de prueba de software, cursos, certificación, tutorial en línea.

Lo más importante es que el software resuelve el problema al que está destinado.

Sin eso, es irrelevante si es claro, eficiente, simple, robusto o elegante.

Me sorprende que nadie en esta discusión parezca haberse centrado en comprender las necesidades del usuario y el problema a resolver.

La mayoría de estas respuestas parecen ser desde una perspectiva de desarrollo de cómo escribir un buen código. Es una diferencia entre “construir lo correcto” y “construir lo correcto”. Si no comprende la necesidad del usuario y el problema a resolver, me parece que escribir código elegante y bien diseñado puede no importar mucho.

¿No debería ser una característica del buen software que una buena solución al problema a resolver?

Chuck Cobb

Autor de “La guía del administrador de proyectos para dominar Agile”

Echa un vistazo a mi capacitación gratuita en línea en Agile Project Management Academy

Sencillez

Simple (r) siempre gana!