Skip to content

Commit

Permalink
chore: update via GitHub Actions
Browse files Browse the repository at this point in the history
  • Loading branch information
@github-actions
github-actions[bot] committed Jan 23, 2025
1 parent c921183 commit a9225d8
Show file tree
Hide file tree
Showing 2 changed files with 331 additions and 0 deletions.
8 changes: 8 additions & 0 deletions posts/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -217,6 +217,14 @@ <h1 class="Article-title">Blog</h1>

<h2 class="ArticleList-heading">2022</h2>

<div class="ArticleList-item"><time datetime="2022-10-24T06:05:00.000Z">2022-10-24</time><i class="fa fa-pencil"></i><a href="/posts/the-effect-of-knowledge-on-efficiency-part-1/">The Effect of Knowledge on Efficiency Part 1</a></div>







<div class="ArticleList-item"><time datetime="2022-06-24T21:53:07.000Z">2022-06-25</time><i class="fa fa-pencil"></i><a href="/posts/survival-in-software-team/">Survival in Software Team</a></div>


Expand Down
323 changes: 323 additions & 0 deletions posts/the-effect-of-knowledge-on-efficiency-part-1/index.html
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,323 @@
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<meta charset="UTF-8">

































<title>The Effect of Knowledge on Efficiency Part 1</title>


<meta property="og:title" content="The Effect of Knowledge on Efficiency Part 1">


<meta name="description" content="List the common problems in daily work, and keep it a secret first~">
<meta property="og:description" content="List the common problems in daily work, and keep it a secret first~">








<meta name="keywords" content="Ourai.PRO,ourai.pro,Ourai Lin,Ourai L.,Ourai,Ourairyu,欧雷,欧雷流,anti-chaos,ntks,反混沌,反混沌工程师,DnA ENGR,dna engr,frontend,front-end,indie developer">


<!-- 页面渲染兼容性 -->
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="renderer" content="webkit">
<meta name="viewport" content="width=device-width,initial-scale=1.0">

<!-- 订阅 -->

<meta name="theme-color" content="#0871ab">
<link rel="shortcut icon" href="/images/ksio/favicon.ico">



<link rel="stylesheet" href="/stylesheets/global.css">


<link rel="stylesheet" href="/stylesheets/ksio/vendors/share.css">

<link rel="stylesheet" href="/stylesheets/pages/post.css">


<script src="/javascripts/ksio/vendors/jquery-1.11.3.min.js"></script>


<script src="/javascripts/ksio/vendors/bootstrap.min.js"></script>

</head>


<body class="Page" itemscope itemtype="http://schema.org/WebPage">


<header class="Page-header">
<div class="navbar navbar-static-top">
<div class="container">
<div class="navbar-header">

<button class="navbar-toggle collapsed" type="button" data-target=".Page-navs" data-toggle="collapse">
<span class="sr-only">Toggle navs</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>





<a class="navbar-brand" href="/">Ourai.PRO</a>



</div>
<!-- Nav menus -->
<nav class="Page-navs navbar-collapse collapse">
<ul class="nav navbar-nav navbar-right">


<li class="dropdown">
<a class="dropdown-toggle" href="javascript:void(0);" data-toggle="dropdown">Blog <span class="caret"></span></a>
<ul class="dropdown-menu">

<li><a href="/posts/">Posts</a>
</li>



<li><a href="https://x.com/ntksol?utm_source=https://ourai.pro&amp;utm_medium=common-header" target="_blank" rel="external nofollow">Tweets</a>
</li>


</ul>
</li>



<li class="dropdown">
<a class="dropdown-toggle" href="javascript:void(0);" data-toggle="dropdown">Works <span class="caret"></span></a>
<ul class="dropdown-menu">

<li><a href="https://producthunt.com/@ourai?utm_source=https://ourai.pro&amp;utm_medium=common-header" target="_blank" rel="external nofollow">Products</a>
</li>



<li><a href="https://github.com/ourai?utm_source=https://ourai.pro&amp;utm_medium=common-header" target="_blank" rel="external nofollow">Open-source software</a>
</li>


</ul>
</li>



<li class="dropdown">
<a class="dropdown-toggle" href="javascript:void(0);" data-toggle="dropdown">Cooperation <span class="caret"></span></a>
<ul class="dropdown-menu">

<li><a href="https://www.upwork.com/freelancers/~016baa7fae7cfff661?utm_source=https://ourai.pro&amp;utm_medium=common-header" target="_blank" rel="external nofollow">Services</a>
</li>


</ul>
</li>



<li class="dropdown">
<a class="dropdown-toggle" href="javascript:void(0);" data-toggle="dropdown">About <span class="caret"></span></a>
<ul class="dropdown-menu">

<li><a href="https://www.linkedin.com/in/ourai?utm_source=https://ourai.pro&amp;utm_medium=common-header" target="_blank" rel="external nofollow">Resume</a>
</li>


</ul>
</li>



<li><a href="https://yaol.in/?utm_source=https://ourai.pro&amp;utm_medium=common-header" target="_blank" rel="external nofollow">中文</a>
</li>



</ul>
</nav>
</div>
</div>
</header>

<main class="Page-content">


<!-- 内容主体 -->
<div class="container">
<article class="Page-main Article">
<header class="Article-header">


<h1 class="Article-title">The Effect of Knowledge on Efficiency Part 1</h1>




</header>
<div class="Article-content col-md-9"><p>The topic of “improving efficiency” is vast and encompasses many aspects. Although it is related to technology and tools, these are relatively less important. The cognition, awareness, and behaviors of the people involved in activities are far more significant!</p>
<p>In <a href="/posts/human-factors-in-software-production-part-1/">Human Factors in Software Production Part 1</a> and <a href="/posts/human-factors-in-software-production-part-2/">Human Factors in Software Production Part 2</a>, I attempted to elaborate on the impact of “people” on “efficiency”. In this article and the next two, I will try to address the issue of “efficiency” from the perspective of “knowledge”.</p>
<h2 id="Common-Issues"><a href="#Common-Issues" class="headerlink" title="Common Issues"></a>Common Issues</h2><p>The problems we encounter in our daily work are largely centered around division of labor, collaboration, and communication—among people, between people and machines, and among machines.</p>
<h3 id="Business-Support"><a href="#Business-Support" class="headerlink" title="Business Support"></a>Business Support</h3><p>When it comes to supporting business functions, how does the front-end operate?</p>
<p>The mainstream approach in front-end development today is to build a “page component” for the corresponding business function on top of basic components (and at most, so-called “business components”). After a series of intense operations, at least several hundred lines of code are generated. If the layout and interaction are slightly complex, breaking a thousand lines is a piece of cake.</p>
<p>When designers and product managers review the work, they are delighted. The fidelity is high, and there are no “glitches”. However, after a few months or even a year or two, when it comes time to add new features or make adjustments, opening the code file leaves one bewildered—</p>
<p>What was the business logic again? Why was this part written this way? How can such a small adjustment require changes in so many places? This area is too complex; I dare not change it. If something goes wrong, I’ll be the one to blame…</p>
<p>Experienced individuals can identify the main issues and know how to avoid them, including those who originally wrote the code—</p>
<p>Refactor the code and logic by splitting them into separate files; use semantic naming to make implicit knowledge explicit and reduce meaningless comments; abstract modules with high cohesion and reusability; follow various “principles” and employ sophisticated “patterns”…</p>
<p>However, in reality, few people are truly motivated to do these things. Writing good code does not lead to promotions or salary increases. Moreover, most of us have no “legitimate reason” to demand that others write good code—unless it becomes an administrative policy.</p>
<p>The mainstream model of front-end development in business support, combined with human laziness, creates significant barriers in communication between people and machines.</p>
<h3 id="Job-Responsibilities"><a href="#Job-Responsibilities" class="headerlink" title="Job Responsibilities"></a>Job Responsibilities</h3><p>Some people have “unrealistic” expectations and demands for front-end practitioners—that front-end developers should understand the business. I find this absurd. It is nothing more than their “illusion”.</p>
<p>In general, the work that falls under the category of “front-end” includes website development, libraries, component libraries, CLI tools, development frameworks, and other areas focused on the “front-end” domain that are unrelated to the company’s “business”. The only area that is somewhat related to “business” is application development.</p>
<p>In companies that make a living from software and services, there are several roles and positions involving “front-end”: front-end engineer, front-end lead, full-stack engineer, application&#x2F;product developer (advocated by <a target="_blank" rel="noopener" href="https://zhuanlan.zhihu.com/p/426707646">Modern.js</a>), business architect, and product manager. Among them, the only “pure front-end” role, focused solely on the “front-end” domain, is the front-end engineer.</p>
<p>If a person’s job responsibilities are not limited to the “front-end”, they are not actually a front-end engineer and are unlikely to refer to themselves as one. Those who call themselves “front-end engineers” and claim that they “should&#x2F;need to understand the business” are probably acting passively—either because they were required to do so during job interviews or task assignments, or to meet KPIs and career advancement goals.</p>
<p>The “front-end” should be the domain of “front-end engineers” who focus on “business-agnostic” work—this is the premise. The front-end should concentrate on presentation and interaction, with no business semantics in the code. Communication with the front-end should also be business-agnostic, using language strongly related to presentation and interaction—stripping away all business-related elements from the “front-end” world.</p>
<p>However, in application development, there will inevitably be business-related elements. How should they be handled?</p>
<p>After using appropriate architecture and frameworks to separate business semantics, logic, and state from UI components, non-front-end personnel (through tools like <a target="_blank" rel="noopener" href="https://handiejs.github.io/">Handie</a>) should be responsible for defining domain models and controlling business-related states.</p>
<p>“Non-front-end personnel” refers to anyone other than “front-end engineers” who focus on “business-agnostic” work—roles such as front-end leads, full-stack engineers, application&#x2F;product developers, back-end engineers, business architects, and product managers.</p>
<p>Those who have “unrealistic” “illusions” about the front-end probably think this will improve collaboration efficiency or value output. They are probably overthinking it…</p>
<p>When a person has a superficial understanding of “business” and has their own ideas, the probability and frequency of friction in communication and collaboration will be higher. This will not increase value output but will instead reduce collaboration efficiency. This applies regardless of whether the person is a “front-end” developer or not.</p>
<p>In this regard, “design” and “front-end” actually belong to the same category—focusing on presentation and interaction without the need to understand or bear the burden of “business” matters. Demanding that “front-end” and “design” understand the business is, from a human perspective, a form of oppressive behavior.</p>
<h3 id="Shift-left-Testing"><a href="#Shift-left-Testing" class="headerlink" title="Shift-left Testing"></a>Shift-left Testing</h3><p>In the software development process, “testing” comes after “development”, meaning that functional testing only begins after the feature development is complete. While this is fine for unit-level issues, if there are problems with architecture or even business logic, the cost of rework can be substantial.</p>
<p>To identify and resolve issues as early as possible, before they cause significant impact, testing personnel or activities need to be involved in upstream stages. For example, testers can participate in requirement reviews, design reviews, software design reviews, and conduct unit tests during the development phase—this is known as “shift-left testing”.</p>
<p>Although this approach can somewhat achieve preventive goals, there are still issues with information synchronization—</p>
<p>During the development process, if problems not identified during reviews are discovered and modifications are made privately with product or design teams without updating relevant documents or informing testers, it is easy to miss tests unknowingly, leading to online failures.</p>
<h3 id="Cross-departmental-Collaboration"><a href="#Cross-departmental-Collaboration" class="headerlink" title="Cross-departmental Collaboration"></a>Cross-departmental Collaboration</h3><p>Overall, cross-departmental collaboration is a very frustrating task, several levels more complicated than intra-departmental collaboration. The reason lies in human nature—conflicts of interest, where people tend to prioritize their own interests over common interests. They are often narrow-minded and short-sighted, focusing on one-off deals rather than long-term cooperation.</p>
<p>A common problem is as follows—</p>
<p>When the business department needs services from the mid-platform&#x2F;platform department during feature iteration, and if the basic services of the mid-platform&#x2F;platform department are not yet perfect and cannot be “plug-and-play”, the choice arises of where and by whom the business department’s customized logic code should be written and maintained:</p>
<ol>
<li>Each department’s personnel develop and debug their own logic code in their respective code repositories;</li>
<li>The mid-platform&#x2F;platform department develops basic services while also developing and debugging the business department’s logic code in the business department’s code repository;</li>
<li>Temporarily place the business department’s logic code in the mid-platform&#x2F;platform department’s code repository and migrate it out once the basic services are perfected;</li>
<li>Write the business department’s logic code into the mid-platform&#x2F;platform department’s code repository and continue to maintain and modify it by the mid-platform&#x2F;platform department’s personnel in the future.</li>
</ol>
<p>Under normal circumstances, the last option is impossible and should not be chosen. This is a basic issue of departmental positioning and responsibility division. However, there may also be some helpless situations, such as when a less assertive mid-platform&#x2F;platform department encounters a rather unreasonable business department.</p>
<p>What’s worse is when the business department’s logic is convoluted. During meetings, all parties believe they have reached a consensus and proceed with development based on their understanding. However, during testing, the business department claims that the mid-platform&#x2F;platform department’s implementation is incorrect and that there are issues with business logic, even overturning the consensus previously reached in meetings.</p>
<p>It is absurd for the mid-platform&#x2F;platform department to maintain the business department’s logic code! For the mid-platform&#x2F;platform department, this is almost a losing proposition. Not only is it unprofitable, but it also invites trouble!</p>
<h2 id="Summary"><a href="#Summary" class="headerlink" title="Summary"></a>Summary</h2><p>This article has discussed several common issues we often encounter in our daily work and briefly expressed my views on each.</p>
<p>Although these issues seem diverse and seemingly unrelated, as the title and introduction of the article suggest—they all have a significant connection with “knowledge”!</p>
<p>The specifics will be revealed in the next article. In the meantime, feel free to ponder on it! 😁</p>

</div>
<footer class="Article-footer col-md-3">

<div class="Widget Widget--share">
<div class="Widget-body">
<p>分享到<i class="fa fa-share-alt"></i></p>
<div class="social-share" data-sites="wechat,weibo,twitter"></div>
</div>
</div>


<section class="Widget Widget--toc">
<div class="Widget-header">
<h2 class="Widget-title">目录</h2>
</div>
<div class="Widget-body"></div>
</section>


</footer>


</article>


</div>
</main>
<footer class="Page-footer Footer">
<div class="container">

<div class="Footer-description">

<!-- Important links -->
<nav class="Footer-navs">
<ul><li><a href="https://x.com/ntksol?utm_source=https://ourai.pro&amp;utm_medium=common-footer" target="_blank" rel="external nofollow"><span>X</span></a>
</li><li><a href="https://github.com/ourai?utm_source=https://ourai.pro&amp;utm_medium=common-footer" target="_blank" rel="external nofollow"><span>GitHub</span></a>
</li><li><a href="https://www.linkedin.com/in/ourai?utm_source=https://ourai.pro&amp;utm_medium=common-footer" target="_blank" rel="external nofollow"><span>LinkedIn</span></a>
</li></ul>
</nav>


<!-- Copyright -->
<div class="Footer-copyright">
<p>

&copy; 2023-2025 <a href="https://ourai.pro?utm_source=https://ourai.pro&amp;utm_medium=common-footer" target="_blank" rel="external nofollow">Ourai L.</a>

</p>
</div>

</div>
</div>
</footer>






<script>$('.Article-content > table').addClass('table table-bordered')</script>

<script src="/javascripts/ksio/vendors/share.min.js"></script>

<script src="/javascripts/ksio/components/page.js"></script>

<script src="/javascripts/ksio/components/toc.js"></script>

<script src="/javascripts/ksio/vendors/jquery.timeago.js"></script>

<script src="/javascripts/ksio/vendors/jquery.timeago.zh-CN.js"></script>

<script src="/javascripts/ksio/initializers/time.js"></script>

<script src="/javascripts/ksio/vendors/jquery.lazyload.js"></script>

<script src="/javascripts/ksio/initializers/lazyload.js"></script>

</body>
</html>

0 comments on commit a9225d8

Please sign in to comment.