<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Riyoth's Blog</title><link>https://blog.riyoth.ca/posts/</link><description>Recent content in Posts on Riyoth's Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Wed, 26 Jun 2024 13:38:50 -0400</lastBuildDate><atom:link href="https://blog.riyoth.ca/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Refactoring Checklist</title><link>https://blog.riyoth.ca/posts/refactoring-checklist/</link><pubDate>Wed, 26 Jun 2024 13:38:50 -0400</pubDate><guid>https://blog.riyoth.ca/posts/refactoring-checklist/</guid><description>&lt;p>Refactoring is a critical part of writing software and should be encourage. Good test make the process much easier.&lt;/p>&lt;h3 id="definition">Definition&lt;/h3>&lt;p>During a refactoring you will improve a pieces of codes without changing it&amp;rsquo;s behavior. Improving code can take multiple form. You can refactor to improve performance, readibility, remove a deprecated library or make the code easier to test.&lt;/p>&lt;p>A few rules to follow when refactoring:&lt;/p>&lt;ul>&lt;li>A refactoring shouldn&amp;rsquo;t change the behavior.&lt;/li>&lt;li>You shouldn&amp;rsquo;t change the method/function signature.&lt;/li>&lt;li>The tests shouldn&amp;rsquo;t change.&lt;/li>&lt;/ul>&lt;h3 id="when-to-refactor">When to refactor&lt;/h3>&lt;p>When should you refactor your code. The easy answer is all the time but that not always possible. In the Test driven development world it&amp;rsquo;s a integral part of writing software. The process goes as follow:&lt;/p>&lt;ul>&lt;li>Write test&lt;/li>&lt;li>Write code to make the test pass&lt;/li>&lt;li>Refactor your code&lt;/li>&lt;/ul>&lt;p>It&amp;rsquo;s a good process for new code but we don&amp;rsquo;t always write new code. You refactore to cleanup your code for the next persons. For existing code, refactore before a big change to make the change easier.&lt;/p>&lt;h3 id="the-check-list">The Check list:&lt;/h3>&lt;p>Follow those step to make your refactoring easier:&lt;/p>&lt;ul>&lt;li>Start with a commit, for easy revert&lt;/li>&lt;li>use in-line variable instead of declaring variable only to pass it to a function&lt;/li>&lt;li>Don&amp;rsquo;t repeat yourself (but don&amp;rsquo;t do it too much)&lt;/li>&lt;li>Extract &amp;ldquo;Magic&amp;rdquo; values&lt;/li>&lt;li>Make public function easy to scan, extract specification in private method&lt;/li>&lt;li>Move value creation to construction time,&lt;/li>&lt;li>Try to remove comment, make the code easier to understand&lt;/li>&lt;/ul>&lt;h3 id="refactoring-excerices">Refactoring excerices&lt;/h3>&lt;ul>&lt;li>&lt;a href="https://github.com/emilybache/GildedRose-Refactoring-Kata">Gilded Rose&lt;/a>&lt;/li>&lt;/ul></description></item><item><title>Bennett Principle</title><link>https://blog.riyoth.ca/posts/bennett-principle/</link><pubDate>Tue, 11 Jun 2024 20:14:44 -0400</pubDate><guid>https://blog.riyoth.ca/posts/bennett-principle/</guid><description>&lt;p>In Digital Minimalism, &lt;a href="https://calnewport.com/">Cal Newport&lt;/a> covers the Bennett principle as a way to live a more fulfilling life.&lt;/p>&lt;p>The Bennett principle: We should dedicate our leisure time to challenging activities: they are more engaging, rewarding, and don&amp;rsquo;t tire as much as you&amp;rsquo;d think.&lt;/p>&lt;p>Lesson 1: Prioritize demanding activity over passive consumption.Lesson 2: Use skill to produce valuable things in the physical world.Lesson 3: Seek activities that require real-world, structured social interaction&lt;/p>&lt;p>In practice, this principle could take the following form in your life:&lt;/p>&lt;ul>&lt;li>fix or build something every week&lt;/li>&lt;li>Join something&lt;/li>&lt;li>Schedule your low-quality leisure&lt;/li>&lt;/ul></description></item><item><title>The Software engineering Guidebook</title><link>https://blog.riyoth.ca/posts/swe-guidebook-1/</link><pubDate>Tue, 11 Jun 2024 20:10:32 -0400</pubDate><guid>https://blog.riyoth.ca/posts/swe-guidebook-1/</guid><description>&lt;p>Lately, I had to reflect on my career orientation and objectives. I asked my network for a book recommendation on my career. Keven Larcheveque recommended The Software Engineer Guide book by &lt;a href="https://blog.pragmaticengineer.com/author/gergely/">Gergely Orosz&lt;/a>. After reading the book, I&amp;rsquo;m surprised a book can contain so many insights. Most of the ideas covered in the book are simple but I&amp;rsquo;ve never seen them explicitly listed.&lt;/p>&lt;p>I learned so much just by reading part 1. It should be taught to any professional. Here are some of the highlights:&lt;/p>&lt;ol>&lt;li>You are in charge of your career, own it. People around you will help, but you have to lead.&lt;/li>&lt;li>Document your work. Build a work log of your accomplishments, write in it daily, and review it weekly. This is the base for your performance review, resume update, and promotion campaign.&lt;/li>&lt;li>Get to know the business: understand what matters to the company and how impact is measured. Ask questions and determine the key metrics. Your work should improve these indicators. Align your goal with the organization&amp;rsquo;s objectives.&lt;/li>&lt;li>Build connections outside your team: work with your product manager but talk with your customer and other specialists. This will help you understand their need and propose valuable initiatives. It will speed up discussion and make development faster.&lt;/li>&lt;li>Share your work with your manager, colleagues, other teams, and outside work if possible. It&amp;rsquo;s a great way to build relationships, gather feedback, and reduce duplication of labor.&lt;/li>&lt;li>Above all, ask for feedback. Precise and actionable feedback. Criticism is great to identify areas to improve, Positive feedback looks amazing on your performance review.&lt;/li>&lt;/ol>&lt;p>It might seem obvious but having those ideas written down is very helpful. I&amp;rsquo;ve done most of those things with diverse degrees of consistency but now I have a good reference.&lt;/p></description></item></channel></rss>