Recently I listen podcast from dotnetrock. The topic was about how can you be a better geeks. Saran yang paling mengena adalah always keep in touch with community. Mengenal setiap orang yang ada di komunitas sesuai spesialisasinya dan lebih bagus jika add ID YM, IM, atau FB mereka. Because if there’s a problem that you can’t handle it, you don’t have to looking everywhere. Just ask their opinion. Or maybe if you lucky enough you may solve the problem. That’s fast direction. Satu lagi yang sebenarnya pernah saya dengar. Yaitu tentang buku Code Complete. Guys from dotnetrock mention it to motivate geek’s skill into higher level. Well, itu buku memang bikin penasaran. Dan saya pun akhirnya mendapatkannya.
Disini saya highlight pada dua header.
Pertama tentang bagaimana memecahkan masalah yang kita pikir sangat kompleks dan anda merasa stuck pada saat tertentu karena belum bisa mendefinisikan major classnya. Well, jawabannya sangat sederhana.
One of the most effective guidelines is not to get stuck on a single approach. If diagramming the design in UML isn’t working, write it in English. Write a short test program. Try a completely different approach. Think of a brute-force solution. Keep outlining and sketching with your pencil, and your brain will follow. If all else fails, walk away from the problem. Literally go for a walk, or think about something else before returning to the problem. If you’ve given it your best and are getting nowhere, putting it out of your mind for a time often produces results more quickly than sheer persistence can. You don’t have to solve the whole design problem at once. If you get stuck, remember that a point needs to be decided but recognize that you don’t yet have enough information to resolve that specific issue. Why fight your way through the last 20 percent of the design when it will drop into place easily the next time through? Why make bad decisions based on limited experience with the design when you can make good decisions based on more experience with it later? Some people are uncomfortable if they don’t come to closure after a design cycle, but after you have created a few designs without resolving issues prematurely, it will seem natural to leave issues unresolved until you have more information (Zahniser 1992, Beck 2000).
Next is about Experimental Prototyping.
Prototyping works poorly when developers aren’t disciplined about writing the absolute minimum of code needed to answer a question. Suppose the design question is, “Can the database framework we’ve selected support the transaction volume we need?” You don’t need to write any production code to answer that question. You don’t even need to know the database specifics. You just need to know enough to approximate the problem space—number of tables, number of entries in the tables, and so on. You can then write very simple prototyping code that uses tables with names like Table1, Table2, and Column1, and Column2, populate the tables with junk data, and do your performance testing.
Prototyping also works poorly when the design question is not specific enough. A design question like “Will this database framework work?” does not provide enough direction for prototyping. A design question like “Will this database framework support 1,000 transactions per second under assumptions X, Y, and Z?” provides a more solid basis for prototyping.
A final risk of prototyping arises when developers do not treat the code as throwaway code. I have found that it is not possible for people to write the absolute minimum amount of code to answer a question if they believe that the code will eventually end up in the production system. They end up implementing the system instead of prototyping. By adopting the attitude that once the question is answered the code will be thrown away, you can minimize this risk. One way to avoid this problem is to create prototypes in a different technology than the production code. You could prototype a Java design in Python or mock up a user interface in Microsoft PowerPoint. If you do create prototypes using the production technology, a practical standard that can help is requiring that class names or package names for prototype code be prefixed with prototype. That at least makes a programmer think twice before trying to extend prototype code (Stephens 2003).
Code Complete, Second Edition By Steve McConnell
.
