1. Ở những ngành khác thì nữ vừa nhiều vừa xinh đẹp, ngành IT thì ngược lại

Điều này ai đã và đang học CNTT ở các trường ĐH đều biết rồi. Không riêng gì trong ngành CNTT mà những ngành kỹ thuật, số lượng nữ giới cũng rất thấp. Tuy nhiên so với các ngành như cơ khí, điện tử thì tỉ lệ nữ giới học CNTT cũng còn khá cao. Nhưng khi học xong và đi làm, tỉ lệ nữ giới làm lập trình lại càng giảm, đa số các bạn ấy làm QC, DB, BA,… (*).

Ở nhóm tôi khoảng 20 người chỉ có mỗi 2 dev, 2 QC là nữ, còn lại toàn đực rựa. Tuy nhiên điều an ủi là trong công ty vẫn có nhiều chị em xinh lắm hỉ hỉ nhưng không làm ở bộ phận lập trình. Thiếu thốn này thường dẫn đến điều thứ hai.

2. Xác suất phải lập gia đình với người cùng ngành rất cao

Nghe có vẽ như hơi mâu thuẫn, đã ít nữ thì làm sao xác suất này cao được. Thế nhưng với những người làm IT thì kể từ lúc đi làm thường nhìn máy tính nhiều hơn giao tiếp với người thật nên sẽ ăn nói kém, giao tiếp kém, cơ hội gặp phụ nữ khác ngành cũng ít hơn người làm ở ngành khác nên trời kêu ai nấy dzạ.

Tuy nhiên chúng ta thường quen nửa cuộc đời của mình từ trong trường ĐH hoặc ở nơi làm việc nên điều này có thể cũng đúng với những người làm ở các ngành khác. Dù những người làm ở ngành IT chúng ta thường được cái thông minh, nhưng hai người thông minh thì sinh con ra chưa chắc thông minh nên đây cũng là một hiểm họa tiềm tàng. Hơn nữa, hai người cùng ngành IT giờ gặp nhau ngoài nói chuyện bug, code thì chán chết. Phải chi chàng kể chuyện bug, nàng hỏi bug là gì huh anh thì có thú vị ko nhẩy.

3. Bạn sẽ bị yếu đi

Điều này không có gì phải bàn cãi. Thứ nhất ngồi nhiều… thì bụng và mông sẽ to. Bụng càng to càng khó làm... nhiều thứ và tuổi thọ giảm. Ngồi nhiều còn có thể gây ra nhiều bệnh tế nhị khác. Ngoài hai bệnh đằng trước và đằng sau thì còn bệnh ở mắt do nhìn quá nhiều. Đa số người làm IT xung quanh ta đều bị cận thị. Gõ máy tính thường xuyên sẽ ảnh hưởng đến tim, rê chuột thường xuyên sẽ thoái hóa cổ tay. Ngoài ra cột sống sẽ bị chai hoặc mọc gai do tật ngồi nhiều hơn đứng của công việc này.

Ngoài ra, người làm IT thường có thói quen làm việc, sinh hoạt ban đêm. Cái giờ đáng lẽ những người ở những ngành khác làm cái việc mà ai cũng biết là việc gì thì người trong ngành IT lại gõ gõ, click click và thường gây ra bệnh đau bao tử. Tay chân ít hoạt động nên con người thường cảm thấy mỏi mệt, lười vận động, thậm chí cả lười tắm nên đừng thắc mắc tại sao một số SV ngành IT thường ở dơ. Nói chung làm cái nghề này nếu ko chịu sinh hoạt… điều độ thì đừng mong thọ.

4. Bạn sẽ thường xuyên bị làm phiền bởi người quen

Đây là một trong những điều tệ hại và khó chịu nhất bạn sẽ gặp phải. Những người quen của bạn: bạn bè, bà con, cô dì chú bác, bạn của ba của mẹ sẽ gọi điện nhờ bạn giúp khi họ không nghe nhạc được, máy khởi động chậm, không thấy webcam, không biết đưa hình lên blog.

Kiểu hỗ trợ kỹ thuật miễn phí này nên cẩn thận vì nó sẽ thường xuyên lặp đi lặp lại. Một số trường hợp bạn sẽ được trả công nhưng theo tôi, bạn chẳng cần số tiền chả đáng đổ xăng đó làm gì so với thời gian phải chạy đi chạy lại. Đa số người nhờ bạn giúp sẽ mong muốn được hỗ trợ miễn phí và tôi chắc chúng ta sẽ không vui gì về điều đó. Vì vậy hãy tập nói không khi có thể.

5. Bạn sẽ phải thường xuyên về trễ mà không được trả tiền

Đặc thù của ngành IT là công việc thường không thể tính chính xác bằng giờ. Có nghĩa là không phải cứ một lượng thời gian nào đó thì sẽ làm xong một công việc. Thường chúng ta sẽ phải ở lại thêm 1 giờ, 2 giờ để làm nốt công việc của mình nếu bạn là người có trách nhiệm. Nhưng dù có trách nhiệm hay không thì khi công việc chưa xong mà đã gần đến deadline thì bạn vẫn phải ở lại để hoàn thành những gì còn dở dang, tất nhiên không có xu nào cả.

6. Bạn sẽ thường xuyên bị stress

Khi làm việc với những project lớn nhiều người, công việc sẽ theo flow rõ ràng, bạn làm ngưòi khác test, manager dzí, và khi đến những ngày cuối cùng là lúc bạn làm việc nhiều nhất. Phải suy nghĩ nhiều, cơ thể mệt mỏi, thiếu ngủ cộng với căng thẳng khi làm việc sẽ khiến nhiều người bị stress.

Theo một số điều tra, thủ phạm gây stress nhiều nhất là email. Khi phải đọc khoảng 100 email một ngày thì người hiền lành cũng trở nên gắt gỏng. Bởi vậy những người làm IT thường hay khó chịu đột xuất.

7. Lương bạn sẽ tăng rất chậm

Ảnh minh họa: Internet

Làm IT lương khởi điểm sẽ khá cao so với một số ngành nhưng tốc độ tăng sẽ chậm và ít đột biến. Thường người làm IT sẽ giải quyết nhu cầu tăng lương bằng cách nhảy sang công ty khác. Cho nên những bạn sinh viên mới ra trường nên tìm một công ty có lương khởi điểm khá tốt, vì thông thường chu kỳ tăng lương sẽ là từng năm và khi lạm phát hai chữ số mà tăng lương dưới 15% + với trả lương bằng tiền Việt thì hơi bị đuối. Tốt nhất nên tìm hiểu những anh chị đi trước hoặc xác định mục tiêu của mình để tìm hướng đi khác vì làm lập trình chay khó làm giàu lắm.

8. Không phải lúc nào cũng được làm công việc ưa thích

Bạn từng nghĩ sẽ áp dụng những kỹ thuật tiên tiến nhất của các ngôn ngữ lập trình hiện đại, sẽ học hỏi những công nghệ mới nhất và làm việc với những chuyên gia đầy kinh nghiệm trong lĩnh vực CNTT nhưng thường không phải như vậy. Ở những công ty càng lớn càng có những project kỳ lạ kiểu như chuyển nguyên một chương trình từ VB6 sang C#, hoặc từ một ngôn ngữ rất cổ xưa sang C#.

Tuy đòi hỏi kiến thức lập trình trên hai ngôn ngữ, khả năng đọc hiểu code nhưng nói chung công việc như vậy khá nhàm chán và tôi nghĩ chẳng ai muốn theo đuổi lâu dài. Đối với những project lớn thì chi phí công nghệ mới là một trong những vấn đề quan tâm của khách hàng.

Bạn muốn sử dụng SQL 2005 nhưng khách hàng sẽ nói “No” khi họ đã có licence cho SQL 2000 và không muốn bỏ tiền mua thứ mới. Bạn muốn sử dụng ASP.NET để làm website cho khách hàng nhưng họ cho rằng PHP sẽ rẻ hơn vì không tốn nhiều licence cho máy chủ WINDOWS. Bạn muốn dùng ORM tool để tiết kiệm thời gian lập trình nhưng khách hàng nhất quyết bạn phải dùng Store Procedure và viết code gọi bằng C# vì làm vậy nhanh hơn 30 milisecond khi gọi 10.000 query. Nói chung khách hàng là thượng đế và chúng ta phải nghe theo.

9. Khi nhảy việc cũng không đơn giản, có khi phải bắt đầu lại từ đầu

Lương bạn hiện không cao trong khi lương tụi bạn đã gấp hai mình. Đề nghị sếp tăng lương thì sao, liệu sếp có chịu tăng cho mình gấp rưỡi không chứ đừng nói gấp hai. Tại sao không nhảy việc khi vừa có thể có lương cao hơn lại có thể học hỏi nhiều cái mới và làm quen nhiều con người mới.

Nhưng khi nhảy việc là lúc bạn phải chấp nhận làm lại từ đầu. Có thể bạn có nhiều kinh nghiệm từ công ty cũ nhưng sang môi trường mới sẽ không có đất để dụng võ. Và khi chưa biết gì hết thì bạn sẽ là một newbie (dân tay mơ) và chấp nhận làm lại từ con số không. Vì vậy, theo tôi, nếu tìm được công việc mới lương gấp rưỡi trở lên thì hãy nhảy, còn không ở lại cho lành và chờ thời cơ.

10. Rất khó để tự kinh doanh riêng về IT

Tỉ lệ thất bại cao của các công ty IT mới thành lập đã nói lên điều này. Nếu bạn làm IT khi muốn mở một công ty làm phần mềm thì rất khó. Một trong những khó khăn lớn nhất là sự cạnh tranh. Bạn sẽ khó kiếm được project từ những khách hàng lớn khi công ty của bạn chưa hề có tên tuổi hoặc không có công ty mẹ đỡ đầu. Nếu chấp nhận làm dự án nhỏ thì có vô khối công ty đã làm như vậy.

Những công ty may mắn sống sót nhờ vào dạng những project nhỏ này họ có thể thực hiện website trong một tuần nhờ tái sử dụng những cái đã có từ project cũ và chúng ta sẽ khó cạnh tranh mỗi khi kinh nghiệm tổ chức và kinh doanh là con số 0. Giỏi lập trình không có nghĩa là giỏi quản lý, và càng không có nghĩa là giỏi kinh doanh nên làm công ty về IT không hề đơn giản. Và khi không có project nào trong khi phải nuôi đội quân cỡ năm người, cộng với trả tiền điện, tiền mặt bằng trong ba tháng là bạn phải nghĩ đến chuyện giải tán.

Đó là 10 trong khá nhiều những khó khăn, thiệt thòi, gian khổ của ngành IT. Làm IT không đơn giản và không sướng chút nào, càng không dễ làm giàu. Thế nên những ai nghĩ làm IT sướng và lương cao thì nên xem lại và cân nhắc nếu như đang chọn nghề cho mình. Đây là những ý kiến chủ quan của tôi, có thể có nhiều ý kiến trái ngược và bổ sung khác nên rất mong được sự chia sẽ từ các bạn. Mọi comment khen ngợi, chửi bới đều hoan nghênh.

Taiichi Ohno, nhà lãnh đạo tinh thần của TPS, cho rằng hao phí lớn nhất là hao phí về sản xuất thừa. Nếu bạn làm ra một thứ mà bạn không thể bán được, thì công sức bạn bỏ ra sẽ mất đi. Nếu bạn làm ra một thứ dùng nội bộ trong dây chuyền mà không sử dụng chúng ngay lập tức, thì giá trị thông tin của chúng sẽ bốc hơi. Và bạn cũng tốn chi phí lưu trữ chúng: chuyển chúng vào nhà kho; theo dõi kho; lau chùi rỉ sét khi đem ra dùng lại; và sẽ gặp rủi ro nếu bạn không bao giờ dùng đến chúng nữa; trong trường hợp đó, bạn lại tốn chi phí để đem hủy bỏ chúng.

Có vô vàn hao phí về sản xuất thừa trong phát triển phần mềm: bộ tài liệu yêu cầu đồ sộ nhanh chóng bị lỗi thời; các kiến trúc phức tạp không bao giờ được dùng; các đoạn mã hàng tháng trời không được tích hợp, kiểm thử và chạy trên môi trường thực; và các tài liệu không ai muốn đọc cho tới khi chúng không còn thích hợp hay mất tác dụng. Bởi vì tất cả những hoạt động này đều quan trọng với phát triển phần mềm, chúng ta cần sử dụng đầu ra của chúng ngay lập tức; để nhận được các phản hồi cần thiết nhằm loại trừ hao phí.

Lấy ví dụ về việc thu thập yêu cầu. Nó sẽ không được cải tiến bởi một tá các qui trình thu thập yêu cầu phức tạp. Nó sẽ được cải tiến bằng cách rút ngắn đoạn đường giữa “việc tạo ra các yêu cầu chi tiết” và “việc triển khai các phiên bản phần mềm”. Sử dụng ngay lập tức yêu cầu chi tiết ngầm ý rằng thu thập yêu cầu không phải là một giai đoạn mà kết quả là một thứ tài liệu tĩnh; thu thập yêu cầu là hoạt động diễn ra suốt quá trình phát triển, nó sản xuất ra các chi tiết vừa ngay khi chúng được cần đến.

Có rất nhiều mặt của TPS tương đồng với phát triển phần mềm; những ý tưởng hữu ích chẳng hạn như: huấn luyện chéo giữa các công nhân, tổ chức nhà máy thành nhiều ô, và lập các hợp đồng chia sẻ thành quả giữa khách hàng và nhà cung cấp. Nếu bạn có hứng thú, tôi khuyên bạn nên đọc quyển Toyota Production System của Ohno.

Trong nhiều năm - thực sự nhiều thập kỷ qua - Tôi là một fan hâm mộ lớn của code đẹp. Tôi đọc gần như tất cả mọi thứ của Brian Kernighan, Jon Bentley, và P. J. Plauger. Niềm đam mê này là một cố gắng tạo lại sự hăm hở (rush) khi tôi đọc được đầu tiên dòng code:

*x++ = *y++

Trong ngôn ngữ lập trình. Tôi chưa bao giờ nhìn thấy bất cứ đoạn code nào cô đọng đẹp đến vậy. Nó đã được phát minh! Nhưng nhiều năm qua, tôi đọc rất nhiều các thuật toán thông minh, rất nhiều tối ưu hóa ấn tượng, rất nhiều thủ thuật nhỏ. Và tôi đã nhận ra càng ngày càng ít hơn những gì thu được (charge) trong những khám phá đó. Lý do là, khá thẳng thắn, là chúng gần như luôn luôn rơi vào một trong hai loại: một số cách thể hiện rất tao nhã trong một ngôn ngữ mới (Ruby được chuyển từ Java là một minh chứng) hoặc một kỹ thuật mà tôi không bao giờ có khả năng để sử dụng. Nói cách khác, tôi đang theo đuổi những món đồ chơi rẻ tiền. Theo thời gian, khiếu thẩm mỹ của tôi chuyển thành việc code một cách sáng sủa vì sự dễ chịu của nó.

Bây giờ, nếu tôi có thể chọn ra một đoạn code phức tạp, đọc nó lướt qua, và hiểu một cách chính xác những gì nó làm, thì tôi cảm thấy hăm hở trở lại. Tôi thường có cảm giác này khi đọc các đoạn code từ những lập trình viên giỏi, hoặc không hàng lâm. Nói một cách trung thực, khi miệt mài trong khoảnh khắc như vậy, tôi thường xuyên nhận thức rằng đoạn code của tôi không giống như họ. Thậm chí đoạn code hay nhất của tôi hoàn toàn không giống với họ một chút nào. Và tôi đã tự hỏi tôi có thể làm gì để cải thiện tính rõ ràng (clarity) trong đoạn code của tôi.

Cuốn sách mới của Kent Beck, Implementation Pattern là một cuốn sách tóm tắt ngắn về code rõ ràng. Tôi đã đọc nhiều về nó và tôi đã nhận ra rằng một số thói quen xấu của tôi đã làm phá hoại đi tính đọc được của đoạn code. Beck cơ bản chỉ nhìn vào các đoạn code có vấn đề và tư vấn những lời khuyên khôn ngoan.

Điều này có nghĩa là vài lời khuyên là thích hợp nhất cho người mới bắt đầu, trong khi chúng chỉ đủ là các lời gợi ý tế nhị để giữ sự chú ý của một người kỳ cựu, người quan tâm đến sự rõ ràng.
Ví dụ, một trong những thói quen xấu là tôi thường code mà không không cần suy nghĩ nhiều về sự pha trộn của các mức độ trừu tượng hóa trong cùng một method. Vì vậy, ví dụ (sử dụng ví dụ của Beck):

void process() {
input();
count++;
output();
}

Dòng code thứ hai rõ ràng ở một mức độ trừu tượng khác với hai cái kia, và làm cho đoạn code khó đọc một cách nhanh chóng. Beck đề nghị giải pháp sau đây, mà tôi đồng ý là rõ ràng hơn.

void process() {
input();
tally();
output();
}

Có nhiều thói quen xấu khác của tôi mà cuốn sách này đã soi sáng. Và trong nửa tá thay đổi sẽ mang đến cho phong cách của tôi, tôi nghĩ rằng tôi đã thu được nhiều lợi ích hơn so với trong tất cả các bài luận tôi đã đọc về chủ đề beautiful code.

Tuy nhiên trước khi kết thúc, tôi nên đưa ra hai lời cảnh báo: Tài liệu cho người mới bắt đầu đến trung cấp đang tràn lan, vì vậy bạn sẽ cần phải lươm lặt trên phần lớn đống chữ nghĩa đó để rút trích ra các thông tin có giá trị. (Tuy nhiên, khía cạnh này tạo món quà cho các lập trình viên junior ở vị trí của bạn.) Điểm thứ hai là cuốn sách này thiếu chỉnh sửa tốt. Một cuốn sách về clarity code thì nên trong sáng; cuốn này thì không. (Xem xét việc sử dụng các từ ‘mẫu từ,' nó rất dể gây hiểu lầm cao. Và không phải tất các mẫu từ đều như vậy.) Nhưng những vấn đề này có thể chấp nhận được.

Những công nghệ mới hứa hẹn đem đến những trải nghiệm hấp dẫn hơn và có khả năng làm lu mờ ngôi sao hiện nay trên bầu trời Web 2.0.

Web, nền tảng ban đầu chỉ nhằm mục đích phân phát tài liệu trực tuyến, giờ đây có vai trò quan trọng trong việc phân phối ứng dụng. Ứng dụng dựa trên web đem lại nhiều lợi ích như: giải phóng người dùng khỏi gánh nặng cấu hình phần mềm và quản lý các phiên bản cập nhật, cho phép họ truy cập ứng dụng và dữ liệu từ nhiều máy tính khác nhau; cho phép nhà cung cấp ứng dụng quản lý tập trung và tiết kiệm đáng kể chi phí triển khai.

Mô hình ứng dụng trên nền web truyền thống theo kiến trúc máy khách-máy chủ (client-server) với trình ứng dụng chạy trên máy tính của người dùng thiết kế “nhỏ gọn” (thin client): mọi tác vụ xử lý thực hiện trên server, còn client chỉ có vai trò hiển thị nội dung tĩnh (HTML). Hạn chế lớn nhất của kiến trúc này là mọi tương tác với ứng dụng đều phải gửi (yêu cầu dữ liệu) đến server, server xử lý và đáp trả, phía client nạp lại trang web với thông tin cập nhật - chu trình đồng bộ này làm cho các ứng dụng web tương tác với người dùng chậm chạp, chậm hơn nhiều so với các ứng dụng truyền thống (ứng dụng desktop) cài đặt và chạy trên máy tính người dùng.

“Java applet” là bước đi đầu tiên nhằm cải thiện tốc độ đáp ứng của các ứng dụng web. Applet có khả năng thực hiện nhiều tác vụ phức tạp phía client nhưng ứng dụng Java (phía client) chạy chậm “có tiếng” và làm việc không ổn định trên các hệ điều hành khác nhau – triết lý “viết một lần, chạy mọi nơi” vẫn chỉ là lý thuyết.

Tiếp theo, Netscape và Microsoft đưa ra “plug-in” và “ActiveX control” mở rộng trình duyệt web, cho phép bổ sung nhiều tính năng phía client. Thế nhưng người dùng tỏ ra do dự trong việc cài đặt các phần bổ sung này (bảo mật là một trong nhiều lý do), và đến nay, ngoại trừ Flash Player và Java Runtime Environment (JRE), không có thành phần bổ sung trình duyệt nào được cài đặt rộng rãi.

Rồi Ajax (Asynchronous JavaScript And XML) xuất hiện, cho phép việc trao đổi giữa client và server diễn ra không theo quy trình đồng bộ thông thường, tương tác giữa người dùng và ứng dụng web không bị ngắt quãng bởi việc nạp lại trang web mỗi khi yêu cầu server xử lý gì đó. Dựa trên những nền tảng sẵn có (JavaScript, Document Object Model, XmlHttpRequest, Cascading Style Sheets) được hầu hết trình duyệt hỗ trợ nên không yêu cầu cài đặt thêm bất cứ gì ở client và hầu hết các nhà phát triển đều có thể dễ dàng vận dụng, Ajax đã nhanh chóng “thống lĩnh” thế giới Web 2.0 – thế hệ (ứng dụng) web tiện lợi hơn, có tính tương tác cao hơn thế hệ web trước đó.

Ajax đem đến cho người dùng những trải nghiệm mới mẻ với ứng dụng web: ít yêu cầu “động tay” (nhấn), đáp ứng nhanh hơn, có những hiệu ứng giao diện giống như ứng dụng desktop kể cả thao tác “kéo thả”... Những ứng dụng như Google Maps và GMail tạo suy nghĩ có thể làm được mọi việc (những gì làm được trên desktop) trên web, và sự thành công của những site như YouTube và Flickr làm cho người ta thêm kỳ vọng về nội dung đa phương tiện trên web - và một loạt công nghệ web mới đã được đưa ra đáp ứng mong đợi này, hầu hết đều có thể làm việc với Ajax hay như Ajax (và tốt hơn), và đặc biệt làm việc tốt với hình ảnh và video - mảng nội dung đang ngày càng “hot” và được cho là xu hướng tương lai của web nhưng lại là mảng “không chuyên” của Ajax. Các công nghệ mới hứa hẹn tạo nên thế hệ ứng dụng web có thể cạnh tranh với các ứng dụng desktop, cả về tính năng lẫn giao diện người dùng, và có khả năng chạy trên bất kỳ hệ thống nào.

NHỮNG CÁI TÊN ĐÁNG GỜM

Các ứng dụng web mạnh cả về tính năng và giao diện người dùng được gọi với thuật ngữ RIA (Rich Internet Application, hay Rich Interactive Application với Microsoft). RIA được Macromedia giới thiệu lần đầu tiên trong một tài liệu vào tháng 3/2002, có trước Ajax (được Jesse James Garrett giới thiệu đầu tiên trong tài liệu “Ajax: A new Approach to web Applications” vào tháng 2/2005), nhưng mãi đến gần đây mới được chú ý nhờ những cái tên đáng gờm mới xuất hiện: Flex và AIR của Adobe, Silverlight của Microsoft và JavaFX của Sun Microsystems.

Flex và AIR của Adobe

Cho đến hiện nay, Adobe Systems là "tay chơi" lớn nhất và trưởng thành nhất trong lĩnh vực RIA. Mua lại Macromedia cách đây hơn 4 năm (tháng 4/2005), Adobe được kế thừa gia sản để đi từ Shockwave đến Flash, Flex và AIR (tên gọi ban đầu là Apollo).

Flash là công nghệ thể hiện nổi tiếng về khả năng xử lý đồ họa vector và ảnh động, cho phép tạo nội dung đa phương tiện tương tác với người dùng thông qua ActionScript. Flex dựa trên Flash, dùng ngôn ngữ khai báo dựa trên xml (MXML) kết hợp với ActionScript, cung cấp sự tách biệt giữa phần giao diện người dùng và phần luận lý ứng dụng rõ ràng hơn so Flash. Ứng dụng Flex được biên dịch thành file .SWF và chạy với Flash player – chạy trên bất kỳ hệ thống nào hỗ trợ Flash, có khả năng chạy trên cả thiết bị di động (với Flash Lite).

Ứng dụng Flash/Flex cũng có thể chạy trên desktop với thư viện thực thi AIR. AIR (Adobe Integrated Runtime) là công nghệ triển khai để chạy các ứng dụng Flash/Flex và cả Ajax mà không cần trình duyệt, tương tự ClickOnce của Microsoft – công nghệ triển khai ứng dụng dựa trên Windows, nhưng AIR chạy trên cả Windows và Mac (phiên bản chạy trên Linux đang trong quá trình thử nghiệm).

Silverlight của Microsoft

Silverlight (2.0) có thể xem là tập con của Windows Presentation Foundation (WPF), cũng sử dụng XAML (eXxtensible Application Markup Language) – ngôn ngữ khai báo dựa trên xml để định nghĩa giao diện người dùng (bao gồm đồ hoạ vector, hiệu ứng động và tương tác dữ liệu trong giao diện). Các tác vụ xử lý phức tạp được tách khỏi định nghĩa giao diện người dùng và có thể viết với mã lệnh “được quản lý” (managed code) dùng các ngôn ngữ .NET hay JavaScript và Python/Ruby.

Silverlight yêu cầu cài đặt thư viện bổ sung trình duyệt để thực thi phía client. Hiện tại ứng dụng Silverlight có thể chạy với trình duyệt Internet Explorer và Firefox trên Windows, Safari và Firefox trên Mac OS X; chưa hỗ trợ trình duyệt nào trên Linux (tuy nhiên hiện đã có dự án nguồn mở Moonlight cho phép chạy ứng dụng Silverlight trên Linux). Hỗ trợ cho thiết bị di động, Microsoft có Silverlight for Mobile chạy trên hệ điều hành Nokia S60 và Windows Mobile 6.

JavaFX của Sun Microsystems

JavaFX (tên mã F3) được xây dựng dựa trên nền tảng công nghệ Java, bao gồm 2 phần: JavaFX Script và Java Mobile. JavaFX Script là ngôn ngữ khai báo không dựa trên xml giúp cất đi gánh nặng xây dựng giao diện người dùng vốn trước đây yêu cầu khá nhiều mã lệnh Swing. JavaFX Script phải biên dịch thành Java byte code để chạy trên máy ảo Java (JVM). JavaFX Mobile là hệ điều hành cho thiết bị di động được thiết kế để triển khai ứng dụng RIA trên các thiết bị này.

Ở mức độ ít phổ biến hơn, còn có những cái tên đáng chú ý khác ngoài những cái tên “đáng gờm” kể trên: OpenLaszlo, Appcelerator, Curl, Google GWT, Mozilla Prism (cho phép chạy ứng dụng web trên desktop, tương tự Adobe AIR).

HIỆN THỰC RIA

Như đã đề cập ở phần đầu, hai thư viện bổ sung trình duyệt thực thi Flash và Java được cài đặt hầu như trên mọi máy tính (ước tính Flash hiện diện trên 95%, Java trên 85% máy tính trên toàn thế giới). Với hệ điều hành Windows ngự trị trên 90% máy tính và “vũ khí” Windows Updates, Microsoft cũng sẽ không khó khăn gì trong việc làm cho Silverlight trở nên phổ biến.

Phát triển

Microsoft đã từ lâu nổi tiếng trong việc xây dựng các công cụ phát triển ngoại hạng cho các công nghệ của mình, và xu hướng này được tiếp tục với Silverlight. Bạn có xây dựng ứng dụng Silverlight trong Visual Studio (hướng đến nhà phát triển) hay Expression Studio (hướng đến nhà thiết kế). Công cụ nào cũng có trình soạn thảo XAML cho phép xây dựng giao diện người dùng phức tạp, nhưng Expression Studio cung cấp các tính năng hoàn chỉnh hơn để tạo hình ảnh động và hiệu ứng đồ họa. Ngược lại, Visual Studio cung cấp các tính năng phát triển và bẫy lỗi tiên tiến mà mọi nhà phát triển đều mong muốn.

Một lợi ích quan trọng khác là Silverlight (2.0) hỗ trợ mã lệnh được quản lý của .NET để viết luận lý ứng dụng, cho phép sử dụng nền tảng phát triển mạnh hỗ trợ các khái niệm lập trình hướng đối tượng như kế thừa và đa hình, và các tính năng ngôn ngữ tiên tiến như lớp chung và lớp riêng. Với .NET CLR (Common Language Runtime) trong trình duyệt, mã lệnh được quản lý sẽ được biên dịch thành nhị phân trên client và chạy cực nhanh. Mã lệnh được quản lý có trong nhiều ngôn ngữ, ứng dụng Silverlight có thể viết bằng C#, VB, IronPython và IronRuby. Với khả năng hỗ trợ thêm nhiều ngôn ngữ nữa, Silverlight sẽ hấp dẫn nhiều nhà phát triển với nền tảng khác nhau.

Adobe cung cấp 3 con đường khác nhau để tạo ứng dụng RIA. Tiện nhất, với HTML và JavaScript có thể phát triển ứng dụng RIA trực tiếp trong môi trường phát triển Dreamweaver CS3 sử dụng AIR SDK. Ứng dụng RIA có thể tạo trong Flash sau khi tải về một bản cập nhật cho Flash CS3 (Adobe có kế hoạch tích hợp sẵn trong phiên bản tương lai). Flash rất thích hợp cho việc xây dựng nội dung đa phương tiện hấp dẫn mà không nhất thiết làm phình to ứng dụng, đây là nơi Flex thể hiện vai trò của mình. Flex cung cấp hỗ trợ việc phát triển ứng dụng tốt hơn Flash, mặc dù vẫn dựa trên ActionScript cho phần luận lý ứng dụng. ActionScript là ngôn ngữ tuân theo đặc tả ECMAScript tương tự như JavaScript, hỗ trợ lập trình hướng đối tượng cơ bản. Flex Builder 3 cung cấp môi trường phát triển dựa trên Eclipse để xây dựng ứng dụng RIA dùng Flex 3 SDK (thư viện nguồn mở) và giao diện kéo-thả để tạo giao diện người dùng dựa trên MXML.

Hỗ trợ về mặt phát triển của JavaFX khá khiêm tốn, chủ yếu gồm thư viện OpenJFX cho NetBeans, cung cấp hỗ trợ cơ bản cho việc tạo và biên dịch mã lệnh (script) JavaFX. NetBeans hiện là môi trường phát triển tích hợp (IDE) duy nhất hỗ trợ JavaFX. Có hai công cụ của hãng thứ ba hỗ trợ phần hiển thị trong JavaFX: công cụ soạn thảo JavaFXPad cho phép viết mã lệnh JavaFX và nhìn thấy kết quả hiển thị trong một cửa sổ xem trước, nhưng không cung cấp bất kỳ hỗ trợ kéo-thả nào cho các phần tử trên màn hình; và công cụ đồ hoạ JFXBuilder của ReportMill cung cấp giao diện kéo-thả cho việc xây dựng giao diện người dùng. Là ngôn ngữ khai báo không dựa trên xml, mã lệnh JavaFX giống như sự trộn lẫn giữa Java và CSS.

Triển khai

Việc xây dựng ứng dụng RIA chỉ là một phần của chặng đường, phần thứ hai là đưa ứng dụng đến người dùng và đảm bảo nó chạy đúng. Cả Flex, Silverlight và JavaFX đều không yêu cầu cài đặt bất cứ thành phần gì trên server, đây cũng là điểm chung của các giải pháp RIA.

Microsoft Silverlight và Adobe Flash đều là thư viện dựa trên trình duyệt với cách thức triển khai tương tự. Khi người dùng viếng thăm trang web có nhúng thành phần Flash hay Silverlight, nếu chưa cài đặt thư viện phù hợp, trang web sẽ hiển thị thông báo để người dùng tải về. Người dùng có thể chuyển đến website Microsoft hay Adobe và làm theo các hướng dẫn để tải về thư viện Silverlight hay Flash.

Riêng các ứng dụng Adobe AIR lại được đóng gói thành file .AIR và được tải về chứ không nhúng trong trang web. Người dùng không cài AIR trên hệ thống sẽ “bị” hỏi dùng chương trình nào để chạy file này, vì vậy việc triển khai AIR sẽ yêu cầu hướng dẫn nhiều hơn để đảm bảo người dùng biết cách chạy ứng dụng AIR.

Mã lệnh JavaFX nhất thiết phải biên dịch thành Java byte code và chạy trên máy ảo Java (JVM) như các Java applet thông thường, không yêu cầu thư viện bổ sung trình duyệt nào khác. Miễn là hệ thống có JVM là có thể chạy JavaFX. Mac OS có tích hợp sẵn JVM, vì vậy không cần tải về thêm bất kỳ thứ gì để chạy JavaFX trên Mac. Trên các hệ thống Windows, cả Firefox và IE đều hiển thị thông báo nếu chưa cài JVM. Firefox sau đó đưa ra một thư viện để giúp cài đặt JVM, còn IE chuyển hướng đến 1 trang web có các hướng dẫn để người dùng tải về và cài đặt JVM thủ công.

THAY THẾ AJAX?

Mặc dù có nhiều ứng dụng hấp dẫn nhưng Ajax có những hạn chế về bảo mật, tương thích trình duyệt, ghi dữ liệu cục bộ ... và nền tảng Ajax “thuần tuý” không hỗ trợ những tính năng đồ hoạ cao cấp (như “vector”) và video. Nhiều thư viện Ajax đã được phát triển (hiện có trên 200 thư viện được liệt kê tại AjaxPatterns.org) khắc phục những khiếm khuyết này, nhưng không nền tảng dựa trên Ajax nào (kể cả Yahoo! UI Library hay Dojo) có được những tính năng như Flex, Silverlight và JavaFX. Các giải pháp RIA không giới hạn trong giao diện người dùng, trình xử lý văn bản xây dựng trên Flex – BuzzWord là minh chứng về ứng dụng RIA hoàn chỉnh không thua kém ứng dụng Ajax nổi tiếng là Google Docs.

Tuy nhiên, các giải pháp RIA hiện tại vẫn chưa đủ sức thay thế hoàn toàn Ajax. Dưới đây là một số lý do:

• Các giải pháp RIA đều yêu cầu cài đặt thư viện bổ sung trình duyệt, trong khi Ajax được hỗ trợ sẵn.

• Các giải pháp RIA dựa trên Flash thường có dung lượng lớn hơn so với giải pháp dựa trên Ajax. Dung lượng tải về lớn sẽ làm chậm việc khởi chạy ứng dụng.

• Không giống các giải pháp RIA (ngoại trừ Flex SDK và JavaFX Script), Ajax được xây dựng trên các chuẩn mở.

• Flex, Silverlight và JavaFX đều dùng ngôn ngữ riêng, ngược lại Ajax dựa trên JavaScript quen thuộc với hầu hết các nhà phát triển web và sẵn sàng “hợp tác” với các công nghệ phổ biến khác như Ruby-on-Rails, PHP, Java và .NET.

Thật may, các yếu tố hạn chế của Ajax và RIA nói chung không trùng nhau. Vì vậy Ajax và các công nghệ RIA có thể kết hợp để tạo nên ứng dụng mạnh như YouTube và SlideShare. Cả Adobe Flex (thông qua Flex-Ajax Bridge), Microsoft Silverligh và JavaFX đều cung cấp khả năng làm việc với Ajax.

Software Architecture chưa bao giờ là lĩnh vực hấp dẫn cả, khi nào cũng khô như ngói. Tác giả chỉ mạn phép dùng ngôn ngữ “cây nhà lá vườn” để giúp các bạn mới học tiếp xúc thêm. Sai sót là không thể tránh khỏi. Và hy vọng các bạn sẽ không ngủ gục khi chỉ mới đọc xong trang một.

Component-Centric

Software Engineering phát triển rất nhanh, tuy nhiên vẫn còn ở giai đoạn chập chững tập đi mà thôi. Để thiết kế và phát triển một phần mềm tiêu tốn rất nhiều tài nguyên, nhưng sau đó thì không sử dụng lại được nữa. Lấy ví dụ, để viết chương trình quản lý kho, bạn sẽ phải xử lý SQL, tạo form, tạo report, security. Sau đó, khách hàng yêu cầu viết chương trình kế tóan thì bạn lại phải viết lại những yêu cầu trên… từ đầu. Nếu thiết kế xe ô tô cũng giống như thiết kế phần mềm thì khi thiết kế model 2008, bạn sẽ phải xây lại đường đi riêng, thiết kế lại bánh xe, đèn, vô lăng, vv…

Bạn nghĩ sao nếu như thiết kế một phần mềm mới cũng đơn giản như thiết kế một cái tivi? Chẳng hạn như bạn chỉ việc gắn bộ nguồn, mạch bắt sóng, mạch điều khiển, gắn đèn hình vào là xong. Bạn không cần phải đi thiết kế lại từng phần chi tiết tỉ mỉ làm gì cả. Giả sử bạn không thiết kế tivi nữa mà xoay sang thiết kế máy tính xách tay thì cũng thế, chỉ việc gắn bộ nguồn, đèn hình, mạch điều khiển. Điểm hay là ở chỗ một con transistor trong laptop hay tivi thì cũng y như nhau mà thôi.

Quay lại ví dụ viết chương trình quản lý kho, giả sử ta có một máy tính siêu thông minh thì chỉ việc bảo nó: gắn cục Security A101, cục Data 2.0, cục Web GUI 8.1 rồi dán nhãn My Big Soft vào đó rồi nó tự động làm hết mọi chuyện cho ta. Rất tiếc, đây chỉ là ước mơ, còn thực tế thì mỗi developer hằng ngày vẫn phải còng lưng viết code như những cái máy đến mờ mắt, viết đi viết lại, viết tới viết lui như một điệp khúc bất tận.

May thay, Component-centric đang ngày nhiều hơn và thông minh hơn. Nếu bạn là dân Java, hãy nghĩ đến Java Beans. Nếu bạn là dân .NET, hãy nghĩ đến Application Block, đến Web-parts. Hay đơn giản hơn, ai cũng đã gặp nhiều lần: UI controls (button, label, listbox, checkbox, …)

Một component không phải là một class, và component-centric cũng không phải là OOP (Object Oriented Programming). Class đơn thuần chỉ là gom nhiều code có cùng mục đích vào chung một chỗ. OOP là xem vấn đề như một hoặc nhiều đối tượng (có thuộc tính, có method) để phân lọai mối quan hệ của chúng. Còn component-centric có nghĩa là lập trình để mỗi phần mang tính độc lập, có thể thay thế, có thể tái sử dụng lại cho những vấn đề khác nhau.

Giả sử bây giờ bạn phải viết trò chơi Snake. (User điều khiển con rắn chạy ăn mồi, mỗi khi ăn được cục mồi thì con rắn dài ra thêm một đọan).

1/ Class: nếu bạn là dân “pro” thì có lẽ bạn chỉ cần viết 1, cùng lắm là 2 class để viết trò chơi tí hon này.

2/ OOP: bạn sẽ bắt đầu viết các class: Snake, Food, Player.

3/ Component-centric: bạn chả viết gì cả

Bạn sẽ ngồi phân tích xem đâu là điểm chung, đâu là điểm riêng, đâu là phần chi tiết chỉ áp dụng riêng cho trò chơi này, đâu là phần bạn có thể abstract nó. Có lẽ bạn sẽ thiết kế ra các component sau: Game Engine, Graphic Engine, Rule Engine, Resouces Manager, User Controller, vv…

Ah, như vậy sau khi thiết kế xong, trò Snake chỉ là sản phẩm phụ mà thôi. Với những component sẵn có, bạn dư sức có thể viết DOOM 2008.

Component-centric development và cao hơn nữa là software-manufacturing đang được đầu tư và phát triển rất nhiều. Nếu bạn có hứng thú, hãy tham khảo thêm:

- Microsoft Application Block

- Enterprise Java Bean

- Java Frameworks and Components: Accelerate Your Web Application Development – Michael Nash. Cambridge University Press 2003 ISBN: 0521520592

N-Tier Layer

Nếu như Component là từng bộ phận nhỏ, đóng vai trò như một “black-box”, ta chỉ quan tâm tới chức năng của nó là chính, thì Layer lại giống như một bản mạch in gồm nhiều components đã được thiết kế sẵn. Lấy ví dụ như Graphics Card. Mở các máy PC hiện tại ra bạn sẽ thấy loại card này. Điểm thú vị là bạn không phải “se duyên” với cái card ấy mãi mãi. Khi nào túi tiền rủng rỉnh, bạn có thể mua card khác mới hơn, nhanh hơn, xịn hơn để gắn vào và quên béng mất cái card cũ (hoặc rao bán chợ trời). Có khi nào bạn suy nghĩ lại và ngạc nhiên tại sao cái máy tính cũ kỹ đời 1998 của mình lại có khả năng chấp nhận card 3D đời 2008 không? Thật là một kỳ quan, bạn nhỉ ?

Software cũng thế, nếu thiết kế chia một software ra thành nhiều layer thì sẽ tăng tính tái sử dụng, và quan trọng nhất là: chịu đựng được với thay đổi trong tương lai. Bạn hãy nghĩ thế này nhé: nếu Windows mà được thiết kế tốt hơn thì bạn đã có thể chơi game của Windows, chạy web server của Linux, và chạy chương trình đồ họa của Macintosh ngay trong hệ điều hành Windows.

Bài viết này sẽ đề cập đến 3 layer cơ bản nhất mà đa số các chương trình từ bé đến khổng lồ, từ bài tập của sinh viên đến game online kinh phí hàng trăm triệu đô đều cần phải có.

Data Access Layer
Nếu bạn biết “Select * from Products Where CustID = @ID” nghĩa là gì nhưng bạn không cần phải dùng đến nó mỗi ngày thì bạn may mắn quá, bạn có thể bỏ qua phần này.

Nếu bạn không những biết mà còn thuộc nằm lòng đến 80% T-SQL, hoặc bạn nằm mơ cũng nghĩ đến SQL, đến StoreProc, đến Triggers, thì bạn rất cần phải dùng đến DAL. Có lẽ 90% developers, nhất là ở Việt Nam trong thời điểm hiện tại, rơi vào trường hợp này.

Trước hết, hãy nói Data Access Object là gì đã. Khi lập trình cơ sở dữ liệu, bạn phải lặp đi lặp lại thao tác sau:

- Create connection

- Create SQL command

- Execute SQL

- Process results

Chán quá, bugs nhiều quá. Database bạn dùng là relational, mọi thứ đều trong table, table và table. Trong khi đó, bạn lại thích lập trình OOP cơ. Thế là bằng cách này hay cách khác, cho dù bạn biết hay không biết, bạn sẽ quay sang làm theo kiểu sau: định nghĩa class chuyên nói chuyện với database. Lấy ví dụ như class sau:

Class ProductDAO {
Connection GetConnection();

bool Insert(int ID, string Name);

DataSet GetAllProducts();

DataSet GetProductByName(string Name);

Bool Delete(int ID);
}

Phương pháp bạn vừa làm chính là Data Access Object. Bạn có thể viết tay, bạn cũng có thể dùng các công cụ như CodeSmith để làm giùm bạn. Xin chúc mừng !!! Bạn đã đỡ khổ hơn trước nhiều rồi đấy.

Nhưng mà, cũng xin… chia buồn với bạn luôn. Bạn nghĩ sao nếu database bên dưới thay đổi ? Bạn sẽ dùng CodeSmith để generate lại ư? Thế mấy cái business logic của bạn khi generate lại đi tong hết thì sao? Thế lỡ năm sau CodeSmith dẹp tiệm thì sao, bạn phải sửa lại bằng tay à? Thế lỡ database không phải của bạn, mà bạn phải integrate vào database bự xự có sẵn của khách hàng thì sao? Chua đấy bạn ạ.

Chưa kể là dùng Data Access Object làm tăng số lượng class lên rất nhiều (cứ mỗi table trong database cần ít nhất 1 class, thậm chí có thể là 3, 4 classes). Mỗi class cần ít nhất 4 method (Create, Read, Update, Delete). Chưa kể là mỗi kiểu select khác nhau lại phải viết method mới. Điều này đồng nghĩa với việc testing cũng tăng lên đến chóng mặt.

Bạn nghĩ sao nếu bạn chỉ cần định nghĩa một class thế này:

Class Product {

Int ID;

String Name;

String Description;

}

Xong, chỉ có thế thôi !!! Nếu cần thêm sản phẩm mới vào database thì làm như sau:

Product p = new Product();

p.Name = “Some product”;

Database.AddNew(p);

Nếu cần query một sản phẩm thì chỉ cần thế này:

Product p = Database.Get(typeof(Product), Name = “ProductA”);

Rất đơn giản, phải không bạn? Cái đẹp là ở chỗ nếu có thêm nhiều table nữa thì cũng thế, bạn chả phải viết thêm nhiều methods chi cho mệt cả, chỉ định nghĩa class của bạn ở mức đơn giản nhất. Và khoái nhất là bạn không cần phải viết thêm một mớ test để kiểm tra việc truy xuất class đó.

Đây chính là chức năng chính của Data Access Layer.

Nếu thích, bạn có thể tham khảo:

- Data Access Layer trong Microsoft Application Block

- O/R Mapping (Object-to-Relational Mapping): Wilson O/R for .NET, ORM.Net, Object Space

- Java Persistence for Relational Databases – Richard Sperko. Apress 2003 - ISBN:1590590716

Lưu ý: Persistence Layer về cơ bản có cùng tính năng như Data Access Layer. Tuy nhiên, Persistence Layer có khái niệm và cách thức thực hiện khác với DAL một tí, mỗi loại có cái hay và cái dở riêng.

Business Object Layer
Business Object rất thú vị ở chỗ chương trình nào cũng cần có nó, nhưng lại chẳng có framework hay standard chuẩn nào cho bạn cả. Đơn giản là vì business object thay đổi xoành xoạch tùy theo yêu cầu cụ thể của từng business khác nhau.

Trong đa số trường hợp, Business Object sẽ được thiết kế rất gần giống với Data Object (chỉ chứa dữ liệu hoặc nói chuyện với cơ sở dữ liệu), chỉ khác ở chỗ thêm vào đó một ít validation rule và business rule (ví dụ: nếu tài khỏan chỉ có 1.000 thì không cho phép rút 1 triệu đồng).

Tuy nhiên, có những vấn đề lặp đi lặp lại mà business nào cũng phải gặp, chẳng hạn như: transaction, distribution, validation. Khi thiết kế Business Object, một architect bao giờ cũng đau đầu với những câu hỏi chẳng hạn như: nên stored proc hay không? Nên validate ở đâu (trong DBMS, trong server, hay trong client)? Object của tui như thế có scalable không, có nhanh hay không? vv.. và vv…

Business Object Layer là một lớp abstraction cho phép giải quyết những vấn đề thường gặp khi thiết kế business logic. Với một framework tốt, Business Object Layer đóng vai trò rất quan trọng vì nó là “sợi chỉ đỏ xuyên suốt các layers”.

Vì nhiệm vụ của Business Object rất đa dạng và cũng có nhiều khó khăn khác nhau nên Business Object Layer thường được đóng gói với tên gọi Application Frameworks. Lập trình viên bình thường và những project vừa và nhỏ ít có cơ hội tiếp xúc. Những framework thương mại chủ yếu dành cho các project lớn và đòi hỏi phải học chuyên sâu. Những framework này cũng thường “overkill” với project nhỏ. Tuy nhiên, nếu đơn giản hóa vấn đề thì khi bạn tự viết một Business Object Layer cho bản thân sẽ tăng năng suất của bạn lên rất cao.

Tài liệu tham khảo:

C- C# Expert Business Object (Cuốn này hơi khó kiếm, nhưng là sách quý nên có)

Presentation Layer
Hồi lúc trước, mình là tín đồ của nàng Athena xinh đẹp (nói cách khác là dân ghiền Delphi). Khi chuyển sang C#, mình đã thất vọng tràn trề. Lẽ ra trong Delphi thiết kế một form có master/detail view chỉ mất 1 phút thì trong C#, mình phải mất 2 trang code (hồi lúc mới học thì mất cả tuần vì không hiểu làm sao để sử dụng cái datagrid). Sau đó, chuyển sang ASP.NET thì … càng đau khổ hơn nữa.

Tại sao ta lại phải khổ thế nhỉ? Viết form cực kỳ chua. (Hỏi mấy anh lập trình Java với AWT thì biết). Với các ngôn ngữ hiện đại ngày nay thì ta có designer làm sẵn cho, chỉ việc kéo thả bụp bụp là xong. Các bộ controls thương mại hiện giờ có rất nhiều, mỗi người một vẻ. Với những bộ lớn chẳng hạn như của ComponentOne, Janus System, họ gắn luôn mác Presentation Layer vào sản phẩm của họ. Có lý phần nào vì đó là những component phục vụ cho việc trình bày thông tin.

Nhưng mà, vẫn còn nhiều vấn đề tồn đọng:

1/ Lệ thuộc vào control nhất định. Hãy quên chuyện thay thế grid của Winform bằng grid của Developer Express mà không cần phải sửa lại code đi nhé. Nhiều khi không chỉ sửa code mà bạn cần phải mướn developer khác để sử dụng UI controls mới.

2/ Không có chuẩn. Mỗi bộ controls là một framework mới cần phải học và không tương thích gì với nhau cả. Đừng mơ có chuyện viết code năm nay, 2 năm sau quay lại thay giao diện cái rẹt.

3/ Logic code và UI code quyện lẫn vào nhau. Visual Studio 2005 cố gắng giúp (lừa) bạn tránh chuyện này bằng partial class, chia code thành 2 file (bắt chước asp.net, file aspx riêng, file code-behind riêng)

4/ Visual rất luộm thuộm. Bạn nghĩ sao nếu bạn viết chương trình đồng hồ Analog (có kim giờ, phút, giây quay vòng vòng), nhưng ngày mai bạn thích đồng hồ Digital (chỉ hiển thị số). Bạn có thể nào giữ y nguyên logic code, chỉ cần thay visual elements cái rẹt trong 5 giây không? Quên chuyện đó đi.

5/ Data-binding: Rất phiền. Những control sẵn có khiến cho bạn trở thành gà công nghiệp và lệ thuộc vào nó. Điều đáng buồn là khi bạn cần binding phức tạp một tí thì vẫn cứ phải “chân lấm tay bùn”, quay trở lại viết code từng dòng một, xử lý event từng chỗ một.

Những năm gần đây xu hướng Declarative Programming gây được nhiều sự chú ý. Lấy ví dụ như thay vì viết code tạo form như sau:

Button b = new Button();

b.SetBounds(100,100,50,25);

b.Text = “Click me”;

b.Click += new EventHandler(b_OnClick);

Thì ta có thể tạo một file XML như sau:

Click me

Rất giống lập trình web, phải không bạn? Vâng, web chính là thuở ban đầu của declarative programming. Bạn thử tưởng tượng cũng một file XML đó, bạn có thể dùng làm windows application, bạn có thể dùng làm webform, có thể dùng cho Flash, có thể dùng cho Macintosh thì sao?

Có mà nằm mơ !

Hẳn bạn sẽ thốt lên như thế. Vâng, rất tiếc rằng ở thời điểm hiện tại chưa có Presentation Layer nào thực hiện được mơ ước “write once, display anywhere”. Tuy nhiên, ít ra thì bạn không còn phải viết code từng dòng bằng tay nữa, bạn có thể nhờ Presentation Layer để tự validate inputs, tự generate forms, tự layout, vv…

Để xem thêm về lĩnh vực này, bạn hãy research các chủ đề sau:
- Avalon, MyXaml, XAML, XAMLon

- Flex

- XUL

Design Patterns

Design patterns nôm na ra là cách thức giải quyết cho những vấn đề thường gặp. Điều đáng buồn là các sách về design patterns khô như ngói, nhạt như vôi. Nhưng tin vui: design pattern là công cụ sẽ giúp bạn tăng lương lên gấp đôi (hoặc gấp trăm lần). Đơn giản vì design pattern chính là kinh nghiệm xương máu của những architect đi trước đúc kết ra được. Khi bạn học design pattern, bạn sẽ có những kinh nghiệm vượt trước năng lực của mình.

Tài liệu để đọc về design pattern hiện có rất nhiều. Mình chỉ mạn phép góp ý với các bạn một câu khi học về lĩnh vực này: “hãy nắm lấy ý tưởng là chính, đừng chú trọng vào code”. Nếu bạn chỉ nhìn vào code ví dụ, bạn sẽ dễ bị “tẩu hỏa nhập ma”, sẽ bị lệ thuộc vào code, nhìn thấy cái nào cũng na ná nhau, và tệ hại nhất là chẳng biết áp dụng vào cho cái gì khác ngòai ví dụ ra.

Tài liệu để tham khảo:

- www.dofactory.com

- www.c2.com

- C

- C# Design Pattern – A tutorial

- Software Architecture Design Patterns in Java – Partha Kuchana

Về layers và thiết kế ở mức cao một tí, đọc các sách sau:

- Enterprise Solution Patterns Using Microsoft.NET version 2.0 – MS Press

- .NET Patterns: Architecture, Design, and Process – Christian Thilmany – Addison Wesley ISBN: 0-32-113002-2

Kết luận

Viết bài này mình cứ sợ “múa rìu qua mắt thợ” bởi vì người tài giỏi của Việt Nam cũng có rất nhiều. Tuy nhiên, có nhiều bạn cứ nói mình mãi là hãy viết đi, và qua thực tế đi dạy học được một thời gian, mình thấy những bạn sinh viên mới ra trường biết rất ít về thiết kế phần mềm, dẫn đến hậu quả là các bạn ấy đa phần giống như gà công nghiệp, và hiển nhiên code của các bạn cũng như một tô mì ăn liền: ăn đỡ đói thì được, còn ăn nhiều thì hơi ngán.

Hy vọng bài viết này sẽ giúp các bạn có được một số gợi ý để đào sâu nghiên cứu thêm. Chúc các bạn luôn giữ niềm đam mê lập trình của mình.

Kinh tế thế giới đang khủng hoảng, CNTT cũng như những ngành khác có những khó khăn nhất định. Môi trường làm việc cạnh tranh hơn, yêu cầu của những nhà tuyển dụng đối với kỹ năng của bạn cũng cao hơn.

Nếu bạn là một người lập trình, mong muốn đạt được thành công cao trong nghề nghiệp, cũng như muốn bổ sung vào bản lý lịch của mình những kỹ năng ấn tượng, cần thiết, những lời khuyên sau đây sẽ giúp bạn cải thiện khả năng để làm việc với những dự án trong tương lai năm năm tới. Bài được viết được tác giả hướng tới đội ngũ kỹ sư IT ở Mỹ, nhưng người dịch nhận thấy nó cũng phù hợp ở môi trường CNTT của Việt Nam.

1. Một trong ba kỹ năng lớn (.NET, Java, PHP)

Đây là ba ngôn ngữ đang thịnh hành nhất trong thế giới lập trình. Có thể nói các dự án lớn phần lớn thực hiện bởi một trong ba ngôn ngữ này. Bạn không chỉ cần hiểu được những kỹ năng lập trình cơ bản, then chốt, mà vì một dự án có thể tổng hợp nhiều chức năng khác nhau, bởi vậy bạn phải hiểu sâu cách tổ chức các nền tảng (frameworks) và thư viện lập trình (libraries) của những hệ thống này một cách cặn kẽ.

2. Các ứng dụng Internet tích hợp - Rich Internet Applications (RIAs)

Dù yêu hay ghét nó, trong một vài năm gần đây, Flash trở nên quan trọng trong các ứng dụng hơn là những hình ảnh hoạt họa thông thường. Flash cũng có thêm các chức năng mở rộng cho form hay Flex và AIRs. Các chương trình tạo Flash như JavaFx và Silverlight, cải thiện nhiều tính năng và hiệu suất. HTML 5 đang tích hợp những các tính năng RIAs, bao gồm kết nối cơ sở dữ liệu, đặt các tiêu chuẩn W3C vào trong AJAX. Trong tương lai gần, việc tham dự một dự án RIAs là một sự khác biệt trong đơn xin việc của bạn.

3. Phát triển WEB

Phát triển web không bao giờ lỗi thời. Nhiều công ty vẫn cần rất nhiều nhà phát triển hiểu biết các nền tảng web cơ bản cũng như nâng cao, bởi vậy những hiểu biết về JavaScript, CSS, và HTML vẫn còn rất cần trong vòng năm năm tới.

4. Dịch vụ web (web services)

REST hay SOAP? JSON hay XML? Tùy thuộc những đặc điểm cụ thể của dự án để đưa ra những câu trả lời sử dụng công nghệ phát triển dịch vụ web nào. Để phát triển một dịch vụ web thì không thể không biết đến những công nghệ này.

5. Kỹ năng mềm (soft skills)

Có một thực tế là người lập trình không chỉ hoàn thiện kỹ năng về kỹ thuật của mình mà còn cần có những kỹ năng bên ngoài IT. Đó là kỹ năng về giao tiếp, hội nghị, hội thảo, gặp gỡ, xử lý các phản hồi từ khách hàng.

Ví dụ, một giám đốc tài chính muốn thay đổi một luật về kế toán thì không thể làm việc với nhân viên IT để cập nhật hệ thống. Một người quản lý điều hành không thể thay đổi một tiến trình xử lý cuộc gọi nếu như không có IT. Khách hàng cũng thường xuyên tiếp xúc với đội ngũ phát triển để chắc chắn rằng những yêu cầu của họ được đáp ứng. Người lập trình sau khi ý thức trau dồi những kỹ năng mềm này sẽ có giá trị hơn trong người tuyển dụng, và có thể có một vị trí cao hơn trong nghề nghiệp.

6. Một ngôn ngữ lập trình động/chức năng (dynamic/functional programming language)

Đó là các ngôn ngữ như Ruby, Python, F#, và Groovy. Ví dụ trong hệ thống LINQ của .NET là một dạng của kỹ thuật lập trình chức năng. Học một trong các ngôn ngữ này không chỉ cải thiện đơn xin việc của bạn mà còn mở ra nhiều chân trời mới. Rất nhiều người lập trình đỉnh cao mà tác giả gặp đều khuyên học ít nhất một ngôn ngữ lập trình chức năng để học cách nghĩ mới.

7. Phương pháp luận Agile - Agile methodologies

Ngày nay, phương pháp luận trong công nghệ phát triển phần mềm Agile đã thật sự trở nên phổ biến. Và một nhà phát triển lập trình sẽ làm việc trong các dự án lớn nên cần hiểu biết rộng phương pháp này để có thể dễ dàng tham dự việc phát triển các dự án lớn.

8. Hiểu biết lĩnh vực

Với phương thức Agile, đội ngũ phát triển cũng sẽ có những góc nhìn như các đối tác trong việc trình bày hiểu biết một dự án. Điều này có ý nghĩa người lập trình cần phải có những hiểu biết lĩnh vực để có thể đóng góp những ý kiến có giá trị và âm thầm. Với Agile, một người lập trình có thể nói, chức năng này, chức năng kia nên được đưa vào bởi vì nó sẽ cho chúng ta nhiều lợi ích sau này. Để làm được điều đó họ phải có một sự hiểu biết sâu rộng trong các lĩnh vực chính liên quan đến dự án.

9. Công cụ “dọn vệ sinh” tích hợp

Một vài năm trước đây, nhiều công ty không cần các hệ thống theo dõi lỗi, cập nhật phiên bản và các công cụ tương tự. Đó chỉ là một lựa chọn của người lập trình với các lựa chọn trong môi trường phát triển tích hợp (IDE) của họ. Hiện nay có nhiều hệ thống tương tự được ra đời như Microsoft Visual Studio Team System, chất lượng cao, mã nguồn mở, tổ chức các công cụ thường dùng nói trên thành một bộ ứng dụng chung. Người lập trình cần phải biết nhiều hơn những gì họ chỉ kiểm tra code hay sử dụng hệ thống Virtual Machine để xây dựng môi trường testing - kiểm tra phần mềm.

10. Lập trình di động

Cuối thập niên 1990, phát triển web nổi lên như một dòng chủ đạo và trước đó là những ứng dụng để bàn. Trong năm 2008, xu hướng phát triển lập trình di động phổ biến là trở nên quan trọng. Có hai cách tiếp cận, là các ứng dụng web được thiết kế lập trình trên điện thoại đi động, là kiểu lập trình RIA, và các ứng dụng chạy trực tiếp trên điện thoại đi động. Bởi vậy hoàn thiện kỹ năng lập trình di dộng cũng mang đến cho bạn nhiều cơ hội nghề nghiệp trong tương lai.

Rất nhiều người tìm đến với Java là do yêu cầu của dự án, chẳng hạn cần 1 website viết bằng JSP + Oracle, nghiên cứu uPortal hoặc những sinh viên muốn viết game cho mobile. Họ bắt đầu học Java như thế đấy.

Gần đây trên diendantinhoc.com, có một cậu kỹ sư hay cử nhân gì đó tuyên bố một khi đã học xong đại học thì họ chỉ cần mất 2-3 ngày để có thể thành thạo (một cách thuần thục) một ngôn ngữ lập trình. Và cậu ta tự nhận mình là ngu nên học hết 1 tuần. Còn tôi, hơn 3 năm trời học Java và đến giờ tôi vẫn còn đang học.

Có lẽ vì là một coder, phần vì trí thông minh của mình thuộc hàng chậm phát triển lại không được đào tạo chính quy nên tôi đã học Java hết hơn 3 năm rồi và hiện tại nồi cơm của tôi là Java.

Java đúng là mênh mông thật, rất nhiều, rất nhiều công nghệ, rất nhiều giải pháp, rất nhiều những sản phẩm nguồn mở. Vì lẽ đó, nhiều coder bắt tay vào học Java thường bị choáng ngợp bởi có quá nhiều thứ để học hỏi ở Java. Vậy thì bắt đầu từ đâu nhỉ ?

Vào java.sun.com download bản JDK mới nhất và dùng một text editor để học nó. Dĩ nhiên tôi không dùng Nodepad rồi vì nó quá sơ sài. Với những người thành thạo Linux có lẽ nên dùng Vi là thứ tốt nhất, còn Windows, bản thân tôi dùng TextPad, sau khi cài đặt (JDK và TextPad) hãy mở TextPad ra gõ vào chương trình nổi tiếng và thông dụng nhất System.out “Hello World !”, nhấn crtl-1 để dịch, nhấn ctrl-2 để chạy.

Thế là bạn đã bắt đầu học Java. Nên download thêm từ java.sun.com gói java doc để có được API Specification trong quá trình học và làm việc với Java.

Một kẻ mù mờ như tôi thì điều đầu tiên là phải thành thạo ngữ pháp, do đó, tôi thường kiếm những bài nho nhỏ để viết thử cho đến khi thuần thục cú pháp Java, chẳng hạn các bài toán sắp xếp, tìm kiếm số nguyên, các bài toán quản lý điểm chẳng hạn. Mục đích duy nhất khi viết chúng là để làm quen dần với cú pháp của một chương trình Java.

Tôi không thể tìm hiểu ngay bản chất của Java là gì ? Chẳng hạn, như làm thế nào để Virtual Machine chạy một class, tại sao lại là máy ảo, bản chất của Object, điều tôi quan tâm đầu tiên là làm sao biến mình thành một cái máy gõ code Java. Tôi học như một cái máy gõ chữ vậy.

Sau khi đã thuần thục ngữ pháp Java, tôi bắt đầu đi tìm hiểu sơ đẳng những đặc điểm của một chương trình Java, chẳng hạn class, package là gì, thừa kế, interface đóng vai trò như thế nào, viết như vậy là một chương trình cấu trúc hay một hướng đối tượng. Dĩ nhiên tôi không thể hiểu rành mạch ngay được mà chỉ hiểu một chút ít. Sau khi tìm hiểu sơ sơ những vấn đề đó, tôi bắt tay vào tìm hiểu những thư viện trong Java.

Viết một cửa số bằng AWT, điều này làm tôi sung sướng vì bằng Java tôi có thể nhìn thấy kết quả của mình là một ứng dụng đồ họa nho nhỏ, tôi tìm hiểu về AWT để viết những bài tập bé bé, chẳng hạn một cửa sổ giao diện quản lý, cài đặt các action. Tuy nhiên, không nên mất nhiều thời gian vào AWT, tôi quay sang học java.lang và java.util.

Với java.lang đây là gói bao gồm rất nhiều những lớp cơ bản, String chẳng hạn, dĩ nhiên là phải làm thuần thục với string rồi ( cắt 1 string, thay thế từ, tìm vị trí từ,...) những bài tập rất nhỏ. Tiếp theo đó là StringBuffer, và ở Java 5 có một người anh em của nó là StringBuilder. Tôi hiểu sơ sơ về StringBuffer, nghĩa là chúng làm việc nhanh hơn khi nối string. Trong java.lang còn một lớp nữa là lớp Math, cũng cần tìm hiểu các hàm mà lớp này cung cấp để viết các bài tập nhỏ. Vậy là ok, tôi đã biết một số lớp cơ bản trong java.lang.

java.util là gói tiếp theo tôi cần tìm hiểu, thử viết một bài toán về Vector, thêm bớt, xóa các thành phần, cái này giống “mảng động” quá. Sau Vector, tôi thử tìm hiểu lớp Date, in ngày tháng hiện tại, giờ giấc xem sao, tôi viết thử một chiếc đồng hồ bằng AWT có sử dụng lớp Calendar và lớp Date. java.util còn một lớp tôi cần phải học đó là Hashtable, viết một ví dụ cho phép đặt cặp giá trị key – value vào đối tượng của lớp Hashtable. Như vậy là tôi đã xong java.util.

Bây giờ đến một gói thứ 3, java.io. Lớp đầu tiên cần phải học trong java.io đó là File. Tạo và xóa một file, đo độ dài một file. Tất cả các hàm đều được cung cấp trong File.class và tôi chỉ cần tạo một object rồi System.out giá trị để kiểm nghiệm lại trong Java. Hai lớp tiếp theo tôi cần tìm hiểu trong java.io là FileReader và FileWriter, tôi dùng hai lớp này để đọc và ghi dữ liệu vào một file text đơn giản.

Sau khi làm việc được với java.util, tôi trở lại gói java.lang để tìm hiểu một lớp nữa, đó là java thread. Dĩ nhiên tôi không thể viết một ví dụ cỏn con về thread được, thế là google, tôi muốn tìm một ví dụ đơn giản nhất của thread.

Tôi gõ vào cụm từ import java.io + public void run() và thế là google trả về cả triệu kết quả cho tôi, trong một mớ hỗn độn, tôi cần tìm ra một ví dụ đơn giản về thread, okies, tôi tìm được rồi, copy và TextPad, ctrl-1 -> ctrl-2 và tôi chạy nó.

Từ ví dụ này tôi viết thử các ví dụ khác về thread, và tôi bắt đầu hiểu về thread. Sau khi đã nắm tương đối về thread tôi bắt đầu thử từ khóa synchronized, tôi viết một lớp có 2 thread, trong 2 thread cùng đọc một file và phương thức đọc file có synchronized.

Bây giờ tôi quay lại gói java.util để cài thử một ví dụ về ArrayList và tìm hiểu vì sao ArrayList cũng làm việc như Vector nhưng người ta lại cài những 2 lớp này. Tôi viết một ví dụ nhỏ có 2 thread cùng add dữ liệu vào 1 ArrayList và làm tương tự với Vector. Ở 2 ví dụ tôi có đo thời gian chạy, tôi dùng 1 vòng lặp while chạy 1000 lần, rồi 10000. Tôi thử rất nhiều lần như vậy thì đều thấy ArrayList add dữ liệu nhanh hơn.

Bây giờ tôi tìm hiểu từ khóa try catch, tôi lại dùng Google để tìm một ví dụ về try catch, sau khi hiểu sơ sơ tôi quay sang cài đặt các ví dụ có throws Exception. Hay quá, nếu có try catch, tôi có thể thông báo những lỗi xảy ra ở chương trình của tôi và chương trình vẫn tiếp tục làm việc, nếu không dùng try catch tôi thấy chương trình gặp lỗi và đơ luôn.

Qua hàng loạt những ví dụ, tôi bắt đầu hiểu sơ sơ về lập trình hướng đối tượng, tôi tìm muốn sách lý thuyết để đọc về chúng, okies tôi đã bắt đầu hiểu Java và tiếp tục tìm hiểu những thứ cần thiết cho công việc của tôi.

Java không đơn thuần là một ngôn ngữ, nó là cả một nền tảng lập trình, một cộng đồng hay một văn hóa. Với quan niệm của tôi, ai đó có thể thuần thục cú pháp trong Java nhưng hiểu hết những tư tưởng tồn tại trong Java thì có lẽ cũng phải mất từ 3-6 tháng với một người thông minh và được đào tạo rất bài bản.

Khi tìm hiểu Java, người ta thường không tìm hiểu kỹ những thành phần cơ bản của Java mà học vào một framework cụ thể với tư tưởng MVC. Đối với tôi, muốn giỏi lập trình java thì hai gói đầu tiên bạn phải thuần thục là java.lang và java.util. Tôi từng được một thạc sĩ CNTT hỏi trong đó có Queue và Stack không,...nếu không có thì chị sẽ tự cài lấy một cái, còn nếu có thì chị dùng ngay cho nó tiện.

Tôi không coi đó làm điều ngạc nhiên hoặc cũng không dám chê chị dốt hay có những ý nghĩ khác không hay bởi chị rất giỏi nên việc cài đặt những thứ đó với chị quá đơn giản, nhưng điều đó giống như việc phát minh bánh xe và rất lãng phí. Do vậy khi học Java, tôi luôn tâm niệm rằng tôi đang học cả một nền tảng chứ không phải là đang học một ngôn ngữ lập trình.

java.util là gói tôi thích nhất, bởi từ java.util, tôi kiểm nghiệm lại những lý thuyết về cấu trúc dữ liệu và giải thuật. Dĩ nhiên framework này không bao giờ đề cập hết được tất cả các thuật toán cũng như cấu trúc dữ liệu, nhưng tôi có thể tìm hiểu những vấn đề cơ bản ở đây rồi từ đó dùng google search thêm những đoạn code khác.

Có khá nhiều những thư viện ngoài cài đặt collections framework, Apache, Trove hay FastUtil chẳng hạn. Mục đích của những thư viện này là cải thiện tốc độ của collections framework và không phải là họ không thu được kết quả gì.

Điều đặc biệt hơn nữa là rất nhiều trường đại học trên thế giới cung cấp những cài đặt về cấu trúc dữ liệu và giải thuật , cũng có cái hay, cũng có cái dở. Tôi bắt đầu trả lời được một thắc mắc của mình là tại sao Java dùng merge-sort chứ không dùng quick-sort, và tại sao ở những phiên bản đầu java chậm, càng những phiên bản về sau thì càng nhanh hơn.

Gói tôi thích thứ 2 là gói java.util.concurrent , tôi tìm hiểu để thỏa mãn từ khóa synchronized và hiểu được vì sao java từng lạm dụng từ khóa này một cách quá đáng; tìm hiều các vấn đề về pooling.

Tôi cố gắng thuần thục java.io với hàng loạt lớp Reader và Writer rồi mở rộng khả năng hiểu biết của bản thân với java.nio. Tôi tìm hiểu về java.net rồi kiếm sách vở về networking đọc thêm, sau đó tự cài đặt các ví dụ, chương trình đầu tiên trong cuộc đời lập trình của tôi là C2 – chat và chơi cờ qua mạng là cách để tôi tìm hiểu về java.net. Cứ như vậy, tôi học java mãi cho đến tận bây giờ.

Theo quan điểm cá nhân tôi, nếu muốn lập trình tốt java bạn cần phải thuần thục những gói sau (bao gồm cả các gói con của nó) là : java.lang (java.math, java.lang.ref, java.lang.reflect ), java.util(java.util.concurrent, java.util.logging, java.util.prefs, java.util.regex, java.util.zip ), java.io (java.nio), java.net. Một khi đã vững những vấn đề và thư viện trong đó, bạn có thể học tiếp những framework như jdbc, swing, servlet+jsp, struts, jsf, hibernate,... để phục phụ trực tiếp vào công việc. Khi học java, tốt nhất đừng dùng các IDE như JBuilder, Eclipse hay Netbean, hãy dùng một TextEditor cố gắng gõ code nhiều nhất. Cũng đừng bao giờ cố gắng hiểu cặn kẽ những tư tưởng mà người ta đã cài đặt, hãy code và chạy, lúc đó bạn sẽ chiêm nghiệm được và khi đó, cầm lại cuốn sách đọc là hiểu rành mạch nhất.

Tôi thường vào những cộng đồng trên mạng để cập nhật những vấn đề cũng như tham khảo các bài viết của họ, tôi ít khi vào java.sun.com bởi các bài viết ở đó cũng không có nhiều bài hay. Nhiều người chọn theserverside.com để cập nhật công nghệ cho mình còn tôi, tôi chọn 2 trang chủ chốt là java.net và jroller.com.

Trên java.net, tôi bắt gặp rất nhiều vấn đề bao trùm cả 3 lĩnh vực j2se, j2ee và j2me, nhiều nhất vẫn là j2se. Ở đây có những bài viết rất tuyệt từ những người đang trực tiếp phát triển java hàng ngày. Còn jroller.com, một cộng đồng blogger từ nhiều nơi trên thế giới đề cập tất cả các chủ đề, khía cạnh và liên tục cập nhật.

Javalobby là một diễn đàn cũng tương đối thú vị, ở đó có những tranh luận tạo nhiều góc cạnh trong cái nhìn tổng thể về một chủ đề, còn article quý báu thì lại nằm rất nhiều trên javaworld.com. Tôi có một thói quen tệ, viết code chúa ghét là chèn những dòng comment rối tung rối mù lên, khi đọc, tôi khoái đọc code hơn là đọc chứ, bởi bản thân chúng gần như toát lên hết những vấn đề đã được đề cập.Ước gì có thể dùng photoshop vẽ ra được phần mềm chứ không cần phải code.

Bạn có 2 sự lựa chọn:
1: Sếp thì luôn luôn đúng.
2: Nếu bạn nghĩ Sếp không đúng, xem điều 1.

Sau khi xem bức tranh, hãy cho tôi biết bạn nghĩ sao về lựa chọn 1.

Bạn không thể sống với họ, nhưng càng không thể sống thiếu họ. Thích hay không, hầu hết chúng ta phải đối phó với một ông sếp, và cách chúng ta làm không chỉ ảnh hưởng đến tiến bộ sự nghiệp của chúng ta và cả lương mà còn tốt cho tinh thần. Sau đây là một số mẹo vặt để đối xử tốt hơn với sếp của bạn.

1. Hãy nhớ rằng: sếp là người hiểu biết

Bạn nghĩ rằng sếp không có khả năng đó? Hãy nhớ lời nói của Mark Twain, ông ta nói rằng khi 14 tuổi, cha của ông là người ngớ ngẩn đến nổi anh ấy không chụi nổi. Rồi anh ấy lớn lên, khi 21 tuổi, ông đã hết sức ngạc nhiên về những kiến thức mà ông ấy học được từ cha chỉ trong 7 năm. Hãy nghĩ rằng sếp của bạn thông minh hơn bạn nghĩ, và có thể đã từng ở vị trí của bạn, bạn sẽ đánh giá đúng sự việc. Dù không, một ông chủ xấu vẫn có thể đưa ra lời khuyên tốt.

Tôi nhớ những gì mà sếp đã nói với tôi vài năm trước. Ông ấy nói rằng tôi cần năng nổ hơn và làm bất cứ điều gì có ích hơn là nghỉ ngơi sau khi làm việc và chờ phân công việc mới.

Bạn vẫn có thể học từ ông sếp tệ. Phân tích tại sao ông tệ và quyết tâm tránh xa những điều đó nếu bạn muốn trở thành ông chủ tốt.

2. Nhận biết mục tiêu của sếp

Những người phát triển phần mềm thường quan tâm đến “mục đích”. Yêu cầu cả hệ thống phần mềm phải trực tiếp hoặc gián tiếp được dùng. Hay nói một cách khác là tìm ý nghĩa của từng đoạn code, để loại bỏ dư thừa.

Việc gì cũng vậy, cần cố gắng để nhìn thấy bức tranh to lớn hơn. Bạn cần biết cái gì sếp mong chờ ở bạn. Và cần biết rằng làm sao để công việc của bạn giúp ích cho sếp. Hãy chắc rằng những điều bạn đang làm không chỉ phù hợp với mô tả chi tiết công việc của bạn mà còn giúp đỡ sếp hoàn tất mục tiêu của ông ấy.

3. Cần biết những điều mà sếp mong chờ ở bạn

Khi tôi còn trẻ, có một lần tôi phàn nàn mẹ rằng: Con không có việc gì để làm hết mẹ à! “Calvin”, bà ấy trả lời, “Tại sao con không chơi piano đi?” Và đó là lần cuối cùng tôi phàn nàn với bà ấy về chủ đề đó.

Bạn có thể không biết những ước mơ của cha mẹ bạn là tốt đẹp khi bạn là đứa trẻ, nhưng không biết những mong đợi của sếp có thể sẽ phá hỏng sự nghiệp của bạn. Làm sao bạn có thể có thành tích tốt nếu bạn không biết mục tiêu của nó? Và nếu bạn biết mục tiêu, bạn có xác định chúng được ko?

Thỉnh thoảng, hãy kiểm tra với sếp về việc mà bạn đang làm? Khi bạn đã hoàn thành cái gì đó và chắc rằng sếp của bạn cũng nghĩ vậy. Nếu sếp bạn đã đánh giá về thành tích của bạn, đều đó sẽ tốt cho cả hai, vì vậy bạn có thời gian để sửa đổi khi sai hướng.

Trong thế giới của sự hoàn hảo, không bất ngờ nào có thể xảy ra trong suốt quá trình làm việc của bạn. Và nếu xảy ra, có thể là do sếp của bạn không truyền đạt tư tưởng, hay bạn thất bại trong việc tìm hiểu chúng. Đừng để điều đó xảy ra với bạn.

4. Chậm sửa đổi

Đừng trở thành một “nhân viên có vấn đề”, có một người sếp luôn luôn phải kiểm tra và theo sau. Để thay thế, cố gắng là một người mà sếp có thể tin tưởng. Điều đó có thể không thấy rõ ràng ngay lập tức, nhưng người sếp tốt sẽ thừa nhận và đánh giá cao điều đó.

Bạn có đang hoàn tất hoàn thành công việc của bạn? Dĩ nhiên là ko? Bạn hầu như mắc sai lầm và tạo ra vấn đề ít nhất 1 lần. Tuy nhiên, khi điều đó xảy ra, bạn hãy đi gặp sếp của bạn. Cố gắng không báo cáo những vấn đề. Hãy nghĩ ra vài giải pháp và chuẩn bị đưa ra đề nghị về kế hoạch của bạn đến sếp.

5. Đừng làm sếp ngạc nhiên

Đừng để sếp nghe được một điều xấu về bạn. Nói cách khác, nếu bạn đã gây ra vấn đề hay mắc phải sai lầm. Tốt hơn hãy trực tiếp nói với sếp – không phải từ khách hàng, từ đồng nghiệp và càng không phải từ chính sếp của sếp bạn. Bạn có phủ nhận sự ảnh hưởng đó không? Ngay sau đó, hãy gọi cho sếp của bạn và yêu cầu lời chỉ dẫn tường tận.

6. Bày tỏ lòng biết ơn với sếp về sự thành công của bạn

Khi khoảnh khắc đó đến: Bạn là đại diện cho nhóm của bạn, tiếp nhận khen thưởng hay thừa nhận khác từ sếp hay sếp của sếp bạn. Việc thích hợp để làm tại thời điểm này là biết ơn những người đã làm cho nó được như vậy, đặc biết là sếp bạn.

Cho biết rằng điều đó thật dễ dàng khi sếp bạn sẵn sàng giúp đỡ. Dù sếp bạn không làm được gì, hãy cố gắng nói một điều gì đó, nhưng đồng thời bạn chắc chắn điều đó phải đúng sự thật.

Hãy nhớ những gì chúng ta đã thảo luận ở trên – thậm chí một ông sếp tồi có thể đưa ra những lời khuyên tốt. Sếp của bạn làm bạn chán nản hay làm một điều gì đó khó khăn? Có lẻ, trong trường hợp này, bạn có thể cảm ơn sếp đã giúp đỡ bạn “giữ cho mọi thứ triển vọng” hay để “kiểm tra sự minh mẩn” hay giúp đỡ bạn “nhìn thấy vấn đề từ nhiều điểm”.

7. Đừng chỉ trích bản thân

Hầu hết chúng ta quá phức tạp với công việc của mình, rằng nó cứng nhắc và khó tách rời bản thân ra khỏi nó. Vì vậy khi một người nào đó phê bình công việc của chúng ta. Chúng ta quan niệm sự phê bình như là sự công kích cá nhân. Cách phản ứng đó có thể gây cản trở sự phát triển của và sự tiến bộ của chúng ta.

Khi sếp của bạn (hay người khác) phê bình công việc của bạn, cố gắng giả vờ như công việc đó được làm bởi một người khác. Và rồi, khảo sát nghiên cứu nó như là một người thứ ba có thể và kiểm tra giá trị của lời phê phán đó.

Một ông chủ thông minh sẽ thấy rõ sự thành công của bạn ràng buộc đến sự thành công của sếp ông ấy. Bởi vậy, cho nên sếp có sự quan tâm trong viêc làm của bạn. Hơn nữa, lời phê bình từ sếp có thể là một dấu hiệu mà sếp có những mông đợi cao hơn từ bạn.

Khi tôi bắt đầu làm việc, tôi đã bị lật đỗ bởi vì sếp của tôi giao cho tôi nhiệm vụ mà tôi suy nghĩ là quá khó khăn. Tôi bàn luận sự quan tâm của tôi với bạn của cha tôi, người đã từng làm việc trong lĩnh vực giống như tôi đang làm. Tôi vẫn nhớ lời khuyên của người bạn đó. “Cavin” ông ấy nói rằng: “[tên của sếp] đã giao cho bạn nhiệm vụ đó bởi vì ông ấy nghĩ rằng bạn có thể làm công việc đó tốt”.

8. Hãy nhớ rằng sếp của bạn cũng có sếp.

Chúng ta đã thảo luận trước đó sự quan trọng của việc biết những mục tiêu của sếp bạn. Trong tĩnh mạch như vậy, ý thức được rằng sếp của bạn có một ông sếp nữa. Bạn có thể sử dụng thực tế kia để xây dựng mối quan hệ cộng tác với sếp của mình, việc có mối quan hệ cộng tác kia đưa cho sếp bạn có ấn tượng tốt hơn về bạn và cho bạn cái nhìn rõ ràng về sếp của sếp bạn.

9. Đừng chỉ trích sếp

Việc chuyển chỉ trích sếp bạn có thể giới hạn sự nghiệp của bạn. Bởi vậy, cẩn thận việc chỉ trích sếp của bạn ở nơi công cộng, như người đã làm với cha tôi. Trong khi ông ta đang làm cộng sự cho một nhóm biểu diễn. Ông ta đã nói đến Viện Bách Khoa Worcester. Nhưng lại phát âm nó như “Woo-ster”. Người đó đã nói: “Wellington, bạn đã sai”. Nó là “Woo-ches-ter.” Thật may mắn, cha tôi đã nhanh trí làm lệch lời bình luận với câu trả lời sau đây: “Tôi lấy làm tiếc, xin tha lỗi cho tôi. Tiếng anh chỉ là ngôn ngữ thứ năm của tôi”. Sự khôi hài của cha tôi đã hủy bỏ hoàn cảnh đó.

10. Quản lý sếp của bạn khi cần thiết

Vươn lên trong sự nghiệp bằng cách hãy làm nhiều hơn là ngồi lại và chờ đợi những mệnh lệnh. Bạn phải có sáng kiến, tìm kiếm những cơ hội để giải quyết các vấn đề. Tận dụng bất kỳ tổ chức nào mà sếp của bạn có mối quan hệ. Giải thích với sếp về những kế hoạch của bạn và tại sao chúng quyết định cho doanh nghiệp thành đạt.

Yêu cầu sếp đấu tranh với bất kỳ cuộc chiến quan liêu nào có ảnh hưởng đến bạn. Hãy biết rằng, sếp là sếp, và bạn đang định hướng sếp, người đang có lợi thế mà bạn không có.

Bạn là một nhà phát triển web (Web Developer), và bạn muốn có một công việc tốt hơn. 5 điều sau đây đều có thể có thể giúp bạn nhiều khi nói chuyện với nhà tuyển dụng - và dĩ nhiên không cần nhiều kinh nghiệm.

1. Luôn muốn vươn lên(Better)!
Và đương nhiên, một điều đơn giản bạn có thể làm, không cần kinh nghiệm, là quan tâm bạn làm gì và làm như thế nào. Một lập trình viên tệ (bad programmer) thường nói: "Tôi đã gặp vấn đề này, và tôi biết cách hoàn thiện nó". Một người phát triển tốt (good developer) là một người luôn tìm kiếm những cách tốt nhất để giải quyết vấn đề, phụ thuộc vào những gì họ có và kinh nghiệm.

Thật khó mà giải thích những điều này, nhưng nếu bạn có thể nói "Tôi tự học dùng Photoshop" hay "Tôi đã viết một ứng dụng nhỏ dùng AJAX" — hay chỉ cần bạn nói một cách say sưa về những điều bạn muốn làm... Chắc chắn họ sẽ để ý đến bạn.

2. Tinh thần học hỏi
Tôi nghĩ rằng IT là một lĩnh vực chỉ phù hợp cho những người ham học hỏi và luôn tìm tòi những điều mới — vì nó luôn thay đổi. Một lập trình viên tốt là một người ham học hỏi, đọc các blog và luôn nắm bắt xu hướng công nghệ.

3. Có ý tưởng lớn
Bạn không thể dùng quá nhiều thời gian để tìm kiếm trong các blog công nghệ mà không chia sẻ cho mọi người. Sự ra đời của web 2.0 là một sự kiện lớn — mỗi người có một ý tưởng, một kiến thức nhất định, sau đó là thử nghiệm, và tiếp theo là vận may khi áp dụng nó.

Đừng suốt ngày nghĩ về nó, mà hãy hiện thực nó — và hãy nói rằng "Tôi đã viết cho mình một dịch vụ chia sẽ file, và là một dự án cá nhân". Đương nhiên, nếu bạn tìm cách đề cập đến ý tưởng lớn của bạn, và bạn luôn muốn hiện thực nó.

4. Viết một blog
Chắc rồi, có hàng triệu blog, nhưng không phải mọi người đều có. Và hành động chăm sóc nó sẽ giúp bạn trở nên một người của công chúng — cũng là một cách cho chúng tôi thấy bạn đang làm gì.

5. Biết và nhận xét về các dịch vụ web
Bạn dùng Flickr để chi sẽ hình ảnh, có một account Facebook và dùng thường xuyên. Và bạn có một chút tham vọng. Không cần viết code nhiều, bạn đã có sẵn một ý tưởng tốt hơn các dịch vụ đã có — nó sẽ như thế nào, một lý do đơn giản mà bạn cho rằng người ta sẽ dùng nó, và kết hợp tất cả.

Đó chỉ là những ý kiến chủ quan, nếu bạn có một ý kiến khác, hãy comment lại nhé ! ^-^