今日推薦開源項目：《湯里有毒 nows》
今日推薦英文原文：《11 rules of effective programming》
今日推薦開源項目：《湯里有毒 nows》傳送門：GitHub鏈接
推薦理由：心靈雞湯，指的是能夠為人的思想提供所謂正能量的文字片段；而反過來派生出的毒雞湯，則是提供負能量的。這個項目提供了一個暢飲毒雞湯的地方，簡單粗暴的界面可以很方便的分享給朋友，有福同享有難同當嘛。不過這也就圖一樂看看就算了，不管是心靈雞湯還是毒雞湯，在每個人眼裡可能都有不同的感受，它們沒有對錯正負之分，而你的想法也不應到受這些影響，而是應該由自己決定。
今日推薦英文原文：《11 rules of effective programming》作者：Jakub Kapuscik
原文鏈接：https://medium.com/swlh/11-rules-of-effective-programming-8932f2d99711
推薦理由：讓你花掉的時間帶來更高收益的小技巧
11 rules of effective programming
This is by no mean an exhaustive list but rather my subjective top after spending several years in IT. Hope you finds some of those helpful
1. The Boy Scout Rule
「Always leave the campground cleaner than you found it」 -that』s a great rule to live by. When you are near campground you should make it cleaner even if it was not you that made the mess. That』s one of the rule of scouts. Just the same should apply to programming. As Robert C. Martin paraphrased it 「Leave your code better than you found it」. If we find some hard to read piece of application that someone else wrote and we spent some time understand, let』s make it at least a bit better. If it is out of the scope of task we are working on, one can always create new small technical task, describe it well and take it to the next sprint.Minimalist version of this rule would be more like a sing in public toilets. We should at least not worsen the condition it is in. We have to remember that some people will one day take over that piece of application we developed and will try to modify it. Let』s just not make their life harder.
2. Think about problem, not only solution
Software developers are really great in implementing solutions. We know languages, patterns, libraries, frameworks and understand how to use them. The problem is that often things we are doing make no sense from business perspective. Some features you are developing may be duplication of existing ones that business owner did not know about. Some may not be well-considered and will never make it to next release or simply no user will ever use them. That is a huge wast of time, money and source of frustration. A lot of people do not bother to ask developers on their opinions and just assumes that their job is to deliver the feature. No deliberation. Only technical work.Developers are the ones working with the application every single day. They know every feature even if nobody used it. Sometimes task that seems to be easy from business perspective takes months of development. Some that seems nearly impossible take days. The reason is lack of communication between the people that will be implementing a feature and ones that request it. There is a huge difference between those two:
- Create persistent storage for users』 shopping carts
- Users should be able to save their shopping carts and use it on mobile and web application
3. Think about Total Cost of Ownership
It is very tempting to sometimes cut corners, skip tests for later, leave temporary solution and promise to correct it later. In most cases you never will if it won』t break. There will be new task, priorities, features to implement and issues to fix. The problem you will have will be that such piece of application probably will break. Moreover, it will be very hard to fix.Total Cost of Ownership of a feature is a sum of money and effort spent from start of development, through deployment and maintenance, all the way to termination. If we take shortcuts during development it will be the cheapest part of all. You may release faster but maintenance will be terrible, users will be unhappy and in total everything will be more expensive then it should.
It is always better to do it right the first time
4. Use SOLID
There are a lot of great rules in form of acronyms in programming: DRY, KISS, YAGNI, SOLID and much more. SOLID is a set of rules that should help make code cleaner and avoid common traps.It can be a great checklist for your code before pushing it to repository. Does this class support Single Responsibility Principle? Can this class be substituted by any other from same hierarchy (is LSP fulfilled)? It will help filter out a lot of sources of future problems. Understanding and conscious application of reasons behind each rule will make you better programmer and increase quality of your code reviews.
5. Use Design Patterns
In most cases you are not the first one trying to solve a problem you are facing or implement a feature with similar requirements. There have been thousands of CRM, CMS, banking systems, chats, online shops, marketplaces and basically any possible type of application one can think of. System you are developing may be the best on the market or have some extremely advanced and unique features nobody else have. Still, most of the job will be at some degree referential. Someone else might try to do it on number of different ways and even describe the whole process. It may save you a lot of hassle and guide to better solution.There is a great book by the Gang of Four presenting some of repeatable patterns that could be used to tackle common problem. It was wrote in 1994 but those are still valid and helpful. In software those are ancient times but somehow problems we are facing writing code are now not much different. There have been a lot of more newer design patterns developed since then. Knowing them can make your job much easier.
All design is redesing. Learn from the experience of others
6. Minimize complexity
Software development is a complex task by it』s nature. Do not make it more complicated then necessary. It is sometimes very tempting to implement some business rules by introducing few extra 『ifs』 or loops in a function. Development will be faster but code will get darker and adding new features will just make it more complex. If something will go wrong it will simply be harder to find out the reason.There is a great and very simple metric with a cryptic name Cyclomatic Complexity. It』s was introduced in 70s but can still be very useful. This metric measures number of way your code can be executed. Each conditional statement and loop adds +1 to the score. The smaller the score the better. When we are analyzing a method and the score is in range:
- 0–10: code is well structured and should not cause unexpected problems
- 10–20: code is quite complex and has a lot of potential paths of execution to test. Candidate for refactoring
- 20–50: code is utterly complex and should be subject to refactoring
- 50+: refactoring is a must
# CYC = 1
def cycle(name, bike, view_points=[]):
if len(view_points): # +1
if name and bike: # +2
for point in view_points: # +1
print("{} is going on his bike {} to {}".format(name, bike, point))
else:
print("No places to go. Sorry")
# CYC = 5
7. Don』t do it alone
It may sound counter intuitive but programming is a social activity. Age of programmers hidden in darkness of a basement is over. Sharing expertise and experiences is getting more and more important. In the worst case scenario people you are talking to will become your rubber duck but most likely you will receive some valuable feedback. Someone may identify problems in your solution you did not even consider. Taking a look from different perspective is a great tool and is very easily available.No single person should be responsible for a deployed piece of code. It is a job for a team, not a person, to deliver new features. Code review, pair programming, pull requests are tools that take responsibility from a person and moves it to a group of people with preferably cross-functional skills. Responsibility for an important feature that may influence performance of whole company for better or worse is simply too much to shoulder for a developer. Such situation is very unhealthy and should never take place.
8. Tests are a must
Finding bugs early is extremely important and saves lot of effort and angry calls from clients. Discovering problems early makes them easier to solve. We are able to remember all details and logic behind specific piece of application best when we are developing it. We remember all reasoning for making specific decision and how to debug each piece of application. Cost of fixing bugs grow exponentially over time.
Source: https://deepsource.io/blog/exponential-cost-of-fixing-bugs/
9. Learn English
Sharing knowledge have always been one of fundamentals of software community. Most of the information is written in English and is easily accessible. It it right now most popular language of all in software world. If you are not able to read and write in English you will have much harder time and loose a lot of opportunities. Moreover, syntax of nearly every language is by default written in English.It is also a good practice to write comments and names in code in English. It makes code cleaner and more consistent with the syntax. If we are sharing code with other people, especially from different country, there is basically no better way then to do it in English.
10. Multitasking makes you stupid
People are simply not able to make multiple things at once well. Software development requires using abstract concept and often building quite complex mental models. If you get distracted or start working on something else you lost it all and have to start from the beginning. Moreover, there are multiple studies that proved that multitasking has negative impact on performance, productivity and IQ.
Source: https://insights.sei.cmu.edu/devops/2015/03/addressing-the-detrimental-effects-of-context-switching-with-devops.html
I have once been on a training in a software house that introduced very useful practice. If you do not have any scheduled meetings or calls you are free to play 「Tomato」. The rules are very simple -you do not have to speak to anyone. If someone ask you any question, you answer with a single word: 「tomato」. Therefore, you show that you are in a middle of work and do not want to be bothered. When people are in 『tomato mode』 they also indicate it in their calendars for chosen hours. It is not always good to go fully 「tomato」 but it is interesting way of improving performance.
11. Better less, but better
The less code and infrastructure to maintain the better. There are a lot of people that like to boast about huge number of line of code in their application, number of modules, servers, nodes, pods, micro-services or any other things. There is a chance that every line of code in their application is of highest quality and is just in the right place. But this is a very rare case. If you can do the same job with usage of fewer resources you should go for it. Quality is a the goal, not quantity.下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
