Being a developer
Developer’s job is not only about
developing the code
Disclaimer: THESE ARE PRINCIPLES,
NOT LAWS!
§ You need to follow the rules,
whether they are
§ You should ask the questions –
especially in case of doubts
§ You should learn new things: all the
time, always and from others
§ ... till end (of time)
§ It would be great to have a leader:
§ to learn from
§ to follow
§ You are the team player
§ You work with legacy systems
2
Typical project setup

There is no one! § Tools:

§ IDE – Xcode, Visual Studio, IntelliJ, ...
Each single project has its own setup! § Repository: Git, SVN, ...
§ CI environment: Azure DevOps,
§ Waterfall, Agile, ... Jenkins, Bamboo, CircleCI, …
§ How project is run: § Scripts: JavaScript, Python, MsBuild,
PowerShell, Bash/Zsh, Make, …
§ Scrum § Supporting tools: Lint, R#, StyleCop, …
§ Kanban § Review Tool
§ Programin Mother*ker
§ Project board, back trucking: JIRA
§ Developing the code § Code guide
§ Code first
§ Definition of Done / Definition of
§ TDD Ready
§ Who needs unit tests / We don’t test § Build in one step & daily builds
our code J

3
Definition of Done / Definition of Ready
DoD / DoR is our contract!
§ DoD / DoR says about the rules you
need to follow during daily work
§ Each developer in team need to
follow DoD – no exceptions!
§ Each team member need to follow
DoR – no exceptions!
§ Each single project has its own DoD /
DoR
§ Sample DoD:
§ All unit tests passed
§ All integration tests passed
§ No warnings in code (also warnings from Lint /
StyleCop)
§ Code coverage over 91%
§ Max cyclomatic complexity below 12
§ Build passed on CI server
§ Sample DoR:
§ Functionality working (all AC’s met)
§ Unit test written
§ Code approved by 2 other developers
§ QA accepted
§ Functionality available on CI staging environment
§ Documentation updated
4
Code smells
If it stinks, change it! § High quality code is:
§ Duplicated Code § Easy to read and understand
§ Long Method § Impossible to hide bugs
§ Large Class § Easy to extend
§ Long Parameter List / too many of § Easy to change
them § Has unit tests
§ Switch Statement
§ Temporary Field § Always code as if the guy who ends
§ Magic numbers up maintaining your code will be a
§ Naming violent psychopath who knows
§ Complex Conditionals where you live.
§ Dead code
5
This is not OOP!

public class Record_Base

{
public DateTime RecordDateTime
{
get { return _recordDateTime; }
set
{
if (this.GetType().Name == "Record_PartRegister") _recordDateTime = value;
else
throw new Exception("Cannot call set on RecordDateTime for table " + this.GetType().Name);
}
}
}
http://thedailywtf.com/Articles/Making-Off-With-Your-Inheritance.aspx
STUPID code

What Makes Code § Singleton

STUPID Programs using global state are very difficult to test. Programs that rely
on global state hide their dependencies.
Why Singletons Are Controversial?
Why is Singleton considered an anti pattern?
§ Singleton So Singletons are bad, then what?
§ Tight Coupling § Tight Coupling
§ Untestability If changing one module in a program requires changing another module,
§ Premature Optimization then coupling exists.
Reducing Coupling (Martin Fowler)
§ Indescriptive Naming
§ Duplication § Untestability
Testing should not be hard!
Whenever you don't write unit tests because you don't have time, the real
issue is that your code is bad.

7
STUPID code

What Makes Code § Premature Optimization

STUPID Optimizing before we know that we need to.
There is only cost and no benefit.
PrematureOptimization Anti-Pattern
§ Indescriptive Naming
§ Singleton
Name your classes, methods, attributes, and variables properly.
§ Tight Coupling Don't abbreviate, never!
§ Untestability
§ Duplication
§ Premature Optimization Don't Repeat Yourself!
§ Indescriptive Naming Keep It Simple, Stupid!
§ Duplication

8
KISS my DRY and SOLID code

Simple rules for § SOLID principles:

developers – how to § Single Responsibility
Every object should have a single responsibility, and that responsibility
write the code should be entirely encapsulated by the class.
§ Open / Closed principle
§ Keep It Simple - Software entities (classes, modules, functions, etc.) should be open for
extension, but closed for modification.
Stupid
§ Liskov Substitution
§ Don’t Repeat Yorself Objects in a program should be replaceable with instances of their
subtypes without altering the correctness of that program.
§ You Aren’t Gonna
§ Interface Segragation
Need It? Clients should not be forced to depend on methods they do not use.
§ Uncle Bob Clean § Dependency Inversion
Code(r) Abstractions should not depend on details. Details should depend on
abstractions.

9
Code reviews

Everybody reviews and everybody is § Rules:

reviewed. § Syntax !
§ Code Style – be project StyleCop
§ Can catch up to 60% of defects (naming)
§ Simplicity
§ Effective code reviews are:
§ Short – don’t waste time
§ DRY violations
§ Constructive § SOLID violations
§ Avoid emotionally draining arguments § Security – buffers, stack overflow, input
§ Code review rules depend on project dfata sanity (trust no one), cross
boarders (SQL injection, XSS)
you’re working on - samples:
§ Memory leaks
§ Banking system - SOLID, security
§ NASA § Optimization - code efficiency
§ Games - optimization , code efficiency, don’t § Strings !
care about exceptions
§ Mobile application – SOLID, but efficiency

10
Why should I refactor?

Refactoring is our way of paying off our § How Should I Refactor:

“Technical Debt”
§ Technical what?! - is a metaphor:
§ doing things the quick and dirty way sets us up
with a technical debt, which is similar to a
financial debt
§ incurs interest payments, which come in the form
of the extra effort that we have to do in future
development.
§ Ask yourself the following questions:
§ Is my code readable?
§ Is my code abstract?
§ Anything more is rearranging the deck chairs
on the Titanic:
§ It gives you a sense of doing something
§ But ultimately it’s pointless L

§ Refactoring is changing the structure, but not the § Follow the rules:
functionality of your application. § KISS / DRY / SOLID
§ Clean code
§ Code review rules!

11
Resources
• Refactoring catalogs:
http://www.refactoring.com/catalog/index.html