Summarized using AI

Safety Nets: Learn to Code With Confidence

Christophe Philemotte • June 27, 2014 • Singapore • Talk

In the talk "Safety Nets: Learn to Code With Confidence," Christophe Philemotte discusses the importance of implementing safety nets in software development, drawing parallels to other fields such as medicine, civil engineering, and manufacturing. He emphasizes that while coding offers powerful tools, it also introduces the risk of errors which can lead to costly consequences. Therefore, strategies must be implemented to minimize and address these risks effectively.

Key Points:

  • Introduction to Safety Nets: Philemotte begins by introducing the concept of safety nets, likening them to precautions in various fields where human error is a possibility.
  • Anecdote from Medicine: He shares a personal story about his wife's work as a medical physicist, highlighting the critical nature of minimizing errors in cancer treatment, which can be extremely costly and harmful. This sets the stage for understanding the need for safety nets in coding.
  • Types of Safety Nets in Software Development: Philemotte identifies three primary methods as safety nets:
    • Testing: Writing tests allows developers to validate functionality before deploying code. He illustrates this with a simple invoicing application example, demonstrating how tests can uncover errors when code changes are made.
    • Static Analysis: Tools that analyze code for potential issues without executing it can identify complex areas that may cause bugs, such as the misuse of variables or readability issues.
    • Code Review: Involving peers in the review process helps in sharing knowledge and ensuring code quality and logic accuracy while catching potential mistakes before code goes live.
  • Economic Rationale: The speaker stresses that implementing safety nets is not just about quality but also about reducing costs associated with bugs and fixes over time. The earlier errors are caught, the less expensive they are to resolve.
  • Conclusion and Recommendations: Philemotte concludes by encouraging developers to assess their current practices and gradually adopt safety nets. He emphasizes taking small steps toward improving safety protocols, such as automating tests or initiating peer reviews.

Through this presentation, Philemotte instills confidence in the software development process by advocating for proactive measures to catch errors. This approach enables developers to innovate and make changes without the heavy anxiety of potential failures, reinforcing the idea that utilizing safety nets not only improves reliability but also enhances overall productivity in coding practices.

Safety Nets: Learn to Code With Confidence
Christophe Philemotte • June 27, 2014 • Singapore • Talk

Ruby gives you a great power, such as easy Duck Typing. As the saying goes, "With great power there must also comes great responsibility!" It comes at a price. We cannot afford to blow off everything when shipping. That's why it's important to put in place different strategies to help us to catch errors asap, but also to avoid the cruft long term. Like a safety net, they allow you to go forward with more confidence.

Help us caption & translate this video!

http://amara.org/v/FGY9/

Red Dot Ruby Conference 2014

00:00:20.480 hi um very pleased to to be here today
00:00:24.640 uh it's also my first talk at the Ruby
00:00:27.800 conference so
00:00:34.920 thanks especially you know the first
00:00:37.360 time you speak and the next speaker is
00:00:39.719 Aon it's kind of a little bit terrifying
00:00:42.559 but
00:00:43.360 well I try to do my best so I'm Kristoff
00:00:47.920 uh you can find me on Twitter and
00:00:50.520 gup uh I come from Belgium a tiny
00:00:53.520 country in Europe between Netherlands
00:00:55.600 and uh and France and we are known to
00:01:00.039 like beers and chocolate and in fact I
00:01:03.960 like beers and chocolate we have a lot
00:01:06.600 of different beers and different
00:01:09.280 chocolate I have because I think we we
00:01:12.720 do the the best chocolate in the world I
00:01:15.400 bring with me I think more than two
00:01:18.280 kilos of
00:01:19.560 chocolate
00:01:26.200 so after the iron talks what I propose
00:01:29.520 is that you come by me say hello and
00:01:32.240 take one piece of chocolate and taste
00:01:34.640 what we do quite the best in in the
00:01:37.759 world um Belgium is also known to do
00:01:41.159 some absess things very efficiently like
00:01:45.159 the previous government uh we need it
00:01:48.840 more than twice the time than the iraes
00:01:52.719 they they have need to to build their
00:01:54.640 own government was about 550 days and uh
00:02:00.000 well we did pretty well with uh you know
00:02:03.719 just a resigning
00:02:06.079 government uh we we we succeeded to to
00:02:10.080 have very good economical uh results
00:02:13.840 since more than 10 years so you you see
00:02:16.920 the kind of country we are I'm the
00:02:19.239 co-founder of Po review so it's an
00:02:21.319 automated code uh review tool for Ruby
00:02:25.800 uh it's presented like that if you don't
00:02:28.080 know we can talk that after the talk at
00:02:31.680 the party for instance um basically the
00:02:35.200 IDE is to give you feedback on your code
00:02:37.560 so you can know how to improve
00:02:40.480 it and today I would like to start not
00:02:43.560 with a software story but with uh a
00:02:47.560 story from uh my wife's
00:02:49.680 job she has uh every day she she goes to
00:02:54.080 job to with one goal which is curing
00:02:57.400 conquer and she's a med medical
00:03:00.760 physicist and she like to play with big
00:03:03.799 machine so this kind of machines the the
00:03:07.599 idea is to to to beam some electrons and
00:03:11.560 photons in order to uh to put energy at
00:03:15.159 a certain place in your body so it looks
00:03:18.280 like that you have different
00:03:20.080 beams and the idea is to deposit some
00:03:23.319 amount of energy on the Conker so you
00:03:25.920 can burn it and eradicate it so the
00:03:30.319 problem with that is that you have some
00:03:32.319 side effects like uh through the body
00:03:35.519 you deposit other energy so you can burn
00:03:38.439 the the skin and organic tissue you can
00:03:41.319 induce other secondary cancer so
00:03:44.400 something that you need to take care of
00:03:47.040 it needs a lot of people for one patient
00:03:50.159 it's about three nurses one doctor one
00:03:52.640 medical
00:03:53.599 physicist it's very complex and you need
00:03:56.239 to use complex program to calculate the
00:04:00.040 doses of energy that you would like to
00:04:02.879 to deposit on the
00:04:04.400 canker it's long it's not only the
00:04:07.480 treatment but it's also the diagnosis
00:04:10.040 the measurements to posate correctly the
00:04:13.079 patient on the machine to to to check if
00:04:16.639 everything is is goes well and so on and
00:04:20.600 because of all of that it cost a lot
00:04:23.199 just for one treatment You Can Count
00:04:25.639 between
00:04:27.120 $3,000 and $15,000
00:04:30.240 just for one
00:04:32.479 treatment that means that if you do one
00:04:35.520 error you can have an ineffective
00:04:38.199 treatment you can have some casualties
00:04:40.960 like burning like secondary
00:04:44.000 cancer it's costly and time consuming to
00:04:47.000 fix their errors you can break the
00:04:49.919 equipment the machine that means that at
00:04:52.560 the end you you will make the people
00:04:55.960 busy to fix their error or to fix the
00:04:59.080 machine and finally you cannot treat
00:05:01.880 other patients and other cancer so it's
00:05:05.080 very important to try to do less uh
00:05:09.320 possible errors that you can so she as
00:05:13.080 an engineer she tries to do her best and
00:05:17.440 her best is to catch errors as earlier
00:05:20.039 as possible and to mitigate the risk to
00:05:22.800 do error how she can do that for
00:05:26.280 instance she has to check if the machine
00:05:29.240 is working correctly so on the left you
00:05:32.960 have a a cube of water it's a good model
00:05:37.360 of the human body and they do some
00:05:40.560 measurements to check if the machine uh
00:05:43.479 beams correctly and uh so you have the
00:05:47.319 the correct energy so when you use a
00:05:49.639 machine you know that uh it's it's
00:05:52.440 correct uh you do also invivo
00:05:55.280 measurement so during the treatment you
00:05:57.319 put some diode on the the body of the
00:05:59.759 person so you can check again at
00:06:02.520 specific point if the energy is
00:06:05.880 correct you need also to be sure that
00:06:08.360 your calculation are
00:06:10.000 correct um you use P review or other
00:06:14.440 program uh other program to calculate uh
00:06:18.120 your your your your treatment or
00:06:21.080 sometimes you just do some quick hand
00:06:23.360 calculation to check their order of
00:06:27.120 magnitude you have to check also if the
00:06:29.639 requirements have been met like because
00:06:32.280 the machine has some physical limitation
00:06:35.400 or because if you go too high in the
00:06:38.560 energy uh you know that you will induce
00:06:41.520 other cancer so you need to check those
00:06:44.319 constraints and again one way to do that
00:06:47.319 is to use peer review or to to follow
00:06:50.360 some ISO process uh and for instance in
00:06:53.880 that process uh it's it's uh it's noted
00:06:57.360 that you have to do pay review and so
00:07:02.240 it sounds probably familiar to you and
00:07:05.160 it's for a good reason and we will talk
00:07:08.039 that
00:07:09.400 later the reason that we put those
00:07:12.599 strategies in place is that because we
00:07:15.000 are IM human and you know like armor we
00:07:19.440 make mistake just because we are tired
00:07:22.879 or you know inative or you just miss
00:07:26.080 something and because we are human and
00:07:29.240 we know know that we are we we can fail
00:07:33.000 it's finally in your our decision to do
00:07:36.520 something or not as you know if you have
00:07:39.440 a pool and a baby you don't have you
00:07:42.680 don't want to find your baby drawn in
00:07:44.520 the pool so you put in place some some
00:07:49.159 some equipment some safety nets to be
00:07:51.520 sure to to keep it safe so what we can
00:07:55.919 do in radiotherapy we do it also in
00:07:58.720 civil engineering ing in manufacturing
00:08:01.039 and also in software
00:08:03.759 development it's what I call safety nets
00:08:06.479 it's the ID that you put in place safety
00:08:09.680 nets so in case you fail it will catch
00:08:12.560 you up and uh you you can continue and
00:08:16.319 uh nothing blows up so in an ideal world
00:08:21.479 you would like to have only one safety
00:08:23.720 net that catch everything but you know
00:08:27.319 there are no silver bullets so
00:08:29.960 you try to have different kind of safety
00:08:32.240 nets to to catch different kind of
00:08:35.120 errors and in the end it's really a
00:08:37.880 trade-off between the cost of safety
00:08:40.279 nets your knowledge your skills and also
00:08:42.919 what you want to
00:08:44.480 achieve and the real ideas with do
00:08:48.360 safety nets is to get be to to be
00:08:50.959 informed so you know if there's an errow
00:08:54.120 and that you can catch it uh and you
00:08:57.000 inform it you can decide if if you fix
00:09:00.760 it or if you let that error in place and
00:09:04.920 in software development I think the
00:09:07.399 three common one are test static
00:09:10.320 analysis and code review I will
00:09:12.680 illustrate the the tree uh and for that
00:09:16.640 we go through a very simple invoicing
00:09:19.760 application I'm sure that everybody has
00:09:23.040 already deal with that so the idea of
00:09:28.360 test it's that you can write before or
00:09:32.680 after that's not the question here um in
00:09:35.720 the in the in the invoicing application
00:09:38.279 you you have different items in your
00:09:40.760 invoice each item has a price and a
00:09:44.279 quantity and you would like that if the
00:09:48.079 the invoice is empty that the total is n
00:09:52.040 and if you have different items the
00:09:54.519 total should be correct and if you
00:09:56.920 update the quantity of item stand you
00:10:00.959 update also the the total after very
00:10:04.519 basic we write the class invoice initial
00:10:09.279 initializer the the method to add the
00:10:11.480 items nothing very complicate and the
00:10:15.360 total
00:10:16.560 method that's calculate the method so we
00:10:19.480 go through all the items and we sum over
00:10:22.399 the multiplication of price and
00:10:25.560 quantity okay you run the test
00:10:27.839 everything is green yeah you did a great
00:10:30.839 job and now for any reason you decide
00:10:34.959 that you would like to make the total an
00:10:37.760 attribute member you put it in the
00:10:41.920 initializer you update the total
00:10:44.800 meod and you run the test and they're
00:10:49.519 red in fact when you you change your
00:10:52.760 code you you did it too quickly and you
00:10:56.160 miss it that it was important to reset
00:10:58.399 the total at the the beginning of the
00:11:00.560 the method so because your test were
00:11:03.880 broken you know there's a problem and
00:11:05.959 you can't fix
00:11:07.360 it so the idea of tests their benefits
00:11:10.760 is that they allow you to check the
00:11:13.079 functionality of your software only the
00:11:16.240 functionality that you can think before
00:11:18.560 that you think how your software should
00:11:22.000 behave um if you discover some edge
00:11:24.920 cases or some bugs after afterwards you
00:11:27.839 can write
00:11:29.880 regression test to to check if later uh
00:11:33.000 you you you the the bugs are are are
00:11:36.920 really fixed and that you deal correctly
00:11:40.440 with those Edge Edge cases of course the
00:11:43.680 the tests have some drawbacks like you
00:11:46.880 know what are we testing are we sure
00:11:49.920 that we test everything so with test
00:11:52.160 coverage report you can have an IDE how
00:11:55.000 you cover your code base um has someone
00:11:58.600 launched the test test especially you
00:12:00.920 know you don't ship your machine in
00:12:04.120 production so that's why it's important
00:12:06.519 to automate the test with a CI and to
00:12:09.000 have a test environment the closest
00:12:11.240 possible to the
00:12:13.320 production and that's the typical
00:12:16.040 question of manager who test the test uh
00:12:18.920 there's also some strategy to to be sure
00:12:21.760 that your test are correct with test
00:12:24.160 mutation like with the mutant gem they
00:12:27.920 basically they change your code and they
00:12:30.440 verify that when you change the code
00:12:32.760 your test
00:12:34.959 fail so that was for the test for St
00:12:38.120 static
00:12:39.079 analysis there are some there are a
00:12:41.880 program that read your code that don't
00:12:44.440 interpret your code and they try to um
00:12:47.880 to to find to underline problems in your
00:12:50.639 in your code they try also to measure
00:12:53.279 some specific Char Char properties like
00:12:58.120 if it's readable
00:13:00.639 maintainable so here I would like to
00:13:03.480 handle vat which is a sales tax in
00:13:06.880 Europe it's quite complex basically if
00:13:10.320 you come if you sell from a given
00:13:12.880 country uh to another country and that
00:13:15.560 your customer is a company or not you
00:13:17.680 don't apply the same sales tax so for
00:13:20.920 instance if I'm a Belgium company and I
00:13:22.959 sell to a person or a company I need to
00:13:25.920 apply to one person but if I sell to
00:13:30.399 another European company the rate is
00:13:32.959 null and so on so it's complex it's like
00:13:35.440 that we cannot do anything against
00:13:39.199 that so it's complex uh we have that
00:13:42.360 feeling but we have tool to measure that
00:13:46.040 complexity like flug and the idea is to
00:13:49.560 give you a score if if the score is high
00:13:53.399 uh it's a kind of proxy to tell you that
00:13:55.839 it's hard to read and that means if it's
00:13:58.120 hard to read it will be hard to change
00:14:01.000 and there's there is a high risk to
00:14:03.399 introduce a
00:14:04.959 bug and you know complexity at the end
00:14:08.240 could like that and you know when you
00:14:11.079 need to change a wire you don't know
00:14:13.920 where to start that could happen in your
00:14:16.800 code so to be sure that uh it's easy to
00:14:21.040 read you try to fix it as early as
00:14:24.839 possible um well so it's complex but we
00:14:27.839 continue to uh to Implement other things
00:14:30.320 like we would like to issue some quote
00:14:32.800 and a quote is basically an invoice but
00:14:35.000 with a given total but the quote has
00:14:38.519 also to handle the V so we very lazy and
00:14:42.160 we copy paste the the the
00:14:46.079 vat uh that's okay maybe at the
00:14:48.759 beginning but at certain point you need
00:14:50.519 to remove that
00:14:52.079 duplicate hopefully even if you forget
00:14:54.720 it there's a tool that check the
00:14:56.600 duplicate it's like fle
00:14:59.680 and it tell you that you find two piece
00:15:02.759 of code similar in different
00:15:07.600 files so we know that we need to
00:15:10.160 refactor our total meod and we start by
00:15:13.120 the beginning we extract uh the first
00:15:16.600 part which is the calculation of the sub
00:15:19.079 total um so we create a new private
00:15:23.000 method we put that code in that private
00:15:26.399 method we do we try to use uh the reduce
00:15:31.399 uh
00:15:32.600 ome okay the test are green everything
00:15:35.319 is okay but with Ruby or rubber cup you
00:15:39.240 can check that there are some flows in
00:15:42.560 that piece of code in fact if we come
00:15:45.800 back here we still have that local
00:15:49.000 variable total but it's useless and we
00:15:52.079 have assigned something it's useless
00:15:54.440 because in the block we have a parameter
00:15:56.720 with the same name that shadow the the
00:15:59.120 local variable that means that if you
00:16:02.160 get it's it's a dead code and at certain
00:16:05.560 point it could be a problem later and
00:16:08.600 the same when you Shadow another
00:16:10.639 variable it's probably not the best
00:16:13.120 thing you want to do hopefully with
00:16:15.560 rubocop or Ruby Runnings you can be
00:16:19.040 informed of those problem and because of
00:16:22.519 that uh you can then refactor your
00:16:26.120 subtotal uh method and make it better
00:16:31.040 so with static analysis you can check
00:16:32.959 flows in your code and
00:16:35.120 smells uh you need to be sure that you
00:16:38.240 run them like the test so you can use a
00:16:42.199 CI with the gem Dev tool or a specific
00:16:45.199 rate task use oet uh software as a
00:16:49.399 service like cod climate or or po
00:16:52.560 review you can get some false positive
00:16:55.399 of course they are machine they are not
00:16:57.680 perfect but but they're probably not
00:16:59.920 perfect but they are better than us
00:17:02.319 because each time you run them you be
00:17:04.919 sure that if there's problem and they
00:17:06.720 are able to detect it they will report
00:17:09.120 you uh that problem and Jordan kach if
00:17:12.559 you know it it's the guy behind Doom you
00:17:15.319 know ID3 software the famous very old
00:17:19.640 video game and uh for him it's really
00:17:24.079 important uh to use Technic analysis
00:17:26.640 because maybe your automation will fail
00:17:30.360 but all failures are legent as a human
00:17:34.320 and the fact that the static analysis
00:17:37.080 will be very consistent and that each
00:17:39.559 time you run it it will report the
00:17:41.440 problem you know every single time that
00:17:44.400 value is very
00:17:47.000 huge so you have test static analysis
00:17:51.000 they they help you to to to check
00:17:53.640 functionality and if there are no
00:17:55.520 problems in your codes but they don't
00:17:57.679 tell you how you can can improve your
00:17:59.679 code and code review for that is really
00:18:03.120 really useful it's the idea to ask a
00:18:06.760 colleague uh how you could fix something
00:18:09.559 to check your code read it if the naming
00:18:12.200 is correct and at the end it's the ID to
00:18:16.480 spread knowledge and for instance oh I
00:18:18.520 don't know how to remove duplicates and
00:18:20.760 your colleague know the okay you can
00:18:23.840 extract the V viit uh rate calculation
00:18:27.520 put it in a module and specific method
00:18:31.600 and then you make it the total method
00:18:34.280 very simple only three lines and it's
00:18:37.880 easier to read and hopefully uh you
00:18:41.559 don't have any more
00:18:43.679 duplicates and indeed when you run
00:18:46.559 fle it didn't find any duplicates we can
00:18:50.760 go further and you know extract
00:18:52.880 everything that's relate to a country in
00:18:54.799 a dedicated country uh class and to make
00:18:58.919 it more meaningful when you test over
00:19:02.000 it and when you will run flog uh you
00:19:05.919 have a lower lower score for the
00:19:08.919 complexity that means it's more readable
00:19:11.240 and again you informed that uh you have
00:19:15.679 a more readable um code
00:19:18.799 source so the idea of code review is
00:19:21.480 really to spread the
00:19:22.840 knowledge and with code review because
00:19:26.520 we are humans we can check anything
00:19:29.799 but because we are humans we cannot
00:19:32.799 check everything every time and that's
00:19:36.360 why it's not you know the the Silver
00:19:39.559 Bullet uh and it's very complementary
00:19:42.200 with test and static
00:19:44.640 analysis so I I have uh Illustrated uh
00:19:49.280 the different kind of uh safety nets
00:19:51.640 that you that you can put in place and
00:19:56.039 you know the we don't do that without
00:19:58.880 purpose the the the real goal is that
00:20:01.960 you want to reduce the cost and the risk
00:20:04.080 to introduce errors in your code when
00:20:07.080 you change it because more and more you
00:20:10.360 wait more it will cost you if you can
00:20:13.320 fix something at the moment you ride the
00:20:15.520 code it's far cheaper than you know
00:20:18.240 waight too cheap in production and then
00:20:20.440 that it blow off your your your your
00:20:23.280 your product and as Kil said yesterday
00:20:27.880 uh you can even be so confident in your
00:20:30.880 code that you can go to continuous
00:20:34.919 deployment Martin Fuller reminds
00:20:38.000 recently that it's not about writing
00:20:40.280 clean code to have the best quality it's
00:20:42.919 really about the
00:20:44.200 economics and because we are only humans
00:20:48.000 we want to do the we are lazy and if we
00:20:51.799 can do something in less time and with
00:20:54.960 less money I think we would be happy to
00:20:57.840 do it so with different kind of safety
00:21:01.080 nets you could be more confident to
00:21:03.799 there something and to go forward to you
00:21:07.480 know just change your code and not be
00:21:10.200 scared each time you change one line in
00:21:12.520 your code base uh that it could
00:21:16.159 introduce a bug so you just change it
00:21:18.919 and if there's a problem the safety net
00:21:21.159 will catch you and uh you can continue
00:21:24.320 without uh any
00:21:27.120 worriness so
00:21:29.039 yeah the reason if you have two options
00:21:31.799 A and B and maybe you are too busy to
00:21:35.760 improve but with some time you can make
00:21:39.440 it better and you can go f farther and
00:21:43.559 faster so the question the last question
00:21:47.440 is where you can start I presented you
00:21:50.679 different solution uh just take a look
00:21:53.919 of what you do today if you do test but
00:21:56.320 you don't automate them you should start
00:21:59.120 Maybe by that uh if you do test and have
00:22:02.279 a CI but don't do code review or static
00:22:05.279 analysis just pick a tool and uh start
00:22:09.279 to use it and try to find if it's useful
00:22:12.640 for you in your workflow or ask a
00:22:15.320 colleague to to to read each time you
00:22:18.080 finish a feature Branch to read your
00:22:19.919 code and give you feedback just step by
00:22:23.480 step do a first one a very tiny one and
00:22:27.080 uh at the end you will which you know
00:22:30.360 probably more you you will cover more
00:22:33.840 distance that you can expect at the
00:22:36.279 beginning that's it you can find the the
00:22:39.919 the code I presented uh in a git
00:22:42.640 repository each commit represent a
00:22:45.520 different step and uh you can find me on
00:22:49.200 Twitter GitHub or po review and don't
00:22:52.720 forget chocolate
00:23:01.919 thanks chrisha any questions for
00:23:05.080 him hi uh thanks for the talk I think
00:23:08.320 along with flock play uh you I think you
00:23:11.559 should also talk about the security
00:23:12.720 features using break M any thoughts on
00:23:15.120 that what I what I think about security
00:23:17.799 security about our applications buil
00:23:19.480 using Breakman yeah Breakman is is
00:23:22.679 effectively capable to to to check your
00:23:26.120 real application and different kind of
00:23:28.919 security
00:23:30.559 vulnerabilities they could be simple but
00:23:33.400 the they are quite common mistake that
00:23:36.279 you can do so it's really useful to have
00:23:39.400 breckman uh check your code and uh be
00:23:42.440 sure that at least the common errors uh
00:23:46.039 have been
00:23:47.240 covered perfect I think it should also
00:23:49.520 be a part of a presentation which was
00:23:50.760 pretty cool um the the other question I
00:23:53.880 had was also around having good coding
00:23:57.120 guidelines can also help you recover
00:23:59.279 from a lot of issues uh sometimes you're
00:24:02.559 converting a a parameter in your
00:24:05.159 controllers into a symbol and stuff like
00:24:07.640 this uh break man catches a lot of this
00:24:10.360 yeah but having these kind of code Lin
00:24:11.960 are they going to be part of your
00:24:13.120 repository because that would be really
00:24:14.640 really
00:24:15.559 helpful could you coding guidelines
00:24:18.159 towards how you go about writing good
00:24:20.520 code from from the start yeah the
00:24:23.400 excessive use of you know instance
00:24:25.480 variables or excessive use of symbols
00:24:28.200 and and uh how you code such that you're
00:24:31.200 always writing code which is not going
00:24:33.320 to get you a larger flock
00:24:35.440 score are you going to have such coding
00:24:37.480 guidelines written down somewhere um not
00:24:40.480 sure to have understand um sorry so try
00:24:44.559 to to recap in other words so how could
00:24:48.360 we use scur to make it better from the
00:24:51.000 beginning or so simply put uh if you
00:24:55.440 could add a little bit more content
00:24:57.399 about break man
00:24:59.120 and something about coding guidelines
00:25:02.000 start programming to ensure that we get
00:25:04.200 a good flock score rather than me
00:25:06.600 running flog every time yeah to reduce
00:25:09.679 my score okay so um guideline about that
00:25:14.279 I think it's um at a certain point you
00:25:16.919 can increase the complexity because you
00:25:19.600 need to to um when you reflector your
00:25:23.200 code um sometimes it's not important
00:25:26.120 that your code is complex just because
00:25:28.399 you need to move the things and find a
00:25:31.520 good way to to uh to the the the best
00:25:34.600 way to to abstract your things so it's
00:25:38.840 interesting to know it's complex because
00:25:41.080 you can spot where are the problems and
00:25:44.000 when you spot the problems you you start
00:25:46.399 to uh to to refactor that Parts but you
00:25:49.880 don't care about the score you just
00:25:52.520 check them uh frequently just um until
00:25:57.279 you you you really reach a reasonable uh
00:26:00.600 state where your code is more readable
00:26:03.080 and simpler to read and indeed when you
00:26:05.960 can split the things in different
00:26:07.720 modules that are very simple and and
00:26:10.360 more short and and shorter uh usually
00:26:13.080 your score your complety score for each
00:26:15.080 modu will be lower uh in in fact what
00:26:18.760 you do is you spread your complexity but
00:26:21.159 because you have individual models they
00:26:23.720 are just you know very dedicated to a
00:26:27.440 simple task it's easier to to understand
00:26:30.120 and to read it so it will be uh easier
00:26:33.720 to change it without introduce a BG have
00:26:37.279 I answered your question yes relatively
00:26:39.480 well thank you so much and apart from
00:26:41.960 the chocolate have you also got some
00:26:43.159 Belgium beer for
00:26:44.679 tasting yeah I'm sorry the problem with
00:26:47.320 beers that my flight were about 15 hours
00:26:51.960 and they they are far more heavy than
00:26:56.039 chocolate so if I if I needed to bring
00:26:59.960 400 beers I'm not sure that it will be
00:27:04.480 feasible you know you would have been
00:27:06.760 more popular than the gold Ed sponsors
00:27:09.520 here that could be a good go for the
00:27:12.000 next
00:27:18.640 one thank you thanks
00:27:28.360 d
Explore all talks recorded at Red Dot Ruby Conference 2014
+20