Search
Functional Programming
Simple and Elegant Rails Code with Functional Style
Edit
#ruby-on-rails
#functional-programming
#code-quality
#refactoring
#service-objects
#business-logic
#design-patterns
Summarized using AI

Simple and Elegant Rails Code with Functional Style

Attila Domokos • April 29, 2013 • Portland, OR

In the video titled 'Simple and Elegant Rails Code with Functional Style,' Attila Domokos presents insights on improving the quality of Rails applications by incorporating functional programming principles. He emphasizes the importance of reducing code complexity to enhance understandability and maintainability.

Key Points Discussed:
- Experience Background: Attila shares his transition from .NET to Ruby on Rails and mentions his recent job transition.
- Common Coding Issues: He highlights the challenges of working with overly complex codebases, exemplified by an Orders model with 2700 lines of code and methods exceeding 200 lines.
- Importance of Code Clarity: Attila stresses that poorly organized code can reflect negatively on developers and impact business operations.
- Code Complexity Analysis: He introduces 'Flog,' a tool for analyzing code complexity, discussing its usability in assessing Rails projects and how high Flog scores indicate problematic code.
- Refactoring Techniques: Attila demonstrates the significance of refactoring, such as method extraction, to simplify controllers and models, showcasing concrete changes in Flog points before and after refactoring.
- Service Objects: He encourages the use of service objects to encapsulate logic and maintain the single responsibility principle, which improves testability and clarity.
- Naming Conventions: A transformation in his naming strategy from nouns to verbs enhanced the clarity of service objects, promoting a better understanding of functionalities.
- Framework for Organizing Actions: He describes the development of LightService as a lightweight gem that facilitates good structure in service calls, emphasizing simplicity and organization in larger codebases.
- Warning on Complexity: Attila cautions against unnecessary complexity, suggesting that the use of Flog should guide developers in restructuring rather than just filling code with complexity.

Conclusion: The talk concludes with a call to action for developers to strive for elegance and simplicity in their code, paralleling it to the functional elegance of minimalist designs. Attila encourages participants to embrace structured approaches such as using the LightService gem to retain clarity and functional integrity in codebases, ensuring not just effective development but an enjoyable coding experience.

Attila leaves the audience with his social links for further engagement, inviting them to pursue more information on the discussed methods.

Simple and Elegant Rails Code with Functional Style
Attila Domokos • April 29, 2013 • Portland, OR

By Attila Domokos

Do you have to look at Rails models with 2500 lines of code? Or 200 line methods loaded with iterators, conditionals and instance variables? Not only you, even the code author does not understand what's going on in there.
I'll show you how you can craft simple and beautiful Rails application by adopting functional programming inspired ideas. Say goodbye to the mess you have by constructing tiny classes and functions that you can use to build up a complex system.

Help us caption & translate this video!

http://amara.org/v/FG9y/

RailsConf 2013

00:00:16.320 Hello everyone. The title of my talk is 'Simple and Elegant Rails Code with Functional Style.'
00:00:22.560 I’ve been working professionally for three years now. Prior to this, I spent eight years in the .NET space.
00:00:28.960 Someone mentioned there’s a bit of feedback. Can you all hear me?
00:00:34.239 Great! So, I spent eight years in the .NET space, and I was fortunate to switch over to Ruby and Ruby on Rails.
00:00:41.280 I was laid off about two months ago from my previous job.
00:00:46.640 I recently found a new job in Chicago, so I'm moving from Northeast Ohio to Chicago.
00:00:52.559 Is everyone okay? Anyone here from Chicago? I hope to see you guys there soon.
00:00:59.199 Currently, I work for a company where I’m the only developer. We are looking to hire additional team members.
00:01:05.680 Our company specializes in the franchise space, and we provide numerical results for hiring decisions.
00:01:11.360 Instead of relying on gut feelings, we make decisions based on numerical results that can help identify the best candidates.
00:01:17.759 I’m not going to teach you functional programming in this talk, nor am I going to try to overly bend Ruby into a functional programming language.
00:01:23.360 My goal is to show you how to write simple and elegant Rails code.
00:01:29.119 In my previous job, I had a 25-minute commute to work. I used to listen to the radio, but I grew tired of the commercials.
00:01:34.560 I decided to start listening to audiobooks, and a friend recommended 'The E-Myth Revisited.' I remember a particular sentence from the book: 'The work you do is a reflection of who you are.'
00:01:42.079 When I see someone who does a lousy job, I don’t just think about the job itself; I reflect on what kind of person they are. This can be applied to our profession as well.
00:01:49.680 The quality of the code you write can be a reflection of your own character.
00:01:55.600 Recently, I went bowling with my son and drove on a road that looked terrible.
00:02:00.719 I was worried I would lose one of my car's wheels. As I stepped out, I could see cars passing by recklessly.
00:02:05.759 I even took a photo to document how hazardous the road looked. It seemed like it took over a year to reach that state.
00:02:12.480 They attempted a fix with tar, which may last through winter, but come spring, the pothole will likely return, if not worse than before.
00:02:18.239 Last year, I stumbled upon a news story from China where the government needed to build a highway but a person refused to sell his apartment.
00:02:24.480 What they did was build the highway around the apartment instead.
00:02:29.680 A couple of weeks later, the owner finally agreed on a price, and the highway was completed.
00:02:35.200 I thought that was an unbelievable story, but it was soon overshadowed by another news item.
00:02:41.200 A family in a similar bind refused to remove the remains of their relatives, and the builders ended up constructing the foundation around the graves.
00:02:46.560 They literally built around the gravesite.
00:02:51.920 Do you remember what your room looked like when you were 15? Mine looked like a mess.
00:02:57.280 I would often spend hours looking for my textbooks or jeans.
00:03:02.800 I'm not proud of it, but that was my reality.
00:03:09.040 This here is a model from a Rails application I once worked on. It's an e-commerce application, and this is the Orders model.
00:03:14.239 It contains 2700 lines of code. I’m not joking. The 'Calculate Shipping' method alone has around 206 lines of code.
00:03:20.239 Right underneath that is the 'Recalculate Shipping' method, which has 197 lines of untested code.
00:03:25.760 We wanted to tackle this issue, but it seemed like too overwhelming a task.
00:03:31.840 When you encounter code like this, think about real companies that have similar size codebases. I was laid off from that company due to financial reasons.
00:03:37.200 Really, this type of complicated code can bring down a company.
00:03:44.080 To add insult to injury, this code was not written by contractors, but by employees before I arrived.
00:03:50.400 I wanted to find a good tool to analyze code complexity and stumbled upon 'Flog.' Does anyone here know about Flog?
00:03:56.480 Awesome! I spoke with Jim Weirich at another conference, and he said he used 'Flog' against a project he had never seen before.
00:04:03.599 It quantifies the code without needing to open up the classes, providing a score based on code complexity.
00:04:08.799 The higher the score, the more challenging it is to test that code.
00:04:13.600 This is a central concept in my talk today.
00:04:19.199 Installing Flog is straightforward; add it to your Gemfile, preferably in the development or test group.
00:04:24.880 Installing through RubyGems is a breeze. You can run it against a class or a group of classes.
00:04:30.000 I typically run it against controllers and models. With 95% accuracy, I can assess what kind of code I'm dealing with.
00:04:37.120 The video you saw earlier mentioned a staggering 25,902 Flog points.
00:04:44.000 The ideas I'll discuss stem from my work on various Rails applications.
00:04:50.480 To illustrate my points, I wanted to share a tracking application where users provide a category, amount, and description.
00:04:55.680 It's important that this app doesn’t just save values into the database; it should also do some parsing.
00:05:01.039 For instance, when you provide a value like 'running 3.2.12', it should save it to a category table with the corresponding details.
00:05:05.200 This data can then be filed under today’s date unless overridden by the user.
00:05:11.040 Now, let me ask you: Where do you put your domain logic? How many of you place it in the controller?
00:05:17.040 Raise your hands. Now, how many put it in the models?
00:05:22.000 That’s about a third of the room. How about the remaining two-thirds? Where do you place it?
00:05:27.440 Interesting! I thought this was a common history, but the codebase I inherited was quite heavy on controllers.
00:05:34.159 I came across controllers with around 1750 lines of code, which is not an uncommon practice.
00:05:42.079 When I interviewed contractors, one of my questions was, 'How many units do you have?' Their answer was zero.
00:05:48.240 Yes, I joined them because despite this, I believed their business idea was strong and had potential.
00:05:54.480 We definitely need to clean that application, and I hope to return one day and share our success story.
00:06:01.920 What I attempted to do was integrate parsing logic right into the controller action, and this is how the codebase appears now.
00:06:09.040 Don't worry about understanding the details; the point is, this code isn't giving us clarity.
00:06:15.360 There are 48 lines of code here, and it's not performing well.
00:06:22.160 The Flog value comparison shows how the controller's complexity overshadows the model’s.
00:06:28.160 Thanks to the extraction method, I managed to reduce the line count from 48 to 25.
00:06:34.720 Following the refactoring exercise, we noticed Flog values changed as well.
00:06:41.920 Now, instead of a hefty 40-plus Flog point action, we have reduced it to a manageable 20.6.
00:06:47.239 This reflects that refactoring via method extraction is beneficial.
00:06:54.080 Through this process, we realized that using logic from the controller can be tricky.
00:07:01.920 I moved the parsing logic from the controller into the model, which improved clarity.
00:07:07.200 Now, instead of complex controllers, we have simplified our approach.
00:07:12.240 The model's Flog value shot up to 84 while the controller's value dropped to about 25.6.
00:07:18.399 That’s a significant improvement! Classes with a Flog point around 20 to 30 are manageable and understandable.
00:07:25.440 I want you to remember that enormous room clutter I showed you earlier—it had 2500 lines of code.
00:07:31.920 Three years ago, when I started working on a Rails application, the code was already four years old.
00:07:37.200 I asked other developers how many unit tests we had, and their response was zero.
00:07:42.560 They explained it takes too long to run the existing tests, with one spec taking 17 seconds.
00:07:48.000 This led to my early decision to move business logic out into services.
00:07:54.560 I even wrote a blog post on it that received quite a bit of attention.
00:08:00.640 Initially, I stubbed everything out of Rails extensively, but with these techniques, I managed to run extra specs under one second.
00:08:06.880 The code didn’t change much after this shift in approach.
00:08:12.160 I began calling a service instead of the model directly, which is just a plain Ruby object.
00:08:19.040 Are there any of you following this method of using plain Ruby objects for services?
00:08:25.759 Now, I’m changing focus to illustrate how I represented Flog values.
00:08:31.440 I moved from comparing controllers and models to comparing models and services.
00:08:36.000 As you can see, the Flog score has readjusted. The model had fallen back to 38.4 while services scored 71 points.
00:08:42.000 Here’s how my initial service class looked.
00:08:50.960 Each entry method calls other methods on the service. By the end of the call sequence, the instantiated track object is returned.
00:08:56.560 This structure allowed me to test every method, but it got complicated.
00:09:03.440 When I modified method signatures, unit tests began to fail, resulting in significant headache.
00:09:08.480 I opted to only have one public method in the service class while keeping everything else private.
00:09:15.679 This allowed me to modify method signatures more effectively. However, setting up tests became burdensome.
00:09:23.040 These service objects were violating the single responsibility principle.
00:09:29.439 Consider what happens when your customer comes back with additional requirements.
00:09:36.000 You have to think about where to put that new functionality and how to scale.
00:09:42.240 A year and a half ago, in January, I was in a coffee shop helping a colleague with a testing issue.
00:09:48.240 I spent 10 minutes trying to identify a failing spec due to dependencies I wasn’t recognizing.
00:09:54.239 Before continuing, I want to emphasize naming.
00:10:00.560 Instead of naming services after physical objects, I started using verbs that describe actions.
00:10:06.400 For example, ‘parse_feed’ clearly indicates its functionality.
00:10:13.440 I attended a coding retreat and was advised to read a piece titled 'Execution in the Kingdom of Nouns,' which changed my perspective on naming.
00:10:20.000 As the complexity increased, so did the size of my methods.
00:10:27.040 Instead of allowing them to grow lengthy, I created subclasses as needed.
00:10:34.000 This approach made testing more accessible since I could stub and mock the dependencies effectively.
00:10:40.040 Yet, I still didn’t feel completely satisfied with the clarity.
00:10:46.720 My goal was to achieve a uniform interface with a method that took context as an argument.
00:10:53.760 The reasoning was to simplify testing by requiring a single argument.
00:11:00.000 As I mentioned, I spent eight years in the .NET space learning design patterns.
00:11:07.200 I loved the Chain of Responsibility design pattern. It made sense to handle multiple steps in a process.
00:11:13.760 Although I attempted to implement this in Ruby, it felt cumbersome.
00:11:20.000 As I navigated through coding exercises, I realized two object types emerged.
00:11:29.600 The organizer object helped narrate the process flow.
00:11:35.760 It starts with splitting the feed into parts and validating the information.
00:11:42.320 By situating code around these processes, you can read the flow.
00:11:50.000 The actions represent the core logic of this process.
00:11:57.480 Each action encapsulates a method that does its job and returns a context.
00:12:03.920 After refactoring that bulky service class, I was pleased to see Flog points reduced.
00:12:12.080 My Flog average for the service class fell from around 70 to 13.9.
00:12:19.040 Classes with lower Flog values are much easier to grasp.
00:12:25.520 Moreover, my actions are not stateful, meaning they are cleaner and simpler.
00:12:31.760 The context serves as a conveyor belt in an assembly line, passing from one action to another.
00:12:38.560 The context object defines a well-structured format for the data.
00:12:44.480 It’s instantiated by the organizer object, which pulls data as needed.
00:12:51.360 Actions process this data in sequence, and if an action fails, the subsequent actions won’t execute.
00:12:58.720 As I transitioned from one project to another, I found a pattern.
00:13:05.120 I developed a lightweight gem called LightService.
00:13:12.320 It’s simple, featuring only two classes.
00:13:18.720 The LightService organizer handles data feeding and action processing.
00:13:25.520 The action class contains the method to be executed if no failure occurs.
00:13:32.160 A friend pointed out that it’s difficult to remember the guard condition and execute methods.
00:13:39.200 In response, we created a macro to simplify this.
00:13:46.080 This macro eliminates the need to memorize specific guard conditions.
00:13:52.480 So, if you want to simplify your approach, check out the macro.
00:14:00.160 However, as software grows, so does its complexity.
00:14:06.720 Every project begins smoothly, but after two years, even minor changes require extensive effort.
00:14:13.040 To study growth, I experimented with a controller action containing an extracted method.
00:14:20.160 On the left, you’ll see the code complexity of the controller, while the right shows a series of actions.
00:14:26.400 In its original form, the coding complexity was at 71 for the actions.
00:14:33.040 After duplicating method and class names, the controller complexity skyrocketed to 124.2.
00:14:39.679 But the actions maintained their lower complexity, remaining around 13.
00:14:46.240 If I had continued to extend them, that Flog value would’ve reached unsustainable heights.
00:14:52.720 Remember, if you add complexity to a codebase, it doesn't just disappear.
00:14:59.680 Use Flog as a guide for when to split objects or functionality.
00:15:07.040 A warning: I won't use this pattern inappropriately.
00:15:13.440 We should recognize when the complexity of business logic doesn't necessitate it.
00:15:19.440 I still take advantage of Rails for simple updates.
00:15:26.320 As soon as conditionals or iterators creep in, I extract that logic to a service.
00:15:35.440 If that service does multiple tasks, it’s split into actions and an organizer.
00:15:42.000 This has become my guiding principle.
00:15:48.960 When you're faced with a requirement change, encapsulate it in a new class.
00:15:55.360 This keeps your codebase tidy and manageable.
00:16:02.080 Think back to that cluttered 2500 lines of code I mentioned.
00:16:09.680 Conversely, consider the simplicity of a minimalist hotel room in Japan.
00:16:15.360 Something so simple yet functional.
00:16:20.440 Let this hotel room symbolize clear, concise action.
00:16:26.880 Now, here are my social links. I’ll leave this up for you.
00:16:33.840 Thank you for your attention.
00:16:38.560 You can find my slides at this link: bitly/ad_at_railsconf. I've created and shared this link this morning.
00:16:44.159 Once again, thanks for your attention!
00:33:30.960 (End of talk.)
Attila Domokos
@adomokos
Explore all talks recorded at RailsConf 2013
+93