First , lets see where are we ?
Lets stop arguing what is the best practice and focus on moving forward . if what we are not moving forward everyday , we will be lost in some day.
Second , gap ? we need alignment !
Where is the next stop ? and how does it comes up ?it comes up from a lunch time discussion ? or it is coming after a details planing ? Lets stop for a moment and think about it .
Everyone have a voice on a solution ? who will be the one make decision.
In a start up , this is happening quite often. again , the important thing is not who is right or wrong , or even best . lets apply one by one and try it again and again and again!
Coding style ? yes , we need it . but not about any one , about team .
This is about every team . everyone may has a different opinion on the codes they are writing . but , what is more important ?
testable ?readability ? maintenance ? performance ? or extensible ?
– you jumped into a project in the middle , just follow the coding convention the team is coding . (DON’T)you will do a interface for anything you dislike ?
– you are starting a new project . remember:
— spending too much time on design but forgot prototype
— over engineering .thinking too much on which technology to use to do the job (get it done first!)
— take into everything into account ? forget about it ! now create a project and put some code get it work .moving forward!
— coding or patterns or practice is really depends on the team skill set , after everyone agree on the (not so bad) naming convention, just start. any part you dislike such as moving method into new class , a visitor or command pattern, just do refactoring job on your own. but don’t expect others will do same as you did .
— but like DI , stairway pattern , or layers or micro-service , should be clarify in the first time.
We have to rush on a ticket? This is the steps i will think of
1. finish the feature ,if possible , write unit test after each single step.
2. go through the logic and add comment where necessary .
3. got time to refactor ?
— clean up dependency by DI
— analysis where need to have an interface .
— behavior and data keep separate .
— inheritance ? careful . in real world , inheritance is natural .but in programming , inheritance usually come to picture after composition.
Attitude , yes, most important come last
you are software engineer , not a potter or pantry auntie ! so you have to get things done right ! be responsible what we write. no time is not an excuse , keep in mind : Unit Test during development , system monitoring during maintenance ! find and use new tools to automation the job ! again , you are programmer ! (not a coding monkey)
watch team steps , what is stopping us from moving forward, point it out!
watch yourself , don’t be the one dragging team behind