Salah satu cara paling mudah dalam mempelajari TDD adalah dengan berpartner / berpasangan dengan developer yang telah terbiasa dengan TDD. Akan tetapi bila tidak memungkinkan, kita dapat memahami konsep TDD dengan melihat screencast yang banyak terdapat di internet.

Beberapa screencast TDD yang mudah dipahami adalah :

1. http://agilesoftwaredevelopment.com/videos/test-driven-development-basic-tutorial
2. http://agilesoftwaredevelopment.com/videos/test-driven-development-mock-objects

Salah satu buku yang seharusnya menjadi bacaan wajib developer java adalah buku Effective Java karangan Joshua Bloch. Buku ini menjadi bacaan wajib karena buku ini mengajarkan penggunaan paling efektif dari bahasa pemrograman java.

Mengutip perkataan James Gosling tentang buku ini “I sure wish I had this book ten years ago. Some might think that I don’t need any Java books, but I need this one.”

Pada edisi 2, buku ini memberikan 78 item cara bagaimana membuat pemrograman java menjadi lebih efektif, dimana ke 78 item itu terpecah menjadi 10 pokok permasalahan.

I. Creating and Destroying Objects

• Item 1: Consider static factory methods instead of constructors
• Item 2: Consider a builder when faced with many constructor parameters
• Item 3: Enforce the singleton property with a private constructor or an enum type
• Item 4: Enforce noninstantiability with a private constructor
• Item 5: Avoid creating unnecessary objects
• Item 6: Eliminate obsolete object references
• Item 7: Avoid finalizers

II. Methods Common to All Objects

• Item 8: Obey the general contract when overriding equals
• Item 9: Always override hashCode when you override equals
• Item 10: Always override toString
• Item 11: Override clone judiciously
• Item 12: Consider implementing Comparable

III. Classes and Interfaces

• Item 13: Minimize the accessibility of classes and members
• Item 14: In public classes, use accessor methods, not public fields
• Item 15: Minimize mutability
• Item 16: Favor composition over inheritance
• Item 17: Design and document for inheritance or else prohibit it
• Item 18: Prefer interfaces to abstract classes
• Item 19: Use interfaces only to define types
• Item 20: Prefer class hierarchies to tagged classes
• Item 21: Use function objects to represent strategies
• Item 22: Favor static member classes over nonstatic

IV. Generics

• Item 23: Don’t use raw types in new code
• Item 24: Eliminate unchecked warnings
• Item 25: Prefer lists to arrays
• Item 26: Favor generic types
• Item 27: Favor generic methods
• Item 28: Use bounded wildcards to increase API flexibility
• Item 29: Consider typesafe heterogeneous containers

V. Enums and Annotations

• Item 30: Use enums instead of int constants
• Item 31: Use instance fields instead of ordinals
• Item 32: Use EnumSet instead of bit fields
• Item 33: Use EnumMap instead of ordinal indexing
• Item 34: Emulate extensible enums with interfaces
• Item 35: Prefer annotations to naming patterns
• Item 36: Consistently use the Override annotation
• Item 37: Use marker interfaces to define types

VI. Methods

• Item 38: Check parameters for validity
• Item 39: Make defensive copies when needed
• Item 40: Design method signatures carefully
• Item 41: Use overloading judiciously
• Item 42: Use varargs judiciously
• Item 43: Return empty arrays or collections, not nulls
• Item 44: Write doc comments for all exposed API elements

VII. General Programming

• Item 45: Minimize the scope of local variables
• Item 46: Prefer for-each loops to traditional for loops
• Item 47: Know and use the libraries
• Item 48: Avoid float and double if exact answers are required
• Item 49: Prefer primitive types to boxed primitives
• Item 50: Avoid strings where other types are more appropriate
• Item 51: Beware the performance of string concatenation
• Item 52: Refer to objects by their interfaces
• Item 53: Prefer interfaces to reflection
• Item 54: Use native methods judiciously
• Item 55: Optimize judiciously
• Item 56: Adhere to generally accepted naming conventions

VIII. Exceptions

• Item 57: Use exceptions only for exceptional conditions
• Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
• Item 59: Avoid unnecessary use of checked exceptions
• Item 60: Favor the use of standard exceptions
• Item 61: Throw exceptions appropriate to the abstraction
• Item 62: Document all exceptions thrown by each method
• Item 63: Include failure-capture information in detail messages
• Item 64: Strive for failure atomicity
• Item 65: Don’t ignore exceptions

IX. Concurrency

• Item 66: Synchronize access to shared mutable data
• Item 67: Avoid excessive synchronization
• Item 68: Prefer executors and tasks to threads
• Item 69: Prefer concurrency utilities to wait and notify
• Item 70: Document thread safety
• Item 71: Use lazy initialization judiciously
• Item 72: Don’t depend on the thread scheduler
• Item 73: Avoid thread groups

X. Serialization

• Item 74: Implement Serializable judiciously
• Item 75: Consider using a custom serialized form
• Item 76: Write readObject methods defensively
• Item 77: For instance control, prefer enum types to readResolve
• Item 78: Consider serialization proxies instead of serialized instances

• Buku Effective Java 2nd edition, karangan Joshua Bloch (chapter 1)
• Amazon.com

Dalam suatu software development project, sering kita memulai project itu dengan gambaran yang jelas akan apa yang akan kita kerjakan. Akan tetapi seiring dengan berjalannya proses development, sering kita mengalami bahwa software yang kita buat semakin sulit untuk dimaintain (ditambah fitur baru, diubah fitur yang telah ada). The software start to rotting.

Design smells – The odors of rotting software

Kita mengetahui bahwa software yang kita buat mulai mengalami rotting ketika salah satu (atau lebih) hal-hal berikut terjadi :

1. Rigidity
2. Fragility
3. Opacity
4. Viscosity
5. Needless Complexity
6. Needless Repetition
7. Immobility

1. Rigidity

Rigidity adalah kecenderungan suatu software untuk sulit dirubah. Suatu design adalah rigid bila sebuah perubahan pada suatu modul menyebabkan banyak perubahan pada modul-modul yang lain.

2. Fragility

Fragility adalah kecenderungan suatu software untuk error di banyak tempat ketika suatu perubahan dibuat.

3. Opacity

Opacity adalah kecenderungan suatu software untuk sulit dipahami. Kode program yang berkembang seiring waktu biasanya akan semakin sulit dipahami ketika kode program itu dibaca.

4. Viscosity

Terdapat 2 bentuk viscosity, yaitu : Software viscosity dan Environment viscosity.

Software viscosity. Ketika software developer dihadapkan pada suatu perubahan, sering developer memiliki beberapa cara untuk melakukan perubahan itu. Ada cara yang tetap mempertahankan design yang telah dipakai untuk software itu (design preserving), ada pula cara yang tidak memperhatikan design yang dipakai untuk software itu (hack). Ketika cara design-preserving lebih sulit untuk dilakukan daripada hack, viscosity dari software itu tinggi. Dangan kata lain, lebih mudah untuk melakukan hal yang salah, daripada hal yang benar.

Environment viscosity. Environment viscosity terjadi ketika development environment terlalu lambat dan tidak efisien. Sebagai contoh, ketika waktu compile software terlalu lama, maka developer akan tergoda untuk membuat perubahan yang menyebabkan proses compile tidak lama, meski perubahan yang dilakukannya tidak memperhatikan design.

5. Needless Complexity

Needless complexity adalah design smell yang terjadi ketika design kita mengandung elemen yang tidak berguna pada saat ini.

Dalam suatu project, sering kita mengantisipasi suatu perubahan kebutuhan dengan memberi fasilitas untuk menyelesaikannya (dalam sisi design). Pada awalnya hal ini terlihat sebagai sesuatu yang cerdas, akan tetapi dengan berjalannya waktu, efek yang timbul justru sebaliknya.

Dengan menambah design untuk antisipasi perubahan kebutuhan di masa datang, maka ada bagian design yang tidak berguna dan ini membuat software semakin komplek dan semakin sulit untuk dimengerti.

6. Needless Repetition

Dalam suatu team, programmer A harus menyelesaikan suatu masalah, kemudian ia mencari contoh kode di dalam project yang sedang ia kerjakan yang sesuai untuk permasalahannya, kemudian mengcopy-paste kode itu dan memodifikasi kode itu agar sesuai dengan permasalahannya.

Yang tidak diketahui oleh programmer A bahwa kode itu adalah kode buatan programmer B dimana programmer B juga meng-copy paste dari bagian lain dari project (dan juga memodifikasinya). Bagaimana bila ternyata kode yang di-copy paste oleh programmer B ternyata adalah hasil copy-paste programmer C dari programmer D????

Dari ilustrasi ini terlihat bahwa kode yang di-copy paste ada di dalam project berulang kali dalam bentuk yang berbeda. Duplicate code terjadi, dan abstraction dilupakan. Apa yang terjadi seandainya kebutuhan akan code yang di-copy paste itu berubah? Seluruh Kode yang di-copy paste oleh programmer A,B,C,D juga harus berubah.

Hal ini berbeda ketika abstraction dipegang oleh programmer dan copy-paste dihindari sedapat mungkin. Ketika ada perubahan kebutuhan, maka bagian kode program yang harus berubah hanya satu, bukannya di setiap kode yang di-copy paste oleh masih-masing programmer.

7. Immobility

Sebuah design adalah immobile ketika suatu bagian design dari suatu sistem berguna untuk sistem lain, tetapi usaha dan resiko untuk memisahkan bagian itu dari sistem aslinya terlalu besar.

Agile Principles, Patterns, and Practices in C# ; by Martin C. Robert dan Martin Micah. (Chapter 7)

Contoh fine grained :

.....
int panjang = 20;
int lebar = 10;
int tinggi = 5;
balok.setPanjang(panjang);
balok.setLebar(lebar);
balok.setTinggi(tinggi);
long volume = balok.hitungVolume();
.....

Contoh coarse grained :

.....
int panjang = 20;
int lebar = 10;
int tinggi = 5;
long volume = balok.hitungVolume(panjang, lebar, tinggi);
.....

Ketika kita mendevelop applikasi berbasis Spring framework, sering kita membutuhkan Spring Application Context, baik itu dari Spring bean ataupun dari non Spring bean (class biasa).

Ada banyak cara untuk mendapatkan Spring Application Context, salah satu cara adalah dengan membuat bean yang mengimplements ApplicationContextAware. Cara ini sangat bermanfaat ketika kita dihadapkan dengan masalah dependensi dari spring bean yang saling sirkular.

Berikut adalah contoh bean yang mengimplement ApplicationContextAware:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

package abc;  
 
import org.springframework.beans.BeansException; 
import org.springframework.context.ApplicationContext; 
import org.springframework.context.ApplicationContextAware;  
 
public class SpringApplicationContextUtil implements ApplicationContextAware {     
 
    private static ApplicationContext CONTEXT;      
 
    public void setApplicationContext(ApplicationContext context) throws BeansException {         
        CONTEXT = context;     
   }      
 
    public static Object getBean(String beanName) {         
        return (CONTEXT != null) ? CONTEXT.getBean(beanName) : null;     
   } 
}

Bean itu kemudian kita daftarkan di file konfigurasi Spring

1
2
3

<bean id="springApplicationContextUtil"
   class="abc.SpringApplicationContextUtil">
</bean>

Kemudian file utils itu dapat digunakan klas apapun (dari spring bean ataupun bukan)

1

Object obj= SpringApplicationContextUtil.getBean("myBean");

• http://pro-programmers.blogspot.com/2009/05/spring-how-to-get-spring-context.html
• http://blog.jdevelop.eu/2008/07/06/access-the-spring-applicationcontext-from-everywhere-in-your-application/

Bukan dari tulang ubun ia dicipta
Sebab berbahaya membiarkannya dalam sanjung dan puja

Tak juga dari tulang kaki
Karena nista menjadikannya diinjak dan diperbudak

Tetapi dari rusuk kiri
Dekat ke hati untuk dicinta
Dekat ke tangan untuk dilindungi

Itulah Wanita