- 4 Rules of Simple Design
- Domain-Driven Design
- SOLID
- Patterns
- Law of Demeter
- Tell, Don’t Ask
- POLA/S
- Design by Contract
- Feature Envy
- Cohesion
- Coupling
- Balanced Abstraction Principle
Category: Uncategorized
Test case structure
A commonly applied structure for test cases has
- Setup: Arrange the state of the unit under test in order to run the test.
- Execution: Act on the unit under test so that it performs the expected behavior and receive output if needed.
- Validation: Assert/Verify the outcome of execution.
- Cleanup: Restore unit under test to a pre-test state.
Test-driven development benefits
- Design first: You understand requirement first via analysis, create use cases for it. Thus, the focus is on the requirement before writing the code.
- Good enough code for now: You write sufficient code against use cases that fulfills the user requirements. You don’t write extra lines of unnecessary code.
- Avoid rework: Due to design first approach, most of the doubts are cleared before writing code hence rework is avoided.
- Developer confidence: Continous delivery of requirement in small cycles gives developer a confidence.
- Regression catching.
- Safe Refactoring: Once the code is covered by multiple tests, a developer can safely improve code structure with confidence and can focus on simple and elegant design.
- A shared understanding of the business: Tests are the live documentation that is the communication channel between you and your future version or other developers that talks about business rules.
- Clean code reminder: IMO, TDD always reminds you to make your code better than you found it. Of course, after covering your code with test, make it better.
Rest parameter under the hood…
You know the rest parameter (usually prefixed with ...) allows functions or methods to accept indefinite numbers of parameters.
This parameter is actually gathering the values from arguments and creates an array of values from it.
How? Let’s see with code using ES6 rest parameter and it’s corresponding transpiled version.
Simple snippet with rest parameter
Obviously, line 2 will print an array
[ 'Monday', 'Tuesday', 'Wednesday' ]
You wonder, How it’s an array? Let’s inspect it via
Below code is transpiled using BABEL.
Transpiled version:
Under the hood, the rest parameters are actually derived from arguments object of called function, `print`. Please notice carefully variable days on line# 5.
It’s value is set to an array whose length is equal to number of arguments passed.
Later, elements from arguments are copied to variable days (element by element from line# 8 to 10).
Another Example
In the second code snippet, please note there is a parameter multiplier apart from rest parameter ...numbers. Hence, copying will not begin from first element instead it started from second element till last one.
See transpiled version for more details.
Transpiled version
const does not mean value it holds is immutable
I see many JavaScript developers have started replacing var with const just because some linter forces them to do so.
const in JavaScript is not only blocked scope but also const variable cannot be reassigned with new content.
It creates readonly reference. It means you cannot reassign value to the const variable. It does not guarantees immutability of the content that it holds.
const person = { name: 'John Doe', age: 33};
person = { name: 'John'}
// Above line will throw Uncaught TypeError:
// Assignment to constant variable.
// However, you can change the content of object
// that is referenced by person variable.
person.age = 40;
So, If you really want to mark your object as immutable then use some other API’s like `Object.freeze`.
There are specific use cases about const variable. Make sure you are intentionally marking some variable as const and not because some linter has that rule.
The Journey Begins
Thanks for joining me!
Good company in a journey makes the way seem shorter. — Izaak Walton
Is it time to re-name “Human resources” department?
Few weeks ago, I received an email from a recruiter. The title of the email went like, “Need immediate .NET resources who can join in Blah Blah.. time”. The email kind of triggered many thoughts in my mind. Am I really a “resource”? Is that only what I stand for? If I put in all efforts in my team and company’s success, will I still be a resource for the company? and so on…
We have been hearing this word “Human resources” for a very long time now. One of the companies I worked for hired college students from a campus in huge numbers. Once these graduates would join the company, there was a separate department named “Resource management group” who would look into how to harness these resources for company business. I was one of those graduate resource. For a very long time, I had the kind of feeling which you would have on seeing a huge farm of humans in the movie Matrix. In this movie, the machines would harness these humans for their survival.
It’s a common term in traditional program management to address, people, computers, cubicles everything as resources. “Is the project delayed? Ok, no problem, put 10 more resources and complete it quickly.” We may have heard or even been a part of such conversations.
But, are we really resources? I’m not. I’m not a machine or a chair or a white board. I’m human. I have feelings, thoughts, ideas, knowledge. I get motivated, I get happy, I get sad, I have ups and I have downs. I don’t just type code. I create things, that help others, makes their life easy, things that make difference.
A company is not made by how fascinating offices they have, or how many computers they have. The most important asset for a company is its people, without it’s people, there would be nothing. Many successful companies originated in someone’s basement.
Google has moved away from the word “Human resources”. They call it “People operations”. And we all know the efforts Google takes in taking care of it’s people. And we also know the care it’s people take in keeping Google such a successful company.
I believe people in any company deserve more respect, not just for the work they do, but also because we’re humans. The culture of mutual respect, drives ownership and belongingness. These values can drive any company to great heights.
What is “Google time”?
Software engineering and product development are different from other streams of business (manufacturing, for instance). Things are more predictable in manufacturing, specifically in the execution phase. But it is no so at any stage in product development, where you get to know the next challenge only once you solve the current one.
What has this to do with “Google time”? Many of us might be aware that employers give some time every week to their employees to work on anything they like. Most of the employees during this time spend time on their own learning or working on their own side projects. Many of the in-house tools and even products are born out of this activity.
But the main intention behind giving such “do-Whatever-you-Wanna-do” time to the employees in my opinion is not to churn out such side projects. The main reason and science of this lies in the “Queuing theory”. Less.works explain in great detail how the utilization levels affect the flow of value through the system. I will attempt to summarize it and put it in a context.
Imagine you have a highway and the vehicles are moving through with ease. Let’s say the traffic increases, vehicles gradually start taking more time to get through.
Each new vehicle coming on the highway gets added to the “Queue” and the time to get that vehicle through then is, can you guess?? As may predict it is linear, but it is not. It grows exponentially, until a certain point when you cant get anything out of the system, which means the response time goes to “Infinity” (mathematically). Such a curve is called M/M/1/∞ curve.
So the thumb rule is, when your size of inputs to the queue are random and when the time taken to process each input is random, then the system response can never be linear, it follows the curve we just described. This theory applies to many scenarios including server utilization for production systems and…… yes, you guessed it right, it applies to a developer’s day to day life as well.
How? as we know that in software development, we can never accurately predict the time it will take us to complete a task. We can only guess based on our experience. Each task gets done one after the other, in variable amount of time.
So let’s say that you, as a developer, is given a task each day of the week. There are 5 tasks you need to complete in this week.
On Monday, you are excited and start working on task A. However, it takes some more time in the end to test and deploy the functionality. You therefore, utilize some of the time on Tuesday to finish task A.
But wait, you already need to complete task B by Tuesday day end. Without wasting any time you get to work on Task B. Task B turns out to be tough one to crack, after you start working on it, you realize that you need some more technical help within the team to proceed. It turns out that you finish Task B on Wednesday.
On Thursday, you already have 2 tasks (C and D) in your plate. You start to feel the pressure now, and you are already thinking about multiple things at a time. On Thursday, your manager calls for a team meeting to discuss teams performance in last quarter, you lose half a day in the meeting (not to mention the context switch that comes along with it). You work on Task C, by sitting late in office and try to complete it.
When you arrive on Friday, you already have 3 tasks assigned to you which you need to complete by EOD. You realize that it is unrealistic for you to achieve it. This is exactly the breaking point, mentioned in the “Queuing theory”. Beyond this point of time, no matter how many tasks you keeping adding to “Your Queue”, they will take (mathematically) infinite amount of time to process.
I’m sure this has happened with most of us at some point of time in our careers. Linearity calculations do not work in software development. So how do we solve this problem? Well, that is precisely why good companies give their employees, some time to take control of their queues. Moving fast, compromises quality and increases technical debt. Most of the time, good employee’s, will utilize this Google time to either finish their pending work or to reduce the technical debt they introduced, when they had to finish things quickly.
There may be times when developers finish work quickly than estimated and may spend this time, learning or work on something else. Either way, it benefits the company, but as we just saw, these are the extra benefits. The main intention from management’s perspective is to induce the “Flow”, so that value get’s out of the system at a consistent pace.