This content originally appeared on Level Up Coding - Medium and was authored by Max Boguslavskiy
A quick introduction to Agile Mindset of Agile Developer
Introduction
Onboarding new personel is a very crucial step. Imagine yourself as a newcomer. You walk into new territory, and everything is unknown to you. Yet, you are chosen for the task and capable of doing your work. But what amount of time and you will waste your inner resources if somebody won’t guide you into your new line of work? What costs you and the company you are working for will be a total lack of information on how you should do your job.
Every company is different, and every culture has its differences. And to describe an example of how our company could solve things, I want to share with you the following guidelines.
Our company vision and development guides from our department form the following PRINCIPLES, STANDARDS, and METHODOLOGIES. We use them in our work daily.
Principles
We base our work on the following principles of Agile Development:
SOLID concepts
- The Single-responsibility principle: “There should never be more than one reason for a class to change.” In other words, every class should have only one responsibility.
- The Open–closed principle: “Software entities … should be open for extension, but closed for modification.”
- The Liskov substitution principle: “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.” See also design by contract.
- The Interface segregation principle: “Many client-specific interfaces are better than one general-purpose interface.”
- The Dependency inversion principle: “Depend upon abstractions, [not] concretions.”
“Don’t repeat yourself”
(DRY, or sometimes “do not repeat yourself”) is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
Code reuse
Code reuse, also called software reuse, uses existing software, or software knowledge, to build new software.
We are trying to use tools and libraries like “lodash” to speed up development and avoid re-inventing the wheel.
Package principles
Organize classes in more extensive systems to make them more organized and manageable.
In our department, we are highly encouraged to use great Yarn 2.0 features like “workspaces.” Our department is responsible for more than six applications, and we split them between 3 repositories. They use the same API and work with the same date. To reduce code duplication, we use the internal package system and Yarn 2.0 ’s workplaces. This way provides us with some middle ground before the private publication of packages.
“You aren’t gonna need it” (YAGNI)
is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.
In our practice, we are trying not to force things. For example, on the first implementation, we might not know how customers will use this functionality. So we are trying to implement the most common and obvious ways possible. This approach allows us to show implementation ASAP (As Soon As Possible) and confirm our offering matches needs.
Standards
In our work, we try our best to follow industry standards:
- W3C;
- ES6;
- Typescript guidelines;
- WebGL.
To lower code review labor and provide some automation, we are using the following instruments of static code analysis:
Linting
Our team stores ESlint and Typechecking rules config as a package, which all our teams are expected to use. We also allow the possibility to tune local settings for each group.
Sonar rules
We use this tool as an instrument for the visualisation and storage of static code analysis. For our project, we use default Quality Gates. It is based on the “Fix the water leak concept.” More info here: https://docs.sonarqube.org/7.4/user-guide/fixing-the-water-leak/
Methodology
Methodology is a blueprint of the process of development. It’s necessary step which leads to
Prototyping UI (User Interface)
We are highly encouraging our developers to prototype UI tasks before starting implementation. This easy step allows us to discuss future implementation with stakeholders and validate the vision. If possible, we are highly encouraged to delegate this task to our developers or implement UI together with them.
Mocking backend data.
To prevent delays, we ask our developers to negotiate the implementation of backend requests with the backend developer. It allows us to form a blueprint, which will serve as a contract for future data exchange. We highly recommend adding these requests to a mocked server. In our case, we use Service Worker, which captures network requests and replies with mocked data.
Writing tests
I highly recommend that you provide yourself with tests before starting implementation. It will be easier to control the quality and manage the completeness of the code. We can divide Our unit tests could into four groups:
- UI. Primarily we test that the interface handles data sets well. For convenience, we use snapshot testing. Then we add tests that fire required events to trigger necessary parts of code.
- Tools. Then we test helper functions. We feed them various data and check that they handle data correctly.
- Backend. We use nock. It allows us to update requests and mock requests to the backend easily.
- Store. In our case, our application uses Redux. In this case, we must check thunks actions. It is easier to provide default state for part of Store, trigger required actions and compare actual movements with the standard set of steps.
Development
Don’t rush things — split tasks into smaller chunks. Implement a happy path first. Use stubs. Don’t try to implement everything from one go. Save often!
Code review
When you accept:
- Be grateful and polite. Remember that another person helps you.
- Try to understand the other person’s view even if you think that he could be wrong.
- If feedback is optional or it would take more time to implement that current temporary solution. It is a beautiful tradition to create a tech debt task, which the developer will implement later.
- If something is unclear, don’t throw debates. Make a call and share the screen. It’s easier to understand when you are both looking at the same thing.
When you review someone:
- Try to be direct, confident, analytical, and friendly.
- Try to be specific and provide small code examples of your idea. We are not playing riddles or trivia.
- Do not forget to praise for intention. We are on the same boat, and we are pushing our company towards the grand goal!
- Suppose you want to judge another person’s work. Please note that people are susceptible to critics. So please be very cautious while selecting three options:
- Block merge (Highly conflicting option) .It’s when for some reason, it’s not great to merge PR. Please provide some comments on why you are doing this.
- Task (Moderate conflicting option). Suppose this is an issue that the developer should fix before merging. Tasks are greater than comments: they have links to code versions, and developers could check their PR progress.
- Comment — If you have an idea and you think that it is optional. It is excellent to place a comment for a colleague.
Validation
It is a process when we try to determine that our functionality works as expected before handling it to the SQA engineer. It’s a very crucial step — it raises trust in your work, and you can ruin it easily by not checking some visible parts in your work. This process should be performed in two places:
- Locally. We could check all implemented steps on local env. It is easier to debug, but data could be outdated.
- On Environment. We deploy our functionality via Bamboo on our testing ENVs. Then we check all requirements described by our analytic.
Conclusion
- People from outside are not familiar with your procedures, so it’s vital to provide some information on how you expect them to do their job.
- The guideline is also a vital step for your company’s transformation because it’s easier to transform a newcomer and show their behavior as an example of how your colleagues should do things.
- Guidelines save a lot of time, nerves, and effort because they show a valid path.
Development guidelines was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Max Boguslavskiy
Max Boguslavskiy | Sciencx (2021-11-04T04:17:41+00:00) Development guidelines. Retrieved from https://www.scien.cx/2021/11/04/development-guidelines/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.