2016


Chào các bạn,

Đã lâu rồi mình không viết bài về C# nhỉ :D, hôm nay nhân lúc đang làm đồ án môn Thiết kế phần mềm, cần sử dụng OOPinheritance,.. khá nhiều, mình xin viết một article nho nhỏ về hàm dựng (constructor) trong tính kế thừa của C#.



Theo nguyên tắc, khi khởi tạo đối tượng của lớp con, thì hàm dựng (constructor) của lớp cha sẽ được gọi trước, sau đó mới tới đổi tượng của lớp con.

Ví dụ mình có class Base Child kế thừa từ lớp Base như sau:


Thì khi Run, chương trình sẽ cho kết quả như sau:


Rõ ràng constructor của lớp Base đã được gọi trước! 

Chúng ta có thể kiểm tra các trường hợp khác:
 - Cho lớp Base thành abstract.
 - Sửa lại hàm Main, khởi tạo đối tượng bằng Child c = new Child();

Tất cả đều cho kết quả tương tự.

Chúng ta tiếp tục thử một trường hợp đặc biệt khác, thêm một constructor mới chứa tham số vào class Base Child như sau:


Run chương trình, chúng ta được kết quả sau:


Ở đây bạn thấy, dù chúng ta tạo đối tượng với constructor có tham số, thì constructor cơ bản của lớp Base luôn được gọi.
Bây giờ nếu bạn xóa đi constructor cơ bản (không tham số) của lớp Base và Run chương trình thì sẽ bị lỗi ngay lập tức.


Từ đó ta rút ra các kết luận sau:

Về vấn đề lỗi khi xóa constructor cơ bản của lớp Base: Khi một class được tạo ra, nếu class đó chưa có constructor, Visual C# sẽ tự động generate một constructor mặc định (không tham số) cho chúng ta, vì nếu không làm vậy chúng ta sẽ không thể tạo một object mới thuộc class đó rồi :D. Tuy nhiên nếu bạn tạo thêm một constructor khác có tham số, và xóa constructor mặc định cơ bản đi, thì Visual C# sẽ cho rằng class của bạn đã có thể tự tạo một object mới và sẽ không generate constructor mặc định. Điều đó đồng nghĩa với việc các object được tạo bằng cách gọi "new Base()" sẽ không thể khởi tạo.

Về vấn đề chính về constructor trong kế thừa mình muốn nói là khi bạn khởi tạo một đối tượng lớp con Child, thì C# sẽ automatically gọi constructor mặc định-không tham số của lớp cha Base trước, sau đó mới gọi constructor của lớp con (constructor nào của lớp con thì còn tùy mình new đối tượng với tham số gì :D).


Tại sao lại như vậy?

Theo ý kiến chủ quan của cá nhân mình, thì bạn cứ tưởng tượng lớp con Child là một "cụ thể hóa" của một lớp cha, giống như một chiếc xe, trước khi thành một chiếc xe nó phải qua công đoạn lắp ráp khung xe, thì KhungXe đó chính là lớp cha. Mà để tạo khung xe thì phải dùng constructor của KhungXe, trong đó sẽ gọi các hàm ráp, hàn, bắt ốc,... Sau khi đã xong phần khung xe, ta gọi constructor của XeMay gọi các hàm gắn bánh, gắn yên xe,.. giúp tạo thành một chiếc xe hoàn chỉnh.
Vậy thứ tự gọi thực sự logic và thực tế đúng không nào?

Nếu bạn muốn gọi constructor có tham số cụ thể của lớp cha theo ý của mình thì sử dụng tự khóa "base" như sau:



Trên là một số kiến thức tổng quát về Lập trình hướng đối tượng (OOP) cho các bạn nào lỡ quên :D.
Minh xin nói luôn một cách tổng quát, trong Java thì hàm dựng của lớp cha cũng sẽ tự động được gọi khi khởi tạo đối tượng của lớp con. Các bạn có thể tham khảo tại đây.



Cuối cùng, mình có một câu hỏi cho các bạn, có cách nào để tạo một đối tượng thuộc lớp con mà không cần gọi hàm dựng (constructor) của lớp cha không? 

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



Chào các bạn,



Đã lâu rồi mình không viết blog, phần vì cũng lười, phần vì vừa phải làm final project tại CoderSchool. Hôm nay vừa internal demo xong, mình ngồi refactor lại code thì thấy như sau


Nhìn vào đống item ở thư mục 'res/layout' kìa!
Horrible, right?

Lang thang search trên mạng cũng thấy nhiều người có vấn đề giống như mình, như article ở StackOverflow.

Thư mục 'res/layout' của bạn quá lớn? khó kiểm soát? khó tìm kiếm? Hãy tưởng tượng trong lúc đang chạy deadline đầu óc rối bời mà tìm hoài không thấy cái 'item_recently_search.xml' nằm ở đâu? (mình cũng vừa bị T.T)

Ok, dài dòng đủ rồi, mình sẽ hướng dẫn các bạn ngay đây.

Bước 1: Đầu tiên các bạn tạo folder tổng "layouts"
Right-click vào thư mục 'res' -> New -> Directory -> gõ "layouts" (nhớ là có 's' nhé, không là bị trùng đấy)



Bước 2: Tạo các Res Folder tương ứng với các category mà bạn muốn làm.
Chọn 'layouts' folder vừa tạo.
Right-click -> New -> Folder -> Res Folder



Đặt tên cho Res Folder theo category mà bạn muốn làm.
Ví dụ ở một chương trình chat bạn sẽ có các category là "home", "profile" và "chat". Ví dụ mình sẽ đặt tên nó là 'chat' nha.

Khi vừa add xong 1 folder, đợi 1 lát để Gradle update cấu trúc chương trình. Sau đó bạn sẽ thấy một folder 'char' màu vàng tương ứng với folder 'res' nhưng lại không năm trong folder 'layouts'.
Thực chất nó vẫn nằm trong 'layouts' tuy nhiên vì minh chỉ mới add một folder duy nhất là 'chat' nên nó chỉ show 'chat' ra thôi.

Tiếp tục bạn tạo thêm một Res Folder mới tên là 'home' thì cấu trúc cây sẽ bắt đầu hiện ra đúng theo những gì bạn mong đợi: 'home' và 'chat' nằm trong 'layouts'.

Tới đây bạn đã chia thành công thư mục ra thành các category riêng biệt rồi.

Bước 3: Thêm folder 'layout' (không có 's') vào từng sub-folder tương ứng với các category cần thiết và sử dụng chúng bình thường như folder 'res/layout' truyền thống. 
Bạn cũng có thể thêm các folder 'menu', 'drawable', 'anim',... vào từng Res Folder nha.

Bước 4: Build thử chương trình. Bạn sẽ thấy trong tag 'android' của file 'app/build.gradle' xuất hiện đoạn lệnh sau


Đoạn lệnh này tương ứng cho khi bạn add 2 category là 2 Res Folder 'home' và 'chat'.
Nếu không tìm thấy các bạn có thể thêm bằng tay vào tag 'android' nha.


Chúc các bạn thành công và quản lý tốt source code của mình. Bởi vì lập trình còn là một quá trình tạo ra sản phẩm cùng với team nên code style là rất quan trọng. Và những thứ như vậy thường không được dạy ở trường.



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


Chào các bạn!

Khi bắt đầu với lập trình Android, chúng ta đều được học rằng KHÔNG THỂ truyền tham chiếu của một đối tượng (object references) tới các Activity hoặc fragment. Để đối mặt với vấn đề khó khăn này chúng ta phải "gói" chúng vào một Intent/Bundle.

Truyền những tham số có kiểu nguyên thủy (primitive data types) như là string, integer, float,... qua Intents thì khá dễ dàng trong Android. Tất cả những gì bạn cần làm là "put" dữ liệu với một key duy nhất làm từ khóa vào Intent và gửi nó đến một Activity bất kỳ.

Nhìn vào API, ta nhận ra rằng có hai cách để truyền Java object qua Intent: một là implements Java class đó từ Percelable interface, hai là implements từ Serializable interface. Là một lập trình viên Java/C# chúng ta chắc hẳn đã biết rõ cơ chế hoạt động của Serializable, vậy tại sao ta lại phải bận tâm với Parcelable?

Để trả lời câu hỏi đó, hay tiếp cận rõ hơn để xem tại sao như vậy nhé!




SERIALIZABLE - BẬC THẦY CỦA SỰ ĐƠN GIẢN

Serializable là một interface chuẩn của Java. Vẻ đẹp của Serializable là việc bạn đơn giản chỉ cần đánh dấu một class Serializable bằng cách implements interface đó lên nó và các class con của nó, sau đó máy ảo Java (Java Virtual Machine) sẽ tự động serialize class theo từng trường hợp khác nhau. Đây là một marker interface, nghĩa là không cần phải cài đặt lại bất cứ method nào của khi implements.


Vấn đề xảy ra với hướng tiếp cận này là Java Reflection được sử dụng, và nó làm tiến trình của phần mềm bị chậm đi. Cơ chế này thường hay tạo rất nhiều đối tượng tạm (temporary object) và khi đó cơ chế dọn rác Garbage Collection của Java sẽ hoạt động và tốn tài nguyên máy tính.


PARCELABLE - ÔNG VUA TỐC ĐỘ

Parcelable là một interface riêng của Android, nơi mà bạn phải tự cài đặt các hàm serialization một cách thủ công mà không được sự hỗ trợ từ JVM. Parcelable được tạo ra cải tiến từ Serializable, nó hiệu quả hơn và khắc phục được một số vấn đề tồn tại ở Java Serializable, đó là lý do tại sao đa phần lập trình viên Android ưu tiên sử dụng Parcelable hơn là Serializable.


Theo những gì mình đọc trên StackOverflow, hay theo các google engineers thì đoạn code trên sẽ chắc chắn thực thi nhanh hơn. Một trong các lý do đó là chúng ta đã cài đặt tường minh các hàm thể hiện quá trình serialization thay vì sử dụng Java Reflection. Khi tối ưu hóa như vậy thì cơ chế dọn rác GC của Java sẽ làm việc ít hơn làm chương trình "nhanh" hơn.

Tuy nhiên, rõ ràng cái gì cũng có cái giá của nó. Với hướng tiếp cận này chúng ta sẽ sinh ra một "đống" code khá phức tạp và làm cho những class này rất khó đọc và fix bug, bảo trì.


KẾT QUẢ KIỂM TRA TỐC ĐỘ

Dĩ nhiên, chúng ta đều muốn biết Parcelable nhanh hơn tới mức nào!

Phương pháp:
- Mô phỏng quá trình truyền object vào activity
- Chạy quá trình đó trong vòng lặp 1000 lần
- Chạy trung bình 10 lần khác nhau để tính dung lượng bộ nhớ, cpu chiếm dụng,..
- Các object được test là HCMUSDeveloper IceTeaVietDeveloper ở trên.
- Test trong nhiều thiết bị android (LG Nexus 4 - Android 4.2.2, Samsung Nexus 10 - Android 4.2.2, HTC Desire Z - Android 2.3.3)

Kết quả:

Thời gian thực thi của bộ test (hình ảnh và dữ liệu theo developerphil.com)

Nexus 10
Serializable: 1.0004ms, Parcelable: 0.0850ms - 10.16x improvement.


Nexus 4
Serializable: 1.8539ms - Parcelable: 0.1824ms - 11.80x improvement.


Desire Z
Serializable: 5.1224ms - Parcelable: 0.2938ms - 17.36x improvement.



TỔNG KẾT

Trong ví dụ trên, Android Parcelable tỏ ra nhanh hơn nhiều so với kỹ thuật Java Serializable. Một trong những lý do chính là do Parcelable hoàn toàn tùy chỉnh code, cho phép lập trình viên convert dữ liệu cần thiết thành Parcel trong khi Serialazation convert đối tượng thành một data stream sử dụng Java Reflection API.

Nếu bạn muốn trở thành một lập trình viên giỏi, hãy bỏ thời gian để cài đặt Parcelable bởi vì nó có thể thực thi nhanh hơn từ 4 - 10 lần và sử dụng ít tài nguyên hơn, khiến GC hoạt động ít hơn.

Tuy nhiên trong nhiều trường hợp, sự "chậm chạp" của Serializable không đáng nhắc tới. Hãy thoải mái sử dụng nó đối với những class nhỏ, nhưng hãy nhớ là nó luôn "ngốn tài nguyên" nên hãy giảm thiểu đến mức đáng kể khi cần những đoạn code đẹp - dễ đọc và bảo trì. Còn nếu bạn đang muốn truyền một List với hàng nghìn object, thì sự "chậm chạp" đó sẽ lên tới con số nhiều giây. Và khi đó chuyển động giao diện cũng như hiệu năng của ứng dụng sẽ trở nên khá tồi tệ và đó cũng là lúc bạn cần dùng đến vị cứu tinh dành riêng cho lập trình viên Android - Parcelable.

________________________________________________________________________

Trên là những chia sẻ của mình về hai hướng tiếp cận cho việc truyền object ref. Cảm ơn các bạn đã theo dõi, chúc các bạn học tốt và hãy để lại bình luận bên dưới nhé! 
Bonus cho các bạn 1 tấm hình từ slide của anh Huynh Q. Thao về những tip trong Android Perfomance, đó cũng là lý do và động lực để mình viết bài này :D



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


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 Bclass 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 Translationhoặ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!



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 GoogleLarry PageSergey 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.



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!


Contact Form

Name

Email *

Message *

Powered by Blogger.
Javascript DisablePlease Enable Javascript To See All Widget