http://www.pcworld.com.vn/articles/cong-nghe/cong-nghe/2014/08/1235674/15-cong-nghe-thay-doi-cach-nha-phat-trien-lam-viec/
15 công nghệ thay đổi cách nhà phát triển làm việc | |
Bùi Lê Duy | |
Việc lập trình có thể nhanh hơn bạn nghĩ rất nhiều nhờ vào những công cụ mạnh mẽ.
Từ rất lâu, các nhà phát triển viết bằng ngôn ngữ Assembly để chương trình vừa nhẹ, vừa nhanh. Lúc ấy, họ cần có đủ ngân sách để thuê ai đó chuyển lại mọi nút bật/tắt phía trước hệ thống nào đó để nhập vào mã của họ, còn không thì họ phải tự mình làm. Cuộc sống quả đơn giản: phần mềm tải dữ liệu từ bộ nhớ, làm vài tính toán và gửi dữ liệu ấy lại. Đó là tất cả.
Ngày nay, các nhà phát triển phải làm việc với đội ngũ ở khắp các châu lục, với mỗi thành viên nói thứ ngôn ngữ khác nhau, có bộ ký tự khác nhau, và điều tệ nhất là sử dụng các phiên bản trình biên dịch khác nhau. Vài đoạn mã mới, một số đoạn mã khác lại rất cũ lấy từ trong thư viện có từ chục năm qua mà có thể có hoặc không có mã nguồn. Tạo một đội ngũ nhân viên viết code có nhiệt huyết và giải quyết rốt ráo được những vấn đề nêu trên mới chỉ là bắt đầu của công việc lập trình viên hiện nay.
Công việc nói cho máy tính biết phải làm gì khác xa với cách nay 5 năm vì mọi thứ đang có vẻ thay đổi rất nhanh.
Dưới đây là 15 công nghệ đang khiến ngành lập trình chuyển mình một cách rất tự nhiên. Chúng thay đổi cách chúng ta làm việc với các nhà phát triển khác, cách chúng ta tương tác với khách hàng và cách chúng ta ngồi viết mã. Vì bạn không còn bắt gặp cảnh tay lập trình viên nào đó ngủ gục trên bàn phím máy tính như trước nữa.
Công cụ số 1: tích hợp liên tục
Khi bạn check in mã nguồn vào một repo (repository, nơi chứa mã nguồn trong quá trình phát triển ứng dụng) thì thường bạn có chút thời gian thư thái, làm tách cà phê và có thể đi ăn trưa. Thế là xong, vì các repo chứa mã nguồn hiện nay gắn chặt với các hệ thống biên dịch liên tục, có thể biên dịch trực tiếp mã của bạn, xem cẩn thận kiến trúc mã, chạy hàng loạt quy trình kiểm thử và bắt đầu đánh dấu (flag) ở mỗi đoạn mã bị lỗi. Bạn không còn phải canh chừng cái máy tính báo lỗi như trước nữa, mà hệ thống sẽ nhắn cho bạn biết qua email hoặc tin nhắn điện thoại di động về những chỗ nào cần sửa trong đoạn mã. Trở lại bàn làm việc, uống cà phê xong, trở lại bàn làm việc, máy tính đưa ra sẵn cả danh sách bạn cần làm để sửa đoạn mã bạn vừa check-in lên repo.
Công cụ số 2: framework
Đứng trên đôi vai gã khổng lồ nào đó bằng cách sử dụng lại công trình của kẻ khác không còn là ý tưởng gì mới lạ, nhưng là chuyện rất phổ biến ngày nay. Có rất ít chương trình nào được viết từ tờ giấy trắng. Cách tiếp cận ưa thích nhất hiện nay là chọn đúng framework, nghiên cứu API và bắt đầu viết các đoạn mã liên kết chúng với nhau, mà thường các API hầu như hoàn thành sẵn luôn công việc giúp bạn. Các trang web không được viết sẵn HTML hoặc CSS như trước nữa, mà mã nguồn thường bắt đầu với Ext JS, ExpressJS hoặc các tập mã khác đóng vai trò làm nền tảng.
Chắc rằng bạn có thể tiên phong và xây dựng một ứng dụng nào đó từ tờ giấy trắng nhưng đó có thể xem là hành động… "tự tử". Vì bạn chẳng thể nào bắt kịp với công việc mà người khác đã từng làm. Bạn không phải là thợ thủ công, bạn là thợ chuyên chỉnh sửa framework. Nếu bạn nghĩ tự mình viết được mã thì hãy dừng lại ngay và nghiên cứu vìa framework thì bạn sẽ nhận ra được điều này.
Công cụ số 3: thư viện
Họ hàng gần của framework là thư viện, là một tập hợp các giải pháp có sẵn, phổ biến mà người viết mã không thể "sống" được nếu không có chúng. Có thể nào viết mã cho trình duyệt mà không sử dụng jQuery? Có ai nhớ tới hàm tích hợp tên là GetElementByID? Chẳng thể nhớ được, vì các thư viện như jQuery hiện nay quản lý mọi thứ.
Người ta bàn về các ngôn ngữ lập trình ưa thích, nhưng ít người biết về họ lập trình như thế nào. Nếu bạn thuê một ai đó thì bạn cần hỏi về kiến thức hiểu biết về thư viện của họ. Một người lập trình JavaScript có thông thạo jQuery hơn Dojo không? Nhà phát triển game có thể sử dụng C++ nhưng câu hỏi thực sự là liệu anh ta có biết đến Allegro, Unity, Corona hay bất kỳ thư viện nào khác liên quan không. Kiến thức về thư viện rất quan trọng, quan trọng như chính đầu vào và đầu ra của một ngôn ngữ lập trình vậy.
Công cụ số 4: API
Ngày xưa, các nhà lập trình lo ngại về cấu trúc dữ liệu. Họ sẽ gói mọi thông tin vào các khối dữ liệu, đếm từng byte, rồi đảm báo giá trị dữ liệu được đặt đúng chỗ để hàm pointer trỏ vào. Còn nay, trình biên dịch làm phần lớn công việc này.
Đến nay, chúng ta làm việc thông qua một giao diện tiện lợi hơn nhiều, với một cái tên nghe đầy thú vị: API. API nằm trên một máy tính hoàn toàn khác và có thể do một công ty hoàn toàn xa lạ chạy, nhưng mỗi khi cần liên kết gì đó, chúng ta lại sử dụng nó. Bạn muốn biết địa chỉ nhà nào đó, kèm theo cả kinh độ, vĩ độ? Có một API làm điều đó rồi, bạn chỉ việc gắn nó vào chương trình của mình.
Trong hầu hết trường hợp, dữ liệu không cần đóng gói quá kỹ. Kiểu đóng gói dữ liệu hồi xưa đến nay đã không còn phù hợp khi có những cấu trúc rất mở như JSON hoặc XML. Bạn cần đảm bảo mình lấy đúng thứ dữ liệu cần có, và may mắn là có một thư viện làm điều ấy giúp bạn.
Công cụ số 5: nền tảng như một dịch vụ - PaaS
Ngày nay có ai tự ngồi tạo một trang web? Thay vì vậy, tạo một tài khoản trên một trang web của ai đó và tuỳ biến nó. Bạn chỉ việc điền vào vài trường thông tin và… xong một trang web, đơn giản như tải một video lên YouTube vậy.
Dĩ nhiên, nói vậy cũng có phần thái quá. Nhiều tuỳ chọn PaaS yêu cầu kỹ năng lập trình một chút để biết được cần đặt thông tin gì phù hợp. Ví dụ Azure của Microsoft muốn bạn bỏ vào các hàm JavaScript để xác định trang web xử lý như thế nào. Sau đó Azure gói chúng với thư viện tương ứng và bắt đầu chạy trên Note.js.
Công cụ số 6: trình duyệt
Hồi xưa khi người ta viết phần mềm cho máy tính để bàn, phần mềm cho máy chủ và phần mềm cho thiết bị, ba mảng này đều khác nhau hoàn toàn. Mỗi mảng có cách truyền thông riêng với người dùng. Bây giờ, mọi thứ đều qua trình duyệt. Khi bạn thiết lập một máy chủ file trong nhà để chứa nhạc, phim, bạn chỉ việc đến một địa chỉ URL của một trang web. Các widget cho máy tính bàn của Apple từng được việt bằng JavaScript và HTML nhiều năm qua. Nhiều ứng dụng di động đa nền viết bằng HTML và JavaScript có sẵn trong Apache Cordova.
Chắc chắn là có ngoại lệ. Những game tốt nhất vẫn cần nhiều tuỷ chỉnh riêng, không cần đến trình duyệt. Nhưng điều ấy cũng đang thay đổi khi ngày càng nhiều nhà phát triển JavaScript đang chuyển sang viết dạng screen canvas object. Ví dụ Angry Birds sẽ chạy trong một cửa sổ trình duyệt.
Công cụ số 7: bộ chứa ứng dụng
Tạo một máy chủ không phải chuyện dễ. Các nhà lập trình muốn chạy đoạn mã, rồi gửi ghi chú đến đội quản lý máy chủ để cài cho đúng phần mềm. Đôi khi nhóm này dùng đúng thư viện, nhưng thỉnh thoảng lại không đúng, thậm chí nguy hiểm hơn là sử dụng sai thư viện mà cho kết quả có vẻ là đúng.
Các bộ chứa ứng dụng (application container) hiện nay như Docker, cho phép chúng ta tạo một nút và kèm một bộ chứa mới mọi thư viện trong đó. Nếu chạy trên máy thử nghiệm, nó sẽ giống hệt như chạy trên máy chủ. Mọi thứ được đóng gói chung với nhau và không còn xảy ra tình trạng không tương thích giữa máy chủ và máy bàn nữa.
Công cụ số 8: kiến trúc như một dịch vụ - IaaS
Đội ngũ quản lý máy chủ trước đây có thể rất… thoải mái nhưng bây giờ họ lại có thêm công việc phải lo xoay quanh một lớp gọi là "đám mây", và công việc của họ giống như làm việc trong một data center toàn cầu, và họ trở thành "ông vua" đám mây này hoặc đám mây nọ. Vài nhà lập trình cần hỏi xin đội ngũ kiến trúc hạ tầng để tạo một máy chủ mới cho một dự án mới nào đó. Họ đơn giản chỉ đăng nhập vào một trang web, nhấn một nút và có ngay được một máy tính ảo chạy cho dự án ấy. Nghe qua quá dễ, nhưng những trang web quản trị IaaS như vậy khiến cho đội ngũ quản lý máy chủ không còn thư thái như trước nữa, chí ít là cho đến nay (hy vọng tương lai sẽ khác đi).
Công cụ số 9: Node.js và JavaScript
Có lẽ trước cả khi bạn sinh ra, máy chủ web chỉ hỗ trợ trang web HTML tĩnh. Tiếp theo, ai đó đã tảoa được máy chủ web động, có thể tương tác với cơ sở dữ liệu. Mỗi đội phát triển cần có một người lập trình cơ sở dữ liệu trong SQL, một người viết mã máy chủ PHP hoặc Java và một người thiết kế giao diện HTML. Và có thời mọi người đều yêu thích AJAX và JavaScript chạy trên máy khách, các trang web ấy cần thêm một người nữa để "nói chuyện" với ngôn ngữ đó.
Bây giờ, mọi thứ đều có thể làm với JavaScript. Dĩ nhiên, trình duyệt vẫn hỗ trợ được JavaScript và dĩ nhiên máy chủ cũng cần hỗ trợ (Node.js) và cơ sở dữ liệu máy chủ cũng cần hỗ trợ tương ứng (MongoDB và CouchDB). Thậm chí HTML cũng thường có kèm các đoạn mã JavaScript để nhúng framework như Ext JS hoặc jQueryMobile để có thể tạo mã HTML ở máy khách.
Công cụ số 10: thị trường thứ hai
Nếu bạn đang viết game thì có thể thuê hoạ sĩ nào đó để tạo bộ mô hình. Thậm chí bạn có thể thuê vài nhà lập trình để thêm hiệu ứng hình ảnh, làm cho game đẹp hơn. Hoặc bạn có thể "đi chợ" như Unity Asset Store và mua mọi thứ mình cần. Khi thực hiện bài này, bộ công cụ Tile A Dungeon Sewer Kit đang giảm giá 33%, là bộ công cụ để tạo những cảnh hầm ngục trong game (giá gốc 45 USD). Nhưng cho dù là ở giá chưa giảm thì vẫn rẻ hơn rất nhiều so với chi phí bạn thuê một hoạ sĩ.
Cũng có nhiều nơi bán sẵn các bộ plug-ins, extension, thư viện và add-on vừa hiệu quả, vừa tiện dụng. Với thư viện và framework, có vẻ lập trình giống như… đi chợ, làm sao mua cho đúng nguyên liệu.
Công cụ số 11: máy ảo
Ngày nay, viết mã để chạy trên một cỗ máy không còn nữa. Nhiều đoạn mã hiện nay đều chạy trên máy ảo, rồi dịch những tập lệnh đó thành mã mà bộ xử lý có thể hiểu và thực thi được. Máy ảo Java, máy ảo C#/.Net và bây giờ là engine JavaScript trở thành mục tiêu chính của các nhà lập trình.
Máy ảo ngày càng phổ biến hơn, được dùng trong mọi mục đích. Trước đây, nếu bạn muốn tạo một ngôn ngữ mới thì bạn phải cần tạo toàn bộ stack mới từ preprocessor để đăng ký bộ cấp phát. Còn bây giờ, các ngôn ngữ mới nằm bên trên máy ảo. Clojure, Scala, Jython, JRuby…, chúng đều qua mặt mọi nỗ lực của Sun (bây giờ là Oracle) trong việc tạo máy ảo.
Điều này cũng tương tự trên thế giới trình duyệt. Chắc chắn là bạn có thể tạo trình duyệt và ngôn ngữ riêng cho mình, hoặc bạn có thể biên dịch đa nền cho nó để chạy trong JavaScript. Đó là những gì mà nhóm lập trình viên tự tạo công cụ như CoffeeScript. Nếu khả năng này chưa đủ khiến bạn bối rối thì thử xem ví dụ khác khi Google tạo ra GWT (Google Web Toolkit) để chuyển đổi Java thành JavaScript.
Công cụ số 12: cổng mạng xã hội
Trong thời kỳ đầu của Internet, bạn có thể tự làm trang web, rồi ngồi hy vọng mọi người có thể tìm được trang web mình tạo. Khi họ đến, họ đơn giản là phải nhớ URL gọn gàng, đẹp đẽ của bạn.
Nhưng đến nay, ngày càng nhiều trang web bị ảnh hưởng của những tên tuổi lớn như Facebook và Salesforce nuốt trọn. Nếu bạn tự tạo trang web, cho nó online rồi rất nhiều khả năng nó sẽ bị "mạng nhện" bám đầy vì người ta chỉ đến Facebook và các trang mạng xã hội khác để xem tin tức mà thôi.
Dĩ nhiên, giải pháp là tạo một ứng dụng Facebook hoặc Salesforce. Chúng cho bạn một con đường tích hợp vào nền tảng của họ. Nhưng cuối cùng, ứng dụng của bạn chỉ là cũng có thể bị người khác loại hoặc phớt lờ. Vậy bạn cần làm gì? Một là bám vào những cổng mạng xã hội lớn, hai là tìm cách… quét mạng nhện.
Công cụ số 13: công cụ Devops
Trước đây, chúng ta cài phần mềm lên một máy chủ duy nhất. Bây giờ, chúng ta thuê máy chủ đại trà, có thể cần đến chục, trăm hoặc cả ngàn máy chủ để đáp ứng nhu cầu, và cài phần mềm lên tất cả máy chủ đó. Đương nhiên, việc cài đặt này không thể làm thủ công như trước nữa.
Bạn hãy gõ vào thanh tìm kiếm từ "devops" xem sao, kết quả trả về sẽ là các công cụ như Chef và Puppet, cho bạn quản lý máy chủ một cách tự động. Bạn đẩy phần mềm mới lên đám mây và những công cụ này sẽ giúp đồng bộ mọi mã, phần mềm lên mọi máy chủ. Chúng tự động hoá mọi công việc như bạn làm trên một máy chủ.
Vài dịch vụ như Google App Engine cũng làm chức năng tương tự vậy, nhưng trong nhóm sản phẩm của Google mà thôi. Mọi thứ bạn cần là vất cho nó một ứng dụng, phần còn lại là tự động. Thậm chí bạn không cần biết chuyện gì đang diễn ra bên dưới, bạn chỉ việc trả tiền phí CPU hàng tháng cho tài nguyên bạn thuê mà thôi.
Công cụ số 14: GitHub, SourceForce và các dịch vụ chia sẻ mã nguồn khác
Các trang web chia sẻ mã nguồn có thể là đóng góp tuyệt vời nhất đối với thế giới nguồn mở. Trước khi các dịch vụ như SoureForce xuất hiện, phần mềm là thứ gì đó bạn làm cho riêng mình. Nếu ai đó muốn sao chép mã nguồn thì họ phải liên hệ với bạn và bạn gửi cho họ một gói file nén nếu bạn thích.
Bây giờ, chia sẻ mã nguồn là một kiểu mạng xã hội. Các trang web như GitHub và SoureForce có tất cả mã nguồn cho mọi người xem và cập nhật. Chúng có cả tính năng chia sẻ, nhận xét, cập nhật mã nguồn ở một nơi ai cũng có thể dễ dàng tiếp cận. Bạn có thể đọc mã nguồn và đề nghị thay đổi, mọi thứ có trong một giao diện duy nhất. Liệu có dự án nào mỗi tuần có trăm ngàn lượt tải về không? Điều này sẽ không khả thi với mô hình chia sẻ mã nguồn cũ.
Dạng mô hình này rất phổ biến hiện nay, thậm chí cả những dự án bản quyền cũng làm theo. Các trang như GitHub và BitBucket hỗ trợ họ bằng cách bán những repo không chia sẻ rộng rãi, chỉ chia sẻ trong nhóm làm việc hoặc được cấp phép truy cập mà thôi.
Công cụ số 15: giám sát hiệu năng
Thời buổi đầu, việc giám sát khả năng của mã nguồn rất đơn giản. Bạn in thời gian mã nguồn bắt đầu chạy và thời gian kết thúc. Nếu bạn muốn chương trình "nặng" hơn thì thêm vài tính toán.
Nhưng nay lại khác, vì nhiều vấn đề không phát sinh khi chỉ chạy trên một máy tính. Thêm một profiler vào mã nguồn sẽ không phát hiện ra nghẽn cổ chai thực sự, mà phần lớn là do vài đa liên kết bất thường hoặc dữ liệu rườm rà gây ra. Các công cụ mới sẽ theo dõi các lệnh gọi liên quan đến mạng cũng như tốc độ thực thi của từng module. Đây là cách duy nhất cho nhà lập trình hiểu được phần nào đúng, phần nào chưa đúng.
Nhưng đây cũng chỉ là một cách quan trọng để biết được mô hình lập trình thực thi trên một máy tính khi triển khai trên mạng có các công cụ kết nối sẽ vận hành như thế nào, có thể tốt, có thể không.
flet says: 
