20 reglas de oro para aprender en desarrollo de software

Si eres un desarrollador, es posible que hayas experimentado algunas cosas en tu equipo…

• A veces es difícil para ti hacer pequeños cambios en el código.
• Rompe la funcionalidad del software debido a los cambios que realizó en su código.
• Introduces un nuevo error mientras arreglas el otro.
• Implementa un código innecesario que no es necesario en su aplicación.
• Agregar una nueva función es difícil para usted debido al código complicado.
• El producto que nunca se envía
• Quitas algo de código de tu aplicación y lo vuelves a escribir desde cero.

Es posible que haya deseado llorar en estas situaciones si alguna de las afirmaciones anteriores es cierta para usted.

Todos los problemas anteriores son comunes y ocurren en la mayoría del equipo de desarrollo. 

Hay muchos pequeños factores responsables de dañar el proyecto del desarrollador. No verá el efecto de inmediato y tal vez no hasta dentro de un año o incluso más. La mayoría de las veces no prestamos atención a estos pequeños factores, y consideramos que no afectarán gravemente nuestro proyecto, pero estos pequeños factores pueden dañar su proyecto a largo plazo. 

En el desarrollo, cuando comienzas a trabajar en un proyecto, todo parece funcionar bien, pero a medida que pasa el tiempo, la complejidad de tu proyecto aumenta y comienzas a ignorar algunos pequeños factores en tu aplicación. Más tarde, estos pequeños factores crean un gran problema y tu propio proyecto se convierte en una pesadilla y una historia de terror para ti. 

Estos problemas se pueden evitar si aprende algunas leyes fundamentales del software y si comprende la mentalidad de los grandes desarrolladores. Vamos a discutir este tema en detalle, lo ayudará a tomar las decisiones correctas en su viaje de desarrollo. Podrá mantener su software manejable y lo más simple posible. 

1. Comprenda el propósito de su software

Antes de comenzar a trabajar en un proyecto, comprenda el objetivo principal o el propósito de su software. ¿Cuál es el propósito de su software??….para ayudar a la gente. Si miras a tu alrededor, encontrarás muchas aplicaciones que estás utilizando en tu día a día y todas estas aplicaciones tienen un único propósito… ayudar a las personas.

El propósito del software no es mostrar lo inteligente que eres.

-Max Kanat-Alexander, Simplicidad de código

Recuerde siempre la cita escrita anteriormente. Los grandes desarrolladores nunca consideran el propósito del software mostrar cuán inteligentes son al escribir el código de un proyecto. Estará construyendo un sistema complejo o una mala aplicación si no comprende el propósito del software. Una mala aplicación no ayuda mucho a la gente. 

Cuando comience a trabajar en un proyecto, hágase una sola pregunta: » ¿Cómo podemos ayudar?» ” y luego la respuesta lo ayudará a comprender el objetivo principal de su aplicación. Además, de esta forma, podrá

2. Comprender los objetivos del diseño de software

Tenga en cuenta solo dos cosas para comprender el objetivo de su diseño de software. Su diseño debe ser lo más simple posible y debe ser útil para otros usuarios. 

Muchas veces en el desarrollo de software, cuando es difícil crear o modificar algo, los desarrolladores cambian su enfoque para hacer que las cosas “simplemente funcionen” y dedican menos tiempo a ayudar a los usuarios. Cada programador es un diseñador y, como desarrollador, debe comprender el objetivo del diseño de software. 

El objetivo del diseño de software es hacer que el trabajo del desarrollador sea lo más fácil posible. De esta manera, los desarrolladores podrán concentrarse en otras cosas importantes que importan en una aplicación. Comprender el objetivo del diseño de su software lo ayudará a crear una aplicación que ayude a los usuarios y continuará durante mucho tiempo. 

3. Comprender su sistema y su trabajo

Antes de comenzar a trabajar en un proyecto, asegúrese de comprender completamente su sistema , su comportamiento, funcionalidad, características y herramientas con las que está trabajando. Si no comprende su sistema y funciona correctamente, estará haciendo su trabajo más difícil y se dirigirá hacia la construcción de un sistema complejo.

Además, un malentendido conduce a más malentendidos y eso se convierte en un círculo vicioso en una aplicación. Estos malentendidos solo aumentan la complejidad de su sistema y esta complejidad puede dañar gravemente su proyecto en el futuro. Si un desarrollador comprende su sistema correctamente, también comprenderá lo que debe hacer en su aplicación. 

Los buenos desarrolladores saben lo que deben hacer en su aplicación, mientras que los malos desarrolladores no saben lo que están haciendo en una aplicación solo porque no entienden el sistema y su funcionamiento correctamente. 

4. Sigue la simplicidad

Siendo un desarrollador, ¿cómo se sentiría si necesitara trabajar en un código complejo en el que no entiende lo que está haciendo un grupo específico de código en la aplicación? ¿Cómo continuaría con él y realizaría su propia tarea si no comprende el código que ya está implementado en el código base? Seguramente es frustrante para cualquier desarrollador y también es difícil para ellos trabajar en este tipo de sistemas.

Como desarrollador, su objetivo debe ser reducir la complejidad del sistema, no crearlo, no aumentarlo. Si cree que escribir código complejo lo convierte en un desarrollador inteligente, entonces está totalmente equivocado. Es una mentalidad equivocada y nunca debe cometer este error en el desarrollo de software. Un buen desarrollador siempre mantiene el código lo más simple posible para que otros desarrolladores puedan entenderlo y trabajar en él.

Recuerda que en el desarrollo de software la complejidad no tiene que ver con la inteligencia, la sencillez sí. La simplicidad de su código muestra lo bueno que es como desarrollador, no la complejidad. 

Un buen desarrollador crea cosas que son fáciles de entender y fáciles de cambiar. Recuerda que los desarrolladores que son nuevos en tu código, tienen que aprender todo sobre él. Entonces, antes de escribir un código complejo, solo hágase una pregunta: » ¿Quiero que otros desarrolladores entiendan este código, estén contentos y continúen trabajando con él, o quiero que se sientan confundidos y frustrados?».

Ahora puede que te estés haciendo una pregunta a ti mismo…

tonto, tonto simple.

5. Controlando la complejidad

En el desarrollo de software, la mayoría de los proyectos fallan debido a la complejidad del sistema. Comienza con un proyecto simple, pero a medida que pasa el tiempo, continúa agregando características y después de un par de meses, cuando mira hacia atrás en su propio código, se da cuenta de que ha escrito una gran cantidad de código innecesario y ha creado un mucho más complejo. sistema. Se da cuenta de que ha ampliado algunas cosas en su software sin ningún motivo. 

Su problema no termina aquí. Debido a la complejidad, se convierte en víctima de muchos errores en su sistema. Empiezas a corregir estos errores sin darte cuenta de que es malo y

Al final, cuando te das cuenta de que lleva mucho tiempo y las cosas ahora están fuera de control. Y Reescribir el código desde cero

historiasdesarrolladoresvíctimaspregunta

,evaluar

desarrollador su comportamiento debe ser resistente al cambio. No realice ningún cambio ni agregue algunas funciones hasta que no sea muy necesario. Evitará escribir código innecesario en su aplicación. 

6. Mantenimiento

La mayoría de las veces los desarrolladores no prestan atención al mantenimiento del código. Se centran en la codificación rápida y el envío rápido del producto e ignoran la importancia del mantenimiento del código. No importa cuán pequeñas o grandes sean las aplicaciones que cree, siempre tendrá que implementar algunos cambios en su aplicación. 

Cada función que haya creado en su aplicación y cada cambio que haya realizado en su aplicación requiere tener en cuenta que, como desarrollador, su trabajo no es solo implementar las funciones o los cambios en su aplicación. También debes prestar atención al futuro.

Simplicidad y complejidad, ambos factores son los principales responsables del mantenimiento del código. Cuanto más simple sea el código que escriba para cualquier pieza de software, más fácil será mantenerlo. Un sistema complejo requiere más esfuerzo para el mantenimiento. 

Es más importante reducir el esfuerzo de mantenimiento que reducir el esfuerzo de implementación.

— Max Kanat-Alexander, Simplicidad de código

7. Sea consistente

La simplicidad de su sistema depende mucho de la consistencia. El código inconsistente siempre es difícil de entender y los desarrolladores deben esforzarse más para aprenderlo y comprenderlo. 

Si ha seguido una forma de hacer algo en un lugar, siga una forma similar

priorizando

En su viaje de programación, tendrá muchas opciones para una determinada cosa o un problema específico. Allí tendrás que tomar una decisión sobre elegir la mejor opción. Ahora la pregunta es… ¿cómo tomar una decisión sobre su software? Cómo priorizar las cosas y cuáles son algunos factores que debe considerar para tomar una mejor decisión. 

En el libro Code Simplicity , se explica muy bien con alguna ecuación…

• La conveniencia de un cambio (D): Medida del cambio que desea que suceda en su sistema (¿Cuánto?)
• El valor de un cambio (V): Medida del valor que ofrece el cambio (¿Cuánto?).

Abajo está la ecuación para priorizar la cosa y tomar la decisión. 

D=V/E

directamente proporcional al valor del cambio e inversamente proporcional al esfuerzo involucrado

Simplicidad de código

La línea anterior le ayudará a tomar una mejor decisión. Elija las opciones que requieren menos esfuerzo pero aportan mucho valor. Ignore las opciones que requieren más esfuerzo pero aportan un poco de valor. 

9. Resolución de problemas

Para resolver el problema, primero debe comprender el problema. Debe saber qué se pregunta exactamente y asegurarse de aclarar toda la confusión. 

Puede seguir la técnica de Feynman para comprender un problema difícil. En esta técnica, debe explicar su problema a otra persona en términos simples.

Si no puedes explicar algo en términos simples, no lo entiendes.

 —Richard  Feynman 

Una vez que comprenda el problema, haga un plan y tome medidas. 

Mirar el gran problema como un todo puede asustarte, así que es bueno dividir el problema en varias tareas pequeñas. Una vez que divida la tarea, resuelva cada subproblema uno por uno y luego combínelos para obtener la solución completa.

10. No persigas demasiada perfección

Uno de los errores comunes que cometen la mayoría de los desarrolladores es que quieren hacer todo demasiado perfecto en una aplicación. Quieren construir todas y cada una de las características a la perfección y, por eso, tienden a planificar todo en detalle desde el principio. La mayoría de las veces, su enfoque se desplaza a hacer las cosas perfectas en lugar de resolver el problema y ayudar a las personas con su software. 

“Lo perfecto es enemigo de lo bueno”.

 — Voltaire

Cuando los desarrolladores comienzan a trabajar en un proyecto, comienzan a pensar en todos y cada uno de los pequeños detalles o características que desean incorporar en su sistema. Cada vez que hacen algunas suposiciones, predicciones, y se hacen una sola pregunta a sí mismos «». Piensan en su software desde una perspectiva futura y predicen todo de acuerdo con eso. 

Para cualquier desarrollador, la imaginación del proyecto desde una perspectiva futura se convierte en la principal razón para construir todo demasiado perfecto. Los desarrolladores piensan que su proyecto tiene que ser perfecto tal como lo imaginaron. Los desarrolladores no prestan atención a ciertas cosas, pero buscar demasiada perfección puede ser perjudicial para ellos. Siendo un desarrollador, si está persiguiendo demasiada perfección en su proyecto, a continuación se detallan las cosas que pueden sucederle más adelante…

• Estarás escribiendo código innecesario, pensando desde una perspectiva futura.
• La complejidad aumentará debido al código innecesario.
• Serás demasiado genérico.
• Te faltarán plazos.
• La complejidad de su proyecto introducirá muchos errores en su software.

Ninguno de los desarrolladores quiere enfrentarse a todas las cosas anteriores. Entonces, siendo un desarrollador, lo que debe hacer en este caso…

Comience poco a poco, mejórelo y luego extiéndalo.

Consideremos el ejemplo de implementar una calculadora en un sistema…

1. Haga un plan para construir un sistema que
2. Trabaje en su plan e impleméntelo.
3. Realice mejoras en su sistema existente para que pueda agregar otras operaciones.
4. Ahora haz un plan para la resta y repite los pasos 2 y 3.
5. Haz un plan para la multiplicación y repite los pasos 2 y 3.
6. Haz un plan para la división y repite los pasos 2 y 3.

No persiga demasiada perfección en su software. Lo suficientemente bueno está bien. 

11. Predicciones

Pensando desde la perspectiva del futuro, escribimos mucho código innecesario y nos volvemos demasiado genéricos en nuestra aplicación, lo que no es bueno. En el desarrollo de software, no se puede predecir el futuro, por lo que no importa cuán genérica sea su solución, no podrá cumplir con los requisitos.

lo innecesarioA más

predecir el

12. No reinventes la rueda.

No implemente algo, si ya existe.  

Muchos desarrolladores pasan su tiempo construyendo o creando algo que ya existe en el portal. Este es uno de los errores comunes y solo consume el valioso tiempo del desarrollador. En lugar de reinventar la rueda, pueden dedicar su tiempo a otra cosa que es más importante. 

Ahora la pregunta es… cuando…

• son tecnologías construidas

13. Resistencia

Di no a las requests de cambio hasta que no sea importante. Cometerá un error si dice ‘sí’ a todas y cada una de las requests y si comienza a trabajar en cada una de ellas.

Agregará más código a su aplicación y eso aumentará la complejidad de su sistema. Por lo tanto, es bueno no realizar cambios innecesarios en su software.

Ahora la pregunta es… ¿qué solicitud de cambio necesitamos implementar en nuestro software?

,la

14. Automatiza las tareas repetitivas

Una de las cosas más frustrantes en el desarrollo de software es trabajar en algunas tareas repetitivas. La tarea repetitiva solo consume su tiempo adicional y es una tontería trabajar en ella una y otra vez. Cuando te des cuenta de que estás haciendo algo, una y otra vez, configúralos, automatízalo y olvídate de ellos. Si puede automatizar algo y si le está ahorrando su valioso tiempo, automatícelo.

15. Medición de código

No mida la calidad del software en función del número de líneas de código. Escribir más líneas de código no te convierte en un gran desarrollador. Si cree que mil líneas de código son siempre una señal de un gran software o aplicación, entonces no es cierto en todos los casos. En la mayoría de los casos, algo sale mal con el diseño del software. 

Si presta atención, puede resolver muchos problemas en un pequeño grupo de código. La mayoría de las soluciones simples en una aplicación no requieren mucho código. Menos código hace que su aplicación sea más simple, pero también debe recordar que no escribe muy pocas líneas de código.

16. Productividad

Muchos desarrolladores miden su productividad con la cantidad de líneas de código que escriben en una aplicación. Recuerde que en el desarrollo de software puede aumentar la productividad si arroja código innecesario de su base de código. 

Su objetivo no debería ser escribir más código y aumentar la complejidad. Deberías pensar en eliminar el código innecesario y hacer las cosas lo más simples posible. Esta regla de oro no solo aumentará su productividad, sino que también aumentará la productividad de otros desarrolladores.

17. Pruebe cada parte del código

En el desarrollo de software, siempre agregue el registro en una etapa temprana de implementación. Estarás ahorrando mucho tiempo y encontrarás los problemas fácilmente en tu aplicación. 

Ahora considere un escenario en el que ha escrito un simple bloque if-else en su aplicación. Le das la entrada al software y eso entra dentro del bloque if. Lo prueba y envía el código al control de código fuente. Por tu parte, está hecho, pero ¿qué pasa con el bloque else? Cuando su software se envíe a la producción, generará un error. 

Para evitar este tipo de problema, pruebe su código correctamente. mi

Todo lleva más tiempo de lo que piensas. 

Esta es una de las reglas de oro más importantes que debe recordar en el desarrollo de software. 

La mayoría de los desarrolladores cometen un error común en el desarrollo de software. Subestiman el tiempo y los esfuerzos necesarios para desarrollar una pequeña cantidad de código o implementar una característica. Perderá los plazos si subestima ambas cosas. 

Para una estimación correcta, puede romper el cálculo si lo adivina mal, solo habrá una ligera diferencia entre su propia estimación y la estimación correcta. Esto no afectará gravemente a su software. 

19. Documentación y comentarios

Cuando la mayoría de los desarrolladores comentan sobre un fragmento de código, piensan que necesitan mencionar » qué está haciendo el código» . Esto está mal. Si necesita mencionar esto, seguramente su código no es legible y necesita hacerlo más fácil y simple. 

Cuando no pueda simplificar el código, escriba el comentario y explique su complejidad. El propósito real del comentario es mencionar » Por qué » hiciste algo y no «Qué» en

documentación. La arquitectura de su software, el módulo y sus componentes, todo debe mencionarse en la documentación. La documentación es útil para ver el alto nivel de una imagen de su software y sería más fácil para los nuevos desarrolladores trabajar en ella si comprenden la arquitectura completa del software. Pueden cometer errores si no tienen idea de las diferentes partes o de la arquitectura completa de la aplicación. 

20. No seas un superhombre

Muchas veces sucede que sobreestimamos nuestro potencial para completar alguna tarea. Es bueno tener confianza en tu potencial, pero no es bueno volverse demasiado confiado. Muchas veces es mejor renunciar que ser un superhombre y demostrar que puedes hacer algo. En lugar de hacer las cosas perfectas y cumplir con tu tarea, cometerás errores garrafales y lo arruinarás todo. 

Suponga que estima que una tarea se puede completar en dos horas. Empezaste a trabajar en ello y han pasado cuatro horas, pero todavía estás

Estás decidido a completar la tarea, pero a veces realmente necesitas pensar de manera práctica y hacerte preguntas «¿es mejor abandonar la tarea con daño corto o es mejor continuar cometiendo un error garrafal al final?»

No seas obsesivo. Sepa cuándo dejar de fumar y no dude en pedir ayuda.