document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-28 23:20:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #4742 from rusking/master

Browse Source 
Delete 20160826 Forget Technical Debt —Here'sHowtoBuild Technical Wea…
This commit is contained in:
Xingyu.Wang 2016-12-11 09:24:52 +08:00 committed by GitHub
commit 7cd97e6eb1
2 changed files with 283 additions and 291 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

291
sources/talk/20160826 Forget Technical Debt —Here'sHowtoBuild Technical Wealth.md
View File

@ -1,291 +0,0 @@
### rusking translating
# Forget Technical Debt —Here'sHowtoBuild Technical Wealth
[Andrea Goulet][58] and her business partner sat in her living room, casually reviewing their strategic plan, when an episode of This Old House came on television. It was one of those moments where ideas collide to create something new. They’d been looking for a way to communicate their value proposition — cleaning up legacy code and technical debt for other companies. And here they were, face to face with the perfect analogy.
“We realized that what we were doing transcended clearing out old code, we were actually remodeling software the way you would remodel a house to make it last longer, run better, do more,” says Goulet. “It got me thinking about how companies have to invest in mending their code to get more productivity. Just like you have to put a new roof on a house to make it more valuable. It’s not sexy, but it’s vital, and too many people are doing it wrong.”
Today, she’s CEO of [Corgibytes][57] — a consulting firm that re-architects and modernizes apps. She’s seen all varieties of broken systems, legacy code, and cases of technical debt so extreme it’s basically digital hoarding. Here, Goulet argues that startups need to shift their mindset away from paying down debt toward building technical wealth, and away from tearing down old code toward deliberately remodeling it. She explains this new approach, and how you can do the impossible — actually recruit amazing engineers to tackle this work.
### RETHINKING LEGACY CODE
#
The most popular definition of legacy code comes from Michael Feathers, author of the aptly titled [Working Effectively with Legacy Code][56][][55]: It's code without test coverage. That’s better than what most people assume — that the term only applies only to really old, archaic systems. But neither definition goes far enough, according to Goulet. “Legacy code has nothing to do with the age of the software. A two year-old app can already be in a legacy state,” she says. “It’s all about how difficult that software is to improve.”
This means code that isn’t written cleanly, that lacks explanation, that contains zero artifacts of your ideas and decision-making processes. A unit test is one type of artifact, but so is any documentation of the rationale and reasoning used to create that code. If there’s no way to tell what the developer was thinking when you go to improve it — that’s legacy code.
> Legacy code isn't a technical problem. It's a communication problem.
![](https://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/H4y9x4gQj61G9aK4v8Kp_Screen%20Shot%202016-08-11%20at%209.16.38%20AM.png)
If you linger around in legacy code circles like Goulet does, you’ll find that one particular, and rather obscure adage dubbed [Conway’s Law][54] will make it’s way into nearly every conversation.
“It’s the law that says your codebase will mirror the communication structures across your organization,” Goulet says. “If you want to fix your legacy code, you can’t do it without also addressing operations, too. That’s the missing link that so many people miss.”
Goulet and her team dive into a legacy project much like an archaeologist would. They look for artifacts left behind that give them clues into what past developers were thinking. All of these artifacts together provide context to make new decisions.
The most important artifact? Well organized, intention-revealing, clean code. For example, if you name a variable with generic terms like “foo” or “bar,” you might come back six months later and have no idea what that variable is for.
If the code isn’t easy to read, a useful artifact is the source control system, because it provides a history of changes to the code and gives developers an opportunity to write about the changes they’re making.
“A friend of mine says that for commit messages, every summary should be the size of half a tweet, with the description as long as a blog post, if necessary,” says Goulet. “You have the chance to tightly couple your rationale with the code that’s being changed. It doesn’t take a lot of extra time and gives tons of information to people working on the project later, but surprisingly few people do it. It’s common to hear developers get so frustrated about working with a piece of code they run ‘git blame’ in a fit of rage to figure out who wrote that mess, only to find it was themselves.”
Automated tests are also fertile ground for rationale. “There’s a reason that so many people like Michael Feathers’ definition of legacy code,” Goulet explains. “Test suites, especially when used along with [Behavior Driven Development][53] practices like writing out scenarios, are incredibly useful tools for understanding a developer’s intention.”
The lesson here is simple: If you want to limit your legacy code down the line, pay attention to the details that will make it easier to understand and work with in the future. Write and run unit, acceptance, approval, and integration tests. Explain your commits. Make it easy for future you (and others) to read your mind.
That said, legacy code will happen no matter what. For reasons both obvious and unexpected.
Early on at a startup, there’s usually a heavy push to get features out the door. Developers are under enormous pressure to deliver, and testing falls by the wayside. The Corgibytes team has encountered many companies that simply couldn’t be bothered with testing as they grew — for years.
Sure, it might not make sense to test compulsively when you’re pushing toward a prototype. But once you have a product and users, you need to start investing in maintenance and incremental improvements. “Too many people say, ‘Don’t worry about the maintenance, the cool things are the features!’” says Goulet. “If you do this, you’re guaranteed to hit a point where you cannot scale. You cannot compete.”
As it turns out, the second law of thermodynamics applies to code too: You’ll always be hurtling toward entropy. You need to constantly battle the chaos of technical debt. And legacy code is simply one type of debt you’ll accrue over time.
“Again the house metaphor applies. You have to keep putting away dishes, vacuuming, taking out the trash,” she says. “if you don’t, it’s going to get harder, until eventually you have to call in the HazMat team.”
Corgibytes gets a lot of calls from CEOs like this one, who said: “Features used to take two weeks to push three years ago. Now they’re taking 12 weeks. My developers are super unproductive.”
> Technical debt always reflects an operations problem.
A lot of CTOs will see the problem coming, but it’s hard to convince their colleagues that it’s worth spending money to fix what already exists. It seems like backtracking, with no exciting or new outputs. A lot of companies don’t move to address technical debt until it starts crippling day-to-day productivity, and by then it can be very expensive to pay down.
### FORGET DEBT, BUILD TECHNICAL WEALTH
# Recommended Article
You’re much more likely to get your CEO, investors and other stakeholders on board if you [reframe your technical debt][52] as an opportunity to accumulate technical wealth — [a term recently coined by agile development coach Declan Whelan][51].
“We need to stop thinking about debt as evil. Technical debt can be very useful when you’re in the early-stage trenches of designing and building your product,” says Goulet. “And when you resolve some debt, you’re giving yourself momentum. When you install new windows in your home, yes you’re spending a bunch of money, but then you save a hundred dollars a month on your electric bill. The same thing happens with code. Only instead of efficiency, you gain productivity that compounds over time.”
As soon as you see your team not being as productive, you want to identify the technical debt that's holding them back.
“I talk to so many startups that are killing themselves to acquire talent — they’re hiring so many high-paid engineers just to get more work done,” she says. “Instead, they should have looked at how to make each of their existing engineers more productive. What debt could you have paid off to get that extra productivity?”
If you change your perspective and focus on wealth building, you’ll end up with a productivity surplus, which can then be reinvested in fixing even more debt and legacy code in a virtuous cycle. Your product will be cruising and getting better all the time.
> Stop thinking about your software as a project. Start thinking about it as a house you will live in for a long time.
This is a critical mindset shift, says Goulet. It will take you out of short-term thinking and make you care about maintenance more than you ever have.
Just like with a house, modernization and upkeep happens in two ways: small, superficial changes (“I bought a new rug!”) and big, costly investments that will pay off over time (“I guess we’ll replace the plumbing...”). You have to think about both to keep your product current and your team running smoothly.
This also requires budgeting ahead — if you don’t, those bigger purchases are going to hurt. Regular upkeep is the expected cost of home ownership. Shockingly, many companies don’t anticipate maintenance as the cost of doing business.
This is how Goulet coined the term ‘software remodeling.’ When something in your house breaks, you don’t bulldoze parts of it and rebuild from scratch. Likewise, when you have old, broken code, reaching for a re-write isn’t usually the best option.
Here are some of the things Corgibytes does when they’re called in to ‘remodel’ a codebase:
* Break monolithic apps into micro-services that are lighter weight and more easily maintained.
* Decouple features from each other to make them more extensible.
* Refresh branding and look and feel of the front-end.
* Establish automated testing so that code validates itself.
* Refactor, or edit, codebases to make them easier to work with.
Remodeling also gets into DevOps territory. For example, Corgibytes often introduces new clients to [Docker][50], making it much easier and faster to set up new developer environments. When you have 30 engineers on your team, cutting the initial setup time from 10 hours to 10 minutes gives you massive leverage to accomplish more tasks. This type of effort can’t just be about the software itself, it also has to change how it’s built.
If you know which of these activities will make your code easier to handle and create efficiencies, you should build them into your annual or quarterly roadmap. Don’t expect them to happen on their own. But don’t put pressure on yourself to implement them all right away either. Goulet sees just as many startups hobbled by their obsession with having 100% test coverage from the very beginning.
To get more specific, there are three types of remodeling work every company should plan on:
* Automated testing
* Continuous delivery
* Cultural upgrades
Let’s take a closer look at each of these.
Automated Testing
“One of our clients was going into their Series B and told us they couldn’t hire talent fast enough. We helped them introduce an automated testing framework, and it doubled the productivity of their team in under 3 months,” says Goulet. “They were able to go to their investors and say, ‘We’re getting more with a lean team than we would have if we’d doubled the team.'”
Automated testing is basically a combination of individual tests. You have unit tests which double-check single lines of code. You have integration tests that make sure different parts of the system are playing nice. And you have acceptance tests that ensure features are working as you envisioned. When you write these tests as automated scripts, you can essentially push a button and have your system validate itself rather than having to comb through and manually click through everything.
Instituting this before hitting product-market fit is probably premature. But as soon as you have a product you’re happy with, and that users who depend on it, it’s more than worth it to put this framework in place.
Continuous Delivery
This is the automation of delivery related tasks that used to be manual. The goal is to be able to deploy a small change as soon as it’s done and make the feedback loop as short as possible. This can give companies a big competitive advantage over their competition, especially in customer service.
“Let’s say every time you deploy, it’s this big gnarly mess. Entropy is out of control,” says Goulet. “We’ve seen deployments take 12 hours or more because it’s such a cluster. And when this happens, you’re not going to deploy as often. You’re going to postpone shipping features because it’s too painful. You’re going to fall behind and lose to the competition.”
Other tasks commonly automated during continuous improvement include:
* Checking for breaks in the build when commits are made.
* Rolling back in the event of a failure.
* Automated code reviews that check for code quality.
* Scaling computing resources up or down based on demand.
* Making it easy to set up development, testing, and production environments.
As a simple example, let’s say a customer sends in a bug report. The more efficient the developer is in fixing that bug and getting it out, the better. The challenge with bug fixes isn’t that making the change is all that difficult, it’s that the system isn’t set up well and the developer wastes a lot of time doing things other than solving problems, which is what they’re best at.
With continuous improvement, you would become ruthless about determining which tasks are best for the computer and which are best for the human. If a computer is better at it, you automate it. This leaves the developer gleefully solving challenging problems. Customers are happier because their complaints are addressed and fixed quickly. Your backlog of fixes narrows and you’re able to spend more time on new creative ways to improve your app even more. This is the kind of change that generates technical wealth. Because that developer can ship new code as soon as they fix a bug in one step, they have time and bandwidth to do so much more frequently.
“You have to constantly ask, ‘How can I improve this for my users? How can I make this better? How can I make this more efficient?’ But don’t stop there,” says Goulet. “As soon as you have answers to these questions, you have to ask yourself how you can automate that improvement or efficiency.”
Cultural Upgrades
Every day, Corgibytes sees the same problem: A startup that's built an environment that makes it impossible for its developers to be impactful. The CEO looms over their shoulders wondering why they aren’t shipping more often. And the truth is that the culture of the company is working against them. To empower your engineers, you have to look at their environment holistically.
To make this point, Goulet quotes author Robert Henri:
> The object isn't to make art, it's to be in that wonderful state which makes art inevitable.
“That’s how you need to start thinking about your software,” she says. “Your culture can be that state. Your goal should always be to create an environment where art just happens, and that art is clean code, awesome customer service, happy developers, good product-market fit, profitability, etc. It’s all connected.”
This is a culture that prioritizes the resolution of technical debt and legacy code. That’s what will truly clear the path for your developers to make impact. And that’s what will give you the surplus to build cooler things in the future. You can’t remodel your product without making over the environment it’s developed in. Changing the overall attitude toward investing in maintenance and modernization is the place to start, ideally at the top with the CEO.
Here are some of Goulet's suggestions for establishing that flow-state culture:
* Resist the urge to reward “heroes” who work late nights. Praise effectiveness over effort.
* Get curious about collaboration techniques, such as Woody Zuill’s [Mob Programming][44][][43].
* Follow the four [Modern Agile][42] principles: make users awesome, experiment and learn rapidly, make safety a prerequisite, and deliver value continuously.
* Give developers time outside of projects each week for professional development.
* Practice [daily shared journals][41] as a way to enable your team to solve problems proactively.
* Put empathy at the center of everything you do. At Corgibytes, [Brene Brown’s CourageWorks][40] training has been invaluable.
If execs and investors balk at this upgrade, frame it in terms of customer service, Goulet says. Tell them how the end product of this change will be a better experience for the people who matter most to them. It’s the most compelling argument you can make.
### FINDING THE MOST TALENTED REMODELERS
#
It’s an industry-wide assumption that badass engineers don’t want to work on legacy code. They want to build slick new features. Sticking them in the maintenance department would be a waste, people say.
These are misconceptions. You can find incredibly skilled engineers to work on your thorniest debt if you know where and how to look — and how to make them happy when you’ve got them.
“Whenever we speak at conferences, we poll the audience and ask 'Who loves working on legacy code?' It's pretty consistent that less than 10% of any crowd will raise their hands.” says Goulet. “But when I talked to these people, I found out they were the engineers who liked the most challenging problems.”
She has clients coming to her with homegrown databases, zero documentation, and no conceivable way to parse out structure. This is the bread and butter of a class of engineers she calls “menders.” Now she has a team of them working for her at Corgibytes who like nothing more than diving into binary files to see what’s really going on.
![](https://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/BeX5wWrESmCTaJYsuKhW_Screen%20Shot%202016-08-11%20at%209.17.04%20AM.png)
So, how can you find these elite forces? Goulet has tried a lot of things — and a few have worked wonders.
She launched a community website at [legacycode.rocks][49] that touts the following manifesto: “For too long, those of us who enjoy refactoring legacy code have been treated as second class developers... If you’re proud to work on legacy code, welcome!”
“I started getting all these emails from people saying, ‘Oh my god, me too!’” she says. “Just getting out there and spreading this message about how valuable this work is drew in the right people.”
Recommended Article
She’s also used continuous delivery practices in her recruiting to give these type of developers what they want: Loads of detail and explicit instructions. “It started because I hated repeating myself. If I got more than a few emails asking the same question, I’d put it up on the website, much like I would if I was writing documentation.”
But over time, she noticed that she could refine the application process even further to help her identify good candidates earlier in the process. For example, her application instructions read, “The CEO is going to review your resume, so make sure to address your cover letter to the CEO” without providing a gender. All letters starting with “Dear Sir,” or "Mr." are immediately trashed. And this is just the beginning of her recruiting gauntlet.
“This started because I was annoyed at how many times people assumed that because I’m the CEO of a software company, I must be a man,” Goulet said. “So one day, I thought I’d put it on the website as an instruction for applicants to see who was paying attention. To my surprise, it didn’t just muffle the less serious candidates. It amplified the folks who had the particular skills for working with legacy code.”
Goulet recalls how one candidate emailed her to say, “I inspected the code on your website (I like the site and hey, it’s what I do). There’s a weird artifact that seems to be written in PHP but it appears you’re running Jekyll which is in Ruby. I was really curious what that’s about.”
It turned out that there was a leftover PHP class name in the HTML, CSS, and JavaScript that Goulet got from her designer that she’d been meaning to getting around to but hadn’t had a chance. Her response: “Are you looking for a job?”
Another candidate noticed that she had used the term CTO in an instruction, but that title didn’t exist on her team (her business partner is the Chief Code Whisperer). Again, the attention to detail, the curiosity, and the initiative to make it better caught her eye.
> Menders aren't just detail-oriented, they're compelled by attention to detail.
Surprisingly, Goulet hasn't been plagued with the recruiting challenges of most tech companies. “Most people apply directly through our website, but when we want to cast a wider net, we use [PowerToFly][48] and [WeWorkRemotely][47]. I really don’t have a need for recruiters at the moment. They have a tough time understanding the nuance of what makes menders different.”
If they make it through an initial round, Goulet has a candidate read an article called “[Naming is a Process][46]” by Arlo Belshee. It delves into the very granular specifics of working with indebted code. Her only directions: “Read it and tell me what you think.”
She’s looking for understanding of subtleties in their responses, and also the willingness to take a point of view. It’s been really helpful in separating deep thinkers with conviction from candidates who just want to get hired. She highly recommends choosing a piece of writing that matters to your operations and will demonstrate how passionate, opinionated, and analytical people are.
Lastly, she’ll have a current team member pair program with the candidate using [Exercism.io][45]. It’s an open-source project that allows developers to learn how to code in different languages with a range of test driven development exercises. The first part of the pair programming session allows the candidate to choose a language to build in. For the next exercise, the interviewer gets to pick the language. They get to see how the person deals with surprise, how flexible they are, and whether they’re willing to admit they don’t know something.
“When someone has truly transitioned from a practitioner to a master, they freely admit what they don’t know,” says Goulet.
Having someone code in a language they aren’t that familiar with also gauges their stick-to-it-iveness. “We want someone who will say, ‘I’m going to hammer on this problem until it’s done.’ Maybe they’ll even come to us the next day and say, ‘I kept at it until I figured it out.’ That’s the type of behavior that’s very indicative of success as a mender.”
> Makers are so lionized in our industry that everyone wants to have them do maintenance too. That's a mistake. The best menders are never the best makers.
Once she has talented menders in the door, Goulet knows how to set them up for success. Here’s what you can do to make this type of developer happy and productive:
* Give them a generous amount of autonomy. Hand them assignments where you explain the problem, sure, but never dictate how they should solve it.
* If they ask for upgrades to their computers and tooling, do it. They know what they need to maximize efficiency.
* Help them [limit their context-switching][39]. They like to focus until something’s done.
Altogether, this approach has helped Corgibytes build a waiting list of over 20 qualified developers passionate about legacy code.
### STABILITY IS NOT A DIRTY WORD
#
Most startups don’t think past their growth phase. Some may even believe growth should never end. And it doesn’t have to, even when you enter the next stage: Stability. All stability means is that you have the people and processes you need to build technical wealth and spend it on the right priorities.
“There’s this inflection point between growth and stability where menders must surge, and you start to balance them more equally against the makers focused on new features,” says Goulet. “You have your systems. Now you need them to work better.”
This means allocating more of your organization’s budget to maintenance and modernization. “You can’t afford to think of maintenance as just another line item,” she says. “It has to become innate to your culture — something important that will yield greater success in the future.”
Ultimately, the technical wealth you build with these efforts will give rise to a whole new class of developers on your team: scouts that have the time and resources to explore new territory, customer bases and opportunities. When you have the bandwidth to tap into new markets and continuously get better at what you already do — that’s when you’re truly thriving.
--------------------------------------------------------------------------------
via: http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/
作者：[http://firstround.com/][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: http://firstround.com/
[1]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[2]:http://www.courageworks.com/
[3]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[4]:https://www.industriallogic.com/blog/modern-agile/
[5]:http://mobprogramming.org/
[6]:http://exercism.io/
[7]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[8]:https://weworkremotely.com/
[9]:https://www.powertofly.com/
[10]:http://legacycode.rocks/
[11]:https://www.docker.com/
[12]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[13]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[14]:https://en.wikipedia.org/wiki/Behavior-driven_development
[15]:https://en.wikipedia.org/wiki/Conway%27s_law
[16]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[17]:http://corgibytes.com/
[18]:https://www.linkedin.com/in/andreamgoulet
[19]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[20]:http://www.courageworks.com/
[21]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[22]:https://www.industriallogic.com/blog/modern-agile/
[23]:http://mobprogramming.org/
[24]:http://mobprogramming.org/
[25]:http://exercism.io/
[26]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[27]:https://weworkremotely.com/
[28]:https://www.powertofly.com/
[29]:http://legacycode.rocks/
[30]:https://www.docker.com/
[31]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[32]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[33]:https://en.wikipedia.org/wiki/Behavior-driven_development
[34]:https://en.wikipedia.org/wiki/Conway%27s_law
[35]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[36]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[37]:http://corgibytes.com/
[38]:https://www.linkedin.com/in/andreamgoulet
[39]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[40]:http://www.courageworks.com/
[41]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[42]:https://www.industriallogic.com/blog/modern-agile/
[43]:http://mobprogramming.org/
[44]:http://mobprogramming.org/
[45]:http://exercism.io/
[46]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[47]:https://weworkremotely.com/
[48]:https://www.powertofly.com/
[49]:http://legacycode.rocks/
[50]:https://www.docker.com/
[51]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[52]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[53]:https://en.wikipedia.org/wiki/Behavior-driven_development
[54]:https://en.wikipedia.org/wiki/Conway%27s_law
[55]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[56]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[57]:http://corgibytes.com/
[58]:https://www.linkedin.com/in/andreamgoulet

283
translated/talk/20160826 Forget Technical Debt —Here'sHowtoBuild Technical Wealth.MD Normal file
View File

@ -0,0 +1,283 @@
# Forget Technical Debt —Here'sHowtoBuild Technical Wealth
#忘记技术债务——教你如何创造技术财富
电视里正播放着《老屋》节目，[Andrea Goulet][58]和她商业上的合作伙伴正悠闲地坐在客厅里商讨着他们的战略计划。那正是大家思想的火花碰撞出创新事物的时刻。他们正在寻求一种能够实现自身价值的方式——为其它公司清理遗留代码及科技债务。他们此刻的情景，像极了电视里的剧情。
“我们意识到我们现在做的工作不仅仅是清理出遗留代码，实际上我们是在用重建老屋的方式来重构软件，让系统运行更持久，更稳定，更高效，”Goulet说。“这让我开始思考着如何让更多的公司花钱来改善他们的代码，以便让他们的系统运行更高效。就好比为了让屋子变得更实用，你不得不使用一个全新的屋顶。这并不吸引人，但却是至关重要的，然而很多人都搞错了。“
如今，她是[Corgibytes][57]公司的CEO——一家提高软件现代化和进行系统重构方面的咨询公司。她曾经见过各种各样糟糕的系统，遗留代码，以及不计其数的严重的科技债务事件。Goulet认为创业公司需要从偿还债务思维模式向创造科技财富的思维模式转变，并且要从铲除旧代码的方式向逐步修复的方式转变。她解释了这种新的方法，以及如何完成这些看似不可能完成的事情——实际上是聘用大量的工程事来完成这些工作。
### 反思遗留代码
关于遗留代码最广泛的定义由Michael Feathers在他的著作[修改代码的艺术][56][][55]一书中提出：遗留代码就是没有被测试的代码。这个定义比大多数人所认为的——遗留代码仅指那些古老陈旧的系统这个说法要妥当得多。但是Goulet认为这两种定义都不够明确。“随时软件周期的生长，遗留代码显得毫无用处。一两年的应用程序，其代码已经进入遗留状态了，”她说。“最重要的是如何提高软件质量的难易程度。”
这意味着代码写得不够清楚，缺少解释说明,没有任何关于你写的代码构件和做出这个决定的流程。一个单元测试属于一种类型的构件，也包括所有的你写那部分代码的原因以及逻辑推理相关的文档。当你去修复代码的过程中，如果没办法搞清楚原开发者的意图，那些代码就属于遗留代码了。
> 遗留代码不是技术问题，而是沟通上的问题
![](https://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/H4y9x4gQj61G9aK4v8Kp_Screen%20Shot%202016-08-11%20at%209.16.38%20AM.png)
如果你像Goulet所说的那样迷失在遗留代码里，你会发现每一次的沟通交流过程都会变得像那条鲜为人知的[康威定律][54]所描述的一样。
Goulet说：“这个定律认为系统的基础架构能反映出你们整个公司的组织沟通结构，如果你想修复你们公司的遗留代码而没有一个好的组织沟通方式是不可能完成的。那是很多人都没注意到的一个重要环节。”
Goulet和她的团队成员更像是考古学家一样来研究遗留系统项目。他们根据前开发者写的代码构件相关的线索来推断出他们的思想意图。然后再根据这些构件之间的关系来作出新的决策。
最重要的代码构件是什么呢？良好的代码结构、清晰的思想意图、整洁的代码。例如，如果你使用了通用的名称如”foo“或”bar“来命名一个变量，半年后你再返回来看这段代码时，你根本就看不出这个变量的用途是什么。
如果代码读起来很困难，可以使用源代码控制系统，这是一个非常有用的构件，因为从该构件可以看出代码的历史修改信息，这为软件开发者写明他们作出本次修改的原因提供一个很好的途径。
Goulet说：”我一个朋友认为对于代码注释的信息，如有需要，每一个概要部分的内容应该有推文的一半多，而代码的描述信息应该有一篇博客那么长。你得用这个方式来为你修改的代码写一个合理的说明。这也不会浪费太多的时间，并且给后期的项目开发者提供更多有用的信息，但是让人惊讶的是没人会这么做。我们经常听到一些很沮丧的开发人员在调试一段代码的过程中报怨这是谁写的这烂代码，最后发现还不是他们自己写的。“
使用自动化测试对于理解程序的流程非常有用。Goulet解释道：“很多人都比较认可Michael Feathers提出的关于遗留代码的定义，尤其是我们与[行为驱动开发模式][53]相结合的过程中使用测试套件，比如编写测试场景，这对于理解开发者的意图来说是非常有用的工具。
理由很简单，如果你想把遗留代码的程度降到最低，你得多注意下代码的易理解性以及将来回顾该代码的一些细节上。编写并运行单元程序、接受、认可，并且进行集成测试，写清楚注释的内容。方便以后你自己或是别人来理解你写的代码。
尽管如此，由于很多已知的和不可意料的原因，遗留代码仍然会发生。
在创业公司刚成立初期，公司经常会急于推出很多新的功能。开发人员在巨大的压力下一边完成项目交付一边测试系统缺陷。Corgibytes团队就遇到过好多公司很多年都懒得对系统做详细的测试了。
确实如此，当你急于开发出系统原型的时候，强制性地去做太多的系统测试也许意义不大。但是，一旦产品开发完成并投入使用后，你就不得投入大量的时间精力来维护及完善系统。“很多人觉得运维没什么好担心的，重要的是产品功能特性上的强大。如果真这样，当系统规模到一定程序的时候，就很难再扩展了。同时也就失去市场竞争力了。
最后才明白过来，原来热力学第二定律对你们公司的代码也同样适用：你所面临的一切将向熵增的方向发展。你需要与混乱无序的技术债务进行一场无休无止的战斗。并且随着时间的增长，遗留代码也逐渐变成一种简单类型的债务。
她说：“我们再次拿家来做比喻。你必须坚持每天收拾餐具，打扫卫生，倒垃圾。如果你不这么做，情况将来越来越糟糕，直到有一天你不得不向HazMat团队求助。”
就跟这种情况一样，Corgibytes团队接到很多公司CEO的求助电话，比如Features公司的CEO在电话里抱怨道：“现在我们公司的开发团队工作效率太低了，三年前只需要两个星期就完成的工作，现在却要花费12个星期。”
> 技术债务往往反应出公司运作上的问题
很多公司的CEO明知会发生技术债务的问题，但是他们也难让其它同事相信花钱来修复那些已经存在的问题是很值的。这看起来像是在走回头路，很乏味或者没有新的产品。有些公司直到系统已经严重的影响了日常工作效率时才着手去处理技术债务方面的问题，那时付出的代价就太高了。
### 忘记债务，创造技术财富
# 推荐文章
如果你想把[重构技术债务][52]作为一个积累技术财富的机会-[敏捷开发讲师Declan Whelan最近提到的一个术语][51]，你很可能要先说服你们公司的CEO、投资者和其它的股东登上这条财富之船。
“我们没必要把技术债务想像得很可怕。当产品处于开发设计初期，技术债务反而变得非常有用，”Goulet说。“当你解决一些系统遗留的技术问题时，你会充满成就感。例如，当你在自己家里安装新窗户时，你确实会花费一笔不少的钱，但是之后你每个月就可以节省100美元的电费。程序代码亦是如此。这虽然暂时没有提高工作效率，但是随时时间地推移将为你们公司创造更多的生产率。“
一旦你意识到项目团队工作不再富有成效时，你必须要确认下是哪些技术债务在拖后腿了。
“我跟很多不惜一切代价招募英才的初创公司交流过，他们高薪聘请一些工程师来只为了完成更多的工作。”她说。”相反的是，他们应该找出如何让原有的每个工程师都更高效率工作的方法。你需要去解决什么样的技术债务以增加额外的生产率?"
如果你改变自己的观点并且专注于创造技术财富，你将会看到产能过剩的现象，然后重新把多余的产能投入到修复更多的技术债务和遗留代码的的良性循环中。你们的产品将会走得更远，发展得更好。
> 别想着把你们公司的软件当作一个项目来看。从现在起，你把它想象成一栋自己要长久居住的房子。
“这是一个极其重要的思想观念的转变，”Goulet说。“这将带你走出短浅的思维模式，并且你会比之前更加关注产品的维护工作。”
这就像一栋房子，要实现其现代化的改造方式有两种：小动作，表面上的更改（“我买了一块新的小地毯！”）和大改造，需要很多年才能偿还所有债务（“我假设我们将要替换掉所有的管道...")。你必须考虑好两者才能你们已有的产品和整个团队顺利地运作起来。
这还需要提前预算好——否则那些较大的花销将会是硬伤。定期维护是最基本的预期费用。让人震惊的是，很多公司在商务上都没把维护成本预算进来。
这就是Goulet提出软件重构这个术语的原因。当你房子里的一些东西损坏的时候，你不用铲除整个房子而是重新修复坏掉的那一部分就可以了。同样的，当你们公司出现老的，损坏的代码时，重写代码通常不是最明智的选择。
下面是Corgibytes公司在重构客户代码用到的一些方法：
* 把大型的应用系统分解成轻量级的更易于维护的微服务。
* 相互功能模块之间降低耦合性以便于扩展。
* 更新品牌和提升用户前端界面体验。
* 集合自动化测试来检查代码可用性。
* 重构或者修改代码库来提高易用性。
系统重构也进入到运维领域。比如，Corgibytes公司经常推荐新客户使用[Docker][50]，以便简单快速的部属新的开发环境。当你们公司有30个工程师的时候，把初始化配置时间从10小时减少到10分钟对完成更多的工作很有帮助。系统重构不仅仅是应用于软件开发本身，也包括如何进行系统重构。
如果你知道有什么新的技术能让你们的代码管理起来更容易，创建更高效，就应该把这它们写入到每年或季度项目规划中。你别指望它们会自动呈现出来。但是也别给自己太大的压力来马上实施它们。Goulets看到很多公司从一开始就这些新的技术进行100%覆盖率测试而陷入困境。
具体来说，每个公司都应该把以下三种类型的重构工作规划到项目建设中来：
* 自动化测试
* 持续性交付
* 文化提升
咱们来深入的了解下每一项内容
自动化测试
“有一位客户即将进行第二轮融资，但是他们却没办法在短期内招聘到足够的人才。我们帮助他们引进了一种自动化测试框架，这让他们的团队在3个月的时间内工作效率翻了一倍，”Goulets说。“这样他们就可以在他们的投资人面前自豪的说，”我们的一个精英团队完成的任务比两个普通的团队要多。“”
自动化测试从根本上来讲就是单个测试的组合。你可以使用单元测试再次检查某一行代码。可以使用集成测试来确保系统的不同部分都正常运行。还可以使用验收性测试来检验系统的功能特性是否跟你想像的一样。当你把这些测试写成测试脚本后，你只需要简单地用鼠标点一下按钮就可以让系统自行检验了，而不用手工的去梳理并检查每一项功能。
在产品的市场定位前就来制定自动化测试机制是有些言之过早了。但是如果你有一款信心满满的产品，并且也很依赖客户，那就更应该把这件事考虑在内了。
持续性交付
这是与自动化交付相关的工作，过去是需要人工完成。目的是当系统部分修改完成时可以迅速进行部属，并且短期内得到反馈。这给公司在其它竞争对手面前有很大的优势，尤其是在售后服务行业。
“比如说你每次部属系统时环境都很复杂。熵值无法有效控制，”Goulets说。“我们曾经花了12个小时甚至更多的时间来部属一个很大的集群环境。然而，想必你将来也不会经常干部属新环境这样的工作。因为太折腾人了，而且还推迟了系统功能上线的时间。同时你也落后于其它公司并失去竞争力了。
在持续性改进的过程中常见的其它自动化任务包括：
* 在提交完成之后检查中断部分。
* 在出现故障时进行回滚操作。
* 审查自动化代码的质量。
* 根据需求增加或减少服务器硬件资源。
* 让开发，测试及生产环境配置简单易懂。
举一个简单的例子，比如说一个客户提交了一个系统Bug报告。开发团队越高效解决并修复那个Bug越好。对于开发人员来说，修复Bug的挑战根本不是个事儿，这本来也是他们的强项，主要是系统设置上不够完善导致他们浪费太多的时间去处理bug以外的其它问题。
使用持续改进的方式时，在你决定哪些工作应该让机器去做还是最好丢给研发去完成的时候，你会变得很严肃无情。如果选择让机器去处理，你得使其自动化完成。这样也能让研发很愉快地去解决其它有挑战性的问题。同时客户也会很高兴地看到他们报怨的问题被快速处理了。你的待修复的未完成任务数减少了，之后你就可以把更多的时间投入到运用新的方法来提高公司产品质量上了。
”你必须时刻问自己，‘我应该如何为我们的客户改善产品功能？如何做得更好？如何让产品运行更高效？’Goulets说。“一旦你回答完这些问题后，你就得询问下自己如何自动去完成那些需要改善的功能”
提升企业文化
Corgibytes公司每天都会遇到同样的问题：一家创业公司建立了一个对开发团队毫无影响的文化环境。公司CEO抱着双臂思考着为什么这样的环境对员工没多少改变。然而事实却是公司的企业文化观念与他们是截然相反的。为了激烈你们公司的工程师，你必须全面地了解他们的工作环境。
为了证明这一点，Goulet引用了作者Robert Henry说过的一段话：
> 目的不是创造艺术，而是在最美妙的状态下让艺术应运而生。
“也就是说你得开始思考一下你们公司的产品，“她说。”你们的企业文件就应该跟自己的产品一样。你们的目标是永远创造一个让艺术品应运而生的环境，这件艺术品就是你们公司的代码，一流的售后服务、充满幸福感的员工、良好的市场、盈利能力等等。这些都息息相关。“
优先考虑公司的技术债务和遗留代码也是一种文化。那才是真正能让开发团队深受影响的方法。同时，这也会让你将来有更多的时间精力去完成更重要的工作。如果你不从根本上改变固有的企业文化环境，你就不可能重构公司产品。改变你所有的对产品维护及现代化上投资的态度是开始实施变革的第一步，最理想情况是从公司的CEO开始转变。
以下是Goulet关于建立那种流态文化方面提出的建议：
* 反对公司嘉奖那些加班到深夜的”英雄“。提倡高效率的工作方式。
* 了解协同开发技术，比如Woody Zuill提出的[暴徒编程][44][][43]模式。
* 遵从4个[现代敏捷开发][42] 原则：用户至上、实践及快速学习、把系统安全放在首位、持续交付价值。
* 每周为研发提供项目外的职业发展时间。
* 把[日工作记录]作为一种驱动开发团队主动解决问题的方式。
* 把同情心放在第一位。Corgibytes公司让员工参加[Brene Brown勇气工厂][40]的培训是非常有用的。
”如果公司高管和投资者不支持这种文件升级方式，你得从客户服务的角度去说服他们，“Goulet说，”告诉他们通过这次调整后，最终产品将如何给公司的大客户提高更好的体验。这是你能做的一个很有力的论点。“
### 寻找最具天财的代码重构者
整个行业都认为那些顶尖的工程师都不愿意去干修复遗留代码的工作。他们只想着去开发新的东西。大家都说把他们留在维护部门真是太浪费人才了。
其实这些都是误解。如果你知道如何寻找到那些技术精湛的工程师以为他们提供一个愉快的工作环境，你可以安排他们来帮你解决那些最棘手的技术债务问题。
”每一次开会的时候，我们都会问现场的同事’谁喜欢去干遗留代码的工作？‘但是也只有那么不到10%的同事会举手。“Goulet说。”但是当我跟这些人交流的过程中，我发现这些工程师恰好是喜欢最具挑战性工作的人才。“
有一位客户来寻求她的帮助，他们使用国产的数据库，没有任何相关文档，也没有一种有效的方法来弄清楚他们公司的产品架构。她称那些类似于面包和黄油的一类工程师为”修正者“。在Corgibytes公司，她有一支这样的修正者团队由她支配，他们没啥爱好，只喜欢通过研究二进制代码来解决技术问题。
![](https://s3.amazonaws.com/marquee-test-akiaisur2rgicbmpehea/BeX5wWrESmCTaJYsuKhW_Screen%20Shot%202016-08-11%20at%209.17.04%20AM.png)
那么，如何才能找到这些技术人才呢？Goulet尝试过各种各样的方法，其中有一些方法还是富有成效的。
她创办了一个社区网站[legacycode.rocks][49]并且在招聘启示上写道：”长期招聘那些喜欢重构遗留代码的另类开发人员...如果你以从事处理遗留代码的工作为自豪，欢迎加入！“
”我刚开始收到很多这些人发来邮件说，’噢，天呐，我也属于这样的开发人员！‘“她说。”我开始发布这条信息，并且告诉他们这份工作是非常有意义的，以吸引合适的人才“
推荐文章
在招聘的过程中，她也会使用持续性交付的经验来回答那些另类开发者想知道的信息：包括详细的工作内容以及明确的要求。我这么做的原因是因为我讨厌重复性工作。如果我收到多封邮件来咨询同一个问题，我会把答案发布在网上，我感觉自己更像是在写说明文档一样。”
但是随着时间的推移，她注意到她会重新定义招聘流程来帮助她识别出更出色的候选人。比如说，她在应聘要求中写道，“公司CEO将会重新审查你的简历，因此确保邮件发送给CEO时”不用写明性别。所有以“尊敬的先生或女士”开头的信件将会被当垃圾处理掉。然后，这只不过是她招聘初期的策略而已。
“我开始这么做是因为很多申请人把我当成一家软件公司的男性CEO，这让我很厌烦，”Goulet说。“所有，有一天我想我应该它当作应聘要求放到网上，看有多少人注意到这个问题。令我惊讶的是，这让我过滤掉一些不太严谨的申请人。还突显出了很多擅于从事遗留代码方面工作的人。
Goulet想起一个应聘者发邮件给我说，“我查看了你们网站的代码（我喜欢这个网站以及你们打招呼的方式，这就是我所希望的）。你们的网站架构很奇特，好像是用PHP写的，但是你们却运行在用Ruby语言写的Jekyll下。我真的很好奇那是什么呢。”
原来是这样的，Goulet从她的设计师那里得知，在HTML、CSS和JavaScript文件中有一个未使用的PHP类名，她一直想解决这个问题，但是一直没机会。她的回复是：“你正在找工作吗？”
另外一名候选人注意到她曾经在一篇说明文档中使用CTO这个词，但是她的团队里并没有这个头衔（她的合作伙伴是首席代码语者）。其次是那些注重细节、充满求知欲、积极主动的候选者更能引起她的注意。
> 代码修正者不仅需要注重细节，而且这也是他们必备的品质。
让人吃惊的是，Goulet从来没有为招募最优秀的代码修正者而感到厌烦过。”大多数人都是通过我们的网站直接投递简历，但是当我们想扩大招聘范围的时候，我们会通过[PowerToFly][48]和[WeWorkRemotely][47]网站进行招聘。我现在确实不需要招募新人马了。他们需要经历一段很艰难的时期才能理解代码修正者的意义是什么。“
如果他们通过首轮面试，Goulet将会让候选者阅读一篇Arlo Belshee写的文章”[命名是一个过程][46]“。它讲的是非常详细的处理遗留代码的的过程。她最经典的指导方法是：”阅读完这段代码并且告诉我，你是怎么理解的。“
她将找出对问题的理解很深刻并且也愿意接受文章里提出的观点候选者。这对于筛选出有坚定信念的想被雇用的候选者来说是极其有用的办法。她强力要求候选者找出一段与你操作相关的最关键的代码来证明你是充满激情的、有主见的及善于分析问题的人。
最后，她会让候选者跟公司里当前的团队成员一起使用[Exercism.io][45]工具进行编程。这是一个开源项目，它允许开发者学习如何在不同的编程语言环境下使用一系列的测试驱动开发的练习进行编程。第一部分的协同编程课程允许候选者选择其中一种语言进行内建。下一个练习中，面试者可以选择一种语言进行编程。他们总能看到那些人处理异常的方法、随机应便的能力以及是否愿意承认某些自己不了解 的技术。
“当一个人真正的从专家转变为大师的时候，他才会毫不犹豫的承认自己不知道的东西，“Goulet说。
让他们使用自己不熟悉的编程语言来写代码也能衡量其坚韧不拔的毅力。”我们想听到某个人说，‘我会深入研究这个问题直到彻底解决它。“也许第二天他们仍然会跑过来跟我们说，’我会一直留着这个问题直到我找到答案为止。‘那是作为一个成功的修正者表现出来的一种气质。“
> 如果你认为产品开发人员在我们这个行业很受追捧，因此很多公司也想让他们来做维护工作。那你可错了。最优秀的维护修正者并不是最好的产品开发工程师。
如果一个有天赋的修正者在眼前，Goulet懂得如何让他走向成功。下面是如何让这种类型的开发者感到幸福及高效工作的一些方式：
* 给他们高度的自主权。把问题解释清楚，然后安排他们去完成，但是永不命令他们应该如何去解决问题。
* 如果他们要求升级他们的电脑配置和相关工具，尽管去满足他们。他们明白什么样的需求才能最大限度地提高工作效率。
* 帮助他们[避免更换任务][39]。他们喜欢全身心投入到某一个任务直至完成。
总之，这些方法已经帮助Corgibytes公司培养出20几位对遗留代码充满激情的专业开发者。
### 稳定期没什么不好
大多数创业公司都都不想跳过他们的成长期。一些公司甚至认为成长期应该是永无止境的。而且，他们觉得也没这个必要，即便他们已经进入到了下一个阶段：稳定期。完全进入到稳定期意味着你可以利用当前的人力资源及管理方法在创造技术财富和消耗资源之间做出一个正确的选择。
”在成长期和稳定期之间有个转折点就是维护人员必须要足够壮大，并且你开始更公平的对待维护人员以及专注新功能的产品开发人员，“Goulet说。”你们公司的产品开发完成了。现在你得让他们更加稳定地运行。“
这就意味着要把公司更多的预算分配到产品维护及现代化方面。”你不应该把产品维护当作是一个不值得关注的项目，“她说。”这必须成为你们公司固有的一种企业文化——这将帮助你们公司将来取得更大的成功。“
最终，你通过这么努力创建的技术财富将会为你的团队带来一大批全新的开发者：他们就像侦查兵一样，有充足的时间和资源去探索新的领域，挖掘新客户资源并且给公司创造更多的机遇。当你们在新的市场领域做得更广泛并且不断发展得更好——那么你们公司已经真正地进入到繁荣发展的状态了。
--------------------------------------------------------------------------------
via: http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/
作者：[http://firstround.com/][a]
译者：[rusking](https://github.com/rusking)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: http://firstround.com/
[1]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[2]:http://www.courageworks.com/
[3]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[4]:https://www.industriallogic.com/blog/modern-agile/
[5]:http://mobprogramming.org/
[6]:http://exercism.io/
[7]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[8]:https://weworkremotely.com/
[9]:https://www.powertofly.com/
[10]:http://legacycode.rocks/
[11]:https://www.docker.com/
[12]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[13]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[14]:https://en.wikipedia.org/wiki/Behavior-driven_development
[15]:https://en.wikipedia.org/wiki/Conway%27s_law
[16]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[17]:http://corgibytes.com/
[18]:https://www.linkedin.com/in/andreamgoulet
[19]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[20]:http://www.courageworks.com/
[21]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[22]:https://www.industriallogic.com/blog/modern-agile/
[23]:http://mobprogramming.org/
[24]:http://mobprogramming.org/
[25]:http://exercism.io/
[26]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[27]:https://weworkremotely.com/
[28]:https://www.powertofly.com/
[29]:http://legacycode.rocks/
[30]:https://www.docker.com/
[31]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[32]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[33]:https://en.wikipedia.org/wiki/Behavior-driven_development
[34]:https://en.wikipedia.org/wiki/Conway%27s_law
[35]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[36]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[37]:http://corgibytes.com/
[38]:https://www.linkedin.com/in/andreamgoulet
[39]:http://corgibytes.com/blog/2016/04/15/inception-layers/
[40]:http://www.courageworks.com/
[41]:http://corgibytes.com/blog/2016/08/02/how-we-use-daily-journals/
[42]:https://www.industriallogic.com/blog/modern-agile/
[43]:http://mobprogramming.org/
[44]:http://mobprogramming.org/
[45]:http://exercism.io/
[46]:http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/
[47]:https://weworkremotely.com/
[48]:https://www.powertofly.com/
[49]:http://legacycode.rocks/
[50]:https://www.docker.com/
[51]:http://legacycoderocks.libsyn.com/technical-wealth-with-declan-wheelan
[52]:https://www.agilealliance.org/resources/initiatives/technical-debt/
[53]:https://en.wikipedia.org/wiki/Behavior-driven_development
[54]:https://en.wikipedia.org/wiki/Conway%27s_law
[55]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[56]:https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
[57]:http://corgibytes.com/
[58]:https://www.linkedin.com/in/andreamgoulet