開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《車軲轆 gulu》
今日推薦英文原文:《Good Developers are Smart, not Clever.》

今日推薦開源項目:《車軲轆 gulu》傳送門:GitHub鏈接
推薦理由:要向製造一個輪子,必然需要了解很多輪子。這個項目是一個前端 UI 框架——也就是一個輪子,不過這個並不是拿來正式使用,而是給新人來閱讀源碼的。框架的用戶千奇百怪,所以編寫框架不僅要追求高性能,也要注意代碼的整潔可讀性等等各方面內容,而讀一讀現有框架的源碼正好適合用來學習這些。
今日推薦英文原文:《Good Developers are Smart, not Clever.》作者:Ravi Shankar Rajan
原文鏈接:https://medium.com/swlh/good-developers-are-smart-not-clever-4d1d4bde8868
推薦理由:變強就是把努力用在正確的地方——還有就是別停止努力

Good Developers are Smart, not Clever.

Good code is expressive, not impressive.

One of my first lessons as a developer 15 years ago was a simple, short message.
「Good code is expressive, not impressive」
I remember retorting back, 「What is the difference?」 and he had said.

「Expressive」 means clear-cut, definitive and specific. So writing an expressive code will necessarily have to address a specific problem. There is a purpose behind investing time and effort in creating it and it does exactly what it was intended for.

」Impressive」 on the other hand means to leave a stamp or an imprint. So writing an impressive code with complex constructs and algorithms, while it might satisfy your ego and get you the wows, eyebrow-rolls, and claps, it might turn out to be a pain of unmitigated proportions for the guy who is going to maintain your code in the future. And if he happens to be a psychopath who knows your address, only God can save you then from his wrath!

That is why good developers are smart, not clever. A smart developer combines natural intelligence with an ability to judge the consequences of his action in the future. They know exactly what code they are writing, why they are writing and how the code will impact in the long run. In short, they are not Band-Aid developers. They believe in fixing the disease once and for all.

Clever developers, on the other hand, are fast, quick and know all the dirty ways in the world to make a code 「work」. They combine natural intelligence with an ability to find supersonic solutions to every problem at hand. But over time the bandages and duct tape build up and one day the code simply crashes along with the reputation of all developers who had worked on it. That is why Steve McConnell had righty said.
「Programming is not like being in the CIA, you don』t get credit for being sneaky.」
And smart developers do not do anything sneaky. They write code, which is boring, simple and easy to understand. Nothing more, nothing less.

And here are some great things smart developers do.

They keep it simple.

Martin Fowler had righty said.
「Any fool can write code that a computer can understand. Good programmers write code that humans can understand.」
Developers sometimes get the feeling that they need to prove. They need to show to others what they can do and are capable of. This makes them search for complex solutions to every problem when the simplest solution would be staring right at their faces. This is the worst mistake any developer can make.

Smart developers write straightforward code. Straightforward code is easy to maintain, optimize and refactor in the future. It does nothing crazy or unexpected and everyone reading it knows precisely what it does. Novel and unusual algorithms and approaches typically look great during a coffee-fueled all-nighter but fail miserably in real-time situations.

Remember whenever you write code and a little bird called ego starts tempting you, ask yourself one simple question.

「If I come back and work on my code after 2 months, will I be able to understand it?」 If the answer is yes, go for it by all means but have pity on your fellow programmers by putting in proper comments, naming variables properly and modularizing it as much as possible so that it does not need to be explained.
Good code is like a joke. If it has to be explained, it is not a good one.

They know when to improve any code.

Edgar Dijkstra has rightly said.
「Focus on WHY instead of WHAT in your code will make you a better developer.」
That said, there are multiple ways to optimize code. Each of the possibilities comes from using more memory, faster execution or different algorithm/logic. And whenever possible, smart developers make this choice wisely.

But before starting any code improvement activity, they follow the golden principle of 「don』t」.

Why should I do it? Is the program good enough already? Knowing how the program is going to be used and the environment in which it runs, is there any benefit of making it faster? These are some questions you should ask prior to optimizing the code.

Yes. Optimization only makes sense in terms of effort and cost if the program is important and it is genuinely slow and there is some expectation that it can be made faster while maintaining robustness, correctness, and clarity. A fast program that gets the wrong results is of no use to anybody. Effectively optimized software has more advantages than disadvantages, but if you do the optimization wrong, the opposite is true.
Remember whatever you are improving should be measurable. Intuition is always a very lousy guide on which to depend on.

They maintain rather than build code.

Vicky Gundotra hit the nail bang on the head when he said.
「You start coding. I will go find out what they want.」
Smart developers do precisely that. They start by searching for the solution in what is available. While some of us like to get on our high horse about rebuilding things the 「right way.」 in most cases we end up burning efforts in reinventing the goddammed wheel.

Do not be afraid to search. Looking up for already implemented solutions online or in your code database is very helpful in learning the methods prevalent for similar situations and the pros and cons associated with them. That is why smart developers spend a lot of time reading code before writing. Writing a brand new code is always expensive in terms of time, money and emotional energy. Don』t do it unless really required.

So when you are trying to complete a task, check to see if someone else has already solved the problem. You are not cutting corners here. You are cutting the effort here.

They challenge themselves.

Aristotle has rightly said.
「If something that you are doing does not challenge you, then it does not change you.」
Smart developers challenge themselves, more precisely the code they had written at every opportunity. They are humble enough to admit that no code is the best code ever created.

They do not settle down in a comfortable rut and deploy the same pattern every time. They consciously avoid their coding preferences to degenerate into blind dogma. They always look for ways and means to do things better and if this means learning something new, they are all game for it.

Remember, Smart developers, are not enamored by shiny ideas or jazzy features. They are pragmatic enough to realize that there is no perfect solution and every great feature or amazing hack comes with downsides.

Lastly, they are not afraid to ask for help.

Sophocles has righty said.
「If we always helped one another, no one would need luck.」
As developers, we like to think of ourselves as smart people. In fact, some of us are pure geniuses also. But having said that, we do have a tendency to think that we know everything and we can think of everything within our minds. After all, who will want to say, 「I don』t know」 in a meeting? Who will want to admit that the new functionality to be deployed is all Greek to you?

Instead, you tell yourself: 「I』ll figure it out myself. I have always relied on myself in the past. I can do it again.」

Smart developers don』t do that. They know when to ask for help and when to use their own minds. They know precisely that any further delay in asking for help will lead to anxiety and subsequently put pressure on everybody in the team to meet the deadlines. That is why they are not afraid to expose their own ignorance and ask for help whenever required.

Remember asking for help is not a question on your capability. It just reinforces the confidence that others have in you that, you will do whatever it takes to complete your work on time and with the right results. You come across as a go-getter, confident developer who wants to change himself every day for the better.

As Kubra Salt has righty said.
「Asking questions is the first way to begin change.」

下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/