开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《面试 fe-interview》
今日推荐英文原文：《Can We Measure Software Developer Productivity?》

---

今日推荐开源项目：《面试 fe-interview》传送门：GitHub链接
推荐理由：书到用时方恨少，面试的时候一问三不知可一点都不好。如果想要在这个学期结束后找实习或者找工作的话面试自然需要好好准备，这个项目提供了前端方向的面试题目，不仅有考验技术实力的概念题，同样也有考验理解能力的理解题，趁着现在能积累经验的时候尽可能的积累经验，每天来几篇这个题目考验一下自己也是个好事，保持每天学习的好习惯。

---

今日推荐英文原文：《Can We Measure Software Developer Productivity?》作者：Derwin Dexter Sy
原文链接：https://medium.com/swlh/can-we-measure-software-developer-productivity-f1c43cb6ce70
推荐理由：现在量化生产力似乎没有一个很好的指标

Can We Measure Software Developer Productivity?

Short answer: I don’t know.

What we can easily get is data, not information. Data is just a bunch of numbers. Information, on the other hand, is something that takes human processing to figure out. Photo by William Warby on Unsplash

Short answer: I don’t know.

Before you move on though, I’d like to say that “I don’t know” here means that I know from personal experience that trying to measure a software developer’s productivity rarely (or never) ends well. However, I also acknowledge that, historically, there have been valiant efforts that worked to some extent, and there are likewise promising ideas today that are making the rounds towards addressing the problem.

I’ll run down most of these things here, and I do hope this helps someone out there find a good way to measure productivity (or any other indicators, for that matter) in a way that makes sense in their context.

The Holy Grail

Finding a good way to measure productivity for software developers has always been a “holy grail” of sorts. Many have tried, few have succeeded. And the reason for this is much more obvious these days than it was when software development (or “computer programming”, as they used to call it) was a young field.

Here’s a relevant quote from jazz legend, Miles Davis, on what makes a great jazz tune.

“It’s not the notes you play, it’s the notes you don’t play.” – Miles Davis

This same message holds true for software code. In its early days, software development used to be considered “production” work, not much different from building a house or manufacturing hardware. This line of thought still exists today with most non-technical stakeholders and even with some who have been working in this field for a while. More and more people, however, are starting to realize that software is not exactly construction work, but is, in fact, closer to a pursuit of creativity.

In this sense, just like notes in a tune, the code you don’t write is just as important as the code you write.

Sorry, what?

The code you don’t write is just as important as the code you write. Photo by Chris Ried on Unsplash

If that’s a little bit too abstract, let me explain a few ways this manifests:

• Long code. This is often an indicator of code that can be improved. If you can do the exact same thing with fewer lines of code, you can save on binary space and perhaps your own time. (Be careful not to compromise on readability though.)
• Reinventing the wheel. “There’s just too much software to write for one company to write it.” This is why open source is a thing. If someone has already done it before and it works, you should reuse that as much as you can. If you can use it as a black box library (as opposed to copying the code), that’s a few less lines of code for you to maintain in the future.
• Cognitive load. The most satisfying code is often that which took you hours to think about and a few minutes to type out. You might be able to write entire classes effortlessly if it’s something you’ve done a million times. But writing an efficient 5-line algorithm for something alien to you might take just as much, if not more, of your time.

In addition, writing more code actually means a higher risk of inadvertently writing a bug somewhere. Likewise, if your code is long enough that other people don’t bother reading it, it’s probably worth considering just abstracting it altogether.

In short, measuring “volume of work” to understand productivity just doesn’t make sense anymore, since volume in any tangible form hardly correlates to effort and quality.

So basically “no”?

The fact that people kept coming up with new ways to measure it says a lot about just how important it is to a lot of people. Photo by William Iven on Unsplash

The industrialist in me doesn’t want to admit that there’s no way to measure software developer productivity. As much as I believe that creativity is important in software, I’d also love to be able to tell a customer that we’re halfway done and actually mean it.

Historically, measuring productivity for software developers has been a long and arduous road — from measuring lines of code (definitely rewarding the wrong things) to function points (overly conceptual and complicated) to velocity (not exactly a measure of productivity, but a decent basis for estimations). Each one works in certain contexts, but as software evolved (and it evolved fast), some eventually became irrelevant.

However, just the fact that people have kept coming up with new ways to measure it says a lot about just how important it is to a lot of people.

The future of code metrics

There seems to be some hope. Companies like GitPrime and Waydev are coming up with new Git-based metrics that might make more sense in the way we do software work today. For example:

• Code churn means the volume of code that has been modified less than 30 days from its first commit. This indicates that we might be doing a lot of work that’s volatile and essentially make very little impact on a business level.
• Review coverage is, in the spirit of collaboration and collective learning, a measure of how much code each developer reviewed.
• Impact is, well, something I don’t fully understand. According to the documentation, it should correlate to “cognitive load”, which means how much thought might have gone into coming up with a certain commit (regardless of whether it’s an edit, an addition, or a removal). Disclaimer: There’s probably a lot more to it that I’m not fully grasping.

These and other metrics, in my limited experience with these tools, do seem very promising. I think the naming, particularly “impact”, could be better. Because whatever these metrics indicate, they definitely don’t indicate anything particularly good or bad. They might, however, represent certain trends and behaviors that we can choose to look further into.

I guess what I’m saying is, maybe we should be focusing less on “metrics” and more on “indicators”. What we can easily get is data, not information. Data is just a bunch of numbers. Information, on the other hand, is something that takes human processing to figure out. Whatever the numbers seem to indicate, we need to interpret them in the context of our actual work and our organization. Most importantly, we definitely should stop making these metrics a competition.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《有问才有答 fe-interview》
今日推荐英文原文：《When the Bill Comes Due》

---

今日推荐开源项目：《有问才有答 fe-interview》传送门：GitHub链接
推荐理由：众所周知，学以致用才是巩固知识的好办法。只学过一遍很容易就随着时间变成山回路转不见妹，雪上空留蝠行处——也就是记得学过，但是不太记得学了什么的情况。使用知识的方法因人而异，这个项目提供了一个不错的方式——问问题，通过回答面试题来巩固所学，不过这个项目的主题是前端。回答面试题不仅能够巩固自己的知识，某种意义上也算是为将来可能的面试做准备，可以一举两得。

---

今日推荐英文原文：《When the Bill Comes Due》作者：Ryan Nehring
原文链接：https://medium.com/better-programming/when-the-bill-comes-due-6f027d06f66
推荐理由：技术债务，一言以蔽之——就是历史遗留问题，而且迟早要解决它

When the Bill Comes Due

The necessity and dangers of technical debt

“Move fast and break things.”—Mark Zuckerberg

In fairness, as quotes go, that one is pretty excellent. It’s succinct, empowering, and motivating. It’s also desperately in need of a second sentence along the lines of, “Once it works, go back and do it correctly!”

Technical debt didn’t start with Zuck’s bold mission statement. He simply made a motto out of what most of us programmers have been doing since time immemorial. We build things, but more than that, we often have to invent the way we build them as we build them.

That’s a messy process.

Oftentimes, the problems we’re building solutions for are so large or complex that we’re writing code just to see if what we’re envisioning is even possible. This proof-of-concept stage is one of my favorite parts of programming. Prototyping an idea can be immensely satisfying, although is rarely well planned, and this is where the origin of most of our technical debt begins.

From Prototype to MVP

Development cycles move fast. For many reasons, the excitement around a working proof-of-concept can quickly become a sprint to a minimum viable product. Whether you’re trying to beat a competitor to market or think you’re onto the next big thing, it’s rare for developers to slow down at this point.

This makes sense. The world of development can be capricious and ephemeral, and speed does matter. It’s in this phase of the process that technical debt begins to really rack up. Quick-fix code solutions designed to get a feature up and running or to find a viable integration of outside data rarely hold up well once scaled.

Broken Promises

Almost nobody lies to themselves as regularly or effectively as a programmer. While accruing technical debt, we intrinsically know we’re taking shortcuts, but we promise ourselves we’ll be back to fix this as we sail forward onto the next feature.

This creates an exponential chain reaction. As your project takes real shape, there is always another feature (or features) on the horizon. This isn’t a bad thing in and of itself; in fact, it’s usually a sign that what you’re working on has value, but as you leave each barely functional feature behind to start on the next one, your tech debt inches ever higher.

Technical Debt Charges Interest

Admittedly, it’s a bit of a cliche, but it’s also true. The longer you ignore that pile of tech debt, the larger it gets, but also the harder it gets to address. Undoubtedly, new features and functions have changed the landscape of your application, and figuring out how to wire everything back together becomes difficult.

Shoddy variable naming practices, insecure data access methods, buggy third-party libraries, etc. all begin to make that transformation from a molehill to a mountain. It’s not uncommon for application state to get buggy or UI issues to crop up at this point.

A Necessary Evil That Shouldn’t Be Ignored

In practical terms, technical debt is unavoidable. It’s a necessary evil empowering us to move quickly towards a better understanding of the big picture. Balancing when and how to address technical debt is a difficult decision that shifts from project to project.

But address it you must.

Ignored technical debt will wreak havoc as your project moves into launch. Under the strain of multiple concurrent users or unanticipated user workflows, the cracks will show. In the best of all worlds, this can be as minor as UI anomalies, but unaddressed technical debt can also expose user data. If your application tracks sensitive personal user information, this can be catastrophic.

Plan for the Fact You Didn’t Plan Enough

So what’s the right approach? Moving forward explicitly understanding that you perhaps haven’t planned out your project as fully as you’d like to is a good first step. In short, don’t lie to yourself.

• Take time after getting any feature working to make a couple notes on what needs to be addressed. Where are the shortcomings? What won’t scale well? Where are the fragile points? Even something as simple as having a running log will help hold you accountable for actually correcting those issues.
• Seek code review. Other developers can point out fragile points you might not recognize. Their experience can guide you in seeing the unexpected issues you may be creating along your way.
• Schedule refactor time. Build into your workflow time to go back and revise and optimize. You’ll always have something new to do, so if you don’t schedule time to address technical debt, you’ll likely ignore it.

Lastly, don’t despair. If you’re accruing technical debt, it probably means you’re building something cool and useful with room to grow. That’s an achievement; that’s why we do what we do!

Technical debt can cause real problems, but it’s not an 800-pound gorilla. It’s your code. You wrote it. Go fix it and make sure it performs the way you need it to, under all circumstances. Then go build that next great feature!

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/