SSブログ

書籍『The Clean Coder: A Code of Conduct for Professional Programmers』 [プログラマー現役続行]

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

  • 作者: Robert C. Martin
  • 出版社/メーカー: Prentice Hall
  • 発売日: 2011/05/23
  • メディア: ペーパーバック

『アジャイルソフトウェア開発の奥義』『Clean Code アジャイルソフトウェア達人の技』の著者であるRobert Martin氏の新著です。サブタイトルは、「プロのプログラマーの行動規範」という意味であり、著者自身の長年のソフトウェア開発の経験や失敗を紹介しながら、プロのプログラマーとしてはどうあるべきかが説明されています。目次は次の通りです。
Pre-Requisite Introduction
Chapter 1. Professionalism
Chapter 2. Saying No
Chapter 3. Saying Yes
Chapter 4. Coding
Chapter 5. Test Driven Development
Chapter 6. Practicing
Chapter 7. Acceptance Testing
Chapter 8. Testing Strategies
Chapter 9. Time Management
Chapter 10. Estimation
Chapter 11. Pressure
Chapter 12. Collaboration
Chapter 13. Teams and Projects
Chapter 14. Mentoring, Apprenticeship, and Craftsmanship
Appendix A. Tooling
目次を見てもらえれば分かるようにソフトウェア開発のいろいろな側面から説明がされています。今回は、Kindle版を購入してKindleで読んだのですが、アンダーラインをかなりたくさん引いています。その中で、私自身の身近な話題に近い事柄に関することをAppendix Aから一部を紹介します。
Source Code Control

When it comes to source code control, the open source tools are usually your best option. Why? Because they are written by developers, for developers. The open source tools are what developers write for themselves when they need something that works.

There are quite a few expensive, commercial, "enterprise" version control systems available. I find that these are not sold to developers so much as they are sold to managers, executives, and "tool groups." Their list of features is impressive and compelling. Unfortunately, they often don't have the features that developers actually need. The chief among those is speed.

An "Enterprise" Source Control System

It may be that your company has invested a small fortune in an "enterprise" source code control system. If so, my condolences. It's probably politically inappropriate for you to go around telling everyone, "Uncle Bob says not to use it." However, there is an easy solution.

You can check your source code into the "enterprise" system at the end of each iteration (once every two weeks or so) and use one of the open source systems in the midst of each iteration. This keeps everyone happy, doesn't violated any corporate rules, and keeps your productivity high.
青字の部分は、私が読んでアンダーラインを引いた箇所です(ボールドは私が単に強調した部分です)。また、Appendix Aには、「UML/MDA]」とタイトルされた部分で、次のようにも述べられています。
UML/MDA
(途中省略)

The dream was that software developers could leave behind the details of textual code and author systems in a higher-level language of diagrams. Indeed, so the dream goes, we might not need programmers at all. Architects could create whole systems from UML diagrams. Engines, vast and cool and unsympathetic to the plight of mere programmers, would transform those diagrams into executable code. Such was the grand dram of Model Driven Architecture (MDA).

Unfortunately, this grand dream has one tiny little flaw. MDA assumes that the problem is code. But code is not the problem. It has never been the problem. The problems is detail.
そして、detail(詳細)の意味を「The Details」で解説していますし、その後の「No Hope, No Change」でも解説が続いています(ちょっと長いので書籍を読んでみてください)。

書籍全体にプログラマーとしての行動規範や考えるべきことがが書かれています。そして、単にプログラマー向けというだけでなく、ソフトウェア開発組織のマネジャー層以上の人にも読んでもらいたい内容です。
nice!(1)  コメント(0)  トラックバック(0) 

nice! 1

コメント 0

コメントを書く

お名前:[必須]
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

Facebook コメント

トラックバック 0