(English version at the bottom)
O livro "Programador Pragmático" é
divido em capítulos curtos, modulares e de fácil leitura. Os autores conseguem
transmitir fundamentos importantes e práticos de programação de uma forma que
envolve o leitor, com histórias e exemplos reais. Muitos desses pontos são
relevantes também aos engenheiros de automação. Nesse post irei comentar alguns
dos pontos que mais me chamaram a atenção.
Um ponto essencial do livro é o DRY
"Don't Repeat Yourself". O DRY pode, e deve, ser aplicado em diversas
atividades do programador, desde a criação de rotinas em um programa até a
documentação de um projeto.
Outro conceito importante é a
modularidade e o princípio de ortogonalidade. A recomendação dos autores é
criar módulos funcionais em um programa, da maneira mais simples possível, que
possam ser configurados e desacoplados, evitando ao máximo dependências. Esse
método ajuda não somente na elegância do programa, mas também na manutenção e
debug.
Uma das responsabilidades do
programador é criar testes que possam testar o maior número possível de
pontos de um projeto. Essa filosofia pode ser resumida como "testar cedo,
testar sempre e testar de modo automático". Testes
unitários, por exemplo, são uma das formas de validar um módulo em um programa. Além dos testes, é fundamental haver um sólido controle de versões de um projeto,
independentemente do tamanho do projeto.
Nesse post foram comentados somente
alguns pontos do livro e vale a pena ler o livro completo para aprender outras
dicas importantes. A grande maioria dos conceitos são aplicáveis também ao
universo da automação industrial. O controle de versões, por exemplo, é
extremamente importante para atingir altos níveis de disponibilidade de uma
fábrica, e pode ser usado para um projeto SCADA, para as versões dos
programas dos PLCs, configurações dos
VFDs, entre outros dispositivos. Nesse momento em que os dispositivos
industriais aumentam a conectividade e complexidade, podemos adaptar boas
práticas existentes há muito tempo em IT nos ambientes de chão de fábrica OT.
Afinal, as distâncias entre os mundos de IT e OT estão ficando cada vez mais
curtas. Para concluir com uma última inspiração do livro, refletindo
criticamente sobre os próprios programas, com uma mentalidade aberta de
melhoria contínua, quais seriam os pontos que poderiam ser melhorados nos
programas que escrevemos cinco anos atrás?
-----
The book "Pragmatic Programmer" is divided into short, modular and easy to read chapters. The authors are able to convey important and practical programming fundamentals in a way that engages the reader, with stories and real case examples.
An essential point of the book is the DRY "Don't Repeat Yourself" concept. DRY can, and should, be applied to various activities of the programmer, from the creation of routines in a program to the documentation of a project.
Another important idea is modularity and the principle of orthogonality. The authors' recommendation is to create functional modules in a program, in the simplest possible way, that can be configured and decoupled, avoiding dependencies as much as possible. This method helps not only in the elegance of the program but also in maintenance and debugging.
One of the programmers' responsibilities is to create tests that can test as many points as possible in a project. This philosophy can be summed up as "test early, test always and test automatically". Unit tests, for instance, are a way to fulfill and validate a module in a program. In addition to having robust tests, it is essential to have a solid version control of a project, regardless of the size of the project.
In this post only a few points of the book were commented and it is worth reading the complete book to learn other important tips. The vast majority of concepts are also applicable to the universe of industrial automation. Version control, for example, is extremely important to achieve high levels of availability in a factory, and can be used for a SCADA project, for program versions PLCs, VFD configurations, among other devices. At a time when industrial devices increase connectivity and complexity, we can adapt good practices that have long existed in IT to the OT shop floor environments. After all, the distances between the IT and OT worlds are getting shorter and shorter. To conclude with one last inspiration from the book, reflecting critically on the programs themselves, with an open mindset of continuous improvement, what would be the points that could be improved in the programs we wrote five years ago?
No comments:
Post a Comment