<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:media="http://search.yahoo.com/mrss/"><channel><title>workflow on Neolisk's Tech Blog</title><link>/tags/workflow/</link><description>Recent content in workflow on Neolisk's Tech Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>neolisk@gmail.com (Victor Zakharov)</managingEditor><webMaster>neolisk@gmail.com (Victor Zakharov)</webMaster><copyright>©2020-2024 Victor Zakharov. All Rights Reserved</copyright><lastBuildDate>Sat, 24 Feb 2024 00:00:00 +0000</lastBuildDate><atom:link href="/tags/workflow/index.xml" rel="self" type="application/rss+xml"/><item><title>Don't Reinvent the Wheel</title><link>/posts/2024-02-24-dont-reinvent-the-wheel/</link><pubDate>Sat, 24 Feb 2024 00:00:00 +0000</pubDate><author>neolisk@gmail.com (Victor Zakharov)</author><atom:modified>Sat, 24 Feb 2024 10:48:14 -0500</atom:modified><guid>/posts/2024-02-24-dont-reinvent-the-wheel/</guid><description>In the dynamic world of software development, the inclination to &amp;ldquo;reinvent the wheel&amp;rdquo; represents a common challenge. Developers, driven by a desire for customization and control, often venture into creating bespoke solutions for problems that have already been addressed.
This approach, while showcasing technical prowess, can lead to inefficiencies, consuming precious time and resources that could be better allocated to enhancing the core value of the project. Recognizing this, the strategic use of third-party component libraries emerges as a compelling alternative.</description><dc:creator>Victor Zakharov</dc:creator><category>development</category><category>architecture</category><category>workflow</category><category>components</category><category>library</category></item><item><title>Value of 100% Test Coverage</title><link>/posts/2024-02-18-value-of-100-percent-coverage/</link><pubDate>Sun, 18 Feb 2024 00:00:00 +0000</pubDate><author>neolisk@gmail.com (Victor Zakharov)</author><atom:modified>Sun, 18 Feb 2024 16:23:03 -0500</atom:modified><guid>/posts/2024-02-18-value-of-100-percent-coverage/</guid><description>In the realm of software development, striving for 100% test coverage often generates heated debates, with critics labeling it as overly ambitious and of little practical value due to the considerable effort required. However, I contend that aiming for full test coverage transcends mere code quality, playing a crucial role in promoting fairness and discipline within a team. This approach not only challenges the conventional wisdom by highlighting the significant, often overlooked benefits for teams of varying skill levels, but also underscores the importance of setting high standards in collaborative environments.</description><dc:creator>Victor Zakharov</dc:creator><category>unit tests</category><category>code coverage</category><category>development</category><category>workflow</category></item></channel></rss>