今日推薦開源項目：《Clean-code-javascript》
今日推薦英文原文：《KISS in Practice》
今日推薦開源項目：《Clean-code-javascript》傳送門：項目鏈接
推薦理由：該項目介紹了 Robert C.Martin 的著作《Clean Code》（中文名：《代碼整潔之道》）對JavaScript代碼編寫的建議，並附有樣例。和文章一樣，代碼整潔是編寫過程中不可忽視的一環。變數名
currentDate 顯然比 yyyymmdstr 好得多不是嗎？
今日推薦英文原文：《KISS in Practice》作者：Wojciech Kasperczyk
原文鏈接：https://medium.com/swlh/kiss-or-not-to-kiss-1f5bc28e7610
推薦理由：本文也是關於代碼編寫原則和思想上的建議。標題「KISS」是軟體工程中的一個常用概念，即「Keep It Simple, Stupid」，不應將事情過於複雜化。
KISS in Practice
KISS is a common method used in software development. It stands for Keep It Simple, Stupid. What does it mean, how would you use it and when simple is not necessarily better?What does it actually mean?
KISS simply put is a mindset — you should not complicate things more than necessary. It finds perfect place in software development as this is a domain that is very prone to overcomplication. There is almost infinite number of possible solutions to every problem, but many of them are just too complex.Young software engineers are so eager to present all their knowledge, apply everything they learned in real life but fail to understand one thing — in business, what matters is the end result not the way of achieving it. Don』t get me wrong, there are still unethical ways of achieving your goals and even though they are simpler you shouldn』t take that road. Here I』m focusing on your workshop as a professional.
Constrains should drive your solution.
Following KISS principle seems rather simple. You just don』t complicate your code and you should be fine, right? Well, not exactly. Usually your solution does not have only one dimension. It is not enough to just solve the issue business is presenting to you. Your manager may want to achieve some goal, but your job as an engineer is to ensure that this goal is not only reached but is also within certain constrains.What are those constrains? They could be anything really. It usually depends on your project, but there are some common ones that you should take into account.
When time is key.
First thing you should take into account when developing new feature is time. There are many aspects to which time could be applied.On most basic level time complexity is the thing that most engineers think when they are speaking of time. Time complexity is crucial when working in games industry. It is even more important in real time applications, the ones that are overseeing sensitive operations and should quickly react to changes. When designing your solution you should strive for it to work as fast as possible. Usually this means less abstraction, less layers of code indirectly passing messages around. You should have a clean, straight path between input and output. No unnecessary allocations, calling virtual methods that could be overridden in subclass. It should be… well, simple.
When maintainability is key.
That speed of work comes with a cost. That cost is also connected to time but in a different way. It is the speed of development. When you create a pice of code, usually that code lands in some kind of repository, so that other developers could pick up what you did and expand on it or fix any mistakes you』ve made. Problem with code that is very efficient in getting the job done is that it is more prone for side effects caused by small changes in the code. There is usually no way of modifying the code to be customizable. Customization requires at least lookup for parameters and usually it involves some kind of abstraction and indirection.To sum it up — when writing business applications that could be maintained for years by multiple developers you should take into consideration the time other developers will spend fixing your code. In that sense modifying your code should be simple.
When versatility is key.
Last thing I would advise you should consider is how versatile your code should be. You might think that the best way is to cover all cases how your code could be used. Lets say you are developing a library that would be used by other developers to create their products. Key here is to know when to stop. At some point your code is covering 90% of your users』 needs. You should ask yourself if it is enough. Answer to that will be crucial.Users, both developers and end users, always want more. More features, more ways of interacting with your software, you name it. If you have access to your users — talk to them. Ask what is the most important feature and focus on that. If they like it there will be time to expand on it. If they don』t like it, you lost minimal amount of time possible to verify it.
Thinking about every possible feature your software might have is very important and shouldn』t be overlooked, but you don』t have to implement everything at once. Again, we come back to the KISS principle — you shouldn』t complicate your code in the name of future work or unnecessary functionality. Abstract what you can, so that later you won』t have problems with adding new things.
Putting it all together.
We』ve look at three things you should take into account when designing your solution: time of execution, maintainability and versatility. There are many more things you might consider, but those three are a starting point and you should always take them into account. Everything is connected and you should find balance among all aspects. That balance would greatly depend on the specifics of the project you are working on. There is no perfect solution, if there was one we wouldn』t have jobs. Look at your problem from many angles and remember: whatever is the most important part — keep it simple.下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
