The Pragmatic Programmer : From Journeyman to Master

Çarşamba, 10 Tem 2013 yorum ekle yorumlara git

The Pragmatic Programmer

Herkese merhaba!

Bir başka kitapla karşınızdayım. The Pragmatic Programmer : From Journeyman to Master yazılım mühendisliğiyle ilgili bir kitap. İşin daha çok felsefik kısmıyla ilgili. Kesinlikle ufuk açıcı bir kitap. Yazdığınız koda bakış açınızı değiştireceğini iddia ediyorum.

ISBN 0-201-61622-X

Altını çizdiğim yerler;

  • A broken window.

    One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
  • Ah, good old Ben Franklin—never at a loss for a pithy homily. Why, if we could just be early to bed and early to rise, we’d be great programmers—right? The early bird might get the worm, but what happens to the early worm?
  • You can also implement a more complex language, with a more formal syntax. The trick here is to define the syntax first using a notation such as BNF. Once you have your grammar specified, it is normally trivial to convert it into the input syntax for a parser generator. C and C++ programmers have been using yacc (or its freely available implementation, bison) for years. These programs are documented in detail in the book Lex and Yacc. Java programmers can try javaCC. The answer to Exercise 7 on page 282 shows a parser written using bison. As it shows, once you know the syntax, it’s really not a lot of work to write simple mini-languages.
  • After all, can’t you do everything equally well by pointing and clicking?The simple answer is “no.” GUI interfaces are wonderful, and they can be faster and more convenient for some simple operations. Moving files, reading MIME-encoded e-mail, and typing letters are all things that you might want to do in a graphical environment. But if you do all your work using GUIs, you are missing out on the full capabilities of your environment. You won’t be able to automate common tasks, or use the full power of the tools available to you. And you won’t be able to combine your tools to create customized macro tools. A benefit of GUIs is WYSIWYG—what you see is what you get. The disadvantage is WYSIAYG—what you see is all you get.
  • The easiest person to deceive is one’s self.
  • The DDD debugger has some visualization capabilities, and is freely available. It is interesting to note that DDD works with multiple languages, including Ada, C, C++, Fortran, Java, Modula, Pascal, Perl, and Python (clearly an orthogonal design).
  • There is a growing number of good text manipulation languages. Unix developers often like to use the power of their command shells, augmented with tools such as awk and sed. People who prefer a more structured tool like the object-oriented nature of Python. Some people use Tcl as their tool of choice. We happen to prefer Perl for hacking out short scripts.
  • When everybody actually is out to get you, paranoia is just good thinking.
  • For Java, there is iContract. It takes comments (in JavaDoc form) and generates a new source file with the assertion logic included.
  • Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away…
  • The project needs at least two “heads”—one technical, the other administrative. The technical head sets the development philosophy and style, assigns responsibilities to teams, and arbitrates the inevitable “discussions” between people. The technical head also looks constantly at the big picture, trying to find any unnecessary commonality between teams that could reduce the orthogonality of the overall effort. The administrative head, or project manager, schedules the resources that the teams need, monitors and reports on progress, and helps decide priorities in terms of business needs. The administrative head might also act as the team’s ambassador when communicating with the outside world.
  • People just aren’t as repeatable as computers are. Nor should we expect them to be. A shell script or batch file will execute the same instructions, in the same order, time after time. It can be put under source control, so you can examine changes to the procedure over time as well (“but it used to work…”).
  • Because memory is the second thing you lose as you age, [4] we don’t want to rely on it too heavily. We can run scripts to perform procedures for us automatically, based on the content of source code and documents. Our goal is to maintain an automatic, unattended, content-driven workflow.[4] What’s the first? I forget.
  • Finding bugs is somewhat like fishing with a net. We use fine, small nets (unit tests) to catch the minnows, and big, coarse nets (integration tests) to catch the killer sharks. Sometimes the fish manage to escape, so we patch any holes that we find, in hopes of catching more and more slippery defects that are swimming about in our project pool.
  • Because we can’t write perfect software, it follows that we can’t write perfect test software either. We need to test the tests.
  • In general, comments should discuss why something is done, its purpose and its goal. The code already shows how it is done, so commenting on this is redundant—and is a violation of the DRY principle.

Paylaş:
  • Facebook
  • FriendFeed
  • Twitter
  • del.icio.us
  • Digg
  • StumbleUpon
  • Technorati
  • LinkedIn
  • MySpace
  • BlinkList
  • Reddit
  • RSS
  • email
  • PDF

Benzer Yazılar (bunları bilgisayar seçiyor);

Benzer yazı yok ya da biz bulamadık.

Categories: Genel, Okuduklarım 88.342 Gösterim
  1. visualboy
    Perşembe, 01 Oca 2015 zamanında 13:17 | #1

    Turkcesi yok mu hocam, ingilizcem kaldirmaz bunu….

  1. şimdilik geri bağlantı yok