General Development

En este documento se especifican los lineamientos y las prácticas que deberán ser utilizadas para el desarrollo de cualquier proyecto.

El objetivo de estas prácticas será el de crear código que tenga las siguientes características:

Legible
Mantenible
Escalable
Modular
Probado

Parte de la filosofía en DEVA es que como programador siempre nos encontraremos que antes los problemas de programación nos podemos encontrar con diferentes soluciones, algunas más fáciles que otras o algunas las conocemos mejor, sin embargo debemos mantener la idea que de todas las soluciones siempre hay una que es más adecuada para nuestro tipo de problema, y esto es lo que debemos mantener como objetivo: “que nuestro problema tenga la mejor solución” para esto debemos tener en cuenta la experiencia de usuario, rendimiento, memoria del sistema y plataforma de desarrollo. Esto nos lleva a la idea de que si estamos trabajando sobre un “framework” (ej. Angular) nuestra solución deberá ser la que utilice de mejor manera las mejores prácticas de este marco de trabajo, considerando los niveles > Lenguaje > Plataforma > Protocolos (ej, Typescript > Browser > HTTP).

Optimización vs legibilidad

Se debe mantener un balance entre la optimización del código (como inline functions) y la legibilidad, esto con el fin de poder mantener el código a largo plazo por las diferentes partes del equipo.

Idioma

Para el desarrollo se debe procurar el uso del inglés tanto para declaración de variables como para los comentarios generados.

En el caso de no dominar el inglés se deben escribir comentarios en el idioma nativo e incluir una traducción de google bien separada, las variables deberán quedar indicadas al inicio del documento comentando el idioma nativo y lo que representa cada variable.

Manejador de versiones y repositorio remoto

Con fines de mantener orden en el desarrollo del código se utilizará “git” como manejador de versiones:

Hacer un “commit” cada que se haga un avance y se detenga la sesión de programar, al terminar una función principal o módulo del sistema, al tener una fecha de entrega sin importar si no se ha acabado y también cuando sea solicitado para revisión de avances o integración u homologación del código.

Hacer “pull” cada vez que se inicie una sesión de desarrollo, cada inicio de iteración y cuando sea solicitado para homologación del código. Al terminar un módulo se deberá notificar para solicitar la integración con la rama principal del proyecto. TODO: Trabajo en conjunto con git

Documentación

TODO: Reglas básicas de documentación Comentarios “TODO”

Estructura e identación

limites de línea

Nombres de variables

Nombres de Archivos

Los archivos deberán (en general) ser nombrados sin utilizar espacios y usando guión "-" para separar palabras, esto siempre en minúsiculas.

Objetos y funciones

Variables de ambiente

Las variables de ambiente son aquellas que incluyen información sensible como la contraseña de la base de datos por lo que NUNCA deberán ser subidas al repositorio git, para esto se utilizará siempre un ambiente que será leído desde las variables locales del sistema.

Basic rules

Echar el error bajo la alfombra, Either by catching and ignoring exceptions, or by using libraries that don’t report errors (such as jQuery), there are many ways to sweep things under the rug. But when one of those errors becomes a priority, the challenge of fixing it will be many times greater, considering that you won’t have a clue where to begin. An easy way to avert this is by logging those ignored errors so you can study them later.

Refusing to write bad code There comes a time in every developer's life when deadlines will force you to write terrible code, and that’s okay. You’ve tried warning your client or manager about the consequences, but they insist on sticking to the deadline, so now it’s time to code. Or perhaps there’s an urgent bug that can’t wait for you to come up with a clean solution. That’s why it’s important to be versatile as a programmer and to be able to write poor code very quickly as well as good code. Hopefully, you can revisit the code and pay back the technical debt.

Blaming others

It's no secret that arrogance is an all-too-common trait among developers and other technical professionals. Taking responsibility for your mistakes is a virtue that will make you shine among your peers. Don’t be afraid to admit that you’ve made a mistake. Once you’re okay with that, you will be free to focus on learning why you made that mistake and how to avoid it. If you don’t own up to it, learning becomes impossible.

Your value as a developer is not only placed on the code you write, but also on what you learn when writing it. Share your experiences, write comments about it, let others know why things are the way they are, and help them learn new things about the project and its intricacies.

Being too slow on giving feedback to managers/clients

One of the most valuable character traits of any craftsman lies in making sure that everyone is on the same page about the work, as much as possible. The reason for this is not so that your manager can fill spreadsheets. It’s for your own gain as well: You will have fewer insecurities and reduce uncertainty about the lifetime and future of the project.

Not using Google enough

The best way of solving a complex problem quickly is not having to solve it at all. When in doubt, Google it. Of course, you can bother the engineer next to you instead, but rarely will he be able to give a response as detailed as Stack Overflow, not to mention that you’ll be interrupting his work as well.

Overvaluing your personal style

Always aim to coordinate your working style and environment setup with your team. Ideally, everyone on your team should be working under similar conditions and following the same coding style. Doing things your way can be more fun, but co-workers might not be used to your coding style, and if it's unusual, it will be harder for the next developer to work on what you've built.

Having a personal attachment to your code

When someone comments on your code, don’t take it personally. Your code should stand on solid ground; that is, you should be able to explain why you wrote it that way. If it needs improvement, that’s only a reflection of the code’s correctness, not of yourself.

Writing code

Not knowing how to optimize

A good optimization strategy takes some experience to get right. It takes exploration, analysis, and knowing every system involved in a process. Inform yourself about these things. Learn about algorithmic complexity, database query evaluation, protocols, and how to measure performance in general.

Using the wrong tool for the job

You can only know so much, but the reason why you have to keep learning is that each new problem brings a different context and requires a different tool—one more applicable to the task at hand. Be open to new libraries and languages. Don’t make decisions based strictly on what you know.

Not bothering with mastering your tools and IDE

Each new hotkey, shortcut, or parameter you learn while using the tools you work with every day will have a more positive effect on your coding speed than you realize. It’s not about saving a few seconds by using a hotkey; it’s about reducing the context switching. The more time you spend on each small action, the less time you’ll have available to think about why you’re doing it and about what comes next. Mastering shortcuts will free your mind.

Ignoring error messages

Don’t assume that you know what’s wrong with your code without even reading an error message, or that you’ll figure it out quickly enough. Having more information about a problem is always better, and taking the time to gather that information will save more time in the long run.

Romanticizing your developer toolkit

Sometimes your preferred editor or command line tool isn't the the best tool for the job at hand. Visual Studio is great for writing IDEs, Sublime is great for dynamic languages, Eclipse is great for Java, and so on. You might love vim or emacs, but that doesn’t mean that it’s the right tool for every job.

Hardcoding values instead of making them configurable

Always be thinking about what changes might come and how to deal with them. Technical debt will grow at a monstrous rate if you don’t separate the moving pieces from the rest of your work. Use constants and configuration files where appropriate.

Reinventing the wheel all the time

Don’t write code you don’t need to. Perhaps someone else has spent a good deal of time on your problem already, and he or she might have a well-tested solution that you can reuse. Save yourself some trouble.

Blindly copy/pasting code

Understand code before you reuse it. Sometimes you don't immediately notice everything the code is doing on first glance. You will also learn more about a problem when you take the time to read the code in detail.

Not taking the time to learn how things really work

Always take the opportunity to expand your knowledge by thinking about how things work and reading about their underlying issues. You might save time by not bothering right now, but what you learn on a project will be more important in the long term than actually getting it done.

Having excessive confidence in your own code

It’s dangerous to assume that just because you wrote something, it must be great. You learn more about programming as you work on new things and gain experience, so take a look at your old code from time to time and reflect on how you’ve progressed.

Not thinking about the trade-offs of each design,

solution, or library Every product has its fine points that you’ll only learn about by using and analyzing it. Seeing a few usage examples for a library will not make you a master of it, nor does it mean that it’s the perfect fit for every situation that will come up in your project. Be continually critical of everything you use.

Not getting help when you're stuck

Keeping a short feedback loop will always be less painful for you. Asking for help doesn’t mean that you’re incompetent. The right people will see your effort and admission of ignorance as a drive to learn, and that’s a great virtue to have.

Testing and maintenance

Writing tests to pass

Writing tests that you know will pass is necessary. They will make refactoring and reorganizing a project much safer. On the other hand, you also have to write tests that you know won’t pass. They are necessary to move the project forward and keep track of issues.

Disregarding performance testing for critical cases

Prepare an automated performance testing setup at about the middle point of a project's development process so you can make sure you don’t have escalating performance problems.

Not checking that your build works

It’s rare when a build passes but doesn’t really work, but it can happen, and it might be troublesome to fix the problem the longer you wait to look into it. Quickly testing every build is an important habit to have.

Pushing large changes late, or leaving after making a large push

This is where overconfidence will get you, and it can take getting burned multiple times to learn why you shouldn't do this, so take my advice now and make sure you are always there when your build eventually breaks.

Disowning code you wrote

Be willing to support code you wrote. You are the most suitable person for helping others understand it. You should strive to make your code remain readable to yourself and others many years from now.

Ignoring the nonfunctional requirements

When you’re trying to deliver something, it can be easy to forget about some important areas such as performance and security. Keep a checklist for those. You don’t want them ruining your party because you drew up your deadlines without thinking about these nonfunctional concerns.

Principios para el desarrollo de una "web app" o un "s.a.s"

https://12factor.net

I. Linea de código única

II. Dependencias declaradas

III. Configuración en el ambiente de ejecución

IV. Servicios de respaldo como recursos adjuntos

V. Etapas: compilación, lanzamiento y ejecución

VI. Ejecución con estado efímero

VII. Accesso por puertos a contenedores

VIII. Alta concurrencia via procesos

IX. Alta desechabilidad de los procesos

X. Ambientes de desarrollo y producción similares

XI. Registros como eventos de salida

XII. Processos administrativos externos

Git

Branches

Each developer should have a main branch created from "master"

ex. master -checkout -b> changes/henry

For each issue create a branch

ex changes/henry -checkout -b> henry/DEV-123

Undoing, fixing or removing commits

http://sethrobertson.github.io/GitFixUm/fixup.html