每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，欢迎关注开源日报。交流QQ群：202790710；微博：https://weibo.com/openingsource；电报群 https://t.me/OpeningSourceOrg
今日推荐开源项目：《使用CSS的正确姿势 CSS Protips》GitHub链接
推荐理由：这个项目记载了许多使用 CSS 时方便的小技巧，比如每个格子都等宽的表格，让元素垂直居中，使用 unset 把所有属性变为默认值等等，兴许它们之中就有一些能够解决你经常遇上的问题。
今日推荐英文原文：《Does your team write good code?》作者：Henrik Haugberg
原文链接：https://medium.com/techtive/does-your-team-write-good-code-8b1dcec6404d
推荐理由：团队开发合作中好的代码库会让你们事半功倍，这篇文章就是介绍形成一个好的代码库的方法的。
Does your team write good code?
Digital services and applications can look amazing while built on a terrible codebase that requires large amounts of work and maintenance. Or they can look outdated and uninspiring while the architecture below is top quality.
Design and code quality are two completely different aspects of a product. A bad code base leads to a number of challenges:
- Steep learning curve for new developers.
- Development of new features requires more time.
- Rewriting existing code takes longer.
- More maintenance.
- Errors occur more often.
- Reduced performance.
- Less attractive to work with.
It is quite common for work on a bad code base to take 3–5 times longer compared to a good one. If your team on average spend 3 times as much time on developing your product compared to what they could have done, is that enough reason to focus more on code quality?
The problem a that all such comparisons are based on assumptions and rough estimates. Developers’ work can not be measured in quality in the same way as many other roles. For this reason, it is much easier to prioritize the development of demanded and marketable features.
How can you, as responsible for the team, know how good or bad your code base is if you do not work in it yourself? It is important to find terms and language that makes it possible to understand a little more of what’s happening under the hood (without being a mechanic yourself). It’s a bit too easy to say “We have a lot of legacy”.
Focus areas may vary between different technologies, but here are some important elements for a good code base.
1. Established language standards
Many programming languages change. New versions of the language allow syntax and functionality that have gone through an extensive process before they become part of the standard. There are big variations in how quickly such changes are taken into use. What has become a part of the standard should be used in cases where it is appropriate. Old ways to solve the same issues create unnecessary extra work.
2. Syntax & unwritten standards
Most internet communities for a given language establish some habits over time for how the language is written. It goes right down to the smallest syntax. Single quotes or double quotes? Brackets? Camel case? Lower or upper case class names? A team must decide what is best for their needs. But the longer you deviate from what is most common in all examples, documentation and people’s habits, and the less consistent you are through the company’s codebases, the longer it takes to work on the code. Not least for new people.
Use a linter if you do not already, and keep discussions on what rules are in use and why!
3. Readability
Code readability is linked to everything from syntax and comments, to architecture and naming of variables and features. Imagine reading a whole book where the whole text is written in a single continuous section? That’s how it is to read the code with low readability. Even for the developer who wrote it, long afterwards. Space and comments in code are as sections and chapters / headings in a book or article. Good readability is important!
4. Modularized (loosely coupled)
Codebases tend to end up like spider webs. All parts are interrelated, and if anything happens, the entire network is affected. This has led to an ever increasing focus on building code as loosely coupled components. Clearly defined roles for each area of the architecture. More code reuse. Fixed patterns for how data structures are built up, processes, microservices, etc. Avoid the code base becoming a huge monolith where refactoring always involves high costs.
5. Community-driven dependencies
Twenty years ago, all the wheels had to be invented in all projects. Fortunately, this is not the case today. There are huge amounts of open-source libraries that try to simplify logic and resolve issues that occur frequently. Use what’s in the community, and contribute yourself too. Or create your own open source module if you find something that you think others may need. It leads to more modular code, greater prerogatives for writing good tests, you contribute to the community, and becoming more visible as tech company.
6. Programming paradigm
There are many programming paradigms that can be used as part of the architecture of a code base. Object-oriented programming, functional programming and similar paradigms, have advantages and disadvantages. Think about what and why and if you see good reasons to change the architecture, do not leave it because it may involve a little comprehensive rewriting job. Make it parallel to other tasks, and phase out the old over time.
7. Design patterns / flow
It is important to think about how the logic and data flow in the code. Are things thrown back and forth in all directions? Do certain groups of logic and modules have responsibility for predefined steps? There are many patterns for programming architecture. MVC, MVP, PAC, MVVM, etc. Whether you follow a predefined pattern or not, this has a significant impact on code quality. Go to Italy for spaghetti.
8. Logic
Programming is more than just structure and syntax. How you actually solve the individual task also has a big impact. No matter how much you try to keep the building blocks loosely connected, there will always be many dependencies back and forth. The way this is linked together has a great impact on usage and scalability. In this area there is experience that counts. One must have experienced and solved similar challenges earlier to know the advantages and disadvantages of different solutions and patterns. Avoid messy logic. And not least, discuss solutions with colleagues! Share each other’s experiences and learn from what has been done on the project earlier. Give yourself room to rewrite where you consider it appropriate.
9. Standardization
When you code, you are an architect in one form or another every single day. Not for anything that will stand still in the same place every day, but something dynamic, that will be a part of people’s habits. How often do the habits change? It’s all too easy to just solve the problem you see there and then, without thinking about whether it could be built into a standard. A standard for this code base. Or for this company. A small standard that is followed in similar solutions and similar needs. The needs in technical architecture always repeats! Certainly with small variations and unique local needs, but look for patterns. Standardization is difficult, but probably the most important thing to increase code base quality! Standards must be able to change, but with higher threshold than other logic. This leads to reduced workload for all development, less maintenance and more satisfied developers!
“Don’t leave broken windows!”
– The Pragmatic Programmer by Andrew Hunt and David Thomas
The most important focus is: do not let bad code become a habit! If you do not add cornices or fix the small hole in the wallpaper at home, you will get used to it and it will never be done. But people who are visiting will notice it. Do not let the weaknesses in the code reside. Can you live with “good enough”? Yes absolutely! But what cost does it bring over time, and what could you achieve if code quality was maintained at a higher level?
每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，欢迎关注开源日报。交流QQ群：202790710；微博：https://weibo.com/openingsource；电报群 https://t.me/OpeningSourceOrg