00:00:00.000
Hi everybody! I am Fernando Hamasaki, and I have been developing web applications for 15 years. I have written real Ruby code since 2009 and I work at Locaweb, the biggest hosting company in Brazil.
00:00:06.029
So, let's see the term WOP. Who knows what WOP is? Who knows about workarounds in object-oriented programming? Who here is still using WOP?
00:00:23.490
WOP, or Workaround-Oriented Programming, is an advanced technique in software development that uses various kinds of workarounds and patches. Evil code can stem from bad application design and complicated flow.
00:00:36.510
The examples I will show are from experienced programmers, not beginners. One of the first examples is masking credit card numbers.
00:01:11.010
We have an RSpec test that includes a method to mask credit card details. The method receives a credit card number and only reveals the last four digits. A possibly simple implementation could take the string representation of the number and replace the initial digits with asterisks. However, the WOP implementation iterates over the string and replaces each digit with an asterisk until it reaches the last four digits.
00:02:23.510
While it technically works, it has downsides. For instance, if you check the original variable after running the method, you'll find that the value of the number parameter has changed inside the method.
00:03:10.500
Next, we have a Rails controller that has an action to create two domains based on names found in the database. If no sites are found with blank names, it continues, and if it cannot find sites, it returns a message back.
00:03:56.230
The flow here is not so clear, especially because there is a return statement followed by an 'else' condition which can be confusing. If sites are found, it builds the domain and saves it, returning a success message. If it cannot save, it returns a message indicating that as well.
00:04:28.389
To improve the readability, we should discard error paths and place the success path at the end of the method. This makes it much clearer. In Ruby, clarity is vital.
00:05:25.960
Now let’s look at a poorly designed Ruby class. First, the constructor receives a hash where email and token keys are required. If they do not exist, it will raise an ArgumentError. Moreover, the options instance variable is widely used across multiple methods.
00:06:14.220
The best approach to ensure required values in a hash is to use the fetch method. If the key is absent, an error will be raised. There are also many methods that dynamically create attribute getters for each instance variable, and this could be improved by having a clearer definition.
00:07:23.199
However, this class is confusing and very hard to read.
00:07:34.410
Next, we have another class causing confusion with method names. It has parameters and various methods that are not clearly defined leading to dangerous code.
00:08:02.280
For instance, the import method is significantly different than what one might expect, resulting in misuse. It’s crucial to ensure clarity in naming functions.”},{