5 câu hỏi tại sao

Ono Taichi, thường chỉ đạo nhân viên cần phải đến hiện trường và lặp đi lặp lại 5 lần câu hỏi "tại sao" để tìm ra bản chất của vấn đề.
Chẳng hạn cấp dưới của bạn là anh A hôm nay nghỉ việc không xin phép.
1. Tại sao anh ta lại nghỉ không xin phép?
Vì hôm qua bạn đã nổi cơn thịnh nộ với anh ta.
2. Tại sao bạn nổi cơn thịnh nộ?
Vì thái độ làm việc của anh ta không tốt.
3. Tại sao thái độ làm việc của anh ta không tốt?
Vì hôm trước anh ta uống rượu đến tận khuya.
4. Tại sao anh ta uống rượu đến tận khuya?
Vì anh ta không có một mơ ước nào cho cuộc đời mình.
5. Tại sao anh ta không mơ ước?
Vì bầu không khí xơ cứng trong công ty làm mọi người không thể mơ ước về tương lai.

Rốt cuộc bản chất của vấn đề không phải ở chỗ nghỉ việc không xin phép mà là ở chỗ công ty bạn đang xơ cứng trong cơ chế hoạt động và không kích thích được nhân viên nuôi lớn những mơ ước của chính họ.

(Trích "Tư duy đột phá - tập quán tư duy của Toyota" - Hibino Shozo)

Code complete - Steve Mc Connell và Cổ Long

Sau khi đọc Giang Hồ Tứ Quái của Cổ Long rồi chuyển qua Code complete của Steve McConnell mới phát hiện ra văn phong gần gầngiống nhau. Nói chung, đọc "Code complete" và "Giang hồ tứ quái" đều cho cùng cảm giác tương tự. Triết lý/ ẩn dụ luôn xuất hiện trong từng câu chữ và làm cho ta bất ngờ.


"Có một số người rất thích mùa đông. Bởi vì những ngày vào đông có thể ngắm tuyết, vịnh mai và uống những chung rượu ấm. Bởi những cái thích thú ấy, những mùa khác đều không có được.

Nhất là sau khi uống vài ba chung rượu ấm rồi là đánh một giấc thì quả thật trừ những ngày đông ra thì không có vào những mùa nào khác.

Những người thích mùa đông tự nhiên không thể là những người nghèo. Vì mùa đông là cái mùa khốn khổ nhất cho những người nghèo khó.
Tất cả những người nghèo, ai cũng đều mong cho mùa đông đến thật muộn và qua thật nhanh, nếu có thể thì đừng bao giờ có mùa đông cũng được."
(Giang Hồ Tứ Quái - hồi 2)
----------------------------------------------------------------
Building a software system is like any other project that takes people and money. If you're building a house, you make architectural drawings and blueprints before you begin pounding nails. You'll have the blueprints reviewed and approved before you pour any concrete. Having a technical plan counts just as much in software.

You don't start decorating the Christmas tree until you've put it in the stand. You don't start a fire until you've opened the flue. You don't go on a long trip with an empty tank of gas. You don't get dressed before you take a shower, and you don't put your shoes on before your socks. You have to do things in the right order in software, too.

Code complete - Steve McConnell

Tuyển dịch - Core J2EE patterns best practices and design strategies

Core J2EE patterns - best practices and design strategies là một trong những quyển sách hay dành cho lập trình viên - được biên soạn bởi Deepak Alur, John Crupi, Dan Malks. Cho dù bạn có là tín đồ của .NET, PHP, Ruby, ... tôi khuyên bạn vẫn nên đọc qua nó - nếu bạn muốn mình có thể đạt đến một trình độ kĩ thuật cao hơn (ở mức độ thiết kế và xây dựng kiến trúc hệ thống phần mềm).

Tôi sẽ lựa chọn một số chương mà tôi tâm đắc để dịch và giới thiệu đến mọi người.
Tuy nhiên tôi sẽ không dịch sát nghĩa trên nội dung mà sẽ viết lại theo cảm nhận và cách hiểu của mình. Nội dung dịch sẽ bám sát theo tư tưởng: phân tích và giải thích vấn đề không bị phụ thuộc vào ngôn ngữ. Do đó nếu bạn muốn hiểu sâu về chi tiết và cách hiện thực trên J2EE thì nên đọc từ ebook tiếng Anh.

Một quyển sách khác mà tôi cũng khuyên bạn nên đọc là: Enterprise Solution patterns Using Microsoft.NET. Đây là quyển dành cho lập trình viên .NET. Tuy nhiên xét về nội dung thì các pattern này cũng gần như tương tự nhau - chỉ khác nhau về cách hiện thực chi tiết trên mỗi platform.

Mục đích của việc dịch và giới thiệu quyển sách này là muốn chia sẻ với mọi người
Nếu các bạn thấy có những đoạn dịch chưa chuẩn hoặc làm mọi người hiểu sai ý nghĩa xin vui lòng đóng góp và gửi mail cho mình: tran.dang.khoa.khtn@gmail.com

Danh sách những chương sách đã dịch sẽ được cập nhật qua bài viết này
(hiện tại chỉ mới dịch xong chương 1)

Chương 1: Giới thiệu

Napoleon Hill và Cách nghĩ để thành công

Có nhiều quyển sách để lại ấn tượng trong tôi, nhưng ít có quyển sách nào để lại trong tôi những "ám ảnh" sâu sắc đến thế.

Cách nghĩ để thành công là quyển sách đầu tiên đưa ra triết lý của sự thành đạt - được viết ra từ vô số những câu chuyện có thật của những người vĩ đại như Edison, Henry Ford,... những con người phần lớn đi lên từ 2 bàn tay trắng và đôi khi còn bị xem là thất học. Tuy nhiên họ đã để lại những dấu ấn thành công rực rỡ và những đóng góp vĩ đại cho nhân loại. Tác giả Napoleon Hill đã dành cả cuộc đời mình để phỏng vấn những con người như thế và đã đúc kết những nguyên lý dẫn đến thành công trong một quyển sách - mà theo tôi là kim chỉ nam cho những con người luôn đặt câu hỏi cho mình: tại sao tôi chưa thành công?

Dưới đây là một số trải nghiệm của tôi từ quyển sách này
1. Biết rõ các mục tiêu trong đời đã là đi được một nữa chặng đường đến sự thành công"
2. Hãy biến mục tiêu của bạn thành nỗi ám ảnh và sự khát khao tột bực. Nỗi ám ảnh đó sẽ chi phối đến tư duy, tiềm thức của bạn để chỉ cho bạn con đường đến thành công.
3. Đừng bao giờ từ bỏ mục tiêu, bởi vì: kẻ chiến thắng không bao giờ từ bỏ. Kẻ từ bỏ sẽ không bao giờ chiến thắng
4. Đừng bao giờ lo lắng rằng khó khăn sẽ đến với mình và dù đó có là sự thật hiển nhiên thì cũng không được phép nản lòng.
5. Không người nào đạt đến những thành công vĩ đại mà không chấp nhận hy sinh
6. Để thành công cần phải có sự liên kết với những con người nhiệt huyết, có khả năng và có cùng chí hướng
7. Bạn không nhất thiết phải trở thành người xuất sắc nhất trong mọi lĩnh vực. Sức mạnh trí tuệ mà bạn có chính là kiến thức của những con người mà bạn liên kết được.
8. Kiến thức không phải là những gì bạn nên biết mà là những gì bạn cần áp dụng để đạt được mục tiêu.

Rất khó để diễn đạt những ám ảnh của tôi sau khi đọc xong "Cách nghĩ để thành công". Có thể bạn sẽ có những trải nghiệm khác với những gì tôi đã rút ra. Hãy đọc thử xem!

Đọc "Refactoring" của Martin Fowler

Refactoring là một trong những quyển sách đáng đọc cho lập trình viên. Sách được viết và biên soạn bởi những cây đại thụ trong làng kĩ nghệ phần mềm: Martin Fowler, Kent Beck, John Brant, William Opdyke và don Roberts




"Refactoring" không phải là một quyển sách mới. Quyển mà tôi đọc được ấn hành vào năm 2002 (có ghi một dòng: Another stupid release 2002
For all the people which doesn’t have money to buy a good book - dành cho những kẻ ko có tiền mua sách :-). Có lẽ tác giả cũng khá vui tính). Trước đây tôi chỉ đọc lướt qua, chủ yếu là học chiêu. Giống như bọn giang hồ chỉ thích học lóm chiêu pháp của người khác mà không luyện qua những chiêu thức căn bản. Đến sau này có thời gian đọc lại, tôi mới thấu hiểu những tinh hoa nằm sau nội dung sách.

Một chương trình, xét cho cùng cũng chỉ là một tập những dòng mã. Do đó giá trị của một chương trình ngoài những giá trị về chức năng - kinh tế nó cung cấp cho khách hàng, còn một yếu tố quan trọng nữa là: chất lượng mã nguồn. Mã nguồn được đánh giá là tốt khi nó thỏa mãn các yếu tố:
1. Có giá trị cao về mặt kinh tế
2. Độ bao phủ test gần 100%
3. Có tính đơn giản
4. Không trùng lặp
5. Có sức biểu đạt cao.
(Trích từ phát biểu của Robert C.Martin về "thế nào là mã nguồn tốt")

Refactoring - tạm dịch là tinh chỉnh mã nguồn - là hoạt động giúp ta đạt được 3 yếu tố (3) (4) (5). Trong đó yếu tố số 5 được xem là yếu tố then chốt cần đạt được trong refactoring.
Dưới đây tôi giới thiệu tổng quan một số chương sách để giúp bạn có một góc nhìn ban đầu.

Chương 1 của quyển sách đưa ra một ví dụ đầu tiên về refactoring thông qua một đoạn mã nguồn cụ thể và áp dụng refactoring để làm cho mã nguồn trở nên dễ đọc hơn.

Chương 2 nói về những nguyên tắc của refactoring. Đây là chương chưa đựng nhiều giá trị đáng đọc. Nó trả lời giúp tôi những câu hỏi thú vị: tại sao cần refactoring? tôi phải nói với sếp điều gì khi tôi muốn refactor mã nguồn của tôi? Mối quan hệ giữa refactoring và design? Mối quan hệ giữa refactoring và hiệu suất chương trình.

Chương 3: Giúp bạn phát hiện mã xấu. Đây cũng là một chương rất quan trọng vì nó giúp bạn hình thành nên ý niệm giữa cái tốt và xấu trong mã nguồn

Chương 4: Giúp bạn ý thức về việc viết Unit test để đảm bảo mã nguồn của bạn chạy đúng. Các unit test cũng giúp bạn phát hiện sai lầm trong quá trình refactoring.

Từ chương 5 đến chương 13 là những chương dạy cho bạn chiêu pháp để tinh chỉnh mã nguồn.
Chương 14 bàn thêm về những công cụ hỗ trợ refactoring

Tôi đánh giá rất cao 4 chương đầu tiên của quyển sách. Chúng được xem là những chiêu thức căn bản và tạo nên tinh hoa của quyển sách này.

Về các chiêu thức để refactoring (HOW), tôi tạm chia chúng ra làm 4 cấp bậc:

Cấp 1: các chiêu thức sử dụng để refactor những đoạn mã nguồn nhỏ (các quy tắc đặt biến, biểu thức điều kiện, loại bỏ parameter thừa, ...)
Cấp 2: Cấp độ phương thức (method)
Cấp 3: Cấp độ class
Cấp 4: Cấp độ thuật toán và thiết kế hệ thống


Thực chất, không cần phải nhớ hết tất cả những chiêu thức trong sách. Để đọc quyển sách này một cách hiệu quả, tôi làm như sau:
- Ghi nhớ tinh thần và các ý niệm của 4 chương đầu tiên.
- Mở lại những đoạn mã nguồn cũ - tìm ra những đoạn mã xấu.
- Xác định các module cần refactor
- Viết Unit test cho những hàm mà module cung cấp ra ngoài. (vì trước đây tôi ít viết Unit test cho những đoạn mã nguồn cũ)
- Đọc tiếp các chiêu thức còn lại. Sau mỗi chương, tôi thực hành ngay trên những module tôi xác định muốn refactor.
Đó là cách mà tôi đọc và thực hành trên quyển sách này. Còn bạn?