Skip to main content

Home/ SoftwareEngineering/ Group items tagged BestPractices

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Java API Design Checklist « The Amiable API - 0 views

theamiableapi.com/...java-api-design-checklist

java BestPractices ApiDesign

shared by kuni katsuya on 17 Nov 12 - No Cached
  • Java API Design Checklist
  • Do not use
  • marketing
  • ...18 more annotations...
  • project
  • organizational
  • names
  • Do not move or rename the package of an
  • already released public API
  • Begin with a short, one sentence summary of the API
  • Provide enough details
  • Include the API version number
  • Ensure each type has a single, well-defined purpose
  • Type Design Checklist
  • Ensure types represent domain concepts, not design abstractions
  • Follow consistent design patterns when designing related types
  • Favor enumeration types over constants
  • Consider generic types
  • Avoid deep inheritance hierarchies
  • Do not use public nested types
  • Do not declare public or protected fields
  • Do not expose implementation inheritance to the client
kuni katsuya

Temporary "junk" Packages Are A Best Practice : Adam Bien's Weblog - 0 views

www.adam-bien.com/...temporary_junk_packages_are_a

java package class naming BestPractices refactoring

shared by kuni katsuya on 19 Jan 13 - No Cached
  • Temporary "junk" Packages Are A Best Practice
  • In the first iterations class names and their packages are constantly refactored
  • a really bad sounding name like "waste", "junk" or "unrelated" does a better job by forcing you to refactor such a "kitchen sink" package with its contents in a later iteration
kuni katsuya

Preemptive commit comments | Arialdo Martini - 0 views

arialdomartini.wordpress.com/...pre-emptive-commit-comments

BDD BehaviorDrivenDevelopment CommitComment BestPractices SoftwareEngineering

shared by kuni katsuya on 15 Mar 13 - No Cached
  • Tell me what the software does
    • kuni katsuya
      kuni katsuya on 15 Mar 13
       
      tell me how the software should *behave*, not how the behavior was *implemented* ie. describe the changes in this commit from the behavioral perspective rather than implementation details
  • What is the project behavior, in this snapshot?
  • What did the programmers, in order to produce this snapshot?
  • ...43 more annotations...
  • committing comments describing the
  • behavior of the software,
  • rather than the
  • implementation or a description of what we did
  • commits’ comments started to look like BDD’s methods name: a description of a behavior.
  • principles
  • Talk about the feature, not about yourself
  • Don’t refer to the past
  • I know it’s now
  • list of benefits
  • More focus while developing
  • Commit review is much easier
  • Less cognitive load
  • You learn commenting much more precisely
  • commit comment becomes a
  • declaration of intent
  • like a BDD method name
  • No more “Just a fix“, “Improvements” or “I made this, this, this and also this” comments.
    • kuni katsuya
      kuni katsuya on 15 Mar 13
       
      BDD/TDD or any methodology aside, these are the worst commit comments as they are as useless as empty commit comments
  • Each preemptive comment triggers a micro design session
  • A preemptive comment sets a micro goal
    • kuni katsuya
      kuni katsuya on 15 Mar 13
       
      which also aligns well with the 'micro goal' or incremental deliverables approaches of most agile methodologies 
  • helps to focus a goal to be reached
  • Without preemptive comments, I often went on coding, always asking myself: “Should I commit now? Have I reached a stable state which I could consider a good commit?“
  • define micro-goals through preemptive comments
  • macro-goal through the feature branch name
  • A preemptive comment creates a little timebox
    • kuni katsuya
      kuni katsuya on 15 Mar 13
       
      similar to the timeboxing strategy of a short sprints, for instance
  • Writing comments preemptively puts the agreement between the pair members to a test
    • kuni katsuya
      kuni katsuya on 15 Mar 13
       
      more relevant to methodologies using pair programming
  • commit history gains a very balanced granularity
  • feature branch becomes a collection of evolutionary commits each of which has usually a 1:1 binding with tests
  • very easy to find which commit introduced a bug, since each commit is related to a single new goal/feature
  • Preemptive commit comments
  • Rule #2: write what the software
  • I started taking a lot of care of the words I was using in comments, commits, test names and classes/variables/methods’ names
  • be supposed to do,
  • not what you did
  • should
  • Introducing BDD
  • began with the simple attempt to replace the world
  • “should“
  • “test”
  • with the world
  • Rule #1: write commit comments before coding
  • use the same criteria for my commits’ comments as well.
  • (not what you did)
kuni katsuya

Domain Language /Newsletter - 0 views

www.domainlanguage.com/...2012-09

DomainDrivenDesign LegacySystems BestPractices patterns

shared by kuni katsuya on 27 Mar 13 - No Cached
  • Expanding a Bubble Getting Started with DDD When Surrounded by Legacy Systems IV
kuni katsuya

Domain Language /Newsletter - 0 views

www.domainlanguage.com/...2012-03

DomainDrivenDesign LegacySystems BestPractices patterns

shared by kuni katsuya on 27 Mar 13 - No Cached
  • Getting Started with DDD When Surrounded by Legacy Systems II
  • Strategy 2: Autonomous Bubble
kuni katsuya

Chris Kelly: Programming Retrospective - 0 views

www.chrisjasonkelly.com/...programming-retrospective.html

BestPractices anti-patterns

shared by kuni katsuya on 27 Mar 13 - No Cached
  • Programming Retrospective
  • anti-patterns
  • Final classes without interfaces
  • ...18 more annotations...
  • Lack of Defensive Programming
  • Exposure of super state to child classes
  • Printing out error messages to console instead of logging
  • Classes with unclear focus
  • Unwieldy or unneeded comments
  • Use of exceptions to control program flow
  • Throwing of ambiguous exceptions
  • Use parameter objects instead of long method signatures
  • Never Duplicate Code
  • copy and paste job
  • Return nulls from methods
  • Null Object pattern
  • onus is then on the callee to check the result is not null before using the result
  • client then doesn't have to check for nulls
  • empty map should be returned
  • instead of returning null, an
  • Refactoring: Improving the Design of Existing Code
  •  Working Effectively with Legacy Code
kuni katsuya

Polymorphism and Interfaces: Chapter 7 of Objects and Java - 0 views

www.artima.com/...PolymorphismInterfaces1.html

java Interface NamingConvention BestPractices

shared by kuni katsuya on 19 Dec 12 - No Cached
  • Interface Naming Conventions
  • leave off redundant modifiers in member declarations of interfaces
  • either a noun or noun phrase
  • ...3 more annotations...
  • if you are using the interface to represent an abstract base class
  • adjective
  • if you are using the interface to represent a behavior
1 - 20 of 46 Next › Last »
Showing 20▼ items per page