danielmarbach

View on GitHub

Projects

This user doesn't have any project on FeatHub yet.

Features suggested

Project Feature Score Description
ardalis/CraftsmanshipCalendarIdeas Overpragmatism 1 Ignoring the non functional requirements We will solve that later syndrom Important aspects haven’t been considered in the design Cannot cleanly integrated into existing solution and is just hacked into it Counter part to http://feathub.com/ardalis/CraftsmanshipCalendarIdeas/+25 From my presentation Legacy Code. Now what?
ardalis/CraftsmanshipCalendarIdeas Overengineering 5 (needless complexity) Too many abstractions Solves more than needed Causes undesired ripple effects because of the unneccessary bagage it carries Overconfigurable Overgeneralised Counter part to http://feathub.com/ardalis/CraftsmanshipCalendarIdeas/+26 from my presention Legacy Code. What now?
ardalis/CraftsmanshipCalendarIdeas Shortcuts 1 Sometimes for people taking short cuts is easier than do it right from the start the problem is that introduced new concept is not following the existing concepts and therefore not maintainable Usually uses existing code which works but doesn’t fit the scenario You hear: But it’s only an if And you end up with everything knows everything architecture From my presentation Legacy Code. Now what?
ardalis/CraftsmanshipCalendarIdeas Diversity / Concept duplication 0 For example I have seen project where XML generation and parsing was done in 4-5 different ways and it was never aligned. Also cross-cutting concerns not treated as such etc.
ardalis/CraftsmanshipCalendarIdeas Heroes 2 Instead of doing a proper root cause analysis people stay until late, do production deployment at a high risk, work over weekends and somehow fix it and are very proud that they solved it (I'm a hero!). Make a step back, talk to your customer and make it properly work
ardalis/CraftsmanshipCalendarIdeas Iceberg effect 0 Only a small part of the problem is visible on the surface, the rest sleeps under the surface Simple changes introduce failures in other locations (fragility)
ardalis/CraftsmanshipCalendarIdeas The new guy fixes the documentation anyway! 2 Missing or worse: Wrong documentation and the attitude that "We all know how it works and the new guy can fix the doco"
ardalis/CraftsmanshipCalendarIdeas Poor technology choice 0 Using a technology for a task which it wasn't built for (example data replication over queuing)
ardalis/CraftsmanshipCalendarIdeas Let's name it FooBar because it is so expressive! 1 Deceptive naming Same same but different name Useless over overused terms like handler, name, server and service Difficult to understand or no information present in the variable/method name
ardalis/CraftsmanshipCalendarIdeas Let's name it FooBar because it is so expressive! 1 Deceptive naming Same same but different name Useless over overused terms like handler, name, server and service Difficult to understand or no information present in the variable/method name
ardalis/CraftsmanshipCalendarIdeas Broken Window Effect 7 Build is red. Yeah that's again some flaky test. You can ignore it. Boom. Nobody cares about the build anymore.
ardalis/CraftsmanshipCalendarIdeas Let's diff and blame my workmates 0 It is so easy to blame others. Do a diff and blame and you know who made the mistake. I've seen companies where people who made mistakes were blamed. Mistakes can happen. If you see a mistake in the code just fix it, use the source control blame feature only to find out who do you need to "educate" that the next time such mistakes don't happen again. Always remember: you make mistakes too
ardalis/CraftsmanshipCalendarIdeas Number of WTFs per Minute 9 An interesting metric to measure software quality ;)
ardalis/CraftsmanshipCalendarIdeas That piece of crap! Let's rewrite the whole thing! 1 Big Bang almost never works.
ardalis/CraftsmanshipCalendarIdeas Layers, layer, layers... 2 Your code should do first what matters most: The business/domain logic. More background you'll find here http://www.methodsandtools.com/archive/onionsoftwarearchitecture.php
ardalis/CraftsmanshipCalendarIdeas Take a step back 0 It is so easy to get lost in the details. Take a step back to see the big picture and never loose it. Same applies for bugs. Do a proper root cause analysis and fix it.
ardalis/CraftsmanshipCalendarIdeas Flat hierarchies for president 0 In an OO world favour flat hierarchies over complex and deep aggregation chains.
ardalis/CraftsmanshipCalendarIdeas Demilitarized Zone 0 Especially for legacy code. Make your safe zones where the new patterns apply. Try to push the evil integration stuff in the outer zones
ardalis/CraftsmanshipCalendarIdeas Common architecture vision 1 I think it is important that a team has a common architecture vision and everybody works towards that vision. I
ardalis/CraftsmanshipCalendarIdeas Favour value objects over dump parameters 1 public string GetPath(); -> public AbsoluteFilePath GetPath(); public Data LoadBy(string id) -> LoadBy(DataId id) Validation can be done in the value object. You get strong typing...
ardalis/CraftsmanshipCalendarIdeas Don't assume. Measure! 7 I always hear: Yeah if we do XYZ it is X times faster than Y. Don't assume. Measure it and most importantly with real workload
ardalis/CraftsmanshipCalendarIdeas Do stuff or know others, but not both 1 Classes should either do stuff (algorithm, read data, write data, …) or orchestrate other classes. This reduces coupling and simplifies testing
ardalis/CraftsmanshipCalendarIdeas Change is local 0 When a software system has to be maintained, extended and changed for a long time, keeping change local reduces involved costs and risks. Keeping change local means that there are boundaries in the design which changes do not cross.
ardalis/CraftsmanshipCalendarIdeas It is easy to remove 0 We normally build software by adding, extending or changing features. However, removing elements is important so that the overall design can be kept as simple as possible. When a block gets too complicated, it has to be removed and replaced with one or more simpler blocks.
ardalis/CraftsmanshipCalendarIdeas Mind-sized components 0 Break your system down into components that are of a size you can grasp within your mind so that you can predict consequences of changes easily (dependencies, control flow, …).
ardalis/CraftsmanshipCalendarIdeas Feature envy 1 The methods of a class should be interested in the variables and functions of the class they belong to, and not the variables and functions of other classes. Using accessors and mutators of some other object to manipulate its data, is envying the scope of the other object.

Comments

This user hasn't voted yet.

Votes

Vote When Project Feature
about 4 years ago ardalis/CraftsmanshipCalendarIdeas Let's name it FooBar because it is so expressive!