Search Results

Search found 4 results on 1 pages for 'telastyn'.

Page 1/1 | 1 

• Should programmers prefer making wide libraries or thin libraries?

  - by Telastyn

  For classes and functions, it is clear cut: each should do only one thing. For libraries though, this is less clear. If you have a library with collections, it might have multiple collections. It might have useful functions like sorting, which aren't strictly collection based but users would expect. Each of these results in a 'wider' library. On the other side is having a library for the specific collection type and/or with little built-in functionality. If you want a queue, it gives you a queue. If you want to sort that list, then the library lets you do that yourself. What is the best practice here (if any)? I can see arguments for each side.

  Read the article

• How to explain why design choices are good?

  - by Telastyn

  As I've become a better developer, I find that much of my design skill comes more from intuition than mechanical analysis. This is great. It lets me read code and get a feel for it quicker. It lets me translate designs between languages and abstractions much easier. And it let's me get stuff done faster. The downside is that I find it harder to explain to teammates (and worse, management) why a particular design is advantageous; especially teammates that are behind the times on best practices. "This design is more testable!" or "You should favor composition over inheritance." go right over their heads, and lead into the rabbit hole of me trying to clue everyone in to the last decade of software engineering advances. I'll get better at it with practice of course, but in the mean time it involves a lot of wasted time and/or bad design (that will lead to wasted time fixing it later). How can I better explain why a certain design is superior, when the benefits aren't completely obvious to the audience?

  Read the article

• Branching strategy for parallel development that won't be in the same release?

  - by Telastyn

  My team is working on a product, which for business reasons needs to be released on a regular schedule. An issue has arisen where we want to do development in parallel for the upcoming release, as well as the 'next' release. This is to become standard practice, so it's not as straightforward as cutting a feature branch for the new work. We'll continually have 2+ teams working on different releases of the same product. Is there an SCM best practice for this sort of arrangement?

  Read the article

• If an entity is composed, is it still a god object?

  - by Telastyn

  I am working on a system to configure hardware. Unfortunately, there is tons of variety in the hardware, which means there's a wide variety of capabilities and configurations depending on what specific hardware the software connects to. To deal with this, we're using a Component Based Entity design where the "hardware" class itself is a very thin container for components that are composed at runtime based on what capabilities/configuration are available. This works great, and the design itself has worked well elsewhere (particularly in games). The problem is that all this software does is configure the hardware. As such, almost all of the code is a component of the hardware instance. While the consumer only ever works against the strongly typed interfaces for the components, it could be argued that the class that represents an instance of the hardware is a God Object. If you want to do anything to/with the hardware, you query an interface and work with it. So, even if the components of an object are modular and decoupled well, is their container a God Object and the downsides associated with the anti-pattern?

  Read the article

1