开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
今日推荐开源项目:《wifi-password》
今日推荐英文原文:《5 Ways To Increase Your Software Development Speed》

今日推荐开源项目:《wifi-password》传送门:项目链接
推荐理由:该项目能够在命令行快速获取 wifi 密码,并能够生成二维码,方便移动端连接。
今日推荐英文原文:《5 Ways To Increase Your Software Development Speed》作者:Jacob Veal
原文链接:https://medium.com/better-programming/5-ways-to-increase-your-software-development-speed-2ea989d8d8cc
推荐理由:一些提高软件运行速度的方法和工具。

5 Ways To Increase Your Software Development Speed

Invest in these developer tools to produce greater returns in the long run

How can we ship features faster? Why are we not hitting our target dates?

These are questions from product managers that software developers often hear when the project is not progressing as projected.

The answer to these questions is to listen to the development teams and allow them the time to remove bottlenecks and reduce constraints in their workflow.

The ongoing goal for software development teams should be in the realm of building and shipping high-quality software quickly at a sustainable pace.

Throwing more engineers at the project — or them working more hours will not move up the target dates. It will only slow down the team or burn them out.

Investing in iteration speed increases the software development team’s velocity over time.

My team and I have spent a significant amount of time improving our workflows, and the investments have most definitely paid off.

We achieved this by communicating the pain points that were slowing us down to our product owner. Our product owner then battled with managers for the time we needed to fix them.

So here’s what we did…

Monolithic Repository

We had three repositories for the application before combining them into one. A repository for the user interface, API, infrastructure of the application, and some other ones included as submodules.

Having all of the source code in a single repository greatly simplified our development and made code reviews more effective. Instead of having to open two or three pull requests for a feature, there was only one. The team could now review all the related code changes in a single view. Sure, this increased the size of our pull requests, but the trade-off was worth it.

Our continuous integration pipelines have also benefited from this improved structure. We no longer needed complex logic or submodules to keep track of the API, user interface, or infrastructure versions required for deployments. Every related change stayed together in perfect harmony.

Readable Code

Our application’s tech stack used Elasticsearch for the database. As the number of features we implemented grew, so did the complexity of our queries and aggregations.

We were having a hard time understanding the queries, which of course, increased the effort it took to modify them. This difficulty limited the number of developers capable of working on them and resulted in knowledge silos within the team.

We spent the time to simplify the queries by using a more readable query syntax called Elasticsearch DSL. We then documented the behavior of them like an 8th grader was going to read it.

Long story short, we spent the time improving the readability of the code. This aspect of coding should never be overlooked — but invested in instead. Everyone on the team is now able to read and modify the queries without requiring much effort.

Rapid Local Development

Like many applications, ours uses AWS cloud-native services like Lambda, Kinesis, SQS, and API Gateway.

Our workflow required pushing up any new code changes and then deploying them to a development environment before testing them. This process took way too much time. Even with one developer using this flow, but we had about 15.

The goal is to reduce the time in the feedback loop as much as possible when testing code changes.

We invested our time to create a process where we didn’t have to deploy our changes to get feedback. We used a combination of docker-compose services and Localstack. A developer can now run the entire application on their workstation with a single command, docker-compose up.

Efficient CI/CD Pipelines

Our continuous integration pipelines were slow and error-prone.

We would fix one issue, and then another one would appear. Not only did we experience blockers, but our deployments and integration tests were taking way too long to complete.

We fixed our problems by overhauling and optimizing our build processes by using pre-built docker images and parallelization wherever possible.

Prebuilding our docker images saved on average two and half minutes, and since we were using them for multiple build steps, the time savings stacked.

The continuous integration/delivery pipeline is the backbone of software development. Any downtime or inefficiencies have a direct negative impact on development speed. So operations must run smoothly and efficiently.

We adapted a dev-ops culture within our team to address issues and further improve processes, and it has significantly paid off.

Stable Automated Integration Tests

Having fully automated integration tests that pass consistently can be challenging to achieve depending on the application’s nature — but they pay off in the long game.

Because our application used Elasticsearh, saving data is eventually consistent. The data is not immediately available for retrieval until it has been indexed. The eventual consistencies were a challenge for our integration tests.

We overcome this challenge by utilizing retry mechanisms based on specific HTTP error codes thrown by the API. So when an API call from a test received a 404, it would wait for a sec and then retry the API call.

Spending time to improve our tests and testing framework gave us more confidence our application was behaving as intended.

Closing Thoughts

The improvements we made gradually started to increase the number of stories we completed within a sprint. It didn’t require working more hours or a carrot in our faces.

These examples and suggestions may not apply to your project, but I hope they have given you ideas or inspiration to start investing in iteration speed. It’s a mindset shift that teams need to adapt to help them work smarter, not harder.

Thank you for taking the time to read my article!


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