Học CCNA hay MCP?

Chuyện chọn học chứng chỉ quốc tế nào luôn là câu hỏi mà chúng tôi nhận được nhiều nhất. Trong đó, do nhu cầu nhân lực có chứng chỉ Cisco và Microsoft luôn rất cao, nên đa số học viên và thí sinh có chung một câu hỏi: nên học CCNA hay MCSA? Chúng tôi xin được cung cấp thêm thông tin để bạn đọc có thể chọn cho mình hướng đi phù hợp.

Không nên so sánh

Trước tiên, hãy cùng xem định nghĩa chính thống của các hãng ra sao. Theo Cisco, CCNA (Cisco Certified Network Associate) là chứng chỉ thể hiện kiến thức cơ bản về mạng; những người đạt được CCNA có khả năng cài đặt, thiết lập cấu hình, và vận hành mạng LAN, WAN và dịch vụ truy cập từ xa (dial access) với quy mô 100 điểm (node) trở xuống, có sử dụng các giao thức (protocols) sau: IP, IGRP, Serial, Frame Relay, IP RIP, VLANs, RIP, Ethernet, Access Lists. Tuy nhiên, nếu xem xét kỹ nội dung, chúng ta thấy phần lớn khối lượng kiến thức là về thiết bị mạng của Cisco và những kỹ thuật mạng có liên quan đến công nghệ của Cisco.

Theo Microsoft, chứng chỉ MCP (Microsoft Certified Professional) xác nhận khả năng triển khai thành công một sản phẩm hay một công nghệ của Microsoft, trong đó bao gồm kỹ năng thực hành. Cần lưu ý, MCP là danh hiệu chung: thí sinh thi đậu một môn của Microsoft – dù là ngành mạng hay lập trình hay cơ sở dữ liệu – đều được gọi là “MCP”. Ở đây, chúng ta chỉ đề cập nhiều về MCP chuyên về mạng.

Như vậy, có thể thấy rằng hai chứng chỉ này không cùng loại để mà so sánh, cũng như Cisco là hãng về thiết bị (phần cứng) và Microsoft là hãng về phần mềm. Tuy nhiên, chúng có những kiến thức liên quan và bổ sung cho nhau để có thể làm việc thực tế. Cả hai chứng chỉ này đều yêu cầu người học phải có kiến thức nền tảng về mạng (khái niệm chung, mô hình, giao thức,…). Ở góc độ này, CCNA đi sâu hơn về kỹ thuật mạng (nhất là về TCP/IP) trong khi MCP tập trung vào phần mềm máy chủ (server) hoặc máy trạm (client).

Có nên học cả hai?

Nếu muốn trở thành chuyên viên, chuyên gia về quản trị mạng, bạn cần có kiến thức về sản phẩm và công nghệ Microsoft, vì chúng được sử dụng rộng rãi trên thực tế. Như vậy, việc học MCP là cần thiết (tuy nhiên có học tiếp lên MCSA hoặc MCSE hay không còn tùy nhu cầu công việc của bạn). Các bạn có thể học mà không cần thi quốc tế nếu không cần thiết. Ngoài ra, một số chuyên gia cho rằng học MCP sẽ giúp bạn dễ hấp thu kiến thức của CCNA hơn.

Chỉ những đơn vị nào sử dụng hoặc kinh doanh thiết bị và giải pháp của Cisco, mới cần đến những người có chứng chỉ Cisco. Có thể thấy, số lượng nhà tuyển dụng cần CCNA sẽ ít hơn những nơi muốn tuyển MCP (một cách tương đối). Nếu có nhu cầu cần thông thạo công nghệ Cisco thì bạn có thể theo đuổi các chứng chỉ CCNP hay CCIE. Riêng cấp độ CCNA vì chứa đựng nhiều kiến thức chung về mạng, nên việc học sẽ tốt cho bất cứ ai theo ngành mạng.

Tóm lại, nên cân nhắc khi muốn học CCNP hay MCSE; riêng với CCNA và MCP thì đừng do dự, hãy học ngay khi bạn có thể! Nguyễn Trọng Hòa (theo Echip)

Kỹ năng học và thi chứng chỉ Mạng máy tính

Nên thi chứng chỉ gì?
Hầu như mọi hãng công nghệ lớn về IT trên thế giới đều có các chứng chỉ của riêng hãng. Việc chọn lựa chứng chỉ nào để theo học nên xem xét để phục vụ cho công việc, phù hợp với lĩnh vực mà công ty nơi mình đang công tác. Nếu công ty bạn đang kinh doanh công nghệ này, bạn sẽ càng có cơ hội để thực tập với thiết bị thật. Nếu bạn đang có ý định thay đổi việc làm, bạn có thể tìm hiểu các chứng chỉ mà thị trường tuyển dụng đang cần. Ở Việt nam hiện nay, các chứng chỉ của Cisco và Microsoft được khá nhiều các bạn trẻ chọn lựa.
Tìm thông tin về các chứng chỉ ở đâu và như thế nào?

Bạn nên dành thời gian đáng kể để tìm hiểu về chứng chỉ mình dự định thi. Tìm hiểu về sách nào cần cho kỳ thi, dùng những phần mềm nào, thực tập những bài lab nào? Các thông tin này có thể tìm ở đâu? Các diễn đàn tin học trong và ngoài nước. Thông tin cũng có thể tìm trong web site của chính hãng mà bạn định thi. Thông thường thông tin từ web site sẽ quyết định thông tin chính xác nhất trong trường hợp bạn có nhiều thông tin trái ngược nhau. Ví dụ nếu bạn định thi chứng chỉ Cisco, web site của bạn nên tham khảo là www.cisco.com. Nếu bạn dự định lấy chứng chỉ Microsoft, bạn nên tham khảo www.microsoft.com. Việc chọn lựa giáo trình cũng rất quan trọng. Thông thường, với một chứng chỉ nghề, sẽ có nhiều bộ giáo trình phù hợp cho nhiều dạng đối tượng khác nhau. Có giáo trình phù hợp cho người đã có kinh nghiệm, có giáo trình phù hợp cho người mới bắt đầu. Các kỳ thi quốc tế thường có lệ phí thi khá cao so với mặt bằng chung. Cụ thể một kỳ thi Cisco vào khoảng 150USD (khoảng 2,4M tiền Việtnam), chi phí thi một kỳ thi Microsoft vào khoảng 50USD. Một chứng chỉ như CCNP (Cisco Certified Network Professionals) có thể đòi hỏi bạn phải vuợt qua 4 kỳ thi. Do đó số tiền cần chuẩn bị sẽ nhân lên nhiều lần.

Học chứng chỉ quốc tế như thế nào?
Có ba công việc chính mà một người học phải thực hiện trong quá trình theo học các chứng chỉ quốc tế: đọc sách, thực hành và tự đánh giá thông qua các chương trình kiểm tra.
- Đọc sách bạn đã chọn lựa trong giai đoạn chuẩn bị. Nếu đọc nhiều loại sách: kiến thức bổ sung cho nhau nhưng thời gian sẽ dài hơn. Hầu hết sách là tiếng Anh: chấp nhận những chương đầu đọc chậm. Diễn dịch các khái niệm cơ bản bằng tiếng mẹ đẻ. Điều này giúp người học nhớ lâu hơn. Các khái niệm hầu như có liên quan với nhau. Khi khối lượng kiến thức người học đã tích luỹ nhiều lên, tốc độ học sẽ nhanh hơn. Sau mỗi chương, nên tự dừng lại và tự trả lời các câu hỏi.
- Sự khác biệt lớn nhất giữa chứng chỉ quốc tế với các chương trình đào tạo chính qui khác chính là việc người học phải có thực hành trên thiết bị thật. Bạn không nên dự bất kỳ kỳ thi Cisco nào nếu bạn chưa từng thực tập trên Cisco routers. Bạn không nên dự thi bất kỳ kỳ thi Microsoft nào nếu bạn chưa từng làm việc với sản phẩm Microsoft đó. Các kỳ thi mới nhất luôn có dạng câu hỏi mô phỏng (simulations), đòi hỏi người dự thi phải thực sự làm viêc trên sản phẩm thật thì mới có khả năng trả lời.
- Dùng thêm các phần mềm bổ trợ cho việc học và tự đánh giá bản thân. Điều cần nhớ là bạn phải chân thật với chính mình. Bài thi quốc tế (trực tuyến) được chấm tự động bởi máy tính. Khi càng gần đến ngày thi, bạn càng nên tập trung cho việc đọc lạI lý thuyết. Giai đoạn này bạn cần tiếp xúc vớI càng nhiều câu hỏI ôn tập càng tốt. Có thể phân bổ 80% thờI gian học tập cho việc học lý thuyết; 20% còn lạI cho việc học thực hành. Đặt mục tiêu cụ thể để có áp lực lên chính bản thân. Ví dụ: sẽ đạt được CCNA vào trước tháng 10 năm 2005 hoặc sẽ đăng ký thi CCNA vào ngày 24 tháng 10….Ngoài ra, bạn cũng nên thông báo cho cơ quan hoặc công ty nơi bạn đang làm việc biết kế hoạch học tập và thi cử của mình. Việc này giúp cho bạn dễ đuợc cấp trên chú ý và tạo điều kiện cho giai đoạn ôn tập. Nếu bạn là sinh viên đại học, nên chú ý phân bổ thời gian sao cho việc học các chứng chỉ nghề không bị ảnh hưởng đến các kỳ thi trong trường Đại học.
- Nên đăng ký thi trước một hoặc hai ngày thi. Ở Hà Nội, có nhiều trung tâm tổ chức thi. Bạn có thể tìm thông tin về các trung tâm khảo thí tại Việt nam ở địa chỉ
http://www.vue.com. Khi đăng ký thi, chú ý cách điền tên và địa chỉ để hãng gửI bằng về cho bạn.
Ngày trước khi thi, bạn đọc lại các study guide, các sự kiện, các hình vẽ. Không nên học nhiều hoặc nhồi nhét.
Kỹ năng thi cử?
Ngày thi:
- Nên đến sớm địa điểm thi trước 10 đến 15 phút. Giấy nháp và viết sẽ do trung tâm khảo thí cung cấp. Bạn không cần thiết phải chuẩn bị các vật dụng này. Máy tính cá nhân cũng không được phép mang vào phòng thi.
- Bạn nên ghi ra giấy khoảng thời gian được phép thi và số câu hỏi cần trả lời. Ước lượng khoảng thời gian trung bình cho từng câu hỏi. Với các bài thi của Cisco, mỗi câu hỏi trả lời bình quân mất một phút. Có những câu hỏi có thể tốn nhiều thời gian hơn.
- Điều quan trọng cần nhớ là bạn phải luôn bình tĩnh và nhịp điệu trong lúc thi. Các kỳ thi chứng chỉ quốc tế không phải là kỳ thi tuyển sinh. Nếu rớt bạn vẫn có thể đóng tiền thi lại. Bạn chỉ cần vượt qua một số điểm qui định nào đó là sẽ được công nhận đậu hay rớt. Với các môn thi Cisco, điểm đậu của kỳ thi CCNA là 849 điểm (trên 1000). Đây là một điểm yêu cầu khá cao với điểm chuẩn thường thấy trong các trường học Việt nam. Nghĩa là, nếu bài thi có khoảng 65 câu hỏi, bạn chỉ được trả lời sai tối đa 9 câu hỏi. Khi bạn phát hiện là mình đã trả lời sai câu hỏi trước đó và bạn không thể quay lại, bạn hãy tâm niệm là còn rất nhiều câu hỏi ở phía trước.
- Một số bài thi cho phép bạn xem lại các câu hỏi đã trả lời qua, ví dụ như kỳ thi của Microsoft. Một trong những cách thi hiệu quả là bạn sẽ trả lời qua tất cả các câu hỏi, đánh dấu các câu hỏi mà bạn chưa biết phương án trả lời. Do đó bạn có thể xem lại và thay đổi chọn lựa trước khi bài thi kết thúc. Các bài thi của hãng Cisco không cho phép bạn quay ngược trở lại câu hỏi đã trở lời trước đó. Do đó, với bài thi Cisco, bạn phải trả lời quyết đoán và chắc chắn cho từng câu hỏi. Có nhiều dạng câu hỏi: câu hỏi dạng chọn lựa đơn (single-choice), câu hỏi dạng “nhiều chọn lựa” (multiple choice), câu hỏi dạng “kéo và thả” (drag and drop), câu hỏi mô phỏng (simulation). Bạn nên đọc hết tất cả các chọn lựa và lựa ra đáp án tốt nhất. Một thí sinh có thể chỉ đọc đến đáp án C là một đáp án đúng và chọn ngay trong khi chọn lựa D mới là đáp án đúng nhất. Đối với các câu hỏi mô phỏng, bạn nên thực hiện chính xác các tác vụ mà câu hỏi yêu cầu. Thông thường sẽ có nhiều thông tin “giả” sẽ được đưa ra, người dự thi phải biết chính xác tác vụ mà câu hỏi yêu cầu. Khi kết thúc dạng câu hỏi này, bạn chú ý thực hiện các tác vụ lưu các kết quả bạn đã thực hiện. Với câu hỏi dạng đa chọn lựa, bạn nên dùng kỹ thuật loại trừ để giới hạn lại bớt các chọn lựa đúng.
- Kết quả đậu hay rớt của một bài thi sẽ hiển thị ngay khi bạn hoàn tất bài thi. Khả năng nhớ các sự kiện và liên kết các sự kiện sẽ giúp ngườI dự thi giảI đáp nhiều câu hỏi lạ.

Làm gì sau khi thi xong?
Nếu bạn đã thi đậu, bạn hãy tự hào về những gì bạn đã đạt được. Hãy chia sẽ thông tin này với công ty, bạn bè và với cộng đồng. Hãy hoạch định các kế hoạch tiếp theo. Bạn cũng nên vào web site của hãng để kiểm tra thông tin về bạn có đúng không để hãng sẽ gửi bằng về cho bạn. Trong trường hợp bạn thi trượt, hãy phân tích các điểm yếu mà mình đã thể hiện trong bài thi vừa gặp và lên kế hoạch cho một kỳ thi mới.
Chúc các bạn thành công!

Tham khảo anh: Đặng Quang Minh(CCNP)

(http://www.vutbay.net)

The craftman- Thợ học việc

Trong phần trước * Jerry, một tay cựu học việc yêu cầu Alphonse, một tay học việc, viết một chương trình tạo các số nguyên dùng "sieve of Etastosthenes". Jerry, nhận thấy Alphonse ứng dụng trọn bộ thuật toán vào một function "khổng tượng" nên đã yêu cầu Alphonse tách nó ra theo ba khái niệm: khởi động, ứng tạo và chuẩn xuất;... nhưng Alphonse không biết phải bắt đầu từ đâu...


Gã nhìn tôi một lúc, rõ ràng đang đợi tôi làm gì đó. Nhưng rốt cuộc gã thở dài, lắc đầu và tiếp tục. "Ðể mở rộng ba khái niệm rõ ràng hơn, tao muốn mày tách chúng ra thành ba methods riêng biệt. Ðồng thời vứt hết những cái phụ chú không cần thiết và đặt một cái tên khá hơn cho cái class. Mày làm xong những thứ đó rồi phải bảo đảm là mấy cái test vẫn còn chạy được."

Các bạn có thể thấy những điểm tôi đã làm trong mã dẫn 3. Tôi đã đánh dấu những thay đổi bằng chữ đậm, y hệt như Martin Fowler trình bày trong cuốn Refactoring của ông ta. Tôi đổi tên của cái class thành dạng danh từ, vứt hết những phụ chú về chuyện Eratosthenes và tạo ra ba methods từ ba khái niệm trong generatePrimes function.

Tách ra ba functions buộc tôi phải đưa ra một số biến hàm của function thành static fields của cái class. Jerry nói cách này làm rõ những biến hàm nào là local và những biến hàm nào có ảnh hưởng rộng lớn hơn.

Mã dẫn 3:

PrimeGenerator.java, version 2

/**
* This class generates prime numbers up to a user-specified
* maximum. The algorithm used is the Sieve of Eratosthenes.
* Given an array of integers starting at 2: Find the first
* uncrossed integer, and cross out all its multiples. Repeat
* until the first uncrossed integer exceeds the square root of
* the maximum value.
*/
import java.util.*;

public class PrimeGenerator {
private static int s;
private static boolean[] f;
private static int[] primes;

public static int[] generatePrimes(int maxValue) {
if (maxValue < 2)
return new int[0];
else {
initializeSieve(maxValue);
sieve();
loadPrimes();
return primes; // return the primes


}
}

private static void loadPrimes() {{{/b}
int i,j;

// how many primes are there?
int count = 0;
for (i = 0; i < s; i++) {
if (f[i])
count++; // bump count.
}

primes = new int[count];

// move the primes into the result
for (i = 0, j = 0; i < s; i++) {
if (f[i]) // if prime
primes[j++] = i;
}
}


private static void sieve() {{{/b}
int i,j;
for (i = 2; i < Math.sqrt(s) + 1; i++) {
// if i is uncrossed, cross out its multiples.
if (f[i]) {
for (j = 2 * i; j < s; j += i)
f[j] = false; // multiple is not prime
}
}
}


private static void initializeSieve(int maxValue) {{{/b}
// declarations
s = maxValue + 1; // size of array
f = new boolean[s];

// initialize array to true.
for (int i = 0; i < s; i++)
f[i] = true;

// get rid of known non-primes
f[0] = f[1] = false;
}
}

Jerry bảo tôi mã này hơi lộn xộn, nên gã giành lấy bàn đánh và chỉ tôi cách dọn dẹp. . Mã dẫn 4 minh hoạ những gì gã đã làm. Thoạt tiên gã vứt đi cái biến hàm s trong initializeSieve và thay thế nó bằng f.length. Sau đó gã đổi tên của ba functions (theo kiểu) gã cho là có ấn tượng hơn. Cuối cùng gã sắp xếp lại cái "bộ lòng" initializeArrayOfIntegers (từ initializeSieve) để cho dễ đọc hơn một chút. Các cái test vẫn chạy nhưng thường.

Mã dẫn 4:
PrimeGenerator.java, version 3 (partial)

public class PrimeGenerator {
private static boolean[] f;
private static int[] result;

public static int[] generatePrimes(int maxValue) {
if ((maxValue < 2)
return new int[0];
else {
initializeArrayOfIntegers(maxValue);
crossOutMultiples();
putUncrossedIntegersIntoResult();
return result;
}
}

private static void
initializeArrayOfIntegers(int maxValue) {
f = new boolean[an[maxValue + 1];
f[0] = f[1] = false; //neither primes nor multiples.
for (int i = 2; i < f.length; i++)
f[i] = true;
}

Tôi phải công nhận mã này rõ hơn một chút. Trước giờ tôi nghĩ tạo functions có tên sinh động là phí thời giờ , nhưng những chỉnh đổi của gã quả thật làm cho mã nguồn dễ đọc hơn.

Tiếp theo Jerry trỏ vào crossOutMultiples, nói là gã nghĩ cụm if(f[i] == true) có thể làm cho dễ đọc hơn nữa. Tôi nghĩ đến điểm này chừng một phút. Ý định của các cụm này dùng để kiểm tra xem i không bị loại trừ; thế là tôi đổi tên của f thành unCrossed.

Jerry nói mã này được hơn nhưng tôi vẫn chưa hài lòng với nó vì nó dẫn đến khả năng phủ định đôi (double negative) như unCrossed[i] = false. Bởi thế gã đổi tên của dãy số thành dãy isCrossed với chỉ số nhỏ hơn 2. Các cái test vẫn chạy được.

Jerry tách phần lặp bên trong (inner loop) của crossOutMultiples function và gọi nó là crossOutMultipleOf. Gã bảo rằng các cụm tương tự như if (isCrossed[i] == false) dễ nhầm lẫn nên gã tạo ra function có tên notCrossed và thay cụm if thành if (notCrossed(i)). Kết tiếp gã chạy thử mấy cái test lại.

Sau đó Jerry hỏi tôi ý nghĩa của phần số căn đó là gì. Tôi tốn ít thời giờ viết phụ chú giải thích tại sao cần phải lặp lại cho đến phần số căn của chiều dài dãy số. Tôi cố tranh đua với Jerry bằng cách tách phần tính toán thành một function, nơi tôi có thể đưa vào phần phụ giải. Trong khi viết phụ chú tôi nhận ra rằng căn số là phân tố cực đại của số nguyên trong một dãy số. Bởi thế để ứng phó, tôi chọn cách gọi đó (maxValue) cho các biến hàm. Cuối cùng tôi bảo đảm các tests vẫn chạy được. Kết quả của các thay đổi trong mã dẫn 5.

Mã dẫn 5:

PrimeGenerator.java version 4 (partial)
public class PrimeGenerator {
private static boolean[] isCrossed;
private static int[] result;

public static int[] generatePrimes(int maxValue) {
if (maxValue < 2)
return new int[0];
else {
initializeArrayOfIntegers(maxValue);
crossOutMultiples();
putUncrossedIntegersIntoResult();
return result; }
}

private static void
initializeArrayOfIntegers(int maxValue) {
isCrossed = new boolean[maxValue + 1];
for (int i = 2; i < isCrossed.length; i++)
isCrossed[i] = false;
}

private static void crossOutMultiples() {
int maxPrimeFactor = calcMaxPrimeFactor();
for (int i = 2; i <= maxPrimeFactor; i++)
if (notCrossed(i))
crossOutMultiplesOf(i);
}

private static int calcMaxPrimeFactor() {
// We cross out all multiples of primes. Thus, all crossed
// out multiples have p and q for factors. If p > sqrt of the
// size of the array, then q will never be greater than 1.
// Thus p is the largest prime factor in the array, and is
// also the iteration limit.
double maxPrimeFactor = Math.sqrt(isCrossed.length) + 1;
return (int) maxPrimeFactor;
}

private static void crossOutMultiplesOf(int i) {
for (int multiple = 2*i; multiple < isCrossed.length;
multiple += i)
isCrossed[multiple] = true;
}

private static boolean notCrossed(int i) {
return isCrossed[i] == false;
}


Tôi bắt đầu nắm bắt được vấn đề nên liền xét lại method xét lại method putUncrossedIntegersIntoResult. Tôi thấy rằng method này có hai phần. Phần thứ nhất đếm các số nguyên không bị loại trong dãy số, và tạo nên dãy kết quả (bằng chiều dài của dãy số). Phần thứ nhì dời các số nguyên không bị loại vào dãy kết quả này. Bởi thế, như bạn thấy trong mã dẫn 6, tôi tách phần thứ nhất ra để hình thành function cho chính nó và dọp dẹp lặt vặt đôi chút. Các tests vẫn chạy được. Jerry chỉ thoáng gật đầu. Gã có thật sự khoái những điều tôi đã thực hiện không?

Mã dẫn 6:

PrimeGenerator.java, version 5 (partial).
private static void putUncrossedIntegersIntoResult() {
result = new int[numberOfUncrossedIntegers()];
for (int j = 0, i = 2; i < isCrossed.length; i++)
if (notCrossed(i))
result[j++] = i;
}

private static int numberOfUncrossedIntegers() {
int count = 0;
for (int i = 2; i < isCrossed.length; i++)
if (notCrossed(i))
count++;
return count;
}


<đón xem phần kế tiếp>

* Trong nguyên bản là "In the last month's column..." nhưng ở đây tạm dịch thoáng ra là "trong phần trước" cho phù hợp với tinh thần các bài craftsman được post lên diễn đàn (không theo tháng mà theo... tùy hứng của người dịch ;)) ;))

Lập Trình Viên - Bạn Sẽ Bị Đào Thải Ngày Mai?

Thế giới là một cuộc chọn lọc và đào thải không ngừng, nhưng thế giới IT còn khắc nghiệt hơn. Bạn sẽ là người bị đào thải kế tiếp?

Cái chết của mô hình Waterfall
Năm 1970, mô hình nổi tiếng và được áp dụng trong qui trình phát triển phần mềm tại phần lớn các công ty hiện nay ra đời: mô hình thác nuớc (waterfall model). Mô hình này là kết quả của sự kết hợp các mô hình sản xuất từ các ngành kỹ thuật khác áp dụng cho công nghệ phần mềm. Nó định nghĩa ra chuỗi qui trình phát triển theo thứ tự từ trên xuống bao gồm: lấy yêu cầu khách hàng, làm thiết kế, phát triển, kiểm định và cuối cùng sẽ bàn giao cho người dùng. Bạn sẽ thấy mô hình này giống hệt với qui trình xây một căn nhà: kiến trúc sư tìm hiểu yêu cầu của chủ nhà, thiết kế căn nhà, đưa cho đội ngũ thi công thực hiện, kiểm tra chất lượng và cuối cùng trao chìa khóa cho người sở hữu.

Năm năm sau, Frederick Brooks phát hiện ra lỗ hổng lớn đầu tiên của mô hình này trong cuốn sách kinh điển về quản trị dự án: The Mythical Man-Month (Bí mật về tháng nhân công). Chắc các bạn làm phần mềm đều biết khái niệm man-month (hay man-day) là thước đo căn bản để tính giá cho việc phát triển phần mềm: đó là công lao động trong một tháng (hay một ngày) của một lập trình viên. Phát hiện nổi tiếng nhất của Brooks là “trong phát triển phần mềm không phải cứ thêm nhân công thì dự án sẽ nhanh hơn theo cùng cấp số“. Vấn đề là do sự mất cân đối trong giao tiếp khi số lượng người tham gia tăng lên.

Nhiều năm qua đi, người ta ngày cảng học hỏi được nhiều hơn về cách tốt nhất để làm một phần mềm và cũng bắt đầu nhận thức được rằng mô hình thác nước là quá cứng nhắc và thiếu thực tế. Không giống như việc bạn xây một căn nhà, ngay khi thiết kế, người ta đã dự kiến được 99% hình thù và chi tiết căn nhà sẽ như thế nào. Một dự án phần mềm hiếm khi được hình dung một cách chi tiết và đúng theo yêu cầu công việc. Chỉ khi đưa vào thử nghiệm trong môi trường thực các vấn đề mới bắt đầu phát sinh và việc thay đổi yêu cầu diễn ra thường xuyên.

Những người “ngoại đạo” thường nghĩ rằng vì phần mềm là “mềm” nên có thể dễ dàng thay đổi chỉnh sửa tùy hứng. Nhưng thực ra phầm mềm cũng giống như bất kỳ một cơ cấu kỹ thuật nào khác (như máy móc cơ khí chẳng hạn), nó cũng có thiết kế và cấu trúc (mà thường lại còn phức tạp hơn các máy móc cơ khí rất nhiều).

Khi yêu cầu công việc thay đổi, việc thay đổi trong phần mềm là tất yếu và trong thế kỷ 21 này các thay đổi lại càng diễn ra thường xuyên và nhanh chóng. Với mô hình thác, việc theo kịp các thay đổi là không thể thực hiện vì vòng qui trình của nó quá dài. Nó giống như việc cứ mỗi lần có bất kỳ thay đổi nào là bạn phải gần như phải phá căn nhà đi và xây lại từ đầu. Bạn có thể hình dung ra được sự tốn kém và bất tiện sẽ lớn như thế nào.

Tóm lại, hai vấn đề lớn nhất của mô hình thác nước là:

1. Mô hình này quá tự tin với giả định rằng chúng ta luôn có thể làm được một hệ thống hoàn hảo ngày lần đầu.

2. Phầm mềm ngày càng khác với các cơ cấu kỹ thuật cứng nhắc mà giống như các cơ thể sống - nó phải tiến hóa để thích hợp với môi trường. Đây chính là tiền đề cho một phương thức phát triển mới chiếm lĩnh ưu thế trong những năm gần đây: phương thức phát triển linh hoạt (Agile Development Methods).

Phát triển linh hoạt - Phần mềm tiến hoá

Phương thức phát triển phần mềm linh hoạt bắt đầu xuất hiện vào đầu những năm 90 với mục tiêu là phần mềm phải có khả năng biến đổi, phát triển và tiến hóa theo thời gian mà không cần phải làm lại từ đầu. Phương thức này tập chung vào tính đơn giản: tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai.

Phương thức phát triển này dựa trên hai kỹ thuật đáng lưu ý nhất:

1. Refactoring: Giống như vệc bạn trang trí lại căn nhà mà không cần phải cơi nới, xây thêm hay xây lại, “refactoring” (xin lỗi, tôi chưa tìm được từ tiếng Việt nào thích hợp để dịch) cho phép chúng ta chuyển đổi mã lệnh để làm cho ứng dụng tốt hơn, đẹp hơn mà không phá hỏng nó (các bạn có thể tìm hiểu thêm về kỹ thuật này trong cuốn Refactoring: Improving the Design of Existing Code).
2. Developer Testing: Phần mềm do chính các lập trình viên được kiểm định thay vì do các nhóm tester độc lập làm. Công cụ là “unit test”, cho phép từng phần nhỏ của phần mềm được kiểm định ngay trong quá trình phát triển trước khi lắp ghép vào ứng dụng. (xin xem thêm cuốn Test Driven Development: By Example)

Một trong những yếu tố khác khiến cho phương thức phát triển linh hoạt có thể cất cánh là sự lớn mạnh của các ngôn ngữ kịch bản (scripting language) như PHP, Python và gần đây là “viên hồng ngọc” Ruby. Tính linh hoạt của các ngôn ngữ này khiến cho việc thay đổi phần mềm dễ dàng hơn nhiều so với các ngôn ngữ tiền bối. Thêm vào đó là việc cộng đồng mã nguồn mở đang cung cấp vô số các thư viện dựng sẵn, đáp ứng cho việc phát triển nhanh, triển khai nhanh, thường xuyên đưa ra các cập nhật mới (release soon, release often) theo đúng tinh thần của phương thức phát triển linh hoạt. Phần mềm ngày nay không phải được nâng cấp hàng năm mà là hàng tuần, thậm chí hàng ngày.

Tương lai phát triển phần mềm: Chỉ cần một vài “nghệ nhân”

Digg, del.icio.us… các “phần mềm” trị giá hàng chục triệu, hàng trăm triệu USD chỉ do một hai người thực hiện. Facebook, mạng xã hội trị giá nhiều tỷ USD, cũng chỉ do một nhóm nhỏ làm ra.

Bí quyết phát triển các phần mềm có giá trị nhất ngày nay là chỉ cần một vài người có kỹ năng, nhiều nhiệt huyết. Với vài cá nhân xuất sắc trang bị các ngôn ngữ lập trình hiện đại và phương thức làm việc mới, một nhóm nhỏ có thể làm ra những sản phẩm tốt hơn cả một “đạo quân” lập trình viên trước kia.

Tổng kết lại, có thể thấy những thay đổi sẽ diễn ra trong các năm tới đây:

• Những kỹ sư phần mềm có trình độ cao, có nhiệt huyết và tham vọng sẽ là những cỗ máy làm ra tiền.
• Những lập trình viên không có kỹ năng đặc biệt có lẽ nên tìm việc làm ở lĩnh vực khác.
• Những thay đổi mà chúng ta đang thấy ở thị trường phần mềm đại chúng sẽ diễn ra ở các công ty lớn.
• Đưa phần mềm cho nước ngoài gia công (outsourcing) sẽ ngày càng ít tính kinh tế hơn.
• Khoa học máy tính vẫn là lĩnh vực cạnh tranh và đòi hỏi cao.

Tương lai của các LTV Việt Nam

Nhìn các xu hướng đang diễn ra trên thế giới, có thể thấy rằng các dự án cần hàng trăm người sẽ ngày càng ít đi. Theo tính toán của Mỹ, chi phí outsourcing đang gia tăng (từ 1/10 lên 1/3 so với giá thành sản xuất trong nước) làm cho việc đưa phần mềm ra nước ngoài gia công ngày càng kém hấp dẫn. Ngoài ra, do khó khăn về giao tiếp và chệnh lệch về trình độ, chất lượng các dự án này cũng không được như mong muốn và rất khó bắt kịp các thay đổi của khác hàng.

Các LTV luôn có xu hướng muốn gia nhập các công ty lớn, tham gia vào các dự án lớn. Nhưng có thể đấy sẽ cách tiếp cận sai lầm vì:

• Tương lai của các công ty làm xuất khẩu phần mềm dạng này đang ngày càng bấp bênh.
• Bản thân các LTV thường không cải thiện được trình độ vì các công việc được giao ít cần kỹ năng cao hay tính sáng tạo.

Tất nhiên, nhìn thẳng vào thực tế, sự thay đổi sẽ không diễn ra ngay trong nay mai — mô hình thác nước và các biến thể của nó vẫn sẽ được dùng, người ta sẽ vẫn outsourcing. Nhưng mọi thứ sẽ ngày càng khó khăn hơn, đòi hỏi cao hơn và chỉ khi bạn thực sự chuẩn bị tốt cho sự thay đổi thì mới tránh được việc bị đào thải.

Đáng lo ngại nhất là các LTV Việt Nam còn xa mới theo kịp các đồng nghiệp ở các nước như Ấn Độ hay Ireland cả về mặt tổ chức lẫn kỹ năng. Chúng ta quá chú trọng tới các công nghệ độc quyền của Microsoft, Oracle hay IBM và hiểu biết về mã nguồn mở là một lỗ hổng lớn. Không may, có thể ngày mai công ty sẽ nói lời chia tay với bạn chỉ vì bạn không có kinh nghiệm gì về Python hay cơ sở dữ liệu MySQL. Như tựa một bộ phim “Đó là một tương lai không quá xa” (Not too far future), xin hãy suy nghĩ lại con đường của mình.

(theo ReadWriteWeb)