Lập Trình Viên - Bạn Sẽ Bị Đào Thải Ngày Mai?
Tổng hợp, Việt Nam, Đánh giá October 18th, 2007
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?
1. 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à:
-
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.
-
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).
2. 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:
- 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).
- 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.
3. 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.
4. 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)
Tới khi đó thì bạn đã bạc tóc rồi, hoặc cũng không thể ngồi code nỗi nửa đâu.
Cũng như trước kia, người ta hô hào nào là sử dụng phần mềm không bản quyền thì sẽ bị đi tù, bị phạt hành chính. Hôm nay bạn xem những cửa hàng bán CD software kia, họ đang xây nhà, mua đất đó.
Lo xa làm chi cho mệt
Cũng hy vọng là thế
Ngay làm phần mềm trong nước, chưa nói làm web thì theo mô hình Waterfall vẫn sẽ tỏi. Người Việt phù hợp với Agile methods hơn.
Release sớm và thường xuyên không chỉ liên quan tới lập trình mà nó giúp mình cảm nhận và đo lường phản hồi của người sử dụng tốt hơn.
Thực thế thì mô hình Waterfall đã không còn phù hợp với việc phát triển phần mềm từ rất lâu rồi, nó tồn tại chỉ còn mang tính chất tham khảo và hàn lâm để dạy cho sinh viên
Em không đồng ý với quan điểm của anh Quang về việc: Tương lai phát triển phần mềm: Chỉ cần một vài “nghệ nhân”.
Hãy xét đến các dịch vụ Web 2 đang làm mưa làm gió như Digg, delicious,… ở thời kỳ sơ khai có thể do một hoặc vài cá nhân phát triển - đó chỉ là bước khởi đầu để hiện thực hóa ý tưởng. Tuy nhiên theo đà phát triển Dev team của họ cũng phải phình ra.
Anyway, great post
Chuyện một vài nghệ nhân cũng có thể lắm. Vì mấy lý do sau
* Nguồn gốc để thắng lợi trên Internet là innovation và change. Đông cũng không giúp vượt qua rào cản lớn, đông nhiều khi làm cho thay đổi khó khăn hơn.
* Vòng đời sản phẩm ngắn. Một sản phẩm chưa kịp phình đã lạc mốt. Nghệ nhân thì có thể làm ngay sản phẩm khác, còn đám đông lập trình viên thì không.
* Công cụ, năng suất và nền tảng ngày càng rẻ và chất lượng càng cao. Kéo theo lợi thế của số đông bị đánh mất. Một vài người giỏi có điều kiện để đứng trên vai người khổng lồ.
* Xu hướng open source, open content, open standard phát triển mạnh, tạo ra cơ chế đứng trên vai người khổng lồ vì có thể tái sử dụng code, framework, cũng như các sản phẩm trí tuệ của người khác.
* Driving force của Internet là người dùng, họ cần càng ít càng tốt. Vấn đề đặt ra là giải quyết bài toán một cách đơn giản, chứ không phải dồn nhiều người để giải quyết bài toán khó. Và đây cũng là sở trường của nghệ nhân, sở đoản của người quản lý chuyên nghiệp.
Digg, del.icio.us chẳng qua được như ngày hôm nay là do đứng trên vai những người khổng lồ thôi.
Mà những người khổng lồ thì cần rất nhiều developer.
Ko biết Digg dùng database system gì nhỉ? Mà 1 database system do bao nhiêu người viết???
Theo tôi biết Digg hiện vẫn là một dịch vụ độc lập, còn del.icio.us được Yahoo mua lại nhưng trước đó đã phát triển rất tốt. Mặt khác Yahoo kg góp sức gì nhiều cho del.icio.us ngoài sự bảo đảm đó là của Yahoo.
Bác có biết trong công nghệ làm máy bay, người ta sử dụng phương pháp nào không? Water Fall hay Agile?
trong công nghệ sản xuất máy bay thì water fall là mô hình thường được sử dụng nhưng việc sản xuất máy bay là hoàn toàn khác với sx phần mềm
Tất nhiên, nhưng chỉ là nói lên một điều, phương pháp nào cũng có chỗ ứng dụng của nó! Nếu cứ chỉ nói một chiều thì cũng không ổn!
He he, rất nhiều lập trình viên chỗ mình làm rất thích áp dụng phương pháp sản xuất máy bay vào sản xuất phần mềm vì nó có vẻ chuyên nghiệp hơn.
Dưới góc độ một người đã từng độc lập tác chiến và cũng đã từng teamwork, mình đánh giá cao quan điểm của tác giả bài viết. Dù cho làm 1 mình, hay 1 team, thì cũng chỉ nghệ nhân/tập thể nghệ nhân mới cho ra đời những tác phẩm nghệ thuật đích thực. Mọi quy trình cũng không thể thay thế cho trình độ các thành viên trong nhóm. Chỉ những nghệ nhân mới hiểu phải làm điều gì là tốt nhất, phải dùng tool nào hiệu quả nhất.
Tuy nhiên, lập trình ở VN thực sự có thể nói là 1 ngành mới mẻ, nên các coder “thợ thủ công” vẫn còn chỗ đứng “nay mai”, chứ không đến mức như anh Quang nói. Còn có nhiều chỗ có thể dùng đến coder để tăng hiệu năng công việc, tuy nhiên trong 1 bài comment chắc khó có thể nói được nhiều.
+ Tôi không đồng ý với cách nói software engineer là 1 “coder” như bạn Tuấn nói. Bạn có cách nhìn thiển cận của 1 người lập trình viên rồi.
@Aladin:
Bạn lại sa đà vào chỉ trích cá nhân hơn là chia sẻ kiến thức rồi bạn ơi. Mình rất ghét khi nghe 2 từ thiển cận, sai ở đâu thì cứ chỉ thẳng ra, cần gì thêm vào 2 từ đó??? Suy cho cùng mọi người đến với nhau trên blog hay forum là để làm gì?
Chú thích: Mình ko coi SE là coder đâu, mà mình chỉ bảo là những SE nào chỉ thuần là coder sẽ vẫn còn chỗ đứng ;), còn những SE nào xịn hơn thì ngon rồi.
Chú thích thêm: SE được coi là người TN ĐH BK , khoa CNTT (định nghĩa ko chính xác lắm :D, nhưng rút cục SE là gì? ở VN những ai được gọi là SE nhi?)
[...] - Lập trình viên - Bạn sẽ bị đào thải vào ngày mai ? - web2vietnam.com [...]
Tôi chưa đồng tình với phần 3 của bài viết. Các ví dụ đưa ra đều là các ứng dụng web có tính cộng đồng kiểu 2.0, vốn chỉ cần một nền tảng công nghệ vững chắc, khả năng mở rộng và đáp ứng tốt và rất thích hợp với Agile.
Cũng như ví dụ với máy bay, các phần mềm lớn sẽ vẫn cần những mô hình phát triển truyền thống và đội ngũ lớn. Một phần là do hạn chế và phạm vi áp dụng của Agile, bản thân tôi cũng đã trải nghiệm điều này.
Công việc CNTT ở Việt Nam đang ngày càng đa dạng, coder hay không thì cũng là từng người.
Dù sao cá nhân tôi rất thích mô hình phát triển Agile với nhóm nhỏ. 37signals với Ruby on Rails là ví dụ điển hình.
Tương lai phát triển phần mềm: Chỉ cần một vài “nghệ nhân” … Nghe câu này xong không chịu được phải lên tiếng. Đúng như bạn Duy đã nói ở trên, các phần mềm đó hoàn toàn dựa trên công nghệ và nền tảng tốt, tôi thấy nó toàn là ứng dụng database hay web, sử dụng ngôn ngữ thông dịch. Mà giá trị của nó cũng chả được tính bằng cái công sức phát triển phầm mềm, nó chỉ có giá trị thương mại mà thôi.
Sao bạn không thử so sánh với những phần mềm hệ thống hay bảo mật hoặc là tối ưu hóa … có độ phức tạp cao cộng với môi trường ngôn ngữ gần hệ thống. Chẳng hạn như hệ điều hành Windows của Microsoft, source code của nó phải tính bằng GB, nếu chỉ một nhóm gõ lại thôi thì không biết mấy năm nhỉ, nói chi là thiết kế rồi phát triển.
Không phải ngôn ngữ mạnh + người giỏi là có thể viết phầm mềm nhanh và giải quyết được mọi thứ. Cái gì cũng có giới hạn của nó.
@Deep Blue: what age are you living on?
tôi không hiểu nếu như bạn nói 1 phần mềm chỉ cần vài nghệ nhân + 1 hệ thống tool tốt thì cái phầm mềm nó lớn thế nảo nhỉ.
Cũng giống như bạn Deep Blue và một số bạn trước đó. tuôi ủng hộ quan điểm nếu chỉ vài nghệ nhân thì chắc chỉ làm được cái nhân phần mềm rồi để đó.
Đúng là mô hình water fall không phù hợp để phát triển các ứng dụng lớn với nhiều modun. nhưng nếu bạn để ý kỹ thì thực ra khi chia các modun ra nhỏ hơn và đến unit nhỏ nhất của 1 ứng dụng thì bạn sẽ lại thấy water fall ở trong đó , mặc dù ứng dụng này rất nhỏ, nhiều khi nó cũng không lớn hơn 1 bài tập của 1 sinh viên mới bắt đầu học lập trình nhưng nó vẫn là 1 unit hoàn chỉnh thực hiện được 1 số chức năng cụ thể và thường thì rất đặc trưng cho phần mềm đó. và khi đó thì tôi có thể chắc chắn là nhóm các nghệ nhân sẽ không bao giờ đủ thời gian dể làm hết các unit như thế trong phần mềm.
Lúc đó thực sự mà nói thì đến coder cũng sẽ phải cần(tôi nói đến coder chứ chưa nói đến mức độ LTV nhá)mà đến bèo nhèo như coder vẫn còn đất sống thì không có lý do gì mà các LTV sẽ chết.
Nhưng có một điều chắc chắn là yêu cầu trình độ của các coder sẽ ngày càng cao. Nếu coder không đáp ứng được thì sẽ bị loại bỏ. còn trình độ cao đến mức nào à ?? cái đó tôi cũng không dám chắc, nhưng nếu bạn muốn biết thì cứ nhìn vào ngành công nghệ cơ khí lắp ráp là một thí dụ điển hình, cụ thể là ô tô và máy bay.
còn nói 1 cách đơn giản thì việc thay đổi qui trình viết phần mềm hiện tại thì cũng giống như việc thay đổi qui trình lắp ráp ô tô và máy bay của thế ký trước thôi. Tất cả rồi sẽ đưa về mức độ modun hóa , unit hóa đến mức tối đa. và sẽ cần 1 team (gồm cả các nghệ nhân và các coder) để thực hiện việc đó. các nghệ nhân nhiều khi chẳng làm gì hết nhưng sẽ là người biết phải làm gì và phần còn lại vẫn là các coder làm.
Còn nếu sau này các tool sẽ được tự dộng hóa đến mức giống như các dây truyền lắp ráp tự động như ở nước ngoài, tức là đến khi đó các các công nhân lắp ráp khi xưa sẽ phải nâng cấp thành các công nhân điều khiển và theo dõi , tương tự như vậy thì các coder của chúng ta cũng sẽ trở thành các chuyên viên lập trình với các tool , modun đầy mình cùng các kỹ năng test và các loại ngôn ngữ …. và ngay cả các nghệ nhân nếu không nâng cấp trình dộ và kỹ năng cũng sẽ bị loại bỏ hoặc xuống làm coder , hoặc chuyển qua công việc khác.
Tất cả chúng ta cả các “nghệ nhân”, lập trình viên, hay các coder đều bị cạnh trah và đứng trước nguy cơ bị thải loại bởi công nghệ ai không theo kịp sẽ chết.
vậy nói chung các bạn có muốn trở thành lập trinh viên không,nếu muốn làm thì phải cập nhật công nghệ mới ,phát minh mới ….nơi nào cũng thể chỉ thiếu những người giỏi ,,,còn yếu yếu ,trung bình thì đầy rẫy,một năm tốt nghiệp đến hàng trăm ngàn người ,nhưng để kiếm ra 1,2 người giỏi thật là khó.vậy sao chúng ta hãy bình luận thế nào là người lập trình viên giỏi đi…
để mình gợi ý trước nhé,,,lập trình viện giỏi là lập trình viên không cần đến trường ,tự có thể nghiên cứu..và học quan trị kinh doanh..hahahahaha
Code, code va code, khong dau dot, khong hot hoang…