Categories
Dev's Corner

Các thuật toán tìm kiếm

Mục đích chính của thuật toán tìm kiếm là để kiểm tra một phần tử hoặc truy xuất nó từ bất kỳ cấu trúc dữ liệu nào. Các thuật toán tìm kiếm này được phân loại thành hai phần, thường là dựa trên kiểu tìm kiếm.

1. Tìm kiếm tuần tự (Sequential search)

Danh sách hoặc mảng được duyệt qua (traverse) tuần tự và mọi phần tử đều được kiểm tra. Ví dụ: Tìm kiếm tuyến tính

2. Tìm kiếm theo khoảng thời gian (Interval search)

Được thiết kế cho các cấu trúc dữ liệu được sắp xếp và hiệu quả hơn giải thuật tìm kiếm tuần tự vì giải thuật này liên tục nhắm đến trung tâm của cấu trúc dữ liệu và chia đôi không gian tìm kiếm. Ví dụ: Tìm kiếm nhị phân

Trong bài viết này, chúng ta sẽ thảo luận về hai thuật toán tìm kiếm: tìm kiếm tuyến tínhtìm kiếm nhị phân.

Tìm kiếm tuyến tính (Linear Search)

Tim kiếm tuyến tính (Linear search)
Tim kiếm tuyến tính (Linear search). Ảnh: GeeksforGeeks

Giải thuật này rất đơn giản, độ phức tạp là O(N). Một tìm kiếm tuần tự được thực hiện cho từng phần tử trong cấu trúc dữ liệu.

Nếu kết quả phù hợp được tìm thấy, nó sẽ được trả về; nếu không, quá trình tìm kiếm sẽ tiếp tục cho đến hết cấu trúc dữ liệu.

Cách tìm kiếm tuyến tính hoạt động

Giả sử ta muốn tìm giá trị x trong mảng A.

Cách tìm kiếm tuyến tính hoạt động
Cách tìm kiếm tuyến tính hoạt động

Pseudocode

Tìm kiếm tuyến tính - Pseudocode
Tìm kiếm tuyến tính – Pseudocode

Java code

Tìm kiếm tuyến tính - Java code
Tìm kiếm tuyến tính – Java code

Tìm kiếm nhị phân (Binary Search)

Tìm kiếm nhị phân - Binary search.Tìm kiếm nhị phân - Binary search.Tìm kiếm nhị phân - Binary search.
Tìm kiếm nhị phân – Binary search. Ảnh: GeeksforGeeks

Đây là một giải thuật tìm kiếm nhanh độ phức tạp là O(logN).

Giải thuật O(logN) được xem là có tính hiệu quả cao vì tỷ lệ giữa số lượng hoạt động so với kích thước của input giảm và có xu hướng bằng không khi N tăng lên. (N là kích thước input tính bằng đơn vị bit cần để đại diện cho input đó).

Việc thu thập dữ liệu phải ở dạng được sắp xếp để giải thuật này hoạt động chính xác.

Cách tìm kiếm nhị phân hoạt động

Tìm kiếm nhị phân tìm kiếm một phần tử cụ thể bằng cách so sánh với phần tử nằm ở ngay chính giữa của mảng.

Nếu kết quả tìm kiếm khớp, thì index của phần tử này sẽ được trả về. Nếu kết quả không khớp, nó sẽ kiểm tra xem phần tử ở giữa có lớn hơn item này hay không, sau đó nó sẽ tìm kiếm phần tử này trong mảng con bên trái của phần tử ở giữa.

Trường hợp phần tử ở giữa nhỏ hơn, nó sẽ tìm kiếm phần tử trong mảng con ở bên phải của phần tử ở giữa. Cho đến khi kích thước mảng con giảm xuống còn 0, quá trình này sẽ tiếp tục tại mảng con.

Để tìm kiếm nhị phân hoạt động, mảng phải được sắp xếp trước.

Giải thuật

Giả sử ta muốn tìm giá trị x trong mảng A đã sắp xếp.

Cách tìm kiếm nhị phân hoạt động
Cách tìm kiếm nhị phân hoạt động

Pseudocode

Tìm kiếm nhị phân - Pseudocode
Tìm kiếm nhị phân – Pseudocode

Java code

Tìm kiếm nhị phân - Jave code
Tìm kiếm nhị phân – Jave code

Đây là hai giải thuật tìm kiếm được sử dụng phổ biến nhất. Hãy cùng theo dõi các bài viết tiếp theo và thảo luận cùng Gambaru các giải thuật hữu ích khác.

Theo Pulsara Sandeepa

Categories
Dev's Corner

20 năm Tuyên ngôn Agile

Tháng 2 năm 2021 tròn đúng kỷ niệm 20 năm Tuyên ngôn phát triển Phần mềm Agile – một cuộc cách mạng trên thị trường phần mềm và có tầm ảnh hưởng trên nhiều ngành nghề.

Tuyên ngôn phát triển phần mềm Agile
Tuyên ngôn phát triển phần mềm Agile

Ngay cả khi bản tuyên ngôn không thay đổi, việc áp dụng cách hiểu của nó cũng khác nhau ở mỗi nơi.

Trong bài viết này, chúng ta sẽ xem xét khái niệm về Agile, những thực tiễn đã thay đổi theo thời gian và hướng đi của nó trong một thế giới đang thay đổi.

Tuyên ngôn Agile

Phát triển phần mềm theo Agile
Phát triển phần mềm theo Agile

Chúng tôi đã tìm ra được những cách thức phát triển phần mềm tốt hơn bằng cách thực hiện và giúp đỡ người khác áp dụng chúng. Qua đó, chúng tôi đánh giá cao:

  • Cá nhân và sự tương tác hơn là quy trình và công cụ
  • Phần mềm hoạt động tốt hơn là tài liệu đầy đủ
  • Sự cộng tác với khách hàng hơn là đàm phán hợp đồng
  • Phản hồi trước thay đổi hơn là bám sát kế hoạch.

Mặc dù những hạng mục bên phải có giá trị của chúng, chúng tôi vẫn đánh giá cao những hạng mục ở bên trái hơn.

12 Nguyên tắc Agile

12 nguyên tắc Agile.
12 nguyên tắc Agile. Ảnh: Unsplash
  1. Làm hài lòng khách hàng thông qua việc chuyển giao sớm và liên tục phần mềm có giá trị là ưu tiên cao nhất.
  2. Đón nhận những thay đổi trong yêu cầu, thậm chí thay đổi muộn trong quá trình phát triển. Các quy trình Agile khai thác những thay đổi vì lợi thế cạnh tranh của khách hàng.
  3. Thường xuyên chuyển giao phần mềm hoạt động tốt tới khách hàng, từ vài tuần đến vài tháng, khoảng thời gian càng ngắn càng tốt.
  4. Đội ngũ business và đội ngũ lập trình phải cùng làm việc hàng ngày xuyên suốt dự án.
  5. Xây dựng dự án với những cá nhân có động lực cao. Mang đến cho họ môi trường và sự hỗ trợ cần thiết, đồng thời tin tưởng họ có thể hoàn thành tốt công việc.
  6. Phương pháp hiệu quả nhất để truyền đạt thông tin là đối thoại trực tiếp.
  7. Phần mềm hoạt động tốt là thước đo chính của tiến độ dự án.
  8. Các quy trình Agile thúc đẩy phát triển bền vững. Các nhà đầu tư, lập trình viên, và người dùng nên luôn duy trì nhịp độ phát triển liên tục.
  9. Liên tục quan tâm đến các công nghệ và thiết kế tiên tiến để gia tăng tính linh hoạt.
  10. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa hoàn thành – là vô cùng quan trọng.
  11. Các kiến ​​trúc, yêu cầu, và thiết kế tốt nhất được tạo ra bởi các team tự quản.
  12. Theo định kỳ, đội ngũ phát triển cùng nghiệm lại cách làm việc hiệu quả hơn, sau đó sẽ điều chỉnh và thay đổi hành vi cho phù hợp.

Những thay đổi trong quy trình phát triển phần mềm Agile

Trong một thế giới đang thay đổi, kỳ vọng về phần mềm ngày càng tăng và lập trình viên độc lập nay đã được thay thế bằng nguyên một đội ngũ lập trình.

Giao tiếp và điều phối trong phát triển phần mềm ngày càng phức tạp
Giao tiếp và điều phối trong phát triển phần mềm ngày càng phức tạp, nên việc bám sát phương pháp truyền thống không còn là lựa chọn tối ưu. Ảnh: Burst

Trong bài “20 Jahre Agiles Manifest – Deftiv den Kinderschuhen entwachsen”, Jutta Eckstein (business coach, change manager) đưa ra danh sách những thay đổi về phát triển phần mềm theo Agile. Trích đoạn:

  • Nếu team đảm bảo rằng các story luôn có cùng size thì việc estimate từng story sẽ không cần thiết nữa.
  • Trong một thời gian dài, các story chỉ được công nhận nếu chúng tương ứng với format Connextra (“As a …, I want …, so …”). Thay vào đó, giờ đây, các story chỉ đóng vai trò như một loại ghi nhớ cho một cuộc hội thoại về nội dung của story (và không có format cho các bản ghi nhớ hội thoại).
  • Flow ngày càng trở nên quan trọng. Điều này bao gồm thực tế là các sprint hay iteration thường không còn đóng vai trò quan trọng nữa. Điều này có nghĩa là các team không lập kế hoạch hai tuần một lần, mà phối hợp hàng ngày theo Kanban những gì có thể hoàn thành và những gì được bổ sung sau từ backlog. Như vậy, việc lập kế hoạch, phản ánh và điều chỉnh có tính liên tục hơn.
  • Với sự gia tăng của tốc độ phát triển phần mềm, những trào lưu mới như DevOps đã góp phần tạo ra một cách nhìn tốt hơn về phát triển phần mềm trong một bối cảnh rộng hơn. Tuy nhiên, không phải lúc nào người ta cũng hiểu được ý tưởng cơ bản của DevOps. Ngày càng có nhiều công ty đặt đội ngũ DevOps bên cạnh đội ngũ phát triển hoặc đảm nhiệm vai trò kỹ sư DevOps. Họ bỏ qua thực tế rằng DevOps là một thái độ, một văn hóa chứ không phải một chức năng, vai trò hay nhiệm vụ đặc biệt.

Jutta Eckstein bổ sung rằng một vài phương pháp vốn là cơ sở của bản tuyên ngôn vẫn còn đóng một vai trò nhất định ở thời điểm hiện tại.

Ví dụ: crystal method (tập trung vào cá nhân và sự tương tác) hoặc phát triển phần mềm mang tính thích ứng.

Extreme Programming (XP) phát triển trong những năm gần đây vì người sáng lập Kent Beck đã quay trở lại sau khi ông vắng bóng trong nhiều năm vì lý do cá nhân.

Cũng cần lưu ý rằng có một sự thiển cận trong nguyên tắc thứ 3 của Tuyên ngôn Agile khi giới hạn tần suất chuyển giao phần mềm xuống còn “một vài tuần” nhưng DevOps và chu kỳ continuous delivery ngày nay cho phép chúng ta release nhiều phần mềm trong một ngày.

Uncle Bob (Robert Cecil Martin) trả lời cho điểm này như sau:

“Vào thời điểm năm 2001, chúng tôi không thể tưởng tượng sẽ làm được gì nhanh hơn vài tuần. Tom Gilb là người duy nhất trong cộng đồng có thể làm được, nhưng ông ấy không có mặt tại cuộc họp. Chúng tôi nghĩ rằng hai tuần là giới hạn thấp hơn và không ai bận tâm đến việc chất vấn điều này, và rõ ràng đây là điểm thiển cận”.

Tương lai của Agile

Agile không còn chỉ được hiểu trong bối cảnh phát triển phần mềm nữa.

Chúng ta có “Scaling Agile” với niềm tin rằng toàn bộ tổ chức cần hoạt động theo các nguyên tắc Agile.

Agile trong doanh nghiệp hiện là một chủ đề ngày càng nhận được nhiều quan tâm và động lực.

Để áp dụng Agile vào các quy trình truyền thống của doanh nghiệp, Bjarte Bogsnes nhấn mạnh một thách thức lớn trong bài “Chuyển đổi Agile và hiện tượng con voi trong phòng” (tựa gốc: Agile Transformation and the Elephant in the Room).

“Thật khó để mở rộng quy mô Agile bằng cách sử dụng cùng một framework và cùng một ngôn ngữ đã hoạt động rất tốt để chuyển đổi phát triển phần mềm. Đối với các giám đốc điều hành, “Scrum” nghe có vẻ giống như một căn bệnh ngoài da, “Sprint” không chỉ việc chạy nhanh hơn, “Slack” không phải nói về sự lười biếng, còn “continuous delivery” không phải là chỉ đến một dây chuyền lắp ráp hiệu quả.
Chúng ta cần một bản dịch, một thứ giúp ban điều hành doanh nghiệp hiểu rõ hơn ý nghĩa của Agile ở cấp độ kinh doanh. Agile trong doanh nghiệp thực sự có ý nghĩa gì trong thực tế?”

Theo Bogsnes, “con voi trong phòng” (một điều hiển nhiên nhưng ai cũng lờ đi) chính là quy trình lập ngân sách.

Vì trước giờ đây được coi là quy luật kinh doanh rồi, nên khó mà thay đổi nó. Nếu nó không được thay đổi, bất kỳ sự chuyển đổi theo hướng Agile nào cũng sẽ gặp khó khăn.

“Quy trình lập ngân sách có lẽ là rào cản cơ bản nhất đối với sự chuyển đổi Agile. Ngân sách hàng năm, quá trình lập ngân sách, và tư duy đằng sau nó đều là phản đề của Agile theo nhiều khía cạnh. Lập ngân sách được xây dựng dựa trên hai giả định cơ bản: tương lai có thể dự đoán được và không thể tin ai được. Còn gì ngược với Agile hơn chứ?”


Nhiều tổ chức trên khắp thế giới đã giải quyết vấn đề này và bổ sung nguyên lý Agile cho các quy trình trong doanh nghiệp bằng cách tuân theo 12 nguyên tắc bên cạnh việc lập ngân sách theo Bjarte Bogsnes.

Thay vì được sử dụng theo nghĩa hẹp của nó là lập kế hoạch và kiểm soát, “ngân sách” có thể là văn hóa lãnh đạo và hệ thống quản lý hiệu suất.

12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile.
12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile. Ảnh: Agile Alliance
12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile (tiếng Việt)
12 nguyên tắc bên cạnh việc lập ngân sách doanh nghiệp theo Agile (tiếng Việt)

Theo Agilemanifesto.org & Rakia Ben Sassi

Categories
Dev's Corner

8 Extension Visual Studio Code mọi developer phải có

Visual Studio Code là một trong những trình soạn thảo code phổ biến và được sử dụng rộng rãi nhất. Nó cũng đi kèm với rất nhiều tính năng miễn phí so với các code editor khác.

Hãy thử tải về các tiện ích mở rộng trên VS Code và bạn sẽ thấy thêm một khía cạnh khác ở các tính năng tuyệt vời này.

8 Extension Visual Studio Code

1. Turbo Console Log

Turbo Console Log là một tiện ích mở rộng xuất sắc cho việc debug.

Tiện ích mở rộng này giúp debug dễ dàng hơn bằng cách tự động hóa quá trình viết log message có ý nghĩa.

Tự động chèn log message có ý nghĩa với hai bước sau:

  • Chọn biến là chủ đề debug
  • Nhấn Ctrl + Alt + L
Turbo Console Log
Turbo Console Log. Ảnh: Medium

2. Import cost

Tốc độ là yếu tố quan trọng cho trang web. Nếu trang web hoặc ứng dụng không thể tải nhanh, thì chẳng phải có cũng như không sao.

Tiện ích mở rộng này hiển thị kích cỡ import. Bằng cách này, bạn sẽ biết khối lượng sẽ tải xuống và tìm ra nguyên nhân ứng dụng hoạt động chậm.

Với tiện ích mở rộng này, bạn có thể quyết định xem mình nên viết một function hay import toàn bộ bundle.

Import cost
Import cost

3. Prettier

Prettier dành cho tất cả mọi dev viết Python, JavaScript hoặc bất kỳ ngôn ngữ lập trình nào khác.

Cái tên nói lên tất cả, tiện ích này làm cho code đẹp hơn lên.

Cá nhân tôi rất tệ trong việc giữ cho các dòng, khoảng cách và tab bằng nhau. Do vậy, code của tôi nhìn rất lộn xộn.

Với Prettier, ngay sau khi nhấn tổ hợp lệnh + S, bạn sẽ chứng kiến điều kỳ diệu xảy ra. Tất cả code sẽ có khoảng cách chính xác và đều tăm tắp, khoảng cách các dòng cũng sẽ thống nhất.

Không ai có thể nhận ra bạn là người lộn xộn như thế nào 😐.

Prettier
Prettier. Ảnh: Medium

4. Bracket pair colorizer

Đã bao nhiêu lần xảy ra trường hợp khi chỉnh sửa code JavaScript, bạn luôn gặp khó khăn khi tìm dấu đóng mở ngoặc?

Đừng lãng phí thêm thời gian nữa chứ! Dùng tiện ích này, các dấu mở và đóng ngoặc sẽ được tô màu giống nhau và mọi việc sẽ dễ thở hơn hẳn.

Bracket pair colorizer
Bracket pair colorizer. ẢNh: Medium

5. Live share

Live share là một tiện ích mở rộng tuyệt vời để code cùng bạn bè và team.

Live share cho phép điều khiển từ xa trình soạn thảo VS code, các tệp đã mở. Một người khác có thể thay đổi và lưu code; vì vậy, giờ đây bạn có thể nhận được mọi trợ giúp từ xa.

Một tính năng khác là bạn có thể code real-time, biết ai đang type và type gì. Bên cạnh đó, nó cũng cấp quyền truy cập vào localhost và thiết bị đầu cuối.

Bonus: Bạn còn có thể tải xuống tiện ích mở rộng âm thanh Live share, bổ sung khả năng gọi âm thanh cực đỉnh. Với các dự án làm việc từ xa, đây quả là một extension miễn phí không thể hoàn hảo hơn!

6. Projects

Nếu bạn đang làm nhiều dự án cùng một lúc thì việc chuyển đổi giữa các folder quả rất khó, khi phải điều hướng đến folder cần thiết phải không.

Projects có thể hoạt động như một tab yêu thích của bạn.

Ví dụ: bạn có thể lưu trữ CSS và bootstrap tùy chỉnh trong một folder và sử dụng Projects để điều hướng giữa các folder một cách nhanh chóng.

Projects
Projects. Ảnh: Medium

7. Settings Sync

Tiện ích mở rộng này giúp lưu trữ tất cả bản sao lưu cài đặt của bạn trong GitHub. Bằng cách này, bạn có thể có các cài đặt giống nhau cho nhiều thiết bị hoặc các thiết bị mới của mình. Bất kỳ thay đổi nào đều được đồng bộ hóa liền mạch.

Setting Sync cho phép đồng bộ hóa hầu như là mọi thứ bạn tùy chỉnh trên VS Code sang Github, từ việc cài đặt phím tắt cho đến các tiện ích mở rộng VS Code khác.

8. JavaScript (ES6) Code Snippets

VS Code đi kèm với JS IntelliSense tích hợp sẵn, nhưng JS Code Snippets nâng cao trải nghiệm này hơn nữa bằng cách thêm các đoạn JavaScript snippet được tạo sẵn, chứa các đoạn code được sử dụng phổ biến nhất. Hãy nói tạm biệt việc liên tục lặp lại đoạn code! 🙌

Tiện ích mở rộng này hỗ trợ JS, TypeScript, JS React, TS React, HTML và Vue.

JavaScript (ES6) Code Snippets
JavaScript (ES6) Code Snippets. Ảnh: Medium

Còn extension nào mà bạn thấy hữu ích nữa không nhỉ? Hãy comment cho cộng đồng Gambaru biết nhé!

Theo Ali Haider

Categories
Dev's Corner

5 Giá trị của Scrum và cách Scrum Master làm việc

5 Giá trị của Scrum

Scrum là công cụ tạo nên thành công của rất nhiều team trong suốt nhiều năm nay và có thể nói, yếu tố thành công chủ yếu xoay quanh 5 giá trị của Scrum.

Tôi sẽ kể cho các bạn về khoảng thời gian tôi tham gia nhóm nhảy trường trung học nhé.

Trải nghiệm này liên quan ra sao đến Scrum nhỉ? Gambaru sẽ cùng bạn kết nối dữ kiện và hướng đến 5 giá trị cốt lõi và cực kỳ thực tế của Scrum.

5 Giá trị của Scrum và cách Scrum master làm việc
5 Giá trị của Scrum và cách Scrum master làm việc

1. Can đảm

Trong nhóm nhảy, chúng tôi là một nhóm theo đuổi nhiều phong cách khác nhau.

Tôi nhớ có lần một số chị lớp trên đã lên tiếng và đề xuất một số thay đổi cho bài nhảy giáo viên đã chuẩn bị trước đó, sao cho phù hợp hơn với phong cách khiêu vũ cổ điển.

Các thành viên của một Scrum Team có lòng can đảm để làm những gì phải làm và giải quyết những thách thức khó khăn - The Scrum Guide.
Các thành viên của một Scrum Team có lòng can đảm để làm những gì phải làm và giải quyết những thách thức khó khăn – The Scrum Guide. Ảnh: Pexels

Điều gì xảy ra tiếp theo?

Một số bước nhảy đã được điều chỉnh. Hậu bối chúng tôi lúc đó mới nhận ra rằng bạn có thể nói ra suy nghĩ của mình và điều đó thực sự đã giúp cả nhóm gắn kết tốt hơn.

Tương tự, Scrum Team cần sẵn sàng dũng cảm áp dụng văn hóa phê bình mang tính xây dựng và giao tiếp cởi mở.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Giúp đỡ team – Nếu thành viên trong team chuẩn bị thực hiện một task mới, hãy hướng dẫn họ nếu họ cần giúp đỡ. Khuyến khích, động viên team trở thành một không gian an toàn để mọi người không cảm thấy có trở ngại trong việc yêu cầu hỗ trợ.
  • Hãy tự xây dựng lòng can đảm – Hãy làm gương. Hãy đứng lên bảo vệ lẫn nhau nếu cảm thấy team mình đang gặp áp lực hoặc tinh thần đội nhóm đang đi xuống.

2. Tập trung

Vì các cuộc thi thay đổi chủ đề và phong cách liên tục, chúng tôi phải chuẩn bị các điệu nhảy trong thời gian ngắn và chuẩn bị/biểu diễn chúng với khả năng tốt nhất của mình.

“Hãy luôn nhớ rằng, sự tập trung sẽ quyết định thực tại của bạn.” - George Lucas.
“Hãy luôn nhớ rằng, sự tập trung sẽ quyết định thực tại của bạn.” – George Lucas. Ảnh: Paul Skorupskas – Unsplash

Trong Sprint theo khung thời gian cố định (time-boxed Sprint), team cần phải tập trung vào các mục tiêu đã đặt ra ban đầu.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Điều phối – Hướng dẫn team bạn giới hạn lại số lượng task và mức độ ưu tiên cho mỗi người trong một Sprint để đảm bảo mọi thành viên đều tập trung.
  • Nhắc lại trọng tâm trong Daily Scrum – Thảo luận với team làm thế nào để cả nhóm đạt được mục tiêu.

3. Cam kết

Cam kết là điều đã thúc đẩy nhóm nhảy của chúng tôi.

Chúng tôi đều có chung mong muốn giành được danh hiệu cấp khu vực và tất cả mọi người đều cam kết thực hiện mục tiêu trên.

“Các cá nhân cần cam kết đạt được các mục tiêu của Scrum Team.” - The Scrum Guide.
“Các cá nhân cần cam kết đạt được các mục tiêu của Scrum Team.” – The Scrum Guide. Ảnh: freepik

Ở mỗi buổi biểu diễn, chúng tôi phải cố gắng hết sức và làm việc cùng nhau.

Chúng tôi phải nghĩ làm thế nào để mang đến màn trình diễn tốt nhất với tư cách là một nhóm nhảy và đồng thời cũng phải trình diễn đạt nhất có thể với tư cách vũ công cá nhân.

Các thành viên một Scrum Team nên cam kết hướng đến tầm nhìn của team và cùng nhau tạo ra các mục tiêu thực tế.

Các team nhỏ trong Scrum Team cần duy trì cam kết với Mục tiêu Sprint và tự tổ chức để đạt được các mục tiêu này trong thời gian Sprint đề ra.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Điều phối Sprint Planning – Đảm bảo rằng team mình cảm thấy thoải mái với việc lập kế hoạch và có phạm vi để giải quyết các lỗi hay vấn đề trong quá trình thực hiện.
  • Bảo vệ nhóm trước việc phạm vi dự án bị thay đổi, vượt phạm vi (scope creeps/changes) – Là Scrum Master, hãy bảo vệ team khỏi những thay đổi không mong muốn trong Sprint, những thay đổi về Mục tiêu Sprint và cả áp lực không đáng có từ Product Owner.

4. Tôn trọng

Là một team, để thực hiện hết khả năng của mình, chúng ta cần làm việc như một nhóm duy nhất và điều đó chỉ có thể xảy ra nếu có sự tôn trọng lẫn nhau.

"Không ai trong chúng ta thông minh bằng tất cả chúng ta." - Ken Blanchard, Tác giả sách Vị giám đốc một phút.
“Không ai trong chúng ta thông minh bằng tất cả chúng ta.” – Ken Blanchard, Tác giả sách Vị giám đốc một phút. Ảnh: Matthew Henry – Burst

Trong Scrum Team, tôn trọng có nghĩa là tin tưởng các thành viên hoàn thành nhiệm vụ của họ, lắng nghe và xem xét ý tưởng của mọi người cũng như công nhận thành tích của nhau.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Ăn mừng các thành tựu – Là một team, hãy cùng ăn mừng thành tích lớn nhỏ của nhau.
  • Tôn trọng các cá nhân – Cho các thành viên không gian riêng của mình và tôn trọng những đóng góp của họ cho cả team.

5. Cởi mở

Khi học một bài nhảy mới, nếu ai trong nhóm gặp khó khăn, chúng tôi thường trao đổi, nói chuyện sớm nhất để có thể học và giải quyết mọi vấn đề sớm nhất.

“Scrum Team và các bên liên quan đồng ý cởi mở về tất cả công việc và những thách thức khi thực hiện công việc.” - The Scrum Guide
“Scrum Team và các bên liên quan đồng ý cởi mở về tất cả công việc và những thách thức khi thực hiện công việc.” – The Scrum Guide. Ảnh: Reshot

Khi các thành viên của một Scrum Team sớm nói về những trở ngại họ đang gặp phải, họ có xác suất quyết tâm và tiến bộ cao hơn.

Bạn có thể làm gì với tư cách là một Scrum Master?

  • Hãy trung thực – Điều này phải bắt đầu từ bạn, hãy có những buổi trò chuyện trung thực với cả nhóm.
  • Hãy là tấm lưới an toàn – Là một Scrum Master, hãy tập quan sát những điểm đang gặp vấn đề. Nếu thấy các vấn đề không được đề cập trong các buổi stand-up chẳng hạn, hãy hỏi các thành viên trong team xem họ có đang đi đúng hướng không.

Bạn nghĩ gì về 5 giá trị Scrum này? Mời các Scrum Master tài năng chia sẻ thêm những kinh nghiệm của riêng các bạn ở phần comment phía dưới cho cả cộng đồng Gambaru học hỏi thêm nhé!

Theo Rishika Mittal

Categories
Dev's Corner

AR, VR, MR: Tái định nghĩa cách nhìn nhận và trải nghiệm thế giới

Ở phần trước, chúng ta đã tìm hiểu sự khác biệt giữa AR, VR và MR.

Phần này, hãy theo dõi kỹ hơn bức tranh toàn cảnh về tình hình đầu tư, công nghệ, yêu cầu kỹ thuật và tương lai của AR, VR và MR.

Một trong những ngành hưởng lợi nhiều nhất khi có sự xuất hiện của VR là ngành công nghiệp giải trí.

Lego Star Wars 360 Experience là một ví dụ về việc áp dụng và triển khai thực tế ảo một cách tuyệt vời, cho phép người xem trải nghiệm câu chuyện được kể theo một cách hoàn toàn khác biệt.

nh: Medium

Gã khổng lồ Facebook cũng đã công bố thiết bị VR headset độc lập đầu tiên (không cần gắn với điện thoại hoặc máy tính).

Oculus Go của Facebook
Oculus Go của Facebook. Ảnh: Justin Doherty – Pexels

Với sự thành công bùng nổ của Pokemon Go vào năm 2016, thế giới đã có cái nhìn đầu tiên về cách AR có thể “di chuyển” thực tế của chúng ta theo đúng nghĩa đen bằng cách tăng cường nó với những con quái vật nhỏ xuất hiện trong và ngoài màn hình điện thoại thông minh.

Thành công của Pokemon Go đã mở ra một cuộc cách mạng
Thành công của Pokemon Go đã mở ra một cuộc cách mạng. Ảnh: Mika Baumeister – Unsplash

Tương lai của MR lại khó xác định hơn.

Cũng giống như VR, MR sử dụng một headset để khởi chạy trải nghiệm. Song, các thiết bị MR khác với phần cứng VR thông thường vì chúng sử dụng kính mờ như Google Glass cho phép chúng ta vẫn ở thế giới thực – thực tế ảo được trộn lẫn với thực tế.

Giống như AR, MR phủ đè nội dung kỹ thuật số và mô phỏng lên trên những gì chúng ta thấy.

Nhưng trải nghiệm MR cho phép bạn thực sự tương tác với mô phỏng theo những cách mà AR chưa thể làm được.

Ngoài ra, thay vì chỉ phụ thuộc vào màn hình điện thoại, bạn có thể sử dụng cơ thể và bộ điều khiển từ xa để tương tác với môi trường một cách sống động hơn.

Intel thích dùng cụm “Merged Reality” hơn là "Mixed Reality"
Intel thích dùng cụm “Merged Reality” hơn là “Mixed Reality”. Ảnh: ExtremeTech

Đầu tư vào AR, VR, MR

Được hỗ trợ bởi các nhà đầu tư nổi tiếng như Google Ventures của Alphabet, Alibaba và Andreessen Horowitz, Magic Leap dẫn đầu cuộc chơi đầu tư MR với gần 2 tỷ đô vốn đầu tư mạo hiểm cho đến thời điểm bài viết này.

Hãy cùng xem lại các khoản đầu tư lớn vào các công ty VR / AR quan trọng trên thị trường hiện nay.

Đầu tư lớn vào các công ty AR, VR
Đầu tư lớn vào các công ty AR, VR. Ảnh: Toptal

Thiết kế VR, AR và MR tương tự như việc tạo ra những thực tế mới. Mô hình mới về tạo nội dung đa chiều và immersive (chìm đắm) này đòi hỏi các quy tắc và cân nhắc mới.

Thiết kế VR, AR và MR thúc đẩy các kỹ năng hiện có từ visual design (3D, UI) đến thiết kế trải nghiệm (UX, sản phẩm) phát triển v.v

Từ sự hiểu biết về giải phẫu con người, sự đồng cảm, âm thanh đến thiết kế hình ảnh và hơn thế nữa, những nhà sáng tạo nay đã có một sân chơi hoàn toàn mới.

3D và Visual Design

Các nhà thiết kế VR phải sử dụng một cách tiếp cận và bộ công cụ hoàn toàn khác để sáng tạo giao diện và trải nghiệm immersive.

Chính xác hơn, họ phải tư duy bên ngoài màn hình 2D và thay vào đó phạm vi sáng tạo bây giờ là một không gian 360° vô hạn.

Các nhà thiết kế VR cần cộng tác với các chuyên gia 3D và/hoặc nắm được hiểu biết cơ bản về đồ họa 3D bằng cách sử dụng WebGL và các công cụ mã nguồn mở khác.

Phần mềm tạo 3D phổ biến bao gồm:

Phần mềm 3D phổ biến
Phần mềm 3D phổ biến. Ảnh: HTC Vive space requirements

Scale và Positioning

Các cân nhắc về quy mô và vị trí cho thiết kế VR và AR được liên kết và ảnh hưởng lẫn nhau.

Một mặt, khoảng cách của một element với người xem ảnh hưởng đến mức độ dễ đọc và mức độ dễ dàng khi tương tác.

Mặt khác, tỷ lệ của một đối tượng trong thực tế mô phỏng phản ánh mức độ lớn/nhỏ, hoặc xa/gần của đối tượng đó trong thế giới thực.

Tracking và Movement

Nguồn ảnh: Oculus Rift Touch Controllers

Khái niệm theo dõi chuyển động liên quan đến phần cứng và phần mềm AR, VR và MR được sử dụng.

Ví dụ: Google Cardboard chủ yếu cho phép theo dõi chuyển động cơ bản từ gia tốc kế của điện thoại, còn VR headset Google Daydream đi kèm với bộ điều khiển từ xa cho phép bạn chỉ vào mọi thứ và thúc đẩy tương tác trong không gian ảo.

Ở phân khúc cao hơn, các hệ thống immersive như Oculus Rift HTC Vive cho phép các hệ thống theo dõi chuyển động và bộ điều khiển tương tác nhanh nhạy hơn.

Thiết kế thiết bị theo dõi và bộ điều khiển chuyển động đòi hỏi sự hiểu biết rộng về các cử chỉ tự nhiên của con người và khả năng tương tác thể chất.

Áp dụng các ngành truyền thống

Chúng ta vẫn có thể áp dụng nhiều nguyên tắc từ các loại hình nghệ thuật thị giác truyền thống.

Ví dụ: lý thuyết màu sắc, quy tắc bố cục và các phương pháp chiếu sáng tốt nhất vẫn áp dụng được cho các phương tiện mới.

Bởi vì đó vẫn là thế giới thực mà ta đang cố gắng mô phỏng và trải nghiệm trong một bối cảnh khác, nên bằng cách tận dụng các công nghệ mới, các nguyên tắc nghệ thuật thị giác cốt lõi có thể được tận dụng khi thiết kế những thực tế mới.

Animation và Transition

Tương tự, ta vẫn có thể áp dụng các nguyên tắc hoạt hình – hiệu ứng chuyển tiếp và chuyển động trong thực tế ảo.

Dưới đây là tóm tắt 12 Nguyên tắc Animation do Disney soạn.

  • Squash and Stretch: Mở rộng và nén một đối tượng để mô phỏng trọng lượng và thể tích trong chuyển động.
  • Anticipation (Dự đoán): Một chỉ báo cho thấy một hành động quan trọng sắp diễn ra.
  • Staging: Thiết lập ý định rõ ràng xuyên suốt mọi trạng thái / vị trí của đối tượng.
  • Straight Ahead and Pose to Pose: Xác định trạng thái bắt đầu và kết thúc trước, sau đó điền vào khoảng trống.
  • Follow Through and Overlapping Action: Khi nhiều vật đang chuyển động dừng lại, chúng không dừng lại cùng một lúc.
  • Slow-In and Slow-Out: Hay hiệu ứng easing – diễn ra chậm, rồi nhanh, rồi chậm.
  • Arc: Thêm một chút độ cong trong hầu hết các chuyển động.
  • Secondary Action (Hành động phụ): Thêm vào hành động chính để củng cố hoặc bổ sung cho hành động đó.
  • Timing: Sử dụng tốc độ hoặc độ trễ để mô phỏng vật lý hoặc canh thời gian.
  • Exaggeration (Cường điệu): Nhấn mạnh các chuyển động cụ thể để giúp truyền đạt điều gì đó.
  • Solid Drawings: Làm mọi thứ trông ba chiều hơn.
  • Appeal (Sự hấp dẫn): Tạo ra những đặc điểm thú vị và hấp dẫn.

Tương lai của AR, VR và MR

AR đã cho thấy tỷ lệ sử dụng rộng rãi hơn nếu chúng ta xem xét sự thành công trên toàn thế giới của cú hit Pokemon Go.

Ngày nay, tất cả những gì cần thiết để trải nghiệm thực tế tăng cường là một chiếc điện thoại thông minh với hệ điều hành cập nhật, có camera tốt và một ứng dụng AR.

Sự gia nhập gần đây của Apple vào sân chơi AR hứa hẹn sẽ thúc đẩy hơn nữa xu hướng thực tế tăng cường.

Mặc dù có lịch sử lâu đời hơn AR hoặc MR, nhưng VR dường như có vấn đề với người dùng, chủ yếu là do chi phí cao để có được một bộ VR headset phù hợp, sự khó chịu về thể chất khi sử dụng thiết bị quá lâu và thiếu các trường hợp sử dụng cụ thể về mặt công nghệ.

Mặc dù vậy, nhiều lĩnh vực có thể sử dụng công nghệ này để tạo ra các cơ hội mới, như VR đang được ứng dụng trong ngành công nghiệp ô tô.

Các ứng dụng về MR là vô hạn.

Giám đốc điều hành Avegant Joerg Tewes đã nói: “MR cho phép mọi người tương tác trực tiếp với ý tưởng của họ thay vì trên màn hình hoặc bàn phím.”

Thế giới đang trên đà mở rộng ranh giới với nội dung 3D và lĩnh vực kỹ thuật số hơn bao giờ hết
Thế giới đang trên đà mở rộng ranh giới với nội dung 3D và lĩnh vực kỹ thuật số hơn bao giờ hết. Ảnh: Pexels

Đây là cơ hội có một không hai cho các nhà thiết kế, kỹ sư và các công ty tham gia vào cuộc cách mạng này.

Theo Miklos Philips

Categories
Dev's Corner

VR, AR, MR là gì? Sự khác biệt giữa AR, VR và MR

Hãy cùng Gambaru phân biệt các khái niệm về VR, AR và MR, đồng thời du hành ngược thời gian xem các công nghệ này đã bắt đầu và phát triển ra sao qua các năm.

VR là gì?

Thực tế ảo, hay VR, là một trải nghiệm được mô phỏng và nhập vai được một thiết bị chiếu vào tầm nhìn của người dùng.
Thực tế ảo, hay VR, là một trải nghiệm được mô phỏng và nhập vai được một thiết bị chiếu vào tầm nhìn của người dùng. Ảnh: Pexels

Hãy tưởng tượng bạn đang đi bộ xuống đại lộ Champs-Elisée (Paris) trong khi vẫn ngồi trong nhà ở San Francisco.

Tất cả những gì bạn cần là một chiếc headset phóng chiếu bạn vào môi trường mô phỏng thông qua kính ngắm. Đó chính xác là những gì VR (Thực tế ảo) hứa hẹn và sẽ còn hơn thế nữa.

VR hoạt động ra sao?

VR cần một bộ kính bên trong khung nhìn trên một headset và một thiết bị được gắn thêm để lưu trữ và lập trình các trải nghiệm.

Từ quan sát thuần túy đến hoàn toàn đắm chìm vào trải nghiệm, phạm vi khả năng VR thay đổi tùy thuộc vào thiết bị và headset được sử dụng.

Sử dụng điều khiển từ xa đồng bộ với headset cho phép người dùng tương tác với các vật thể 3D trong không gian ở các trò chơi VR hoặc các giao diện và ứng dụng VR.

Lịch sử về VR

Theo Hiệp hội VR (Virtual Reality Society) trình bày về Lịch sử thực tế ảo thì VR có thể bắt đầu từ “những bức tranh tường 360 độ (hoặc những bức tranh toàn cảnh) từ thế kỷ 19”.

Sau đó, chúng ta có chuyến bay bay mô phỏng đầu tiên (năm 1929), tiếp theo là Head Mounted Display (Màn hình hiển thị gắn trên đầu) VR đầu tiên của Morton vào năm 1960, và Neo trải nghiệm toàn bộ thế giới dưới dạng mô phỏng trong bộ phim The Matrix (Ma trận) vào năm 1999.

Những công ty nào đang dẫn đầu thị trường VR ngày nay?

Công ty dẫn đầu về VR
Công ty dẫn đầu về VR

Tua nhanh đến năm 2014, Google bắt đầu sản xuất dòng headset DIY trên thị trường đại chúng, sử dụng điện thoại thông minh để thúc đẩy trải nghiệm VR: Google Cardboard.

Năm sau đó, Samsung tiếp nối với Gear VR và cuộc đua mới về thực tế ảo chính thức bắt đầu.

Được mua lại vào tháng 6 năm 2014, Oculus VR đã gia nhập gia đình Facebook để đẩy nhanh mục tiêu thống trị phân khúc headset thực tế ảo cao cấp.

AR là gì?

Đúng như tên gọi, Thực tế tăng cường, hay AR, bổ sung vào nhận thức của chúng ta về thế giới bằng cách tạo chồng thêm các lớp đồ họa, hình ảnh hoặc tập hợp dữ liệu tương tác do máy tính tạo ra.

AR hoạt động ra sao?

AR yêu cầu điện thoại thông minh có camera và ứng dụng AR.

Hai yếu tố chính làm cho nó hoạt động là khả năng máy ảnh ghi lại được môi trường xung quanh khi bạn di chuyển và phần mềm giúp tính toán và phóng chiếu hình ảnh hoặc nội dung do máy tính tạo ra.

Một ví dụ minh họa xuất sắc trên đây chính là ứng dụng AR của IKEA cho phép mọi người tưởng tượng cảm giác ở trong không gian với các sản phẩm nội thất của hãng.

Các nhà thiết kế và kiến trúc sư rõ ràng có thể hưởng lợi từ cách tiếp cận mới này để tạo ra các vật thể có kích thước như thật trong bối cảnh đời thực.

“Giờ đây, công nghệ đã bắt kịp tham vọng của chúng tôi. AR cho phép chúng tôi tái xác định trải nghiệm bán lẻ đồ nội thất, với mục tiêu tạo ra một cuộc sống hàng ngày tốt hơn cho mọi người, ở mọi nơi.”

Michael Valdsgaard, Trưởng nhóm Chuyển đổi Kỹ thuật số tại Inter IKEA Systems cho biết.

Lịch sử về AR

Từ việc tạo ra đường đánh dấu màu vàng ảo đầu tiên trong trận đấu trực tiếp giải bóng bầu dục quốc gia Mỹ NFL vào năm 1998 đến các dữ liệu bản đồ ảo tăng cường để hỗ trợ các chuyến bay mô phỏng của NASA, AR đã không còn chỉ có trong tiểu thuyết khoa học viễn tưởng.

Năm 1974, Myron Kruger đã sử dụng kết hợp máy chiếu và máy quay video trong một môi trường tương tác – đó là sự ra đời của AR như chúng ta biết ngày nay.

Gần đây hơn, AR đã có một bước nhảy vọt hướng đến việc áp dụng AR rộng rãi hơn tại hội nghị WWDC 17 của Apple khi Apple giới thiệu trước công chúng về ARKit, một khung phát triển cho các ứng dụng AR được tạo cho iPhone và iPad.

ARkit vs ARCore – Cuộc chiến giữa Apple và Google để thống trị AR

ARkit vs ARCore.
ARkit vs ARCore. Ảnh: Medium

ARKit của Apple cho iOS 11 hứa hẹn sẽ dân chủ hóa việc phát triển nội dung cũng như sự tiêu thụ AR.

Đây là phản hồi trực tiếp trước ARCore của Google, công ty vốn có lợi thế tận dụng kiến thức đã có trong ngành VR, trái với Apple.

Do các ứng dụng AR vẫn còn mới trên thị trường đại chúng, nên còn quá sớm để nói các bộ công cụ phát triển này thực sự khác nhau như thế nào, ngoại trừ việc chúng dành riêng cho từng hệ điều hành và đối tượng cốt lõi.

Cả hai khung thiết kế và phát triển AR này hứa hẹn sẽ đơn giản hóa và đẩy nhanh quá trình sáng tạo cũng như đưa công nghệ vào tay hàng triệu người dùng điện thoại Android và iOS
Cả hai khung thiết kế và phát triển AR này hứa hẹn sẽ đơn giản hóa và đẩy nhanh quá trình sáng tạo cũng như đưa công nghệ vào tay hàng triệu người dùng điện thoại Android và iOS. Ảnh: Unsplash

Giờ đây, khi hai công ty công nghệ nổi bật nhất này – kiểm soát 99% thị trường điện thoại thông minh – đã có một động thái công khai về AR, chúng ta nên sẵn sàng chứng kiến các ngành công nghiệp sẽ bị disrupt (phá vỡ) – một lần nữa.

MR là gì?

MR (Thực tế hỗn hợp) là sự kết hợp giữa VR và AR.

Ví dụ: MR sử dụng headset giống như VR, nhìn qua một khung nhìn hoặc mắt kính, và nó cũng chiếu hình ảnh lên trên môi trường hiện tại của ta.

Điều làm cho MR nổi bật là khía cạnh tương tác cao và khả năng hiển thị thực tế của hình chiếu mà MR bổ sung vào môi trường xung quanh.

Thay vì chỉ phụ thuộc vào bộ điều khiển từ xa hoặc màn hình điện thoại, ta có thể tương tác với nội dung immersive này bằng cử chỉ cơ thể và các ngón tay.

Apple và Google rõ ràng dẫn đầu về công nghệ AR, nhưng bối cảnh MR ngày nay đang chuộng Microsoft (HoloLens) và Magic Leap (với fund cực lớn).

HoloLens vs Magic Leap – Hai vị vua của cuộc đua MR

Bất chấp sự thất bại về mặt thương mại của Google Glass, Microsoft vẫn không ngại thử nghiệm “holographic computer” của riêng họ trong sân chơi MR.

Cái tên “HoloLens” xuất phát từ trải nghiệm cốt lõi “cho phép bạn tương tác với nội dung kỹ thuật số của mình và tương tác với hình ảnh hologram trong thế giới xung quanh.”

Là một trong những công ty start-up được gây quỹ nhiều nhất giai đoạn pre-product, dự án do Google hậu thuẫn này cũng là một trong những dự án bí mật nhất từ trước đến nay của ngành công nghệ.

Founder của Magic Leap, Rony Abovitz gọi nó là “thực tế điện ảnh – một sự thay đổi hoàn toàn về điện toán trực quan”.

Công ty công nghệ MR này giải quyết thách thức trong việc thiết kế môi trường tương tác bằng cách tận dụng những gì tốt nhất của cả hệ thống VR và AR.

Kính Magic Leap sử dụng công nghệ Dynamic Digitised Lightfield Signal (tạm dịch: Tín hiệu trường sáng số hóa động) – chiếu hình ảnh trực tiếp vào mắt và “lừa” não bộ nghĩ rằng đó là thật.

Kết quả là trải nghiệm sẽ được tăng cường phong phú hơn và đáng tin hơn.

Theo Miklos Philips

Categories
Dev's Corner

Tại sao lập trình viên không thể estimate thời gian hiệu quả?

Hãy cùng Gambaru xem xét một cách tiếp cận thống kê để giải thích tại sao nhiều dự án công nghệ lại trễ hạn.

Cho dù bạn là lập trình viên junior, senior, quản lý dự án hay quản lý cấp cao với 20 năm kinh nghiệm, việc ước lượng thời gian trong các dự án phần mềm không bao giờ là dễ dàng.

Không ai dù có kinh nghiệm hay thiên tài đến đâu luôn có thể dõng dạc tuyên bố mình biết chắc chắn các mốc thời hạn chính xác của một dự án phần mềm cả
Không ai dù có kinh nghiệm hay thiên tài đến đâu luôn có thể dõng dạc tuyên bố mình biết chắc chắn các mốc thời hạn chính xác của một dự án phần mềm cả. Ảnh: Medium

Tổng quan

Trước tiên, hãy nhìn tổng thể vào vấn đề, hậu quả và nguyên nhân gốc rễ tiềm ẩn.

Vấn đề

Các dự án phần mềm hiếm khi đáp ứng đúng thời hạn.

Hậu quả

Các nỗ lực tiếp thị bị lãng phí, khách hàng không hài lòng, lập trình viên gặp áp lực có thể viết code chất lượng kém để chạy kịp deadline, khiến độ tin cậy của sản phẩm bị ảnh hưởng, và cuối cùng, các dự án hoàn toàn có thể bị hủy.

Các nguyên nhân đã được biết

  • Estimate thời gian sai (trọng tâm của bài viết này).
  • Yêu cầu không rõ ràng khi bắt đầu dự án và các yêu cầu thay đổi ở những giai đoạn sau.
  • Hội chứng “dát vàng” (gold plating): quá chú ý đến những chi tiết ngoài phạm vi công việc.
  • Không dành đủ hoặc mất quá nhiều thời gian cho giai đoạn nghiên cứu và thiết kế kiến ​​trúc.
  • Bỏ qua các vấn đề tiềm ẩn liên quan đến sự tích hợp của bên thứ ba.
  • Mong muốn “làm đúng ngay lần đầu tiên”.
  • Thực hiện quá nhiều dự án cùng một lúc hoặc bị phân tâm (thường xuyên phá vỡ quy trình).
  • Quy mô chất lượng-số lượng không cân bằng.

Lạc quan quá mức, Hiệu ứng Dunning-Kruger, Yếu tố bất định hay Tất cả chỉ là toán?

Hãy thử điểm qua các giả thuyết
Hãy thử điểm qua các giả thuyết! Ảnh: Unsplash
  • Thật dễ để loại bỏ giả thuyết về việc lạc quan quá mức chỉ vì một lẽ thường thấy rằng không có lập trình viên nào từng vật vã với deadline lại lạc quan khi đặt ra thời hạn làm task. Còn tình huống khi việc quản lý dự án đến từ người không có nền tảng kỹ thuật và họ đặt ra thời hạn mà không biết mình đang làm gì lại là một vấn đề hoàn toàn khác nằm ngoài phạm vi của bài viết này.
  • Một số cũng cho rằng việc ước lượng thời gian kém là do hiệu ứng Dunning-Kruger (đánh giá năng lực của bản thân cao hơn thực tế). Tuy nhiên, nếu việc thiếu kinh nghiệm hoặc đánh giá quá cao khả năng của một người là nguyên nhân dẫn đến đánh giá thấp thời gian, vậy có phải nhiều kinh nghiệm hơn sẽ giảm bớt vấn đề không? Thực tế, các công ty lớn với nhiều nguồn lực vẫn có tỷ lệ trễ deadline cao choáng váng, do đó giả thuyết này bị loại bỏ. 
  • Hầu hết các lập trình viên, đặc biệt là lập trình viên có kinh nghiệm, nhanh chóng kết luận cho yếu tố bất định. Theo họ, việc ước lượng thời gian sẽ luôn sai, “cuộc sống mà”, và điều duy nhất ta có thể làm là cố gắng đáp ứng yêu cầu khách hàng và bảo team lập trình “thôi ráng thêm xíu nữa” khi có sự cố. Tất cả chúng ta đều quen thuộc với những căng thẳng, code lỗi và sự hỗn loạn ở kịch bản này.

Đây có thực sự là cách tốt nhất mà ta có thể hoàn thành công việc không? Chà, tôi không nghĩ vậy và đó là khi tôi bắt đầu cố tìm ra một lời giải thích có tính toán học hợp lý về lý do tại sao những người thông minh như kỹ sư phần mềm không thể ước lượng thời gian hiệu quả được.

Nó chỉ là toán thôi!

3 giả thuyết đã bị loại!
3 giả thuyết đã bị loại!

Ngày nọ, tôi thực hiện một task lẽ ra chỉ mất 10 phút nhưng rốt cuộc nó tốn mất 2 giờ. Tôi bắt đầu suy ngẫm về lý do tại sao.

  • Tôi nghĩ sẽ mất 10 phút vì thực tế trong đầu đã biết 100% đoạn code mình cần viết.
  • Sau đó, nó ngốn mất của tôi đến 2 giờ vì có bug trong framework mà tôi hoàn toàn không biết.

Trong quản lý dự án, điều này được gọi là force majeure (sự kiện bất khả kháng): các nguyên nhân bên ngoài không thể kiểm soát được gây nên chậm trễ.

Đến đây bạn có thể nghĩ rằng tôi đang chứng minh cho giả thuyết các yếu tố bất định với kịch bản này. Đúng và Sai. Hãy nhìn rộng hơn một chút.

Sự bất định là nguyên nhân gốc rễ cho sự chậm trễ của task này bởi vì tôi sẽ không bao giờ đoán trước được có bug đó. Nhưng có nên cho đó là lý do dẫn đến sự chậm trễ của toàn bộ dự án?

Đến đây, ta cần phân biệt được rằng một task đơn lẻ không phải đại diện cho toàn bộ dự án và ngược lại.

Cách chúng ta “thường” ước lượng thời gian

  • Mean (giá trị trung bình)
  • Median (giá trị trung vị): giá trị tách giữa nửa lớn hơn và nửa bé hơn của một mẫu.
  • Mode (giá trị yếu vị): giá trị thường xuyên xuất hiện nhiều nhất.
Phân phối chuẩn (đường cong hình chuông)
Phân phối chuẩn (đường cong hình chuông)

Phân phối chuẩn

Phân phối chuẩn (normal distribution) rất phổ biến và bộ não người đã khá quen với chúng.

Về bản chất, chúng ta là những chuyên gia ước lượng mọi thứ tuân theo nguyên tắc phân phối chuẩn; đó là cơ sở để tích lũy kinh nghiệm trong quá trình làm việc.

Nếu bạn đã đi làm 7-11 lần trên 20 lần trong tháng này và mỗi lần đều mất 5 phút, ngoại trừ hôm thang máy đang bảo trì và bạn phải đợi 10 phút và có hôm bạn đợi vài phút cho đến khi trời tạnh mưa mới đi làm.

Vậy bạn ước tính thời gian đến chỗ làm hôm nay là bao nhiêu? 5 phút?

Nếu nói 15 phút thì không hợp lý vì thang máy hư là sự cố hy hữu hoặc 7 phút nếu hôm nay trời mưa.

Nếu 7-11 lần trên 20 lần, bạn mất 5 phút thì chắc chắn có khả năng lớn là hôm nay cũng chỉ mất 5 phút (median – giá trị trung vị), xác suất khoảng 90%.

Phân phối lệch

Ngay cả khi thực sự giỏi ước lượng thời gian cho một task, điều đó không có nghĩa là bạn sẽ giỏi ước lượng thời gian cho toàn dự án! Trái với những gì mọi người thường nghĩ, bạn sẽ ngày càng mắc nhiều sai lầm.

Meme ở phần 3 chính là nói về phân phối lệch (skewed distribution)! Hãy thử làm rõ cùng tôi.

Phân phối lệch
Giá trị trung vị (median) vẫn có xác suất đúng cao hơn giá trị trung bình (mean), đối với cùng 1 việc! Nếu đoán yếu vị (mode) (giá trị có xác suất cao nhất), bạn thậm chí còn sai nhiều hơn trên quy mô lớn hơn.

Phỏng đoán “tự nhiên” của chúng ta dựa trên số trung vị (median) giúp tối đa hóa xác suất đoán đúng; tuy nhiên, con số thực khi “sự kiện” đó xảy ra đủ số lần sẽ luôn gần với giá trị trung bình (mean).

Nói cách khác: Bạn càng làm nhiều task tương tự nhau, lỗi đó càng tích lại nhiều hơn!

Phương trình tính thời gian trễ theo giả thuyết trên.Phương trình tính thời gian trễ theo giả thuyết trên.
Phương trình tính thời gian trễ theo giả thuyết trên.

Các task lập trình trong một dự án thường khá giống nhau hoặc ít nhất được nhóm thành vài cụm tương tự! Phương trình này cũng gợi ý rằng vấn đề có thể mở rộng! Ai cũng muốn mọi thứ trong dự án phần mềm có thể mở rộng, trừ các vấn đề!

Vậy làm thế nào để áp dụng kiến ​​thức này?

Thành thật mà nói, khi viết bài, tôi không hề có ý định đưa ra “hướng dẫn” dựa trên giả thuyết này.

Bài viết là một phân tích mang tính khám phá, việc kết luận với một giả thuyết và hiểu nó là tùy thuộc vào độc giả.

Tuy nhiên, tôi biết rằng nhiều người sẽ thất vọng với kết luận mở trên, vì vậy đây là những gì cá nhân tôi đúc kết.

  1. Sẽ dễ dàng hơn để biết liệu task X sẽ mất nhiều / ít / cùng thời gian so với task Y hơn là nói chính xác chúng sẽ mất bao lâu. Điều này là do việc so sánh các giá trị median hoạt động giống như việc so sánh giá trị mean nếu độ lệch của các đường cong gần như nhau (điều này đúng với các task tương tự nhau).
  2. Tôi không nhớ hoặc ghi lại mọi task tương tự để tính toán và lấy giá trị trung bình. Vì vậy, tôi thường ước tính sai số không thể tránh khỏi (mean – median) theo phần trăm thời gian làm task đó tăng / giảm tùy thuộc vào mức độ thoải mái của tôi với môi trường development (tôi có thích ngôn ngữ / framework này không? (40%) Tôi có công cụ debug tốt không? (30%) Hỗ trợ IDE có tốt không? (25%) v.v.).
  3. Tôi chia sprint thành các task tương đương nhau, nhằm tạo sự đồng nhất trong quá trình ước lượng thời gian. Điều này cho phép tôi hưởng lợi từ điểm 1 ở trên, do sẽ dễ dàng biết được liệu hai task có thời gian gần bằng nhau hay không. Điều này cũng làm cho các task có thể có độ tương đương nhiều hơn, để có thể áp dụng hiệu quả giả thuyết trên và mọi thứ trở nên dễ đoán hơn.

Áp dụng các nguyên tắc này, bạn có thể thực hiện “thử nghiệm” nếu có đủ tài nguyên.

Ví dụ: nếu trong X1 ngày với Y1 lập trình viên, Z1 task tương đương đã được hoàn thành, thì ta có thể dễ dàng giải quyết X2 (ngày) nếu biết có sẵn Y2 lập trình viên và Z2 số task còn lại.

Theo Hesham Meneisi

Categories
Dev's Corner

Làm thế nào để viết một unit test hiệu quả?

Viết unit test là một phần quan trọng của quá trình phát triển phần mềm bởi khi làm chính xác và hiệu quả, bạn có thể giảm đáng kể số lượng bug và đẩy nhanh tiến độ công việc.

Hãy cùng Gambaru xem qua một số cách tiếp cận viết unit test sau
Hãy cùng Gambaru xem qua một số cách tiếp cận viết unit test sau! Nguồn ảnh: freepik

Kiểm thử phương thức (method) với business logic

Giả sử ta có lớp Story với phương thức publish. Ta chỉ được phép publish một story nếu nó có trạng thái DRAFT.

Kiểm thử phương thức với Business Logic
Xem code gốc.

Trong trường hợp này, sẽ hợp lý nếu viết bài unit test cho phương thức này bởi nó chứa một quy tắc nghiệp vụ quan trọng.

Ta cần tạo hai bài unit test để bao quát hoàn toàn được quy tắc này:

  • Kiểm tra xem có xuất hiện Error khi trạng thái không phải là DRAFT hay không.
  • Kiểm tra xem liệu trạng thái có chuyển đổi thành Published khi trạng thái là DRAFT hay không.
Kiểm thử phương thức
Xem code gốc.

Chỉ bằng cách kiểm thử phương thức, ta có thể giữ cho các bài unit test ở mức nhỏ. Điều này đặc biệt hữu ích khi kiểm tra business logic khó.

Hãy cố gắng luôn bao quát mọi nhánh trong business logic của mình.

Ngoài ra, sử dụng công cụ báo cáo code coverage để thống kê phần trăm code đã được kiểm thử cũng là một thực tiễn tốt.

Giả lập các thành phần phụ thuộc

Trong một số trường hợp, để đảm bảo rằng mình chỉ đang kiểm tra business logic, bạn sẽ cần giả lập các thành phần phụ thuộc (mock the dependencies). Hãy sử dụng ví dụ sau:

Giả lập các thành phần phụ thuộc

Dịch vụ này có một phụ thuộc vào một event dispatcher. Cần phải giả lập phụ thuộc này vì ta không muốn dispatch MoneyTransferredEvent trong quá trình tiến hành làm unit test.

Ta chỉ muốn biết liệu dịch vụ này có xử lý tất cả các business logic như mong đợi hay không.

Giả lập các thành phần phụ thuộc
Xem code gốc.

Khi giả lập phụ thuộc này, ta có thể thay thế triển khai thực tế bằng triển khai “giả” (fake implementation) và sử dụng triển khai giả này để kiểm tra xem phương thức chính xác đã được gọi hay chưa.

Một giả lập cũng có thể trả về dữ liệu. Điều này có thể hữu ích khi ta giả lập repository chẳng hạn.

Hãy giữ các bài unit test ở mức độ nhỏ và chi tiết. Nếu có các assertion không liên quan trong một bài unit test, bạn có thể xem xét việc tách chúng thành nhiều bài unit test. Dưới đây là một ví dụ:

Tách thành nhiều bài unit test
Xem code gốc.

Bằng cách tách các assertion này ra, bạn sẽ biết trực tiếp phần nào của ứng dụng không hoạt động khi bài unit test không thành công.

Kiểm thử mô-đun

Đôi khi, sẽ hữu ích hơn khi kiểm thử toàn bộ mô-đun thay vì viết một bài unit test cho mọi phương thức.

Giả sử chúng ta có một số code cho cronjob trong ứng dụng của mình. Cronjob này sẽ tìm lấy tất cả các story đang chờ và publish chúng:

Kiểm thử module
Xem code gốc.

Điều quan trọng duy nhất đối với mô-đun này là nó lấy các story và publish từng story một. Viết một bài kiểm thử cho một mô-đun như thế này mang lại một số lợi ích tuyệt vời sau:

  • Bạn chỉ có thể kiểm tra những gì quan trọng: Các endpoint chính xác có được gọi với dữ liệu chính xác không?
  • Bạn có thể dễ dàng tái cấu trúc code của mình. Bài kiểm thử sẽ pass miễn là các endpoint được gọi với dữ liệu mong đợi.
  • Việc kiểm thử một mô-đun thường có thể được thực hiện nhanh hơn so với việc viết một bài kiểm thử cho mọi phương thức.

Hãy cùng xem qua bài kiểm thử mô-đun dưới đây:

Bằng cách giả lập API client, ta có thể trả về hai story. Kiểm thử sẽ pass nếu hai story này cũng được publish. Thêm một số bài kiểm thử khác cho các kết quả API khác nhau cũng là một ý hay.

Một lựa chọn tốt khác để kiểm thử các mô-đun là viết các bài kiểm tra tích hợp (integration test).

Tuy nhiên, lợi ích của làm unit test là bạn có thể dễ dàng chạy nó cục bộ hoặc trong một pipeline. Các bài kiểm thử mô-đun này cũng rất hữu ích cho phát triển hướng kiểm thử (test-driven development – TDD).

Nếu mô-đun chứa nhiều business logic, bạn có thể muốn thêm một số bài kiểm thử cho các quy tắc nghiệp vụ cụ thể này.

Khi bao quát được business logic trong các bài kiểm thử phương thức, các bài kiểm thử mô-đun sẽ trở nên đơn giản.

Các bài kiểm thử mô-đun sẽ vẫn hữu ích để xác nhận xem liệu tất cả các lớp có hoạt động cùng nhau như mong đợi hay không.

Kết

Tôi cực kỳ chuộng kiểm thử mô-đun vì chúng bao quát được rất nhiều code. Chúng cũng có thể hữu ích để kiểm thử dependency injection.

Tuy nhiên, chỉ viết các bài kiểm thử mô-đun thường sẽ không đủ. Sự kết hợp các bài kiểm thử mô-đun và kiểm thử phương thức sẽ mang đến nhiều lợi ích mỹ mãn.

Một điều quan trọng khác cần lưu ý là có nhiều bài kiểm thử phương thức quá có thể làm bạn chậm lại.

Ví dụ, khi thay đổi một chuỗi thành một enum, hầu hết các bài kiểm thử sẽ không thành công.

Tuy nhiên, các bài kiểm thử mô-đun vẫn sẽ pass. Vì vậy, hãy cân nhắc việc chỉ viết các bài kiểm thử này cho các phương thức chứa business logic.

Nếu bạn chưa bao giờ viết một bài unit test, lời khuyên là bạn nên bắt đầu bằng việc thử nghiệm các phương pháp nhất định.

Các bài kiểm thử mô-đun có thể hơi gian nan, phức tạp hơn – đặc biệt nếu chúng có nhiều thành phần phụ thuộc.

Quan trọng nhất là các bài kiểm thử của bạn bao quát hết logic quan trọng nhất và giúp cải thiện chất lượng code của mình
Quan trọng nhất là các bài kiểm thử của bạn bao quát hết logic quan trọng nhất và giúp cải thiện chất lượng code của mình. Ảnh: freepik

Để viết được các bài unit test hiệu quả, bạn sẽ cần tách code của mình đúng cách. Hãy tuân theo nguyên tắc SOLID.

Việc tách dự án của bạn thành các lớp khác nhau bằng cách sử dụng kiến ​​trúc đa tầng (multitier architecture) chẳng hạn, cũng có thể giúp việc kiểm thử ứng dụng dễ dàng hơn.

Theo Stein Janssen

Categories
Dev's Corner

4 Khóa học Automation Testing miễn phí hàng đầu về Selenium và Cucumber

Kiểm thử là một phần không thể thiếu trong quá trình phát triển phần mềm. Chúng ta từ lâu luôn dựa vào kiểm thử thủ công được thực hiện bởi các tester và QA chuyên nghiệp để tìm lỗi và mang đến phần mềm chất lượng.

Song, hiện nay, kiểm thử tự động (automation testing) ngày càng được chú trọng bởi tính bền vững của nó. Trong đó, Selenium WebDriver của Selenium đang là một trong những xu thế hàng đầu.

Bạn đã biết nhiều về Selenium chưa
Bạn đã biết nhiều về Selenium chưa? Ảnh: Christopher Gower – Unsplash

Selenium là một công cụ kiểm thử tự động miễn phí cho các ứng dụng web. Nó có thể hoạt động với các trình duyệt web khác nhau như Chrome, Firefox, Internet Explorer, Opera và mô phỏng hành vi giống con người.

Sử dụng Selenium, bạn có thể tương tác với tất cả các phần tử khác nhau trên trang web: nhấp vào, nhập hay trích xuất văn bản, v.v.

Selenium cũng hoàn toàn khác với các công cụ kiểm thử tự động khác như QTP, Win Runner, Load Runner, v.v., vì nó cho phép bạn ghi lại và phát lại cho mục đích kiểm thử tự động.

Selenium cung cấp một API cho phép tự động hóa mọi thứ trên một trang web. Bạn có thể kiểm tra xem một phần tử có tồn tại hay không hoặc một phần tử có giá trị gì.

Selenium cũng cho phép kiểm thử bất kỳ loại trang web nào được viết bằng ngôn ngữ gì như PHP, Perl, Python, Java, C#, v.v.

Nó hỗ trợ nhiều trình duyệt như Chrome, Firefox, Internet Explorer, Safari và Opera. Điều này có nghĩa là bạn có thể tự động kiểm thử ứng dụng của mình trên nhiều trình duyệt.

Ngoài ra, bạn có thể sử dụng Selenium cho các bài kiểm thử tự động trên nhiều ngôn ngữ như Java, C #, Perl, Python, v.v., nhưng 90% các công ty sử dụng Selenium với Java.

Vậy nên, nếu đang là manual tester và muốn học thêm Selenium để kiểm thử tự động, bạn nên học về Java.

Còn chờ gì nữa, hãy cùng Gambaru khám phá các khóa học tuyệt vời và hoàn toàn miễn phí sau cho mục đích trên!

Các khóa học Automation Testing (Selenium, Cucumber)

1. Selenium với C# và Java Titbits

Đây là một khóa học miễn phí về Selenium, giải thích một số khái niệm về Selenium trong Java và C# với các ví dụ ngắn.

Hầu hết các chủ đề đều bắt nguồn từ các câu hỏi trên Stack Overflow nhưng tựu chung, các kiến thức đều có giá trị và quan trọng nhất là nó miễn phí.

Nó sẽ giúp bạn hiểu những gì đang diễn ra khi dùng Selenium và các chi tiết cơ bản phải biết trước khi thực hiện các dự án lớn hơn sử dụng Selenium (ví dụ như framework development).

Bạn sẽ học cách làm việc với các trình duyệt khác nhau với Selenium Java web driver, cách tìm và làm việc với control, sử dụng explicit wait và implicit wait, chụp màn hình bằng Selenium và kiểm tra xem control có tồn tại với Selenium hay không.

Một khóa học thực hành hiệu quả về Selenium dùng Java và C#
Một khóa học thực hành hiệu quả về Selenium dùng Java và C#! Ảnh: freepik

Bạn cũng sẽ học cách kéo và thả, cách di và nhấp chuột bằng Selenium và làm việc với popup windowXPath.

Khóa học cũng giải thích cách cấu hình Selenium grid và thiết lập thực thi song song (parallel execution) bằng Java.

Lưu ý, các bài học tập trung vào Java nhiều hơn là C#.

2. Cucumber với Selenium Java (Cơ bản)

Đây là một khóa học Selenium miễn phí khác trên Udemy của cùng tác giả Karthik KK, người đã tạo ra khóa học phía trên, nó cung cấp những giải thích tường tận hơn về Cucumber và Phát triển theo hướng hành vi (Behavior-driven Development – BDD) cùng với Selenium.

Khóa học được chia thành hai phần.

  • Trong phần đầu tiên, bạn sẽ học các bài vỡ lòng về Cucumber và Behavior-driven Development.
  • Phần thứ hai tập trung vào Selenium với Cucumber, cách code đơn giản cho Selenium với Cucumber và cách tương tác với Page Object Model. Bạn cũng sẽ học cách chạy Selenium với Cucumber thông qua Maven và thực hiện kiểm thử với Cucumber thông qua TestNG. Khóa học cũng dạy báo cáo bằng Cucumber cho Selenium.
Đăng ký nếu bạn muốn một khóa học hiệu quả về Cucumber và Selenium trong thời gian ngắn
Đăng ký nếu bạn muốn một khóa học hiệu quả về Cucumber và Selenium trong thời gian ngắn. Ảnh: Pexels

3. Selenium WebDriver với C# cho người mới bắt đầu + Live Testing Site

Khóa học Selenium miễn phí này tập trung vào demo trực tiếp và thực hành
Khóa học Selenium miễn phí này tập trung vào demo trực tiếp và thực hành. Ảnh: Unsplash

Đây là một trải nghiệm học tập thú vị dành cho manual tester và QA chưa có kinh nghiệm về Selenium.

Trong khóa học này, bạn sẽ học Kiểm thử chức năng và giao diện đồ họa người dùng và cách làm việc với các selector của Selenium, ví dụ: Name selector, ID Selector, Class Name selector, CSS Path selector, và XPath selector.

Tiếp theo, bạn sẽ học cách làm việc với một số phần tử HTML phổ biến như Input text box, Checkbox, Radio button, Dropdown menu, và JavaScript Alert box.

Ngoài ra, khóa học còn cung cấp một vài bài giảng lý thuyết về việc khi nào bạn nên sử dụng selector nào, cách kiểm tra các phần tử, Automation Testing Framework là gì và tại sao chúng ta cần tạo nó.

4. Cucumber, Selenium & Java – Tạo một Framework trong 2,5 giờ!

Bạn có phải là automation tester muốn đưa thêm kinh nghiệm về BDD hoặc Cucumber vào hồ sơ xin việc của mình? Nếu vậy, đây là khóa học không thể nào phù hợp hơn.

Bạn sẽ học Cucumber BDD từ cấp độ mới bắt đầu đến cấp độ tương đương nâng cao, sử dụng Selenium WebDriver và Java.

Bạn cũng có thể học cách phát triển các Cucumber framework nhỏ và mạnh cho BDD.

Khóa học cũng sẽ dạy về Gherkin, Maven, Eclipse và các công cụ liên quan khác để bạn làm việc hiệu quả hơn với Selenium và Cucumber và trở thành một kỹ sư QA về kiểm thử tự động thành công.

Thành công với Automation Testing
Chúc bạn ngày một thành công với Automation Testing! Nguồn ảnh: freepik

Theo javinpaul

Categories
Dev's Corner

Cộng đồng PHP: Mâu thuẫn và Tầm nhìn

Một bài viết tâm huyết từ một lập trình viên PHP. Dù bạn là developer trẻ, đang có hứng thú với ngôn ngữ lập trình này, hay một leader nhiều năm kinh nghiệm, hãy cùng Gambaru nhìn nhận góc nhìn của Neal và thảo luận ở phần comment cuối bài viết nhé.

Bạn có quan tâm về lập trình PHP?
Bạn có quan tâm về lập trình PHP? Ảnh: Pixabay – Pexels

Tôi đã lập trình với PHP được khoảng 7 năm, tự mình mày mò, khám phá về các framework, library, hệ sinh thái xung quanh các nền tảng quản lý nội dung, và quen biết một cộng đồng đông đảo lập trình viên PHP.

Rất nhiều người đã trở thành những người bạn thực sự và theo đánh giá của các bài phát biểu tại các diễn đàn tôi từng tham dự, tôi biết mình không đơn độc khi tin rằng chúng tôi có thể giúp mọi người cùng học hỏi và phát triển, xây dựng phần mềm tốt hơn, cũng như chung tay hỗ trợ lập trình viên tiến xa hơn trong sự nghiệp.

Ngôn ngữ PHP thường bị chỉ trích và chế nhạo bởi những lập trình viên cho rằng ngôn ngữ chúng ta lựa chọn chẳng khác gì một mớ hỗn độn và chỉ dân nghiệp dư mới sử dụng PHP.

(Có thể quan điểm này có lý trong quá khứ, nhưng bây giờ chỉ có người thiếu hiểu biết mới tranh luận như vậy, đặc biệt khi sự thật là PHP 7 đã đóng góp rất nhiều để giúp PHP trở thành một ngôn ngữ hoàn thiện hơn).

Tuy nhiên, cộng đồng PHP chẳng ngán gì “dăm ba lời khen chê này”, họ ngày càng bản lĩnh hơn và tiếp tục xây dựng các sản phẩm, thư viện, công cụ và tính năng mới.

Trong bài viết này, tôi muốn nói đến mâu thuẫn ngày càng gia tăng trong chính cộng đồng PHP, giữa những nhóm lập trình viên ủng hộ giữa các framework Laravel, Symfony và Doctrine ORM.

Nhiều người chuộng Symfony/Doctrine đưa ra những nhận xét chê bai về Laravel.

Đáp lại, những người ủng hộ Laravel dường như ngày càng trở nên chống đối và có xu hướng phản ứng quyết liệt với những lời chỉ trích (dù mang tính xây dựng hay không). 

Mâu thuẫn ngay trong chính cộng đồng PHP
Mâu thuẫn ngay trong chính cộng đồng PHP. Ảnh: freepik

Tôi chắc chắn rằng hầu hết lập trình viên chúng ta đều đã từng bị chỉ trích về cách mình code.

Chỉ trích cũng có đủ loại, có thể là “Cái quái gì thế này?” hoặc “Anh nên thử áp dụng các nguyên tắc SOLID / [x design pattern] ở đây, vì nó sẽ tiết kiệm thời gian và đỡ phải bực mình sau này đấy”.

Cách ta đưa ra và đón nhận phê bình đặt nền tảng cho cách ta phát triển như một nhà lập trình chuyên nghiệp cũng như sự nhìn nhận của những người xung quanh.

Đối với những người lãnh đạo, nó xác định cách những người theo gương và tôn trọng bạn cư xử ra sao đối với đồng nghiệp của họ.

Hiện nay, ta có thể thấy các lập trình viên ở vị trí Senior, các leader dự án và những nhân vật có tầm ảnh hưởng tham gia vào các cuộc tranh luận công khai trên các nền tảng như Twitter và Reddit.

Bạn đọc được những bình luận có tính gây hấn về khả năng mở rộng của dự án với framework x hoặc phương thức của library y chứa bao nhiêu dòng code.

Họ làm như vậy chẳng để đạt được điều gì ngoài việc thuyết phục người đọc rằng họ đã đúng khi không dùng những framework hay tool này.

Tóm lại, khi cứ mãi tranh luận như vậy, chúng ta đang cướp đi cơ hội của những lập trình viên ít kinh nghiệm hơn để thử nghiệm và trải nghiệm các cách tiếp cận khác nhau đối với các giải pháp chung.

Chúng ta phủ nhận họ có khả năng thoải mái thể hiện quan điểm và thảo luận về những cái lợi và hại của mỗi framework mà không sợ bị chế giễu.

Chúng ta ngăn họ đánh giá và học cách chọn công cụ phù hợp cho từng công việc cụ thể.

Chúng ta dần dần ngăn cản tiến trình sự nghiệp của họ. Điều này tạo ra một rào cản có hại cho họ và cho cả chúng ta như một hệ sinh thái của những nhà lập trình PHP.

Hãy nói về Symfony và Laravel nàoHãy nói về Symfony và Laravel nào
Hãy nói về Symfony và Laravel nào! Ảnh: Pixabay – Pexels

Về cá nhân mình, Symfony là framework ưa thích của tôi, nhưng tôi đã làm việc chuyên nghiệp với cả Laravel [versions 4 & 5] và Zend.

Symfony sử dụng Doctrine 1, triển khai ActiveRecord pattern, bao gồm rất nhiều tính năng bổ sung theo mặc định và khiến việc liên kết business logic với framework trở nên cực kỳ dễ dàng.

Là một opinionated framework (có tính quy chuẩn và áp đặt), Symfony đặt ra các công cụ nó mong đợi bạn sử dụng ngay trước bạn và cho phép bạn nhanh chóng bắt đầu công việc.

Symfony 2 bắt đầu thay đổi tất cả những điều đó.

Lập trình viên sử dụng Symfony muốn có nhiều sự lựa chọn và tính linh hoạt hơn khi chọn các công cụ và những gì cần đưa vào dự án. Họ muốn đưa các thư viện khác vào dễ dàng hơn nếu giải pháp ban đầu không còn ổn nữa.

Symfony đã phát triển rất nhanh giữa các phiên bản 1 và 2 và trở nên khác biệt so với phiên bản ban đầu.

Nó chuyển từ một framework cố định với tất cả các công cụ được đóng gói bên trong và một mức độ chưa đủ tinh vi sang khả năng tương tác với các gói bên ngoài Symfony.

Symfony đã đi một chặng đường dài để chuyển mình thành một tập hợp các gói và thành phần có thể tái sử dụng và việc kết hợp các đề xuất của PHP-FIG có nghĩa là các thành phần có thể dễ dàng được đưa vào các framework, library và hệ thống CMS khác.

Lập trình viên sử dụng Symfony có quyền tự hào về Symfony và mong muốn chia sẻ cách họ làm được điều đó.

Phần lớn các nhà lập trình tôi biết đồng tình rằng tài liệu của Laravel dễ tiếp cận hơn của Symfony và cũng dễ bắt đầu với Laravel hơn nhiều.

Ngày nay, Laravel có tính áp đặt hơn Symfony, vì vậy, tài liệu hướng dẫn có thể ít trừu tượng hơn và trực tiếp hơn về cách đạt được mục tiêu với các công cụ được cung cấp.

Người ta thường có xu hướng gán Laravel là framework cho người mới bắt đầu hoặc chỉ là một công cụ cho RAD (Rapid Application Development – phát triển ứng dụng / tạo mẫu nhanh) và khuyên không dùng nó cho các dự án phức tạp hơn.

Tất nhiên, phản ứng từ người dùng Laravel là sau đó sẽ là “Chà, nó đã được sử dụng trên trang x đó nhe!”.

Người dùng Doctrine phản ứng lại “Tụi tôi đã bỏ ActiveRecord từ lâu rồi, ORM của mấy ông phèn quá”, và rồi bên kia tiếp “Muốn cãi nhau về facade pattern thật sao?”, rồi lại một hồi dài tranh cãi.

Than phiền duy nhất của tôi về Laravel Eloquent là việc thêm các foreign key và index vào cơ sở dữ liệu sẽ tốn nhiều công sức hơn.

Tôi nghĩ đây là điều có độ ưu tiên cao khi thiết kế cấu trúc dữ liệu. Tôi đã kế thừa nhiều dự án Laravel bởi các công ty khác nhau, và không có dự án nào trong số đó có một foreign key hoặc index nào.

Điều này dẫn đến mất tính toàn vẹn của dữ liệu cũng như các vấn đề khác về hiệu suất.

Tôi cũng cảm thấy rằng Laravel và nhiều tài nguyên hướng dẫn về nó khuyến khích người dùng liên kết code ràng buộc với framework.

Một dev ở công ty tôi từng làm việc đã dành hàng tháng trời làm một việc đáng ra rất đơn giản là nâng cấp Laravel 4 lên Laravel 5. Anh chàng sao chép và viết lại các file và file logic được đặt trong controller.

Nếu như code được tách ra thì công ty hẳn sẽ chi ít tiền hơn cho việc nâng cấp này và anh ấy đã có thể chuyển sang phát triển tính năng mới sớm hơn nhiều.

Theo tôi, Laravel có thể được sử dụng cho các ứng dụng quy mô lớn, nhưng trừ khi lập trình viên đủ kinh nghiệm để biết những gì họ đang tìm kiếm trong tài liệu để cho phép scale ứng dụng, họ có thể sẽ không dùng Laravel.

Phải thừa nhận rằng rất dễ để liên kết code với Symfony controller, nhưng cộng đồng Symfony biết rằng làm như vậy là một ý tưởng tồi.

Theo trải nghiệm riêng, tôi chưa thấy người dùng Symfony chế nhạo ý tưởng tách code nhưng tôi thấy một số người dùng Laravel chế giễu cách làm này.

Dấu hiệu của một vấn đề sâu xa hơn
Tuy nhiên, tranh luận về việc này chỉ là một dấu hiệu của một vấn đề sâu xa hơn. Ảnh: Pixabay – Pexels

Lập trình viên chúng ta thường đưa ra lựa chọn về các công cụ yêu thích và hợp tác với những người khác đã giải quyết các vấn đề tương tự theo cùng cách.

Khi hạn chế bản thân bằng cách liên tục sử dụng những gì chúng ta biết và ở trong cộng đồng những người có cùng tư duy và ý tưởng, chúng ta hạn chế cách mình code và cả con đường sự nghiệp.

Tự ta buộc xích vào chân mình.

Việc ta giải quyết vấn đề theo một cách không nhất thiết có nghĩa là cách tiếp cận của người khác tốt hơn hay tệ hơn mà chỉ là chúng khác nhau mà thôi
Việc ta giải quyết vấn đề theo một cách không nhất thiết có nghĩa là cách tiếp cận của người khác tốt hơn hay tệ hơn mà chỉ là chúng khác nhau mà thôi. Ảnh: cottonbro – Pexels

Điều khiến tôi lo lắng nhất là ảnh hưởng mà chúng ta có thể có đối với lựa chọn của các lập trình viên trẻ, ít kinh nghiệm.

Có lẽ ai cũng đều cảm thấy hài lòng khi khuyên bảo một người và sau đó thấy họ nối gót mình.

Tuy nhiên, điều ta không nên làm là khuyến khích lập trình viên trẻ tuổi đừng thử nghiệm framework x hoặc y, đừng học lập trình ngôn ngữ z vì những thành kiến ​​của riêng mình. 

Hãy để người trẻ tự thử nghiệm và cho họ lời khuyên
Hãy để người trẻ tự thử nghiệm và cho họ lời khuyên. Ảnh: Arijit manna -Unsplash

Hãy để người trẻ tự thử nghiệm và cho họ lời khuyên. Hãy quan sát cách một người đưa ra và đón nhận chỉ trích.

Hãy nghĩ thử “Đây có phải là loại phản hồi đóng góp tích cực cho cộng đồng không? Đây có phải là mẫu người tôi nên lấy làm gương không? ”

Với tư cách là một leader, hãy tự hỏi bản thân “Tôi có đang buộc chiếc xích của chính mình vào chân những người xung quanh không? Tôi có ảnh hưởng tiêu cực đến người khác thông qua sự lựa chọn của chính mình không? ”

Các cuộc tranh luận gay gắt không có tác dụng gì trong việc thúc đẩy sự nghiệp chung của cộng đồng lập trình viên mà chỉ khiến mọi người e ngại gia nhập cộng đồng PHP toàn cầu mà thôi.

Theo Neal Brooks