React là gì và tại sao nó lại quan trọng?

Chào các bạn! 

Tình cờ trong lúc lục lại đống assignment cũ năm 3, mình tìm thấy một bài report dài 30 pages do mình viết để seminar về React và React Native. Nhưng lúc đấy lại không đăng lên blog. Dù hơi cũ nhưng hôm nay mình xin giới thiệu cho các bạn biết sơ về nó nhé.

GIỚI THIỆU

React (React.js hay ReactJS) là một thư viện JavaScript mã nguồn mở để xây dựng giao diện, được tạo ra bởi Facebook vào tháng 3/2013. React hiện chỉ là thư viện chứ không phải framework, và ứng với phần V trong mô hình MVC.

React được Facebook đưa vào sử dụng thực tế cho dự án Facebook Ads của họ, và từ đó cả Instagram, Netflix hay Airbnb,.. cũng bắt đầu đưa React vào sử dụng cho các dự án của họ. Danh sách các dự án lớn sử dụng React có thể xem tại đây.

Hiện nay, thư viện này nhận được rất nhiều sự quan tâm đến từ cộng đồng, Github repo của React đang có được hơn 67k stars. Nó đang được maintain bởi Facebook và Instagram, cũng với sự đóng góp của cộng đồng 1011 (28/5/2017) lập trình viên giỏi trên Thế giới.

VẤN ĐỀ & GIẢI PHÁP

Từ xưa đến nay, việc xây dựng ứng dụng MVC phía client với data-binding 2 chiều thì cũng khá là đơn giản, tuy nhiên khi dự án phát triển, càng nhiều tính năng mới, càng nhiều người được bổ sung vào team dẫn tới quá trình phát triển bị chậm đi với code bases lớn và phức tạp, đồng thời hiệu năng cũng sẽ bị giảm đi.

Thời gian trôi qua, project đó sẽ trở thành ác mộng đối với những con người đang thực hiện nó. Source code trở nên quá “sâu” để lập trình viên có thể nhớ được. Khi thêm một chức năng mới sẽ rất vất vả và đòi hỏi testing khá nhiều.

Bạn cũng có thể giải quyết vấn đề đó bằng các thư viện khác như Backbone.js hay Angular.js tuy nhiên với các project qui mô càng to thì sẽ càng khó để quản lý.

React thì trái lại, nó sinh ra để dành cho những ứng dụng lớn dễ dàng quản lý khi mở rộng. React được tạo ra cho phần V của mô hình MVC, cho phép lập trình viên tạo ra các web app lớn, có thể hiển thị các dữ liệu thay đổi theo thời gian mà không cần reload lại trang, cũng như xây dựng các UI components có thể tương tác và tái sử dụng. Mục tiêu chính của React là nhanh, đơn giản, hiệu năng cao và dễ dàng mở rộng.


TẠI SAO LẠI LÀ REACT

React trở nên phổ biến như vậy là vì nó được tạo ra bởi Facebook?

Không! Dĩ nhiên là không.
Vậy tại sao React lại được nhiều ông lớn lựa chọn đưa vào dự án của mình mặc dù nó vẫn chưa thực sự trưởng thành?

● Giải quyết cho V trong mô hình MVC

● Giúp viết Javascript dễ dàng hơn với JSX

React sử dụng một cú pháp mới gọi là JSX, là một sự hòa trộn giữa Javascript và cú pháp XML: cho phép quoting như HTML và sử dụng HTML tag để render sub-components. Vì vậy nó cũng trở nên thân thiện hơn với các lập trình viên front-end.

● Component hóa giao diện

React Component API cho phép lập trình viên tạo ra các Component tương ứng với các phần của giao diện. Các component này có thể được tái sử dụng như một layout template, hoặc kết hợp với các component khác để xây dựng content của giao diện.

Việc này sẽ giải quyết được vấn đề ở mục (b), khi mà project trở nên càng lớn và phức tạp, nhờ đó tăng năng suất và chất lượng công việc của lập trình viên bởi vì thật dễ dàng khi bạn chỉ quản lý và sửa chữa các component của chính bạn. 

Vì các lý do đó component thực sự là tương lai của lập trình ứng dụng Web, và đây cũng là tính năng quan trọng nhất, là Top-Level API mà bộ lõi React đem lại.

● Tăng hiệu năng với Virtual DOM:

React sử dụng khái niệm virtual DOM để tạo lại các component của bạn ngay cả khi component đó đang “live”. Cách tiếp cận này mang lại cho bạn tính linh hoạt rất lớn và cải thiện hiệu năng bởi React có thể tính toán được trước những thay đổi nào cần thực hiện trong DOM và chỉ update DOM theo những thay đổi đó.

Bằng cách đó React tránh và giảm thiểu những hành động gây tốn tài nguyên của DOM và làm cho việc cập nhật giao diện hiệu quả hơn.

● Thân thiệt với SEO:

Một trong những vấn đề lớn của các Js frameworks là nó không thân thiện với các cỗ máy tìm kiếm (search engine). Mặc dù đã có nhiều cải thiện nhưng thực sự search engine vẫn gặp rất nhiều khó khăn khi “đọc” các web app chứa nhiều Js. 

Tuy nhiên React tự hào nằm ngoài số đó bởi vì bạn có thể chạy React trên server và các virtual DOM của component sẽ được render và trả về trình duyệt dưới dạng web page mà không cần các thư viện bên thứ 3 hay bất kì thủ thuật nào. Vì vậy React đáp ứng đầy đủ tính SEO friendly

● React cung cấp nhiều công cụ out-of-the-box

Khi bạn bắt đầu những chuyến phiêu lưu với React, đừng quên cài đặt extension chính thức của React Chrome, nó giúp debug app nhanh hơn. React cũng giúp chúng ta update các Views với Flux – mô hình kiến trúc để thiết kế UI do Facebook đề xuất nhằm kiếm soát workflow của chương trình.

● Dễ dàng viết UI Testcases.

● React Native

React Native được Facebook công bố 2 năm sau React, cung cấp kiến trúc React để phát triển các ứng dụng native (iOS, Android UWP) và hứa hẹn sẽ tiếp nối React thành một kẻ khổng lồ trong lĩnh vực lập trình ứng dụng mobile

● Những bộ não lớn đang “hậu thuẫn” đằng sau React

React được Facebook opensource và hiện được phát triển bởi rất nhiều lập trình viên giỏi trên thế giới, vì vậy tương lai của React cũng cực kì được đảm bảo.

● Dễ dàng chuyển đổi trong công việc: 

Khi thuần thục React, bạn sẽ tận dụng được cốt lõi của nó để dễ dàng chuyển đổi giữa ReactJs và React Native để làm việc trên cả 2 khía cạnh đang “hot” trong giới IT hiện nay là lập trình web và lập trình mobile.

Đến đây là kết thúc phần 1 về Reactjs rồi. Mời các bạn đón xem phần 2 - React Native ở bài tiếp theo và đừng quên để lại bình luận bên dưới nhé. 

Chúc các bạn học tốt!

Read More

Google tham khảo code hay search giải pháp ở những trang như Stack Overflow có khiến bạn trở thành developer kém?

Chào các bạn! Đã gần 4 tháng không gặp nhỉ :D.

Thời gian gần đây mình rất hay nhận được câu hỏi từ các bạn sinh viên năm 1,2 kiểu như:

• "em code cũng khá được nhưng thường phải search Google tham khảo code không biết có quá tệ không?"
• "em luôn lên Stack Overflow để tìm giải pháp cho vấn đề gặp phải, thậm chí những hàm cơ bản của ngôn ngữ em cũng hay quên và phải Google để tìm, vậy có phải em sẽ trở thành một developer tệ không?"

Anh cũng vậy đó em =))

Mình cũng không hiểu tại sao lại có những câu hỏi ngớ ngẩn thế này, nhưng theo mình câu trả lời còn tùy thuộc vào lĩnh vực mà bạn đang học. Software Engineering, Computer Science, Networking hay Database,..

Các lĩnh vực như C.S. đòi hỏi bạn phải có một tư duy tốt, động não suy nghĩ trước khi sử dụng last resort là search Google giải pháp cho vấn đề đó.

Ở đây mình sẽ nói đến lĩnh vực S.E - tập trung nhiều hơn về productivity và chất lượng của project - cũng là lĩnh vực mình đang theo học nên mới dám chém gió =)).

Câu trả lời là: KHÔNG. Dĩ nhiên là không.

Không developer/programmer nào có thể tự vỗ ngực tuyên bố rằng họ có thể hoàn thành một project mà không phải google một vài lần.

Ví dụ đối với các web developers, ngoài kia có hàng trăm HTML tags, cả đống thuộc tính của CSS, rồi Javascript lại là một ngôn ngữ không "strict" làm mọi thứ rối tung lên thì làm sao bạn có thể dễ dàng nhớ hết tất cả mọi hàm, mọi tag, mọi thuộc tính của chúng được chứ? 
Sẽ có những lúc ta cần quyền trợ giúp, và trong 80% trường hợp thì luôn có một người nào đó trên Trái Đất này từng gặp phải vấn đề tương tự và đã giải quyết được nó. Nếu họ là người sống vì cộng đồng dĩ nhiên họ sẽ post lên Internet và mong rằng có thể sẽ giúp được ai đó tiếp tục tập trung vào công việc mà không lãng phí thời gian vô ích.

Việc này làm mình nhớ tới một câu chuyện về Albert Einstein như này: 
Trong một buổi tiệc tối Einstein được hỏi xin số điện thoại của ông, và ông mở phone book ra để tìm nó, người kia bèn hỏi tiếp tại sao ông lại cần phone book để ghi lại cả số của mình trong khi ông là người rất rất thông minh và có trí nhớ siêu đẳng như vậy. Einstein trả lời rằng: "Tại sao tôi cần phải làm não mình trở nên lộn xộn để nhớ những thông tin mà tôi có thể dễ dàng tìm thấy khi tôi cần nó?"

Stack Overflow (SO) - trang hỏi đáp mà bạn hay thấy mỗi lần search vấn đề gì đó trên Google - thực sự là best steroids dành cho các developer. Mình nghiêm túc đấy!

SO hoạt động theo dạng example based - giải quyết vấn đề qua các đoạn code ví dụ - đó là một cách cực kì mạnh mẽ để học một thứ gì đó. Ngay cả khi copy/paste những đoạn code đó không giải quyết được vấn đề của bạn, nó cũng sẽ giảm thiểu thời gian bạn bỏ ra để cho việc hiểu một vấn đề gì đó bằng những đoạn code nhỏ, hơn là phải loay hoay trong đống code dài vô tận của hầu hết các documents hiện nay

Chắc ai cũng muốn có một quyển ^^

Muốn biết cách để thực hiện việc X với Y,Z? Chỉ cần search và đây là cách mà Y, Z nó hoạt động, đây là các tham số đầu vào, đây là những dữ liệu cần thiết.

Gặp phải vấn đề B? Chỉ cần search và...đây...thì ra là do C. Bây giờ đơn giản chỉ việc suy nghĩ làm sao để giải quyết C thôi. Hmmm hay lại lên search làm sao để giải quyết C nhỉ? :D

Mặt khác, việc search Google tham khảo code hay giải pháp của người khác còn giúp bạn viết những đoạn code tốt hơn, tránh việc sử dụng các giải pháp tạm thời (work around) mà không hiểu rõ và giải quyết triệt để vấn đề (dễ thấy ở việc các developers hay lạm dụng try/catch hoặc check null vô tội vạ mà không cần biết vấn đề tại sao Exception đó bị thrown). 
Hay tốn cả tấn thời gian vào việc đọc đống documents cùng với những đoạn code ví dụ dài loằng ngoằng trong đó và dẫn đến việc không bắt kịp deadlines.

How to không trễ deadline???

Là một sinh viên ngành S.E, là một developer, mình thường dành thời gian và chất xám vào việc hiểu cách thức mà hệ thống vận hành và làm sao để giải quyết các vấn đề. Tập trung vào bức tranh toàn cảnh sẽ tốt cho công việc của bạn hơn là cố gắng ghi nhớ rõ từng cú pháp như to_upper(), upper(), hay là toUpper(). Với những vấn đề như vậy khi mắc phải mình có thể search và ôn lại gần như ngay lập tức.

Bởi vì không có lý do nào để reinventing the wheel khi nó đã được người trước giải quyết và áp dụng thành công.

Một số bạn sẽ hỏi rằng: Vậy khi gặp những vấn đề khó hơn và phức tạp hơn thì làm cách nào mà áp dụng search Google vào giải quyết được?

Đối với những vấn đề phức tạp - chúng ta...vẫn áp dụng nguyên tắc trên. Tại sao chúng ta phải dành nhiều thời gian và nỗ lực để giải quyết vấn đề mà có một người nào đó đã giải quyết rồi ?? :D ??. 
Bạn không cần phải tìm hiểu làm cách nào để tạo ra một transmission nếu bạn đang muốn tạo ra một chiếc xe hơi. Vấn đề quan trọng là dành thời gian đó để hiểu được giải pháp mà bạn vừa implement và dành thời gian đó để giải quyết các vấn đề độc nhất mà chỉ mình project bạn gặp phải.

Nói đi cũng phải nói lại.

Bạn cũng không nên lạm dụng việc search Google mà đi copy/paste bất cứ thứ gì bạn tìm thấy, ít nhất thì cũng phải hiểu "sơ sơ" về các đoạn code đó trước khi implement vào project của bạn.

Điều tốt nhất bạn có thể làm là luôn hiểu rõ tại sao vấn đề được giải quyết với giải pháp đó. Cứ như vậy bạn sẽ học được những cái mới một cách nhanh nhất và những vấn đề đó sẽ không phiền bạn trong tương lai nữa. Việc học là việc tìm hiểu, nhưng nếu bạn cứ bỏ qua phần "hiểu" mà chỉ chăm chăm vào việc "tìm" sau đó copy/paste code thì đó chính là thất bại của bạn.

Link sách ở trên: https://www.gitbook.com/book/tra38/essential-copying-and-pasting-from-stack-overflow/details

Chúc các bạn học tốt! Happy coding!

Read More

Thiết kế và Con người (phần 2)

Chào các bạn,  ở phần trước mình đã nêu ra tổng quan và 2 ý kiến cho rằng Thiết kế = Hình mẫu và Chức năng. Hôm nay mình sẽ tiếp tục bài viết chia sẻ về thiết kế trong cuộc sống của chúng ta.

Thiết kế = Thương hiệu

Khi một công ty luôn cung cấp ra thị trường những sản phẩm thẩm mỹ và chất lượng, thì thiết kế của công ty đó bây giờ sẽ biến thành thương hiệu. Nó trở thành một phương tiện để kết nối giữa nhà sản xuất và khách hàng của họ. Người tiêu thụ thường chọn gắn bó với một thương hiệu nào đó lâu dài bởi vì những thương hiệu là hiện thân và đại diện cho những giá trị và ý tưởng của họ, thứ mà đã làm họ cảm thấy hấp dẫn và thoải mái khi sử dụng.

Thiết kế = Trải nghiệm

Về cuối thập nên 90s, một thiết kế được gọi là thành công khi nó gây được sự chú ý, và để lại ấn tượng trong ký ức của khách hàng, và những thứ đấy đã trở thành sản phẩm - "sự trải nghiệm"
Hãy lấy những con búp bê làm ví dụ. Nó không chỉ là "mua" một con búp bê nữa, mà bây giờ trẻ em có thể thiết kế búp bê cho riêng mình, trang điểm nó giống như bản thân, cho nó đi shopping, đi spa, nuôi tóc dài,... Nó không còn là "mua" một con búp bê nữa, mà là tạo ra cả một không gian trải nghiệm riêng xung quanh việc mua và sở hữu con búp bê này.
Thiết kế đã vươn lên khỏi tầm của một sản phẩm độc lập hay một thương hiệu, mà nó còn bao gồm cả trải nghiệm của khách hàng!

Trải nghiệm: hãy nghĩ về lần gần đây nhất mà bạn đến rạp xem phim. Trong suốt 2-3h của bộ phim, bạn bị cuốn hút hoàn toàn vào màn ảnh, câu chuyện và những cảm xúc vui buồn của nhân vật. Khi bộ phim kết thúc bạn cảm thấy mình vừa lấy được một giá trị gì đấy cho cuộc sống của mình: bạn nên trân trọng cuộc sống này hơn? Bạn nên đỗi xử tốt hơn với gia đình và những người mình yêu quý? Hay đơn giản bạn cảm thấy sảng khoái tinh thần.Dù cảm xúc đó là gì đi nữa thì bạn bữa "trải nghiệm" qua một bộ phim, và trải nghiệm đó đã làm bạn hoàn toàn hài lòng vào số tiền đã bỏ ra.

Hiện nay trong lĩnh vực thiết kế nói chung và thiết kế trang web, phần mềm nói riêng, việc lưu tâm tới trải nghiệm của người dùng (User Experience) đã trở thành một vấn đề thực sự lớn và quan trọng. Nó dẫn trở thành một nhóm ngành mới, các nhà thiết kế UX sẽ nghiên cứu và đánh giá cách người dùng cảm nhận về sản phẩm như tính dễ sử dụng, tiện ích, sự hiệu quả, linh hoạt,..
Ví dụ: cái ghế trong rạp có thoải mái hay không, âm thanh quá to hay nhỏ, phòng chiếu có đủ tối hay không,...có ảnh hưởng đến việc xem phim của bạn không?
Lại nhìn rộng thêm nữa, trải nghiệm người dùng không chỉ bắt đầu khi bạn bước vào phòng chiếu mà là khi bạn vừa vào đến cửa rạp bạn đã được chào đón nồng nhiệt bởi đội ngũ nhân viên. Đập vào mắt bạn sẽ là poster và các nhân vật của bộ phim đang chiếu lôi cuốn và gây ấn tượng cho bạn. Khi đó bạn vừa có ý định mua vé xem một bộ phim thì ngay phía trên quầy bán vé là những tấm bảng đen lớn với tên phim, giờ chiếu và tình trạng phòng rõ ràng với nền chữ sáng màu vàng làm bạn cảm thấy ấm áp và được chào đón

Tất cả, tất cả mọi thứ đều tạo nên một hệ sinh thái, một không gian trải nghiệm người dùng

Tư duy thiết kế = Giải quyết vấn đề

Thuật ngữ "design thinking" được phổ biến bởi IDEO và đại học Stanford trong vòng 10 năm trở lại đây. Design thinking liên quan đến một tập hợp các quá trình nhận thức hướng vào giải quyết vấn đề. Các công đoạn của quá trình design thinking bao gồm: Định nghĩa vấn đề, xây dựng sự đồng cảm với người dùng, sinh ra nhiều ý tưởng, tạo mẫu, đưa ra prototype các giải pháp khả thi, thu thập phản hồi, cứ vậy và lặp đi lặp lại. Với cách hiểu này, Design là những thứ gì đó xoay quanh việc giải quyết vấn đề

Tóm lại, Thiết kế là một thuật ngữ dùng để chỉ một sản phẩm hoặc một dịch vụ nào đó trông như thế nào, cách nó hoạt động, cảm xúc của người dùng khi tương tác với nó, những trải nghiệm nào mà khách hàng nhận được, và cách suy nghĩ, tư duy và hành động để giải quyết vấn đề. Đó cũng là sự biểu hiện của Con người!

Bài viết dựa trên "Design and the Self" của blogger Irene Au

Read More

Thiết kế và Con người (phần 1)

Bất cứ nơi đâu chúng ta đến, ta đều bị vây quanh bởi những thiết kế tồi tệ - từ chỗ ngồi của máy bay làm biến dạng tư thế ngồi của chúng ta đến một chiếc xe máy với thiết kế khiếm nhã. Những cảnh quan đã từng là màu xanh của sự sống và bây giờ một màu xám xịt đang dần phủ lên. Môi trường xung quanh của chúng ta chứa đầy những cơ hội bị bỏ lỡ để đem đến sự hài lòng, phấn khích và niềm vui cho cuộc sống con người!

Chỗ ngồi máy bay làm biến dạng tư thế ngồi

Những đồ vật với thiết kế tồi tệ làm chúng ta chậm lại, và làm phiền lòng mọi người - giống như tòa nhà xấu xí của ông hàng xóm làm bạn nhăn nhó mỗi khi nhìn thấy nó, hay cái remote TV với quá nhiều nút bấm, hay chỉ là một phần mềm không thể hoạt động đúng như chức năng của nó.
Những thứ như vậy đa phần là hậu quả của sự hiểu lầm, tham lam, không đồng cảm, thiếu tập trung. Những thiết kế tồi tệ đặc biệt làm phiền lòng con người khi ảnh hưởng rất nhiều tới hành tinh xanh này. Nói có hơi quá, nhưng đôi khi nó có vẻ như đang lấp đầy thế giới này bằng rác rưởi linh tinh.

Cùng với sự trưởng thành của nền công nghiệp thông tin, chúng ta đã chứng kiến sự quan tâm và đầu tư nhiều hơn cho việc thiết kế. Nhiều công ty hiện giữ vững quan điểm cho rằng thiết kế có thể trở thành lợi thế trong việc cạnh tranh với các đối thủ khác. Những hiểu biết của con người về ý nghĩa của "thiết kế" ngày càng trở nên sâu sắc qua từng năm tháng, vượt qua cả thẩm mỹ để đến với những kỹ năng giải quyết vấn đề. Trong những thập kỷ gần đây, trong ngành công nghiệp phần mềm chúng ta cho rằng một sản phẩm là "thiết kế toàn diện" khi sản phầm đó được cho rằng hữu dụng, dễ dùng và hấp dẫn khách hàng. Chúng ta có thể làm tốt hơn vậy - chúng ta cần làm tốt hơn vậy!

Tôi đang muốn ám chỉ điều gì? Trước khi chúng ta đi sâu vào vấn đề, hay để tôi cung cấp cho bạn một vài bối cảnh bằng cách quay trở lại và review những cấp độ khác nhau mà thiết kế có thể được hiểu.


Thiết kế = Hình mẫu

Hầu hết mọi người đều cho rằng thiết kế thì thường liên quan đến thẩm mỹ. Những nguyên tắc phổ quát của cái đẹp, như là Tỉ lệ vàng (Golden Ratio), quy tắc 1/3 (Rule of Thirds) hay là những quy tắc của sự tương đối, căn chỉnh liên kết, tương phản và sự lặp lại thông báo cho tiềm thức của chúng ta rằng vật đó có đẹp hay không. Ở mức độ hiểu biết này đối với thiết kế, chúng ta sẽ nghĩ rằng thiết kế là vẻ ngoài của đồ vật, ví dụ như chiếc xe hơi trông có vẻ chạy nhanh, có vẻ đắt hay có vẻ rất cứng cáp,...

Thiết kế = Chức năng

Tuy nhiên thiết kế không phải chỉ là vật thế đó trông như thế nào mà còn là nó hoạt động như thế nào. Chúng ta xem một vật thể là "thiết kế toàn diện" không chỉ khi nó đẹp mà còn khi nó dễ sử dụng. Thiết kế tốt sẽ giúp cuộc sống chúng ta dễ dàng hơn. tiết kiệm thời gian hơn, và giúp ta không cần phải suy nghĩ nhiều, từ đó giảm thiểu stress trong cuộc sống và giữ gìn ý chí và thiện chí đối với những người xung quanh. Trong trường hợp này, thiết kế  giống như là một cái tủ lạnh - khi nó hoạt động thì mảy may chẳng ai chú ý, nhưng khi nó ngừng hoạt động thì mọi thứ trở nên tệ hại cả lên!

Ở bài tiếp theo mình sẽ đưa đến một khía cạnh hoàn toàn khác của thiết kế, các bạn hay đón xem nhé!

Bài viết dựa trên "Design and the self" của blogger Irene Au

Read More

Private IP và Public IP là gì? Và chúng khác nhau như thế nào?

Chào các bạn!

Hôm nay nhân dịp chuẩn bị ôn thi Mạng máy tính, mình xin chia sẻ một số thứ cơ bản về Private và Public IP.

Một địa chỉ IP (Internet Protocol) dùng để nhận biết mỗi máy tính, thiết bị trong mạng. Khi máy tính giao tiếp với nhau trên Internet hoặc trong mạng LAN cục bộ, thông tin được gửi thông qua địa chỉ IP của các thiết bị. Bạn phải cần một địa chỉ IP nếu bạn đang host một server cho phần mềm vừa làm - các máy trạm (client) cần biết địa chỉ IP đó nếu muốn kết nói đến server để sử dụng phần mềm.

Địa chỉ IP thường được chi làm 2 loại: Public và Private. Nếu bạn đang tự hỏi không biết giữa chúng khác nhau như thế nào, thì xin mời đọc tiếp phần tiếp theo.

PUBLIC IP

Public IP là địa chỉ được ISP (nhà cung cấp dịch vụ Internet) cấp và có thế được "nhìn thấy" và truy cập từ Internet. Giống như địa chỉ nhà dùng để nhận thư tín, bưu phẩm vậy. Mỗi public IP chỉ tồn tại độc nhất trên mạng Internet cho cả toàn cầu, vì đó không thể tồn tại hai thiết bị (server, máy tính, router,...) có cùng địa chỉ public IP.

Có thể tìm public IP của mình bằng cách search Google

Đa phần người dùng phổ thông không có quyền kiểm soát địa chỉ public IP của mình, quyền đó thuộc về ISP.

Một public IP có thể là tĩnh (static) hoặc động (dynamic) tùy theo loại dịch vụ của người dùng. Một địa chỉ public IP tĩnh không thay đổi và thường được dùng cho hosting các trang web, hoặc dịch vụ trên Internet. Mặt khác, địa chỉ động được chọn từ một "hồ chứa" các địa chỉ có sẵn và thay đổi mỗi lần người dùng kết nối đến Internet.
Đa số ISPs hiện nay cung cấp địa chỉ IP động cho người dùng!

Ví dụ: Các web server, email server, hay các server game bất kì đa số đều được kết nối trực tiếp từ Internet thông qua địa chỉ public IP. Hoặc ở các mạng gia đình, ký túc xá,... thì router giữ public IP để kết nối trực tiếp đến Internet. Các máy tính, smartphones,... và các thiết bị "đằng sau" của router chỉ sử dụng các địa chỉ private IP để kết nối đến router. Router bây giờ hoạt động như một người trung gian, forward lưu lượng dữ liệu đến các địa chỉ IP cục bộ theo yêu cầu, và đảm bảo dữ liệu gửi/nhận đến các địa chỉ chính xác!

Router - "bộ não" của các mạng gia đình thường gặp

PRIVATE IP

Private IP là các địa chỉ được cấp phát bởi InterNIC cho phép các công ty, tổ chức có thể tạo cho họ một mạng cục bộ riêng. Có ba dãy IP ở class A, class B và class C được IANA (Tổ chức cấp phát số hiệu trên Internet) dành riêng để đánh địa chỉ private IP.

Các dãy địa chỉ được cung cấp để làm private IP

Private IP dùng để phân biệt các máy tính và thiết bị trong một mạng "riêng" bao gồm mạn
g gia đình, trường học, hoặc các tổ chức, công ty, bussiness LANs trong các sân bay, khách sạn,... Và nhờ đó các thiết bị trong mạng có thể giao tiếp được với nhau.

Một ví dụ khác, một mạng X bao gồm 10 máy tính, mỗi máy được gán địa chỉ IP từ 192.168.1.1 đến 192.168.1.10. Không như public IP, quản trị mạng cục bộ có thể tự do gán IP theo ý thích (nhưng phải thuộc dãy private IP ở trên và theo đúng class đang sử dụng)

Khi một máy tính kết nối đến router và được gán một địa chỉ private IP, các thiết bị cục bộ trong mạng "nhìn thấy" máy tính này qua private IP. Tuy nhiên với private IP thiết bị sẽ không thể kết nối trực tiếp đến Internet được, tương tự các thiết bị "bên ngoài" của mạng cũng không thể kết nối trực tiếp đến thiết bị giữ private IP, mà tất cả phải thông qua router. 

Vì vậy với ví dụ mạng gia đình ở trên, thì ở góc nhìn từ bên ngoài, mọi thiết bị trong mạng gia đình, ký túc xá,.. đều đang giao tiếp với Internet thông qua một địa chỉ IP duy nhất - địa chỉ public IP của router!

Để cho phép truy cập trực tiếp đến thiết bị cục bộ bằng private IP, bạn phải cần sự hỗ trợ của NAT (Network Address Translation) hoặc kết nối trực tiếp thiết bị đến Internet mà không thông qua bất kỳ router nào!

Bạn có thể tìm thấy địa chỉ private IP của mình bằng cách mở Command Prompt và gõ ipconfig. Vì hầu hết mạng hiện nay vẫn đang sử dụng IPv4 nên con số xuất hiện ở dòng "IPv4 Address" chính là private IP của bạn. Với mạng gia đình, hầu hết sẽ là 192.168.1.1 hoặc 192.168.1.2.

Private IP class A của nhà mạng ký túc xá

NHỮNG HIỂU LẦM THƯỜNG GẶP VỀ PRIVATE IP

Nhiều người cho rằng private IP là địa chỉ được dùng cho các hành động lén lút trên Internet, và do đó nó không thể bị phát hiện. Nhưng điều đó KHÔNG ĐÚNG!

Không như nhiều người nghĩ, địa chỉ private IP không giống như số điện thoại riêng tư, nó chỉ là một địa chỉ thuộc về một mạng "riêng tư". Trong thực tế không một địa chỉ public IP nào mà không thể bị "trace" - theo dõi, bởi vì chính giao thức TCP/IP này được thiết kế nhằm mục đích công khai và minh bạch!

Read More

Tại sao bỏ việc để theo đuổi ước mơ là một ý tưởng cực kì tồi tệ

Chúng ta thường được nghe qua sự thành công trong sự nghiệp của các doanh nhân là nhớ vào chấp nhận mạo hiểm, rủi ro để nhận phần thưởng. "Chúng tôi dám dũng cảm nắm bắt cơ hội và làm liều thôi" - đó là những phát ngôn của họ khi họ đã thực sự thành công, tuy nhiên sự thật thì điều đó khá hiếm xảy ra, thậm chí chỉ xuất hiện trong những câu chuyện ngụ ngôn!

Liệu mạo hiểm để thành công có hoàn toàn đúng

Tôi từng đọc đâu đó trên Internet, rằng có một người bạn trên là Bryan chấp nhận từ bỏ công việc Technical writer  (viết tài liệu kỹ thuật, hỗ trợ khách hàng,...) cho một tập đoàn nằm trong danh sách Fortune 500 để tìm một việc gì đó thực sự mới mẻ.

Trong ngày làm việc cuối cùng của Bryan, mọi người trong văn phòng bộc lộ nhiều thái độ khác nhau: từ ghen tị đến bất ngờ. Họ không thể tin rằng anh lại có thể rời công ty như vậy, rằng anh ta vừa có một bước nhảy thực sự lớn trong sự nghiệp. Nhưng thực tế Bryan đã lên kế hoạch cho thời khắc ấy từ 10 năm trước.

Đã đến lúc phải nghỉ việc và chuyển sang một công việc mới?

________________________

Đến đây tôi tự ngẫm rằng, tôi dù đang học công nghệ phần mềm, nhưng lại ấp ủ niềm đam mê khởi nghiệp. Liệu rằng sau này khi có một công việc làm ổn định trong một công ty có sức hút đủ lớn, với mức thu nhập chấp nhận được, bạn có sẵn lòng nghỉ việc để làm một điều gì đó mới mẽ như Bryan?

Bởi vì đơn giản nếu thất bại tôi có thể mất gần như hoàn toàn những gì mà công sức bản thân đã gây dựng trong bao năm qua. Tuy nhiên nếu thành công thì sẽ như một câu chuyện cổ tích! Tôi nên làm gì?

______________________

Ai từng đọc qua một số quyển sách kinh doanh, nghe những câu chuyện về những người tự thân lập nghiệp, hoặc ghé thăm những người bạn cũ thành đạt thời Đại học, bạn luôn nghe đi nghe lại cụm từ "Tôi dám dũng cảm nắm bắt cơ hội và làm liều thôi".

Cụm từ này được nhắc đi nhắc lại khi nói về những thành công lớn. Nó như là một câu chuyện về rủi ro và phần thưởng mà chúng ta hay nghe từ miệng của những doanh nhân giàu có, các diễn viên điện ảnh nổi tiếng hay những nghệ sĩ trứ danh... Nhưng, nó đều là những lời nói dối!

THÀNH CÔNG THƯỜNG ĐẾN RẤT MUỘN

Jeff Goins - một nhà văn, doanh nhân nổi tiếng - từng được phỏng vấn rằng, làm cách nào anh ta có thể trở thành một nhà văn toàn thời gian. Mọi người muốn biết lý do lớn nhất mà anh theo đuổi công việc này là gì?

"Không, không có, không có gì là lớn lao cả, chỉ là sự cộng hưởng của những thành công nhỏ qua thời gian..." 

Anh ta không có khoảnh khác giống như Jerry Maguire - một nhân vật trong bộ phim điện ảnh cùng tên đã quyết định từ bỏ mọi thứ khi đang ở đỉnh cao sự nghiệp để có thể sống và hành động theo đúng với cảm nhận của mình - tuy nhiên khi bắt đầu có một cái nhìn chân thành về sự thành công, anh ta nhận ra rằng chúng ta cần có những chiến lược chậm và chắc.

Để thành công cần luyện tập ngày qua ngày

Năm 1975, Bill Gates thành lập Microsoft. Nhưng mãi đến 6 năm sau ông mới ký được hợp đồng đầu tiên với IBM. Sau đó cần đến 5 năm nữa công ty mới IPO (phát hành cổ phiều lần đầu ra công chúng), giúp Gates trở thành triệu phú và được mọi người tung hô là một vĩ nhân với "thành công chỉ qua một đêm". 

Với Steve Jobs, thậm chí nó còn mất nhiều thời gian hơn. Ông cùng với Steve Wozniak thành lập Apple Computer năm 1976, nhưng không có gì nổi bất đến 1984, với sự ra đời của Macintosh. Sau đó ông bị đuổi khỏi công ty và sau khi trở lại thì sự nghiệp của ông mới thành công như hôm nay.

Một câu chuyện nổi tiếng khác trong giới công nghệ, nhà đồng sáng lập Google là Larry Page và Sergey Brin cũng gặt hái thành công khá chậm. Họ mở công ty năm 1996, và đến 8 năm sau công cụ tìm kiếm của họ mới đánh bại tất cả các đối thủ khác thời đấy và giúp Google hoàn thành thương vụ IPO với mức vốn hóa thị trường lên tới 23 tỉ USD.

Cả 3 ví dụ trên đều phù hợp với thuyết "luyện tập thận trọng" của K. Anders Ericsson và thuyết "quy tắc 10 000 giờ" của Malcoml Gladwell sau đó trở nên phổ biến. Trong nghiên cứu của ông, Ericsson cho rằng để một người nào đó trở thành chuyên gia trong một lĩnh vực, họ cần ít nhất 10 000 giờ luyện tập. Nói cách khác, trước khi bỏ việc hoặc chuyển sang một ngành nghề mới, hãy dành thời gian luyện tập, xây dựng kĩ năng cần thiết để làm việc đó một cách tốt nhất.

Trước khi nghỉ việc, dành thời gian xây dựng những kỹ năng cần thiết để làm tốt công việc mới

SAI LẦM TỪ NHỮNG CƠ HỘI LỚN

Trong bối cảnh hiện nay, chưa bao giờ sự gia tăng không ngừng của những startup lại lớn như thế này. Kinh doanh trực tuyến càng trở nên dễ dàng - chúng ta vẫn luôn bị ám ảnh bởi những tư tưởng "chấp nhận rủi ro", "dám làm liều"...

Tại sao? Bởi vì tất cả mọi người xung quanh đều có suy nghĩ rằng để thành công trong sự nghiệp chắc hẳn chúng ta phải dám đánh một ván cược lớn để hưởng thành quả to lớn. 

________________________

Thực ra tư tưởng khởi nghiệp đang dần ăn sâu vào từng con người, ngay từ thời sinh viên đã liên tục có những buổi hội thảo, chuyên đề về startup, dạy cách để đạt thành công trong sự nghiệp. Hàng trăm, hàng nghìn quyển sách "dạy đời" truyền cảm hứng rằng con người trong cuộc sống phải chấp nhận rủi ro, chấp nhận mạo hiểm để gặt hái được thành công. Ngay cả lang thang trên Internet cũng không khó để bắt gặp những bài viết kiểu như vậy!.

Tư tưởng đó luôn ám ảnh tôi và cả những người rất giỏi tôi từng biết.

Mọi khi có dịp tụ tập từ quán nước vỉa hè đến các quan coffee sang trọng chúng tôi đều nói hoặc nghe người khác nói về con đường tương lai. Ai cũng muốn thành công sớm, có cho mình một công ty riêng, một sự nghiệp ổn định. Mà không ai nghĩ rằng làm sao để có được nó, liệu "dám mạo hiểm, nắm bắt cơ hội, chấp nhận rủi ro" đã đủ chưa? Hãy phải trải qua "10 000 giờ" luyện tập gian khổ?

________________________

Vâng, thực tế mọi chuyện không diễn ra dễ dàng như vậy!

Chắc hẳn các bạn còn nhớ câu chuyện Thỏ và Rùa này chứ!

Dr. Robert Maurer, tác giả của "One Small Step Can Change Your Life", cho rằng chúng ta thích ý tưởng về một "bước nhảy lớn", ngay cả khi nó có thể gây hại. Nhưng nó không phải là cách mà những sự đổi mới trên thế giới xảy ra. Một lý do là bộ não của chúng ta được phản xạ để từ chối những thay đổi lớn. Đây là cách ông ta giải thích nó trong một bài phỏng vấn:

Bộ não phản ứng với những thách thức lớn bằng cách kích hoạt các amygdala, trung tâm sợ hãi trong não. Nếu thách thức được coi là quá lớn, nếu đó là người sợ thất bại, nỗi sợ hãi trở nên to lớn và người đó sẽ bỏ cuộc.

Maurer thậm chỉ còn đưa thêm dẫn chứng về "kaizen", một thuật ngữ Nhật Bản được ghep từ chữ "kai" - thay đổi và "ken" - tốt hơn. Tức là một quá trình "thay đổi để hoàn thiện", hay "cải tiến liên tục". Thay vì cố gắng để giảm cân, hãy ra ngoài luyện tập 1 phút mỗi ngày, rồi 2 phút, 3 phút,... Theo thời gian, những thứ nhỏ nhặt lại trở nên lớn lao và bền vững.

Nhà triết học nổi tiếng Aristotle từng nói "Chúng ta là những gì chúng ta thường xuyên làm. Vì vậy sự hoàn hảo không phải là hành động mà là thói quen". Nếu làm một điều gì đó đủ lâu, bất kể điều gì dần dần cũng trở thành thói quen.

THAY VÌ MẠO HIỂM, CHẤP NHẬN RỦI RO ĐỂ THỰC HIỆN "BƯỚC NHẢY VỌT"

Vậy làm sao để áp dụng những lời khuyên của Maurer vào thực tế?

Đầu tiên, hãy bắt đầu từ những việc nhỏ, thật nhỏ. Nhiều người cho rằng để có được thành công, họ phải làm nó thật to lớn. Nhưng nó không thực sự đúng. Mỗi ngày, mọi người theo đuổi ước mơ của họ và đều mắc sai lầm. Họ đặt mục tiêu "trên cung trăng" mà không chuẩn bị những bước đầu cơ bản nhất. Và kết quả là họ thất bại.

Thứ hai, xây dựng thói quen của bạn theo thời gian.  Mọi thứ đều phải trải qua thực hành. Và càng làm nhiều, mọi việc càng trở nên dễ dàng hơn. Thói quen làm mọi thứ trở nên dễ dàng hơn, và làm mỗi người chúng ta tốt hơn.

Thỏi quen giúp mọi thứ trở nên dễ dàng hơn và giúp mỗi người chúng ta trở nên hoàn thiện hơn.

Cuối cùng, hãy luôn nhớ rằng bạn xây dựng kĩ năng và cũng chính bạn trau dồi cho những kĩ năng đó. Và sau cùng, những gì bạn nhận được không phải là những bước nhảy vọt bấp bênh, mà là một cây cầu vững chắc mà bạn đã chậm rãi, thận trọng xây nó theo thời gian. Điều này sẽ không trở thành một câu chuyện tốt để làm phim cho Hollywood, nhưng nó là cách tốt nhất để thành công tồn tại lâu dài!

____________________________

Thực sự tôi không nghĩ ý kiến bỏ việc và mạo hiểm để Startup là tồi, bởi vì sau này dường như tôi cũng sẽ làm vậy. Tuy nhiên trước đó bạn phải đảm bảo có một quá trình luyện tập dài để có những kỹ năng đáp ứng cho công việc.

Dù bạn là ai, dù bạn có giỏi hay không, dù cho mọi người xung quanh đang gặt hái nhiều thành công to lớn, có nhiều "bước nhảy vọt", trong lúc chúng ta luôn thất bại, xin đừng nản lòng. Hãy cố gắng tìm cho mình những thứ mình thích, luyện tập và trau dồi kỹ năng để làm việc đó. Rồi khi đạt đến một trình độ nhất định, bạn chắc chắn sẽ thành công. Và cho dù có xui xẻo thất bại thêm nhiều lần nữa thì cũng là vì những thứ bạn yêu thích. Nó rất xứng đáng mà, phải không?

Tôi cũng từng có một quá khứ thành công, và cũng đầy thất bại. Vì quá khứ huy hoàng thời phổ thông làm tôi trở nên tự kiêu, tự mãn. Đôi lúc tôi cũng thử mạo hiểm bỏ học tập ở trường, nắm bắt cơ hội để đi làm từ thời sinh viên năm 2, tuy nhiên vấp phải đầy khó khăn và đôi lúc tôi thực sự gục ngã. Tuy nhiên kết quả nhân được là kinh nghiệm sống, và quan trọng là rút ra quyết định dừng lại để trau dồi, học tập thêm kỹ năng và cố gắng đạt thành công một cách chậm rãi, bền vững. 

Trong suốt quá trình học hỏi và mạo hiểm của mình tôi không bỏ ra quá nhiều thời gian để hối hận, ngay cả khi thất bại. Bởi vì chẳng có thuốc chữa hối hận, mà lãng phí thời gian dành cho nó cũng chẳng giúp ích gì cho bản thân tôi cả. Cuộc sống có thể sẽ khó khăn và khắc nghiệt với bạn, nếu cảm thấy thiều định hướng, hãy thử bắt đầu với những gì bạn thích làm và làm khá về nó. Bằng cách đó, khi tưởng chừng như mọi cánh cửa đã đóng, thì biết đâu đấy sẽ có một cánh cửa mở ra với bạn, giống như tôi vậy!

____________________________

Hãy cứ ước mơ, hãy cứ dại khờ. Luyện tập ngày qua ngày rồi thành công sẽ đến với bạn

Bài viết tham khảo từ những quan điểm cá nhân của Jeff Goins - một doanh nhân và nhà văn nổi tiếng.

Read More

Sơ lược về công nghệ phần mềm và quy trình phát triển phần mềm

Chào các bạn,
Khi chúng ta nói đến lập trình máy tính (computer programming), ta không chỉ đề cập riêng việc viết code bằng các ngôn ngữ lập trình như Java, C#, C++, Python,... mà còn là cả một quá trình phát triển phần mềm. Chỉ đơn thuần học cách viết mã nguồn bằng ngôn ngữ lập trình là KHÔNG ĐỦ để trở thành một người phát triển phần mềm (software developer) tài giỏi. Bạn cần phải nắm rõ cách thiết kế một chương trình theo phương pháp lập trình hướng đối tượng (object-oriented programming). Khi đó bạn sẽ không chỉ đơn thuần là một coder lúc nào cũng chỉ biết ôm máy tính để lập trình, mà sẽ trở thành một developer hiểu sâu và rộng kiến thức trong nhiều lĩnh vực.

Kỹ nghệ phần mềm - Xu hướng của đa số sinh viên CNTT hiện nay

VỊ TRÍ BẮT ĐẦU TRONG NGÀNH CÔNG NGHỆ PHẦN MỀM

Vậy thì coder, programmer, developer và engineer là gì? Và nó khác nhau chỗ nào?

Về cơ bản, coder (thợ code) chỉ viết các mã lệnh logic với ngôn ngữ lập trình trong phạm vi yêu cầu mà anh ấy không cần biết nhiều về logic của chương trình. Họ được cung cấp định nghĩa về các bussiness logic và flowchart hoặc dễ hiểu hơn là các vấn đề được mô tả bằng ngôn ngữ tự nhiên, mã giả,... và nhiệm vụ của họ là chuyển nó sang mã nguồn lập trình.
Còn Programmer thì cũng tương tự như coder, tuy nhiên anh này là người đề ra giải pháp giải quyết các vấn đề, cung cấp bussiness logic cho coder. 

Tôi đang trên đường trở thành một Engineer, còn bạn thì sao?

Developer là người không chỉ code mà còn tham gia vào tất cả các quá trình của SDLC (Software development life cycle). Nếu dự án có vấn đề mà bạn chưa định hình được nó và hướng giải quyết thì các developer sẽ giúp bạn phân tích vấn đề, và tìm cách giải quyết nó. Vậy developer là người vừa lập trình, vừa định hướng phát triển sản phẩm
Engineer là một thuật ngữ được sử dụng ở mức cao cấp nhất. Anh này hoạt động ở cả phần lập trình, phân tích thiết kế (bussiness level) và bảo trì. Là những developer giỏi, có khả năng phân tích và giải quyết các vấn đề phức tạp. Những anh này thường sẽ được trả lương xấp xỉ với quản lý dự án (Project Manager), tuy nhiên thiên về hướng phát triển kỹ thuật hơn.

Ở bài này mình chỉ nói sơ về các vị trí bắt đầu khi bước vào ngành CNPM, bởi vì kiến thức thực tế còn quá giới hạn nên các vị trí khác đành chờ phần sau vậy :D

QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Chúng ta xây một ngôi nhà với các giai đoạn được xác định rõ ràng (làm móng, xây nền, dựng cột, xây tường,...), và áp dụng các nguyên tắc kỹ thuật vào tất cả các giai đoạn đó. Làm phần mềm cũng vậy, bạn xây dựng một chương trình qua các công đoạn và áp dụng các phương pháp, qui tắc phát triển phần mềm vào từng công đoạn. Trình tự các công đoạn đó từ giai đoạn ý tưởng (conception) đến vận hành (operation) được gọi là qui trình phát triển phần mềm (Software Development Life Cycle)

Có 5 giai đoạn chính trong qui trình phát triển phần mềm: Phân tích (Analysis), Thiết kế (Design), Cài đặt mã nguồn (Coding), Kiểm thử (Testing) và Vận hành (Operation). Phần mềm ra đời dựa trên yêu cầu của người dùng.

PHÂN TÍCH

Ví dụ: một người muốn có một danh bạ online. Trong giai đoạn phân tích, chúng ta thực hiện nghiên cứu tính khả thi, chúng ta phân tích các vấn đề và xác định xem liệu giải pháp có thực sự khả thi. Và nếu giải pháp đó khả thi, thì kết quả của giai đoạn này sẽ là bảng "Đặc tả yêu cầu"  - requirement specification - để mô tả các chức năng của chương trình. Các tính năng này phải được phát biểu theo những cách có thể kiểm chứng được. Một trong những tính năng của danh bạ online là có khả năng tìm kiếm một người dựa trên first name của họ. Chúng ta có thể kiểm tra tính năng đó bằng cách chạy trực tiếp chương trình và tìm kiếm, và kiểm tra xem chương trình có hoạt đông đúng và cụ thể khi tên của một người có trong danh bạ, và người không có trong danh bạ được gõ vào khung tìm kiếm. Những việc làm đó thuộc pha Kiểm thử, thứ mà mình sẽ nói tới nó sau.

THIẾT KẾ

Trong giai đoạn thiết kế, chúng ta sẽ chuyển bảng đặc tả yêu cầu thành bảng "Thiết kế chi tiết" - detailed design của chương trình. 
Trong giai đoạn này chúng ta sẽ thiết kế các giao diện người dùng của chương trình (User Interface) -  bao gồm các bước: Lập danh sách các màn hình (view, form,...) dựa vào Use Case, vẽ sơ đồ mối quan hệ giữa các màn hình, Thiết kế các đối tượng trên mỗi màn hình (Sắp xếp vị trí các button, textbox,...) theo các qui tắc về thiết kế giao diện, cuối cùng đặc tả, giải tích cách hoạt động của các đối tượng trên từng màn hình đó.
Với một chương trình thiết kế hướng đối tượng (object-oriented design), kết quả của pha này không thể thiếu Danh sách các lớp (class) được dùng để đáp ứng yêu cầu. Chúng ta sẽ thiết kế các lớp đối tượng, dựa vào những yêu cầu cần thiết, các kiến thức về kế thừa, đa hình để thiết kế các lớp đối tượng, và mô hình hóa chung bằng các sơ đồ (ví dụ UML - Unified Modeling Language). Ví dụ: với chương trình danh bạ online ở trên thì chúng ta có thể cần các class như Person, Phone, Group,...

Thiết kế phần mềm - giai đoạn không thể thiếu trong qui trình phần mềm

Ngoài ra ở một số chương trình đặc thù, ta còn cần thiết kế các tầng dữ liệu cho chương trình. Dữ liệu ở đây có thể là hệ thông tập tin đơn giản, đến các hệ  cơ sở dữ liệu phức tạp. Sau đó vẽ sơ đồ mô hình hóa, đặc tả dữ liệu.
Cuối cùng không thể thiếu là thiết kế xử lý cho chương trình. Chi tiết hóa các kịch bản usecase, các luồng logic trong chương trình. Và sử dụng sơ đồ tuần tự để mô tả.

CÀI ĐẶT MÃ NGUỒN

Trong giai đoạn cài đặt mã nguồn, chúng ta triển khai các thiết kế thành một chương trình thực tế bằng các ngôn ngữ lập trình như Java, C#, Python, hay các hàm API,... Chúng ta đã có một bảng thiết kế cấu trúc hoàn chỉnh, thì việc triển khai thành mã nguồn không thực sự quá khó khăn.

Nhiều người hay lầm tưởng làm phần mềm chỉ là ngồi viết code!

KIỂM THỬ

Khi quá trình triển khai mã nguồn hoàn chỉnh, chúng ta sẽ đến với giai đoạn kiểm thử. Trong giai đoạn này chúng ta sẽ chạy chương trình với nhiều bộ dữ liệu để kiểm chứng là chương trình chạy đúng theo đặc tả yêu cầu. Hai loại kiểm thử dành cho các chương trình hướng đối tượng là: kiểm thử đơn vị (unit testing) và kiểm thử tích hợp (integration testing). 

Giai đoạn dễ gây "mâu thuẫn" giữa các thành viên trong team nhất!

Kiểm thử đơn vị thường do lập trình viên thực hiện, kiểm nghiệm từng class riêng biệt, từng hàm trong mã nguồn trong môi trường cô lập. Còn đối với kiểm thử tích hợp chúng ta kiểm tra các class có làm việc đúng khi ghép lại với nhau hay không, và quá trình test diễn ra ngay sau unit testing. Hành động "bất hủ" dùng để phát hiện và loại bỏ lỗi của quá trình  thiết kế và cài đặt gọi là "debugging". Nếu tìm được lỗi, chúng ta phải quay về pha trước đó để sửa chữa và hoàn thiện chương trình.

Bonus cho các bạn 1 câu nói bất hủ của Dijkstra :

"Program testing can be used to show the presence of bugs, but never to show their absence!"

VẬN HÀNH

Cuối cùng sau khi quá trình kiểm thử kết thúc thành công, chúng ta đi vào pha vận hành, khi đó chương trình sẽ được đưa vào sử dụng thực tế. Thứ quan trọng nhất và mất nhiều thời gian nhất trong pha này là bảo trì phần mềm (software maintenace). Ngay cả sau khi phần mềm được đưa vào sử dụng, chúng ta hầu như luôn phải sửa đổi nó. Bởi vì khách hàng có thể yêu cầu thêm tính năng, hoặc các lỗi mới được tìm thấy. 
Thống kê cho thấy, xấp xỉ 70% phí của phần mềm thuộc về công đoạn bảo trì. Vậy nên khi phát một phần mềm chúng ta phải nhắm vào phần mềm dễ bảo dưỡng, bỏ thời gian và công sức ra để phân tích thiết kế và lập trình cẩn thận. Ngay cả nó có mất thời gian, và chi phí giai đoạn đầu, nhưng trong qua trình hoạt động lâu dài, các phần mềm có sự chuẩn bị thiết kế chu đáo sẽ ít tốn kém hơn. Đây là một điểm rất quan trọng mà các bạn nào muốn trở thành một nhà phát triển phần mềm giỏi cần phải lưu ý!

--------------------------------------------------------------------------------------------

Giai đoạn thiết kế luôn là giai đoạn quan trọng nhất trong qui trình phần mềm!

Chào và chúc các bạn học tốt!

Read More