Bước đầu làm quen với Amazon Kindle 3

Màn hình

Amazon Kindle 3 có màn hình lớn 6″ công nghệ hiển thị e-ink. Tất nhiên đây không phải là màn hình cảm ứng, và có lẽ phải cảm ơn Amazon đã không sử dụng màn hình cảm ứng vì dù sao thì đây cũng là một thiết bị đọc sách và không cần thiết phải dùng màn hình cảm ứng làm gì cả. Thực tế cho thấy, một số thiết bị đọc sách khác dùng e-ink và có cảm ứng cho chất lượng hiển thị không bằng với Kindle 3.

Với công nghệ e-ink, việc bạn mở màn hình bao lâu không là vấn đề quan trọng vì màn hình e-ink chỉ tốn pin khi bạn thực hiện các một thao tác nào đó như chuyển trang, mở menu … Hay nói cách khác với Kindle 3 mỗi lần nhấn phím bấm là một lần tốn pin. Và thời gian sử dụng pin tùy thuộc vào số lần bấm của bạn, bấm nhiều thì hao pin nhanh hơn. Amazon cũng khuyến khích bạn không tắt hẳn máy mà chỉ cần để chế độ sleep là được, khi đó màn hình sẽ chuyển qua hiển thị một hình ảnh có sẵn trong máy, máy sẽ không tốn pin trong quá trình này.

Mỗi lần cần hiển thị một thông tin mới, màn hình sẽ nháy (xoá và hiển thị cái mới), đây là đặc thù của màn hình e-ink và bạn không cần phải quá lo lắng về vấn đề này. Màn hình e-ink cũng không tự phát sáng mà dựa vào nguồn sáng xung quanh, chính vì thế mà nắng càng to thì màn hình nhìn càng rõ điều này cũng đồng nghĩa là trong đêm nếu bạn muốn đọc sách thì nên kiếm cho mình 1 cái đèn.

Loa ngoài

Kindle 3 có 2 loa ngoài lớn ở mặt sau của máy. Loa này cho chất lượng khá tốt, to và rõ. Rất thích hợp với ai thích vừa đọc sách vừa nghe nhạc. Ngoài ra nó còn rất hữu dụng trong tính năng Text-To-Speech, máy sẽ tự đọc ebook cho bạn nghe (tất nhiên là tiếng anh). Loa ngoài cũng là một thành phần tiêu thụ điện năng khá nhiều của Kindle 3.

Cặp nút bấm chuyển trang

Đặc trưng và cũng là điểm mạnh của Kindle 3 đó chính là cặp nút bấm chuyển trang ở 2 bên cạnh màn hình. Với cụm nút bấm này bạn sẽ rất linh hoạt trong việc thao tác cũng như thoải mái cầm máy ở nhiều tư thế khác nhau. Hai cặp nút ở 2 bên có chức năng giống nhau đều bao gồm 2 nút bấm: 1 dài 1 ngắn: nút ngắn hơn ở phiá trên là back – quay lại trang trước, nút dài hơn ở phía dưới là forward – qua trang kế tiếp.

Các chi tiết khác

Phía dưới máy còn các các chi tiết khác lần lượt từ trái qua đó là: cặp phím tăng giảm âm lượng, giắc cắm tai nghe, cổng kết nối microUSB, nút power và đèn báo sạc pin.

Bàn phím QWERTY

Bàn phím QWERTY của máy có 4 dòng và không có dòng phím số. Riêng về bàn phím thì có nhiều ý kiến trái chiều nhau. Có một số người không thích nó vì bàn phím khiến cho máy khá dài, và tất nhiên là cồng kềnh hơn một chút, có vẻ như không hữu dụng so với một thiết bị đọc sách thông thường.

Riêng bản thân mình thấy bàn phím này khá tốt và hữu dụng. Với các phím tắt được thiết lập, bạn sẽ thao tác nhanh hơn và không phải quá khó khăn khi cần chuyển qua một vị trí location cụ thể nào đó trong ebook. Hơn nữa với bàn phím thực thì việc tra từ điển, nhập địa chỉ web … cũng đơn giản hơn.

Ngoài các phím tiêu chuẩn thì bàn phím này còn có thêm phím menu, cụm phím 5 chiều, các phim back, Home, Alt, Shift và Aa.

Hiện tại, phiên bản phần mềm mới nhất của Kindle 3 là 3.0.3. Nếu máy bạn chưa update lên phiên bản mới nhất này thì hãy làm ngay đi nhé. Các thao tác để kiểm tra và nâng cấp phiên bản phần mềm:

• Ngoài màn hình Home, nhấn phím Menu sau đó vào Settings. Trong Settings bạn có thể nhìn thấy phía dưới màn hình có dòng chữ “Version Kindle 3.0.x“, nếu x không phải số 3 thì chúng ta bắt đầu tiến hành nâng cấp nhé.
• Tải về phiên bản phầm mềm mới nhất: vào thời điểm của bài viết này thì Kindle 3 đang có phiên bản là 3.0.3, bạn có thể truy cập trực tiếp vào amazon.com để kiểm tra phiên bản mới nhất.
  • Kindle Wi-Fi: Download 3.0.3 Số serial number bắt đầu bằng “B008″
  • Kindle 3G (Free 3G + Wi-Fi): Download 3.0.3 Số serial number bắt đầu bằng “B006″
  • Kindle 3G (Free 3G + Wi-Fi): Download 3.0.3 Số serial number bắt đầu bằng “B00A”
• Kết nối Kindle với máy tính, lúc này máy tính hiểu Kindle ở dạng USB. Chép file mới tải về vào Kindle. Thực chất là control + c, control + v file đó vào. Sau khi quá trình chép hoàn tất (file chỉ có khoảng 3MB nên chép rất nhanh) thì remove usb và rút kết nối Kindle ra khỏi máy tính.
• Đảm bảo rằng Kindle của bạn còn trên 50% pin để cho an toàn. Các bước thực hiện:
  • Ngoài màn hình Home nhấn Menu sau đó vào Settings
  • Trong Settings nhấn Menu lần nữa, trên thanh Menu mới show ra chọn vào Update Your Kindle.
  • Kindle sẽ đơ 1 – 2s và sau đó quá trình update bắt đầu. Cứ để máy chạy và không can thiệp gì cả. Sau khoảng 3p đến 5p là hoàn tất.

Register – đăng kí máy với amazonNếu máy bạn đặt mua trực tiếp từ Amazon với tài khoản của bạn thì yên tâm là không phải làm bước nay vì họ đã làm sẵn cho bạn rồi. Chỉ cần bật máy lên và dùng thôi. Nếu bạn mua ở VN thì hãy lưu ý yêu cầu họ register giùm bạn vì một số trường hợp máy mua ở VN không register được, vì thế tốt nhất là nên yêu cầu người bán làm giùm bạn thao tác này.

Nếu không Register thì một số tính năng sẽ bị mất mà dễ thấy nhất là “Create New Collection“. Để đăng kí thì trước tiên máy bạn phải kết nối internet (thông qua wifi, tin buồn là Kindle3 3G hiện không đăng kí được nếu bạn ở VN). Sau khi đã đăng kí thì phần Settings của bạn cũng có thêm nhiều lựa chọn khác.

Thao tác để Register: Ngoài màn hình Home nhấn Menu -> Settings -> Registration -> Nhập vào email và mật khẩu -> nhấn submit (Nếu email này đã đăng kí với Amazon); nhấn create account (nếu email này chưa đăng ký).

Chỉnh các thông số trong SettingsSau khi đã đăng kí thì Settings của bạn sẽ có thêm một vài tùy chỉnh khác mà bạn có thể sử dụng. Có một số tính năng mình không nói đến trong mục này thì hoặc là nó sẽ được nói đến ở phần sau hoặc là vì nó không hữu dụng ở Việt Nam nên mình không đề cập đến ở đây. Danh sách các mục được liệt kê từ trên xuống.

1 – Registration

Phần này đã nói ở bên trên. Sau khi đã Register xong thì ở đây sẽ xuất hiện mục deregister để bạn loại bỏ đăng kí cho máy, cần thiết trong trường hợp bạn muốn bán hay cho người khác máy của mình.

2 – Device Name

Tên hiển thị tại vị trí góc trái trên mỗi khi bạn ở ngoài màn hình Home. Tên này được tự động cập nhật khi bạn register với Amazon, nếu muốn đặt tên bất kì thì bạn nhấn vào nút edit bên cạnh và chọn lại tên cho mình.

3 – Wifi Settings

Thiết lập kết nối Wifi cho máy. Trong trường hợp tiết kiệm pin hay không có nhu cầu dùng đến thì bạn nên tắt wifi đi. Nhấn vào view để chọn mạng wifi và kết nối.

4 – Device Password

Cài đặt mật khẩu cho máy, trong trường hợp bạn không muốn người khác tò mò chú Kindle của mình. Để đặt mật khẩu chọn Turn on và đặt vào mật khẩu mong muốn.

Ngoài ra: nếu trong Settings mà bạn nhấn Menu thì sẽ có thêm 1 số lựa chọn khác như: Turn Wireless Off (tắt wifi đi), Change Primary Dictionary (đổi từ điển mặc định của máy), Restart (khởi động lại máy), Reset to Factory Defaults (xóa hết dữ liệu, đưa máy về tình trang ban đầu).

Chép ebook vào Kindle 3

Để chép file vào Kindle thì cách đơn giản nhất là cắm thẳng Kindle vào máy tính, khi đó máy tính sẽ hiểu Kindle là một cái USB, và chúng ta cứ thế khéo thả file vào là được. Ngoài ra Amazon cũng cung cấp cho người sử dụng một dịch vụ rất tốt, thông qua trang Manage Your Kindle, qua đây bạn có thể gửi file thẳng vào Kindle thông qua email. Để cho đơn giản thì mình chỉ nói đến việc chép file thông qua USB, phần gửi file qua email xin để nói riêng.

Trước tiên bạn phải biết Kindle 3 có thể đọc được các định dạng file nào. Phải nói là định dạng được Kindle hỗ trợ khá ít, tuy nhiên đáng mừng là định dạng PRC phổ biến được hỗ trợ rất tốt:

• documents: Kindle (.AZW, .AZW1). Text (.TXT), Unprotected Mobipocket (.MOBI, .PRC), PDF
• audible: Audible (.AA, .AAX)
• music: MP3 (.MP3)
• pictures: (.GIF, .JPG, .PNG)

Một lưu ý đó là khi chép file vào Kindle thì bạn phải đặt nó đúng vào thư mục phù hợp (phần chữ in đậm bên trên cũng chính là tên thư mục của từng loại file). Và tốt nhất là bạn không nên xóa những file mà bạn không biết rõ nó là gì trong Kindle. Danh sách các thư mục và nội dung tương ứng:

• documents: chứa file ebook (.AZW, .TXT, .MOBI và .PRC)
• audible: Audible (.AA, .AAX)
• music: Kindle chỉ hỗ trợ file nhạc định dạng MP3. Ngay cả những file audiobook (sách nói) định dạng MP3 thì cũng chép vào đây. Trình nghe MP3 có sẵn khá đơn giản và không được thiết kế để nghe audiobook mp3, có lẽ Amazon không cho đây là nhu cầu cần thiết.
• pictures: Mặc định thư mục này không có sẵn, nếu máy bạn chưa có sẵn thư mục này thì bạn tạo thêm vào. Để chép 1 bộ hình vào thư mục này thì bạn nhớ tạo riêng 1 thư mục cho bộ hình đó trong thư mục này. VD: Kindle/Pictures/Hinh xxx. Sau khi chép hình vào máy, rút kết nối ra khỏi máy tính và nhấn Alt + Z để Kindle tự cập nhật danh sách những cái mới.

Đọc sách trên Kindle 3

Màn hình Home

Trước khi bắt đầu vào đọc sách thì chúng ta làm quen với giao diện màn hình Home của Kindle 3. Đặc điểm của Kindle đó là tất cả các nội dung khi bạn chép trong máy thì nó đều hiện ra ngoài màn hình chính này. Và bạn chỉ có màn hình chính này để quản lí tất cả các ebook, hình ảnh của mình mà thôi. Để tiện cho việc quản lý thì tạo Collections là một lựa chọn cần thiết.

Để tạo một Collection thì ngoài màn hình Home nhấn Menu và chọn Create New Collection. Tất nhiên máy bạn đã phải Register như phần trên đã trình bày thì mới có lựa chọn này.

Để chỉnh ebook vào 1 collection nào đó thì có 2 cách: đơn giản là bạn di chuyển con trỏ tới ebook nó sau đó nhấn phím điều hướng (phím 5 chiều) qua bên phải, sau đó chọn Add to Collection … Hoặc cũng có thể vào 1 collection có sẵn nhấn phím Menu và chọn Add/Remove Items.

Để xóa 1 ebook bạn cũng di chuyển con trỏ tới ebook đó và nhấn phím điều hướng (phím 5 chiều) qua phải và chọn Delete This Document. Để đổi tên hay xóa 1 collection thì truy cập vào collection đó, nhấn Menu và chọn tính năng tương ứng.

Màn hình đọc sáchVới khá nhiều phím bấm thì việc đọc sách khá là thuận tiện, cả 2 cụm phím bấm chuyển trang ở 2 bên máy giúp bạn có thể cầm máy bên tay trái hay tay phải đều được. Ngoài ra các phím khác giúp bạn có thể thao tác nhanh là Menu, Home, Back … Bấm 1 phím bất kì trên bàn phím để kích hoạt tính năng tìm từ trong ebook. Dùng phím 5 chiều để di chuyển con trỏ đến từ bạn muốn tra nghĩa hoặc ghi chú.

Ngoài ra còn 1 phím bấm đặc biết đó là phím Aa, giúp bạn chỉnh nhanh chế độ hiển thị ebook. Di chuyển con trỏ đến lựa chọn của bạn và giữ yên đó trong khoảng 2s, máy sẽ hiển thị trước kết quả để bạn có thể duyệt qua trước:

• Dòng đầu tiên: Chỉnh kích thước font chữ
• Typeface: Chọn font chữ. Có 3 font cho bạn chọn đó là regular, condensed và sans serif
• Line Spacing: Khoảng cách giữa các dòng
• Words per Line: số từ trên mỗi dòng
• Text-to-Speech: kích hoạt tính năng đọc văn bản. Chỉ áp dụng cho tiếng anh vì tiếng việt máy đọc không hiểu là nó đọc cái gì. Với những ebook tiếng anh máy đọc khá tốt, bạn có thể vừa nghe vừa đọc chữ để học tiếng anh.
• Screen Rotation: xoay màn hình.

Các tính năng mở rộng – Experimental

Ngoài đọc sách là tính năng chính thì Kindle 3 còn có thêm 1 số tiện ích khác. Tuy nhiên đây chỉ là những phần phụ vì thế nó cũng chỉ đáp ứng được phần nào nhu cầu của bạn và có phần hơi hạn chế. Để truy cập các tính năng này thì ngoài màn hình Home nhấn Menu và chọn Experimental 1 – Text To Speech

Như đã nói ở phần Màn hình đọc sách tính này giúp bạn có thể vừa đọc vừa nghe tiếng anh, rất tốt nếu như bạn muốn đọc tiếng anh. Ebook tiếng Việt máy cũng đọc được nhưng bạn sẽ ko hiểu nó đọc cái gì.

2 – Play MP3

Cũng giống tính năng trên, Play MP3 cũng là 1 tính năng chạy nền. Bạn có thể vừa nghe nhạc vừa đọc sách. Kindle 3 không có một giao diện quản lí nhạc vì thế việc bạn có thể làm là chỉ có thể nghe từ đầu đến cuối, play/stop hoặc next mà thôi, (không có back)

Nếu như bạn chép chuyện đọc audiobook định dạng mp3 vào đây thì bắt buộc phải nghe một lèo từ đầu đến cuối.

3 – Web Browser

Với màn hình đơn sắc và tốc độ xử lý chậm thì không khuyến khích bạn dùng Kindle 3 để duyệt web, đây cũng là tính năng “đốt pin” khá tốt. Amazon cũng trang bị cho Kindle 3 tính năng Article Mode, hỗ trợ chuyển trang web đang duyệt về dạng article, hiển thị giống như trang sách với các thông tin dư thừa bị loại bỏ, tin buồn là không phải website nào cũng hỗ trợ tính năng này.

Để kích hoạt tính năng này thì trong khi đang duyệt web bạn nhấn Menu và chọn Article Mode.

Một số phím tắt và thủ thuật

Amazon Kindle 3 có hỗ trợ từ điển và cả tra từ chéo khi bạn đang đọc sách, máy có sẵn 2 từ điển Anh – Anh khá tốt. Nếu muốn bạn có thể cài thêm từ điển Anh – Việt – Anh vào nữa là đầy đủ. Tham khảo thêm:

• Cài từ điển mặc định cho Kindle 3

Sử dụng mục tìm kiếm

• Alt + Del: xoá toàn bộ nội dung trong khung tìm kiếm.
• @dict <từ khoá>: tra từ điển
• @help : hiển thị toàn bộ các câu lệnh của máy
• @url <địa chỉ web>: truy cập thẳng vào 1 trang web nào đó. Nếu điạ chỉ web đễ trống thì Browser được kích hoạt
• @web <từ khoá>: tìm kiếm google với từ khoá

Sử dụng Text-to-Speech (TTS)

• Tính năng này chỉ chạy khi bạn đang đọc ebook.
• Kích hoạt: Shift + SYM. Để tắt đi thì ta nhấn phím BACK. Nếu bạn nhấn Shift + SYM mà TTS không chạy thì có nghĩa là ebook đó không hỗ trợ TTS.
• Tạm dừng: khi TTS đang được kích hoạt thì bàn phím sẽ bị khoá. Để tạm dừng nhấn SPACEBAR.

Chơi nhạc:

• Nhạc MP3 phải được để trong folder “music”
• Play/Stop: ALT + SPACEBAR
• Chạy tới 1 bài: ALT + F

Xem hình:

• Chép hình ảnh (JPG, GIF hay PNG) vào 1 folder nào đó trong folder “picture”. Tốt nhất nên để kích thước là 600 x 800.
• nhấn ALT + Z. Folder mới chép vào sẽ hiện lên trên danh sách ebook.
• Zoom in: Q
• Zoom out: W
• Reset zoom: E
• Quay hình: R

Kích hoạt Games ẩn:

• Ngoài màn hình Home nhấn ALT + Shift + M
• Nhấn MENU để chỉnh option của game
• Nhấn G để mở games GoMoKu

Phím tắt khác:

• ALT + Z: quét lại dữ liệu và lên danh sách mới
• ALT + (Q W E R T Y U I O P) ra kết quả là các con số (1 2 3 4 5 6 7 8 9 0)
• ALT + G: tương tự F5 trên máy tính. Trong trường hợp màn hình bị nhoè chữ, có bóng mờ
• ALT + Shift + G (hoặc H): chụp hình màn hình
• Trong khi đọc sách muốn xem giờ thì nhấn Menu
• Soft restart: Home -> Menu -> Settings -> Menu -> Restart
• Hard restart: Slide và nhấn giữ power trong 30s
• Tắt hẳn máy: Slide và giữ power trong 7 giây. Không khuyến khích bạn tắt máy, chỉ tắt khi không dùng máy trong thời gian dàiSử dụng Kindle 3 – những vấn đề cơ bản
  

  
  Khái niệm thiết bị đọc sách điện tử (sau này xin gọi tắt là Sách điện tử) dường như dần trở lên quen thuộc đối với chúng ta. Càng ngày càng có nhiều người có ý định sở hữu một Sách điện tử để thoả mãn thú vui đọc sách. Tuy nhiên để chọn cho mình được một chiếc ưng ý cũng là cả một vấn đề, hiện nay trên thị trường có vô vàn các loại Sách điện tử khác nhau. Một trong những ứng cử viên đó là Kindle 3 do Amazon sản xuất, đây đúng nghĩa là một Sách điện tử với việc nó đề cao tính năng đọc sách và tất cả các tính năng khác kèm theo chỉ để cho vui mà thôi.

  Amazon Kindle 3 có gì đặc biệt?

  Kindle 3 sử dụng mà hình công nghệ giấy điện tử e-ink, kích thước 6″ 800 x 600, không có cảm ứng. Ở Việt Nam, Kindle khá hữu dụng với việc nó hỗ trợ tiếng Việt unicode tốt, hỗ trợ định dạng ebook PRC. Bạn sẽ dễ dàng tìm và tải về những ebook dạng này trên mạng.

  Điểm trừ là máy không hỗ trợ thẻ nhớ ngoài tuy nhiên với bộ nhớ trong 4G có lẽ cũng đủ để bạn chứa kho ebook của mình rồi. Loa ngoài khá to, bạn có thể vừa đọc sách vừa nghe nhạc du dương.

  Tính năng của Kindle 3?

  Ngoài tính năng đọc sách thì Kindle 3 còn có thể lướt web qua wifi, nghe nhạc MP3. Với việc có nhiều loại từ điển khác nhau, chức năng đọc văn bản tự động rất thích hợp cho ai cần học tiếng Anh. Máy cũng có thêm một tính năng khác đó là xem hình, nếu bạn là tín đồ của truyện tranh thì Kindle 3 cũng có thể đáp ứng được.

  Có hạn chế đó là vì tốc độ không cao, cùng với màn hình chỉ hiển thị đơn sắc nên việc lướt web trên Kindle 3 khá khó khăn. Chiếc máy này chỉ để đọc sách, nếu bạn đặt nặng vấn đề internet thì không lên nghĩ đến nó nhé.

  

  Sử dụng Kindle 3 có khó không?

  Câu trả lời là hoàn toàn không. Kindle 3 hướng tới việc đọc sách là chủ yếu, máy không nhiều chức năng vì thế bạn có thể yên tâm là nó khá dễ dùng. Hiện nay hướng dẫn sử dụng bằng tiếng Việt cũng đang được tinhte.vn hoàn thiện, trong tuần sau sẽ có thôi.

  Kindle 3 có sẵn bàn phím QWERTY nên bạn có thể sử dụng phím tắt để thao tác, nhanh và tiện hơn nhiều so với việc cứ phải nhấn menu và phím 5 chiều. Bàn phím này cũng thuận tiện trong khi bạn sử dụng từ điển.

  
  Nhỏ gọn, màn hình e-ink, pin lâu, bàn phím QWERTY

  Nguồn ebook cho Kindle 3 có nhiều không?

  Như đã nói ở trên Kindle 3 hỗ trợ ebook chuẩn PRC (ngoài ra còn có: Kindle (AZW), TXT, PDF, Audible (Audible Enhanced (AA, AAX)), MP3, unprotected MOBI, PRC natively; HTML, DOC, JPEG, GIF, PNG, BMP). Mà ebook dạng này bạn có thể tìm thấy dễ dàng trên mạng. Ngay trong tinhte bạn cũng có thể tìm thấy vô số những topic chia sẻ ebook này, ngoài ra có e-thuvien.com là một kho sách rất phong phú.

  Tạo, chuyển đổi định dạng ebook cho Kindle 3 có dễ không?

  Không dễ mà cũng không khó  nếu bạn có hứng thú thì có thể nghiên cứu thêm Mobipocket Creator nhé.

  Pin của Kindle 3 có sử dụng được lâu không?

  Thời lượng sử dụng pin của Kindle 3 không tính bằng thời gian bạn đọc sách mà tính vào số lần chuyển trang. Mỗi khi bạn thực hiện một thao tác nào đó (chuyển trang, nhấn menu …) màn hình máy sẽ nhấp nháy, những lúc như thế máy mới tốn pin.

  Tất nhiên nếu bạn bật wifi liên tục, hay lướt web, nghe nhạc thì đây lại là chuyện khác. Khi đó máy hết pin nhanh hơn bình thường. Hãy nhớ tắt wifi đi khi không sử dụng nhé.

  Một số người than phiền là máy của họ hết pin khá nhanh. Tuy nhiên để ý lại thì thấy, khi mua máy về, đã ngay lập tức chép rất nhiều ebook vào. Lúc này kindle phải index lại tất cả các ebook đó, công việc này tốn rất nhiều thời gian và pin. Vì thế nếu bạn chép nhiều ebook vào quá, để qua đêm pin tụt nhanh thì đừng thắc mắc nhé, index xong thì lại trở về bình thường.

  Phụ kiện kèm theo trong hộp có gì?

  Khi mua, ngoài Kindle 3 thì bạn còn nhận được sạc, cable và một sách hướng dẫn sử dụng.

  Có nên mua bao bảo vệ?

  Với thiết kế mỏng, màn hình lớn thì bao bảo vệ là một phụ kiện không thể thiếu của Kindle 3. Bạn có nhiều lựa chọn cho nhu cầu này, loại tốt thì có bao da của Kindle, bao da khacten, kém hơn một chút thì có thể đi đặt người ta may. Nhiều người đã đi đặt làm bao cứng, khi bỏ kindle vào thì nó như cuốn sách, cũng khá hay.

  Theo quan điểm cá nhân đã dùng qua, mình thấy không cần thiết phải mua bao da có đèn. Loại này khá đắt mà lại nặng. Gắn vào máy làm máy dày và nặng hơn rất nhiều, hơn nữa đèn theo bao không sáng đều khi đọc khá khó chịu. Đèn này dùng nguồn trực tiếp từ máy nên cũng ảnh hưởng đến thời gian sử dụng.

  
  Bao da có đèn của Kindle 3
  

  Dùng mã giảm giá để mua từ Amazon nhé các bác:
  Kindle Coupon Codes, Tutorials video, Amazon Kindle Coupon, Kindle Promo Code

Theo tinhte.vn

Chuyện em kể (1)

Sáng nay, cơn thèm ngủ réo gọi từ tờ mờ sáng, tôi định thần cố tiếp tục cho đến khi nào đầu óc hiện tại hoàn toàn bị mụ mẫm. Vẫn cái giường đặt trên lầu thuợng, mùng vắt sẵn bốn góc từ đời nào, cái mền được sắp ngay ngắn – bên trên là cái gối phai màu lục và chú Harkat kế bên. Tôi để đèn, bắt đầu chui vào ổ, không quên nhờ vã hai cái điện thoại xinh xinh gọi dậy giúp, và khòz.
Tôi nằm mơ, mơ những gì thì có lẽ tôi sẽ kể ra đây chi tiết khoảng mười mươi thôi, nhưng hôm nay thì hoàn toàn tôi không còn nhớ gì về giấc mơ của tôi cả, mà tôi nhớ về giấc mơ của em.

6h15 em gọi, đến chuông reo thứ năm (tôi ước chừng là như vậy) thì tôi bắt máy, trong đầu tôi không nghĩ hay bực bội gì vì xác xuất em gọi vào lúc sáng là cao nhất. Tôi chui ra chộp lấy điện thoại – chui vào ổ và nghe.

“Anh ơi em nằm mơ” – em vừa sản xuất bánh lọt vừa nói, em vẫn còn trong ổ giống tôi. Giấc mơ rất xấu khiến em khóc sướt mướt, tôi nói em kể cho tôi nghe. Như mọi khi, giờ thì cơn buồn ngủ đã trốn đâu mất rồi, dường như nó sợ em.

Em kể em thấy tôi và em về sống ở dưới quê, cùng ba mẹ tôi. Sau một thời gian, tôi sẽ cưới một cô gái khác – kể đến đây thì em khóc nữa, em nói em khóc dữ lắm khi kể đến đó, và giờ thức dậy vẫn còn khóc y như trong mơ – em không có phản ứng gì về sự việc đang xảy ra, em thầm lặng. Ngày đãi tiệc, cũng như anh chị em trong nhà, em tiếp mọi người chuẩn bị – lúc này bản ngã của em đang làm những việc mà chính em cũng không biết tại sao. Khi rước dâu về, em nhìn cảnh tượng đó rồi lại buồn, đột nhiên nghĩ về gia đình em, không biết phải nói sao với ba mẹ và chị ba của em. Và em lại khóc, khóc và khóc nữa. Khóc xong rồi lại khóc tiếp, em đi thơ thẩn, tính về nhà mẹ nhưng đi được một đoạn thì quay về. Về đến thì lại thấy mọi người đang ăn tiệc vui mừng. Em lại khóc. Ba mẹ tôi hỏi sao lúc đầu con không phản đối gì cả, giờ con lại khóc, con không có phản ứng gì hết.

Em kể tiếp, cho một chi tiết nhỏ ngồ ngộ trong giấc là, lúc em tính đi về nhà thì làm rớt tờ tiền một trăm nghìn, khi rơi xuống thì nó biến mất, em làm thử với mấy tờ tiền lẻ còn lại thì kết quả xảy ra cũng y như vậy. Em lại khóc (trong mơ), em nói trong túi em chỉ còn có một-trăm-mấy-ngàn mà cũng bị mất.

Em và tôi

 

Lạnh lạnh giáng sinh an lành 2011

Hooray! Hip-hip-hooray!

M.E.R.R.Y C.H.R.I.S.T.M.A.S

 

1. Bà xã nói năm nay anh phải mần cái gì đó tặng em. hj hj

Và đây là sản phẩm mới ra lò, chúc bà xã giáng sinh an lành!

 

 

2. 1 tấm thiệp nhỏ làm tặng ACE mọi người

 

Merry Christmas 2011

 

3. Cũ mà hay

 

Error 20111224 Unknown build error The system cannot find the file specified. (Exception from HRESULT: 0x20111224).’ X:\Execute Project\Merry Christmas\SVN\MerryChristmas\wtfMerryChristmas\SantaModules\Items\NewItem\ListLovelyGirls.xaml wtfMerry Christmas …Be careful when click on it!

 

4. It’s Beginning To Look A Lot Like Christmas By Johnny Mathis

 

.

Một bài học quý

/*
*
* Nguồn Một bài học…
*
*/

9/29/2011 Gần đây tôi có đọc một bài diễn văn rất hay trên mạng. Tôi cũng không nhớ rõ đã đọc nó ở trang web nào, cho nên mạo muội xin phép tác giả và người đã đăng bài viết này trước đó cho tôi một cơ hội được giới thiệu bài viết này tới các bạn đọc.

Luật sư Georges Graham Vest

 

Đây là bài diễn văn của luật sư Georges Graham Vest tại một phiên tòa xử vụ kiện người hàng xóm làm chết con chó của thân chủ, được phóng viên William Saller của The New York Times bình chọn là hay nhất trong tất cả các bài diễn văn, lời tựa trên thế giới trong khoảng 100 năm qua.

“Thưa quý ngài hội thẩm,
Người bạn tốt nhất mà con người có được trên thế giới này có thể một ngày nào đó hoá ra kẻ thù quay lại chống lại ta. Con cái mà ta nuôi dưỡng với tình yêu thương hết mực rồi có thể là một lũ vô ơn.Những người gần gũi thân thiết ta nhất, những người ta gửi gắm hạnh phúc và danh dự có thể trở thành kẻ phản bội, phụ bạc lòng tin cậy và sự trung thành. Tiền bạc mà con người có được, rồi sẽ mất đi. Nó mất đi đúng vào lúc ta cần đến nó nhất. Tiếng tăm của con người cũng có thể tiêu tan trong phút chốc bởi một hành động một giờ. Những kẻ phủ phục tôn vinh ta khi ta thành đạt có thể sẽ là những kẻ đầu tiên ném đá vào ta khi ta sa cơ lỡ vận.
Duy có một người bạn hoàn toàn không vụ lợi mà con người có được trong thế giới ích kỷ này, người bạn không bao giờ bỏ ta đi, không bao giờ tỏ ra vô ơn hay tráo trở, đó là con chó của ta. Con chó của ta luôn ở bên cạnh ta trong phú quý cũng như trong lúc bần hàn, khi khoẻ mạnh cũng như lúc ốm đau. Nó ngủ yên trên nền đất lạnh, dù đông cắt da cắt thịt hay bão tuyết lấp vùi, miễn sao được cận kề bên chủ là được. Nó hôn bàn tay ta dù khi ta không còn thức ăn gì cho nó. Nó liếm vết thương của ta và những trầy xước mà ta hứng chịu khi ta va chạm với cuộc đời tàn bạo này. Nó canh giấc ngủ của ta như thể ta là một ông hoàng dù ta có là một gã ăn mày. Dù khi ta đã tán gia bại sản, thân bại danh liệt thì vẫn còn con chó trung thành với tình yêu nó dành cho ta như thái dương trên bầu trời.
Nếu chẳng may số phận đá ta ra rìa xã hội, không bạn bè, vô gia cư thì con chó trung thành chỉ xin ta một ân huệ là cho nó được đồng hành, cho nó làm kẻ bảo vệ ta trước hiểm nguy, giúp ta chống lại kẻ thù. Và một khi trò đời hạ màn, thần chết rước linh hồn ta đi để lại thân xác ta trong lòng đất lạnh, thì khi ấy khi tất cả thân bằng quyến thuộc đã phủi tay sau nắm đất cuối cùng và quay đi để sống tiếp cuộc đời của họ. Thì khi ấy còn bên nấm mồ ta con chó cao thượng của ta nằm gục mõm giữa hai chân trước, đôi mắt ướt buồn vẫn mở ra cảnh giác, trung thành và chân thực ngay cả khi ta đã mất rồi.”

Chú chó Ha-chi-ko

Hẳn ai trong chúng ta cũng đã từng nghe tới tên một chú chó rất nổi tiếng đến từ xứ sở hoa anh đào-đất nước mặt trời mọc, chú chó Ha-chi-ko – một biểu tượng về lòng trung thành. Hàng ngày Ha-chi-ko vẫn kiên trì chờ đợi người chủ của mình ở trước sân ga cho dù người chủ của nó sẽ không bao giờ còn về nhà đúng hẹn nữa…

Câu chuyện cảm động đó khiến chúng ta có nhiều suy nghĩ. Những gì mà vị luật sư kia bào chữa quả thật đúng đắn. Tôi có tham gia một lớp tư tưởng Hồ Chí Minh, vị giảng viên của chúng tôi có nói về “thuyết nhân-quả” và “nghiệp báo” giữa nhiều kiếp. Việc đối nhân xử thế trong kiếp này có thể sẽ là “nghiệp” của kiếp sau. Tôi chợt nghĩ đến những người thích trò hành hạ súc vật liệu sau này có gặp báo ứng gì không hoặc có thể kiếp sau sẽ “đầu thai” làm con vật để chịu sự hành hạ. Mới đây trên Kenh14.vn có đăng tin về chuyện một khách du lịch khi đến bờ biển Hạ Môn, Phúc Kiến, Trung Quốc, đã tình cờ ghi lại được cảnh một người thanh niên liên tục ném một chú cún tội nghiệp xuống biển chỉ để… cho vui. Chú chó tội nghiệp bị ném xuống nước nhiều quá nên dần kiệt sức và không bơi nổi vào bờ, may mắn là nó đã trèo lên được một tảng đá ở giữa biển. Sau đó, tên thanh niên độc ác bỏ đi và một du khách đã bơi ra phía tảng đá để đưa chú cún vào bờ. Một người phụ nữ tốt bụng đã nhận nuôi chú cún và hứa sẽ mang lại sự an toàn cho nó. Tôi không biết liệu sau này tên thanh niên ấy có gặp quả báo gì không khi đối xử với động vật một cách vô lương tâm như vậy.

Những con vật sinh ra đâu phải chỉ để mua vui, nó còn là một người bạn tri kỉ những lúc vui buồn, ít nhất thì nó luôn biết lằng nghe. Tôi có biết về chuyện một người bà mà tôi quen, bà ấy sống một mình cùng với một chú chó, chồng và con trai đều thất lạc ở bên Nga. Thời gian trước chú chó đã chết, bà quá thương tiếc và thề sau này sẽ không nuôi thêm một con chó nào nữa, đơn giản chỉ vì bà không muốn nhìn thấy cảnh người bạn tri kỉ phải từ biệt bà mà ra đi.

Tôi nhớ hồi tôi còn nhỏ, mẹ tôi có nuôi chó và mèo. Năm tôi học lớp 4, chú mèo mà tôi vô cùng thương yêu và thân thiết đã chết trong một tai nạn, tôi đã khóc nức nở và không ngừng gọi tên nó. Và khi những chú chó con bị ăn phải thức ăn có độc mà chết đi, tôi đã viết cho chúng một bức thư nói rằng tôi nhớ chúng biết bao nhiêu. Sau đó tôi đã đốt bức thư đó đi và hi vọng rằng ở bên kia thế giới, những chú cún của tôi sẽ nhận được lá thư do tôi viết. Tất nhiên đó là những suy nghĩ của trẻ con nhưng chưa bao giờ tôi quên được điều đó. Vì tôi biết trong tôi có những tình cảm rất đẹp và đáng quý, những thứ tình cảm mà có cơ số kẻ không bao giờ có được.

Tôi ước chi khi bạn đọc được bài viết này của tôi, bạn cũng sẽ chợt phát hiện ra mình cũng đã từng có thứ tình cảm đẹp như thế, cũng đã từng vuốt ve một chú chó hay cưng nựng một chú mèo… Và tôi thấy đáng tiếc cho bạn nếu như bạn chạnh lòng khi đã từng đối xử tệ bạc với một con thú nào đó… Hãy tin tôi. Nếu bạn tin vào thuyết nhân-quả thì bạn hãy tin rằng bạn sẽ trở thành cái gì ở kiếp sau nếu như kiếp này bạn không chịu xây dựng những tình cảm đẹp…

/*
*
* Nguồn Một bài học…
*
*/

Bạn học đặt biệt danh “Châu Bò” cho Ngô Bảo Châu

/*
*
* Nguồn Bạn học đặt biệt danh “Châu Bò” cho Ngô Bảo Châu
*
*/

Bạn học đặt biệt danh “Châu Bò” cho Ngô Bảo Châu

Một người bạn học thời nhỏ của GS Ngô Bảo Châu đã gửi bài viết này, với nhiều kỷ niệm và tình tiết đáng nhớ lại và suy nghĩ. VietNamNet xin giới thiệu cùng bạn đọc nhân dịp anh được tặng thương Huy chương Fields.

Tôi đọc “Thi nhân Việt Nam” từ nhỏ, đọc đến những lời cuối thì giật mình. Hoài Thanh và Hoài Chân thật khiêm nhường khi gắn những lời bình của mình vào những tác phẩm lớn. Các ông không muốn mình là những người ăn theo những tên tuổi nổi tiếng. Bài học đó đã khắc ghi trong tôi ngay từ khi bước vào đời. Tôi viết bài này nhân dịp Ngô Bảo Châu được tặng thưởng Huy chương Fields – một giải “Nobel” của Toán học, nhưng là để dâng tặng cho các thầy cô giáo và những người bạn thuở niên thiếu của mình.

Châu “Bò” từng trượt chuyên toán lớp 6

Tôi bắt đầu học cùng Ngô Bảo Châu từ năm 1984 trong lớp chuyên toán Trường THCS Trưng Vương, Hà Nội.

Tất cả chúng tôi chẳng ai gọi bạn ấy là Bảo Châu cả. Châu được gọi là Châu “Bò”. Điều này có lẽ xuất phát từ gia đình. Ông bà của Châu, bác Cẩn, cô Hiền, cậu Hòa đều gọi là Bò.

Những năm đó, sự học có lẽ là đang phát triển ở giai đoạn cực thịnh. Chúng tôi được học các lớp chuyên ngay từ cấp 1. Con trai mà “oách” là phải học chuyên Toán. Hà Nội ngày đó chỉ có 4 quận nên lớp cấp 2 cũng chỉ có 4 lớp chuyên toán, tương ứng với 4 quận.

Thời học chuyên Toán Trưng Vương.

Lớp chuyên toán Trường Trưng Vương đại diện cho quận Hoàn Kiếm tương đối nổi tiếng. Lớp chuyên Toán ngày đó được dìu dắt bởi những nhà giáo xuất sắc, có tâm, có đức và rất giỏi về chuyên môn là các thầy Tôn Thân, thầy Bình và thầy Chiến.

Để vào được lớp, người ta tổ chức các cuộc thi toán hàng năm và lấy điểm từ cao xuống thấp rồi chọn ra khoảng 30 học sinh. Nếu tôi nhớ không nhầm, Châu “Bò” đã không đỗ vào lớp chuyên toán năm lớp 6.

Dạo đó, lớp tôi có những bạn học toán rất thông minh như Việt Anh, Duy Minh… Châu “Bò” gia nhập năm lớp 7. Bạn hòa nhập rất nhanh và ngay lập tức đã khẳng định vị trí số 1 của mình về học toán. Điều này làm chúng tôi tương đối bất ngờ: Một bạn học cấp 1 ở trường thực nghiệm, lớp 6 học lớp “thường” bên cạnh mà sao dám cạnh tranh với học sinh chuyên toán “nhà nòi” như mình.

Trong toán học, mọi thứ thật rõ ràng, bạn chỉ có thể hoặc là “giải được” hoặc “không giải được” một bài toán mà thôi.

Chúng tôi học cùng nhau trên lớp. Môn toán do thầy Tôn Thân trực tiếp giảng dạy. Và còn cùng nhau “học thêm” môn toán, chủ yếu từ thầy Bình (trường Trưng Vương) và thầy Hậu (trường Chu Văn An).

Đích ngắn của chúng tôi lúc đó là đội tuyển thi toán toàn quốc của Thành phố Hà Nội. Thời điểm sau học kỳ 1 năm lớp 8, khoảng sau Tết Âm lịch, mỗi quận sẽ chọn 10 học sinh làm đội tuyển của quận và 4 đội tuyển sẽ thi cùng nhau để chọn ra 12 học sinh (10 chính thức và 2 dự bị) để làm đội tuyển Toán thành phố đi thi toán Toàn quốc.

Đội tuyển quận Hoàn Kiếm của chúng tôi năm đó thật xuất sắc. Các thầy cô đều kỳ vọng sẽ chiếm đa số trong đội tuyển toán thành phố. Nhưng chỉ có Châu và tôi được vào đội tuyển mà thôi. Châu “Bò” thì vô địch dạo đó rồi, còn tôi thì có lẽ cũng là do may mắn.

Châu “Bò” đoạt giải nhất cuộc thi toán toàn quốc.

Ngày 1/6/1986, chúng tôi tham gia lễ trao phần thưởng tại Hội trường Ba Đình. Tôi vẫn nhớ như in, bác Phạm Văn Đồng, mặc dù mắt đã kém vẫn lên tuyên dương các cháu học sinh và trao phần thưởng cho khoảng 20 đại diện học sinh thủ đô.

Túi quà thật đơn sơ. Chỉ vài quyển vở, vài cái bút gói trang trọng trong một túi nilon cỡ trung bình (bây giờ mà mua chắc khoảng 30-40.000 đồng) có thể làm cho bạn nổi tiếng trong cả một khối nhà của khu tập thể Giảng Võ hay Nam Đồng thời bấy giờ.

Thuở niên thiếu của chúng tôi gắn liền với thi cử. Thi để cọ sát, thi để học tập kinh nghiệm, thi để khẳng định mình….và đương nhiên thi để giành giải.

Chuyện thời chuyên Toán A0

Các thành viên của các đội tuyển các tỉnh, thành phố (miền Bắc và miền Trung) sau đó được phép tham gia thi vào lớp chuyên toán Trường ĐH Tổng hợp và ĐH Sư phạm Hà Nội, mỗi lớp khoảng 20 người.

Sự khác biệt, ngoài chuyện học hành, còn cả về chính sách nhà nước. Các bạn tôi, kể cả ở trường “Am” tiêu chuẩn tem phiếu là ND (nhân dân, tức là được 10kg gạo, 1 lạng thịt, 1 lạng đường… 1 tháng.

Còn chúng tôi khi đó đã được coi là SV, tiêu chuẩn tem phiếu hạng E, được 15kg gạo, 0,5 kg thịt, 0,5 kg đường trong 1 tháng… Ôi! Những niềm tự hào nho nhỏ! Thật không thể so sánh được với xe SH hay xế hộp mà các cha mẹ thời nay “đãi ngộ” cho con cái khi chúng đỗ vào lớp cấp 3…

Học là con đường duy nhất của chúng tôi ngày ấy. Mục tiêu của chúng tôi khi ấy cao hơn 1 chút, đó là tham dự đội tuyển Toán Việt Nam đi thi toán quốc tế hoặc chí ít cũng là đỗ đại học điểm cao để đi học nước ngoài.

Chúng tôi học như “điên dại”. Phần thì ngoài việc bản thân đã là “thợ học”, chúng tôi cũng chẳng có game, chẳng có vũ trường, chẳng có internet… như bây giờ.

Tôi còn nhớ thầy Nguyễn Văn Mậu, trước khi đi làm tiến sĩ ở Ba Lan có dạy cho chúng tôi 4 buổi về lượng giác, mỗi buổi 2 tiếng trong mùa hè năm 1986, sau khi đã có kết quả đỗ vào lớp chuyên toán ĐH tổng hợp Hà Nội. Bốn buổi thôi, nhưng là toàn bộ chương trình lượng giác của học sinh THPT trong năm lớp 12.

Lớp phổ thông A0

Học hết lớp 8, chưa vào cấp 3, Châu “Bò” làm bài thi toán đại học năm đó đã được khoảng 8 điểm. Trường ĐH Tổng hợp năm đó đánh ký hiệu cho khoa Toán là chữ A, tức là năm thứ nhất là A1,… năm thứ 5 là A5. Người ta tự hào khi học toán, tự hào khi mình là chữ cái đầu tiên trong bảng chữ cái. Lớp chúng tôi gọi là A0, lớp 10 là A010,…lớp 12 là A012.

Lớp có 21 bạn từ các vùng miền khác nhau của đất nước. Bạn Thương đến từ Hà Tây, bạn Kiên, Hà đến từ Hải Dương, bạn Hài, Hưng đến từ Thái Bình, bạn Thắng đến từ Thanh Hóa, bạn Minh đến từ Bắc Giang…

Học sinh Hà Nội có 5 người là Châu “Bò”, Hà Huy Minh (vẫn gọi là Minh “Khoái” vì bố là GS.TS Hà Huy Khoái, nguyên Viện trưởng Viện Toán học), Nguyễn Thái Dương (Dương “xỉ”), Nguyễn Thanh Hoa và tôi. Trừ Hoa là con gái, còn 4 thằng chúng tôi thì dính vào nhau như hình với bóng. Lớp học nằm ở một nửa khối nhà 5 tầng đặt tại ký túc xá Mễ Trì, Hà Nội. Tầng 1,2 dùng làm ký túc xá cho các bạn học sinh ở tỉnh xa, tầng 3 là phòng thí nghiệm, phòng của các thầy cô giáo…còn học sinh chúng tôi học ở tầng 4, 5…

Những kỷ niệm ăn cơm cặp lồng

Một ngày, chúng tôi học 2 buổi sáng và chiều, buổi trưa nghỉ ăn cơm khoảng 2 tiếng. Những ngày đầu tiên ăn cơm tại bếp ăn tập thể của trường ĐH Tổng hợp quả là những kỷ niệm không bao giờ quên.

Sau khi đưa phiếu ăn, bạn sẽ nhận được cái khay cơm 3 ngăn. Ngăn lớn nhất là một ít cơm màu không trắng, ngăn nhỏ nhất là khoảng 10 hột lạc rang có những chấm trắng li ti của muối bám xung quanh. Ngăn còn lại là nước canh, thường là canh cải với khoảng vài sợi xanh xanh cắt ngắn khoảng nửa cm. Có những thời gian, chúng tôi không thể ăn nổi, chỉ dám hớt một chút cơm phía trên vì bên trong khay còn nguyên mỡ, tóc…

Giám đốc nhà ăn khi đó, được giới thiệu trong buổi tựu trường, là một tiến sĩ về hóa học, được chuyển sang đảm nhiệm việc chế biến thức ăn cho sinh viên… Ở chính giữa nhà ăn là một cái nồi nhôm to, bên trong chứa một thứ dung dịch màu cánh gián. Đó được gọi là nước mắm, để ai nếu thấy cần có thể ra lấy ăn thêm.

 

Từ phải qua trái: Minh “Khoái”, Dương “xỉ”, Hoàng Anh, Châu “bò”.

Bốn đứa con trai Hà Nội chúng tôi quyết định mang cặp lồng cơm cha mẹ chuẩn bị để ăn buổi trưa ở trường. Khẩu phần thường là một cặp lồng cơm to, lèn chặt (khoảng 7,8 bát ăn cơm) 1 quả trứng vịt rán hoặc là ốp lếp và 1 quả cà chua sống ăn thay rau. Chỉ cần ăn như thế thôi, chúng tôi đã được các bạn nội trú gọi là “tư sản”.

Không ở trong ký túc xá đồng nghĩa với việc phải đi học hằng ngày bằng xe đạp. Trung bình, chúng tôi đi 10km đi và 10km về, đi về hướng Hà Đông (nay là đường Nguyễn Trãi). Những ai đã từng đi qua khu Cao Xà Lá ngày đó chắc hẳn không thể nào quên cái mùi đặc trưng của 3 nhà máy ấy trộn lẫn vào nhau.

Chúng tôi đạp xe rất nhanh và điệu nghệ. Châu “Bò” đi xe đạp mipha (xe của Đông Đức cũ). Huy Minh đi xe của Nga, còn tôi và Dương “xỉ” đi xe đạp trong nước. Chúng tôi có thể đạp xe bỏ hai tay từ Ngã Tư Sở đến khu Mễ Trì, vừa đi vừa luồn lách trong dòng xe đạp đông đúc thời bấy giờ.

Nói thêm về chuyện đi học bằng xe đạp, trong lớp tôi có một bạn là Nguyễn Quang Thương, nhà gần khu vực chùa Trăm gian, Hà Tây, tức là cách trường khoảng 25km. Bạn vẫn đạp xe sáng, chiều đi học. Nhưng có nhiều hôm buổi trưa, bạn còn đạp xe về, chiều lại đạp đến lớp. Một ngày, đạp xe 100km đi học, thử hỏi có học sinh nào ngày nay dũng cảm và kiên trì như thế không?

Ăn uống kham khổ, đi lại vất vả nhưng bù lại, chúng tôi được dạy dỗ bởi những thầy cô giáo tuyệt vời. Phần lớn giáo viên đều là giảng viên của ĐH tổng hợp xuống trực tiếp giảng dạy.

Không chỉ riêng môn toán (thầy Hùng môn đại số, thầy Sơn môn Hình học, thầy Điền trưởng khối chuyên toán) mà các thầy cô giáo khác như thầy Việt (môn Địa), thầy Giang (môn Hóa), thầy Vinh (môn Văn lớp 10), cô Hoa (môn Văn lớp 11,12)…đều là những chuẩn mực về sự tận tậm, lòng nhiệt tình, kiến thức uyên thâm truyền dạy cho chúng tôi những bài học thật sâu sắc và bổ ích trong những năm dưới mái trường.

Tôi muốn nhắc tới câu chuyện của thầy Thiệp, dạy môn đại số véc tơ năm lớp 10. Đó là môn học không khó nhưng khá khô khan. Thầy nhiệt tình đến độ, sau khi xong tiết học buổi sáng, thầy yêu cầu lớp trưởng cho xem thời khóa biểu trong tuần trống tiết nào buổi chiều là thầy yêu cầu lên lớp để thầy dạy thêm mà không lấy một xu thù lao nào.

Kỷ niệm ngày 20/11 năm lớp 11, chúng tôi gặp thầy ở văn phòng khối, trông thầy khác lắm. Và đó cũng là lần cuối gặp người thầy giáo tận tâm đến mức không tưởng đó. Thầy ra đi vì là người học và dạy toán, nghĩ đơn thuần là người ta thi nghiên cứu sinh chỉ thi có môn chuyên ngành mà thôi. Thầy đâu có biết rằng để đỗ được nghiên cứu sinh, người ta còn phải thi nhiều môn “xã hội” khác nữa.

Tết Âm lịch năm 1988, Châu “Bò”, Huy Minh và tôi có đến thăm gia đình thầy. Tiếp chúng tôi là người vợ trẻ, một đứa con trai khoảng 4 – 5 tuổi trong một căn phòng rộng 1.5m, dài 5m nguyên là hành lang của một căn biệt thự Pháp cổ. Căn nhà tuềnh toàng, chẳng có gì ngoài sách. Chúng tôi chia sẻ với gia đình thầy những mất mát quá lớn vừa qua. Trước khi chia tay, vợ thầy có nói với chúng tôi một điều là: Cô sẽ không bao giờ cho đứa con của thầy cô đi học….toán nữa.

Người ta cứ nghĩ dân học toán là học kém các môn xã hội khác, như văn chẳng hạn. Điều đó hoàn toàn nhầm. Trong lớp chuyên toán ngày ấy có ít nhất 3 người chẳng sợ môn văn mà còn học giỏi văn là khác. Trong đó có Đào Trung Kiên, Châu “Bò” và có cả tôi nữa. Bài kiểm tra môn văn của chúng tôi thông thường là 8, thậm chí có cả điểm 9 và sẽ khá buồn nếu được 7.

Châu “Bò” làm một bài văn thường mang phong cách của dân học toán, lập luận khúc chiết, chặt chẽ. Kiên “cốp” thì dung dị, chắc chắn còn tôi thì bay bổng, lãng mạn có phần lan man và tự do. Sau này khi lớn lên tôi mới hiểu ra được “Văn chính là Người”. Tính cách của bạn sẽ phản ánh qua cách viết.

Giải trí của chúng tôi ngày đó là chơi bóng đá, chơi cờ vua. Học sinh Hà Nội thì đương nhiên không chơi bóng đá khỏe như các bạn nội trú.

Châu “Bò” chơi được nhưng không khỏe lắm. Dương “xỉ” nhỏ con nhưng chơi rất khéo. Tôi và Huy Minh chơi kém, to xác nên chỉ được làm hậu vệ và thủ môn mà thôi.

Châu “Bò” chơi cờ vua khá tốt, chắc là đứng thứ 2 ở lớp sau 1 bạn tên là Hà người Hải Dương. Âu cũng một phần Hà chơi nhiều hơn, cọ xát nhiều hơn. Nhưng Châu “Bò” có thể chơi được cờ mù, tức là chơi cờ mà không cần nhìn bàn cờ, chỉ dùng trí nhớ mà thôi. Phong cách chơi cờ của Fisher đã thể hiện trong con người của bạn tôi từ năm lớp 11 như thế đó.

“Vô địch toán từ phổ thông”

Nói đến học toán thì Châu “Bò” đã là vô địch từ những năm phổ thông. Cách học thông thường của chúng tôi là thầy giáo giao 1 bài toán và chúng tôi “châu đầu” vào giải. Giải được thì tốt, không giải được thì thầy lại hướng dẫn, gợi ý cho đến khi giải được thì thôi. Bài toán kết thúc khi chúng tôi giải xong.

Bạn tôi thì khác hẳn. Châu “Bò” thường giải xong 1 bài toán và tự đề xuất 1 bài toán khác, lớn hơn và bao quát hơn. Điều này khiến chính các thầy giáo giảng dạy cũng phải ngỡ ngàng. Cách Châu “Bò” học toán đã bỏ xa chúng tôi 1 bậc. Ngay từ năm lớp 10, thầy Nguyễn Minh Đức dạy môn giải tích đã nói với các phụ huynh: Trong vòng 20 năm nay, mới có 2 học sinh thông minh đến thế, đó là Nguyễn Tiến Dũng (hơn chúng tôi 3 tuổi) và Ngô Bảo Châu.

Kỳ thi toán quốc tế năm 1988 diễn ra ở Úc và năm 1989 diễn ra ở CHLB Đức, Châu “Bò” đã mang lại 2 HCV. Cùng năm với chúng tôi, còn có Đinh Tiến Cường, huy chương vàng năm 1989, học chuyên Toán ĐH Sư phạm Hà Nội hiện là GS Toán tại ĐH Paris 6, Pháp, cũng là một trường hợp rất đặc biệt.

Nhà Cường rất nghèo, bố chỉ là người sửa xe đạp rất bình thường. Cường là một minh chứng rõ ràng nhất là: Chỉ trong học tập nói riêng và trong khoa học nói chung người ta mới có sự bình đẳng, không phân biệt giàu nghèo. Trong lớp học mà một đứa trẻ được bố mẹ đưa đi đón về bằng ô tô chưa chắc đã học giỏi hơn đứa trẻ đi bộ đến trường.

Cứ mỗi tháng 8 hàng năm, khi báo đưa tin về những thủ khoa xuất thân từ những hoàn cảnh khó khăn, những gia đình nghèo, tôi lại thấy ầng ậc nước mắt. Nhiều người trong xã hội hiện nay không hiểu chúng tôi là vì thế.

Kết thúc năm học 1989, số phận lại một lần nữa đặt 2 chúng tôi vào cùng một lớp học…ngoại ngữ. Châu “Bò” không xin được vào học toán ở MGU (ĐH Tổng hợp Lomonoxop Matxcova) nên muốn học toán ở Hungary. Còn tôi đi học “Điện tử Bách khoa” ở Hungary. Lúc đó, chúng tôi có hiểu gì đâu, chỉ biết đơn thuần là Hungary là nước “sướng” nhất trong khối XHCN lúc bấy giờ. Nhất là Hung, nhì mới đến Đức, Tiệp, Ba Lan… Trong lớp tiếng Hung có cả Đoàn Hồng Nghĩa, huy chương đồng toán quốc tế 1989.

Học gần nửa năm, tháng 12/1989 những diễn biến chính trị diễn ra dồn dập ở châu Âu. Thể chế thay đổi ở Đức, Tiệp, Ba Lan…làm lưu học sinh chúng tôi hết sức lo lắng. Đó cũng là năm cuối cùng các nước XHCN nhận lưu học sinh Việt Nam, trừ 2 nước là Tiệp và Hungary.

Điều may mắn đã đến với Châu “Bò” khi nhận được học bổng tại Pháp. Nếu không mất một năm học ngoại ngữ tại trường ĐH Ngoại ngữ Hà Nội thì điều hiển nhiên là chúng ta sẽ được thấy các công trình khoa học của Ngô Bảo Châu sớm hơn 1 năm.

Tôi sẽ kết thúc cho phần kể về những năm học phổ thông của chúng tôi bằng những câu chuyện về tình cảm và giải trí của tuổi học trò. Đừng bao giờ nghĩ dân chuyên toán là khô khan và vụng về.

Thời đó, âm nhạc của chúng tôi là những bài nhạc “đỏ”. Nhạc nước ngoài thì có vài ba cái đĩa của những người ở Liên Xô, Đức mang về. Châu “Bò” là người đầu tiên mang nhạc Ý của “To to” Cutugno rồi The Beatle đến cho nhóm tôi nghe. Bạn là người biết cân bằng giữa học tập và giải trí, vừa nghe nhạc vừa học toán chứ không như những trò học “gạo” khác.

Châu “Bò” biết yêu từ lớp 12

Tác giả và Ngô Bảo Châu.

Nói về tình yêu học trò thì Châu “Bò” không phải là “nhân vật” nổi tiếng. Ngoài một số bạn trong lớp đã biết đến những rung động đầu đời, tôi muốn nhắc đến bạn Huy Minh. Huy Minh trắng trẻo, hiền lành, khôi ngô như một đứa trẻ, cả ngay khi tôi gặp bạn cách đây vài ngày trong buổi họp lớp, khi bạn đã 38 tuổi.

Đầu năm học lớp 12, Huy Minh thích một cô gái hàng xóm, kém vài tuổi, học chuyên Sinh Trường Ams Hà Nội. Bạn tôi có viết một lá thư tỏ tình, đại ý là em hãy là hình vuông của anh, em hãy là hình tròn của anh…. Cô bé kia viết lại cho bạn tôi “Hình vuông thì mãi là hình vuông, hình tròn mãi mãi là hình tròn, em không thể…”

Nhưng chắc chắn là Châu “Bò” biết “yêu” từ năm lớp 12. Mà cũng chẳng phải ai xa lạ, người trong tim và sau này Châu “Bò” lấy làm vợ chính là bạn Bảo Thanh, cũng là bạn học của chúng tôi từ hồi học chuyên Toán Trưng Vương.

Thanh rất xinh, da trắng như trứng gà bóc. Hai người bạn đến với nhau từ khi nào tôi không rõ. Đến cả sau khi cưới, 2 bạn tôi vẫn xưng hô là “mày, tao”, dễ thương như hồi học cấp 2.

Tôi cũng đồ rằng, có lẽ, lúc đi luyện thi toán toàn quốc, thầy Tôn Thân có giao cho Bảo Thanh chép bài hộ Châu “Bò” những môn học cậu ấy vắng mặt, đã giúp hai người có những ấn tượng ban đầu về nhau và trải qua năm tháng, một câu chuyện tình yêu kết thúc có hậu đã xảy ra. Châu “Bò” và Bảo Thanh làm đám cưới năm cả 2 người mới 22 tuổi, nay gia đình hạnh phúc đó đã có 3 cô con gái xinh xắn.

Tôi cũng không biết nhiều về thời gian Châu “Bò” học và làm Tiến sỹ ở Pháp. Chỉ biết, đó là một quãng đời rất khó khăn. Bạn còn trẻ lại lập gia đình và có con sớm, học bổng không nhiều lại sống ở một thành phố đắt đỏ nhất thế giới. Châu “Bò” phải ở nhờ trong nhà của vị giáo sư người Pháp. Năm 2004, sau khi được giải thưởng của Viện Clay, Hoa Kỳ cùng 50% số tiền thưởng đi kèm với giải, Châu “Bò” mới có đủ tiền để mua nhà riêng và cuộc sống cũng bớt phần khó khăn.

**************

Thời gian này báo chí, truyền hình cũng đưa tin về Châu “Bò” rất nhiều. Rồi quan chức thăm hỏi, mời Châu “Bò” làm công tác quản lý, đề xuất chế độ đãi ngộ, tặng biệt thự…làm tôi bật cười. Châu “Bò” là một người đa tài, có thể làm việc ở nhiều vị trí khác nhau. Việc Châu “Bò” dành thời gian cho giảng dạy cho các khóa đào tạo Toán tại Trường ĐH Sư phạm Hà Nội hàng năm chứng tỏ một trái tim luôn hướng về Tổ quốc.

Đã có rất nhiều học sinh đi thi toán quốc tế, nhiều tiến sỹ toán nay đã chuyển sang làm các công việc kinh doanh, các công tác quản lý. Đại đa số họ đều thành công, nhiều người đã là những doanh nhân hay những cán bộ cấp cao. Nhưng nhiều người trong số họ đã tâm sự rất thật với tôi là: Phép toán mà họ sử dụng chủ yếu bây giờ là cộng trừ nhân chia. Cộng và nhân thì làm còn đúng nhưng trừ và chia thì hay làm sai lắm!

Châu “Bò” muốn làm toán hay muốn làm cộng trừ nhân chia?

Viết trước một chuyến đi chơi xa.
Hà Nội, ngày 18/8/2010

    • Nguyễn Hoàng Anh

Theo Vietnamnet

/*
*
* Nguồn Bạn học đặt biệt danh “Châu Bò” cho Ngô Bảo Châu
*
*/

Project [N] – Những bài học từ một dự án phần mềm

/*
*
* Nguồn Những bài học từ một dự án phần mềm
*
*/

Đây là một câu chuyện có thật về một dự án phần mềm trải qua 4 năm và tiêu tốn 35 triệu USD mà không đem lại kết quả nào, và có kế hoạch kéo dài thêm ít nhất là 4 năm nữa.

Dự án này diễn ra tại một công ty sản xuất dụng cụ thể thao vào hàng đầu trên thế giới, doanh thu khoảng hơn chục tỷ USD một năm, có trụ sở tại Tây Bắc Mỹ, tạm gọi là công ty N.

Trên phương diện là một study case, đây là một dự án khá độc đáo, và có thể dùng làm bài học điển hình về nhiều khía cạnh khác nhau của một dự án phần mềm, nhất là dành cho các doanh nghiệp sản xuất, dịch vụ đang có ý định ứng dụng công nghệ thông tin vào quy trình sản xuất và hoạt động của mình. Bài viết này hướng tới các đối tượng là Giám đốc Công nghệ Thông tin của doanh nghiệp (CIO – Chief Information Technology Officer), Quản trị Dự án (Project Manager) và Kiến trúc sư phần mềm (Software Architect), và sẽ phân tích qua các khía cạnh sau đây của dự án: Quy trình Quản lý (Management Process), Quy trình phát triển phần mềm (Software Development Process) và Kiến trúc phần mềm (Software Architecture).

Dự án này là một dự án xây dựng một hệ thống enterprise software nhằm mục đích phối hợp (collaborate) hoạt động giữa các bộ phận trong hệ thống sản xuất giày dép (Footwear Production) của công ty N trên khắp thế giới, bao gồm:

• Hệ thống quản lý tài liệu Thiết kế giày dép (Footwear production documents), bao gồm tài liệu, bản vẽ mẫu giày dép, tài liệu về nguyên vật liệu, màu sắc, công nghệ …

• Hệ thống quản lý dự án sản xuất (Project Management) để quản lý các dự án cho từng mẫu giày dép, từ thiết kế qua tới thử nghiệm, sản xuất, tiêu thụ …

• Hệ thống phối hợp hoạt động giữa các bộ phận khác nhau của công ty N, từ Bộ phận Thiết kế mẫu sản phẩm ở Bắc Mỹ đến các Nhà máy sản xuất giày dép đặt tại châu Á và các Nhà cung cấp nguyên vật liệu trên khắp thế giới.
  Bao gồm việc lưu chuyển và quản lý một cách tự động việc đưa mẫu thiết kế từ Bắc Mỹ đến sản xuất thử nghiệm tại châu Á, đến việc thử nghiệm, thu thập thông tin về sản phẩm mẫu, cải tiến, sản xuất chính thức và tiêu thụ, tự động theo dõi hệ thống lưu chuyển nguyên vật liệu và vận tải sản phẩm.

Trước đây, công ty đã có thời kỳ sử dụng mainframe computer và COBOL, sau đó tới thời kỳ sử dụng Power Builder và SAP để quản lý một số phần rất nhỏ trong quy trình sản xuất. Hiện nay, công ty muốn xây dựng một hệ thống hoàn chỉnh, toàn diện với những công nghệ mới hiện nay.

Công nghệ được sử dụng trong dự án là J2EE và Oracle database. Application Server là Apache Webserver kết nối với Tomcat servlet engine. Dự án này không phải được xây dựng hoàn toàn từ đầu (build from scratch), mà dựa trên một enterprise platform khá nổi tiếng trong loại phần mềm PDM/PLM (Product Data Management/Product Lifecycle Management) và Enterprise Collaboration Software, có tên là Windchill. Windchill là một sản phẩm J2EE của công ty PTC (Parametric Technology Corp.), trụ sở chính tại bang Massachusetts, Mỹ [1]. Đây là một phần mềm nền tảng (platform), cung cấp toàn bộ cơ sở hạ tầng và các chức năng căn bản cho một hệ thống enterprise software.

Các công ty sản xuất có nhu cầu xây dựng B2B enterprise software để phối hợp hoạt động giữa các bộ phận khác nhau trong công ty, hoặc với các công ty khác, với các nhà cung cấp và khách hàng thường sẽ ít khi xây dựng từ đầu, mà sẽ mua Windchill (hoặc các sản phẩm tương tự, ví dụ như Matrix One, EDS, SAP, People Soft, IBM Dassault …) về, cải biến và cài đặt thêm (customization) trên platform có sẵn để phù hợp với đặc điểm riêng của doanh nghiệp, và đưa vào sử dụng. Hiện có khoảng hơn 3000 công ty sản xuất lớn trên thế giới đang sử dụng Windchill để điều hành hoạt động của toàn bộ doanh nghiệp, trong đó có nhiều tên tuổi đáng kể như NASA, Boeing, Airbus, Lockheed Martin, Rolls Royce, DaimlerChrysler, Ferrari, Toyota, Bose … Mỗi dự án triển khai Windchill cho một doanh nghiệp kéo dài vào khoảng từ 6 tháng đến 2 năm (Một thời gian tương đối ngắn cho việc triển khai Enterprise Software, bao gồm cài đặt hệ thống, cải biến và cài đặt thêm, performance tuning, administrator training, user training, chạy thử nghiệm và chạy chính thức).[2]

Từ 4 năm nay, Công ty sản xuất hàng thể thao N cố gắng dử dụng Windchill làm nền cho hệ thống enterprise software của mình, và đã chi hơn 35 triệu USD cùng nhiều nhân tài vật lực vào dự án này..

Bộ phận Sản xuất giày dép (Footwear Production) của công ty N có bộ phận IT riêng của mình, nhưng để triển khai dự án, công ty thuê các chuyên gia tư vấn về Công nghệ thông tin để tiến hành. Đây là cách làm việc rất phổ biến ở Mỹ, vì việc phát triển phần mềm hoặc cài đặt các hệ thống mới chỉ mang tính chất thời vụ, nhưng lại đòi hỏi trình độ chuyên môn cao. Mặt khác, khi hệ thống đã hoàn thành, thì việc vận hành và bảo trì chỉ đòi hỏi trình độ chuyên môn tương đối thấp. Vì thế các công ty sản xuất và dịch vụ chỉ duy trì một đội ngũ IT với trình độ vừa phải, lương thấp để bảo trì và vận hành hệ thống, và khi có nhu cầu làm mới, thì sẽ thuê chuyên viên tư vấn với giá cao, nhưng chỉ trong thời gian thực hiện dự án. Cách làm này giúp cho công ty tiết kiệm chi phí hoạt động, và bảo đảm tính chuyên môn hóa cao (Giả sử là công ty thuê được chuyên gia tư vấn tốt, và tổ chức làm việc theo nhóm một cách có hiệu quả).

Trong quản lý dự án, công ty N sử dụng một Quản trị dự án (Project Manager) là nhân viên chính thức của N (Permannent full time employee). Các nhân viên trong Dự án được chia làm ba nhóm chính là Nhóm Chuyên gia sản xuất giày dép (Domain expert – Trong trường hợp này, domain là footwear production, và nhóm còn gọi là Footwear Expert), Nhóm Phân tích Hệ thống kinh doanh (Business System Analyst) và Nhóm Chuyên gia phần mềm (Application Engineer).

Nhóm Chuyên gia sản xuất giày dép là những nhân viên chính thức của công ty N, công việc hàng ngày là thiết kế mẫu giày dép, giao dịch với các nhà máy ở châu Á và công ty cung cấp nguyên vật liệu trên khắp thế giới, là những người sẽ cung cấp thông tin về quy trình, phương pháp và logic làm việc của công việc footwear production cho Dự án.

Nhóm Chuyên gia Phần mềm (Application Engineer) có nhiệm vụ dựa trên những thông tin về quy trình, phương pháp và logic làm việc để xây dựng phần mềm tự động hóa những công việc đó. Trong nhóm này, các vị trí Senior đều là các chuyên viên tư vấn, và ở những vị trí lập trình, có xen lẫn những nhân viên tư vấn có kinh nghiệm và nhân viên chính thức của N.

Trong những dự án phức tạp, đòi hỏi có sự giao tiếp chặt chẽ, chính xác giữa nhóm cung cấp thông tin về sản xuất, dịch vụ với nhóm làm ra phần mềm, thường sẽ có một nhóm trung gian gọi là Nhóm Phân tích Hệ thống sản xuất (Business System Analyst), đóng vai trò trao đổi thông tin giữa Nhóm Domain Expert và Nhóm Application Engineer.

Trong Công nghệ Phần mềm, thông thường những chuyên gia sản xuất, dịch vụ và những Chuyên gia Phần mềm nhìn công việc và hệ thống từ những góc nhìn khác nhau, và sử dụng những thứ ngôn ngữ khác nhau để mô tả về hệ thống. Do đó, những chuyên gia trong nhóm Phân tích Hệ thống sản xuất phải vừa có kiến thức về sản xuất lẫn kiến thức về làm phần mềm (về độ am hiểu chuyên môn sâu thì không cần thiết phải như các nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm, nhưng phải am hiểu các khái niệm cơ bản và thuật ngữ) để có thể làm trung gian giữa hai nhóm. Trong nhóm Phân tích Hệ thống sản xuất có cả chuyên viên tư vấn lẫn nhân viên chính thức của công ty N.

Điểm yếu nhất trong ba nhóm của công ty N là Nhóm Phân tích Hệ thống sản xuất. Nhóm này (hoàn toàn trái ngược với yêu cầu) không có một khái niệm gì cả về sản xuất giày lẫn về sản xuất phần mềm. Điều này làm nảy sinh ra tình trạng hoạt động không hiệu quả trong quy trình quản lý và quy trình làm phần mềm.

Công ty N không có một phương pháp chuẩn (methodology) nào trong việc quản lý dự án phần mềm. Dựa trên quá trình thu thập thông tin, chưa xây dựng thành Use Case, chưa qua phân tích và làm specification, mới chỉ dựa trên một vài mục đích, nhận định, công ty đã đưa ra một số giới hạn về thời gian, nhân lực, ngân sách, mà không có căn cứ cụ thể.

Về mặt quản lý, công ty hoàn toàn không có phương pháp cụ thể về việc phân chia trách nhiệm, quyền hạn giữa các nhóm và các thành viên trong các nhóm. Điều này dẫn đến tình trạng có những lúc công việc bị ách tắc hoặc sai lệch, nhưng không tìm được nguyên nhân chính một cách kịp thời, và không quy được trách nhiệm cho đối tượng nào cần phải sửa chữa hoặc có hình thức xử lý.

Công ty cũng hoàn toàn không có một hệ thống hợp lý để theo dõi quá trình làm việc, theo dõi về ngân sách và tiến độ để có thể điều chỉnh cho phù hợp. Điều này dẫn đến các giai đoạn của dự án thường xuyên bị chậm dead line và vượt quá ngân sách dự tính.

Do không có Phương pháp chính thức (formal methodology) để đánh giá về khả năng, trình độ cũng như tốc độ làm việc của từng nhóm và từng nhân viên trong dự án, và do không có đủ trình độ về Chuyên môn Sản xuất giày dép và Chuyên môn về Công nghệ Phần mềm để có thể nhận định được về năng lực và kết quả làm việc thực sự của nhân viên, nên Quản trị Dự án (Project Manager) và Ban Lãnh đạo Dự án thu thập thông tin bằng cách nói chuyện với nhân viên này trong dự án để tìm hiểu về nhân viên kia, họp với nhóm này để lấy thông tin về nhóm kia trong dự án, và dẫn đến những đánh giá chủ quan, cảm tính và thường không chính xác. Sự đời ở đâu cũng thế, những kẻ nói giỏi và những kẻ hay nói thường là làm ăn không ra gì, và thông tin thường là sai lệch. Vì thế Ban Lãnh đạo Dự án hoàn toàn không có một nhận thức chính xác về trình độ nhân viên, tiến trình của dự án, và không nắm bắt được chi tiết những gì đang thực sự xảy ra trong dự án.

Công ty N thực hiện khâu tổ chức thực hiện dự án một cách hết sức máy móc. Hàng tuần, có những cuộc họp cố định vào thứ hai để báo cáo tiến độ công việc, vào thứ ba để xem xét thiết kế phần mềm và thứ năm để trao đổi thông tin giữa các nhóm Chuyên gia Sản xuất, Chuyên gia Phân tích Hệ thống Sản xuất và Chuyên gia Phần mềm. Ngoài ra còn rất nhiều cuộc họp phụ khác. Một tuần làm việc có 40 tiếng, đã có một vài lần tôi phải tham gia họp 30 tiếng một tuần, và có một vài ngày tôi phải ngồi 6 tiếng trong phòng họp.

Mặc dù có cuộc họp để báo cáo tiến độ công việc, nhưng vì thiếu một phương pháp tốt để theo dõi, phân tích, đánh giá tình hình và phân chia trách nhiệm, nên những cuộc họp này chỉ giúp cho Quản trị Dự án nhận ra những gì đã làm được, những gì còn lâu mới xong, mà không biết tại sao, có cách nào làm nhanh hơn không, đâu là vị trí khó khăn tại thời điểm này của dự án…

Cuộc họp về xem xét thiết kế phần mềm cũng không có tác dụng gì bổ ích mấy, vì công ty N đã tốn 4 năm và chi phí hơn 35 triệu USD để xây dựng một hệ thống phần mềm có nhiều vấn đề về mặt thiết kế (tôi sẽ phân tích kỹ hơn trong phần liên quan tới Kiến trúc phần mềm). Đại khái cũng như trong xây dựng, khi người ta đã vẽ ra một thiết kế có vấn đề và xây nên một vài phần móng có vấn đề, thì việc xây thêm và gia cố cũng khó mà dẫn đến một kiến trúc gì thực sự tốt và có giá trị sử dụng được. Vì thế, các cuộc họp này chỉ nhằm đưa ra những giải pháp chắp vá, tạm thời để tạo ra những chức năng có liệt kê trong danh sách mục đích xây dựng phần mềm.

Nhưng những cuộc họp về trao đổi thông tin giữa các nhóm làm việc mới thực sự là thảm họa. Có một quy định hết sức máy móc là Nhóm Chuyên gia Sản xuất chỉ được nói chuyện với Nhóm Phân tích Hệ thống sản xuất, rồi nhóm này sẽ đi nói lại với Nhóm Chuyên gia Phần mềm. Nhóm Chuyên gia Phần mềm cần hỏi thông tin gì, cũng chỉ được phép nói chuyện với Nhóm Chuyên gia Phân tích, rồi nhóm này sẽ đi hỏi Nhóm Chuyên gia Sản xuất và truyền đạt lại.

Trong khi đó, như đã nói, Nhóm Chuyên gia Phân tích lại bao gồm những người không có khái niệm gì về cả Sản xuất giày lẫn Sản xuất Phần mềm, nên Nhóm Phân tích chỉ đóng vai trò như Nhóm đưa tin giữa hai nhóm Chuyên gia Sản xuất và Chuyên gia Phần mềm. Hơn nữa, do không có trình độ chuyên môn, nên nhóm Phân tích không đọc được Use Case Diagram để trao đổi với nhóm Phần mềm, mà cũng không biết các thuật ngữ như size-range, color-bucket … để nói chuyện với nhóm Sản xuất.
Như vậy, hoàn toàn không có một thứ ngôn ngữ chính xác để trao đổi về mặt phân tích yêu cầu, thu thập thông tin và thiết kế hệ thống cho toàn bộ dự án. Ngoài ra, cách tổ chức trao đổi thông tin cũng kỳ quặc: Trong thứ năm của một tuần, Nhóm Phần mềm họp với Nhóm Phân tích, bàn đi bàn lại một hồi, rút ra là có một số vấn đề sau đây chúng ta chưa biết. Nhóm Phân tích sẽ đem vấn đề đó đi hỏi nhóm Sản xuất vào cuộc họp thứ năm tuần kế tiếp. Và trong cuộc họp ngày thứ năm của tuần tiếp sau nữa, Nhóm Phân tích sẽ đem câu trả lời về cho Nhóm Phần mềm. Như vậy là mất 3 tuần cho một câu hỏi và trả lời, và việc này diễn ra trong 4 năm nay, mặc dù đi bộ từ khu nhà của Nhóm Phần mềm xuống Nhóm Sản xuất mất đúng 3 phút, và tất cả các nhân viên trong dự án đều có điện thoại và e-mail. Đó là chưa kể đến sự thiếu hiểu biết chuyên môn của Nhóm Phân tích dẫn đến việc trình bày sai, thiếu phương pháp ghi chép tài liệu (documentation methodology), nên có những vấn đề phải hỏi đi hỏi lại.

Có hai trường hợp điển hình. Một lần có một chuyên gia phần mềm hỏi “Trong thiết kế mẫu, người ta quản lý cỡ giày như thế nào, theo giá trị chính xác (exact size, nghĩa là từng con số 5,6,7,8,9 ..), hay theo khoảng cỡ (size-range, tức là 5-7, 8-10 , 11-12 …). Sau vài tuần trao đổi đi, trao đổi lại, Nhóm Phân tích không đưa ra được câu trả lời cụ thể. Chuyên gia phần mềm đành phải làm một câu hỏi có nhiều chọn lựa (multi-choice question), gồm có a) Quản lý theo giá trị chính xác, b) Quản lý theo khoảng cỡ, c) Quản lý theo kiểu khác, đề nghị viết rõ, rồi đưa cho Nhóm Phân tích đi hỏi Nhóm Sản xuất, đề nghị khoanh vào a hoặc b hoặc c, thì mới có câu trả lời là a).

Nếu không có quy định quá máy móc là Nhóm Phần mềm không được giao tiếp với Nhóm Sản xuất , hoặc nếu Nhóm Phân tích biết chuyên môn cơ bản và biết sử dụng thuật ngữ, thì tình trạng không đến nỗi thế.

Trường hợp thứ hai là có lần có chuyên gia phần mềm hỏi: “Về mặt quản lý vận tải, trong một lần gửi hàng, có thể có hàng hóa của nhiều đơn đặt hàng được gửi cùng một chuyến hay không?”.

Trước đây công ty N không có hệ thống theo dõi vận tải, mọi giao dịch được làm bằng giấy tờ. Thay vì đi hỏi trực tiếp những người từ trước đến nay vẫn theo dõi việc vận tải bằng sổ sách, Ban Quản trị Dự án họp nhau đoán già đoán non, và cho rằng việc theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải là quá khó (?), nên cho rằng phần mềm chỉ cần theo dõi mỗi chuyến vận tải là một đơn đặt hàng thôi, bất chấp ý kiến của Nhóm Phần mềm là về mặt công nghệ không có gì khó, và ý kiến của Nhóm Sản xuất là trước nay vẫn có nhiều trường hợp một chuyến hàng chứa nhiều đơn đặt hàng. Sau khi Nhóm Phần mềm cài đặt xong Hệ thống theo dõi Đơn đặt hàng và Vận tải, công ty N cử một nhóm 3 người sang châu Á để đưa cho các nhà máy ở châu Á sử dụng thử và thu thập ý kiến phản hồi, thì mới nhận ra là phải làm hệ thống theo dõi nhiều đơn đặt hàng khác nhau trong một chuyến vận tải. Kết quả là toàn bộ công việc trong hai tháng trời phải bỏ đi hoàn toàn, làm lại từ đầu.

Một hiện tượng khác điển hình cho sự thiếu cả Kiến thức lý thuyết lẫn Kinh nghiệm thực tế trong Quản lý Dự án phần mềm của Ban Lãnh đạo Dự án là mỗi khi dự án chậm so với thời hạn, Ban Lãnh đạo Dự án lại thuê thêm lập trình viên vào, nhằm cứu vãn tiến độ công việc. Bất kỳ một nhân viên quản trị dự án phần mềm nào khi mới tập tọng vào nghề cũng phải nghe qua định luật Brooks [3]:

“Thêm người vào một Dự án phần mềm bị chậm thì chỉ làm cho nó chậm hơn.” Định luật này được Brooks chứng minh bằng mô hình toán học một cách chính xác, và đã được kiểm nghiệm qua rất nhiều dự án phần mềm trong thực tế.

Công ty N sử dụng một Quy trình Phát triển phần mềm chuẩn trong Công nghệ Phần mềm là Rational Unified Process (RUP). Hiện tại, trong ngành Công nghệ Phần mềm, đại đa số các Dự án Phần mềm lớn và phức tạp đều sử dụng RUP làm Quy trình Phát triển phần mềm.

Quy trình này gồm có 4 giai đoạn: Khởi đầu (Inception), Dự thảo chi tiết (Elaboration), Thực hiện xây dựng (Construction), Chuyển giao (Transition).

Trình bày chi tiết về Rational Unified Process hoàn toàn không nằm trong khuôn khổ của bài viết này.

Nhưng một quy trình tốt không bảo đảm cho sự thành công của một dự án phần mềm. Phương pháp tiến hành các bước trong các giai đoạn của một dự án là một yếu tố hết sức quan trọng. Trong toàn bộ ba giai đoạn đầu của dự án, công ty N đều phạm phải các sai lầm hết sức cơ bản. Giai đoạn bốn (Transition) chưa bao giờ có, vì chưa bao giờ có sản phẩm chính thức đưa vào sử dụng, nên chưa có sai lầm. Suốt 4 năm từ lúc bắt đầu Dự án cho đến nay, sau khi tiêu tốn hơn 35 triệu USD, công ty N mới đưa ra được một vài kết quả thử nghiệm:

• Hệ thống Quản lý Vật liệu (Material Management). Nghe tên thì như vậy, nhưng thực chất đây là một hệ thống cho phép ghi đối tượng về vật liệu vào database, thêm, xóa, sửa, tìm kiếm …, nghĩa là các chức năng thông thường của một chương trình quản lý cơ bản bất kỳ cái gì.

• Hệ thống Quản lý màu sắc (Color Management) : Đây là một hệ thống cho phép thêm, xóa, sửa, tìm kiếm màu sắc trong database.

• Hệ thống quản lý Dự án (Project Management), thực ra chỉ là một hệ thống tạo thêm, xóa, sửa, tìm kiếm tài liệu cho các dự án, chứ không có quản lý tiến trình (workflow management) và theo dõi tiến độ dự án (project progress tracking), đang trong giai đoạn chạy thử nghiệm và có đầy lỗi.

* Giai đoạn Khởi đầu (Inception) :

Đây là giai đoạn dùng để thu thập thông tin, nhằm đặt ra mục đích và tầm mức của Dự án Phần mềm. Thay vì thu thập trực tiếp thông tin trong thực thế thiết kế và sản xuất giày để xây dựng tầm mức và mục đích, công ty N đã chọn cách thu thập chức năng và mục đích cho chương trình bằng cách sao chép lại toàn bộ chức năng và mục đích của hệ thống phần mềm cũ (legacy system) chạy trên mainframe, hệ thống cũ làm bằng Power Builder và SAP. Đây là một sai lầm hết sức ấu trĩ, vì các legacy system kể trên được xây dựng cách đây hàng chục năm, dựa trên công nghệ hết sức lạc hậu, không thông qua các quy trình thiết kế và phân tích chuẩn cho các hệ thống Hướng đối tượng (Object Oriented), vì thời đó chưa có công nghệ này.
Hơn nữa, quy trình thiết kế và sản xuất giày dép và việc trao đổi thông tin hiện nay đã khác xa so với quy trình hàng chục năm trước, công nghệ sản xuất, phương tiện sản xuất, phương tiện thông tin liên lạc giữa các chi nhánh và quy trình sản xuất đã hoàn toàn thay đổi. Chính vì thế, quyết định về việc xây dựng một hệ thống phần mềm với công nghệ mới để sao chép hoàn toàn chức năng và hoạt động của hệ thống phần mềm cũ đang sẵn có, với rất ít bổ sung, là rất phi lý, thiếu thực tế, và xét cho cùng, nếu vậy thì cứ việc giữ nguyên hệ thống cũ để sử dụng thì còn có giá trị thực tiễn và kinh tế cao hơn.

* Giai đoạn Dự thảo chi tiết (Elaboration):

Trong giai đoạn này, các thông tin thu thập được ở giai đoạn Khởi đầu (Inception) sẽ được đánh giá và phân tích chi tiết, nhằm xác định cụ thể, chính thức về tầm mức của dự án (project’s scope) , các yêu cầu của dự án (project’s requirement), các điều kiện để dự án được coi là hoàn thành (project’s acceptance criteria), các tính năng của dự án (project’s feature) và những tính năng nào là quan trọng (critical criteria), xác định những mạo hiểm có thể xảy ra (potential risk), xác định chi tiết về thực tế sản xuất (business specification) để dẫn tới xây dựng chi tiết về thiết kế phần mềm (design specification) và xây dựng dự thảo cho kiến trúc phần mềm (software architecture). Những công việc hỗ trợ như thiết lập mạng (network), mua bán phần cứng (hardware), phần mềm (software), chuẩn bị quy trình, công cụ cũng được thực hiện trong giai đoạn này.

Một trong những sai lầm căn bản nhất của giai đoạn cụ thể hóa dự án này là Ban Lãnh đạo Dự án đã đánh giá sai thời gian và khối lượng công việc trong việc chuyển đổi database từ các hệ thống cũ (legacy system) dùng mainframe, Power Builder và SAP sang Oracle database của Windchill.

Không hiểu căn cứ vào đâu, dựa trên những tiêu chí nào, vào những phân tích ra sao, mà Ban Lãnh đạo Dự án xác định rằng để chuyển đổi database từ hệ thống cũ sang Windchill’s Oracle database phải tốn ít nhất là 5 năm. Điều này chứng tỏ Ban Lãnh đạo Dự án không có bất kỳ một khái niệm gì về database migration.

Hệ thống cũ chạy Power Builder và SAP cũng dùng Oracle database, nghĩa là hoàn toàn có thể được truy cập từ chương trình Java. Có những dữ liệu được lưu trong những khu vực lưu trữ riêng của Power Builder App và SAP, nhưng đều có những công cụ kết nối (adapter), do đó có thể đọc được từ chương trình Java.

Như vậy công việc chuyển đổi database từ legacy system sang Windchill bao gồm những phần việc sau:

1. Xác định database schema và data format của legacy system.
2. Xây dựng database schema cho hệ thống mới trong Windchill’s Oracle database.
3. Viết một chương trình đọc database từ legacy system và ghi vào Windchill’s database.

Đây là một công việc rất cơ bản, hầu như là lặp đi lặp lại cho tất cả các dự án có chuyển đổi database (database migration). Bất kỳ một Kiến trúc sư Phần mềm (Software Achitect) có kinh nghiệm nào cùng với một nhóm lập trình viên trình độ trung bình có thể hoàn thành những Dự án database migration trong khoảng 6 tháng đến 1 năm. Rất nhiều dự án database migration ở những nhà máy sản xuất máy bay chiến đấu, tàu ngầm hạt nhân, ô tô đua … (là những thứ phức tạp hơn một chiếc giày rất nhiều) được thực hiện với thời gian còn ngắn hơn thế.

Chính vì nhận định sai về thời gian chuyển đổi database, nên Ban Lãnh đạo Dự án đã đề ra một mục đích và tầm mức hết sức kỳ quặc cho dự án.

Dự án sẽ được xây dựng như là một chương trình sử dụng Java, J2EE trên nền Windchill để cung cấp giao diện mới và database mới cho một Hệ thống quản lý sản xuất giày có chức năng giống hệt như Hệ thống cũ viết bằng Power Builder, với một vài chức năng mới không đáng kể, ví dụ như theo dõi Vận tải và Đơn đặt hàng. Phần phối hợp chức năng hoạt động giữa các bộ phận, tạo ra một vài loại đối tượng nhất định, vẫn dùng Hệ thống cũ viết bằng Power Builder và SAP, rồi gửi dữ liệu qua Windchill. Dần dần, sau một thời gian chạy thử vào khoảng 7 đến 10 năm, một hệ thống mới được xây dựng dựa trên Windchill sẽ được đưa vào thay thế hoàn toàn hệ thống cũ.

Sự sai lầm của nhận định về mục đích và tầm mức này là: Windchill đã có sẵn toàn bộ các chức năng để phối hợp hoạt động sản xuất và kinh doanh giữa các bộ phận khác nhau (vì thế nên nó mới được gọi là PDM/PLM và Collaborative enterprise software). Quyết định chỉ dùng Windchill để làm giao diện và lưu trữ dữ liệu, trong khi đó vẫn dùng hệ thống cũ để phối hợp hoạt động (mặc dù công nghệ của hệ thống cũ đã lạc hậu, lỗi thời và không có đủ chức năng) là một quyết định không thể hiểu nổi.

Hơn nữa, theo tiến trình phát triển của công nghệ hiện nay, trong khoảng 7 đến 10 năm nữa, công nghệ đã hoàn toàn thay đổi, những Hệ thống được xây dựng dựa trên J2EE hiện tại sẽ trở nên lỗi thời. Chả lẽ lúc đó lại tiến hành xây dựng một hệ thống mới, trong lúc việc chuyển đổi chức năng, dữ liệu giữa Hệ thống Power Builder + SAP với Hệ thống Windchill hiện nay chưa xong, và sử dụng song song cả 3 hệ thống cho tới 7 hay 10 năm tiếp sau đó nữa?

Những nhận định và kế hoạch nói trên chứng tỏ Ban Lãnh đạo Dự án thiếu thực tế về mặt Sản xuất và không có khái niệm gì về Quản lý và Tiến hành Dự án Phần mềm.

Khâu chuẩn bị vật chất và công cụ cho dự án cũng được tiến hành rất kém. Mạng máy tính của công ty N vào năm 1999 đã bị hacker tấn công một lần, tai tiếng khá lớn, nên công ty trở nên quá đa nghi về an ninh mạng (network security), và do thiếu khả năng, nên đã cài đặt quá nhiều công cụ security tự động lên mạng và các máy tính cá nhân, làm cho mạng máy tính trở nên chậm và kém ổn định. Rất nhiều lập trình viên trong một ngày đẹp trời tự nhiên thấy máy tính của mình bị loại khỏi domain của N network, và phải gọi quản trị mạng để kết nối trở lại. Máy tính được dùng trong hệ thống được mua của một hãng khá danh tiếng, nhưng có lẽ là loại rẻ, dùng cho gia đình, chưa qua test để dùng trong công nghiệp, nên có rất nhiều máy tính bị hỏng, nguy hiểm nhất là hỏng đĩa cứng, và mất toàn bộ dữ liệu.

Về môi trường phát triển phần mềm (software development environment), công ty sử dụng khá nhiều công cụ chuẩn (standard tool) được sử dụng rộng rãi trong Công nghệ Phần mềm ở nhiều công ty khác, nhưng đáng tiếc là lại sử dụng sai, nên phát sinh rất nhiều sự cố trong quá trình phát triển phần mềm. Một ví dụ điển hình là để kiểm soát mã nguồn (source code control) và chia sẻ làm việc theo nhóm, công ty sử dụng ClearCase, một công cụ quản lý mã nguồn rất mạnh của công ty Rational Software. Nhưng đáng tiếc là công ty không thuê đúng chuyên gia cài đặt và định cấu hình ClearCase có đủ trình độ, nên việc quản lý mã nguồn của dự án luôn luôn gặp trục trặc, chương trình không dịch được, hoặc ClearCase view không thể update được là chuyện bình thường.
Chương trình dùng để viết Java code trong Dự án là Eclipse, một opensource IDE rất phổ biến, có nhiều chức năng và công cụ rất mạnh, nhưng do mã nguồn của dự án và từng project được tổ chức trên File System quá phức tạp, nên việc setup Eclipse Project để viết và chạy chương trình đòi hỏi phải qua rất nhiều bước phức tap, và không có chuẩn hóa. Quá trình tạo mẫu đối tượng (object modeling), phát sinh mã nguồn Java cho đối tượng (Java source code generation) và phát sinh lệnh SQL để tạo table trong database (SQL generation) được thực hiện bằng UML diagram trong Rational Rose. Nhưng do không biết cách cài đặt (setup) và định cấu hình (configure), nên mỗi lần thay đổi mô hình (model), các lập trình viên lại trải qua một thời gian dài đau khổ trước khi database hoạt động và chương trình chạy trở lại. Có nhiều lập trình viên đến công ty chơi cả tuần vì máy tính hỏng, không có gì để làm, và cũng không có máy tính để thay thế. Hiện nay, công ty đang thuê một vài nhân viên tư vấn để chuyên nghiên cứu về việc cài đặt môi trường phát triển (setup development enviroment), nhưng tình hình cải biến một cách chậm chạp, mặc dù project đã tiến hành được 4 năm.

* Giai đoạn Thực hiện xây dựng (Construction):

Trong giai đoạn này, sai lầm có tính chất quyết định chính là sai lầm về Kiến trúc phần mềm (Software Architecture). Những sai lầm này sẽ được phân tích chi tiết trong phần Những điểm yếu trong Kiến trúc Phần mềm.

Trong phần này, tôi tập trung phân tích những sai lầm của việc cài đặt phần mềm, nhưng không liên quan đến kiến trúc.

Ban Lãnh đạo Dự án của công ty N chọn quy trình phát triển phần mềm theo mô hình Iterative Development, là một mô hình rất phổ biến trong phát triển phần mềm hiện nay. Nhưng Ban Lãnh đạo Dự án đã hiểu sai toàn bộ ý nghĩa của Iterative Development.

Iterative Development chia quá trình xây dựng phần mềm làm nhiều khoảng thời gian nhỏ gọi là iteration. Trong từng iteration đó, có đủ cả bốn giai đoạn của RUP là Khởi đầu (Inception), Dự thảo chi tiết (Elaboration), Thực hiện xây dựng (Construction) và Chuyển giao (Transition). Toàn bộ Hệ thống phần mềm sẽ được chia nhỏ thành từng chức năng hoặc nhóm chức năng, đủ để thực hiện trong thời gian của một iteration. Trong khoảng thời gian của một iteration, chức năng (hoặc nhóm chức năng) phải hoàn thành sẽ được đưa qua đủ 4 giai đoạn kể trên, và phân tích, thiết kế cho thành phần phần mềm này của Hệ thống có thể được phát triển, thay đổi hoặc đánh giá lại, và kết quả là khi kết thúc mỗi iteration, sẽ có thêm một phần của Dự án được hoàn thành. Trải qua nhiều iteration, cả hệ thống phần mềm sẽ được hoàn thành. Phát triển theo mô hình Iterative Development như thế sẽ cho phép bổ sung thêm thông tin thực tế, thay đổi thiết kế và chỉnh sửa việc cài đặt chức năng cho từng chức năng hoặc nhóm chức năng, mà không làm ảnh hưởng hoặc ảnh hưởng rất ít đến tiến trình của toàn bộ Dự án và các phần khác của Hệ thống.

Nhưng các iteration trong Dự án của công ty N được thực hiện như sau: Cả hệ thống được chia làm nhiều chức năng (hoặc nhóm chức năng) nhỏ. Sau đó, mặc dù việc phân tích mới chỉ qua loa đại khái, chưa có đủ thông tin đã bắt tay ngay vào việc thiết kế và lập trình. Sau khi hoàn thành việc lập trình cho chức năng (hoặc nhóm chức năng) này, bỗng nhiên quá trình thu thập thông tin, phân tích có thêm thông tin, thiết kế thay đổi, thế là lại vứt bỏ toàn bộ từ mô hình đối tượng (object model), Java code cho đến database schema, viết lại từ đầu trong một iteration mới. Kết quả là trải qua nhiều iteration, sẽ có một phần của Dự án được hoàn thành, và thời hạn của Dự án (dead line) thường xuyên bị thay đổi, dời chậm lại. Ban Lãnh đạo Dự án thường nhắc đi nhắc lại mỗi khi bắt đầu một iteration mới là “Chúng ta lùi hai bước để tiến lên ba bước”, nhưng trên thực tế là lùi hai bước và chỉ tiến lên đúng hai bước (vì kết thúc iteration mới, cũng chỉ có chức năng trong iteration cũ được cài đặt lại mà thôi), và quá trình này diễn ra lặp đi lặp lại rất nhiều lần.

Hiện tượng trên xảy ra vì Ban Lãnh đạo Dự án không hiểu ý nghĩa và cách vận dụng của Iterative Development, đồng thời Kiến trúc sư Phần mềm (Software Architect) của Dự án không có tầm nhìn đủ xa và không có đủ kỹ năng để thiết kế mẫu đối tượng (object model) và sử dụng mẫu thiết kế (Design Pattern) một cách tổng quát (generic) và linh hoạt (flexible), để mỗi khi có thay đổi về yêu cầu và thay đổi thông tin, thì không ảnh hưởng đến kiến trúc của hệ thống hoặc ảnh hưởng rất ít. Kiến trúc Hệ thống của công ty N không đạt được tính ổn định, linh hoạt, dễ bảo trì và dễ sử dụng, vì những người thiết kế Hệ thống và Ban Lãnh đạo Dự án đơn thuần chỉ có giải pháp tức thời cho những thông tin trước mắt, không có hoạch định (planning) và tầm nhìn (vision) cho sự thay đổi, mở rộng và phát triển.

Một sai lầm khác không thể hiểu nổi của Ban Lãnh đạo Dự án là thứ tự thực hiện cài đặt phần mềm. Thông thường, các thông tin thực tế trong sản xuất và dịch vụ sẽ được thu thập, phân tích, đánh giá, hệ thống hóa và được viết lại dưới dạng Use Case và vẽ ra Use Case Diagram. Sau khi Use Case và Use Case Diagram được đánh giá là đủ tốt và chính xác vào một thời điểm nhất định của dự án, các lập trình viên sẽ tạo ra các chức năng của chương trình dựa trên Use Case và Use Case Diagram. Trong Dự án của công ty N, các thực tế sản xuất, thông tin thực tế được Nhóm Sản xuất nói cho Nhóm Phân tích, và Nhóm Phân tích nói lại cho Nhóm Phần mềm, thông qua các tài liệu viết bằng tiếng Anh, nhưng không có độ chính xác về thuật ngữ, và các biểu đồ được vẽ một cách tùy tiện với những hình khối tùy tiện, không có cú pháp (syntax) và ngữ nghĩa (semantic) nào chặt chẽ, và cũng không có một Phương pháp Chính thức (formal methodology) nào cho việc trao đổi, ghi nhận và trình bày thông tin.
Nhóm Phần mềm sẽ căn cứ vào những tài liệu này vừa làm, vừa đoán, vừa hỏi, vừa đi họp, sau đó, qua rất nhiều iteration như đã trình bày ở trên, sẽ làm ra một chức năng (hoặc nhóm chức năng) tạm chấp nhận được. Trong thời gian Nhóm Phần mềm làm lập trình qua nhiều iteration, thì Nhóm Phân tích sẽ đi hỏi han cả Nhóm Sản xuất lẫn Nhóm Lập trình để xem thông tin thực tế, yêu cầu và phân tích như thế nào, được lập trình ra sao, sau đó bắt đầu viết Use Case bằng tiếng Anh thông thường và vẽ biểu đồ bằng Visio một cách tùy tiện, sử dụng mũi tên, hình khối và tạo bóng thẩm mỹ một cách bừa bãi chứ không sử dụng UML. Kết quả là mỗi khi Nhóm Phần mềm hoàn thành một iteration Lập trình, thì Nhóm Phân tích cũng cho ra một version của Use Case document nói chung chả ai thèm đọc và chả giúp ích gì cho ai. Có bao nhiêu iteration để lập trình một chức năng thì cũng có bấy nhiêu version của Use Case document, nhưng Use Case được viết ra sau khi đã lập trình xong, không có cú pháp (syntax) và ngữ nghĩa (semantic) chính xác, thì cũng chả có tác dụng gì ngoài việc làm tốn giấy, tốn mực máy in và tốn chỗ lưu trữ trong tủ.

Trong quá trình lập trình cụ thể , do Ban Lãnh đạo Dự án và đội ngũ Kiến trúc sư của Dự án quá kém về chuyên môn, nên xảy ra nhiều chuyện hết sức vô lý và làm chậm đáng kể tiến độ lập trình.

Một ví dụ điển hình là có trường hợp, một lập trình viên cho server code báo cáo là các đối tượng của anh ta làm việc hoàn toàn chính xác với Unit Test (sử dụng JUnit) và với client sử dụng Struts framework, nhưng thông tin không được hiển thị chính xác trên Swing GUI, trong khi cả JUnit, Struts client và Swing client đều sử dụng server code này theo cùng một cách, gọi cùng một tập các hàm API và dùng cùng một lớp trung gian (middleware). Qua rất nhiều tuần, Ban Lãnh đạo Dự án cứ nhất quyết đòi lập trình viên này xem xét tại sao server code của mình không hoạt động tốt với Swing GUI. Điều này chứng tỏ sự dốt nát toàn diện của Ban Lãnh đạo Dự án và Kiến trúc sư phần mềm (Software Architect) về Lập trình Hướng đối tượng căn bản.
Một thành phần phần mềm (software component) hoạt động tốt đối với Unit Test chính là điều chứng tỏ là thành phần này được lập trình đúng theo Chỉ định thiết kế (Design Specification), và thỏa mãn yêu cầu (Requirement). Một bằng chứng khác về sự hoạt động tốt của server code là thành phần này làm việc chính xác với Struts client. Không hiểu do thiếu hiểu biết về lập trình hay vì lý do gì khác, mà Ban Lãnh đạo và Kiến trúc sư phần mềm cứ nhất quyết đòi tìm nguyên nhân không hoạt động trong server code chứ không phải trong Swing GUI code.

Hệ thống phần mềm của công ty N được xây dựng trên nền tảng của Windchill, và sau một thời gian dài nghiên cứu, Ban Quản trị Dự án đã xây dựng nên một sơ đồ kiến trúc như sau:

Đây là một kiến trúc phần mềm nhiều lớp tiêu biểu (a typical muti-layer software architecture). Thực ra thì không cần phải là một kiến trúc sư phần mềm giàu kinh nghiệm mới có thể vẽ được sơ đồ như trên, mà chỉ cần lật một quyển sách Nhập môn Kiến trúc Phần mềm bất kỳ nào cũng có thể thấy những sơ đồ đơn giản kiểu này, thay tên và các mũi tên thích hợp là xong.

Việc thiết kế cụ thể và cài đặt cho từng lớp (layer) cũng như tổ chức giao tiếp giữa các lớp mới là việc quan trọng.

Trong Dự án này, toàn bộ tất cả các dịch vụ cho các phần từ Application Layer, Server Layer cho đến Data Layer đã được cài đặt sẵn trong Windchill foundation. Trong Kiến trúc (Architecture) và cài đặt (Implementation) của Windchill foundation đã có cung cấp toàn bộ những thành phần (component) được liệt kê trong sơ đồ như Service Management, Business Services, System Services, Task Delegate, Windchill Adapter Webject, Command Beans, Command Delegate, Info* Engine, Business Object Model, Naming Service, Directory Server , Persistence layer …

Phần cải biến và thêm chức năng chỉ xảy ra trong phần Client Layer và phần xây dựng mô hình cho các đối tượng kinh doanh (Business Object Modelling).

Thực ra trong sơ đồ của phần Server Layer và Data Layer có hai điểm sai rất căn bản, do Kiến trúc sư Phần mềm (Software Architect) và Lãnh đạo kỹ thuật của Dự án (Technical Lead) trong thời kỳ trước khi tôi tham gia dự án không hiểu rõ về cấu trúc của Windchill, đoán mò và chép sách Nhập môn Thiết kế phần mềm một cách bừa bãi. Thứ nhất là trong Windchill không có cái gọi là Modelled Attributes (Các thuộc tính được mô hình hóa), vì tất cả các Business Object đều được mô hình hóa (model) như là những Java Object, và được sử dụng trong tất cả các lớp (layer) từ Windchill Service đến Presentation. IBA (International Business Attribute) cũng không phải là một component của kiến trúc phần mềm, mà chỉ là một hệ thống công cụ để chuyển đổi giữa các hệ thống đo lường Anh-Mỹ và Quốc tế. Do đó, sẽ không có cái gọi là Modelled Attributes và IBA nằm giữa Command Delegate và Windchill Services. Thứ hai là giữa lớp Windchill Services và Oracle Database còn có một lớp nữa là Persistence Layer, làm nhiệm vụ chuyển đổi giữa Java object và Relational Database (Object-Relational Mapping – ORM), đồng thời đóng vai trò tìm kiếm (query) và thao tác (manipulate) database.

Sai lầm căn bản ngay từ xuất phát điểm của dự án là không sử dụng hết các chức năng sẵn có của Windchill. Hệ thống Windchill đã cung cấp toàn bộ những tính năng cần thiết của một hệ thống PDM/PLM Enterprise Software bao gồm các chức năng cơ bản như Persistence Management, Document Magement, Project Management, LifeCycle Management, Workflow Management, CAD/CAM management, Document and Part versioning, Data Transprotation, Distributed Data Management, Data Replication, Enterprise Security, Access Control, Enterprise Resource Management and Planning … dưới dạng các dịch vụ (service) và framework có thể mở rộng được.

Nhưng Dự án triển khai Windchill ở công ty N chỉ sử dụng một phần rất giới hạn các chức năng của Windchill:

• Chức năng mô hình hóa các đối tượng (object modelling), mô hình hóa các dịch vụ (service modelling), phát sinh mã chương trình Java từ mô hình (Java code generation from model) và phát sinh SQL DML (SQL Data Manipulation Language) từ mô hình (SQL DML generation from model), sử dụng Rational Rose.

• Sử dụng PersistenceLayer chỉ để ghi object vào database, đọc object từ database và xóa object trong database. Không sử dụng được chức năng database query và database manipulation.

• Sử dụng một phần nhỏ của LifeCycle Management để đổi trạng thái (State) của object trong database.

• Sử dụng RMI server của Windchill để làm giao tiếp RMI giữa client và server.

• Sử dụng Windchill configuration cho Apache Webserver, Tomcat và Aphelion LDAP server để dùng một phần nhỏ của Directory Service và Authentication.

Như vậy, các chức năng chính của một enterprise software trong Windchill như object versioning, data transportation, workflow management, built-in business object , advanced query capabilities, data replication, security và access control hoàn toàn không được sử dụng.

Do thiếu hiểu biết về kiến trúc và các chức năng của Windchill, nên khi cần có những chức năng rất sơ đẳng và cơ bản, Nhóm Phần mềm của Dự án phải làm mới từ đầu, phát minh lại rất nhiều bánh xe, và do thiếu hiểu biết, nên những thành phần (component) mới làm việc không được tốt với Windchill foundation, và nhiều thành phần có tốc độ thi hành chậm (slow performance).

Một ví dụ điển hình về phát minh lại bánh xe trong dự án là N Search Framework. Windchill Foundation cung cấp một Persistence Layer rất hoàn chỉnh, với toàn bộ các chức năng về database query và database manipulation từ cơ bản đến nâng cao, bao gồm hết toàn bộ các chức năng của SQL’92 và phần mở rộng của Oracle SQL, phiên bản 8i và 9i. Nhưng do hoàn toàn không biết cách sử dụng, Kiến trúc sư Phần mềm (Software Architect) và Ban Lãnh đạo Dự án quyết định xây dựng một cái gọi là N Search Framework, chỉ dùng để tìm kiếm các đối tượng trong database. Từ khi N Search Framework ra đời, mỗi khi cần tìm kiếm mỗi đối tượng trong database, thay vì viết code mất khoảng 5 phút sử dụng Persistence Layer, các lập trình viên phải dùng Rational Rose để tạo mẫu (model) cho 4 loại đối tượng khác nhau, viết 2 lớp đối tượng Search Criteria và Search Result cho client side và viết code cho 4 lớp đối tượng Java ở server side, cập nhật (update) 2 file cấu hình XML (XML configuration), mất ít nhất 1 ngày làm việc (8 tiếng). Việc tìm kiếm đối tượng trong database trở nên phức tạp đến nỗi mỗi khi có một kiểu đối tượng mới, thì phải dành hẳn một lập trình viên làm việc mất mấy ngày để viết code cho việc ghi đối tượng vào database và tìm kiếm đối tượng.

Ngoài ra, hệ thống software của N hoàn toàn không có security và access control, bất kỳ ai sau khi đã qua basic authentication với Webserver có thể thực hiện tất cả mọi lệnh với tất cả các đối tượng trong hệ thống.

Không chỉ thiếu hiểu biết về enterprise software và Windchill, Kiến trúc sư phần mềm (Software Architect) và Ban lãnh đạo Kỹ thuật của Dự án tỏ ra thiếu hiểu biết toàn diện về Phân tích/Thiết kế Hướng đối tượng (Object Oriented Analysis/Design – OOA/OOD) và Lập trình Hướng đối tượng (Object Oriented Programming – OOP).

Về mặt phân tích (Analysis), tất cả những thực thể (entity) tham gia vào quá trình sản xuất trong User Story đều được tạo ra một object tương ứng trong Hệ thống Phần mềm. Điều này là một sai lầm rất sơ đẳng của những học sinh mới học lập trình, vì không phải tất cả các thực thể được kể trong quy trình sản xuất đều là đối tượng trong phần mềm, mà chỉ có một số nhất định là các đối tượng chính (business object), một số là các mối quan hệ giữa các đối tượng (object relationships) và một số chỉ là các thuộc tính của các đối tượng (attributes of objects). Tất nhiên, trong Object Oriented Analysis/Design cũng tương tự như trong Kiến trúc Xây dựng, không có câu trả lời tuyệt đối đúng, mà chỉ có câu trả lời tốt hơn, và nằm trên ranh giới của nghệ thuật (Art) nhiều hơn là nằm trên ranh giới của Kỹ thuật (Engineering). Nhưng trong thu thập thông tin sản xuất, dịch vụ, có thực thể (entity) nào đều quy cả ra là object trong hệ thống phần mềm thì là một sai lầm ấu trĩ không thể tha thứ được.

Sau vài năm, sau khi có khái niệm về mối quan hệ giữa các đối tượng (object relationships) và mối liên kết giữa các đối tượng (object-to-object link), Kiến trúc sư Phần mềm lại tỏ ra hăng hái trong việc tạo ra object-to-object link đến nỗi có nhiều business object được tạo mẫu (model) trong hệ thống như là các link.

Một sai lầm khác trong phân tích (OOA) là không xác định được Tính Tối thiểu Và Đủ trong xây dựng đối tượng.
Một ví dụ về Tính Tối thiểu và Đủ: Giả sử trong một Hệ thống theo dõi Chuyên môn, có một lớp đối tượng là Programmer, thì những thuộc tính mà hệ thống cần phải biết về một Lập trình viên là Tên, Bằng cấp, Trình độ Lập trình, Những kỹ năng chuyên môn, Khả năng đặc biệt, Số năm kinh nghiệm, Quá trình làm việc (Tùy theo hệ thống theo dõi Chuyên môn, có thể có một vài thuộc tính nữa, nhưng với mục đích ví dụ, tôi giới hạn ở các thuộc tính đề cập ở trên). Tất nhiên, ông lập trình viên A có thể khác ông lập trình viên B ở chỗ ông thì béo, ông thì gầy, ông này là người Ấn Độ còn ông kia là người Mỹ, ông thì lái xe màu đỏ, ông thì lái xe màu xanh… Nhưng những thuộc tính như Béo-Gầy, Ấn Độ – Mỹ – Xe màu đỏ – Xe màu xanh … không phải là những thuộc tính tiêu biểu cho việc theo dõi Chuyên môn , nên không được lưu trữ trong lớp Programmer (Nhưng để mục đích theo dõi cá nhân, có thể được lưu trữ trong lớp đối tượng Employee, nếu có). Như vậy, tập các thuộc tính Tối thiểu và Đủ cho lớp Programmer là (Tên, Bằng cấp, Trình độ Lập trình, Những kỹ năng chuyên môn, Khả năng đặc biệt, Số năm kinh nghiệm, Quá trình làm việc ). Nhưng do không xác định được tính Tối thiểu và Đủ, nên các đối tượng trong dự án N thường có những thuộc tính chồng chéo, có trong nhiều lớp đối tượng có quan hệ với nhau, tham khảo lòng vòng giữa các đối tượng, và có nhiều thuộc tính đặt sai vị trí. Ví dụ về thuộc tính đặt sai vị trí: trong ví dụ ngoài lề ở trên, thuộc tính về quốc tịch không đặt trong lớp Employee, mà đặt trong lớp Programmer.

Một sai lầm thô thiển khác là không phân biệt được lớp đối tượng (object class) và một thể hiện của đối tượng (object instance). Ví dụ khi ta nói đến xe ô tô, tức là ta nói đến một lớp (class) các xe ô tô nói chung, và khi ta nói đến chiếc ô tô BMW có biển đăng ký XYZ 123, tức là ta nói đến một chiếc xe chính xác và cụ thể, là thể hiện (instance) của lớp đối tượng ô tô. Chính vì không phân biệt được các khái niệm class và instance, trong Hệ thống Phần mềm của công ty N có những trường hợp đặc biệt ấu trĩ như:

• Trong hệ thống có các lớp đối tượng (class) And, lớp đối tượng Or, lớp đối tượng Xor, lớp đối tượng Not, có các thuộc tính giống hệt nhau. Đúng ra, tất cả các vật thể (entity) And, Or, Xor, Not kể trên đều thuộc về một lớp đối tượng (class) gọi là Toán tử (Operator), và chúng chỉ là những thể hiện (instance) có tên khác nhau là And, Or, Xor, Not.

• Trong hệ thống có những lớp đối tượng như Mũi giày, Đế giày, Dây giày, Thân giày … Đúng ra tất cả những vật thể (entity) kể trên đều thuộc về một lớp đối tượng gọi là Chi tiết Giày (ShoePart) và có các tên gọi khác nhau.

Một chiếc máy bay có hàng chục triệu chi tiết khác nhau, và nếu Hệ thống Phần mềm cho Sản xuất máy bay ở Boeing, Airbus hay Lockheed Martin được cài đặt theo phân tích và thiết kế như ở công ty N, thì Hệ thống phải có hàng chục triệu kiểu đối tượng (object type), và chỉ để viết code cơ bản cho các đối tượng cũng phải mất vài nghìn năm, chưa nói đến chuyện viết code cho cả hệ thống.

Công nghệ Hướng đối tượng (Object Oriented Technology) có ưu điểm là có công cụ để xây dựng được các thành phần (component) có tính sử dụng lại (reuse) cao, dễ bảo trì (easy to maintain), dễ phát triển, mở rộng (easy to extend). Nhưng tính sử dụng lại (reuse), dễ bảo trì (easy to maintain) và dễ phát triển, mở rộng (easy to extend) của các thành phần không phải tự nhiên mà có, mà phải thông qua một quá trình phân tích kỹ lưỡng, và phải được thiết kế một cách hợp lý, có tính toán sâu sắc và tầm nhìn xa. Điều này phụ thuộc vào quy trình, phương pháp làm việc và trình độ của Kiến trúc sư phần mềm, chứ không phải là điều sẵn có của Công nghệ Hướng đối tượng.

Có vẻ như Kiến trúc sư phần mềm (Software Architect) và Lãnh đạo Kỹ thuật trong dự án của công ty N chỉ biết đến những từ ngữ reuse, extensible qua sách Nhập môn Lập trình, chứ không có kiến thức thực tế, nên mặc dù các thuật ngữ được sử dụng vung vít trong các tài liệu thiết kế và trong các cuộc họp, nhưng hầu như không có thành phần nào trong hệ thống có thể sử dụng lại được, hoặc dễ dàng mở rộng.

Một ví dụ điển hình là khi thiết kế một kiểu đối tượng (object type) để quản lý Vận tải cho Đơn đặt hàng, Ban Lãnh đạo Dự án quyết định là để cho kiểu đối tượng ShipmentInfo có thể sử dụng được (reuse) cho việc quản lý gửi hàng cho nhiều loại đối tượng khác nhau, không chỉ riêng cho Đơn đặt hàng, trong đối tượng ShipmentInfo sẽ không có thông tin gì về Đơn đặt hàng trong đó.

Thế nhưng ShipmentInfo là đối tượng để quản lý Vận tải, tức là phải có nội dung về hàng hóa được giửi trong chuyến gửi hàng đó. Thông tin về gửi hàng mà không nói lên cái gì được gửi thì sẽ được sử dụng vào đâu? Sau một thời gian họp hành khá lâu, Ban Lãnh đạo Dự án mới nhận ra điều hiển nhiên này. Thay vì dùng một kiểu giao diện tổng quát (generic interface) gọi là ShipmentContent để chứa thông tin về nội dung được gửi trong ShipmentInfo, và cài đặt những đối tượng cụ thể được gửi trong Hóa đơn Vận tải như Đơn đặt hàng, Mẫu tiếp thị , Hàng bán Chính thức như là một implementation của interface ShipmentContent, do đó ShipmentInfo có thể sử dụng lại để quản lý Vận tải cho tất cả các lớp đối tượng có cài đặt (implement) ShipmentContent interface, thì Kiến trúc sư phần mềm và Ban Lãnh đạo quyết định dùng rất nhiều liên kết (link) lòng vòng để diễn tả thông tin và các mối quan hệ giữa một Hóa đơn Vận tải, Hàng được gửi và Địa chỉ gửi hàng, làm tăng đáng kể độ phức tạp của các thao tác căn bản, lẽ ra phải rất đơn giản như ghi Hóa đơn và Đơn đặt hàng vào database và đọc Hóa đơn và Đơn đặt hàng từ database. Và cuối cùng, thực ra do mối liên kết thông qua các link còn phức tạp và có mối ràng buộc cao hơn, nên đối tượng ShipmentInfo cũng chẳng reuse được vào đâu.

Việc thiết kế các kiểu đối tượng một cách bừa bãi, mỗi kiểu đối tượng tương ứng với một thực thể trong thực tế, không có phân loại các đối tượng có cùng nhóm chức năng, cùng có giao diện chung, làm cho mỗi kiểu đối tượng chỉ dùng được cho một trường hợp cụ thể trong Hệ thống, không có tính sử dụng lại (reuse), và mỗi lần cần mở rộng, bổ sung chức năng thì chỉ có mỗi cách mở file Java code ra viết lại.

Trong Thiết kế Hướng đối tượng (OOD), Kiến trúc sư Phần mềm (Software Architect) và Ban Lãnh đạo Dự án tỏ ra có một sự hiểu biết rất nông cạn và ấu trĩ. Số lượng các Mẫu thiết kế (Design Pattern) được áp dụng vào dự án rất hạn chế, và thường là áp dụng sai, mặc dù với yêu cầu và đặc điểm của dự án, thiết kế hệ thống hoàn toàn rơi vào đại đa số các trường hợp điển hình để áp dụng Mẫu thiết kế cơ bản (Basic Design Pattern) và Mẫu thiết kế J2EE (J2EE Design Pattern).

Có duy nhất hai trường hợp áp dụng được Design Pattern một cách tương đối là Business Delegate và Singleton Design Pattern, nhưng đó là do có ví dụ sẵn trong Windchill foundation [4]. Trong Windchill foundation còn có nhiều ví dụ khác về áp dụng Design Pattern, nhưng do thiếu kiến thức về Windchill và không đọc Windchill document cũng như Windchill code, nên thiết kế của Dự án không áp dụng được gì.

Trong khi đó, những ví dụ về áp dụng sai Design Pattern thì nhiều không kể xiết. Sai lầm cơ bản đầu tiên phải kể đến là áp dụng sai MVC Design Pattern [5], một design pattern rất căn bản mà bất kỳ ai học nhập môn Lập trình Hướng đối tượng cũng phải biết. Mục đích chính của MVC Design Pattern là nhằm để tách biệt dữ liệu (data) và phần hiển thị dữ liệu (view). Như vậy, trong đối tượng lưu trữ dữ liệu sẽ không có logic về mặt hiển thị (presentation logic), và các đối tượng hiển thị dữ liệu (view) chủ yếu là sử dụng các getters của đối tượng dữ liệu (model) để lấy thông tin cần hiển thị. Trong khi đó, trong Dự án, các đối tượng tạm gọi là Client Object lại có chứa các chức năng về hiển thị, như việc notify các GUI component về việc thay đổi giá trị và một vài chức năng khác, do đó, các đối tượng View và Model bị phụ thuộc rất chặt chẽ vào nhau.

Do sử dụng sai MVC Design Pattern, chèn logic hiển thị vào đối tượng mang dữ liệu, nên các đối tượng mang dữ liệu để hiển thị khác với business object được tạo ra và lưu trữ trong database. Như vậy, trong hệ thống có hai loại đối tượng để biểu diễn cho cùng một dữ liệu là Client Object và Business Object (ví dụ, để biểu diễn mẫu giày, ta có ClientShoe và BusinessShoe, ClientShoe được sử dụng ở client side và BusinessShoe được sử dụng ở server side).

Do đó, khi cần hiện thông tin về business object (ví dụ như Mẫu giày hay Đơn đặt hàng), cần phải có một quá trình chuyển đổi từ Business Object sang Client Object. Trong tất cả các phần của Dự án, mỗi khi cần ghi một Business Object được tạo ra từ Client GUI vào database, thì chỉ tốn khoảng 4 dòng code để ghi Business Object vào database, kể cả khởi tạo transaction, nhưng phải tốn kèm vào đó khoảng 100 dòng code để copy các thuộc tính từ Client Object sang Business Object (Đây là đã có cải tiến sau khi loại bỏ Data Transfer Object).

Do có nhu cầu gửi thông tin giữa các lớp (layer) khác nhau của Hệ thống, Kiến trúc sư Phần mềm của Dự án nảy sinh ra ý định sử dụng một Design Pattern rất cơ bản là Data Transfer Object (DTO). DTO Design Pattern đúng là được sử dụng để truyền thông tin giữa các lớp (layer) khác nhau của một hệ thống phần mềm nhiều lớp (multi-layer system), nhưng chỉ dùng trong những trường hợp sau đây:

• Dùng để gửi nhiều thông tin rời rạc trong cùng một lần gửi. (Ví dụ như để gửi username và password từ cửa sổ login tới authentication service để kiểm tra, thay vì gửi hai String riêng biệt username và password, mất hai lần communication qua các layer, chương trình sẽ đóng gói username và password thành thuộc tính của một đối tượng là AuthenticationInfo và gửi đối tượng này đi, như vậy chỉ tốn một lần communication).

• Dùng để làm giảm số lần giao tiếp từ xa (remote request) trên mạng. Nhiều thông tin (nhiều thuộc tính hoặc nhiều đối tượng) sẽ được đóng gói vào trong một đối tượng là Data Transfer Object và gửi qua các thành phần phân tán (distributed component) trên mạng, do đó làm giảm số lần trao đổi qua lại trên mạng, làm giảm network traffic và tăng application performance. Ví dụ như client có yêu cầu cần biết về Đơn đặt hàng (Sample Request) và Thông tin Vận tải (ShipmentInfo) của Đơn đặt hàng, thay vì gửi Sample Request và ShipmentInfo trong hai lần gọi API qua mạng, thì hệ thống sẽ đóng gói Sample Request và ShipmentInfo vào trong một DTO object và gửi trong một lần gọi API qua mạng. (Đáng tiếc là hệ thống tại công ty N không được thiết kế như vậy).

Trong dự án tại công ty N, DTO Design Patter được sử dụng như sau: Bởi vì có hai loại đối tượng khác nhau biểu diễn cho cùng một dữ liệu là Client Object ở client side và Business Object ở server side, nên để truyền dữ liệu từ client side đến server side và ngược lại, hệ thống sẽ sử dụng một loại đối tượng thứ ba gọi là Data Transfer Object (DTO).

Như vậy, trong hệ thống, tương ứng với mỗi loại dữ liệu sẽ có 3 loại đối tượng khác nhau là Client Object ở client side, Business Object ở server side và DTO Object dùng để gửi thông tin giữa client và server. Ví dụ một mẫu giày sẽ có ClientShoe, BusinessShoe và DTOShoe.

Quá trình ghi một mẫu giày được thiết kế từ GUI vào database sẽ được tiến hành như sau:

• Tại client side: Copy các thuộc tính (attributes) từ ClientShoe vào DTOShoe.

• Gửi DTOShoe tới server.

• Tại server side: Copy các thuộc tính từ DTOShoe vào BusinessShoe.

• Ghi BusinessShoe vào database.

Việc áp dụng DTO Design Pattern ở đây không làm giảm số lượng các thông tin rời rạc được gửi từ client tới server, vì thông tin trong ClientShoe và DTOShoe về mặt cơ bản là như nhau. DTO trong trường hợp này cũng không làm giảm số lần communication qua mạng, vì dù gửi ClientShoe hay gửi DTOShoe từ Client đến server cũng tốn một lần gửi một đối tượng.

Ngược lại, áp dụng DTO như trình bày ở trên tăng thêm 100 dòng code để copy các thuộc tính từ ClientShoe sang DTOShoe và 100 dòng code để copy từ DTOShoe sang BusinessShoe.

Sau 4 năm tìm tòi, nghiên cứu một cách cần cù và gian khổ, có lẽ nhận ra sự ngu xuẩn của việc áp dụng DTO Design Pattern một cách sai lầm của mình, Kiến trúc sư Phần mềm và Ban Lãnh đạo Dự án quyết định loại bỏ DTO Object, và gửi thẳng Client Object đến server side để copy sang Business Object. Việc làm này được Ban Lãnh đạo Dự án đánh giá như một phát kiến vĩ đại, một bước đột phá để tăng năng suất lập trình (Programming Productivity), vì cho mỗi kiểu đối tượng, bớt đi được 100 dòng code phải viết, và tăng tốc độ thi hành chương trình (Program Performance), vì bớt đi 100 dòng code phải thi hành.

Nhưng bỏ DTO đi thì lại phát sinh ra một vấn đề mới là lúc này ClientObject có mang client code và logic hiển thị (presentation logic) được gửi tới server code, mà xuyên qua rất nhiều layer, đến tận Persistence Layer. Điều này đã phá vỡ hoàn toàn sự linh hoạt (flexibility) của một kiến trúc phần mềm nhiều lớp (multi-layer architecture), và làm cho client và server bị ràng buộc chặt chẽ (tightly-coupled) vào nhau. Một thay đổi nhỏ trong client code cũng sẽ dẫn đến thay đổi trong rất nhiều lớp của server code, từ business layer đến persistence layer và trong rất nhiều trường hợp, thậm chí thay đổi cả database schema. Thiết kế thiên tài này của công ty N đã đưa chúng ta về lại những năm 70 của thế kỷ 20 với kiến trúc phần mềm 2 lớp (2-tier) client-server, Lập trình có cấu trúc (Structural Programming) và gọi hàm từ xa (Remote Procedure Call).

Đồng thời sự phụ thuộc của server vào client code thông qua việc sử dụng Client Object trong server code làm cho trong rất nhiều trường hợp, việc phát triển song song server code và client code không thể thực hiện được, vì lập trình viên cho server code phải ngồi chơi, chờ đến khi lập trình viên cho client code hoàn thành việc lập trình cho Client Object. Do sự quản lý yếu kém và thiếu phối hợp trong Dự án, có nhiều trường hợp, lập trình viên cho client code viết code cho cửa sổ, menu và các đối tượng GUI trước khi viết code cho Client Object, và lập trình viên cho server code được hưởng niềm vui là ngồi chờ lâu hơn nữa.

Một Giải pháp tốt cho tình trạng này là thiết kế một Client tốt, tuân thủ chặt chẽ MVC Design Pattern, tức là không có presentation logic trong data model. Như vậy, Business Object sẽ được sử dụng như là một biểu diễn duy nhất cho một loại dữ liệu trong cả hệ thống, từ Persistence Layer tới Business Layer và Presentation Layer. Business Object sẽ được dùng để gửi thông tin về đối tượng giữa các lớp (layer) của hệ thống, và sẽ được dùng làm model trong hệ thống MVC của GUI.

Ngoài ra, do không phân biệt được các Design Patterns Delegate, Template và Strategy, các khái niệm và cài đặt được sử dụng một cách lung tung, bừa bãi và dẫn đến những cài đặt cực kỳ rắc rối, phức tạp (overly complicated implementation), dẫn đến khó bảo trì, phát triển và làm chậm tốc độ chạy chương trình.

Ở trên chỉ là một vài ví dụ trong rất nhiều trường hợp sử dụng sai Design Pattern trong Software Architecture của công ty N.

Hiểu biết về những nguyên tắc căn bản trong Lập trình Hướng đối tượng (OOP Fundamentals) của Ban Lãnh đạo Dự án cũng không khá hơn bao nhiêu so với hiểu biết về OOA/OOD. Những sai lầm về OOP Fundamentals trong dự án có rất nhiều, nhưng tôi chỉ dẫn ra một vài ví dụ điển hình.

Có một khẩu hiệu mà bất kỳ một lập trình viên tập việc nào cũng có đọc qua ít nhất một lần

“Code to interfaces, not code to concrete implementations”, nghĩa là

“Lập trình gọi đến giao diện, chứ không gọi đến các lớp cài đặt cụ thể.”

Mục đích của việc làm này là để tách riêng chức năng (functionality) khỏi các cài đặt cụ thể (implementation). Điều này có nghĩa là các thành phần (component) và các lớp (layer) của một hệ thống phần mềm chỉ giao tiếp với nhau thông qua một hệ thống chức năng/dịch vụ được định nghĩa trước, còn việc cài đặt các chức năng/dịch vụ đó như thế nào thì phụ thuộc vào các lớp cài đặt cụ thể (concrete implementation). Tuy nhiên, các lớp cài đặt cụ thể này không được bộc lộ (expose) ra khỏi component và layer, nên khi cách cài đặt hoặc thuật toán cho chức năng thay đổi, các component và layer khác hoàn toàn không bị ảnh hưởng, hoặc ảnh hưởng rất ít. Điều này làm tăng tính sử dụng lại, dễ bảo trì và dễ phát triển của component và của cả hệ thống. [6]

Nhưng do không biết (hoặc không hiểu) khẩu hiệu này, nên trong Hệ thống của công ty N, mặc dù trong hệ thống có định nghĩa các interface, nhưng các hàm API để giao tiếp giữa các lớp (layer) và các thành phần (component) của hệ thống chủ yếu sử dụng các lớp cụ thể (concrete class) như là tham số (parameters, arguments) và giá trị trả về (return value).

Một sai lầm khác về OOP Fundamentals trong dự án của công ty N là không phân biệt nổi Mở rộng chức năng cho đối tượng bằng Inheritance (Kế thừa) và Mở rộng bằng Composition (tạm dịch là Bao gồm) hoặc Mở rộng bằng Design Pattern (ví dụ Decorator Pattern và Visitor Pattern), do đó, trong tất cả các phần của dự án, việc mở rộng, bổ sung chức năng cho các lớp đối tượng được thực hiện một cách duy nhất bằng Inheritance, tạo ra những họ (family) các lớp đối tượng lớn, các thành viên thực chất chả có liên quan đến nhau mấy, mà chỉ được tạo ra bởi nhu cầu mở rộng chức năng.[7]

Trong một hệ thống enterprise software, XML đóng một vai trò rất quan trọng. Và trong dự án tại công ty N, việc sử dụng XML cũng có nhiều sai lầm, bao gồm cả Lạm dụng XML (Overuse XML) và Sử dụng không hết chức năng của XML (Underuse XML).

Trình bày về chức năng và phương pháp sử dụng XML trong Enterprise Software Development hoàn toàn không nằm trong phạm vi bài viết này. Tôi chỉ xin dẫn ra một vài sai lầm căn bản trong việc sử dụng sai lầm trong dự án tại công ty N.

Một trong những sai lầm nghiêm trọng trong sử dụng XML trong dự án là đa số các file XML được viết trong quá trình phát triển dự án hoàn toàn không có biểu diễn cấu trúc và kiểm tra cấu trúc thông qua DTD (Document Type Definition) hoặc XSD (XM Schema Definition). Điều này dẫn đến tình trạng khá nguy hiểm là cấu trúc của file XML có thể bị thay đổi một cách bừa bãi, và có thể dẫn đến việc hệ thống hoạt động sai, sinh ra các lỗi thi hành (run-time error) nghiêm trọng.

Trường hợp điển hình về việc lạm dụng XML xảy ra trong việc xây dựng một hàm tiện ích ở server side có tên là getServerObject để tìm kiếm một Business Object trong database khi biết kiểu đối tượng ClientObject và Unique Identification của object này vào thời điểm mà hàm API được gọi. Như đã trình bày trong phần trên, cho một kiểu dữ liệu nhất định, có ít nhất hai kiểu đối tượng tương ứng là ClientObject và BusinessObject. Quan hệ giữa ClientObject và ServerObject là quan hệ 1:1, điều này có nghĩa là vào thời điểm hàm getServerObject được gọi, nếu ta biết kiểu đối tượng (object type) của ClientObject, thì có nghĩa là ta cũng biết kiểu của BusinessObject, và chỉ việc gọi lệnh tìm kiếm trong database cho BusinessObject.

Tuy nhiên, theo yêu cầu của Kiến trúc sư Phần mềm (Software Architect) và Ban Lãnh đạo Dự án, nhằm mục đích tăng tính linh hoạt của hệ thống (?), vào lúc gọi hàm getServerObject, mặc dù đã biết rất rõ kiểu của ClientObject, ta phải giả vờ không biết kiểu của BusinessObject, và phải tìm trong một XML mapping file để xem kiểu (type) của BusinessObject là gì, rồi mới gọi lệnh tìm kiếm trong database cho BusinessObject. Ở đây, việc tồn tại của XML file và XML lookup là hoàn toàn thừa và làm giảm tốc độ thực hiện chương trình.

Trường hợp điển hình về không sử dụng hết chức năng của XML nằm trong N Search Framework dùng để tìm kiếm object trong database. Như đã trình bày ở trên, framework này là hoàn toàn thừa, và tạo nhiều rắc rối cho lập trình viên nhiều hơn là tạo công cụ. Framework này không chỉ có vấn đề về mặt chức năng, mà còn có rất nhiều vấn đề về mặt cài đặt. Một trong những vấn đề đó là: Đối với mỗi loại đối tượng (object type) khác nhau, cần phải có rất nhiều loại đối tượng phụ trợ (helper object) đi kèm thì mới thực hiện được việc tìm kiếm. Và riêng về một hàm API phục vụ cho việc tìm kiếm, mỗi loại đối tượng phải có một hàm getObject khác nhau, trong đó sự khác biệt giữa các hàm getObject của các loại đối tượng khác nhau là:

• Thêm các thuộc tính (attribute) làm điều kiện tìm kiếm và cần lấy từ database vào một danh sách các thuộc tính.

• Lấy ra các giá trị (value) của thuộc tính của đối tượng từ kết quả trả về.

Các bước tiến hành khác trong các hàm API getObject này là giống hệt nhau. Như vậy có thể dùng một file XML để lưu các thuộc tính làm điều kiện tìm kiếm và các thuộc tính cần lấy từ database cho từng loại đối tượng. Sau đó viết một hàm getObject cho tất cả các loại đối tượng (object type), trong đó kiểu đối ượng được truyền làm tham số cho hàm getObject, và tại hai phần khác biệt kể trên, chương trình sẽ căn cứ vào tham số object type để phân tích file cấu hình XML và tìm ra những điều kiện tìm kiếm và thuộc tính trả về cho từng loại đối tượng thích hợp. Nhưng đáng tiếc, trong cài đặt của N Search Framework, có hàng chục hàm getObject cho hàng chục kiểu đối tượng khác nhau, trong đó sự khác nhau giữa hàng chục hàm getObject này chỉ nằm ở hai bước có thể dùng XML để định cấu hình (configure) như đã miêu tả ở trên. Với đà phát triển hiện nay của dự án, số lượng các kiều object (object type) hoàn toàn có thể lên tới hàng nghìn, và sẽ có hàng nghìn hàm getObject đòi hỏi phải có sự bảo trì và sửa đổi mỗi khi có một sửa đổi trong thiết kế hoặc từ thực tế sản xuất.

Còn rất nhiều những sai lầm trong phân tích và thiết kế hệ thống cũng như việc thực hiện dự án, nhưng khuôn khổ bài viết có hạn, hơn nữa, những sai lầm còn lại mặc dù có những sai lầm nghiêm trọng nhưng không có tính điển hình, và phần nhiều là hệ quả của sự thiếu kiến thức, kinh nghiệm và những sai lầm đã có phân tích, vì thế tôi không đề cập tới.

Một quy trình tốt, được thực hiện đủ tất cả các bước không bảo đảm cho sự thành công của một Dự án phần mềm. Quy trình được sử dụng trong Dự án của công ty N là Rational Unified Process, một quy trình chuẩn công nghiệp được sử dụng rộng rãi trong phát triển phần mềm, nhưng do chi tiết thực hiện từng bước sai, nên không đem lại kết quả.

Sử dụng những công nghệ tốt, theo chuẩn công nghiệp không bảo đảm cho sự thành công của một Dự án phần mềm. Công nghệ được sử dụng trong Dự án của công ty N là J2EE và Oracle database, là những công nghệ tốt nhất hiện nay cho Enterprise Software, có chuẩn công nghiệp và chi tiết kỹ thuật (Technical Specification) rõ ràng, với đầy đủ các công cụ (tool) và tiện ích (utility) để phát triển. Nhưng do sử dụng không có phương pháp, nên kết quả vẫn là phần mềm chắp vá, kém chất lượng, không sử dụng được.

Những công cụ lập trình và phần mềm tiện ích tốt cũng không đảm bảo cho sự thành công của một dự án phần mềm. Các công cụ được sử dụng trong dự án như ClearCase,Rational Rose, Eclipse, Aphelion, Apache, Tomcat … đều là những công cụ đã được thử thách và chứng tỏ là tốt trong Công nghệ Phần mềm. Nhưng do sử dụng không đúng, nên không giúp ích được nhiều cho quá trình làm việc, và không tạo ra được sản phẩm tốt

Con người chính là khâu quan trọng nhất trong một Dự án Phần mềm. Chính vì Ban Lãnh đạo Dự án và Kiến trúc sư Phần mềm của Dự án không có đủ năng lực để quản lý, thiết kế và thi hành Dự án, nên Dự án mới dẫn đến tình trạng như đã trình bày trong bài viết.

Khi bắt tay vào việc tiến hành một Hệ thống Phần mềm, việc đầu tiên là phải tìm được một đội ngũ nhân sự có trình độ thích hợp với quy mô và độ phức tạp dự tính sẽ có của Dự án, sau đó mới tiến hành thu thập thông tin, phân tích thiết kế và thực hiện.

Thực ra, phần chuẩn bị Nhân sự chính là phần khó khăn nhất của một Dự án phần mềm, vì nhiều công ty sản xuất và dịch vụ không có sẵn chuyên gia và nhân viên kỹ thuật có trình độ Phần mềm cao để có thể phỏng vấn và tuyển người cho Dự án. Ngay cả khi công ty sản xuất và dịch vụ có bộ phận IT riêng, thì những người trong các bộ phận này thường không có trình độ cao, vì yêu cầu công việc thường xuyên hàng ngày không đòi hỏi nhân viên phải có trình độ chuyên môn cao. Hơn nữa, khi khởi đầu việc tuyển người cho bộ phận IT nội bộ, có rất nhiều khả năng là công ty sản xuấtvà dịch vụ không có người có đủ trình độ để phỏng vấn và xét tuyển nhân viên.

Giải pháp cho vấn đề nhân sự cho những Dự án phần mềm lớn và phức tạp là: Đầu tiên phải thuê một trong những công ty Tư vấn về Giải pháp Công nghệ Thông tin để thu thập thong tin sơ bộ và làm phác thảo ước tính về quy mô cũng như Độ Phức tạp của Dự án. Sau đó dựa vào những công ty Cung cấp Nhân sự chuyên nghiệp để thuê những nhân viên quản trị Dự án (Project Manager) và Kiến trúc sư Phần mềm (Software Architect) có năng lực , để làm nhiệm vụ lãnh đạo Dự án, thu thập thong tin, phân tích đánh giá, lựa chọn công nghệ, công cụ, ngôn ngữ lập trình, phác thảo thiết kế …

Làm theo cách này, sẽ đảm bảo được tính chuyên môn hóa cao, vì các công ty chuyên về Tư vấn về Giải pháp Công nghệ Thông tin có chuyên môn cao trong việc thu thập thông tin thực tế và phác họa giải pháp, các công ty Cung cấp Nhân sự có chuyên môn cao và có chuyên gia với trình độ chuyên ngành cần thiết trong việc tìm kiếm, phỏng vấn và xét tuyển nhân viên. Tuy nhiên, do nhu cầu thị trường lớn, nên có nhiều công ty cung cấp dịch vụ Tư vấn Giải pháp và Cung cấp Nhân sự hoạt động, và rất nhiều trong số đó không có đủ kinh nghiệm, trình độ và kiến thức cần có cho những Dự án có quy mô lớn và phức tạp. Do đó, việc chọn công ty Tư vấn Giải pháp và Cung cấp Nhân sự để thuê cần phải được tiến hành hết sức cẩn thận.

Sau khi hoàn thành tốt khâu Chuẩn bị Nhân sự, thì các khâu khác của Dự án sẽ được tiến hành một cách thuận lợi, vì những Quản trị Dự án và Kiến trúc sư Phần mềm có kinh nghiệm, kiến thức sẽ biết phải điều hành dự án theo những Quy trình nào, tiến hành việc thu thập thông tin, phân tích, hệ thống, đánh giá ra sao, tổ chức đội ngũ và giao tiếp giữa các nhóm làm việc như thế nào, tuyển lập trình viên và nhân viên phân tích với tiêu chuẩn trình độ sao cho phù hợp, lựa chọn công cụ, tiện ích để quản lý, theo dõi công việc và công cụ lập trình một cách tối ưu. Tất nhiên, các công việc kể trên không phải là dễ dàng, nhưng với một đội ngũ Lãnh đạo tốt, có kinh nghiệm, kiến thức thì khả năng tiến hành tốt các bước của Dự án sẽ rất cao, và Dự án có khả năng thành công đúng thời hạn và trong phạm vi ngân sách.

Hy vọng là qua study case này, bạn đọc sẽ rút ra được những điểm yếu có thể xảy ra trong những khía cạnh khác nhau của một Dự án Phần mềm như Quy trình Quản lý Dự án (Project Management Process), Quy trình Phát triển Phần mềm (Software Development Process) và Kiến trúc Phần mềm (Software Architecture) và qua những giai đoạn (phase) khác nhau của một chu kỳ phát triển phần mềm (Software Development Lifecycle) như Khởi đầu (Inception), Dự thảo Chi tiết (Elaboration), Thực hiện xây dựng (Construction). Có điều, các giai đoạn được trình bày về Dự án tại công ty N này không phải là một Chu kỳ phát triển Phần mềm đầy đủ (Full Lifecycle Software Development) vì Dự án chưa có, và rất có thể không bao giờ có giai đoạn Chuyển giao (Transition).

U.S.A. 1-8-2005

JMS

[1]

Trước đây tôi đã từng làm việc vài năm trong vị trí là Senior Software Engineer, Software Architect và R&D Team leader trong Windchill R&D (Research and Development) của PTC.

[2]

Trong thời gian làm trong Windchill R&D, ngoài công việc nghiên cứu phát triển công nghệ và thiết kế Windchill foundation, tôi có tham gia hỗ trợ trực tiếp cho dự án triển khai Windchill ở Rolls Royce (Anh), Airbus (Pháp) và Tokyo Electron (Nhật).

[3]

Frederik Phillips Brooks, Jr.: Kenan Professor of Computer Science, Department of Computer Science, University of North Carolina

Ông tốt nghiệp Cử nhân Khoa học ngành Vật lý với điểm tuyệt đối trong toàn bộ quá trình học (summa cum laude) trường Duke, Master và Ph.D. toán ứng dụng trường Harvard. Ông đã tham gia giảng dạy nhiều năm, làm nghiên cứu trong Bộ phận Nghiên cứu và Phát triển Công nghệ của IBM, tham gia Ban Nghiên cứu của Bộ Quốc phòng và nhiều Ủy ban Nghiên cứu Liên bang và Quốc gia khác. Các giải thưởng, huy chương về Phát minh và Công nghệ của ông được trao bởi Học Viện Hoàng gia Anh, Học viện Hoàng gia Hà lan, Viện nghiên cứu Liên bang Thụy sĩ, của các Viện nghiên cứu, trường Đại học và Ủy ban Quốc gia của Mỹ nếu liệt kê hết phải tốn nhiều trang giấy khổ A4. Ông có hai bằng Phát minh Sáng chế của Mỹ (U.S. Pattern) trong lĩnh vực Computer Science. Ông đã tham gia quản trị nhiều dự án nghiên cứu công nghệ và phát triển phần mềm trong công nghiệp.

Danh mục các tác phẩm khoa học bao gồm sách, bài viết, tài liệu nghiên cứu … nếu được liệt kê cũng tốn rất nhiều trang A4.

[4]

Có một trường hợp áp dụng Memento Design Pattern trong Swing GUI của Dự án cũng khá lý thú, nhưng là do sáng tạo của một Swing Developer chứ không phải nằm trong thiết kế của dự án. Lác đác trong Java code của dự án cũng có một vài chỗ có ứng dụng tốt Design Pattern, nhưng toàn bộ là do các lập trình viên giàu kinh nghiệm trong dự án áp dụng, chứ không có trong tài liệu thiết kế (Design Document) và Mô hình Đối tượng (Object Model), và không phải từ Ban Lãnh đạo Dự án và Kiến trúc sư phần mềm mà có.

[5]

MVC: Model-View-Controller. Chi tiết về lý thuyết và ví dụ về ứng dụng MVC Design Pattern trong lập trình Java có thể tìm thấy trong PC World Vietnam tháng 5 năm 2005. [...]

[6]

Trong ngôn ngữ lập trình Java, interface có 4 chức năng rất quan trọng:

1. Java không hỗ trợ (support) việc thừa kế từ nhiều lớp đối tượng (multiple inheritance), do đó interface cung cấp công cụ để một lớp đối tượng có thể cài đặt (implement) nhiều interface, và qua đó thừa kế các hành vi (behavior) của nhiều loại đối tượng khác nhau.
2. Java interface tách biệt chức năng (functionality) và cách cài đặt chức năng (implementation). Đây là một đặc điểm rất quan trọng, giúp cho các thành phần (component) trong một hệ thống OOP có thể tương tác với nhau, nhưng không phụ thuộc chặt chẽ vào cách cài đặt của nhau, do đó các thành phần có thể được dùng lại trong nhiều hệ thống, dễ bảo trì, mở rộng.
3. Java interface có tác dụng như một sự đánh dấu (marker interface), xác định với hệ thống là nếu một lớp đối tượng (class) cài đặt (implement) một interface, thì lớp đối tượng này có thể được hệ thống thao tác và sử dụng theo một số phương pháp nhất định. Một ví dụ về marker interface là Serializable interface.
4. Java interface có tác dụng là định nghĩa các phương thức (method) nhằm mục đích bắt buộc những lớp đối tượng (class) nào cài đặt (implement) interface này, thì cũng phải có những phương thức (method) có trong interface. Chức năng này dung để thiết kế các framework mà các hành vi cụ thể có thể mở rộng hoặc thay đổi cách thực hiện trong tương lai, hoặc các hành vi phải được thực hiện đã biết, nhưng cách thức thực hiện thì chưa được biết vào thời điểm viết chương trình, mà chỉ biết khi chạy chương trình (run-time) . Trong design pattern, chức năng này được sử dụng nhiều trong Template Method và Strategy pattern.

[7]

Một ví dụ về mở rộng chức năng thông qua Kế thừa (Inheritance) và thông qua Bao gồm (Composition).

Giả sử trong một hệ thống dữ liệu về hàng điện tử ta có nhiều loại thiết bị cần quản lý, trong đó có Phone (Điện thoại), Camera (máy ảnh), CameraPhone (Điện thoại có máy ảnh) và Digital Camera (Máy ảnh kỹ thuật số).

Ta nhận thấy CameraPhone có chức năng của Phone và Camera, có thể được mở rộng từ Phone và Camera. DigitalCamera thuộc về họ Camera, và có thể được mở rộng từ Camera.

Mở rộng thông qua kế thừa:

Trong Java không có thừa kế từ nhiều lớp (multiple Inheritance), nên ta phải định nghĩa Camera và Phone là Interface, và định nghĩa CameraPhone là implementation của các interface Camera và interface Phone. Như vậy trong lớp CameraPhone, ta phải viết code cho các chức năng của Phone và Camera. Tương tự, ta có thể định nghĩa DigitalCamera là implementation của Camera, và trong Camera, ta phải viết code cho các chứ năng của Camera.

* Lợi: Xây dựng được một hệ thống các lớp đối tượng có chung một số chức năng nhất định (ví dụ như DigitalCamera và CameraPhone có chung chức năng chụp ảnh).

* Hại: Trùng lặp code (trong DigitalCamera và CameraPhone cùng có code cho chức năng chụp ảnh, và rất có thể là hoàn toàn giống nhau, vì cùng là chụp ảnh digital). Dễ gây ra tính thiếu tự nhiên trong thiết kế và lỗi khi chạy chương trình (ví dụ như một API dành cho interface Phone được gọi và truyền cho tham số là CameraPhone, sau đó dùng reflection để gọi các method trên đối tượng được truyền làm tham số, rất có thể API này sẽ gọi cả chức năng của Camera, là điều hoàn toàn sai và không được dự tính cho API này). Tạo ra nhiều lớp đối tượng một cách không cần thiết (mỗi lần cần mở rộng tính năng lại phải dẫn suất (derive) ra một lớp đối tượng mới).

Mở rộng thông qua Bao gồm (Composition):

Ta định nghĩa Phone như một class có các chức năng của điện thoại, và Camera là một class có chức năng của máy ảnh. Như vậy CameraPhone được định nghĩa như một lớp đối tượng có hai thành viên (member variable) là Camera và Phone. Khi chức năng Phone của CameraPhone được gọi, CameraPhone sẽ gửi lệnh gọi này tới biến thành viên (member) Phone, và khi chức năng Camera của CameraPhone được gọi, CameraPhone sẽ gửi lệnh gọi này tới thành viên Camera. Đối với DigitalCamera, ta có chọn lựa rộng rãi hơn, có thể kế thừa (inherit) và định nghĩa chồng (override) các chức năng của Camera, hoặc các chức năng được cài đặt cơ bản là giống nhau, thì có thể định nghĩa DigitalCamera có một biến thành viên là Camera, và gửi các lệnh gọi về chức năng của Camera tới thành viên này.

Lợi: Giảm được sự trùng lặp code. Tạo ra các chức năng mới một cách dễ dàng bằng cách bổ sung biến thành viên.

Hại: Trong trường hợp đối tượng mới cần có chức năng khác hơn chức năng có sẵn của biến thành viên (ví dụ chức năng chụp ảnh của DigitalCamera khác chưa năng chụp ảnh của Camera, còn các chức năng như nạp pin, lau ống kính thì giống), sẽ có dư thừa code (vì chức năng chụp ảnh phải viết mới, trong khi đó trong biến thành viên Camera cũng có chức năng chụp ảnh).

Tất nhiên, không có luật tuyệt đối đúng (hard and fast rule) cho việc trong trường hợp nào thì phải mở rộng chức năng bằng Inheritance, trong trường hợp nào thì phải sử dụng Composition hay Design Pattern. Có một khẩu hiệu cũng khá nổi tiếng trong giới lập trình “Prefer composition over Inheritance”. Tuy vậy, điều này phụ thuộc vào yêu cầu thực tế, trình độ, kỹ năng kinh nghiệm của kiến trúc sư phần mềm (Software Architect), và có tính nghệ thuật cao.

Nhưng một Dự án phần mềm mà chỉ có mở rộng chức năng đối tượng bằng Inheritance (trong khi có những trường hợp dùng các phương pháp khác tốt hơn) là tuyệt đối không được, thể hiện trình độ kém và thiếu hiểu biết của kiến trúc sư phần mềm.

/*
*
* Nguồn Những bài học từ một dự án phần mềm
*
*/