What is solid principle

https://medium.com/@mari_azevedo/s-o-l-i-d-principles-what-are-they-and-why-projects-should-use-them-50b85e4aa8b6
https://medium.com/better-programming/solid-principles-simple-and-easy-explanation-f57d86c47a7f

S.O.L.I.D is an acronym that represents five principles of object-oriented programming and code design theorized by our beloved Uncle Bob (Robert C. Martin) by the year 2000. The author Michael Feathers was responsible for creating the acronym:

[S]ingle Responsibility Principle
[O]pen/Closed Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle

Single Responsibility Principle:

A class should have one, and only one, reason to change.

One class should serve only one purpose. This does not imply that each class should have only one method, but they should all relate directly to the responsibility of the class. All the methods and properties should work towards the same goal. When a class serves multiple purposes or responsibilities, it should be made into a new class.

Open-Closed Principle:

Entities should be open for extension, but closed for modification.

Software entities (classes, modules, functions, etc.) should be extendable without actually changing the contents of the class you’re extending. If we could follow this principle strongly enough, it is possible to then modify the behavior of our code without ever touching a piece of the original code.

Liskov Substitution Principle:

The Liskov Substitution principle was introduced by Barbara Liskov in her conference keynote “Data abstraction” in 1987. 

Robert Martin made the definition smoother and more concise in 1996:

Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.

Or simply: Subclass/derived classes should be substitutable for their base/parent class.

It states that any implementation of an abstraction (interface) should be substitutable in any place that the abstraction is accepted. Basically, it takes care that while coding using interfaces in our code, we not only have a contract of input that the interface receives, but also the output returned by different classes implementing that interface; they should be of the same type.

Interface Segregation Principle:

A client should not be forced to implement an interface that it doesn’t use.

This rule means that we should break our interfaces into many smaller ones, so they better satisfy the exact needs of our clients.

Similar to the Single Responsibility Principle, the goal of the Interface Segregation Principle is to minimize side consequences and repetition by dividing the software into multiple, independent parts.

Make fine grained interfaces that are client specific.

Dependency Inversion Principle:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Or simply: Depend on abstractions, not on concretions.

By applying the Dependency Inversion Principle, the modules can be easily changed by other modules just changing the dependency module. Any changes to the low-level module won’t affect the high-level module.

Agile manifesto and principles

The Four Values of The Agile Manifesto

The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development. Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.

1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.

2. Working Software Over Comprehensive Documentation -> living document
Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.
The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out the details of a delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.

4. Responding to Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.

With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.

Perhaps nothing illustrates Agile’s positive approach to change better than the concept of Method Tailoring, defined in An Agile Information Systems Development Method in use as: “A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.” Agile methodologies allow the Agile team to modify the process and make it fit the team rather than the other way around.

The Twelve Agile Manifesto Principles

The Twelve Principles are the guiding principles for the methodologies that are included under the title “The Agile Movement.” They describe a culture in which change is welcome, and the customer is the focus of the work. They also demonstrate the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs.

The twelve principles of agile development include:

1.       Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.

2.       Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.

3.       Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.

4.       Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned.

5.       Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.

6.       Enable face-to-face interactions – Communication is more successful when development teams are co-located.

7.       Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress.

8.       Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.

9.       Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.

10.   Simplicity – Develop just enough to get the job done for right now.

11.   Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.

12.   Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.

The intention of Agile is to align development with business needs, and the success of Agile is apparent. Agile projects are customer focused and encourage customer guidance and participation. As a result, Agile has grown to be an overarching view of software development throughout the software industry and an industry all by itself.

Advertisements

Ceremonies in Scrum Cycle

·         Sprint Backlog Refinement

·         Sprint Planning Meeting

·         Daily Stand-up Meeting

·         Sprint Review Meeting

·         Sprint Retrospective Meeting

Sprint Backlog Refinement

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.

As mentioned above, Product Backlog refinement is an ongoing activity, and unless it is being conducted at scale it does not restricted to be a time-boxed event (or meeting). However, there is nothing to stop teams from time-boxing each refinement session anyway. In general it is good practice to use time-boxing.

Sprint Planning Meeting

The goal of Sprint Planning is to answer the questions “What are we going to work on, and how are we going to do it?” It’s also important for the team to have a shared goal and a shared commitment to this goal before beginning their Sprint – the list of items the team plans to work on during that specific Sprint. The team then breaks down these items into tasks, typically no bigger than a 2 days’ worth of work.

Daily Stand-up Meeting

Once we begin a Sprint, we have what we call a Daily Scrum every day. Organized by the Scrum Master, Daily Scrum is typically a 15-minute stand-up meeting to synchronize the work of team members, i.e. what’s done on the prior day, what needs to be done today, identify any impediments, and creates visibility around the work that everyone is doing in the Sprint.

Note That

At the end of the Sprint, the goal is to have a Potentially Shippable Product Increment (PSPI). We’re trying to get something of incremental value done every Sprint.

Sprint Review Meeting

Held at the end of each sprint to demonstrate the added functionality. The goal is to get feedback from the product owner and other stakeholders to ensure that the delivered increment met the business need and to revise the Product Backlog based on the feedback. This feedback will then become items that will be looped back into the Product Backlog, where it can be ordered and pulled in by the team in a future Sprint.

Sprint Retrospective Meeting

Retrospectives typically last 90 minutes and are there to help us incorporate continuous improvement into our team culture and into our Sprint cadence. This is where the Scrum Team meets to reflect on their previous Sprint and to figure out how to improve as a team by asking – what went well, what did not and what can be improved. It allows the team to focus on its overall performance and identify strategies for continuous improvement.

Flutter vs Xamarin vs React Native

From https://blog.logrocket.com/flutter-vs-react-native-vs-xamarin/

What is cross-platform development?

Cross-platform mobile app development allows you to build mobile applications for multiple platforms such as iOS and Android with just one technology stack.

This means that instead of creating multiple versions of your app, each written using the dedicated native language for each platform, you can write your code once and deploy it on several platforms at once.

Cross-platform development advantages

There are several pros when it comes to cross-platform mobile app development compared to native mobile app development, including:

Write once, deploy everywhere

The most significant advantage of cross-platform development is having a single codebase that you can export to multiple operating systems.

Uniformity across apps

Having a single shared codebase allows you to maintain the same look, feel, and experience across all platforms. All updates and fixes are also automatically reflected everywhere.

Saving resources

Instead of having separate teams with different skill sets working on multiple native versions of your app, you only need one team working on a shared codebase. This allows you to leverage smaller teams and quicker development time to save time and money.

Audience reach

Having your app published on multiple platforms allows you to increase your market reach without any added effort, consequently increasing your chances of getting more downloads and users.

Cross-platform development disadvantages

While cross-platform development comes with many benefits that make it an optimal solution for many developers and companies, they come with a few drawbacks and some trade-offs including:

Performance issues

While cross-platform frameworks work on providing apps that are as close to native apps as possible, they still don’t integrate seamlessly with the respective platforms and have inconsistent communication between the native and non-native components, reducing the  app’s speed and degrading performance.

Inconsistency with platforms

Cross-platform development tools don’t have all the features offered by each different platform, so you might need to employ some workarounds. It may also take these frameworks some time to get up-to-date with the newest features and updates released by the platforms.

Limited features

There are many native-only features and integrations available in each platform that are not available in cross-platform apps, which limits the user experience you can provide.

Cross-platform mobile app development tools

There are many cross-platform mobile app development tools and frameworks available, including:

• Flutter
• React Native
• Xamarin
• PhoneGap
• NativeScript
• Titanium
• Ionic
• Sencha
• Monocross
• Unity

We will take a closer look at the first and arguably most popular three frameworks available right now: Flutter, React Native, and Xamarin.

Flutter

Flutter is an open-source, cross-platform mobile application development framework created by Google in 2017. It’s the newest framework of the three and in short order has become one of the most popular frameworks among front-end devs.

Flutter advantages

Some of the reasons Flutter is currently one of the most loved cross-platform frameworks include:

• Complete development ecosystem: Flutter offers APIs, pre-built widgets, CLI tools, and pretty much all the tools needed for cross-platform mobile app development.
• Customizable: While it offers an extensive library of pre-built widgets, you can also create your own or customize pre-existing ones.
• Reliability: Developed and supported by Google
• Hot reload: Allows developers to fix bugs faster through faster code implementation
• Free: Open-source platform

Flutter disadvantages

Flutter poses a few challenges, especially being a new framework, including:

• Large app size: Flutter apps can be quite large compared to other frameworks that can force developers to reduce the number of libraries and packages used, compress images, and even steer away from using animation altogether in favor of reducing their app’s size.
• Native APIs: Flutter doesn’t expose many native APIs for you to use. That’s why, for many purposes, you will need third-party packages. Which also means that you will have to depend on the ecosystem.

However, you can always write your own native code that accesses the needed feature, and Flutter will give you a bridge to use that feature from within your Dart code.

Apps built using Flutter

• Google AdWords
• Google Greentea
• Alibaba
• AppTree
• Reflectly
• Hookle
• Topline
• Birch Finance
• OfflinePal
• Hamilton (musical)
• BetaBubs

Flutter development tools

• Flutter development language
• Dart
• Flutter IDEs:
  • Android Studio
  • IntelliJ IDEA
  • Visual Studio Code
• Flutter tools:
  • Flutter SDK
  • DevTools
  • Hot reload
• Flutter packages:
  • Dart Packages

React Native

React Native is an open-source, cross-platform mobile app development framework created by Facebook in 2015.

It enables users to use JavaScript and React along with native platform capabilities to build mobile apps.

React Native advantages

Some of the pros of React Native include:

• User Interface: Implements native UI components, allowing apps to look like native apps, and therefore providing a high-quality user interface.
• Ready-made components: Offers a vast library of UI components, allowing for faster development time.
• Access to native functionalities: Like camera, accelerometer, etc.
• Platform-specific code: Allows you to further optimize your separate native apps by using native code.
• Hot reload: Allows developers to apply changes to the apps right away without having to recompile the apps.
• Reliability: Developed and supported by Facebook.
• Free: Open-source platform.

React Native disadvantages

Unfortunately, React Native still has its pitfalls, including:

• Navigation: Navigation built in React Native is not seamless and not comparable to native navigation.
• Complex UI: React Native struggles with building complex animation and transitions.

React Native development tools

• React Native development language
• JavaScript
• React Native IDEs:
  • Atom
  • Nuclide
  • Visual Studio Code
  • React Native Tools
• React Native tools:
  • Expo
  • Redux
  • Ignite
  • Flow
  • Reduxsauce
  • ESLint
  • React Navigation
• React Native UI components:
  • NativeBase
  • Snowflake
• React Native testing tools:
  • Enzyme
  • Reactotron

Apps built using React Native

• Facebook
• Facebook Analytics
• Facebook Ads Manager
• Instagram
• Uber Eats
• Tesla
• Skype
• Pinterest
• SoundCloud Pulse
• Walmart
• Bloomberg
• Discord
• Myntra
• Gyroscope
• Chop
• Vogue
• Artsy
• F8

Xamarin

Xamarin is an open-source, cross-platform mobile app development framework that was founded in 2011, making it the oldest of the three.

Xamarin advantages

Xamarin cross-platform mobile app development pros include:

• Performance: Xamarin apps are known for having almost native-like performance levels.
• Complete development ecosystem: C#, .Net, and Microsoft Visual Studio with Xamarin are all you need to build mobile apps with Xamarin, making it one of the most complete cross-platform mobile app development frameworks out there.
• Seamless user experience: Xamarin.Forms allows you to take advantage of standard interface elements by providing a library of templates so that you can reuse your code across different platforms. You can also use Xamarin.iOS and Xamarin.Android for manual customization, if needed.
• Free: For small teams.

Xamarin disadvantages

However, as any cross-platform development framework, Xamarin does have its setbacks, including:

• Updates delay: Whenever new platform features or updates roll out, there is usually a delay until these changes are reflected in the Xamarin tools, which may cause issues with your app.
• Large app size: Xamarin apps can add around 5 megabytes for releases and 20 megabytes for debug builds, making them larger than native apps. This is primarily due to the libraries used to translate C# calls into native calls.
• Heavy graphics: Xamarin is great for apps with a simple UI. However, building complex applications or mobile games with Xamarin might not be the best thing to do as you will have to spend a lot of time writing platform-specific code, which defeats the purpose of using it.
• Platform-specific code: You might need to re-write some parts of the UI in your app in native code. That means that you will need some knowledge in native programming languages such as Kotlin or Java for Android, and Swift or Objective-C for iOS.

Xamarin development tools

• Xamarin development language
• C#
• Xamarin IDEs:
  • Visual Studio
  • XCode
• Xamarin tools:
  • NuGet
  • Xamarin Inspector
  • Prism
  • MFractor
  • Resharper
• Xamarin testing tools:
  • NUnit
  • xUnit.net
  • Visual Studio Unit Testing Framework

Apps built using Xamarin

• Skulls of the Shogun
• SuperGiant Games
• Storyo
• Insightly
• FreshDirect
• The World Bank
• Just Giving
• Olo
• Thermo Fisher Scientific
• APX

Flutter, React Native, or Xamarin?

Now let’s look at how these cross-platform development tools compare to each other.

Performance

One of the most important factors you should consider when choosing a cross-platform development framework is app performance.

While React Native and Xamarin provide near-native app performances, some argue that Flutter’s performance is better because Dart code is compiled to a C-library, which means it’s close to the native code.

This improves communication speed and provides better performance.

However, it’s hard to benchmark performance as it depends on many factors and variables including device, code, app, and features being used.

Popularity

With over 1.6 million developers across 120 countries, Xamarin has definitely developed quite the userbase over the years. However, this is largely due to the fact that it is one of the oldest frameworks out there.

Since its release, React Native has slowly but surely gained popularity, surpassing Xamarin in 2017.

According to the Stack Overflow Developer Survey 2019, Flutter ranked as the most loved framework out of the three, with 75.4 percent of users expressing interest in continuing to develop with Flutter.

React Native came in second with 62.5 percent, followed by Xamarin with only 48.3 percent.

Development languages

The cross-platform tool development language is another crucial factor to consider when making your decision.

Xamarin uses .Net languages like C# and F#, which are common languages and can be used to write native platform code.

While React Native uses JavaScript, which was not invented for it, it still does a great job with React Native apps.

You might encounter a few issues or come across some required workarounds as JavaScript was originally developed for the web.

As a result, some APIs might not work, while others may have to be proxied by React Native.

Flutter uses Dart, which was also not invented for mobile apps. However, it is managed by Google, the same company that created Flutter.

That’s why they make sure to adapt Dart for Flutter and mobile app development, making it better in many ways than JavaScript or C# with fewer workarounds needed.

According to the TIOBE Programming Community Index, C# is the fifth most popular programming language worldwide as of October 2019, followed by JavaScript in seventh place.

While still relatively new, Dart is ranked as the 26th most popular programming language in the world.

This gives an advantage to React Native and Xamarin, which both work with a familiar language that can help boost your productivity and save you from enduring a steep learning curve.

Components

React Native offers some pre-built and partly adaptive components like buttons and text inputs.

However, most of these components aren’t really adaptive. If you need something a bit more advanced, you would have to build it yourself by recomposing these built-in components.

Flutter provides a more extensive library of components, which are called widgets. However, these pre-built components are non-adaptive.

The language offers widgets for both iOS and Android, but you have to switch between both manually as it doesn’t have components that automatically adjust their styles depending on the platform you’re running.

Xamarin.Forms offers a complete cross-platform UI toolkit consisting of native UI components for both platforms, which are compiled into platform-specific UI components.

You can also use Xamarin.iOS or Xamarin.Android for custom app UI and better performance.

Code reuse

Code reuse is what brings developers to cross-platform frameworks, so how much of the code written with each framework is actually reusable?

React Native allows you to write the code once and ship anywhere, but it also embraces platform differences.

This means that from time to time, you have to find out on which platform you’re running and load a different component or set of components depending on the platform you’re running.

Still, a considerable part of the codebase can still be reused.

Flutter’s codebase is more reusable as it allows you to define one UI widget tree and reuse the defined logic so you don’t have to do a lot of differentiation, which you can also still do if you need to.

Xamarin prides itself on allowing developers to reuse up to 96 percent of their C# code by leveraging the language.

Xamarin also offers forms components, making it better for code reuse than React Native and Flutter which share an average of 60–90 percent of codes.

Pricing

While all three tools are free, open-source platforms, Xamarin is only free for individuals and small companies.

For large enterprises, single-user licenses start at $499 and go anywhere up to $2,999 for a Visual Studio Enterprise annual subscription.

While this might not be a problem for large enterprises, the costs can still add up, which could cause bigger companies to go with React Native or Flutter.

Support and ecosystem

When choosing a framework, you should also consider its community support, especially if you’re new to it. This includes forums, documentation, tutorials, etc.

React Native has a pretty good amount of support out there. You can easily find a lot of learning material as well or developers on forums or QA sites like Stack Overflow to ask for support whenever you need any help.

Flutter is still relatively new, so it is yet to build a strong community like React Native. However, Google is investing heavily in it, and therefore it is expected to grow into a robust ecosystem in the future.

For Xamarin, support is quite limited. However, Microsoft provides some free Xamarin courses and learning paths to help you get started.

Conclusion

When choosing a cross-platform development tool, there is no one-size-fits-all option.

All three frameworks have proven successful in building great mobile apps. Your specific needs and preferences determine which framework is best for you.

Currently, Flutter seems to be the most popular option as it excels in terms of performance. So if you’re new to the world of cross-platform development, Flutter might be the way to go for you.

However, you can’t rule React Native and Xamarin out just yet as they still excel in other areas.

For example, if you already have some prior knowledge of JavaScript, then it might be wise to go with React Native.

At the end of the day, it all depends on what you’re building and what you hope to achieve. Any framework will have its pitfalls, but the one where the advantages heavily outweigh those setbacks would probably be the right choice for you.