O Verão finalmente chegou, e a PT Comunicações conseguiu, pela segunda vez em semanas, cortar o telefone à vizinhança toda sem pré-aviso. Fiquei sem acesso à Internet e sem poder trabalhar. Foi uma boa motivação para pegar nos livros que tinha aqui para ler. Venho-vos falar de um livro, que achei muito interessante.
Este livro reúne um conjunto de regras, ou boas práticas, para um programador sénior ou líder de projecto que queira trabalhar seguindo uma metodologia ágil. Os autores são experientes na matéria. O Andy Hunt já tinha sido co-autor do livro The Pragmatic Programmer: From Journeyman to Master. O livro está cheio de bom senso, ressoa bem com a minha experiência, dá exemplos e conselhos práticos como resolver problemas de desenvolvimento. Não só a nível de bater código, mas também de design, bem como comunicação entre a equipa ou com o cliente. Penso que tem boas ideias para todos nós que estão interessados no desenvolvimento de software.
Cito-vos algumas destas regras:
Quick Fixes Become Quicksand
A former client of Andy’s had this very problem. None of the developers or architects understood the underlying data model of their domain, and over the course of several years the code base became littered with thousands of +1 and -1 corrections. Trying to add features or fix bugs in that mess was a hair-pulling nightmare (and indeed, many of the developers had gone bald by then). But like most catastrophes, it didn’t get like that all at once. Instead, it happened one quick fix at a time. Each quick fix—which ignored the pervasive, underlying problem—added up to a swamp-like morass of quicksand that eventually sucked the life out of the project.
Criticize Ideas, Not People
You’ve probably seen design discussions that get out of hand and become emotionally charged—decisions get made based on whose idea it was, not on the merits of the ideas themselves. We’ve been in meetings like that, and they aren’t pleasant. But it’s only natural. When Lee presents a new design, it’s easiest to say, “That’s stupid” (with the clear implication that Lee is stupid as well). It takes a little more effort to elaborate, “That’s stupid; you forgot to make it thread-safe.” And it actually takes real effort and thought to say the far more appropriate, “Thanks, Lee. But I’m curious, what will happen when two users log on at the same time?”
Damn the Torpedoes, Go Ahead
Courage doesn’t feel very comfortable, certainly not ahead of time. But it’s often the only way to remove obstacles that will just grow worse over time, and you’ll feel relief instead of increasing dread.
Keep Up with Change
“There is nothing permanent except change,” said Heraclitus. That has been true throughout history, but it’s especially true now. You’re in an exciting and ever-changing field. If you graduated with a degree in computer science or some related professional field and thought you were all done with learning, you were dead wrong.
...
Keep up with changing technology. You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly.
Invest in Your Team
Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).
Know When to Unlearn
As technology marches on, things that used to be of paramount importance fall by the wayside. Not only aren’t they useful anymore, they can actually harm your effectiveness. When Andy was first programming, memory overlays were a big deal. You often couldn’t fit the whole program in main memory (48KB or so) at a time, so you had to split your program into chunks. When one chunk was swapped in, some chunk had to be swapped out, and you couldn’t call functions on one chunk from the other.
...
We’ve seen ten man-year J2EE projects go down in flames, only to be replaced with a month-long hack in PHP that delivers most of the features. Growing interest in languages such as PHP and web frameworks like Ruby on Rails show that developers are catching on that the old ways might not be cutting it anymore.
...
Old habits are hard to break and even harder to notice. The first step to unlearning is to realize that you’re using an outdated approach. That’s the hardest part. The other hardest part is actually letting go. Mental models and patterns of thought are built and refined at great cost over many years. One doesn’t discard them lightly. And it’s not that you really want to discard them completely, either. The previous memory overlay example is just a special case of manually maintaining a working set of items from a larger cache. The technique hasn’t gone away, although that implementation of it has. You don’t want to drill into the brain and snip all those dendrites off. Instead, you want to use older knowledge in context. Reinvent it and reuse it where applicable, but make sure you don’t drag along old habits just out of, well, habit.
Practices of an Agile Developer : Working in the Real World
por Venkat Subramaniam and Andy Hunt
por Venkat Subramaniam and Andy Hunt
Este livro reúne um conjunto de regras, ou boas práticas, para um programador sénior ou líder de projecto que queira trabalhar seguindo uma metodologia ágil. Os autores são experientes na matéria. O Andy Hunt já tinha sido co-autor do livro The Pragmatic Programmer: From Journeyman to Master. O livro está cheio de bom senso, ressoa bem com a minha experiência, dá exemplos e conselhos práticos como resolver problemas de desenvolvimento. Não só a nível de bater código, mas também de design, bem como comunicação entre a equipa ou com o cliente. Penso que tem boas ideias para todos nós que estão interessados no desenvolvimento de software.
Cito-vos algumas destas regras:
Quick Fixes Become Quicksand
A former client of Andy’s had this very problem. None of the developers or architects understood the underlying data model of their domain, and over the course of several years the code base became littered with thousands of +1 and -1 corrections. Trying to add features or fix bugs in that mess was a hair-pulling nightmare (and indeed, many of the developers had gone bald by then). But like most catastrophes, it didn’t get like that all at once. Instead, it happened one quick fix at a time. Each quick fix—which ignored the pervasive, underlying problem—added up to a swamp-like morass of quicksand that eventually sucked the life out of the project.
Criticize Ideas, Not People
You’ve probably seen design discussions that get out of hand and become emotionally charged—decisions get made based on whose idea it was, not on the merits of the ideas themselves. We’ve been in meetings like that, and they aren’t pleasant. But it’s only natural. When Lee presents a new design, it’s easiest to say, “That’s stupid” (with the clear implication that Lee is stupid as well). It takes a little more effort to elaborate, “That’s stupid; you forgot to make it thread-safe.” And it actually takes real effort and thought to say the far more appropriate, “Thanks, Lee. But I’m curious, what will happen when two users log on at the same time?”
Damn the Torpedoes, Go Ahead
Courage doesn’t feel very comfortable, certainly not ahead of time. But it’s often the only way to remove obstacles that will just grow worse over time, and you’ll feel relief instead of increasing dread.
Keep Up with Change
“There is nothing permanent except change,” said Heraclitus. That has been true throughout history, but it’s especially true now. You’re in an exciting and ever-changing field. If you graduated with a degree in computer science or some related professional field and thought you were all done with learning, you were dead wrong.
...
Keep up with changing technology. You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly.
Invest in Your Team
Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).
Know When to Unlearn
As technology marches on, things that used to be of paramount importance fall by the wayside. Not only aren’t they useful anymore, they can actually harm your effectiveness. When Andy was first programming, memory overlays were a big deal. You often couldn’t fit the whole program in main memory (48KB or so) at a time, so you had to split your program into chunks. When one chunk was swapped in, some chunk had to be swapped out, and you couldn’t call functions on one chunk from the other.
...
We’ve seen ten man-year J2EE projects go down in flames, only to be replaced with a month-long hack in PHP that delivers most of the features. Growing interest in languages such as PHP and web frameworks like Ruby on Rails show that developers are catching on that the old ways might not be cutting it anymore.
...
Old habits are hard to break and even harder to notice. The first step to unlearning is to realize that you’re using an outdated approach. That’s the hardest part. The other hardest part is actually letting go. Mental models and patterns of thought are built and refined at great cost over many years. One doesn’t discard them lightly. And it’s not that you really want to discard them completely, either. The previous memory overlay example is just a special case of manually maintaining a working set of items from a larger cache. The technique hasn’t gone away, although that implementation of it has. You don’t want to drill into the brain and snip all those dendrites off. Instead, you want to use older knowledge in context. Reinvent it and reuse it where applicable, but make sure you don’t drag along old habits just out of, well, habit.
Não me tinha ocorrido antes de ler o livro, mas mesmo com 29 anos, não escapo ao problema de ter de saber desaprender. Dei-me ao trabalho de aprender linguagens novas como Java, C#, Python e PHP, que não me foram ensinadas no curso, mas continuava a editar código com o vim. Desde que mudei para IDEs com suporte para refactoring, algo que não também não existia quando acabei o curso, reparei que a minha produtividade aumentou imenso.
Comentários
Enviar um comentário