Freigeben über

Slashdot on Framework Design

  • Artikel

Very cool to see Slashdot address framework design, although I am a bit disappointed they didn't reference the Framework Design Guidelines as it covers all of these areas. I do basically agree with the primary point of the post...

Our presumption is that software developers mostly evaluate following software framework characteristics based on:

  1. perceived ease of use (e.g. easy to learn, easy to adapt)
  2. perceived usability (e.g. improving developer performances, reducing work, faster development),
  3. perceived sustainability (e.g. perceived long term support, supporting standards, clear project directions) and
  4. perceived fit to specific developer requirements (e.g. suited language, suited functions, suited architecture).

And it is interesting that this not only goes to base frameworks (Java, .NET Framework, etc) but also to the frameworks you design for your own internal usage. Are they easy learn, usable, sustainable and appropriate for the audience?

Are there any other characteristics that you use to chose a framework?

Comments

  • Anonymous
    February 25, 2006
    I found that it is very interesting that all points have word 'perceived'. Make me think that even though the developers 'knows better', 'the better way to do stuff' may not be a good framework from the target users POV.
  • Anonymous
    February 25, 2006
    Joel rocks:

    http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
  • Anonymous
    February 25, 2006
    Do you want to build a widely used framework/library?Consider the test for a consumer electronic product. Can the average consumer pick it up, press buttons, and accomplish his/her tasks, without having to read the manual or documentation? The same test applies to software libraries.

    The average developer doesn't have time to read your documentation, nor does he/she have time to be "educated". If you are spending lots of effort on educating developers, your product is a failure. A far better investment of your time is to actually listen to the developers (something Microsoft does poorly) and fix the product to work the way the developer expects it to work.

    Can you read code using your library/framework without any prior knowledge of that framework? Do the methods, objects, and properties pass the "sentence" test -- can the names of these be used seamlessly in sentences? Is your documentation a nest of abstractions that lead to dead ends (eg, Avalon)?
  • Anonymous
    February 25, 2006
    Over all else, CONSISTENCY!  I just got a reply last week from someone on the WPF team on why, with all the guidelines about boolean props being IsX, FrameworkElement has Focusable rather than IsFocusable, and the answer was "because it's late in the game, so we don't want to break people's code in the next CTP(!), and it's more trouble than it's worth."  Well, guess what?  For the next 10 years, the core graphics API will be inconsistent with MS' own API standards because no one's gonna make it consistent during a friggin' beta!  I would much rather have to do a global search & replace (isnt' that what the glacially-paced refactoring tool is for?!?!?!) now than have to write to an unpredictable API.
    The other one: minimal surface area, meaning overrides only when the parameters are truly different...no using them for default parameters.
  • Anonymous
    February 28, 2006
    One thing I don't see mentioned here:  Take from other frameworks.

    Following the guidelines of other peoples guidelines, especially the core framework that you're using (for example .NET), will allow you to create a framework that is intuitive to a programmer thats never seen your product before.

    Don't invent your own standards, but rather use the ones already provided!
  • Anonymous
    April 08, 2006
    Hi
    To write the letter, it is necessary ...