This was the last session of the conference but fortunately, also one of the most fun sessions! The session was moderated by Matt Aimonetti and featured a panel discussed if bad ruby code exists. The panel was comprise of Aaron Patterson, Bryan Liles, and Bryan Helmkamp. If you have a chance, WATCH THIS TALK! As opposed to being a presentation, it was actually a really interesting discussion. I have a few notes from this session that I’ll write below but a lot of the conversation was mostly about questions to ask yourself as a developer when you’re writing code. Additionally, the panel members talked about their perspectives on good code, bad code, get it done code, etc. Overall, they were all really good points for me to continue to keep in mind as I work on different projects and in the future, work on more complicated projects.
First, there was a discussion about what is good code. The consensus seemed to be that good code was more testable, more maintainable, and more extendable. Most people seemed to settle on the fact that there is no bad code, but there definitely is code and better code. To this point, Bryan from Code Climate talked about the static analysis of code which helps people make more informed decisions. He hopes that the code climate process is helping to make better coders and also help determine what is better code.
Second, there was some discussion of “the rules”. I found this really interesting since I’m still learning the rules and the rules are important. When you’re first learning, it’s important to know the best practices and what the rules are. The goal is to get to a point where you can decide in an educated way if you want to break that rule or group of rules and why.
A question came up about refactoring and when you should take the time to look over your code, refactor and make those changes. The panel discussed always asking themselves the question of “how long would it take me to take this code and make it easier/better?” (easier/better meaning easier to work with or in). When the answer is around a week or longer, you’ve probably gone too far without pausing to refactor.
One suggestion based on this is when you’re working in a class, decompose the things into composed methods. In other words, factor out methods into smaller methods.
But seriously, watch this talk. It was entertaining, humorous, interesting and I feel like made me a better developer in a very different way than most of the other sessions.
The most important things I took from this talk:
1. Good development is knowing why versus how
2. A good developer knows the rules and also knows when to break them
3. Write the best code you can in the time you have
4. Focus on moving forward. Be a better developer today than you were yesterday, be better this year than you were last year, and so on.
No comments:
Post a Comment