Developer Job in Practice
1 like849 views
The document provides guidance for developers on best practices for writing code. It emphasizes following rules like clean code, code reviews, and refactoring. Key points include writing simple and readable code, avoiding duplication, learning from others, and ensuring code meets definitions of done that specify requirements like testing and code quality. Refactoring is advised to reduce technical debt by improving structure without changing functionality. Code reviews are recommended to catch defects through constructive peer review.
![public
class
Record_Base
{
public
DateTime
RecordDateTime
{
get
{
return
_recordDateTime;
}
set
{
if
(this.GetType().Name
==
"Record_PartRegister")
_recordDateTime
=
value;
else
throw
new
ExcepQon("Cannot
call
set
on
RecordDateTime
for
table
"
+
this.GetType().Name);
}
}
}
hp://thedailyw].com/ArQcles/Making-‐Off-‐With-‐Your-‐Inheritance.aspx
This is not OOP!](https://image.slidesharecdn.com/devjobinpractice-150424074422-conversion-gate02/85/Developer-Job-in-Practice-6-320.jpg)
Developer Job in Practice
- 1. Developer Job in Practice Clean code rules • Code review • Refactoring Kamil Kowalski [email protected]
- 2. 2 Being a developer ! You need to follow the rules, wheter they are ! You should ask the questions – especially in case of doubts ! You should learn new things: all the time, always and also from others ! ... till end (of time) Developer’s job is not only about developing the code ! It would be great to have a leader: ! to learn from ! to follow ! You are the team player ! You work with legacy systems
- 3. 3 Typical project setup ! Waterfall, Agile, ... ! How project is run: ! Scrum ! Kanban ! Programin Mother*ker ! Developing the code ! Code first ! TDD ! „Who needs unit tests” / „We don’t test our code” ☺ There is no one! Each single project has its own setup! ! Tools: ! IDE – Xcode, VS, IntelliJ, ... ! Repository: SVN, Git, ... ! CI environment: Hudson, Jenkins, CC.NET,... ! Scripts: Python, MsBuild, ANT, NANT, ... ! SupporQng tools: R#, StyleCop ! Review Tool ! Project board, back trucking: JIRA ! Code guide ! DefiniQon of Done / DefiniQon of Ready ! Build in one step & daily builds
- 4. 4 Definition of Done / Definition of Ready ! 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 DoD / DoR is our contract! ! Sample DoD: ! All unit tests passed ! All integration tests passed ! No warnings in code (also warnings from 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
- 5. 5 Code smells ! Duplicated Code ! Long Method ! Large Class ! Long Parameter List / too many of them ! Switch Statement ! Temporary Field ! Magic numbers ! Naming ! Complex Conditionals ! Dead code If it stinks, change it! ! High quality code is: ! Easy to read and understand ! Impossible to hide bugs ! Easy to extend ! Easy to change ! Has unit tests ! Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
- 6. public class Record_Base { public DateTime RecordDateTime { get { return _recordDateTime; } set { if (this.GetType().Name == "Record_PartRegister") _recordDateTime = value; else throw new ExcepQon("Cannot call set on RecordDateTime for table " + this.GetType().Name); } } } hp://thedailyw].com/ArQcles/Making-‐Off-‐With-‐Your-‐Inheritance.aspx This is not OOP!
- 7. KISS my DRY and SOLID code 7 Simple rules for developers – how to write the code ! Keep It Simple - Stupid ! Don’t Repeat Yorself ! Uncle Bob Clean Code(r) ! SOLID principles: ! Single Responsibility Every object should have a single responsibility, and that responsibility should be en7rely encapsulated by the class. ! Open / Closed principle So:ware en77es (classes, modules, func7ons, etc.) should be open for extension, but closed for modifica7on. ! Liskov SubsQtuQon Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. ! Interface SegragaQon Clients should not be forced to depend on methods they do not use. ! Dependency Inversion Abstrac7ons should not depend on details. Details should depend on abstrac7ons.
- 8. 8 Code reviews ! Can catch up to 60% of defects ! EffecQve code reviews are: ! Short – don’t waste Qme ! ConstrucQve ! Avoid emoQonally draining arguments ! Code review rules depend on project you’re working on -‐ samples: ! Banking system -‐ SOLID, security ! NASA ! Games -‐ opQmizaQon , code efficiency, don’t care about excepQons ! Mobile applicaQon – SOLID, but efficiency Everybody reviews and everybody is reviewed. ! Rules: ! Syntax ! ! Code Style – be project StyleCop (naming) ! Simplicity ! DRY violaQons ! SOLID violaQons ! Security – buffers, stack overflow, input dfata sanity (trust no one), cross boarders (SQL injecQon, XSS) ! Memory leaks ! OpQmizaQon -‐ code efficiency ! Strings !
- 9. 9 Why should I refactor? ! 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. ! Refactoring is changing the structure, but not the funcQonality of your applicaQon. Refactoring is our way of paying off our “Technical Debt” ! How Should I Refactor: ! Ask yourself the following quesQons: ! 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 ulQmately it’s pointless # ! Follow the rules: ! KISS / DRY / SOLID ! Clean code ! Code review rules!
- 10. • Refactoring catalogs: hp://www.refactoring.com/catalog/index.html • Refactoring (book) hp://www.amazon.co.uk/Refactoring-‐Improving-‐Design-‐ ExisQng-‐Technology/dp/0201485672/ref=sr_1_1? ie=UTF8&s=books&qid=1246371771&sr=8-‐1 Resources