Aprenda los fundamentos de una buena mentalidad de desarrollador en 15 minutos

"Difícil de hacer incluso pequeños cambios"

"Romper la funcionalidad del software mediante la realización de cambios"

"Introduciendo un nuevo error corrigiendo otro"

"Implementar código innecesario"

"Es casi imposible agregar una función nueva debido al código complicado"

"El producto que nunca se envía"

"Tirar el código y reescribirlo desde cero"

¿Son familiares todas las declaraciones anteriores?

Cada minuto, un desarrollador de cualquier parte del mundo dice (o piensa) cualquiera de las declaraciones anteriores y desea llorar. ¿Por qué?

Estos son problemas comunes de los que los desarrolladores hablan con mucha frecuencia. Estas historias se experimentan en todos los equipos de desarrollo.

Hay muchos factores pequeños que dañan lenta y gradualmente los proyectos de un desarrollador. No son destructivos de inmediato. La mayoría de ellos solo causan daños a largo plazo. Algo que no verá el daño durante un año o más. Entonces, cuando alguien los propone, a menudo suenan inofensivos.

Incluso cuando comience a implementarlos, pueden parecer bien. Pero a medida que pasa el tiempo, y en particular a medida que se acumulan más y más, la complejidad se vuelve más evidente y crece hasta que eres otra víctima de esa historia de terror siempre tan común.

Para evitar ser una de las víctimas, debe adoptar las leyes fundamentales del software. Debería desarrollar una mentalidad que todo desarrollador debería tener. Esta mentalidad lo ayudará a tomar mejores decisiones en su viaje diario de programación. Puede mantener su software lo más simple posible. Puede protegerlo para que no sea un sistema complejo e inmanejable.

Estos son los puntos clave que todo desarrollador debe dominar.

1. Concebir el propósito del software

En primer lugar, debe comprender el propósito del software. De hecho, todo software tiene un único propósito: ayudar a las personas .

Recuerde: el propósito del software no es mostrar lo inteligente que es. - Max Kanat-Alexander, Code Simplicity

Los desarrolladores que no puedan concebir el propósito del software escribirán software incorrecto. ¿Qué es un software malo? Un sistema complejo que no ayuda mucho a la gente.

Cuando tome decisiones sobre software, debe guiarse teniendo siempre esto en cuenta: ¿Cómo podemos ayudar? Incluso puede priorizar las solicitudes de funciones de esta manera.

2. Los objetivos del diseño de software

Todo programador es un diseñador.

Cuando el software es difícil de crear o modificar, los desarrolladores pasan la mayor parte de su tiempo enfocándose en hacer que las cosas “simplemente funcionen” y menos tiempo enfocándose en ayudar a los usuarios. El diseño de software tiene como objetivo facilitar el trabajo de los desarrolladores para que puedan centrarse en lo que importa. Creará software que ayudará a los usuarios y su software continuará ayudándolos durante mucho tiempo.

Sin embargo, si diseña un sistema defectuoso, la vida útil de su software será corta.

Esto nos lleva al objetivo más importante del diseño de software:

Diseñar sistemas que sus desarrolladores puedan crear y mantener lo más fácilmente posible, de modo que puedan ser, y continúen siendo, lo más útiles posible. - Max Kanat-Alexander, Code Simplicity

Por lo tanto, aquí hay dos puntos clave: su diseño debe ser fácil para usted y útil para los demás.

3. (Mal) entendimiento

Los desarrolladores que no comprenden completamente su trabajo tienden a desarrollar sistemas complejos. Puede convertirse en un círculo vicioso: la incomprensión conduce a la complejidad, lo que conduce a una mayor incomprensión, y así sucesivamente.

En realidad, una de las mejores formas de mejorar sus habilidades de diseño es asegurarse de que comprende completamente los sistemas y herramientas con los que está trabajando.

La comprensión es la diferencia clave entre un mal desarrollador y un buen desarrollador. - Max Kanat-Alexander, Code Simplicity

Los malos desarrolladores no entienden lo que están haciendo y los buenos desarrolladores sí. Es realmente así de simple.

4. Sencillez

Simplicidad es la máxima sofisticación. - Leonardo da Vinci

La programación es el acto de reducir la complejidad a la simplicidad. Un "mal desarrollador" es simplemente alguien que no logra reducir la complejidad. Un “buen desarrollador” está haciendo todo lo que está a su alcance para que el código sea lo más simple posible para otros programadores.

Un buen desarrollador crea cosas que son fáciles de entender para que sea realmente fácil eliminar todos los errores.

Ahora, los desarrolladores son generalmente personas inteligentes y a ninguno de ellos le gusta que los traten como idiotas. Irónicamente, esto los lleva a veces a crear cosas un poco complicadas. Básicamente piensan así:

Oh, otros desarrolladores entenderán todo lo que he hecho aquí. Debería escribir un código inteligente que sea difícil de entender para que puedan pensar que soy muy inteligente. "

Un error causado por una mentalidad incorrecta, no necesariamente por una falta de habilidades de programación. La mayoría de las fallas de programación ocurren debido a esa mentalidad.

Mostrar que eres inteligente no les ayuda.

Los desarrolladores que son nuevos en su código no saben nada al respecto; tienen que aprender.

Entonces, debe hacer esta pregunta: “ ¿Quiero que la gente entienda esto y sea feliz, o quiero que se sientan confundidos y frustrados? "

La verdad es que si otros desarrolladores que leen su código pueden entenderlo fácilmente, significa que lo está haciendo bien.

La complejidad no tiene nada que ver con la inteligencia, la simplicidad sí. - Larry Bossidy

La pregunta es: "¿Qué tan simple tienes que ser?"

Aquí está tu respuesta: Estúpido, tonto simple.

5. Complejidad

Controlar la complejidad es la esencia de la programación de computadoras. - Brian Kernighan

La fuente de muchas fallas de software es la complejidad. Comienza con un proyecto simple que se puede completar en un mes. Luego agrega complejidad, y la tarea tomará hasta tres meses. Luego comienzas a agregar características que cumplen algún otro propósito. Las cosas se vuelven muy complejas porque expande el propósito de su software sin ninguna razón. Las tareas tardarán seis meses.

Pero ese no es el final.

Luego, toma cada parte de la función y la hace aún más compleja, y la tarea llevará nueve meses. Luego, comienza a introducir muchos errores nuevos debido a la complejidad de su código. Naturalmente, comienza a arreglarlos todos sin pensar en cómo afectarán estos arreglos a otras partes. Al final, cuando incluso los pequeños cambios se vuelven difíciles. Cuando las correcciones de errores comiencen a introducir errores nuevos, llegará a una de las historias de terror de programación más populares: Reescribir el código desde cero .

Entonces, ¿cómo te convertiste en víctima de esta historia de terror? No, a quién le importa. Es mejor preguntar: ¿Cómo podrías evitar ser una víctima?

Bueno, es simple. Primero, conocerá exactamente el propósito de su software y su definición. En segundo lugar, será lo más simple posible en cada fragmento de código que escriba. En tercer lugar, cuando una nueva característica o una solicitud de cambio llegue a la mesa de discusión, las evaluará según el propósito de su software y las cuestionará.

Como desarrollador, su primer comportamiento debería ser la resistencia a cambios (innecesarios). Esto evitará que agregue códigos innecesarios a su software. Cuando esté convencido de que este cambio es una necesidad, puede implementarlo.

Hay muchos factores que aumentarán la complejidad, pero esos son los más populares. Aparte de todo, solo hay una regla que debes seguir:

Su principal objetivo es controlar la complejidad, no crearla.

6. Mantenimiento

El mantenimiento es una de las cosas más importantes en el desarrollo de software. Desafortunadamente, los desarrolladores generalmente ignoran lo importante que es. La codificación rápida y el envío rápido parecen más importantes que el mantenimiento del código. Este es el punto en el que cometen un error: ignorancia del futuro mantenimiento del código.

Siempre habrá alguna implementación de cambios. No solo tienes que implementarlos, también tienes que mantenerlos en el tiempo. Como desarrollador, pensar en el mantenimiento futuro de los cambios es una de sus principales responsabilidades.

Todos los cambios requieren mantenimiento. La simplicidad y la complejidad son los dos factores principales que afectan el mantenimiento del código. La facilidad de mantenimiento de cualquier software es proporcional a la simplicidad de sus piezas individuales. El esfuerzo de mantenimiento es proporcional a la complejidad del software. La única regla que debe seguir sobre el mantenimiento es: Es más importante reducir el esfuerzo de mantenimiento que reducir el esfuerzo de implementación. - Max Kanat-Alexander, Code Simplicity

7. Coherencia

La consistencia es una gran parte de la simplicidad. Si haces algo de una manera en un lugar, hazlo de esa manera en todos los lugares. Por ejemplo, si nombra una variable thisIsVariable, entonces todas sus variables deben ser nombradas de esa manera (otherVariable, anAnotherVariable, etc.no other_variable). - Max Kanat-Alexander, Code Simplicity

El código que no es coherente se vuelve más difícil de entender. No siga obligando a los desarrolladores a volver a aprender la forma en que funciona su sistema cada vez que vean una nueva pieza.

En cualquier deporte de equipo, los mejores equipos tienen consistencia y química. - Roger Staubach

8. Priorización

¿Cómo toma decisiones sobre su software?

Cuando se enfrenta a muchas direcciones posibles, ¿cómo decide cuál es la mejor opción? ¿En qué concentrarse y qué características debe implementar?

Para responder esas preguntas, hay tres factores importantes que lo ayudarán a tomar una mejor decisión. Esta ecuación se explica muy bien en el libro Code Simplicity:

  • La conveniencia de un cambio (D): ¿Cuánto desea que ocurra ese cambio?
  • El valor de un cambio (V): ¿Cuánto valor ofrece el cambio? ¿Cuánto ayuda a tus usuarios?
  • El esfuerzo requerido para realizar el cambio (E): ¿Cuánto trabajo necesitará hacer para lograr este cambio?

La ecuación es simple: D = V / E

La conveniencia de cualquier cambio es directamente proporcional al valor del cambio e inversamente proporcional al esfuerzo que implica realizar el cambio. - Simplicidad de código

Cuando priorice su trabajo, debe seguir esta regla:

The changes that will bring you a lot of value and require little effort are better than those that will bring little value and require a lot of effort.

9. Solving Problems

The first step is understanding. Know exactly what is being asked. Most hard problems are hard because you don’t understand them. Write down your problem and try to explain it to someone else.

If you can’t explain something in simple terms, you don’t understand it. — Richard Feynman

The second step is planning. Don’t take action. Sleep on it. Give your brain some time to analyze the problem and process the information but don’t spend too much time on planning.

Think before acting.

The third step is dividing. Don’t try to solve one big problem. When you look at the problem as a whole, it can scare you. Divide it into smaller tasks and solve each sub-problem one by one. Once you solve each sub-problem, you connect the dots.

10. Good enough is fine

“Perfect is the enemy of good.” — Voltaire

Whether creating a new project or adding a feature to existing system developers tend to plan everything out in detail from the beginning.

They want the first version to be perfect. They don’t focus on the problem they will solve and how their software will help people.

They start by thinking of every small detail they could think about. Then assumptions and predictions come along followed by “What if” sentences. They have to predict the future because they were now so captivated by the imagination of the project in their mind and their project has to be as perfect as they imagined it.

Actually, they are not aware of what’s waiting for them and how much it will cost them by chasing perfection.

Let me tell you what will happen:

  • You will be writing code that isn’t needed
  • You will increase complexity by adding unnecessary codes
  • You will be too generic
  • You will be missing deadlines
  • You will be dealing with many bugs caused by the complexity

Do you want this to happen? I guess no.

What you should instead?

Start small, improve it, then extend.

El diseño incremental debe ser su guía. Así es como lo usaría para diseñar una calculadora:

  1. Planifique un sistema que solo haga sumas y nada más.
  2. Impleméntalo.
  3. Mejore el diseño del sistema ahora existente para que pueda agregar otras operaciones también.
  4. Planifique la resta y repita los pasos 2 y 3.
  5. Planifique la multiplicación y repita los pasos 2 y 3.
  6. Planifique la división y repita los pasos 2 y 3.

11. Predicciones

“Una predicción es simplemente un pronóstico de que algo sucederá en el futuro. Podría ser fáctico y estar basado en algún tipo de datos objetivos o podría estar basado en una suposición ". Cuando se enfrentan al hecho de que su código cambiará en el futuro, algunos desarrolladores intentan resolver el problema diseñando una solución tan genérica que (creen) se adaptará a todas las situaciones futuras posibles. - Simplicidad de código

Being too generic involves a lot of code that isn’t needed.

You can’t predict the future, so no matter how generic your solution is, it will not be generic enough to satisfy the actual future requirements you will have. Most probably, this time will never come and the code you wrote to solve future problems will increase complexity, make it hard to change the pieces of code and eventually it will become a burden that may destroy your software.

Don’t predict to future. Be only as generic as you know you need to be right now.

12. Assumptions

What is the assumption?

“An assumption is something that you accept as true or suppose to be true, although you have no conclusive proof.”

One of the great killers of a software project is assumptions. Let’s see how an assumption can kill a software project.

Un desarrollador sabe que tiene que desarrollar un sistema para hacer X. Entonces piensa que el sistema requerirá que hagan Y en el futuro, y también implementan Y. Escriben miles de líneas de código para diseñar Y.

En el futuro, el desarrollador se da cuenta de que los requisitos actuales son completamente diferentes de lo que pensaban. Pero ahora, el software tiene códigos innecesarios que dificultan su desecho porque todo está entrelazado. Se necesitan meses para refactorizar el código y ahora piensan en reescribir todo el software desde cero, lo que les hará perder meses.

Para evitar ser una víctima como este desarrollador, siga esta sencilla regla:

El código debe diseñarse basándose en lo que sabe ahora, no en lo que cree que sucederá en el futuro. - Simplicidad de código

13. Deja de reinventar

If, for example, you invent your own garbage collector when a perfectly good one exists, you’re going to be spending a lot of time working on the garbage collector, when you could just be working on your software.

The only times it’s okay to reinvent the wheel is when any of the following are true:

  • You need something that doesn’t exist yet
  • All of the existing “wheels” are bad technologies or incapable of handling your needs
  • The existing “wheels” aren’t being properly maintained

Simple rule:

Don’t reinvent the wheel.

14. Resistance

As a developer, your first reaction to changing requests should be “NO’’.

Always resist adding more code, more features until you are convinced that they are required and there is a need to implement them. Because unnecessary changes will increase defects in your software.

How can you know that there is a need for them?

Go back and remember your software purpose. Then remember the simple equation in prioritizing section.

From: [email protected] (Russ Cox)Subject: Re: [9fans] design clairvoyance & the 9 way Date: Thu, 8 May 2003 04:05:31 GMT > What does tomorrow's unix look like? I'm confident that tomorrow's Unix will look like today's Unix, only cruftier. Russ

15. Automation

Don’t spend your time on repetitive tasks. Set them up and forget about them. They can work while you are sleeping. When you realize that you are doing something again and again, just remember this rule:

If you can automate it, automate it.

16. Code measurement

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

— Bill Gates

I see developers who measure their software quality based on code lines. They think that more code lines mean that they are doing a great job. The software contains hundreds of thousands of lines of code, which means the software they work on is so big.

The question that pops up here is: Is it really that big, or there is something wrong there?

The answer is that most probably there is something wrong with their design. Most of the simple solutions don’t require a lot of code. You can achieve simplicity with a little bunch of code and solve the problem.

I’m not saying that fewer lines of code is always better. While you want to avoid having less code, you can easily fall in a trap that will cause you to write clever code that is hard to understand for others. You should find a balance.

The optimum code is a small bunch of code that is easy to understand, easy to read.

17. Productivity

How do you measure your productivity?

By writing more lines of code or by throwing hundreds of lines of code away?!

Your main goal should be keeping your code base as small as possible. The question is not “How can I write more code?” rather it should be “How can I remove more code?”

“One of my most productive days was throwing away 1000 lines of code.” — Ken Thompson

18. Testing

When should you add logging and error handling to your project?

You should add logging in a very early stage. This will help you to find the problem easily and save your time.

I see many mistakes when it comes to testing code. Let me give you an example. There were two conditions, a simple if-else block. The developer gave input to the software which will enter inside the if block. They tested it and committed code to source control. Done!

But what about the else block? When the software was shipped to production, that caused a lot of errors. When you test your code, you must execute all new lines at least once and you should start to test parts before the whole.

When you have a bug, first you should reproduce it. You shouldn’t guess the source of the bug and apply fixes based on your assumption. Most probably, you will be wrong. You should see it with your own eyes before applying the fix.

You should be reliable. When other developers in your team see that you committed new code to source control, everyone should know that your code is tested, and works.

Untested code is the code that doesn’t work.

19. (Under)Estimation

Developers’ estimation sucks.

Usually, they underestimate things rather than overestimate them. They underestimate the time and effort required to develop a small amount of code or a feature. In the end, this underestimation leads to missing deadlines.

The solution: Break the big thing into smaller things. The smaller it is, the easier it is to estimate. You’re probably still going to get it wrong, but you’ll be a lot less wrong than if you estimated a big project.

Remember:

Everything takes longer than you think.

20. Running Away From Rewriting

I believe that when you embrace the fundamental principles of software development mentioned in that article, you won’t come to this point. However, if, somehow you make these mistakes and find yourself thinking about rewriting your code, here is the main thing that you should know:

Rewriting code is often a developer delusion, not the solution in most cases.

Why is it a delusion?

Well, because it’s harder to read code than to write it. This is why it is so hard to reuse code. This is why our subconscious mind whispers to us “Throw it away and start over” when we read another developer’s code.

There are many cases that you should consider to rewrite your code from scratch and you can read them here. But, here is simple advice for you:

Refactoring should be the first option.

21. Documentation and Commenting

One of the common misconceptions about commenting is that developers add comments that say what code is doing. This is wrong. That should be obvious from reading the code. If it’s not obvious, it means that it is not readable and it should be made simpler.

Cuando no pueda simplificar el código, debe agregar el comentario para explicar esta complejidad.

El propósito real de comentarios es explicar “por qué” que hizo algo, no “qué” de la el código está haciendo. Si no explica esto, es posible que otros programadores se confundan y, cuando vayan a cambiar su código, eliminarán partes importantes del mismo. - Simplicidad de código

Escriba un comentario para explicar "POR QUÉ", no para explicar "QUÉ".

Otra cosa es documentar. Es importante tener documentación para explicar la arquitectura de su software y todos los módulos y componentes. Esto es necesario para ver la imagen de alto nivel de su software.

When a new developer joins your team, it will be easier for them to understand the software as a whole. When developers don’t have any clue about other parts of the software, they could easily make a mistake in their own part which can affect other parts also.

22. Picking Technologies (Tools, Libraries, etc.)

First things first, always remember this rule:

Don’t depend on external technologies.But when you have to do so, try to reduce your dependency on them as much as you can.

Why is that? Because they are another common source of complexity. They can kill your active development and make everything even harder.

When you are dependent so much on external technologies, you are not free. What if there is a major bug in that technology? You have to wait for the developers to fix that bug and if this technology is in the center of your project basically you are stuck, you can’t move forward. So that’s why it is so important to pick the right technologies for your project.

There are a few factors you should consider before you start using some technology:

  • Is there active development behind it?
  • Will it continue to be maintained?
  • How easy is it to switch away from?
  • What does the community say about it?

If you can find the right answer these questions, you can reduce the risk of picking the wrong technology.

23. Self-Development

Keep learning. Try out different programming languages and tools, read books on software development. They will give you another perspective. Every day small improvements will make a real difference in your knowledge and skills.

Be open-minded. Don’t be obsessive about one technology. Use the required technology to solve a specific problem. Don’t be in the unnecessary discussion like Microsoft vs Linux :)

Know that every specific problem has its own specific solution.

24. Don’t be a hero

A lot of times it’s better to be a quitter than a hero. As Jason Fried explains,

Por ejemplo, supongamos que cree que una tarea se puede realizar en dos horas. Pero cuatro horas después, todavía estás solo una cuarta parte del camino. El instinto natural es pensar: "¡Pero no puedo rendirme ahora, ya he pasado cuatro horas en esto!" Entonces entras en modo héroe. Está decidido a hacer que funcione (y le avergüenza un poco que aún no esté funcionando). Agarras tu capa y te aislas del mundo. - Jason Fried

No seas obsesivo. Sepa cuándo dejar de fumar. No dudes en pedir ayuda.

25. No haga preguntas ... Pida ayuda

Cuando tenga algo que implementar y no esté seguro de las soluciones, no pregunte a los demás cómo hacerlo ... al menos no de inmediato. En su lugar, pruebe todo lo que se le ocurra. Esto es más importante cuanto menos cómodo se sienta con un concepto o lenguaje.

When you can’t think of anything on your own, search! Find answers and try them out. Modify those answers, see if you can understand why they work, adapt them to your code.

…But always seek advice.

When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice. Look to peers and senior developers to review your code.

I tried to explain the fundamentals of a good developer mindset in this article. I used some part from Code Simplicity book which has a big impact on my thinking process as a developer. When I read this book, there was a lot of moment that I reacted “ohh I did this mistake, I did that too.” I mentioned some important parts of the book and combine them with my experience.

I strongly recommend you to read Code Simplicity from Max Kanat-Alexander.

Thanks for reading! I hope this guide helped you out!

You can read more of my articles at //huseyinpolatyuruk.com.