Group items tagged

"It's good habit to get back to basics and really understand why you hold principles so that you can judge whether or not they are appropriate in the circumstances you are in. Today's little nugget of principle is to write expressive code and avoid magic values in your code."

"This course introduces foundational principles of creating well-crafted code and is appropriate for anyone hoping to improve as a developer"

"If you were to look at a .Net project that I told you strictly followed SOLID principles, what would expect to see in terms of the project and code structure ?"

A series of six articles desribing each of the five SOLID principles used for dependency management in object-oriented design and programming. When followed, these principles can enhance the maintainability of software.

Perhaps interesting after today's meeting...

"I often hear people say something like "if you need it once, build it. If you need it twice, abstract it." People often say then in the context of the "DRY" - or Don't Repeat Yourself - principle. [..] The idea of DRY needs to be tempered with YAGNI - "You Aint Gonna Need It". With that, we end up with The Rule Of Three, and it clearly says that code can be copied once but the third time you need it, you should abstract it."

A great TED talk about applying Agile principle outside the workplace.

"No matter which source control system you decide to use, there are a number of universal principles that will help you to get the most out of source control."

Really, a few time management principles can do our life successful and improve software and web development to profitable and fascinating levels.

"While Scrum's primary goal is organization and project management, Lean is more about optimizing processes in order to quickly produce quality products. It can be your first step toward adopting Agile principles, or it may be something that your team evolves to, when Scrum isn't enough. I invite you to read my team's story, and how we evolved from Scrum to a more Lean-ish development process."

"Have you ever seen code that looked like the snippet here? [..] You probably have seen code like this, and I hope that it makes you sad. I know it makes me sad. It makes me sad because it's clearly the result of a fundamental failure to understand (or at least implement) polymorphism."

"Interfaces are wonderful for a language like C#. Interfaces give us everything we need to work with an object in a strongly-typed manner, but place the least number of constraints on the object implementing the interface. Interfaces make the C# compiler happy without forcing us to pay an inheritance tax for working with a class hierarchy. We'll define an interface that describes exactly how we want to fetch customers and how we want the customers packaged for us to consume."

"Let's look at this implementation through the lens of the Rule of Modularity. The above code fails the "simple parts, clean interfaces" sniff test."

"This is going to be the first post in a new series that I'm doing on design patterns. [..] So, my idea here is to relate the design patterns in the context of a story rather than a stuffy-sounding taxonomy. Why do people do this? What problem does it solve? Why is my code potentially worse if I don't do this?"

"I'm getting really tired of all blog posts that states that service locator is an anti pattern. It's not."

"Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right? No, it's actually an anti-pattern and should be avoided."

"Recommendation: Go for the lightweight Factory Delegate approach. As with all patterns, use with caution and watch for overuse & abuse. In particular, if you need to manage state between multiple delegate, fall back to the overriding approach, because you can keep the state in the subclass."