The document outlines essential software engineering principles, emphasizing problem-solving through planning and implementation, as well as the importance of simplicity and learning from mistakes. It introduces the S.O.L.I.D principles which guide the design of maintainable software by ensuring classes have a single responsibility and can be extended without modification. Additionally, it covers best practices for naming conventions to enhance code readability and maintainability.

1. Basic Software
Engineering
Principles
By Lahiru Wijewardana

2. What is Software Engineering?

3. How Engineer solves a problem
● Understand the requirement
● Plan a solution
● Carry out that plan
● Examine your results for accuracy
Solve problems fully BEFORE diving into the
implementation of your solution

4. Principles and Best Practices of Engineering
BEFORE you plan the solution….
1. Think through the problem completely
2. Divide and conquer
3. KISS (Keep It Simple, Stupid!)
4. Learn, especially from your mistakes
5. Remember the reason the software exists
6. Remember that YOU won't be using the software

5. Thinking About the Process
1. Have a clear vision for the project
2. Have a rigorous process
3. Develop applications rapidly
4. Make it WORK first, then work RIGHT, THEN look
pretty

6. Thinking About (Coding) the Solution
1. YAGNI (You Ain't Gonna Need It!)
2. DRY (Don't Repeat Yourself)
3. Embrace abstraction
4. DRITW (Don't Reinvent The Wheel)
5. Write code that does one thing well
6. Debugging is harder than writing code
7. Kaizen (leave it better than when you found it)

7. Rules of Thumb
● Finding and fixing a software problem in production is
100 times more expensive than finding and fixing it
during the requirements and design phase.
● In the same token, more than half of errors in design
are committed during the design phase.
● Just about all the time spent fixing issues can be traced
back to just a small handful of trouble modules.
● About half of user programs contain non trivial defects
● Only 60% of features in a system are actually used in
production

8. S.O.L.I.D Principles

9. What is S.O.L.I.D?
● [S]ingle Responsibility Principle
● [O]pen/Closed Principle
● [L]iskov Substitution Principle
● [I]nterface Segregation Principle
● [D]ependency Inversion Principle

10. Single Responsibility Principle
“A class should have one, and only one, reason to change”

11. Open/Closed Principle
“You should be able to extend a classes behavior, without
modifying it”
In other words: Software entities (classes, modules,
functions, etc.) must be opened for an extension, but
closed for modification

12. Liskov Substitution Principle
“Derived classes must be substitutable for their base
classes”

13. Interface Segregation Principle
“Make fine grained interfaces that are client specific”
In other words: Many specific interfaces are better
than a general interface

14. Dependency Inversion Principle
“Depend on abstractions, not on concretions”
Definition of this principle into two sub-items:
● 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.

15. Naming Conventions

16. Why Naming Conventions?
To maintain,
● Readability
● Understandability
● Maintainability
Each organization has its own syntax specific standards

17. Mobisec Best Practices
● Variable naming
● Function Naming
● Programming Standards

18. Variable naming
● Variable names should be meaningful and pronounceable.
For example appcnt Vs appCounter.
● Specific words should not be used like equals, compare, data.
● Don't use same variable for different purposes in a method.
● Don't use _ to declare a variable name, Use camel casing. For
example, employeeName is better than employee_name

19. Function naming
● Function names should be meaningful and pronounceable.
● Avoid pointless function names. For example myFunc(),
procedure().
● Don’t say one thing and do another.
● Function names should have a verb.

20. Programming Standards
● Use Camel Case (aka Upper Camel Case) for classes:
VelocityResponseWriter
● Use Lower Case for packages: com.company.project.ui
● Use Mixed Case (aka Lower Camel Case) for variables:
studentName
● Use Upper Case for constants : MAX_PARAMETER_COUNT = 100
● Use Camel Case for enum class names and Upper Case for enum
values.
● Don't use '_' anywhere except constants and enum values (which are
constants).

21. Questions….?

22. Reference
● https://www.vikingcodeschool.com/software-engineering-basics/basic-
principles-of-software-engineering
● https://mari-azevedo.medium.com/s-o-l-i-d-principles-what-are-they-and-
why-projects-should-use-them-50b85e4aa8b6
● https://itnext.io/solid-principles-explanation-and-examples-715b975dcad4
● https://dev.to/danialmalik/a-beginner-s-guide-to-clean-code-part1-naming-
conventions-139l
● https://medium.com/swlh/javascript-best-practices-variable-naming-
conventions-ea121ca389c5
● https://medium.com/wix-engineering/naming-convention-8-basic-rules-for-
any-piece-of-code-c4c5f65b0c09
● https://dzone.com/articles/best-practices-variable-and

23. Thank You…..