How can you balance functionality and maintainability in back-end development languages?

The first and foremost criterion is the availability of developers who will create and support the project during its lifecycle. If it is an MVP of a startup that is likely to die in six months - develop in any language the team is familiar with. If it is an application that will need to be maintained - avoid trendy technologies, use time-tested solutions with a large community of developers. Another important point is to compare the cost of development and the cost of running the code. Code written in Go will work much faster than code written in PHP, but you will spend 3 times more time and 10 times more money on development.

1. Developer Availability 2. Sustainability and Maintenance 3. Cost Considerations 4. Performance Evaluation 5. Balancing Speed and Cost 6. Community Support and Reliability 7. Longevity and Adaptability

1.Choose a suitable language. 2.Follow coding standards and conventions. 3.Use modular and reusable code. 4.Implement error handling and logging. 5.Write tests and documentation. 6.Refactor and optimize your code.

One insight I also give to people here is to choose languages that they can hire talent for. Many people underestimate this . If the current engineer leaves and you can't easily get new engineers , your project may be dead on arrival.

~~Choose languages with robust community support and scalability potential. ~~Modularize code for easier debugging, testing, and updating. ~~Thorough documentation aids understanding and future maintenance efforts. ~~Implement automated testing frameworks to ensure functionality and reliability. ~~Regularly refactor code to improve structure and readability.

One thing to mention in the day and age of copy and paste is to fully understand the available logic and port over only the needed lines of code. Error handling is always poor and logging should be implemented with support mindset. Passwords should not be cleartext visible in configuration or dB. It is implicit for me but I found not for a majority.

Consider formatting tools that are highly opinionated and automated so conversations and reviews can focus on semantics instead - like (e.g. Prettier VS Code extension). Where possible adopt an existing standard and try never to deviate. This reduces time spent on standards so we can spend more time coding. Finally, never make coding standards, like static code analysis, a quality gate in a CI pipeline. It is fine to measure and share but code should improve through good design and collaboration rather than being forced via meeting a target.

5 Key Phases for Enhancing Code Standards: Hiring: Ensure candidates understand SOLID principles, dependency injection, and unit testing. Train existing team members as needed. Tech Utilization: Use tools like SonarCloud to detect code smells in builds and pull requests. AI Integration: Employ AI tools like GitHub Copilot and ChatGPT to boost code quality. Many enterprises are adopting these. Collective coding: Implement pair or mob programming to skill up juniors and elevate code standards, Teamwork: making sure everyone participates in code review, for instance, a junior review of the senior developer's code will help the junior to gain insight.

Absolutely Key to follow coding standards and conventions. As we are focusing on shipping the product to market as quickly as possible, this will enable smooth PR, faster and efficient reviews and also support smoother coordination with the SDETs. So this not only helps DEV but also QA. Standardization thus becomes a necessity even if your team is focussing on Innovation Also, This is essential in any development methodology you follow!

In today's era of copy and paste, it's crucial to fully understand the logic you're working with and only transfer the necessary lines of code. Proper error handling is often neglected, so it's important to focus on implementing robust logging with a support-oriented mindset. Additionally, passwords should never be stored in cleartext in configurations or databases. While this may seem obvious to some, it's clear that many still overlook these basic security practices.

Having documents is good but if no one reads it among the team, it won't be helping to avoid duped logic. Understand the team and come up with what works best. E.g weekly stand up on function implemented and possible reusability. Triggers in DB to be default used for error logging or track history etc

Following these good practices can save a lot of hours of refactoring and debugging in the future. Focus on follow the best practices in the language you are working on even if that increases the development time apparently. And I use the term apparently, because the cost of maintaining poor quality code is really high.

In very simple terms write functions that are meaningful. Once your functions are meaningful, maintainability will come with it.

Documentar, tanto el código internamente como en documentos separados (con capturas y ejemplos), escribir metodos/funciones/procedimientos que solo tenga una responsabilidad, actualizar librerias solo si es estrictamente necesario, ordenar los modulos de forma lógica,..

Well-defined interfaces play a crucial role in reducing dependencies between modules, enabling changes within one module without affecting others. Design patterns like dependency injection contribute significantly to creating a decoupled system by allowing components to interact through interfaces rather than concrete implementations. This approach enhances flexibility and makes the codebase easier to maintain and scale.

An aspect of logging that is missed in a lot of companies is that logs are only valuable when someone is actualy looking at the logs. Logging without having a system in place to monitor logs provides little real world value. Logs that are "created in case we need them" will typically not contain enough information (or worse to much - like passwords or user data) if they are not created with "who needs these logs and when" in mind. Log monitoring can be implemented in a lot of ways and supported by tools and alerting mechanisms - designing these systems should be included in the "we need to log" conversations.

An innovative way of handling errors without a single try-catch statement, was implemented in a project with python django through a separate exception handler function. The handler decided if it was a ValueError, ObjectNotExist Error, Validation Error or any other kind of error, then outputs a specific message and status_code. Try-catch makes the code much more verbose. Implementing a single function acted as a single point of truth and reduced code verbosity by an estimated ~1000 lines per each app in django.

Make use of the framework your programming language is using, most of them can implement global exception handling and always use structured logging to easily trace back the logs when needed.

The best systems are those that handle errors very efficiently. Error handling is a crucial aspect of software development, aiming to gracefully manage unexpected issues and prevent the entire program from crashing. From experience, we say "Errors must be thrown when encountered". Also, Logging certain actions in our codebase helps debugging a lot easier as logging plays a crucial role in understanding the behavior of a system and diagnosing issues. There are several tools used to log and trace errors such as Prometheus, ELK(Elasticsearch, Logstash, and Kibana) as well as Grafana. But essentially, it's a very good practice to set up monitoring and alerting based on log messages to proactively identify and address issues in real-time.

Two very different subjects in one headline. About error handling. It really should follow industry standard in the chosen framework. That enables faster onboarding of new developers and quicker debugging af bug fixing when the need is really there. Nothing worse that debugging a critical application at 3 am. if the error handling if done wrong. Handling of logs is really dependant on the ecosystem surrounding it. Collecting logs without automated monitoring and alerting is really not providing much value. Either it's too much which makes it impossible to located the one line that actually help fix a problem or it's not enough and does not help. A goal should be to move from a reactive to a proactive way of working.

It is one of my favourite topics in each company. Writing tests, especially unit tests, are not negotiable - part of modern software development. It is like brushing your teeth. When starting as a child, it needs discipline until it is part of a bedtime routine. But it is a crucial routine that helps you with your health for the rest of your life.

Writing tests and documentation is crucial for ensuring the reliability, maintainability, and understandability of code. Follow these: 1. Test-Driven Development (TDD) 2. Unit Tests 3. Integration Tests 4. End-to-End Tests 5. Test Coverage - sonar or gitlab scanner 6. Performance Tests and keeping track 7. Mocking and Stubbing

Yes! Always write unit tests and document as much as possible. Unit tests are a "must" in software enginnering as it prevents you from breaking any existing code and it enables you to capture various use cases before even writing the actual code. Writing good code and naming classes, methods and variables properly minimizes the need for adding comments in your code. However, documenting the high-level functions of your system and code parts really help you and your team better understand the process and connect the dots in the picture. They may seem unnecessary and too much work in the beginning, but as the application gets bigger, you'll see the value on them and thank yourself later for doing them.

Unit testing, Integration testing, Business Testing, Security testing and Functional testing are key. Automate testing as much as possible and program for a daily test run utilizing BA/QA to help with result check, jira etc

Don't write tests if you are making an MVP of a startup. Write some unit tests if you have mathematical logic in your project that counts something. Write acceptance tests for basic positive business scenarios. For 99.9% of projects this is enough. Full code coverage with tests will increase your development cost by 3-4 times or more. For most projects this is a huge overhead, try to avoid it.

Be honest with yourself. If it is not a pet project "for the soul" - there will be no refactoring. Most businesses are not ready to pay for refactoring and the older the code is, the harder it is to convince a business to refactor it. Try to write "good enough" code at once. I emphasize: "good enough", not "perfect". Ideal code is too expensive to write.

Only refactor when needed, as the saying goes "don't fix it if isn't broke". If your application demands more throughput with less resources, then you should consider refactoring to make your application consume less memory and execute faster.

In my experiences, most performance heavy jobs are data related. A prperly tuned database and optimized queries would contribute very much to an application's performance.

You can have two strategies regarding code maintenance. 1. If you want to launch an MVP asap, this means no refactoring, only bug fixing, until you do. This is the fastest way to market, but is not sustainable in the longer run. If you keep this longer then 1 year, your development will cost more and progress will become a lot slower. So the tech debt will catch-up and instead of investing in code quality, you are investing the same in slower development because of low quality. 2. You want to create a sustainable product for the long run. A reasonable amount of refactoring should be spent all the time. This includes regular updates to the latest stable versions of all dependencies and libraries, at least twice per year.

Refactoring means re-organizing/changing the existing application code without changing the behaviour of the application. That means, it is a technical decision to be solely made by a developer. How the developer performs the refactoring is another thing. In general, I recommend to always refactor. Just ensure to do it in small increments, prior to & after introducing changes to application behaviour, and always in the vicinity of those changes. Unit tests play significant role in this. If you have comprehensive & well-written tests, you are far more likely to succeed in refactoring - meaning, you are far less likely to accidentally change the behaviour of the application.

A key thing to factor in is even tho a first version of a project can be rushed, it shouldnt be too messy else an entire refactor of the codebase will be required :/

Lembre-se sempre de consultar o Know-how e as expertises da equipe que está presente no projeto. A adi??o de muitas techs novas e diferentes pode gerar complica??es na altera??o e evolu??o do projeto como um todo.

Be clear, not clever. Remember that debugging code is harder than writing code, so if you write complex code that use 100% of your skillset you will have a hard time debugging it. Write at 80%. Don't worry about those parts missing out in the 20% for now. You will get to use those when your knowledge has increased and you are at 125% compared to today.

While the back-end functionality is essential, the user experience is equally important. Therefore, it is important to balance both front-end and back-end development to ensure a seamless user experience while also delivering the required functionality.

In my experience, this forms part of technical debt, as the balance would suffer when pushed for time and/or resources. As with all technical debt, if it is not prioritized in your backlog, it will bite with the possibility of death or bankruptcy. Ensure balance is kept during prioritization.