Cả hai commit D và E vẫn còn ở đây, nhưng chúng tôi tạo ra phối commit M mà thay đổi thừa hưởng từ cả hai D và E. Tuy nhiên, điều này tạo ra hình dạng kim cương, mà nhiều người thấy rất khó hiểu. Nếu bạn có hàng chục commit D và E thì bạn có có hàng chục viên kim cương M lúc này bạn sẽ thấy log rối đến mức nào!?
REBASE :
Chúng tôi tạo ra commit R, mà nội dung thực tế file là giống hệt nhau của merge commit M ở trên. Tuy nhiên, chúng ta thoát khỏi commit E, giống như nó không bao giờ tồn tại (denoted bằng dấu chấm – vanishing dòng). Điều này sẽ làm cho commit của bạn nhìn dễ hiểu hơn.
Vì obliteration này, E sẽ có local để developer Ed và nên đã không bao giờ được đẩy đến bất kỳ các kho lưu trữ khác. Lợi thế của rebase là kim cương hình dạng tránh được, và lịch sử vẫn đẹp đường thẳng.
Sau đây là một so sánh log của rebase và merge 1 branch trong một mini project:
A) History dùng rebase nhìn clear và dễ dàng tracking do chính bạn tạo ra một cách hệ thống và logic!
B) History dùng merge nhìn khó hiểu và khi tracking bạn sẽ nói gì ngoài bullshit do chính bạn commit và merge vô tội vạ!
C) Transport plan của git, những chổ dùng rebase sẽ thằng hàng còn merge sẽ chỉa qua lại nhìn chung là ảnh hưởng các branch.
Kết Luận:
Chú ý vào rebase, mọi người sẽ thấy commit của rebase nằm phía trên commit mới nhất của master. Còn ở merge, mọi người sẽ thấy commit của master nằm phía trên commit mới nhất của merge, ngoài ra một commit Merge branch cũng được tạo ra.
Ban sử dụng git rebase nếu như bạn muốn các sự thay đổi thuộc về branch của bạn luôn luôn là mới nhất. Và bạn có thể log một cách có hệ thống dễ nhìn, dễ tracking sao này.
Bạn sử dụng git merge nếu bạn muốn sắp xếp các commit theo mặc định. Bạn không biết về những gì mình làm gì trên branch đó thì dùng merge cho đảm bảo việc tracking sao này có thể tốn nhiều thời gian lần mò.
Một số vấn đề cần lưu ý sau:
Git rebase thì nên dùng trên branch riêng, nó sẽ đẩy history commit của branch lên, history commit sẽ tách biệt hẳn với những commit từ branch khác, rất tiện cho quản lý các branch. Đặt biệt khi các bạn có các branch master / develop / hot-fix / features / release …
Cả rebase và merge sẽ conflict kinh khủng hơn nếu không update code thường xuyên chứ không phải chỉ có rebase như mọi người thường nói đâu nhé. Ví dụ: Nếu như master branch có time line hơn branch của bạn 1 tháng . Lúc đó hãy rebase hay merge branch của bạn và sẽ thấy conflict 2 cái có khác gì nhau!
Git merge là làm cho git commit list dài ra áp dụng cho branch riêng thì không phù hợp vì khó trace log vì nhiều commit dài thòn không phải do bạn tạo ra!?. Nhất là trong 1 dự án dài hơi, việc nhìn lại log của vài tháng trước có thể sẽ là vấn đề trong bầu trời đầy sao chổi với bạn.
Ở phần 1 và phần 2, chúng ta đã điểm qua được phần lớn những đặc điểm của một kỹ sư kiểm thử giỏi. Bài viết đã nhận được nhiều phản hồi tích cực từ cộng đồng kỹ sư kiểm thử phần mềm Việt Nam và đó là động lực để mình hoàn tất loạt bài viết này. Trong phần cuối này, mình sẽ tiếp tục chia sẻ những đặc điểm để giúp chúng ta áp dụng những đặc điểm đã được đề cập trong phần 1 và phần 2 một cách hiệu quả nhất.
Một kỹ sư kiểm thử giỏi hiểu rằng việc tìm bug cũng như hiểu được bản chất của con bug đòi hỏi sự chuyên tâm nhất định. Một kỹ sư kiểm thử giỏi không bỏ sót một con bug nào tìm thấy dọc đường đi. Tuy nhiên họ sẽ không đào sâu tìm hiểu những con bug đó trước khi con bug chính được làm rõ.
Để không bị chệch hướng, bạn cần phải có một kế hoạch và bám sát vào nó. Trước khi tiến hành một lượt kiểm thử, hãy dành thời gian để lên kế hoạch trong đó xác định được bạn sẽ phân bổ thời gian kiểm thử như thế nào. Và khi tiến hành kế hoạch đó, hãy ghi nhận lại những điều thú vị bạn quan sát được trên đường đi nhưng vẫn chuyên tâm vào kế hoạch đã vạch ra. Khi bạn đã hoàn tất việc ghi nhận lại những vấn đề bạn gặp được trên đường đi, hãy quay lại và bắt đầu lần lượt tìm hiểu từng vấn đề đó. Khi tìm hiểu những vấn đề đó, tiếp tục lặp lại quá trình: ghi nhận những điều mới nhưng đừng xa rời mục tiêu.
Tác giả đã đưa ra lời khuyên nhưng những kỹ sư kiểm thử giỏi không áp dụng nó một cách cứng nhắc – nghĩa là chỉ ghi nhận và rồi đi tiếp. Đôi khi cũng có những điều quan trọng bạn gặp trên đường đi, hãy tập trung đào sâu tìm hiểu nó ngay lập tức thay vì chỉ ghi nhận lại.
[TH]:Trong quá trình nghiên cứu một con bug hay một vấn đề nào đó, chúng ta rất dễ bị “chèo kéo”, “mời gọi” của những vấn đề mới phát sinh và làm chúng ta lạc lối. Một sự lạc lối rất đáng yêu. Tôi lạc lối vì tôi có nhu cầu đào sâu tìm hiểu vấn đề, tôi chấp nhận “đào sâu để tìm vàng”, tôi sợ rằng nếu không đào sâu tôi sẽ bỏ sót những vấn đề tưởng chừng như nhỏ nhưng có thể gây ảnh hưởng nghiêm trọng đến khách hàng. Tuy nhiên hãy biết cân bằng và luôn tự hỏi “có đáng để làm công việc này không?”
14. Nhờ giúp đỡ
Những kỹ sư kiểm thử giỏi luôn sẵn sàng đối mặt với thử thách, “đập đầu vào tường” (khuyến cáo không nên hiểu và làm theo nghĩa đen) để phá vỡ nó từ từ. Vấn đề là có một số bức tường dày hơn một số khác. Những kỹ sư kiểm thử giỏi luôn biết khi nào cần sự giúp đỡ từ ai và vào khi nào.
Điều này đòi hỏi sự cân bằng. Bạn muốn tự mình tìm hiểu vấn đề nhưng cũng không muốn lãng phí thời gian vô ích. Hãy nói chuyện với quản lí của bạn để định ra đâu là giới hạn thời gian cho việc bạn tự nghiên cứu. Hết thời gian đó, bạn sẽ nhờ giúp đỡ.
Mặc dù bạn biết rằng bạn cần giúp đỡ nhưng cũng khó để có thể thừa nhận là bạn cần sự giúp đỡ. Để làm được việc này, bạn cần nhận thức được rằng việc nhờ giúp đỡ sẽ không làm giảm đi chất lượng của công việc cũng như việc kiểm thử của bạn. Mọi người sẽ hiểu được rằng nhờ giúp đỡ là một việc đúng đắn và nên làm và sẽ càng tôn trọng bạn hơn nếu bạn thực lòng muốn làm điều đó. Một kỹ sư kiểm thử giỏi hiểu rằng chẳng việc gì phải hổ thẹn khi nhờ ai đó giúp đỡ. Nếu bạn không thường xuyên nhờ ai đó giúp đỡ, có khi đó lại là vấn đề.
15. Nói cùng ngôn ngữ với kỹ sư lập trình
Điều này cũng tương tự như bạn ghé thăm một đất nước nào đó. Bạn được khuyến khích làm quen với ngôn ngữ cũng như phong tục tập quán của nước đó để ít nhất bạn thể bắt taxi về khách sạn hay hỏi thăm đường. Tương tự, kỹ sư kiểm thử phải tập làm quen với ngôn ngữ và thói quen của kỹ sư lập trình.
Nếu kỹ sư lập trình trong nhóm sử dụng UML, bạn phải tìm hiểu nó ít nhất là ở mức căn bản để không khiến cho họ phì cười khi bạn vẽ một biểu đồ UML. Hãy học cách viết một đoạn code ít nhất là ở mức của một sinh viên năm nhất. Hãy trò chuyện với kỹ sư lập trình để có cái nhìn tổng quát về những thành phần của ứng dụng. Điều quan trọng nhất là bạn có thể tự tin đặt câu hỏi để không cảm thấy ngớ ngẩn cũng như học cách để học.
Nếu bạn làm tốt khâu này, thì một ngày nào đó kỹ sư lập trình sẽ đến và nói với bạn rằng “Bạn tìm được bug. Bạn chỉ ra được bug chính xác là do đâu. Nếu bạn có thể sửa được bug nữa thì chẳng còn gì cho chúng tôi làm nữa”.
[TH] Vâng. Tác giả rất hài hước. Dĩ nhiên, chúng ta luôn biết rằng sẽ không ai có thể giỏi tất cả các khâu được và trên hết chúng ta hiểu được sức mạnh của tinh thần làm việc nhóm. Tuy nhiên việc đó cũng không thể ngăn cản chúng ta tự hoàn thiện bản thân và bổ sung thêm những kỹ năng mới. Bạn chuyên kiểm thử thủ công thì việc tìm hiểu và học một ngôn ngữ lập trình, một công cụ kiểm thử tự động, hay học cách viết các câu truy vấn cơ sơ dữ liệu v.v là không bao giờ thừa. Tương tự, nếu bạn là một kỹ sư kiểm thử tự động thì việc tìm hiểu thêm về những kỹ thuật kiểm thử thủ công, cách thức quản lý bug, trường hợp kiểm thử cũng đều sẽ rất hữu ích.
16. Đầu tư
Một kỹ sư kiểm thử giỏi biết được rằng cách duy nhất để họ tiếp tục là một kỹ sư kiểm thử giỏi là không bao giờ ngừng học hỏi. Nếu bạn được công ty hỗ trợ cho việc học là rất tốt, nếu không thì hãy tự trang bị bổ sung kiến thức cho chính mình.
Để tìm thời gian cho việc đào tạo, hãy đánh giá lại tất cả những công việc bạn đang làm và hãy cân nhắc xem việc nào không quan trọng và có thể bỏ đi. Ban lãnh đạo công ty thường cân nhắc việc được và mất khi hỗ trợ việc đào tạo cho nhân viên. Do đó, để có được sự chấp thuận của họ, việc bạn cần làm là chứng minh việc hỗ trợ đào tạo cho nhân viên sẽ được nhiều hơn mất.
Có nhiều cách khác nhau để đào tạo. Chẳng hạn để luyện tập kỹ năng trình bày, bạn có thể xây dựng một buổi trình bày về một kỹ thuật lập trình/kỹ thuật kiểm thử hữu ích cho đồng nghiệp. Kết quả cuối cùng là cả bạn và đồng nghiệp đều có được kỹ năng hoặc kiến thức mình còn thiếu. Đầu tư vào chính bản thân là cách tốt nhất để cải thiện những đặc điểm đề cập trong bài viết này.
[TH] Hãy không ngừng học hỏi và đầu tư cho việc nâng cao kiến thức chuyên ngành. Tùy nhu cầu và định hướng phát triển nghề nghiệp, các bạn sẽ chọn cách đầu tư theo cách riêng mình…nhưng hãy đảm bảo rằng các bạn có đầu tư.
17. Nhìn thấy bug
Một kỹ sư kiểm thử giỏi biết rằng một ứng dụng dường như không có bug là một ứng dụng có thể có đầy bug mà mình vẫn chưa tìm ra được. Một kỹ sư kiểm thử giỏi luôn tâm niệm rằng mỗi con bug mà khách hàng tìm được là một dấu hiệu cho thấy họ đã để sót rất rất nhiều bug.
Chuyện này sẽ trở nên tự nhiên hơn khi chúng ta hiểu rằng một ứng dụng tưởng chừng như đơn giản nhưng lại không đơn giản như mình nghĩ và rằng không có ứng dụng nào có thể chạy đúng hết tất cả các trường hợp được.
Hãy nhìn vào những khu vực mà ứng dụng hay bị lỗi. Hãy tìm hiểu xem người dùng cuối sử dụng sản phẩm như thế nào vì người dùng thỉnh thoảng có những thói quen sử dụng sản phẩm mà bạn không thể ngờ tới. Cho dù bạn có tìm được bug hay không thì bug vẫn còn đâu đó nhưng những người kỹ sư kiểm thử giỏi luôn muốn tìm được chúng.
[TH] Nếu bạn không tìm thấy bug thì hãy thử những gợi ý sau đây: bạn đã xem qua tài liệu mới của ứng dụng chưa (thiết kế, đặc tả, help, hướng dẫn sử dụng, v.v), xem lại những email cũ xem còn vấn đề nào chưa thảo luận xong và bị “bỏ quên” không, lật lại cuốn sổ tay xem có thông tin gì thú vị mà bạn đã ghi chú không, xem lại những con bug và những thảo luận của chúng trên hệ thống quản lý bug… Sau khi lục lọi tìm tòi đủ thứ, bạn có thể tìm được bug nhưng cũng có thể không. Tuy nhiên, điều quan trọng là bạn sẽ hiểu thêm về hiện trạng của sản phẩm cũng như sẽ đưa ra được những câu hỏi hay vấn đề thú vị để đem ra thảo luận với khách hàng, với kỹ sư lập trình, với giám đốc sản phẩm, giám đốc dự án.
18-19-20. Trung thực – Chính trực – Dũng cảm
Đây là 3 đặc điểm nền tảng cho những đặc điểm khác. Như Jerry Weinberg đã từng nói “Nếu như không có sự chính trực và lòng dũng cảm để bảo vệ nó thì bạn sẽ bị cán dẹp trên đại lộ của sự phát triển và mỗi ngày trôi qua bạn sẽ ngày càng dẹp lại …dẹp lại..”. Sự trung thực, chính trực và lòng dũng cảm là nền móng của một kỹ sư kiểm thử giỏi.
Nếu bạn không trung thực về tình trạng hiện tại của ứng dụng thì hoặc là ứng dụng sẽ không bao giờ được đưa ra thị trường (nếu như bạn cố tình phóng đại về tình trạng tệ hại của ứng dụng) hoặc là bạn sẽ bỏ sót một “rừng bug” cho khách hàng (nếu như bạn cố tình nói giảm về tình trạng tệ hại). Sự chính trực có mối quan hệ mật thiết với danh tiếng của bạn; cải thiện điều này sẽ cải thiện điều kia. Cuối cùng, bạn sẽ thể hiện lòng dũng cảm dễ dàng hơn nếu như bạn thật lòng tin rằng là bạn đã làm đúng. Những đặc điểm khác sẽ giúp bạn có thêm lòng dũng cảm để đứng lên tranh đấu khi cần thiết. Sự trung thực, chính trực và lòng dũng cảm là chất xúc tác giúp bạn đạt được những đặc điểm khác nhanh chóng hơn.
[TH] Một trong những nhiệm vụ quan trọng của một người kỹ sư kiểm thử là cung cấp thông tin một cách chính xác và kịp thời đến cho khách hàng. Nếu thông tin cung cấp bị sai lệch thì công việc kiểm thử coi như là vô ích. Nếu bạn thấy thời gian kiểm thử cho sản phẩm quá ít hãy cho khách hàng biết. Nếu bạn cảm thấy không tự tin khi đưa sản phẩm ra thị trường, hãy chia sẻ với khách hàng. Nếu bạn thấy bạn không hoàn tất việc được giao, hãy thông báo khách hàng. Nếu bạn cảm thấy không khỏe và không thể làm công việc với kết quả tốt nhất, hãy chia sẻ với khách hàng…Hãy luôn trung thực với những việc mà bạn tin rằng sẽ ảnh hưởng đến chất lượng công việc, sản phẩm và dự án.
Lời kết
Mình vừa đi qua những đặc điểm cuối cùng trong loạt bài về 20 đặc điểm của một kỹ sư kiểm thử giỏi. Bạn sẽ phì cười khi nghĩ rằng làm gì có ai có đủ 20 đặc điểm đó và rằng tất cả chỉ là “sách vở” thì bạn biết rằng ít nhất có một người chia sẻ quan điểm với bạn…người đó là mình. Tuy nhiên, đối với mình việc có đủ 20 đặc điểm đó (hoặc đặc điểm khác hoặc nhiều hơn hoặc ít hơn) không quan trọng bằng việc luôn tìm kiếm những đặc điểm của riêng mình để trở thành một kỹ sử kiểm thử giỏi và luôn cố gắng đạt được nó.
Ngoài ra, nếu ai đó đã đọc đến phần thứ 3 này (dĩ nhiên là cả phần 1 và phần 2 nữa) thì mình tin là bạn đó rất có thể là một kỹ sư kiểm thử giỏi vì bạn đó đã chứng tỏ được sự kiên nhẫn – một trong những đặc điểm làm nên một kỹ sư kiểm thử giỏi – theo nhận định của mình.
Bài viết được sự cho phép của tác giả To Thi Van Anh
Tranh thủ mấy ngày Tết, mặc dù tình hình ăn uống, đi chơi cứ phải gọi là tưng bừng nhưng cũng không thể lơ là việc học tập được. Hehe. Thế nên là theo như kế hoạch mình sẽ tung ra một ‘hit’ mới rất không liên quan đến ngày Tết, nhưng mà lại vô cùng liên quan đến công việc mà mình đã làm được gần hai tuần trước khi nghỉ tết và dự là sau Tết còn làm nhiều nhiều và dài dài.
Nghe đã thấy hoang mang, và tóm lại thì nó là gì, không lan man nữa đó chính là hoạt động review test case như tiêu đề bài viết đã gợi ý đó!
Tất cả chúng ta (trong lĩnh vực phần mềm mềm nói riêng) đều biết được sự cần thiết của các test case, một trong những yếu tố đánh giá hiệu quả của hoạt động kiểm thử. Các test case đóng một vai trò quan trọng trong quá trình đảm bảo chất lượng đầu ra của sản phẩm phần mềm, do đó việc cần phải đảm bảo tính hiệu quả, sự chính xác và tối ưu của các test case cũng là một việc cần được ưu tiên. Và hoạt động reivew ở đây chính là để đảm bảo các yếu tố đó!
Test case sau khi được viết ra xong, đúng quy trình thì sẽ được chính người viết đó tự kiểm tra lại một lượt (self-review) trước khi chuyển cho một thành viên khác trong nhóm kiểm thử, kiểm tra chéo những test case đó (peer-review), sau khi hoàn tất công đoạn này thì test case mới được đưa vào giai đoạn thực thi.
Nắm bắt được tư tưởng và ứng dụng được một số yếu tố dưới đây mình nghĩ là nó sẽ giúp ích được kha khá cho hoạt động self-review và peer-review của chúng ta được tốt hơn đấy (vì mình cũng đang áp dụng rồi mà, ah thì tất nhiên là cũng có chọn lọc cho phù hợp với hoàn cảnh thực tế dự án của mình nhé! kaka), các bạn cùng tham khảo nha!
– Giá trị sử dụng
Việc đầu tiên cần kiểm tra đó là giá trị sử dụng của test case đó, với yêu cầu đó thì test case này có cần thiết không? Test case này đã có được cover bởi một test case nào khác hay chưa? Trong đó ta cần phải xác định được những giá trị mà test case mang lại, việc xác định này sẽ dựa theo mô tả hay chức năng của hệ thống mà test case này được viết ra cho nó.
– Mục tiêu của test case
Đọc lướt qua mô tả, nội dung test case để xác định xem là bạn có hiểu được mục đích của test case này là gì hay không? Lưu ý là mỗi một test case chỉ để kiểm tra một vấn đề cụ thể nào đó thôi nhé. Nếu trong một test case mà nó có nhiều hơn một mục đích cần kiểm tra khi thực thi thì lúc này ta cần phải xem xét tách nhỏ case đó ra.
– Điều kiện trước
Ở đây ta sẽ xác định xem là cái test case này có yêu cầu ta phải chuẩn bị, thực hiện một số setup đặc biệt nào đó trước khi thực thi test case hay không. Thứ tự thực hiện các yêu cầu ấy, và việc review là phải xem xem trong test case đã có lưu ý rõ ràng và đầy đủ những yêu cầu đó hay chưa?
– Các bước thực hiện
Các bước thực hiện được đưa ra trong test case có dễ dàng làm theo khi thực thi test case không? Với một người mới liệu có thể nắm được mục đích và làm theo được thông qua các bước này hay không? Nếu không, thì có thể là người viết chỉ đang suy đoán các bước là như vậy, lúc này cần thì phải chỉnh sửa hoặc là phải thêm một số bước cụ thể hơn để có thể dễ dàng làm theo được.
– Inputs
Các test case cần cung cấp rõ ràng và cụ thể những giá trị đầu vào nào cần cho test case đó. Ta cũng cần phải lưu ý rằng, với những giá trị cụ thể đó ta cũng sẽ có những kết quả cụ thể tương ứng. Và những giá trị này có thể là nguyên nhân mà test case sẽ trả về các kết quả khác nhau sau mỗi lần thực thi.
– Ngôn ngữ
Yếu tố quan trọng nữa là việc sử dụng từ ngữ cần phải đơn giản và rõ ràng. Từ đó, không phải chú thích hay giải thích gì khi mà test case được đưa vào thực thi – tuy nhiên có thể sẽ có những ngoại lệ (cái này thì không tính nhé :v). Rồi liên quan đến việc diễn đạt, ngữ pháp, hay chính tả… (Lỗi dễ mắc khi mà chúng ta viết test case bằng tiếng Anh, hehe)
– Kết quả mong muốn
Một test case kiểu mẫu cần phải mô tả một cách rõ ràng kết quả mong muốn hay phản hồi của hệ thống khi thực thi test case đó. Từ đây, việc đánh giá test case đó pass hay fail có thể xác định một cách dễ dàng và công bằng.
– Clean-up
Thao tác này đối với một số test case đặc thù, trong khi thực hiện những bước làm thay đổi trạng thái hay cài đặt của hệ thống, nó có thể làm cho các bước sau đó và test case chạy không chuẩn xác nữa. Do đó, với những trường hợp này thì ta cần phải có thêm một bước để khôi phục lại những thay đổi đó.
– Sự phụ thuộc
Ta sẽ xác định test case này có phụ thuộc vào các test case khác hay không? Những test case đó có yêu cầu cần được thực thi trước hoặc sau test case này hay không? Nếu có thì cần phải lưu ý rõ ràng trong các test case đó. Lý tưởng ở đây là mỗi test case cần phải độc lập với các test case khác. Nhưng trong trường hợp không thể tránh được thì điều cần làm đó là phải note lại một cách vô cùng cẩn thận và rõ ràng các thông tin đó nhé.
– Tài liệu
Test case cần có thông tin đầy đủ về tác giả – người viết ra test case đó, độ ưu tiên của test case (nếu có), requirement của test case, những thông tin này sẽ hữu ích trong trường hợp mà cần thêm thông tin hoặc kiểm tra độ bao phủ của test case.
Về cơ bản là chúng ta sẽ nên tập trung chủ yếu vào các yếu tố trên, ngoài ra tùy theo đặc thù của hệ thống, nền tảng ta sẽ cần xem xét thêm những yếu tố khác nữa nhé, như là các thiết bị test nào cần được chuẩn bị, môi trường test là gì… Ta cũng sẽ cần kiểm tra thêm những cái đó có được mô tả đầy đủ và chính xác đối với từng case cụ thể hay chưa.
Hi vọng rằng, với những gợi ý từ bài viết sẽ mang lại những lợi ích nào đó cho tất cả những bạn nào đã đọc bài viết này.
Bài viết được sự cho phép của blogchiasekienthuc.com
Wi-Fi 6 (hay còn gọi là WiFi thế hệ thứ 6) là một khái niệm đã quá quen thuộc với những người yêu thích công nghệ rồi. Vậy bạn đã hiểu gì về Wi-Fi 6 rồi?
Nếu như bạn đang tìm kiếm một bài viết giải thích ngắn gọn và dễ hiểu nhất về Wi-Fi 6 thì mời các bạn tham khảo bài viết bên dưới đây.
Trong bài viết này mình sẽ tổng hợp lại những nét đặc trưng và những ưu điểm nổi bật của Wi-Fi 6, để các bạn có cái nhìn tổng quát nhất.
I. Lịch sử phát triển WiFi?
Okay, trước tiên thì mình sẽ nói qua một chút về lịch sử ra đời các phiên bản Wi-Fi trước đã:
WiFi thế hệ 1: Được phát triển vào năm 1997 với chuẩn 802.11
WiFi thế hệ 2: Được ra đời 2 năm sau đó, tức là vào năm 1999 với chuẩn 802.11b
WiFi thế hệ thứ 3: Được ra đời vào năm 2003 với chuẩn 802.11 a/g (chuẩn a và chuẩn g ra đời).
WiFi thế hệ thứ 4: Được ra đời vào năm 2007 với chuẩn 802.11n (chuẩn n ra đời).
WiFi 4 được sinh ra để giải quyết vấn đề về tốc độ (HT – Hight Throughput hay còn gọi là tốc độ cao). Chuẩn n này có thể đạt tốc độ tối đa là 600 Mbps
WiFi thế hệ thứ 5: Được ra đời vào năm 2012 với chuẩn 802.11ac (chuẩn ac ra đời). Và tiếp tục, vào năm 2015 một phiên bản cải tiến của chuẩn ac ra đời ( 802.11ac Wave 2).
Vâng, và chuẩn ac được ra đời cũng là để cải tiến tốc độ (VHT – Very Hight Throughput hay còn gọi là tố độ rất cao). Và chuẩn ac này có thể đạt tốc độ tối đa là 6Gbps
WiFi thế hệ thứ 6: Đây là chuẩn Wi-Fi mới nhất hiện nay (chuẩn 802.11ax). Tốc độ của WiFi 6 lên đến 10 Gbps, và nó có thể đạt được 12 Gbps với điều kiện ở trong phạm vi ngắn và với tần số sóng không dây cao nhất.
Có thể nói, với người dùng phổ thông thì ít ai mà có thể sử dụng được tối đa của tốc độ WiFi 5, vậy thì WiFi 6 được phát triển ra là với mục đích gì?
Vâng, chuẩn ax được phát triển ngoài mục đích là để nâng cao tốc độ hơn nữa thì nó còn để giải quyết vấn đề về sô lượng user (người dùng) và giảm độ nhiễm, chồng chéo sóng. Nói một cách ngắn gọn thì WiFi 6 được phát triển với mục đích mang lại HIỆU QUẢ CAO TRONG VIỆC TRUYỀN DỮ LIỆU (HE – Hight Efficiency)
=> Như vậy thì các bạn có thể thấy, sự khác nhau trong việc đặt tên cho các thế hệ Wi-Fi là ở phần tên phía sau, như là b, a/g, n, ac, ax…
Nhưng sẽ thật khó nhớ khi chúng ta cứ phải gọi chuẩn ac hay ax.. đúng không. Mà để đơn giản hóa vấn đề, thì những cái tên như Wi-Fi 5, Wi-Fi 6 nên được sử dụng.
II. Những ưu điểm nổi bật của WiFi 6?
#1. Hoạt động trên cả 2 băng tần 2.4GHz và 5GHz
Như các bạn đã biết, Router băng tần kép hiện nay thường hoạt động trên phổ tần là 2.4GHz và 5GHz, và các phổ này phân bổ theo bộ kênh với độ rộng 20MHz.
Wi-Fi 6 ra đời hoạt động trên cả 2 băng tần 2.4GHz và 5GHz. Ngoài ra thì nó cũng tương thích hoàn toàn với các thiết bị chỉ hỗ trợ một băng tần 2.4GHz
Điều này là vô cùng cần thiết, bởi vì đa số các thiết bị hiện nay đều chạy trên băng tần 2.4 GHz. Nói tóm lại là Wi-Fi 6 có khả năng tương thích tốt với các thiết bị cũ.
#2. Sử dụng OFDMA
Nếu như Wi-Fi 3, 4 hay là Wi-Fi 5 sử dụng OFDM thì Wi-Fi 6 lại sử dụng OFDMA.
Vậy OFDM khác gì so với OFDMA? Vâng, với OFDM khi bạn cấu hình các kênh như 20MHz, 40 MHz… thì lúc này OFDM sẽ sử dụng toàn bộ 20MHz, 40 MHz… đó cho 1 user, user này xong thì sẽ đến lượt các user khác.
Còn với OFDMA thì khác hoàn toàn, với 20MHz, 40 MHz… đó thì nó sẽ chia sẻ ra cho nhiều người cùng một lúc trên băng thông 20MHz, 40 MHz… đó.
Các bạn có thể hình dung đơn giản là OFDM được ví như là con đường chỉ có 1 làn đường, còn OFDMA là một con đường nhiều làn vậy.
Giải thích theo góc độ kỹ thuật thì:
Wi-Fi 6 sẽ thực hiện phân bổ các kênh 20 MHz này ra thành 256 kênh nhỏ hơn (một con số lớn hơn rất nhiều so với 64 kênh trước kia).
=> Điều này không chỉ giúp cho Wi-Fi 6 gia tăng về mặt số lượng kênh đơn thuần, mà còn sửa đổi các kết nối dữ liệu trong những kênh được tăng thêm.
Từ đó mà Wi-Fi 6 có thể chạy được nhiều luồng cùng một lúc hơn, và nó hoạt động tốt hơn, ổn định hơn khi có nhiều người truy cập.
__
Ngoài ra, ở trong phiên bản trước (tức là Wi-Fi thế hệ 5) thì chỉ có 256 Quadrature Amplitude Modulation (QAM), nhưng trên Wi-Fi 6 thì đã được nâng cấp lên tới 1024 QAM.
=> Điều này giúp cho Wi-Fi 6 có thể phát sóng 8 luồng cùng một lúc, hiểu đơn giản thì nó có thể xử lý lưu lượng truy cập của 8 người cùng lúc, ở cùng một tốc độ mà không hề bị giảm => giải quyết được vấn đề nghẽn mạng.
#3. Resource Unit
Nó sẽ thực hiện chia nhỏ tài nguyên băng thông ra thành những Resource Unit, và nó sẽ phân phát các Resource Unit này cho các user ở phía bên dưới chia sẻ nhau => Cho phép nhiều thiết bị có thể truyền/nhận dữ liệu cùng lúc.
#4. BSS Color
Nó sẽ đánh dấu các gói tin WiFi, mục đích là để nhận biết những gói tin nào cùng một SSID, cùng một hãng WiFi thì nó sẽ được đánh dấu cùng một màu. Còn ngược lại, nếu khác SSID thì nó sẽ đánh dấu khác màu.
=> Như vậy thì nếu chẳng may có 2 Access Point có đặt cạnh nhau, và phát cùng một kênh đi chăng nữa thì nó cũng sẽ không bị nhiễu sóng.
#5. Target Wake Time (TWT)
Một tính năng giúp giảm xung đột & Tiết kiệm năng lượng hơn. Vâng, tiết kiệm điện là tiết kiệm cho các thiết bị kết nối với mạng Wi-Fi 6 nhé các bạn, ví dụ như smartphone, máy tính….
III. Một số thuật ngữ mà bạn có thể gặp khi dùng Wi-Fi 6
Bên dưới là một số thuật ngữ mà có thể bạn sẽ gặp khi tìm mua một bộ phát WiFi 6 nào đó, mình sẽ tiếp tục update tại đây nên nếu quan tâm bạn có thể bookmark lại bài viết này để theo dõi nhé.
#1. WiFi Mesh là gì?
Vâng, các bạn có thể hiểu đơn giản WiFi Mesh là một hệ thống bao gồm nhiều thiết bị (Mesh) kết nối không dây lại với nhau, để phủ sóng Wi-Fi trong một không không gian rộng lớn, như là: chung cư, quán xá, văn phòng, hoặc biệt thự, căn nhà nhiều tầng….
Bạn không cần phải chạy dây mạng lằng ngoằng tới các thiết bị như những modem truyền thống nữa, và điều này thì đương nhiên là sẽ mang lại tính thẩm mỹ cao hơn cho căn nhà.
WiFi mesh giúp cho toàn bộ các thiết bị sử dụng chung một tên WiFi duy nhất, mà từ đó người dùng cũng không cần phải trực chờ đổi sang mạng Wi-Fi khác khi di chuyển giữa các tầng.
Qua đó thì cũng giúp cho các thiết bị thông minh (smart) trong gia đình như: camera, robot hút bụi … dễ dàng kết nối và cài đặt hơn.
Nhưng bạn đừng nghĩ WiFi Mesh là một bộ kích sóng nhé, bởi bộ kích sóng chỉ đơn giản là giúp tăng cường độ tín hiệu của Router chính, còn WiFi Mesh sẽ tạo ra một mạng WiFi hoàn toàn độc lập.
#2. AIoT là gì?
AIoT là sự kết hợp của AI (Trí Tuệ Nhân Tạo) và IoT (Internet of Things – Vạn vật kết nối) nhằm mục đích trao quyền cho cho các thiết bị được kết nối với trí thông minh của riêng chúng.
Vâng, điều này cho phép chúng học hành vi của con người và hành động theo hành vi và sở thích của người dùng mà không cần tương tác, nhắc nhở hoặc lập trình từ con người .
IV. Lời Kết
Okay, như vậy là mình đã giúp bạn hiểu rõ hơn về Wi-Fi 6 rồi nhé, về cơ bản thì bạn chỉ cần hiểu như vậy là đủ.
Và tất nhiên, ngoài những lý thuyết bên trên ra, nếu bạn còn biết thêm những kiến thức hay ho khác về Wi-Fi 6 thì đừng quên chia sẻ lại cho anh em bằng cách để lại comment phía bên dưới bài viết này nhé!
Nhưng có lẽ bạn chưa biết, hệ điều hành “Linux nói chung” hiện cũng đã chiếm một tỷ lệ khá lớn rồi. Phần đa những người sử dụng điều hành này là các lập trình viên, những người yêu thích mã nguồn mở và những người làm việc với hệ thống.
Và ở trong bài viết này, mình sẽ cùng các bạn điểm tên những phiên bản phân phối phổ biến nhất của Linux, mà nếu bạn yêu thích Linux thì có thể trải nghiệm thử nhé.
I. Nhân Linux là gì?
Trước khi tìm hiểu về các phiên bản phân phối của Linux, chúng ta cần phải nắm được một khái niệm đó là “nhân linux – Kernel” trước đã.
Đây là thành phần quan trọng nhất của hệ điều hành Linux nói chung và các phiên bản phân phối nói riêng.
Chức năng của nó là cho phép hệ thống giao tiếp, quản lý và điều khiển các bộ phận phần cứng của máy tính.
II. Các phiên bản phân phối của Linux
Hiện có hàng trăm phiên bản phân phối khác nhau của Linux. Các bạn có thể xem chi tiết tại đây: https://distrowatch.com/
Nhưng trong số đó, chỉ có một vài cái tên nối tiếng và phổ biến như: Ubuntu, Debian, Fedora, Kali, Red Hat, PopOS!…
Việc có quá nhiều phiên bản như vậy phần nào cũng khiến cho người dùng (đặc biệt là với những bạn đang tìm hiểu) thấy rất khó trong việc lựa chọn phiên bản phù hợp.
Chính vì vậy mà tùy mục đích, tùy cấu hình máy tính mà các bạn có thể chọn ra cho mình một phiên bản phù hợp để cài đặt thì sẽ đem lại hiệu quả cao nhất.
Okay ! Bây giờ thì mình sẽ cùng các bạn điểm mặt một vài những phiên bản phổ biến nhé.
#1. Red Hat Enterprise Linux
Được phát triển bởi Red Hat và mục tiêu là hướng tới thị trường thương mại. Red Hat Enterprise Linux được phát hành cho các phiên bản máy chủ x86, x86-64, Itanium, PowerPC và IBM System z.
Red Hat Enterprise Linux có hai phiên bản là RHEL và RHELAP.
RHEL(Red Hat Enterprise Linux) là phiên bản hỗ trợ 2 CPU.
RHELAS(Red Hat Linux Advanced Server) là phiên hỗ trợ CPU không giới hạn
Red Hat Enterprise Linux chủ yếu được sử dụng bởi các tổ chức có yêu cầu tính bảo mật cao (các cơ quan, tổ chức nhà nước chẳng hạn).
Trình quản lý gói RPM được sử dụng trên Red Hat và các bản phân phối dựa trên nó (Red Hat Package Management).
#2. CentOS
CentOS là viết tắt của Community Enterprise Operating System và là một bản phân phối miễn phí của Red Hat Enterprise Linux (RHEL).
Trên thực tế thì có rất nhiều doanh nghiệp sử dụng CentOS là hệ điều hành cho các Server, đơn giản vì nó là một bản phân phối của RHEL nên đảm bảo về mức độ bảo mật.
Hai nữa là CentOS lại miễn phí, vậy nên các doanh nghiệp sẽ tiết kiệm được một khoản tiền khá lớn khi không phải trả tiền mua và duy trì dịch vụ.
Trước đây Fedora được gọi là Fedora Core và cũng là một bản phân phối Linux dựa trên RPM Package Manager. Fedora được cộng đồng Fedora Project phát triển và được bảo trợ bởi Red Hat.
Do được tài trợ bởi Red Hat, Fedora được dùng để kiểm tra các tính năng mới của Red Hat phát triển trước khi tính năng đó được thương mại hóa với RHEL.
Debian Linux là phiên bản phân phối miễn phí của Linux, nó được phát triển bởi cộng đồng các lập trình viên và người dùng (phát triển dựa trên những phản hồi từ người dùng).
Do Debian miễn phí nên mọi người có thể tham khảo Souce Code của dự án và sử dụng nó với các mục đích hợp pháp.
Với hơn 23000 ứng dụng và công cụ cài đặt có sẵn thông qua dpkg thì chúng ta sẽ có rất nhiều lựa chọn khi cài đặt phần mềm, công cụ trên Debian.
Ubuntu có lẽ là cái tên quen thuộc trong giới lập trình viên, nhiều người còn ví von “Ubuntu giống như Windows của Linux” – kiểu nó phổ biến như cách Windows phổ biến với người dùng vậy.
Ubuntu cũng miễn phí giống như Debian với khoảng 6 tháng sẽ được cập nhật một lần. Hiện nay, phiên bản mới nhất của Ubuntu là 20.04 LTS (Long-term Support).
Ngoài ra thì Ubuntu cũng có hỗ trợ các phiên bản thương mại dành cho các tổ chức. Ubuntu được sử dụng với với nhiều mục đích khác nhau gồm cả desktop, server, IoT và Cloud..
Ubuntu được đánh giá là một phân phối Linux dễ sử dụng, hiệu năng tương đối tốt và mang lại trải nghiệm tốt cho người dùng.
Gentoo Linux là một bản phân phối Linux được đặt tên theo loài chim cánh cụt Gentoo.
Gentoo chủ yếu được thiết kế cho các thiết bị xách tay với mục tiêu dễ bảo dưỡng, linh hoạt và có khả năng tùy biến theo máy tính của người sử dụng.
Một ưu điểm của Gentoo đó là hệ thống quản lý gói của Gentoo được xây dựng như một plug-in rất linh hoạt, dễ bảo trì và độ tương thích phần cứng là gần như không giới hạn.
III. Lời Kết
Okay, vậy là trong bài viết này mình đã cùng các bạn tìm hiểu về các phiên bản phân phối phổ biến của Linux rồi ha.
Trên thực tế thì việc lựa chọn dựa trên nhiều yêu cầu khác nhau như mình đã trình bày bên trên. Nhưng nếu bạn mới bắt đầu tiếp xúc với Linux thì mình nghĩ Ubuntu là một lựa chọn tốt, vì nó phổ biến và bạn sẽ dễ dàng tìm được hướng dẫn khi cần.
NOTE: Trong các Distro trên, nếu dùng ở môi trường Desktop thì các bạn nên chọn Ubuntu, còn nếu dùng làm Server có thể chọn CentOS, Ubuntu Server.
Ở phần 1 mình đã giới thiệu đến các bạn một số đặc điểm cơ bản của một kỹ sư kiểm thử giỏi như “sự cân bằng”, “sự tò mò”, “sự thực hành thường xuyên”, “luôn phấn khích khi tìm được bug”, “niềm đam mê đối với khách hàng”. Ở phần 2, mình sẽ giới thiệu tiếp những đặc điểm mà với những đặc điểm này sẽ bổ trợ cho những đặc điểm ở phần 1.
Những kỹ sư kiểm thử giỏi thường bắt đầu công việc kiểm thử bằng việc nghĩ ra những phần nào có thể kiểm thử được trên sản phẩm của mình. Những kỹ sư kiểm thử này bắt đầu bằng việc phân tích kiến trúc, thiết kế, hay những tính năng của sản phẩm tuy nhiên họ cũng nhận thức được rằng đó chỉ là một trong nhiều yếu tố có thể ảnh hưởng đến chất lượng sản phẩm.
Nên nhớ rằng người dùng thật của sản phẩm không có ý định kiểm thử sản phẩm mà chỉ muốn sử dụng chúng cho nên hãy sáng tạo khi kiểm thử. Do đó nếu có trường hợp kiểm thử nào mà bạn kiểm thử ít hơn những trường hợp khác thì đôi khi vẫn có thể chấp nhận được. Việc có cái nhìn tổng thể sẽ giúp kỹ sư kiểm thử có thể cân bằng được những điều này.
8. Sắp xếp thứ tự ưu tiên
Khả năng nhìn tổng thể sẽ giúp cho kỹ sư kiểm thử sắp xếp được thứ tự ưu tiên trong công việc. Một kỹ sư kiểm thử giỏi luôn biết phải kiểm thử cái nào trước cái nào sau và phạm vi kiểm thử như thế nào để những phần kiểm thử mà có khả năng tìm được bug nhiều nhất và ảnh hưởng đến khách hàng nhiều nhất sẽ được thực thi trước.
Cũng theo ý tác giả, để làm được việc này một cách hiệu quả thì cần phải nắm được khách hàng của mình là ai. Khách hàng của khách hàng cũng là khách hàng. Đội hỗ trợ sản phẩm cũng là khách hàng. Các bên liên quan đến sản phẩm đều sẽ bị ảnh hưởng bởi những con bug bạn tìm được hoặc không tìm được.
Theo sát phần thiết kế của sản phẩm ngay từ đầu hay trao đổi với kỹ sư lập trình sẽ giúp bạn biết được mình cần phải tập trung kiểm thử phần nào và độ ưu tiên ra sao. Tuy nhiên, hãy tin vào bản năng của một kỹ sư kiểm thử. Nếu bản năng nói với bạn rằng chỗ này hoặc chỗ kia cần phải kiểm thử, hãy nên lắng nghe nó.
[TH]: Đó là lí do vì sao các bộ trường hợp kiểm thử hay bug thường có 2 thông tin quan trọng là “độ ưu tiên” (Priority) và “độ nghiêm trọng” (severity). Trong nhiều trường hợp vì một lí do nào đó bạn không thể thực thi hết tất cả các bộ kiểm thử thì khi đó việc xác định độ ưu tiên sẽ giúp bạn chọn được những phần kiểm thử quan trọng nhất để thực thi để rủi ro ảnh hưởng đến sản phẩm thấp nhất.
9. Khả năng quan sát
Những kỹ sư kiểm thử giỏi luôn để mắt quan sát những điều bất thường trên đường kiểm thử của mình. Những điều bất thường này có khi chỉ là những lỗi lập trình đơn giản, có khi là cả một “ổ” bug, có khi đó là một con bug nào đó mà trước giờ nhiều người vẫn chưa mô phỏng lại được. Hãy ghi nhận lại tất cả những gì bất thường quan sát được.
Để quan sát được những điều bất thường thì trước tiên kỹ sư kiểm thử phải biết được như thế nào là bình thường. Để làm được vậy người kỹ sư kiểm thử phải nắm được sản phẩm của mình từ trong ra ngoài. Bên cạnh đó phải luyện tập thường xuyên kỹ năng quan sát. Để tâm vào chi tiết và phát hiện những điều có vẻ hơi bất bình thường một chút. Tuy nhiên, đừng quá sa đà nếu không bạn sẽ bỏ qua những con bug lộ ngay trước mặt.
[TH]: Lời khuyên của mình là hãy luôn có một cuốn sổ tay bên mình hay bất cứ thứ gì có thể ghi chú được khi thực thi các trường hợp kiểm thử hay kiểm thử kiểu khám phá (mình chọn Onenote ) Mục đích là để ghi chú tất cả những gì mình quan sát được, nghi ngờ là bug hoặc đơn giản chỉ là những điều mình thắc mắc và sẽ quay lại tìm hiểu và kiểm chứng sau mà không làm chệch mục tiêu mình đang kiểm thử.
10. Sự chính xác
Khi những kỹ sư kiểm thử giỏi tìm được bug, họ thường dành thời gian để làm giảm thiểu số bước cần thiết để mô phỏng con bug đến mức tối thiểu. Họ cũng thường kiểm thử thêm xung quanh con bug để hiểu thêm về con bug. Những kỹ sư kiểm thử giỏi khi báo cáo một con bug luôn chỉ rõ ra chỗ nào là ngầm định, chỗ nào là họ thực tế quan sát được.
Có nhiều cách để làm tốt khâu này. Hãy nhìn vấn đề với con mắt của kỹ sư lập trình để hiểu được bản chất của nó. Hãy giả định rằng người đang đọc bản báo cáo bug có thể là người không có hoặc ít kiến thức về vấn đề đang được đề cập. Mục đích là để làm sao ngay cả CEO cũng có thể đọc, hiểu được bản báo cáo bug và đưa ra quyết định dựa trên báo cáo đó. Trong báo cáo bug, hãy chỉ rõ hành vi bạn mong muốn là gì và tại sao cái bạn quan sát là không hợp lí. Hãy giải thích con bug này sẽ làm ảnh hưởng như thế nào đến khách hàng.
[TH]: Hãy làm tất cả những gì có thể mà bạn nghĩ là cần thiết để giúp người đọc hiểu được bản chất của con bug đó. Các bước mô phỏng, ảnh chụp màn hình, video, log file, trích dẫn tài liệu đặc tả, thiết kế, v.v tất cả đều hữu dụng khi bạn báo cáo bug.
11. Suy nghĩ độc lập
Mặc dù việc con bug làm ảnh hưởng đến khách hàng như thế nào đã được để cập đầy đủ trong báo cáo bug nhưng kỹ sư kiểm thử giỏi đôi khi cũng phải đối diện với tình huống là phải yêu cầu để sửa bug đó gấp. Những kỹ sư kiểm thử giỏi luôn sẵn sàng trở nên cứng đầu và “xù lông” khi cần thiết.
Tuy nhiên, trước khi “xù lông” thì hãy đánh giá lại một lần nữa liệu vấn đề có phải là do bạn đã không cung cấp đủ thông tin cần thiết về mức độ ảnh hưởng của con bug hay là bạn đã không đặt độ ưu tiên đủ cao cho con bug. Một kỹ sư kiểm thử giỏi luôn cân nhắc tất cả những điều này cùng với việc đặt khách hàng lên trên hết trước khi đưa ra quyết định của mình.
Nên nhớ rằng bạn không cần phải thô lỗ hay bất cần khi nêu lên quan điểm của mình. Hãy tìm đồng minh để “chống lưng” cho vấn đề của bạn. Hãy nhẹ nhàng chỉ ra lí do tại sao con bug cần được sửa và thuyết phục rằng sản phẩm sẽ không thể được đưa ra thị trường với con bug đó được.
Uy tín của bạn đóng vai trò quan trọng ở đây. Nếu bạn báo động giả nhiều lần, sẽ chẳng ai còn tin bạn. Do đó hãy suy nghĩ và nghiên cứu vấn đề một cách thấu đáo và hãy chắc chắn rằng bạn có đủ thông tin để tự tin.
Hãy luôn nhớ rằng kỹ sư kiểm thử không phải là người quyết định sau cùng một con bug có được sửa hay không. Do đó khi tranh luận, hãy lịch sự nhưng đồng thời cũng phải tỏ ra cứng rắn.
12. Nhu cương đúng lúc
Những kỹ sư kiểm thử giỏi luôn sẵn sàng đứng lên tranh luận khi cần thiết nhưng họ cũng biết khi nào nên dừng lại. Kỹ sư kiểm thử giỏi luôn cảm nhận được nỗi đau khi để vuột mất một vấn đề quan trọng nào đó. Họ cũng biết được không thể và không đáng để sửa tất cả các con bug. Họ cũng biết được rằng một số con bug sẽ được đưa ra thị trường cùng với sản phẩm để những con bug khác được sửa.
Hãy luôn nhớ rằng việc cung cấp thông tin là cốt lõi trong kiểm thử phần mềm. Vai trò của kỹ sư kiểm thử không phải là ra quyết định mà là cung cấp thông tin một cách đầy đủ để ban lãnh đạo có thể ra quyết định khi nào sửa bug, khi nào đưa sản phẩm ra thị trường và khi nào không.
[TH]: Hãy nhu cương đúng lúc!!
Hết phần 2 .
Trong phần cuối, mình sẽ giới thiệu đến các bạn những đặc điểm sẽ giúp các bạn áp dụng những đặc điểm trên một cách tối ưu nhất.
Đầu năm chính là thời điểm mà thị trường nhân lực, tuyển dụng hoạt động vô cùng sôi nổi, có thể nói là sôi nổi nhất trong năm, vì chúng ta mới nghỉ Tết xong lại còn có một cục thưởng Tết nữa mà! Nhưng điều đó thì liên quan gì đến việc kia nhỉ?! Tưởng ko liên quan nhưng mà lại khá là liên quan đó, hehe.
Khi mà bạn vừa nhận được cục kia, gọi là thưởng cho thành tích mà bạn đã đạt được trong năm vừa qua, có người thì hài lòng với con số mà có nhiều số 0 đằng sau 1 con số ‘vừa đủ’ nào đó, có người thì không hài lòng, cảm thấy “bất công”, chẳng xứng với công sức mình đã đóng góp, cống hiến.
Với những người cảm thấy hài lòng hoặc tạm hài lòng với con số đó thì họ lại muốn được nhiều hơn trong năm tới, người chưa hài lòng muốn tìm một nơi có con số kia khiến người ta có thể chấp nhận được hơn, cũng có những người không quan trọng các con số đó quá thì họ lại muốn tìm một môi trường làm việc thách thức hơn, hay nhàn nhã hơn, hoặc thoải mái hơn, phù hợp hơn về nhiều mặt, rồi hay vì những ức chế với mấy vị sếp, phải cố lấy thưởng xong rồi đi… và còn muôn vàn lý do khác nữa cho những người nhảy việc.
Và ở công ty hiện tại bên mình thời gian gần đây cũng không thể nào tránh khỏi cái thời điểm nhạy cảm này, khi mà đùng một cái bao nhiêu người báo nghỉ, liên hoan chia tay cứ rần rần như cái việc liên hoan gặp mặt cuối năm ấy! Hòa chung không khí nhộn nhịp ấy mình cũng lướt qua thị trường tuyển dụng xem tình hình ra sao. Mình quan tâm nhiều hơn đến các vị trí kiểm thử, và tìm hiểu luôn bên thị trường Thái (cơ bản cũng không khác VN nhưng mà mình muốn kiếm cơ hội đi Thái luôn ấy mà! ) hehe
Các tiêu chí về mặt chuyên môn, thì cũng đều yêu cầu người ứng tuyển có kinh nghiệm (mới tốt nghiệp hoặc là ít kinh nghiệm cũng có nhé), nắm chắc các kiến thức cơ bản về kiểm thử, tạo mới, và thực thi test case cho hệ thống, có kiến thức về cơ sở dữ liệu, kiến thức về lập trình ngoài ra cũng rất đánh giá cao các ứng viên năng động và thái độ tích cực trong công việc.
Liên quan đến chủ đề chính của bài viết này, trong nhiều các yêu cầu của các công ty mình đã xem qua thì đều dành luôn một dòng yêu cầu các ứng viên phải có đó chính là kiến thức về UAT và SIT. Thấy cũng hay hay nên mình tổng hợp lại kiến thức về hai cái này để chúng ta cùng ôn lạị nhé!
Bạn nào mà ôn ISTQB rồi thì chắc là nắm được cái này rồi, có thể đọc tiếp để xem mình có nhầm chỗ nào không rồi góp ý cho mình với nha!
UAT là gì?
UAT: là viết tắt của User Acceptance Test
UAT và SIT là hai mực độ kiểm thử phần mềm khác nhau.
UAT được thực hiện ở giai đoạn cuối cùng trong chu trình kiểm thử trước khi đưa sản phẩm ra thị trường, đưa đến tay người dùng. Việc này để đảm bảo là các chức năng của sản phẩm phần mềm xây dựng đáp ứng được các yêu cầu và nghiệp vụ mà hai bên (là bên cung cấp phần mềm và khách hàng) đã thống nhất với nhau trước đó.
Các loại UAT
UAT có hai loại chính là Alpha testing và Beta testing
Alpha testing: được thực hiện trong môi trường của developer, và thường do một team độc lập với team design nhưng vẫn trong cùng công ty nhé! Có thể là một nhóm các test engineer, hoặc các SQA.
Beta testing: hay còn được biết đến với tên gọi khác là field testing, được thực hiện 1 hoặc nhiều lần trên môi trường với các điều kiện thực tế mà nó sẽ được sử dụng chính thức và do chính các khách hàng là người sử dụng phần mềm. Beta test chỉ được thực hiện sau khi Alpha test đã hoàn thành. Ta vẫn thường nghe đến các bản beta của các loại game đó!
SIT là gì?
SIT: là viết tắt của System Integration Test
SIT được thực hiện để xác nhận rằng các chức năng đã được test độc lập khi kết hợp với nhau có thể hoạt động và đáp ứng yêu cầu chức năng. Các chức năng có thể hoạt động tốt khi chúng được test độc lập, nhưng khi tích hợp với các chức năng khác thì có thể xảy ra một số vấn đề khiến nó không hoạt động đúng yêu cầu. SIT được thực hiện để kiểm tra tính đúng đắn và sự toàn vẹn dữ liệu giữa các chức năng phụ thuộc nhau.
So sánh nho nhỏ giữa UAT vs. SIT
SIT
UAT
Khái niệm
Kiểm thử giao tiếp giữa các module khi tích hợp với nhau
Kiểm thử để đảm bảo đáp ứng đúng yêu cầu của người dung
Mục đích
Mục đích là kiểm tra việc giao tiếp các module hệ thống với nhau
Kiểm tra dưới góc nhìn của người dung thực tế
Người thực hiện
Được thực hiện bởi dev và test
Được thực hiện bởi khách hàng, người dùng cuối
Cách thức thực hiện
Thực hiện theo quy trình, luồng xử lý dữ liệu và nghiệp vụ
Thực hiện ngẫu nhiên, có thể không theo một quy trình cụ thể bắt buộc nào.
Chi tiết về từng loại như sự cần thiết, lợi ích, áp dụng và triển khai trong dự án thực tế như thế nào các bạn có thể tìm hiểu thêm trên nhiều trang chia sẻ về testing nhé. Ở đây mình chỉ điểm một vài ý chính để chúng ta có thể hiểu và nhớ được khi mà nhắc đến mấy khái niệm này thôi. Hehe.
Khi bạn vừa thêm một commit vào git tree, và chợt nhận ra commit vừa rồi bị sai, không hoàn chỉnh hoặc có vấn đề, bạn sẽ muốn “undo” commit hoặc loại bỏ nó. Ở đây mình sẽ giới thiệu 3 cách undo commit hoặc loại bỏ commit cơ bản: RESET, REVERT VÀ –amend
Git Reset
git reset là một lệnh mạnh mẽ trong Git cho phép bạn quay lại trạng thái trước đó của project. Git reset được sử dụng để di chuyển HEAD (con trỏ chỉ đến commit hiện tại) đưa nhánh hiện tại về một commit cụ thể trong lịch sử.
Nhảy HEAD về vị trí trước, khi commit sai bằng git reset như sau:
git reset --hard HEAD^
Ở đây có vài điểm cần lưu ý:
HEAD^ có ý nghĩa giống với HEAD~ hay @^, nghĩa là quay về trước 1 commit
Muốn quay về trước n commit, VD 5 commit thì có thể thay bằng HEAD~5.
git reset --hard|soft HEAD~2 -> Quay về trước 2 commit so với HEAD.
--hard có nghĩa là bỏ commit đi và bỏ cả những thay đổi chưa được commit trong working space. Khi này môi trường sẽ hoàn toàn “sạch sẽ” như thời điểm trước khi commit.
--soft có nghĩa là bỏ commit đi nhưng giữ nguyên những thay đổi chưa được commit trong working space. --soft hữu dụng khi bạn muốn giữ lại những thay đổi chưa commit cho lần commit tiếp theo.
Git Revert
git revert là một lệnh Git được sử dụng để tạo ra một commit mới nhằm đảo ngược thay đổi của commit trước đó. Không giống như git reset, git revert không thay đổi lịch sử Git. Nó tạo ra một commit mới có tác dụng ngược lại so với commit mà bạn muốn loại bỏ, giúp giữ nguyên lịch sử commit một cách rõ ràng và an toàn hơn.
Giả sử commit cũ có hash là (commit_hash) thì câu lệnh sẽ là:
git revert (commit_hash)
Git revert hay được sử dụng để đảo ngược một merge commit. Nếu sau khi git revert bạn lại muốn quay lại trạng thái trước khi đảo ngược thì sao ? Câu trả lời là git revert lại chính revert commit vừa mới tạo.
–amend
git commit --amend là một lệnh hữu ích trong Git giúp bạn sửa đổi commit gần đây nhất. Thay vì tạo một commit mới, --amend cho phép bạn ghi đè lên commit cuối cùng đã thực hiện.
git commit --amend
Lúc này git sẽ cho phép bạn viết lại commit message. Cách này hay dùng khi muốn sửa commit message. Nếu bạn chỉ muốn add thêm file mà không muốn sửa commit message thi có thể dùng option --no-edit
# Đây là commit sai / thiếugit add home.php
git commit -m 'Add home'# Nhận ra là add thiếu 1 file home.css và muốn thêm vào commit bên trên
git add home.css
git commit --amend --no-edit
Kết luận
3 cách bên trên đây có những trường hợp sử dụng cụ thể khác nhau
Muốn bỏ hoàn toàn một commit sai, dùng git reset
Muốn undo commit và để lại lịch sử, dùng git revert
Muốn thêm những thay đổi nhỏ không đáng kể và tránh bị lắt nhắt, dùng git commit --amend
React Router Cheatsheet và mọi thứ bạn cần biết (Phần 1)
Tác giả: Reed Barger
Nếu bạn đang xây dựng các ứng dụng React cho web, bạn sẽ cần sử dụng một router chuyên dụng để hiển thị các trang và điều hướng người dùng của bạn xung quanh chúng.
Đó là lý do tại sao hôm nay chúng ta sẽ xem xét bộ React applications – React Router.
Cài đặt React Router
Bước đầu tiên để sử dụng React Router là cài đặt package thích hợp. Về mặt kỹ thuật, chúng là ba gói khác nhau: React Router, React Router DOM và React Router Native.
Sự khác biệt chính giữa chúng nằm ở cách sử dụng. React Router DOM dành cho các ứng dụng web và React Router Native dành cho các ứng dụng di động được tạo bằng React Native.
Điều đầu tiên bạn cần làm là cài đặt React Router DOM bằng cách sử dụng npm:
npminstall react-router-dom
Setup React Router cơ bản
Sau khi được cài đặt, có thể đưa thành phần đầu tiên vào để sử dụng bộ định tuyến React được gọi là BrowserRouter.
Lưu ý rằng có nhiều loại router react-router-dom cung cấp ngoài BrowserRouter nhưng ở đây sẽ không đi sâu vào phân tích. Nếu chúng ta muốn cung cấp các tuyến trong toàn bộ ứng dụng của mình, nó cần được bao bọc xung quanh toàn bộ cây thành phần của chúng ta. Đó là lý do tại sao bạn thường sẽ thấy nó được bao bọc xung quanh hoặc bên trong thành phần ứng dụng chính:
import{ BrowserRouter as Router }from'react-router-dom';exportdefaultfunctionApp(){return(<Router>{/* routes go here, as children */}</Router>);}
Đây là chức năng chính của BrowserRouter: để có thể khai báo các tuyến đường riêng lẻ trong ứng dụng.
Bắt đầu bằng khai báo các router trong Router component là các tuyến con. Bạn có thể khai báo bao nhiêu routes tùy thích và cần cung cấp ít nhất hai props cho mỗi route path và component (hoặc render):
import{ BrowserRouter as Router, Route }from'react-router-dom';exportdefaultfunctionApp(){return(<Router><Route path="/about" component={About}/></Router>);}functionAbout(){return<>about</>}
Prop path hỗ trợ chỉ định đường dẫn của ứng dụng mà một route nhất định được đặt.
Các props render hoặc component được sử dụng để hiển thị một thành phần cụ thể cho đường dẫn của chúng ta.
Các props component chỉ có thể nhận tham chiếu đến một thành phần nhất định, trong khi render thường được sử dụng nhiều hơn để áp dụng một số logic có điều kiện để hiển thị một thành phần này hay thành phần khác. Để kết xuất, bạn có thể sử dụng tham chiếu đến một thành phần hoặc sử dụng một hàm:
Cần lưu ý rằng bạn có thể bỏ prop render hoặc component hoàn toàn và sử dụng component mà bạn muốn liên kết với một route nhất định khi là route con:
import{ BrowserRouter as Router, Route }from"react-router-dom";exportdefaultfunctionApp(){return(<Router><Route path="/about"><About /></Route></Router>);}
Cuối cùng, nếu muốn một thành phần (chẳng hạn như thanh điều hướng) hiển thị trên mọi trang, hãy đặt nó nằm trong trình duyệt của router, nhưng ở trên (hoặc bên dưới) các routes đã khai báo:
import{ BrowserRouter as Router, Route }from"react-router-dom";exportdefaultfunctionApp(){return(<Router><Navbar /><Route path="/" component={Home}/><Route path="/about" component={About}/></Router>);}functionNavbar(){// visible on every pagereturn<>navbar</>}functionHome(){return<>home</>;}functionAbout(){return<>about</>;}
Khi bắt đầu thêm multiple routes, bạn sẽ nhận thấy một số vấn đề. Giả sử chúng ta có một route cho trang chủ và trang giới thiệu. Mặc dù chỉ định hai đường dẫn khác nhau, ‘/’ và ‘/ about’, khi truy cập trang giới thiệu, bạn vẫn sẽ thấy cả thành phần home và about.
Có thể khắc phục sự cố này bằng phần mềm hỗ trợ chính xác, trên route chính để đảm bảo rằng router của chúng tôi khớp chính xác với đường dẫn ‘/’ thay vì ‘/ about’:
Khi nói đến chuyển đổi giữa các routes khác nhau mà router sẽ hiển thị, trên thực tế, có một thành phần chuyên dụng mà bạn nên sử dụng nếu bạn có nhiều routes trong router của mình và đó là việc chuyển đổi thành phần.
Thành phần chuyển đổi nên được bao gồm trong router và có thể đặt tất cả các routes bên trong nó:
Switch sẽ xem xét tất cả các child routes và hiển thị cái đầu tiên có đường dẫn khớp với URL hiện tại. Thành phần này là những gì bạn muốn sử dụng trong hầu hết các trường hợp cho hầu hết các ứng dụng, vì sẽ có nhiều routes và nhiều plate pages trong ứng dụng của mình nhưng chỉ muốn hiển thị một trang tại một thời điểm.
Nếu vì lý do nào đó bạn muốn nhiều trang được hiển thị cùng một lúc, bạn có thể cân nhắc không sử dụng thành phần chuyển đổi.
Nếu chúng ta cố gắng đi đến một route không tồn tại trong ứng dụng thì sẽ thấy gì? Bạn sẽ không nhìn thấy bất cứ điều gì nếu không có một route tương ứng với điều đó. Làm thế nào để tạo một catch-all route?
Nếu người dùng cố gắng truy cập một trang không có route xác định, bạn cũng có thể tạo một route và sau đó đặt đường dẫn thành dấu hoa thị *:
import{ BrowserRouter as Router, Switch, Route }from"react-router-dom";exportdefaultfunctionApp(){return(<Router><Navbar /><Switch><Route path="/" component={Home}/><Route path="/about" component={About}/><Route path="*" component={NotFound}/></Switch></Router>);}functionNotFound(){return<>You have landed on a page that doesn't exist</>;}
Điều này sẽ phù hợp với bất kỳ nỗ lực nào để truy cập một trang không tồn tại và có thể kết nối nó với một thành phần không tìm thấy để cho người dùng biết rằng họ đã “đến một trang không tồn tại”.
Bài viết được sự cho phép của tác giả To Thi Van Anh
Tại vì là đã có rất nhiều các bài viết nói rất kỹ về TestNG này rồi, nếu muốn tìm hiểu thì mọi người chỉ cần tìm kiếm trên Google với những từ khóa liên quan đến TestNG, thì có hàng trăm nghìn kết quả được tìm ra chỉ trong vài giây luôn, và thế là các bạn đã có thể thoải mái đọc hiểu về bạn này.
Chính vì thế mà mình không nói lại nữa, mà sẽ ôn tập theo hình thức là đưa ra các câu hỏi mà khi phỏng vấn có thể là bạn sẽ gặp phải. Hehe, chỉ là dễ gặp thôi nha, quan trọng ở đây vẫn là lượng kiến thức hữu ích cho các bạn để có thể nắm được và vận dụng thành thạo trong các project của mình!
#1. Ý nghĩa của file <testNG.xml> là gì? Hay sử dụng file <testNG.xml> này có tác dụng gì?
Trong dự án Selenium TestNG, ta sử dụng file <testNG.xml> để cấu hình các bộ test đã hoàn thành vào trong một file cụ thể. File này giúp cho chúng ta gom nhóm các bộ test case và các tham số của bộ đó một cách dễ dàng trong file đó. Đồng thời cũng cung cấp khả năng tạo các tập hợp con cho các test hoặc tách thời gian gian chạy các test theo cấu hình.
Một số công việc ta có thể nhóm trong file .xml này như:
Có thể cấu hình bộ test bao gồm nhiều test case cụ thể nào đó để chạy từ một nơi duy nhất. Như cho phép bộ test này chỉ run test trên FireFox, hoặc chỉ trên IE thôi.
Có thể bao gồm hoặc không bao gồm các test method được thực thi việc test ứng dụng
Có thể chỉ định cụ thể một nhóm nào sẽ được chạy hoặc không
Có thể sử dụng các tham số cho các test, như việc set tham số để chọn trình duyệt sẽ sử dụng này, linh động trong việc kết nối cơ sở dữ liệu…
Bạn cũng có thể cấu hình để chạy test song song cho ứng dụng, ví dụ như cấu hình để chạy bộ test nào đó chạy cùng một lúc trên các trình duyệt là FireFox, Chrome và IE chẳng hạn.
Bên cạnh đó, ta cũng sẽ sử dụng các parameter theo cú pháp dưới đây trong test case:
Ở đây, thuộc tính name định nghĩa tên của tham số, thuộc tính value là giá trị của thuộc tính đó.
#3. Trong trường hợp một test case có nhiều method @Test, nhưng khi thực thi test case thì lại không muốn run một method test nào đó, bạn có thể làm gì để giải quyết vấn đề này?
Ở đây chúng ta chỉ cần thêm tên method mà ta không muốn chạy vào trong tag exclude trong file <testNG.xml> theo cú pháp hướng dẫn dưới đây nhé:
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="Test Exclusion Suite">
<test name="Exclusion Test" >
<classes>
<class name="Your Test Class Name">
<methods>
<exclude name="Tên test method mà bạn muốn Exclude"/>
</methods>
<class>
</classes>
</test>
</suite>
#4. Sắp xếp thứ tự các thẻ dưới đây theo cấp cha-con trong file <testNg.xml>:
<test><suite><class></methods></classes>
Trong file <testNg.xml> ta có:
Tag cha trong file testNg.xml là tag <suite>
Trong tag <suite> có thể bao gồm một hoặc nhiều tag <test>
Trong tag <test> có thể bao gồm tag <classes>
Tag <classes> có thể bao gồm một hoặc nhiều tag <class>
Tag <class> chứa các tag <method> – nơi mà chúng ta định nghĩa các test method có thể được thực thi hoặc là không.
Do đó, thứ tự các thẻ theo cấp cha-con được sắp xếp như sau:
<suite> <test></classes> <class> </methods>
#5. Bạn set thứ tự ưu tiên của các @Test method như thế nào? Nó có ý nghĩa gì?
Trong số các test case cho ứng dụng web mà chúng ta có, ta có thể thực hiện gắn độ ưu tiên thực hiện cho các test case ấy bằng cách thêm tham số vào trong anotation @Test theo cú pháp sau:
@Test(priority=0)
Bằng cách sử dụng việc này ta có thể dễ dàng điều khiển thứ tự thực thi các test case theo ý muốn, hoặc theo yêu cầu nhất định nào đó. Cụ thể với những test case được gắn trọng số priority = 0 thì sẽ được ưu tiên chạy trước những test case có trọng số bằng 1, rồi 2…
#6. Kể tên ít nhất 5 assertion của testNG mà chúng ta có thể sử dụng trong Selenium webdriver
Có nhiều loại assertion khác nhau trong testNG, dưới đây là một số loại assert mà mình đã dùng như:
assertEquals
assertNotEquals
assertTrue
assertFalse
assertNull
assertNotNull
#7. Bạn hãy đưa ra một số cách khác nhau để run TestNG?
Chúng ta có thể run TestNG bằng một số cách sau:
Thực hiện run trực tiếp từ Eclipse IDE
Thực hiện run thông qua IntelliJ’s IDEA IDE
Thực hiện run với ant build tool
Hoặc run từ command line
#8. Để disable một test trong testNG bạn làm cách nào?
Để disable một test case, ta có thể thêm tham số enable vào trong annotation @Test theo cú pháp dưới đây:
@Test(enabled = false)
#9. Parametric testing trong TestNG là gì?
Parametric testing cho phép chúng ta chạy lại cùng một test case nhưng với các giá trị test data khác nhau. Ví dụ với trường hợp đăng nhập, ta có thể đăng nhập với nhiều dữ liệu test có cặp username và pass word khác nhau. TestNG cho phép chúng ta có thể truyền các tham số vào trong các test method bằng hai cách dưới đây:
Sử dụng trong file TestNG.xml
Với Data providers.
#10. Các cách để xuất báo cáo trong TestNG là gì?
TestNg cung cấp hai cách giúp chúng ta có thể xuất báo cáo, đó là:
Sử dụng Listeners: một class listenter sẽ thực thi một interface là org.testng./TestListener. Trong khi run test, TestNg sẽ gửi thông tin tới các class đó mỗi khi các test case đó ở các trạng thái như: est begins, finishes, skips, passes hoặc fails.
Sử dụng Reporters: đối với một class reporting, nó cũng sẽ thực thi cái interface là org.testng/Reporter. Khi mà tất cả các test suite chạy xong, những class này sẽ được gọi đến, lúc này tất cả các thông tin của các đối tượng trong toàn bộ quá trình thực hiện test sẽ được gửi đến class này.
#11. Liệt kê những ưu điểm của TestNG so với Junit?
Dưới đây là một số ưu điểm của TetsNG so với Junit:
TestNG có các anotation logic hơn và dễ hiểu hơn
TestNG class không yêu cầu bắt buộc khai báo @BeforeClass và @AfterClass.
Trong Selenium TestNG không có các ràng buộc về method name
TestNG hỗ trợ thêm một số annotations:
@Before/AfterSuite,
@Before/AfterTest, and
@Before/AfterGroup.
Trong Selenium TestNG project, thì bạn không cần phải extend class nào
Trong TesNG, bạn có thể thực hiện chạy song song các test case
TestNG hỗ trợ bạn gom nhóm các test case, điều mà Junit không làm được.
Từ các nhóm, TestNG cho phép bạn chạy các test case nằm trong các nhóm ấy.
TestNG cho phép bạn xác định các test case phụ thuộc.
Nói chung là kiến thức thì rộng lớn lắm, bọn mình cần phải làm nhiều thì mới gặp đến những trường hợp mà bình thường chả bao giờ đả động đến luôn. Mấy câu hỏi này thực ra là cũng chẳng có gì là khó, và nó cũng còn nhiều lắm hehe. Nếu các bạn quan tâm thì phần sau mình sẽ cố gắng chọn lọc và đưa vào những câu hỏi nâng cao hơn.
Không khí tết tràn ngập khắp nơi rồi, mình cũng a dua theo dân tình đi làm mẻ mứt dừa để tết ngồi gặm cho mỏi răng đây!
Bài viết được sự cho phép của blogchiasekienthuc.com
Chào anh em, có lẽ việc học một ngôn ngữ lập trình nào đó là bắt buộc nếu như anh em có ý định làm về IT nói chung, hay làm về lập trình nói riêng.
Thực ra nếu dùng từ “bắt buộc” là không đúng, vì thực tế có nhiều hướng đi trong ngành IT không yêu cầu anh em phải nắm rõ một ngôn ngữ lập trình nào đó.
Nhưng cũng giống như việc ăn cơm, nếu như anh em biết một ngôn ngữ lập trình thì nó cũng giống như kiểu anh em có một đôi đũa trong tay vậy, và mọi việc sẽ trở nên dễ dàng hơn rất nhiều.
Nhưng liệu lập trình viên có nên học nhiều hơn một ngôn ngữ lập trình hay không?
Đã có rất nhiều ý kiến trái chiều xoay quanh vấn đề này, vậy nên trong bài viết ngày hôm nay mình sẽ đưa ra 5 lý do để các bạn nên học nhiều hơn một ngôn ngữ lập trình.
Do là ý kiến chủ quan của mình nên có thể đúng với người này, không đúng với người khác mong anh em góp ý nha.
#1. Rèn luyện khả năng tiếp cận công nghệ mới
Anh em làm về IT thì biết rồi đấy, công nghệ mới thay đổi liên tục từng giây. Nhiều khi chưa kịp làm chủ công nghệ này thì đã có công nghệ khác tốt hơn và tối ưu hơn rồi.
Tất nhiên, việc chạy theo công nghệ không phải lúc nào cũng tốt, nhưng ngược lại, cứ khư khư mãi một công nghệ cũ cũng là không nên.
Mà công nghệ mới thường được phát triển dựa trên các ngôn ngữ lập trình khác nhau, nó được cập nhật hàng tuần chứ không muốn nói là hàng ngày.
Mình lấy ví dụ bạn rất giỏi về Java, nhưng lại không biết gì về NodeJS thì các công nghệ mới được phát triển từ NodeJS bạn sẽ tiếp cận khó khăn hơn, vì bạn chưa có nền tảng về NodeJS.
Tất nhiên là nếu nắm được phương pháp và cách tiếp cận thì cũng không mất quá nhiều thời gian, nhưng trong nhiều trường hợp gấp rút (dự án đang rất cần) thì một chút thời gian đó thôi cũng có thể quyết định doanh thu của dự án.
Chính vì vậy, việc học một ngôn ngữ lập trình (ở mức cơ bản, nắm được cú pháp, biết cách dùng) đôi khi sẽ giúp bạn làm chủ công nghệ được nhanh hơn.
#2. Có thêm “vũ khí”
Hồi sinh viên chúng ta thường nghe thầy cô bảo “Ngôn ngữ lập trình chỉ là công cụ thôi, cái quan trọng là tư duy thuật toán”.
Thì đúng là như vậy, ngôn ngữ lập trình chỉ là công cụ ! Nhưng nếu bạn đã đi làm rồi thì bạn sẽ phải bổ sung câu trên như sau:
“Ngôn ngữ lập trình chỉ là công cụ thôi, cái quan trọng là tư duy thuật toán. Nhưng nếu biết dùng và dùng đúng công cụ thì bài toán đôi khi lại đơn giản hơn rất nhiều”
Thực tế là như vậy anh em à, việc anh em triển khai một thuật toán hồi đi học trong một dự án thực tế thì gần như là rất hiếm. Chủ yếu là sử dụng các phương thức, các hàm có sẵn hoặc thay đổi chúng sao cho phù hợp với bài toán.
Có nhiều bài toán nếu dùng Java có khi cả ngày không ra, nhưng ngược lại khi dùng Python thì lại cho kết quả rất nhanh hoặc ngược lại.
Nhưng để đạt được đến trình độ mà bài toán nào thì sử dụng ngôn ngữ nào là hiệu quả nhất sẽ đòi hỏi anh em phải hiểu về ngôn ngữ và có kinh nghiệm làm việc với nó, chứ không phải đơn thuần học qua qua là làm được ngay.
#3. Dễ dàng thích nghi với thay đổi hơn
Như mình đã trình bày bên trên, việc học nhiều hơn một ngôn ngữ lập trình sẽ giúp bạn tiếp cận công nghệ mới dễ dàng hơn.
Và thực tế trong quá trình đi làm thì có thể các bạn sẽ phải làm nhiều dự án khác nhau, mỗi dự án sử dụng một công nghệ khác nhau.
Nếu chỉ khư khư một công nghệ nào đó thì mình đảm bảo là các bạn sẽ rất khó để “mở tư duy”, để tiếp cận với các công nghệ khác.
Trong khi khả năng thích nghi gần như là một kỹ năng bắt buộc phải có của một lập trình viên hiện nay, vì không phải công ty nào cũng có đủ nguồn lực để đáp ứng kịp thời theo dự án.
Lập trình viên buộc phải tiếp cận và thích nghi nhanh với công nghệ mới để cho kịp dự án. Đây là sự thật mà anh em chấp nhận khi đi làm, và tất nhiên nếu bạn có nền tảng về các ngôn ngữ lập trình khác nhau thì việc thích nghi sẽ dễ dàng thôi.
#4. Thêm nhiều cơ hội việc làm
Quay lại với câu chuyện cơ hội nghề nghiệp thì thầy cô đại học thường nói: “Người ta chỉ thuê người giỏi về một thứ gì đó, chứ chẳng bao giờ đi thuê một đứa mà cái gì cũng biết một chút để chẳng biết dùng vào đâu.”
Mình phải công nhận là đúng, vì thực tế mình đi làm và đi thực tập gặp nhiều ông bảo cái gì cũng biết nhưng thực tế thì chẳng làm được gì !
Nhưng điều này có đúng với tất cả mọi người không? Theo mình thì là không, vì đôi khi biết nhiều (hiểu về những gì mình biết) có khi còn có nhiều cơ hội việc làm hơn.
Nhất là trong thị trường lao động như hiện này, các bạn sinh viên mới ra trường (những bạn giỏi xuất sắc mình không nói) còn những bạn cũng bình thường mà nếu lười tìm tòi, học hỏi cái mới thì “chết” là chắc. Chết là chết đói ấy
#5. Nâng cao trình độ
Chắc đọc đến đây thì nhiều anh em sẽ nghĩ tại sao mình không để lý do này lên đầu tiên. Rõ ràng đây mới là một lý do quan trong nhất mà !
Nhưng thực tế thì không hẳn là như vậy, không hẳn việc học nhiều ngôn ngữ lập trình là sẽ nâng cao trình độ đâu anh em à.
Nếu bạn không có nền tảng tốt về một ngôn ngữ lập trình nào đó, mà cứ học theo kiểu mỗi thứ biết một ít, mỗi ngôn ngữ lập trình học một ít… thì anh em có học 10 ngôn ngữ hay 20 ngôn ngữ thì cũng thế cả thôi.
Chính việc học và tìm hiểu về nhiều ngôn ngữ lập trình đôi khi nó “ngốn” mất thời gian để anh em chuyên sâu vào một công nghệ nào đó.
Nói vậy thì có vẻ học nhiều hơn một ngôn ngữ lập trình là sai vì nó không giúp anh em nâng cao trình độ?
Không, chắc chắn là không phải là như vậy, quan trọng là anh em học thế nào thôi. Nếu biết trau dồi chuyên môn lại vừa học thêm công nghệ, ngôn ngữ mới thì đảm bảo trình độ của anh em sẽ lên rất nhanh.
Quan trọng vẫn là phương pháp thôi: Phương pháp mà mình gợi ý cho anh em là hãy tập trung học thật chuyên sâu vào một ngôn ngữ, sau đó mở rộng thêm các ngôn ngữ khác ở mức độ cơ bản !
#6. Lời kết
Vâng, đó là một vài những quan điểm cá nhân của mình về việc liệu có nên học nhiều hơn một ngôn ngữ lập trình lập trình hay không?
Đặc biệt là những anh em đã đi làm được 1 – 2 năm rồi thì mình nghĩ là anh em nên học thêm một vài ngôn ngữ lập trình khác, ngoài cái mà anh em đang dùng.
Hi vọng là bạn sẽ thích bài viết này. Xin chào và hẹn gặp lại anh em trong các bài viết tiếp theo nha !
Đâu là những đặc điểm của một kỹ sư kiểm thử giỏi? Mình muốn giỏi thì phải làm sao? Đó cũng chính là băn khoăn của mình cách đây vài năm (và bây giờ vẫn vậy). Và trong một lần tình cờ mình đọc được một bài viết khá đầy đủ và sâu sắc đã giải đáp được phần lớn câu hỏi ở trên và hôm nay mới có dịp chia sẻ bài viết này với cộng đồng kỹ sư kiểm thử phần mềm Việt Nam.
“The hallmarks of great tester” được viết bởi Michael J Hunter – một người có hơn 20 năm kinh nghiệm làm lập trình và kiểm thử ở Microsoft. Michael J Hunter chia sẻ về những đặc điểm của một kỹ sư kiểm thử giỏi và cách ứng dụng chúng trong công việc. Vâng, rất thực tiễn. Tất cả chúng ta đều muốn học một cái gì đó mà có thể ứng dụng ngay được.
Mình sẽ lần lượt giới thiệu với các bạn 20 đặc điểm làm nên một kỹ sư kiểm thử giỏi. Sao? Bạn nói dài quá hả? Mình đồng ý. Tuy nhiên, trong 20 đặc điểm đó chúng ta sẽ bắt gặp đâu đó hình ảnh của mình trong đó và cả những điều mà chúng ta có thể chưa biết hoặc đã biết nhưng làm chưa tốt và chỉ riêng điều đó thôi cũng đáng để chúng ta đọc 20 đặc điểm này.
OK. Bắt đầu thôi.
1. Cân bằng
Những kỹ sư kiểm thử giỏi luôn nhận biết được tầm quan trọng của việc cân bằng trong tất cả các công việc mình làm cũng như luôn biết cách cân bằng sao cho hợp lý trong những tình huống mà họ gặp phải.
Thật khó để định nghĩa thế nào là “hợp lý” tuy nhiên bạn phải biết cân bằng giữa ham muốn đào sâu tìm hiểu vấn đề với yêu cầu phải ra quyết định cũng như nhu cầu hoàn thành công việc.
[TH] Thực vậy, mình thấy khả năng cân bằng trong công việc là rất quan trọng. Mình đã gặp nhiều bạn kỹ sư kiểm thử nhiều khi do quá tập trung việc nghiên cứu tài liệu, sửa lỗi scripts hay tìm bug mà quên deadline của task, quên kiểm tra email, quên một cuộc họp, quên thư giãn, v.v. Cân bằng tốt sẽ giúp mình cảm thấy thoải mái và làm công việc bền vững hơn.
2. Sự tò mò
Sự tò mò là lí do tại sao những kỹ sư kiểm thử giỏi luôn hỏi, tại sao lại như thế này mà không phải thế kia. Họ biết rằng việc hiểu cách một chương trình/ứng dụng chạy sẽ giúp họ hiểu được cách nó tương tác với những chương trình/ứng dụng khác và đó là cách giúp họ tìm ra bug. Một kỹ sư kiểm thử giỏi không những thể hiện sự tò mò trong phạm vi công việc của mình mà còn trong tất cả các mặt khác của cuộc sống như cách bộ phận marketing hoạt động như thế nào hay như chiếc cần cẩu được vận hành như thế nào, v.v
Tuy nhiên nếu bạn vốn không phải tuýp người tò mò thì bạn vẫn có thể thể hiện sự tò mò bằng cách đặt câu hỏi càng nhiều càng tốt trong những vấn đề bạn gặp phải. Một lưu ý là sự tò mò tuy không xấu nhưng cách bạn tò mò có thể làm phiền người khác. Cho nên lời khuyên là bạn phải cho người khác thấy rằng bạn chỉ muốn tìm hiểu tính hợp lý của vấn đề chứ không chỉ đơn thuần là đặt câu hỏi cho mỗi quyết định của họ.
[TH] Trong quá trình làm việc, mình nhận thấy có nhiều bạn luôn ngại hỏi? Nguyên do thì đa dạng nhưng đa phần là vì các bạn đó nghĩ hỏi là dở, hỏi là làm phiền người khác, v.v và các bạn đó một số thì chọn giải pháp “im lặng là vàng”, một số thì giả định vấn đề, một số khác âm thầm tự tìm hiểu. Những cách đó có thể cũng có thể mang lại kết quả nhất định tuy nhiên đó không phải là lựa chọn thường xuyên của những kỹ sư kiểm thử giỏi.
3. Thực hành thường xuyên
Một kỹ sư kiểm thử giỏi luôn kiểm thử toàn bộ sản phẩm chứ không chỉ dừng lại ở tính năng của sản phẩm. Một kỹ sư kiểm thử giỏi còn kiểm thử luôn cả những sản phẩm khác. Một kỹ sư kiểm thử giỏi kiểm thử luôn sách, tủ lạnh, bóng đèn, cửa v.v kiểm thử tất cả mọi thứ trong cuộc sống mà kích thích trí tò mò của họ.
Thực ra thì cơ hội để thực hành công việc kiểm thử không hề hiếm. Bạn có thể kiểm thử máy bán hàng tự động, cửa tự động, lò vi sóng hay bất cứ thứ gì. Hãy thử hình dung ra những tình huống mà những thứ đó có thể hoạt động sai và rồi thử xem bạn có thể khiến nó hoạt động sai không. Kiểm thử mọi thứ mà bạn có thể nghĩ ra nhưng đừng sa đà quá.
[TH]: Lời khuyên này nghe có vẻ ngớ ngẩng nhưng đó là một trong những cách hiệu quả và tiết kiệm nhất để luyện cho bạn khả năng “nhạy” với bug. Tin mình đi, sau một thời gian luyện tập, khả năng tìm bug của bạn trong công việc sẽ cải thiện đáng kể đồng thời cũng đừng ngạc nhiên khi ngày càng có nhiều người khen bạn “hâm” * Lưu ý nhỏ: Không nên luyện tập kiểm thử trên những sản phẩm có độ nguy hiểm cao như…thang máy chẳng hạn.
4. Lắc léo
Một kỹ sư kiểm thử giỏi luôn hình dung ra nhiều cách lắc léo khác nhau để tấn công sản phẩm thay vì chỉ dựa vào checklist hay những hướng dẫn có sẵn. Một kỹ sư kiểm thử giỏi sẽ luôn tìm được những con bug để khiến cho lập trình viên phải đặt câu hỏi “Ai lại đi làm trò vớ vẩn đó” và khi đó họ sẽ trả lời rằng là vì họ có thể làm được, hacker cũng sẽ làm được và người dùng cuối cũng có thể làm.
Nếu bạn không có tính lắc léo bẩm sinh hoặc đã lắc léo rồi nhưng cảm thấy chưa đủ thì đây là cách để bạn luyện: Hãy nghĩ về những thứ có thể khiến cho sản phẩm chạy sai. Bạn có thể bắt từ đầu tài liệu đặc tả nhưng đừng chỉ dừng lại ở đó. Hãy thử với những cách tiếp cận khác nhau (chẳng hạn như HICCUPP), những kỹ thuật khác nhau lên sản phẩm và tập trung vào điểm giao nhau giữa những chức năng. Đó là những nơi mà một kỹ sư kiểm thử giỏi thường dành thời gian vào. Hãy tinh nghịch một chút nhưng phải luôn nắm được những tính năng yêu cầu của sản phẩm. Bug nào cũng là bug nhưng những con bug quan trọng nhất là những con bug có thể gây ảnh hưởng đến người dùng.
5. Luôn phấn khích khi tìm được bug
Kỹ sư Kiểm thử giỏi luôn nhìn bug bằng con mắt đáng yêu. Kỹ sư kiểm thử giỏi luôn thường xuyên tìm gặp lập trình viên để “khoe” những con bug tuyệt đỉnh mà mình vừa mới tìm được trong code của họ. Những kỹ sư kiểm thử giỏi hào hứng “chém gió” về những con bug của mình với những kỹ sư kiểm thử khác và sẵn lòng lắng nghe những kỹ sư kiểm thử khác “chém gió”. Và khi đi làm về nhà, cả nhà đều có thể biết được hôm đó kỹ sư kiểm thử nhà mình có tìm được con bug nào xịn không.
Để làm tốt việc đó, bạn phải học cách luôn vui vẻ và sẵn lòng tìm bug và bị tìm bug. Khi bạn tìm được bug trong code của người lập trình viên hay trong tài liệu đặc tả sếp viết hãy luôn nhớ lại cảm giác khi mình bị người khác tìm được bug. Hãy luôn ghi nhớ mục tiêu của kỹ sư kiểm thử giỏi là giúp đồng nghiệp cảm thấy tốt hơn bằng cách tìm ra những lỗi mà họ đã phạm phải chứ không phải là xát muối vào nỗi đau của họ.
Hãy luôn luôn ghi nhớ:
– Tìm được bug: tuyệt.
– Khiến cho lập trình viên đau đầu với con bug đó: càng tuyệt.
– Giữ mối quan hệ tốt với lập trình viên: vô giá.
[TH] Phần nhiều thì kỹ sư kiểm thử đều (rất) phấn khích khi tìm được bug, tuy nhiên cũng có một số ít lại tỏ ra thờ ơ với những con bug mình tìm được ?!?
6. Niềm đam mê đối với khách hàng
Tác giả chia sẻ một trong những cách có được niềm đam mê đối với khách hàng/người dùng là hãy “thấu hiểu nỗi đau của họ”. Hãy đánh giá về những ảnh hưởng của con bug mà bạn tìm lên khách hàng/người dùng của bạn. Hãy tìm hiểu xem khách hàng/người dùng của bạn chia sẻ những tâm tư nguyện vọng gì trên các diễn đàn, blog hoặc bạn cũng có thể gặp trực tiếp họ để tìm hiểu xem những vấn đề khó khăn mà họ đang gặp phải. Nếu có thể hãy thử sử dụng chính sản phẩm mình đang kiểm thử để đánh giá sản phẩm. Điều cốt lõi là “thấu hiểu nỗi đau của khách hàng”
[TH] Đây là một ý rất hay mà mình rất tâm đắc – Niềm đam mê đối với khách hàng, thấu hiểu khách hàng. Đã bao nhiêu lần kỹ sư kiểm thử mừng ra mặt khi sản phẩm không được đưa ra thị trường đúng hẹn do một số bug quan trọng chưa kịp fix. Kỹ sư kiểm thử cảm thấy tự hào, cảm thấy “vip” nhưng cũng nên hiểu rằng việc chậm trễ trên là không ai muốn và việc đó cũng gây tổn hại cho khách hàng (tài chính, danh tiếng) và cũng có thể cả kỹ sư kiểm thử nữa. Trễ deadline, khách hàng đòi tăng ca, trễ deadline, khách hàng mất khách hàng của họ, sản phẩm thất bại, đóng dự án v.v. Hãy luôn tỏ ra chuyên nghiệp vì bạn sẽ không biết khi nào thì những thứ dường như chẳng liên quan gì đến mình sẽ gây ảnh hưởng đến chính mình.
Mình vừa giới thiệu xong phần đầu tiên (trong 3 phần) về những đặc điểm của một người kỹ sư kiểm thử giỏi. Trong phần 2 của bài viết, mình sẽ giới thiệu đến các bạn cách mà một kỹ sư kiểm thử giỏi ứng dụng những điểm trên vào công việc.
Git Stash là một khái niệm và công cụ dùng để quản lý các chuỗi thay đổi (stack of changes) trong Git, thường được sử dụng trong các dự án phần mềm phức tạp. Nó giúp phát triển và duyệt qua các thay đổi theo cách có tổ chức hơn, đặc biệt là khi làm việc với nhiều nhánh và nhiều yêu cầu pull (pull requests). Dưới đây là một số thông tin chi tiết về Git Stack.
Khái niệm Git stash
Git Stash là gì?
Git Stash giúp bạn tạo ra và quản lý một loạt các thay đổi (commits) liên quan đến nhau một cách dễ dàng. Thay vì chỉ có một chuỗi commit thẳng đứng, bạn có thể có nhiều nhánh nhỏ chứa các thay đổi liên quan. Điều này giúp bạn sắp xếp và hệ thống được các thay đổi theo thứ tự logic, dễ dàng duyệt qua và xem lại từng thay đổi một cách tuần tự.
Trong working directory, để bạn có thể chuyển đổi sang một nhánh khác hoặc thực hiện các công việc khác mà không mất đi những thay đổi chưa hoàn thành. Sau khi hoàn thành công việc khác, bạn có thể áp dụng lại các thay đổi đã lưu trữ một cách dễ dàng.
Cách thức hoạt động của Git Stash
Lưu trữ các thay đổi: Khi bạn chạy lệnh git stash, Git sẽ lưu lại tất cả các thay đổi trong working directory và index (staging area) vào một khu vực lưu trữ tạm thời gọi là stash stack. Working directory và index của bạn sẽ trở về trạng thái của commit cuối cùng.
Quản lý các thay đổi: Bạn có thể lưu nhiều mục stash khác nhau, mỗi mục được lưu trong một stack. Các mục này có thể được áp dụng lại, xóa hoặc quản lý theo nhu cầu của bạn.
Áp dụng lại các thay đổi: Khi bạn cần áp dụng lại các thay đổi đã lưu trữ, bạn có thể sử dụng các lệnh như git stash apply hoặc git stash pop.
>> Xem thêm: Tổng hợp kiến thức về Git cho người mới bắt đầu
Các lệnh cơ bản của Git Stash
Git stash
git stash là lệnh cơ bản nhất khi sử dụng Git stash, nó giúp lưu trữ các thay đổi hiện tại trong working directory và index vào stash.
Git stash save – Lưu lại thay đổi
Git stash được sử dụng khi muốn lưu lại các thay đổi chưa commit, thường rất hữu dụng khi bạn muốn đổi sang 1 branch khác mà lại đang làm dở ở branch hiện tại.
Muốn lưu toàn bộ nội dung công việc đang làm dở, bạn có thể sử dụng git stash như sau
$ git stash save # or just "git stash"
Khi này branch đã trở nên “sạch sẽ” và git status sẽ cho thấy bạn có thể chuyển sang branch tuỳ thích. Bạn có thể git stashbao nhiêu lần tuỳ thích và mỗi lần đó git sẽ lưu toàn bộ lần thay đổi đó như 1 phần tử trong 1 stack.
Sau khi đã git stash 1 hoặc vài lần, bạn có thể xem lại danh sách các lần lưu thay đổi bằng câu lệnh
$ git stash list
stash@{0}: WIP on :
stash@{1}: WIP on :
stash@{2}: WIP on :
Nếu muốn xem cả nội dung của từng thay đổi thì thêm option -p
$ git stash list -p
hoặc xem nội dung cụ thể hơn nữa của lần thay đổi thứ 1:
$ git stash show stash@{1}
Khi muốn apply lại thay đổi từ stash lần 1 bạn có thể
$ git stash apply stash@{1}
Git stash apply
Lệnh này sẽ chiếm phần trên cùng trong stack và apply nó vào repo. Trong trường hợp này là stash@{0}
Nếu bạn muốn áp dụng một số stash khác, bạn có thể chỉ định stash id.
Đây là một ví dụ:
git stash apply stash@{1}
Git stash pop
Lệnh này rất giống với stash apply nhưng nó xóa stash từ stack sau khi nó được áp dụng.
Câu lệnh:
# Giả sử bạn đã lưu trữ các thay đổi
git stash
# Bây giờ bạn muốn áp dụng các thay đổi đó và xóa stash khỏi danh sách
git stash pop
Nếu bạn muốn một stash cụ thể để “pop”, bạn có thể chỉ định stash id.
git stash pop stash@{1}
Git stash show
Lệnh này chỉ ra bản tóm tắt của các stash diff. Lệnh trên chỉ xem xét về stash mới nhất.
Câu lệnh:
# Giả sử bạn đã stash một số thay đổi
git stash
# Bạn có thể xem các thay đổi trong stash gần nhất
git stash show
# Bạn cũng có thể chỉ định stash id để có được tóm tắt diff.
git stash show stash@{0}
Nếu bạn muốn xem full diff, bạn có thể sử dụng
git stash show -p
Git stash branch <name>
Lệnh này tạo ra một nhánh mới với một stash hiện thời, và sau đó xóa các stash mới nhất (như stash pop).
Nếu bạn cần một stash cụ thể bạn có thể chỉ định stash id.
git stash branch <name> stash@{1}
Điều này thật sự hữu ích khi bạn gặp rắc rối sau khi đã áp dụng stash vào phiên bản mới nhất của chi nhánh.
Git stash clear
Lệnh này xóa tất cả các stash được tạo ra trong repo này và có thể không thể revert.
# Xóa tất cả các stash đã lưu trữ
git stash clear
Git stash drop
Lệnh này sẽ xoá stash mới nhất khỏi stack, nhưng hãy dùng nó cẩn thận, có thể sẽ khó để revert.
Bạn cũng có thể chỉ định stash id.
git stash drop stash@{1}
Sau khi tìm hiểu toàn bộ nội dung về Git Stash, ta có thể thấy Git Stash giúp bạn duy trì một luồng làm việc có tổ chức, dễ theo dõi và kiểm soát, đặc biệt hữu ích trong các dự án lớn và phức tạp.
Làm thế nào để quản lý sự phụ thuộc của code thông qua việc giảm đi tính trừu tượng?
Tác giả: Kealan Parr
Sự phụ thuộc là một phần rất phổ biến của bất kỳ cơ sở code tốt nào. Và điều quan trọng là phải xử lý rõ ràng mọi vấn đề trong code của bên thứ ba mà chương trình của bạn dựa vào để hoạt động.
Có nhiều cách để nhận và cập nhật code của bên thứ ba. Và tôi đã đọc một cái gì đó gần đây mà nó dễ dàng trở thành cách yêu thích của tôi để làm điều này, vì vậy tôi đã phải chia sẻ nó.
Tính trừu tượng
Các nhà phát triển thường sử dụng sự trừu tượng của code để đơn giản hóa một hệ thống. Trừu tượng là một cách ẩn code phức tạp bên trong một cái gì đó và chúng thường cung cấp một giao diện dễ sử dụng.
Về cơ bản, chúng tôi không buộc người sử dụng code phải lo lắng về các chi tiết triển khai. Họ chỉ có thể gọi hàm và sẽ nhận được câu trả lời của họ – họ không phải lo lắng về những gì hàm đang làm “chui”.
Đó là điểm mạnh của việc trừu tượng hóa các chi tiết trong code của bạn. Bạn có thể trừu tượng hóa mọi thứ trong vô số cấu trúc dữ liệu hoặc cấu trúc code. Và bạn có thể trừu tượng hóa các chi tiết triển khai bên trong một nguyên mẫu, lớp, hàm hoặc hơn thế nữa.
Nếu bạn phải hiểu từng dòng code trong một danh sách dữ liệu code quá lớn (giả sử cơ sở code có 2 triệu dòng) thì bạn sẽ không bao giờ có thể bắt đầu viết code được. Bạn có thể tạo một bộ code có thể sử dụng lại, đơn giản để hiểu và dễ dàng thay đổi bằng cách trừu tượng hóa các chi tiết nhất định thành các mô-đun chính xác / tách code của bạn ra.
Shimming là hành động đặt một thứ gì đó trước thứ khác để chặn dữ liệu đang được truyền qua.
Hãy xem một ví dụ về cách nó hoạt động.
Giả sử một ngân hàng có API thực sự cũ không chấp nhận JSON do một số lỗi kỹ thuật kế thừa. Thay vào đó, nó chỉ có thể chấp nhận XML. Chúng tôi sẽ gọi đây là LegacyAPI .
Nhưng rất nhiều devs muốn sử dụng API ngân hàng này muốn gửi JSON. Ngân hàng từ chối thay đổi LegacyAPI vì nó quá rủi ro và có thể phá vỡ API. Vì vậy, phần lớn hệ thống của họ phụ thuộc vào nó, và họ không thể mạo hiểm thực hiện nhiều phát triển mới và gỡ bỏ những phần lớn của hệ thống nếu họ mắc lỗi.
Họ luôn luôn có thể Shim LegacyAPI nếu họ không muốn làm phát triển mới trên nó. Họ có thể làm điều này bằng cách tạo một API nằm “trước” LegacyAPI. Chúng tôi sẽ gọi nó là NewAPI .
Từ “phía trước” chỉ có nghĩa là thứ tự của người đầu tiên xử lý yêu cầu mạng. Bởi “phía trước”, chúng tôi có nghĩa là NewAPI sẽ là người đầu tiên nhận được các yêu cầu mạng.
Bạn sẽ nói với các nhà phát triển rằng bây giờ họ có thể nhấn NewAPI với JSON như họ muốn và NewAPI sẽ biến JSON thành XML cho LegacyAPI và cả hai bên đều có thể hài lòng.
Ngân hàng hiện có thể mở rộng dịch vụ của họ (ví dụ: họ có thể chấp nhận JSON) thông qua NewAPI mà không cần thay đổi API kế thừa cũ mà họ đã cảnh giác khi thay đổi.
Đây chỉ là một ví dụ của việc shimming. Và chỉ để xem lại, về cơ bản nó là thêm một cái gì đó vào phía trước một cái gì đó khác để hoạt động như một người đàn ông ở giữa để truyền dữ liệu cho một thứ khác.
Bất cứ khi nào chúng tôi cần quản lý các phần phụ thuộc, cần đảm bảo rằng chúng tôi ngăn code của bên thứ ba “rò rỉ” trên toàn bộ code chính của chúng tôi. Leaking đồng nghĩa với việc code phụ thuộc được nhập nhiều lần đến những nơi khác nhau cần nó trong code của bạn.
Nếu bạn để một phần phụ thuộc “xâm chiếm” source code, nghĩa là bạn đang ngày càng trở nên gắn bó chặt chẽ với nó hơn. Điều này có thể (đôi khi!) Có nghĩa là bạn sẽ bị buộc phải viết mã theo hướng mà thư viện lựa chọn khi bạn kết hợp chặt chẽ với nó. Dẫn đến chi phí nhận thức đáng kể khi bạn ngày càng cố gắng làm cho thư viện này hoạt động trong code của bạn, nhưng nó không phù hợp với phần còn lại của các quyết định kiến trúc của bạn.
Điều này có thể làm cho bất kỳ quá trình tái cấu trúc nào bạn cần thực hiện mất nhiều thời gian hơn so với việc tách biệt nó. Ví dụ, nếu phụ thuộc thay đổi, nó sẽ cần phải chấp nhận những đối số nào để tạo một đối tượng trong phụ thuộc?
Ngoài việc khó giữ cho bản dựng hoạt động tốt với phần phụ thuộc, nếu nó không còn phù hợp với nhu cầu hoặc bạn tìm thấy một thư viện tốt hơn để thay thế nó, thì việc tái cấu trúc của bạn trở nên khó khăn hơn nhiều để thực sự loại bỏ nó.
Để thử và ngăn chặn tất cả những điều trên xảy ra, trước tiên, hãy đặt bất kỳ phụ thuộc nào chúng ta cần vào các mô-đun của riêng chúng, nơi chúng chỉ được tham chiếu một lần trong codebase của bạn.
Đây thực chất chính là shim. Bất cứ khi nào cần sự phụ thuộc của bên thứ ba, bạn chỉ cần nhập mô-đun trình bao bọc mà chúng tôi đặt xung quanh nó, để nó cung cấp một cấp độ trước khi chúng tôi gọi vào phần phụ thuộc bên thứ ba của mình.
Shim cho phép chúng tôi làm cho các biến phụ thuộc trở nên trừu tượng. Các nhà phát triển có nhu cầu sử dụng phụ thuộc bên thứ ba chỉ có thể sử dụng một assumption. Bạn sẽ đặt các đối số thành giá trị mặc định hợp lý và cố gắng loại bỏ càng nhiều chi tiết triển khai phức tạp càng tốt.
Bất kỳ nơi nào khác cần sự phụ thuộc này sẽ chỉ tải module và sau đó có thể được đưa vào khi cần thiết. Một lý do lớn mà chúng ta đã thảo luận là nó ngăn sự phụ thuộc của bạn và mã của bạn không bị kết hợp quá chặt chẽ với nhau.
Điều này hoạt động khi bạn chỉ có nó trong một module duy nhất. Sau đó, bạn chỉ phải thay đổi một module cho nhiều nơi khác để có quyền truy cập vào thứ gì đó. Điều này cho phép chúng tôi thực hiện các thay đổi dễ dàng hơn nhiều và giữ cho sự tách biệt rõ ràng về các mối quan tâm trong code.
Ở đây chúng tôi chỉ nói về một sự phụ thuộc – nhưng bạn có thể thấy điều này có thể tồi tệ hơn thế nào nếu chẳng hạn như bạn đang dựa vào 25 thư viện tùy chỉnh khác và bạn cần hiểu cách chúng hoạt động. Đây thường sẽ là một cơ sở code khá mỏng manh.
Hi vọng bài viết này sẽ mang đến cho bạn một cái nhìn tổng quan hơn về các vấn đề liên quan đến shimming và duy trì sự phụ thuộc.
Bài viết được sự cho phép của tác giả Kien Dang Chung
1. PSR là gì?
PSR viết tắt của cụm từ PHP Standard Recommendation là các tiêu chuẩn viết code trong ngôn ngữ PHP được đưa ra bởi tổ chức PHP-FIG (PHP Framework Interop Group).
PSR có rất nhiều các tiêu chuẩn khác nhau từ PSR-0 đến PSR-19, mỗi tài liệu đặc tả về những tiêu chuẩn viết code khác nhau cho những công việc khác nhau trong lập trình PHP. Thiết lập tiêu chuẩn viết code là rất quan trọng trong lập trình theo nhóm, nó giúp code dễ đọc, dễ phát hiện sai sót khi kiểm tra bởi các thành viên khác nhau trong nhóm.
Tiêu chuẩn viết mã trong PHP là rất khác nhau giữa các framework và ngay cả các phiên bản PHP khác nhau, ví dụ tên phương thức có thể viết theo nhiều kiểu khác nhau như camelCase, snake_case… hoặc một ví dụ khác về cách thức sử dụng các thư viện PHP ngoài bằng cách sử dụng include thuần túy hoặc sử dụng tiêu chuẩn autoload.
Chính vì vậy, PSR được hiệp hội phát triển framework ngồi lại và đưa ra các tiêu chuẩn chung cho viết code PHP. Trong viết code PHP có 4 tiêu chuẩn thường thấy nhất là PSR-0, PSR-1, PSR-2 và PSR-4, chúng ta cùng xem chúng là những tiêu chuẩn gì? PSR-0 và PSR-4 là tiêu chuẩn về đặt tên namespace và cách load các thư viện PHP tự động. Từ tháng 10 năm 2014, tiêu chuẩn PSR-0 không còn được dùng nữa và khuyến cáo chuyển sang PSR-4. PSR-1 và PSR-2 là các tiêu chuẩn cơ bản về viết mã nguồn và hiện PSR-2 được coi là tiêu chuẩn phổ biến cho “phong cách” viết code.
2. Autoloading là gì?
Composer là một công cụ tuyệt vời cho các lập trình viên PHP, nó giúp cho việc quản lý các gói thư viện dễ dàng. Trong bài viết này chúng ta không đi sâu vào composer mà chỉ tìm hiểu cách thức composer quản lý sự phụ thuộc giữa các gói thư viện thông qua autoloading. Vậy autoloading là gì? Vấn đề: Khi chúng ta viết một ứng dụng cho sử dụng một danh sách dài các thư viện, ở mỗi file code PHP chúng ta phải thực hiện include chúng vào những đoạn nào có gọi đến các class này, nếu danh sách này dài hàng vài chục dòng thì quả là vấn đề. Giải pháp: include tất cả các class này ở phần đầu mỗi file PHP. Giải pháp tốt hơn: Ở những đâu cần gọi đến các class này, thực hiện tải chúng ở thời điểm đó, như vậy ứng dụng không cần tải tất cả các class trong các thư viện cho tất cả các file PHP và chi tiết hơn là các phiên làm việc. Cách thức tải và sử dụng các class như vậy gọi là autoloading.
Để hiểu rõ cơ chế autoloading, chúng ta sẽ cùng nhau thử tạo ra một autoloader riêng. Bắt đầu bằng một ví dụ mà chúng ta thường viết kiểu này trước đây: Chúng ta có hai Class A và B ở hai file khác nhau A.php và B.php
<?php
// Classes/A.php
classA{}
và
<?php
// Classes/B.php
classB{}
Trong một file PHP chúng ta muốn gọi đến các Class A và B thì chúng ta phải thực hiện include các class này vào:
<?php
// index.php
include_once'Classes/A.php';include_once'Classes/B.php';
// load A class
$a=newA();
// check the list of all loaded files
var_dump(get_included_files());
Như vậy, toàn bộ các class được include vào index.php. Nếu chúng ta chỉ có 2 Class A và B thì không có vấn đề gì cả, khi số lượng class lên đến hàng 100 thậm chí hàng 1000, những ứng dụng hiện đại sử dụng các gói thư viện ngoài có khi lên đến cả triệu class thì cách thức viết code như vậy sẽ không thể thực hiện được, chúng ta cần đến autoloader. Cùng xem cách thức autoloading thực hiện bởi autoloader đơn giản sau:
<?php
// index.php
functionmy_autoloader($class){include'Classes/'.$class.'.php';}
// register the autoloader
spl_autoload_register('my_autoloader');
// load A class
$b=newA();
// check the list of all loaded files
var_dump(get_included_files());
Như vậy trong function my_autoloader() chúng ta đã thực hiện việc ánh xạ giữa tên class và đường dẫn đến class để thực hiện include class này. Kết quả như sau:
Composer làm việc với một file thiết lập có định dạng json là composer.json được thêm vào trong thư mục gốc của dự án. Thực hiện tạo ra bằng lệnh composer init hoặc có thể tạo một file text và đặt tên là composer.json. Trong ví dụ này khá đơn giản không có thiết lập gì nên chúng ta đưa vào nội dung { } là bao của nội dung json. Tiếp đến, thực hiện lệnh composer install, nó sẽ tạo ra thư mục vendor chứa các gói thư viện ngoài mà bạn muốn sử dụng và file autoload.php.
Thay đổi nội dung file composer.json để composer sẽ tự động tạo lại file autoload.php. Có 4 cách autoloading trong composer là:
File base autoloading
Classmap Based Autoloading
PSR-0 Autoloading
PSR-4 Autoloading
Trong bài viết này chúng ta sẽ sử dụng PSR-4 Autoloading, thay đổi nội dung composer.json như sau:
{"autoload":{"psr-4":{"Classes\\":"Classes"}}}
Để composer tự động tạo ra file autoload thực hiện lệnh composer dump-autoload. Khi đó mở file vendor/composer/autoload_psr4.php chúng ta thấy composer đã tự động sinh code autoloading
<?php
// autoload_psr4.php @generated by Composer
$vendorDir=dirname(dirname(__FILE__));$baseDir=dirname($vendorDir);returnarray('Classes\\'=>array($baseDir.'/Classes'),);
Để sử dụng autoloader này trong file index.php chúng ta thực hiện include mỗi autoloader này vào:
Ở đây chúng ta thấy ứng dụng load cả các file của composer tuy nhiên khi số lượng class tăng lên hàng trăm, hàng nghìn thì autoloader thật sự mới phát huy tác dụng.
5. Lời kết
Qua bài viết chúng ta hiểu thêm về khái niệm các tiêu chuẩn lập trình trong PHP như PSR-0, PSR-4, khái niệm autoloading và được thực hành PSR-4 autoloading với công cụ Composer. Những kiến thức cơ bản này sẽ đi cùng bạn trong suốt quá trình làm việc với các framework viết bằng PHP nói chung và framework Laravel nói riêng.
Apache ActiveMQ™ là một server JMS (Java Message Service) dựa trên Java, đa giao thức, mã nguồn mở phổ biến nhất. Tích hợp các ứng dụng đa nền tảng bằng giao thức AMQP phổ biến. Trao đổi tin nhắn giữa các ứng dụng web của bạn bằng STOMP qua websockets. Quản lý thiết bị IoT của bạn bằng MQTT. ActiveMQ cung cấp sức mạnh và tính linh hoạt để hỗ trợ mọi trường hợp sử dụng hệ thống tin nhắn.
Nhiều ngôn ngữ khác nhau: Java, C#, C, C++, Python, NodeJs, Go, …
Nhiều giao thức khác nhau: AMQP, MQTT, REST, RSS and Atom, …
Ngoài việc có thể sử dụng được trong nền tảng Java SE độc lập, có thể sử dụng được trong nhiều loại Container: J2EE, JBoss, Glassfish, JNDI, Tomcat, WebLogic, Spring, OSGi, …
Clustering: Queue consumer cluster, Broker cluster, Discovery of broker, Networks of broker, Master Slave, Replicated Message Stores.
Còn rất nhiều tính năng khác, các bạn tham khảo thêm trên ActiveMQ document.
Hãy lựa chọn phiên bản phù hợp với hệ điều hành của các bạn. Ở đây mình đang sử dụng hệ điều hành macOS, do đó mình sẽ download tập tin apache-activemq-5.15.12-bin.tar.gz dành cho macOS.
Sau khi download, các bạn cần giải nén nó ra:
Mở thư mục bin của thư mục Apache ActiveMQ, mở command line lên và nhập dòng lệnh sau: ./activemq start . Để stop Apache ActiveMQ server này, các bạn cũng vào thư mục bin của Apache ActiveMQ rồi chạy câu lệnh sau: ./activemq stop
Tương tự nếu bạn sử dụng Window, để start cần chạy file activemq.bat
Sau khi khởi động Apache ActiveMQ chúng ta có thể theo dõi và quản lý Apache ActiveMQ từ giao diện web ở cổng 8161. Các bạn có thể truy cập vào trang này bằng URL sau: http://localhost:8161/admin với username và password là admin/admin:
Chúng ta có thể xem thông tin Queues, Topics, Subscribers, Connections, … trên các menu tương ứng.
Bây giờ, chọn menu Queues và tạo tạo một Queue có tên là: jms/gpcoder-queue
Chọn menu Topics và tạo một Topic có tên là: jms/gpcoder-topic
Sau đó, chọn menu Send và nhập thông tin Message để send tới Queue:
Destination: jms/gpcoder-queue
Queue or Topic: Queue
Message body: Welcome to ActiveMQ world
Chọn Send
Chọn menu Queues, chúng ta có kết quả sau:
Tương tự, send một message đến Topic, chúng ta có kết quả sau:
Bài viết được sự cho phép của tác giả Trần Anh Tuấn
Trước đây khi chúng ta thiết kế web đặc biệt là dàn trang layout, menu, chia các cột cho các thành phần trong web thì hầu hết đều sử dụng các thuộc tính như float kèm theo đó là clear float để chia cột . Khó khăn là khi responsive và hiển thị trên nhiều thiết bị phải chỉnh sửa code khá nhiều nên rất tốn thời gian.
Hoặc nhanh hơn thì các bạn sử dụng CSS Framework như bootstrap chẳng hạn, nhưng như thế thì website của bạn lại có nhiều đoạn code ‘dư thừa’ bạn không sử dụng gây ảnh hưởng đến tốc độ website…
Thế là Flexbox được sinh ra để cải thiện tình hình này, giúp cho việc dàn trang, canh các thành phần với nhau linh hoạt, dễ dàng và tiết kiệm thời gian hơn rất nhiều.
Hôm nay mình viết bài này để chúng ta cùng tìm hiểu về sức mạnh của CSS Flexbox để xem cách sử dụng nó như thế nào, nó có những thuộc tính hay gì mà nhiều người lại sử dụng nó thay cho float hay inline thế nhỉ ?
Roài giờ đây mình sẽ đi vào chi tiết từng thuộc tính khác của CSS Flexbox kèm theo hình minh họa để cho các bạn dễ hình dung nha. Mình sẽ giải thích từng thuộc tính một cho các bạn kèm hình minh họa cho các bạn dễ hiểu. Nếu không hiểu thì bình luận ở dưới mình sẽ trả lời thắc mắc của các bạn. À 1 lưu ý nhỏ:
DÀNH CHO BẠN:
Mình có khoá học HTML CSS từ cơ bản tới nâng cao cho người mới, nếu bạn quan tâm thì bạn có thể học thử miễn phí bằng việc nhấn vào đây nha.
Các bạn nhớ check code ở Codepen. Và mình khuyên thêm đó là nên code theo để hiểu nó hoạt động như thế nào, ra sao nhé chớ đọc nhiều rồi gật gù đúng đúng mà không làm thì cũng công cốc.
# Flex-direction
Như tên gọi của nó là hướng(trục), thì trong flexbox có 2 trục chính đó là trục X và trục Y giống như biểu đồ toán học đó các bạn. Lưu ý là flexbox chỉ hiển thị theo 1 trong 2 hướng thôi nha, chứ không hiển thị 1 lần 2 hướng như CSS Grid được(Sau này mình sẽ viết bài này sau).
Mặc định thì những items trong flexbox được sắp xếp theo trục X và từ trái qua phải. Đó là lý do vì sao khi mình dùng display: flex ở ví dụ ở trên đầu thì các items được sắp xếp thành hàng ngang và hiển thị từ trái qua phải.
Trong flex-direction có 4 giá trị bao gồm: row, row-reverse, column và column reverse.Các bạn nên mở Codepen mình chèn ở trên lên rồi chèn từng thuộc tính vào thử xem có giống hình mình minh họa không nhé.
flex-direction: rowlà giá trị mặc định trong flex-direction các items sẽ được sắp xếp theo chiều ngang(trục X) và hiển thị từ trái sang phải.
flex-direction: row-reverse cũng giống như thuộc tính flex-direction: row nhưng những items sẽ được hiển thị từ phải qua trái
flex-direction: column các items được sắp xếp chiều dọc(trục Y) và hiển thị từ trên xuống dưới
flex-direction: column-reverse cũng giống với thuộc tính flex-direction: column là các items được sắp xếp chiều dọc(trục Y) nhưng khác ở chỗ là các items hiển thị từ dưới lên trên
# Flex-wrap
Các bạn nhớ resize trình duyệt ở những demo codepen ở dưới đây để thấy sự khác nhau nha.
Cho phép các items tự động xuống hàng hoặc vẫn luôn nằm trên cùng một hàng khi kích thước container thay đổi. Hơi khó hiểu nhỉ, xem demo dưới đây nha.
Flex-wrap có 3 giá trị đó là wrap, nowrap và wrap-reverse.
Mặc định là nowrap nên các bạn không cần phải set. Khi chúng ta resize trình duyệt lại nếu các bạn sử dụng thuộc tính flex-wrap: nowrap thì các items sẽ tự động co lại cho chớ không có rớt xuống hàng, điều này dễ làm cho content bên trong(nếu có) bị ép lại có thể gây xấu giao diện.
flex-wrap: wrap ngược lại so với flex-wrap: nowrap khi kích thước container thay đổi và tổng chiều rộng các items cộng lại lớn hơn chiều rộng của container bọc ngoài thì nó sẽ rớt xuống.
Ví dụ như ở demo Codepen. Có 3 items mỗi item 150px, độ rộng(width) của container là 100% là khung hiển thị ở codepen. Khi chúng ta resize trình duyệt thì khung container nó cũng nhỏ theo, khi chạm qua item số 3 màu xanh lá 1 chút thì item sẽ tự động rớt xuống.
Cuối cùng là flex-wrap: wrap-reverse cũng tương tự như flex-wrap: wrap nhưng nó ngược lại thay vì item rớt xuống thì nó rớt lên. Resize trình duyệt phát hiểu ngay.
Lâu lâu các bạn có thấy một số người dùng thuộc tính flex-flow: row wrap. Thuộc tính này viết để gộp 2 thuộc tính flex-direction và flex-wrap lại nhé các bạn. Nó như thế này flex-flow: flex-direction flex-wrap. Ứng với flex-direction và flex-wrap các bạn thay giá trị tương ứng vào nhé.
# Tạm kết
Do bài này dài và mình cũng muốn giải thích chi tiết cho các bạn. Nên mình chia bài về flexbox này thành 5 phần(4 phần lý thuyết và 1 phần thực hành) cho các bạn dễ theo dõi và đỡ ngán khi đọc do dài quá.
Bài tiếp theo mình sẽ nói đến 4 thuộc tính khác đó là justify-content, align-items, align-self và order các bạn nhớ đón đọc nha. Nếu có ý kiến hay góp ý hoặc không hiểu thì bình luận bên dưới mình sẽ trả lời. Chúc các bạn một ngày tốt lành.
Theo như cấu hình trên thì server sẽ thực hiện mã hóa ssl khi truy cập qua cổng 443, ssl certificate được sử dụng là file cert.pem và cert.key (nằm cùng folder với file nginx.conf)
Ngoài ra bạn cũng có thể trỏ ssl certificate tới địa chỉ trên mạng, ví dụ:
Bài viết được sự cho phép của BQT Kinh nghiệm lập trình
Bài viết hôm nay mình sẽ chia sẻ cách fix lỗi “RDP Authentication Error Has Occurred – The Function Requested Is Not Supported” khi remote tới Windows Server. Một ngày đẹp trời, tự nhiên bạn không thể remote tới Server như bao ngày. Màn hình xuất hiện thông báo như sau:
Remote Desktop Connection
An authentication error has occurred.
The function requested is not supported.
Remote computer: computer_name
Nguyên nhân gây ra lỗi trên?
Thực tế là các bản cập nhật bảo mật mới nhất (được phát hành sau tháng 5 năm 2018) được cài đặt trên máy tính của bạn. Các bản cập nhật này khắc phục lỗ hổng nghiêm trọng trong giao thức CredSSP (Nhà cung cấp hỗ trợ bảo mật thông tin xác thực) được sử dụng để xác thực trên các máy chủ RDP (CVE-2018-0886 –RDP authentication error: CredSSP Encryption Oracle Remediation). Các bản cập nhật này không được cài đặt ở phía máy chủ RDP / RDS của bạn và NLA (Network Level Authentication) được bật để có thể remote vào server.
NLA sử dụng các cơ chế CredSSP để xác thực trước người dùng RDP qua TLS / SSL hoặc Kerberos. Máy tính của bạn chỉ cần chặn kết nối máy tính từ xa đến một máy chủ sử dụng phiên bản bảo mật kém của CredSSP.
Cách fix?
Có những cách fix sau đây:
Cách chuẩn xác nhất và tốt nhất bạn cần thực hiện là cài đặt “Windows security updates” trên server của bạn.
Cách 2: Tắt NLA (Network Level Authentication) trên server của bạn.
Làm thế nào để vô hiệu hóa NLA trên Windows Server
Nếu NLA được bật trên máy chủ RDP của bạn, điều này có nghĩa là CredSSP được sử dụng cho người dùng RDP xác thực trước. Bạn có thể tắt Network Level Authentication (NLA) trong System Properties trên tab Remote bằng cách bỏ chọn các điều kiện. Chỉ cho phép kết nối từ các máy tính chạy Remote Desktop với Network Level Authentication (khuyên dùng) (Windows 10 /8.1 hoặc Windows Server 2012R2 / 2016).
Done! Các bạn cùng thử remote lại xem sao nhé. Hi vọng các bạn thành công!
Nếu anh em học và làm về lập trình thì chắc đã từng ít nhiều nghe về khái niệm “Clean Code” rồi phải không nhỉ. Nhưng mình tin chắc là số lượng anh em hiểu rõ về “clean code” là không nhiều.
Vậy tại sao phải “clean code” trong lập trình? nếu anh em đã từng thắc mắc như vậy thì hãy để mình giải thích kỹ hơn cho anh em trong bài viết ngày hôm nay nhé.
Nhưng trong khuôn khổ của bài viết này, mình sẽ chỉ đề cập đến các lý do để anh em nên viết code sao cho sạch, sao cho đẹp, gọn gàng… chứ không nói về cách làm như thế nào nhé.
#1. “Clean code” là gì?
Trước khi trả lời cho câu hỏi tại sao thì chúng ta cần phải hiểu như thế nào là clean code trước, vì chỉ khi hiểu được khái niệm thì chúng ta mới biết tại sao nó quan trọng.
Clean code nếu dịch ra thì có nghĩa là “mã nguồn sạch”, nhưng hiểu một cách đơn giản thì clean code bao gồm: cách tổ chức mã nguồn, cách triển khai mã nguồn sao cho khoa học, dễ hiểu và đem lại hiệu năng cao cho chương trình.
Việc áp dụng clean code không khó, nhưng áp dụng làm sao cho đúng và chuẩn thì lại là một câu chuyện khác. Chính vì vậy mà việc nắm được, hiểu và biết cách áp dụng clean code sẽ khiến cho mã nguồn tốt hơn rất nhiều.
#2. “Clean code” giúp code dễ bảo trì hơn
Bảo trì gần như là khâu bắt buộc của rất nhiều sản phẩm phần mềm nói riêng và sản phẩm kỹ thuật nói chung.
Nếu trong quá trình phát triển phần mềm chúng ta làm không tốt thì khâu bảo trì sẽ gặp rất nhiều khó khăn và tốn kém.
Và một trong những điều quan trọng mà đội ngũ phát triển có thể làm đó là đảm bảo chất lượng source code ngay từ đầu.
Để làm được điều này không phải không phải là dễ, vì bản chất của dự án là sẽ nhiều người làm cùng nhau. Nếu không có một quy chuẩn chung thì chắc chắn có người code hay có người code dở.
Khi bảo trì code, nếu người trước biết clean code thì người sau vào làm sẽ dễ dàng mở rộng chương trình, phát triển thêm tính năng mà không phải sửa đổi mã nguồn cũ.
Ngược lại, nếu không clean code thì sau này bảo trì và phát triển lên sẽ rất khó trong việc mở rộng mã nguồn. Thậm chí, trường hợp tệ nhất có khi còn phải đập đi xây lại toàn bộ nữa, gây lãng phí nguồn lực.
#3. “Clean code” giúp người khác đọc code dễ hơn
Như mình đã nói bên trên, bình thường thì một dự án sẽ do nhiều người cùng làm với nhau, chứ không phải chỉ có một người làm (thực tế thì cũng có, nhưng rất ít).
Vậy một bài toán đặt ra là mỗi ông code một kiểu thì làm sao để đọc code của nhau mà vẫn hiểu được người kia đang viết gì?
Mình đã từng trong hoàn cảnh này nên mình rất hiểu cái cảm giác “ức chế” khi phải đọc những dòng “xấu, bẩn, cẩu thả” của người khác.
Nếu một lập trình viên biết clean code thì họ sẽ không bao giờ viết code để cho mỗi mình anh ta đọc hiểu. Họ sẽ luôn nghĩ đến việc làm sao viết code để cả người khác khi đọc vẫn có thể hiểu được.
Tất nhiên, để làm được điều đó không phải là dễ, vì bản chất mỗi người sẽ có một phong cách lập trình trình khác nhau. Nhưng bạn phải chấp nhận thôi, muốn trở nên chuyên nghiệp bạn buộc phải nắm được những quy tắc chung.
Tham khảo thêm các vị trí tuyển dụng ngành Code hot từ các công ty:
#4. “Clean code” thể hiện trình độ của lập trình viên
Tại sao clean code lại thể hiện trình độ của lập trình viên?
Thực ra, để đánh giá thì trình độ của một lập trình viên sẽ phải dựa trên rất nhiều khía cạnh khác nhau.
Nhưng nếu gói gọn lại trong khía cạnh kỹ thuật thì việc nắm được, hiểu được và áp dụng được clean code sẽ thể hiện phần nào trình độ kỹ thuật của một lập trình viên.
Đôi khi clean code còn thể hiện kinh nghiệm của một lập trình viên ra sao. Việc code nhiều, gặp nhiều lỗi sẽ giúp họ tích lũy kinh nghiệm theo năm tháng.
Và họ biết khi gặp một vấn đề, họ nên bắt đầu từ đâu và xử lý nó như thế nào cho hợp lý nhất.
Ngoài ra, việc làm qua nhiều dự án, tiếp xúc với nhiều loại mã nguồn (được viết bằng nhiều ngôn ngữ lập trình khác nhau) thì lập trình viên cũng “lĩnh ngộ” được nhiều cách tổ chức, triển khai mã nguồn.
Từ đó đúc rút ra những kinh nghiệm riêng để hoàn thiện và nâng cao khả năng kỹ thuật của mình (bạn có thể nhận thấy rõ khi làm việc với những DEV Lead từng làm nhiều dự án)
#5. “Clean code” giúp mọi người hình thành một quy tắc chung
“Quy tắc” gần như là điều bắt buộc nếu một doanh nghiệp muốn trở nên chuyên nghiệp, uy tín hơn.
Đối với các công ty phần mềm thì điều này càng chính xác hơn, đặc biệt là trong khâu phát triển sản phẩm (xây dựng mã nguồn chương trình)
Nếu tất cả thành viên của dự án đều code theo một chuẩn chung thì dự án sẽ phát triển rất nhanh, ít xảy ra lỗi, dễ bảo trì sau này và chất lượng sản phẩm cũng tốt hơn.
Ngược lại, nếu đội ngũ phát triển làm việc không có quy tắc (thường xảy ra ở các công ty nhỏ, mới thành lập chưa có kinh nghiệm và quy trình) thì mình tin chắc sản phẩm thường có nhiều nhiều lỗi, hoạt động không ổn định và đặc biệt chất lượng mã nguồn (source code) cực kỳ thấp.
Thực tế là không phải lập trình viên nào trong cùng dự án cũng có khả năng tương đương nhau, nhưng chỉ cần có 1-2 người có kỹ năng clean code thì họ sẽ “uốn” cả team theo chuẩn.
#6. “Clean code” thể hiện sự chuyên nghiệp của đội ngũ phát triển
“Chuyên nghiệp” là mục tiêu mà bất kỳ doanh nghiệp nào đều muốn hướng đến, đặc biệt là các doanh nghiệp làm phần mềm.
Chuyên nghiệp ở đây phải là trên mọi khía cạnh: từ quản lý con người, phát triển sản phẩm cho đến việc marketing để bán sản phẩm…
Nếu xét riêng về khía cạnh kỹ thuật thì đội ngũ phát triển phần mềm được gọi là chuyên nghiệp khi nào?
Điều này rõ nhất là khi chúng ta nhìn vào mã nguồn (source code) của họ. Source code có theo chuẩn, có theo quy tắc chung không, hay mỗi ông code một kiểu chẳng theo quy chuẩn gì hết.
Tổ chức mã nguồn ra sao, cách quản lý mã nguồn đó như thế nào, có đảm bảo về an toàn thông tin không?
Nói chung là câu chuyện về “chuyên nghiệp hóa” đội ngũ phát triển phần mềm thực sự không phải là dễ.
Nó đòi hỏi sự chuyên nghiệp từ các bộ phận khác của doanh nghiệp, từ những con người trong chính đội ngũ đó cho đến những người trưởng nhóm, người lãnh đạo.
#7. Lời Kết
Okay, vậy là qua bài viết này thì mình tin là bạn đã hiểu hơn về khái niệm Clean code rồi đúng không? và lý do tại sao cần phải Clean code.
Clean code thực sự là một trong những kỹ năng quan trọng bậc nhất nếu bạn muốn trở thành một lập trình viên chuyên nghiệp.
Có hai cuốn sách rất hay về chủ đề này bạn có thể tham khảo đó là:
Clean Code: A Handbook of Agile Software Craftsmanship
The Clean Coder: A Code of Conduct for Professional Programmers: Nếu thích bạn có thể mua trên Tiki !
. Lúc đó hãy rebase hay merge branch của bạn và sẽ thấy conflict 2 cái có khác gì nhau!
