Catégorie : programming

SOLID Principles

Single Responsibility Principle – the methods and classes should focus on doing one thing and doing it well

Open Closed Principle – extend the classes instead of modifying them – Open for extension, closed for modification. Imagine you want to add a basement to your house. You don’t want to change the code that is already in production.

Liskvov Substitution Principle – Derived classes can stand in before base classes – Code against an interface.

Interface Segregation Principle – Make fined grained interfaces client specific –

Dependency Inversion – Depend on abstractions, not concrete implementations

 

Things any programmer should know #4

  • A good bug report must express three things:
    • how to reproduce the bug
    • what should have happened, in your opinion
    • what actually happened, with as much information as you can record
  • You can improve code by removing it. You Aren’t Gonna Need It.
  • Remove all you warnings or deal right away with a warning when it appears. You need to get rid of the noise.
  • Know your IDE but try working with command-line build tools, they can help look under the hood and understand what is going on.

 

Things any programmer should know #3

  • Understand as much as you can the project you work on
  • A common web-based development architecture:
    • local development and unit testing on the developer’s machine
    • development server where manual or automated integration testing is done
    • staging server where the QA team and the users do acceptance tests
    • production server
  • If something is broken, it should not be fixed on production.
  • There is no guru. There should be an expert willing to develop other experts.

Things any programmer should know #2

  • Don’t ignore an error!It will raise problems in the future.
  • Write comments only when the code doesn’t or can’t say something.
  • Technical exceptions will be handled by the application framework while the business domain exceptions by the client code.
  • Deploy often.
  • Challenge yourself by doing what you are not good at (deliberate practice).

Things any programmer should know #1

  1. Create shared library only when you know the context. Sometimes, while decreasing the number of line of code in the system the number of dependencies is increased.
  2. Care for the team’s code. Make it a little bit better than when you checked it out.
  3. Debug your own code before rushing to blame others.
  4. Choose the right mix of tools:
    1. avoid architectural mistmatch (some tools are good only in some specific contexts)
    2. avoid using too many
    3. should be easy to configure
    4. licensing terms matter
    5. start by using only the tools that are absolutely necessary

ASP.NET Core Authorization

Authentication – when you ask someone who they are and you get its identity.

Authorization – decide what identity is able to do.

You can authenticate but you don’t have to authorize.

You can authorize without having any authentication.

Two main HTTP codes in web security:

401 – Unauthorized – You are not authenticated

403 – Forbidden – You are authenticated but you don’t have access

ASP.NET Authorization workshop

 

 

Undoing a commit in git

When forgot something on a commit:

git reset –soft HEAD^ — move to the commit one before the HEAD.

undo the last commit and move everything from that commit back into staging.

git commit –amend -m « modify something and add it to the last commit »

git reset –hard HEAD^ -undo last commit and all changes

git reset –hard HEAD^^ – undo last two commits and all changes

 

 

 

Unstaging files in git

When staging files that I didn’t mean to stage:

(use git reset HEAD (file) … to unstage)

git reset HEAD filename

HEAD – the last commit on the current branch

The file has its modifications.

Reset the file to its last commit.

git checkout — filename

Risks when changing software

Some questions to answer to:

  1. What changes do i have to make?
  2. How will i know that i’ve done them correctly?
  3. How will i know that i haven’t broken anything?

You can’t minimize software problems by avoiding them. Avoiding changes will make people get rusty at it. Another consequence is fear.

The alternative of avoiding changes is to try harder.

Changing software

Requirements change. Designs that cannot tolerate changing requirements are bad designs.

There are four primary reasons to change software:

  • Adding a feature
  • Fixing a bug
  • Improving the design
  • Optimizing resource usage

There is a very big difference between adding a new feature and changing old behaviour. When adding behaviour we must NOT change or remove behaviour the users already depend on.

Improving the design without changing its behaviour is called refactoring.

Optimization is like refactoring but it has a different goal. Some resource used by the program, time or memory, is changed.

When working on a system we can change three different things:

  • structure
  • functionality
  • resource usage

The Legacy Code Change Algorithm

  1. Identify change points – the places where you need to make the changes
  2. Find test points
  3. Break dependencies – Depenencies are the bigges impediment to testing. Break them to get tests in place.
  4. Write tests
  5. Make changes and refactor