Trong kỷ nguyên số, công cụ tìm kiếm đã trở thành một phần không thể thiếu trong cuộc sống của chúng ta. Google đã trở thành công cụ tìm kiếm thống lĩnh thị trường trong nhiều năm qua. Tuy nhiên, sự xuất hiện của SearchGPT, một công cụ tìm kiếm mới dựa trên trí tuệ nhân tạo (AI), đang hứa hẹn sẽ mang đến một cuộc cách mạng trong lĩnh vực này. Cùng TopDev tìm hiểu thật cặn kẽ về SearchGPT và có khác biệt nổi bật nào so với Google Search không nhé.
SearchGPT là gì?
SearchGPT là công cụ tìm kiếm sử dụng trí tuệ nhân tạo (AI) được phát triển bởi OpenAI – ra mắt chính thức vào 25/7/2024. Khác với các công cụ tìm kiếm truyền thống chỉ đơn thuần liệt kê các liên kết, SearchGPT sử dụng công nghệ AI để hiểu sâu hơn về ý định của người dùng và cung cấp các câu trả lời trực tiếp, tổng hợp từ nhiều nguồn thông tin khác nhau.
SearchGPT có khả năng truy vấn thông tin theo thời gian thực, truy cập được link gốc, tăng độ tin cậy của kết quả trả về.
Ngay sau khi SearchGPT ra mắt cổ phiếu công ty Alphabet (công ty mẹ của Google) bốc hơi 3% – tương đương hơn 60 tỷ USD, nhìn vào đây ta đủ thấy SearchGPT là một đối thủ đáng gờm mà Google phải dè chừng.
Những tính năng nổi bật của SearchGPT
SearchGPT, với sự kết hợp tinh tế giữa công nghệ tìm kiếm truyền thống và trí tuệ nhân tạo tiên tiến, đã tạo nên một bước đột phá trong việc truy xuất thông tin. Dưới đây là những đặc điểm nổi bật làm nên sự khác biệt của công cụ này:
Độ chính xác của thông tin cao
Search GPT được xây dựng trên mô hình LLM hiện đại nhất của Open AI hiện tại là GPT-4. Vì vậy nguồn tài nguyên sẽ không bị giới hạn và lấy được những thông tin mới nhất theo thời gian thực tế.
Để tránh vấn đề “ảo giác AI” mà cái AI model hiện tại đang mắc phải thì Search GPT kết nối với các nhà xuất bản, bản tin, cơ quan truyền thông bằng cách trích dẫn nội dung và gắn đường dẫn liên kết đến các bài báo.
Khả năng hiểu sâu ý định người dùng
Không chỉ đơn thuần là một công cụ tìm kiếm các từ khóa, SearchGPT có khả năng hiểu ngữ cảnh một cách sâu sắc. Công cụ này có thể nắm bắt được ý nghĩa ẩn sau câu hỏi, thậm chí cả những câu hỏi phức tạp, đòi hỏi sự suy luận logic và tổng hợp thông tin đa chiều. Nhờ đó, người dùng có thể đặt câu hỏi một cách tự nhiên, gần gũi với ngôn ngữ giao tiếp hàng ngày.
Cung cấp câu trả lời toàn diện và trực quan
Thay vì liệt kê một danh sách dài các liên kết như Google search, hay chỉ đưa ra câu trả lời được tổng hợp bằng AI, SearchGPT tổng hợp thông tin từ nhiều nguồn đáng tin cậy để đưa ra một câu trả lời ngắn gọn, súc tích và dễ hiểu và có gắn thêm nguồn tham khảo để tăng độ tin cậy và tính xác thực của thông tin. Ngoài văn bản, công cụ này còn có khả năng trình bày kết quả dưới dạng hình ảnh, video, đồ thị, giúp người dùng tiếp cận thông tin một cách trực quan và sinh động hơn.
Khả năng học hỏi và phát triển không ngừng
SearchGPT được xây dựng trên nền tảng của các thuật toán học máy tiên tiến, cho phép công cụ này tự học và cải thiện khả năng hiểu ngôn ngữ và cung cấp thông tin chính xác qua thời gian. Nhờ đó, SearchGPT ngày càng trở nên thông minh hơn và đáp ứng tốt hơn nhu cầu của người dùng. Nếu bạn bắt đầu và đang thảo luận về điện thoại iPhone của Apple thì những truy vấn tiếp theo SearchGPT sẽ tự hiểu được Apple đang nhắc đến là hãng điện thoại chứ không phải quả táo.
Việc ra mắt SearchGPT không chỉ là bước đột phá của OpenAI mà còn đặt ra thách thức lớn đối với Google, cùng xem hai công cụ tìm kiếm này có điểm gì khác nhau trong bảng tổng hợp dưới đây:
Tính năng
Google Search
SearchGPT
Cách thức hoạt động
Liệt kê các liên kết đến các trang web có liên quan
Hiểu ý định của người dùng và cung cấp câu trả lời trực tiếp
Kết quả tìm kiếm
Các trang web
Câu trả lời tổng hợp, các đoạn trích văn bản, liên kết đến các trang web có liên quan
Giao diện
Đơn giản, tập trung vào các liên kết
Thân thiện hơn, giao diện dạng chat, tăng tính tương tác.
Công nghệ
Dựa trên thuật toán PageRank và Machine Learning để xếp hạng các trang web.
Sử dụng AI để hiểu ngữ cảnh, trả lời câu hỏi phức tạp
Độ chính xác thông tin
Cung cấp thông tin cập nhật và chính xác hơn nhờ vào việc thu thập dữ liệu liên tục
Phụ thuộc vào thông tin đầu vào của model, có thể không cập nhật thông tin mới nhất
Khả năng xử lý
Không thể trả kết quả đúng với những truy vấn phức tạp.
Xử lý được dễ dàng các câu hỏi phức tạp và có thể giải thích chi tiết hơn nữa.
Cách sử dụng Search GPT đơn giản nhất
Hiện tại, Search GPT đang chỉ là phiên bản dạng “nguyên mẫu” và có khoảng 10,000 người dùng được đăng ký trải nghiệm sản phẩm. Hiện tại số lượng người trải nghiệm đã đủ, ở đây TopDev vẫn sẽ hướng dẫn các bước sử dụng SearchGPT dựa vào thông tin được publish bởi Open AI.
Bước 1: Bạn có thể vào website: chatgpt.com/search để đăng nhập hoặc đăng ký (nếu bạn đã có tài khoản chatGPT, có thể đăng nhập bằng tài khoản này)
Bước 2: Sau khi đăng ký thành công, bạn đăng nhập vào tài khoản đã được xác nhận trên website SearchGPT.
Bước 3: Nhập truy vấn vào ô “What are you looking for?” và nhấn Enter để đi đến kết quả tìm kiếm
Bước 4: Search GPT sẽ trả lại kết quả đã được AI tóm tắt từ những nguồn uy tín kèm theo nguồn link gốc của thông tin.
Bước 5: Bạn có thể tiếp tục hỏi thêm những thông tin chuyên sâu về chủ đề tìm kiếm trong chatbox tại ô “Ask a follow-up…”.
Dù hiện tại SearchGPT chỉ là một nguyên mẫu thử nghiệm tuy nhiên với những tính năng nổi bật như đã nêu trên chắc hẳn SearchGPT sẽ là một mô hình tìm kiếm bằng AI được nhiều người dùng ưa chuộng. Sự ra mắt của SearchGPT cũng đánh dấu thêm một bước ngoặt quan trọng trong cuộc cạnh tranh khốc liệt giữa OpenAI và Google. Theo dõi TopDev để cập nhật những tin tức mới nhất về công nghệ bạn nhé!
Bài viết được sự cho phép của tác giả Nguyễn Thành Nam
Nếu bạn đang định xây dựng tính năng để tính toán khoảng thời gian tương đối (như “sau 3 ngày nữa”, “4 tháng trước”, “1 phút trước”) mà không cần sử dụng thư viện bên ngoài?
Trong bài viết này, chúng ta sẽ tìm hiểu về Intl.RelativeTimeFormat, một tính năng để định dạng thời gian tương đối (hỗ trợ nhiều ngôn ngữ) trong JavaScript.
I. Giới thiệu về Intl.RelativeTimeFormat
Intl.RelativeTimeFormat là một phần của bộ công cụ quốc tế hóa (i18n – Internationalization) trong JavaScript. Nó cho phép bạn định dạng các khoảng thời gian tương đối (như “sau 3 ngày nữa”, “4 tháng trước”, “1 phút trước”) một cách dễ dàng và chính xác. Đặc biệt nó có hỗ trợ hiển thị nhiều ngôn ngữ khác nhau và bạn cũng không cần sử dụng thư viện bên ngoài để xử lý.
Tại sao nên sử dụng Intl.RelativeTimeFormat?
Hỗ trợ đa ngôn ngữ:Intl.RelativeTimeFormat hỗ trợ nhiều ngôn ngữ (bao gồm cả tiếng việt).
Đơn giản và dễ sử dụng: Đối tượng này cung cấp các phương thức để định dạng thời gian tương đối mà không cần phải tự viết các chức năng phức tạp.
Đảm bảo tính chính xác: Định dạng chính xác và phù hợp với ngữ cảnh văn hóa của từng ngôn ngữ.
II. Cách sử dụng Intl.RelativeTimeFormat
⚡️ Tạo đối tượng Intl.RelativeTimeFormat
Để sử dụng Intl.RelativeTimeFormat, bạn cần tạo một đối tượng mới từ lớp này. Dưới đây là cú pháp cơ bản:
Một số câu hỏi thường gặp khi sử dụng Intl.RelativeTimeFormat (FAQs)
Intl.RelativeTimeFormat là gì? Intl.RelativeTimeFormat là một API trong JavaScript cho phép định dạng thời gian tương đối cho nhiều ngôn ngữ khác nhau.
Làm thế nào để tạo đối tượng Intl.RelativeTimeFormat? Bạn có thể tạo đối tượng bằng cách sử dụng cú pháp new Intl.RelativeTimeFormat('vi', { numeric: 'auto' }).
Có thể sử dụng Intl.RelativeTimeFormat cho những đơn vị thời gian nào? Intl.RelativeTimeFormat hỗ trợ các đơn vị thời gian như giây, phút, giờ, ngày, tuần, tháng, quý, và năm.
Các tùy chọn định dạng của Intl.RelativeTimeFormat là gì? Các tùy chọn bao gồm numeric (always, auto) và style (long, short, narrow).
Có thể kết hợp nhiều tùy chọn khi sử dụng Intl.RelativeTimeFormat không? Có, bạn có thể kết hợp các tùy chọn để đạt được định dạng mong muốn cho từng ngữ cảnh cụ thể.
VII. Kết luận
Intl.RelativeTimeFormat là một công cụ mạnh mẽ và dễ sử dụng để định dạng thời gian tương đối trong JavaScript. Bằng cách hỗ trợ nhiều ngôn ngữ và cung cấp các tùy chọn định dạng linh hoạt, nó giúp việc quốc tế hóa ứng dụng của bạn trở nên dễ dàng hơn. Hãy thử áp dụng Intl.RelativeTimeFormat vào dự án của bạn và trải nghiệm sự tiện lợi mà nó mang lại!
Hy vọng bài viết này đã giúp bạn hiểu rõ hơn về cách sử dụng Intl.RelativeTimeFormat trong JavaScript.
Mình từng gặp một trường rất trớ trêu: dự án đã đóng rồi, hợp đồng thì cũng đã thanh lý, nhưng mình cứ bị kẹt vô thế nửa nạc nửa mỡ.
Số là dự án đã qua 3 tháng bảo hành và đã đóng hoàn toàn dựa trên hợp đồng. Nhưng khách hàng thì cứ ỡm ờ. Lúc thì nói muốn ký gói bảo hành một năm, lúc thì không thấy đá động phản hồi gì hết.
Mà oải cái là anh chàng Contact Point bên khách hàng cứ lâu lâu nhắn mình, nhờ support cái này, cái kia.
Về lý, team mình không việc gì phải tiếp tục support. Nếu muốn support, khách hàng phải ký hợp đồng Maintenance, không nói nhiều.
Về tình, team mình không thể nói không support, vì còn phải giữ mối quan hệ cho những deal sau này (rất có thể là những deal lớn). Đặc biệt là khi họ đang nửa nạc nửa mở nói muốn ký tiếp hợp đồng Maintenance. Nghĩa là miếng ăn đang cận kề trước mặt…, nên không nỡ phũ được.
Nếu tạm bỏ qua các quyết định về lãi lỗ (vì có thể ký hợp đồng maintenance nhưng team mình vẫn lỗ), thì dưới vai trò BA, anh em sẽ giải quyết vấn đề này như thế nào?
Rõ ràng anh em phải ra quyết định đúng không nào: Support hay không support, không support hay support nói một lời.
Ngoài ra, anh em vẫn có thể raise lên để mấy sếp giải quyết. Quyết định nào cũng có cái lợi, cái hại. Nó tùy thuộc vào anh em. Kỹ năng ra quyết định của mình là ở chỗ này.
Dự án sau đó có êm hay không, mọi người có còn happy với nhau hay không chính là nằm ở những quyết định của mình trong dự án.
Như mình, mình không thích ỡm ờ, nhưng vì “một lý do nào đó”, khách hàng không rõ ràng, hoặc “không muốn rõ ràng”. Tuy nhiên, nếu khách hàng muốn nửa nạc nửa mỡ, thì mình cũng sẽ nửa nạc nửa mỡ. Thích ba rọi, thì có ngay ba rọi.
Những điểm nào mình có thể trả lời ngay, “low_energy”, thì mình hoàn toàn có thể support họ. Còn những vấn đề khác phức tạp hơn, đòi hỏi “high_energy” hơn thì mình sẽ tìm cách từ chối khéo.
Và mình cũng sẽ linh động từng case, theo khả năng có thể phát sinh thêm những issue khác. Cố gắng triệt để những vấn đề này. Vì nếu có ký maintenance thì team mình cũng sẽ là bên phải giải quyết.
Nên dù gì người được lợi nhất vẫn là cả khách hàng và team dự án mà thôi 🙂
Đây chỉ là cách để mình dung hòa mối quan hệ và lợi ích của 2 bên. Và nó có khoảng thời gian nhất định, chứ không thể kéo dài suốt được. Đặt một hạn chót, và cho khách hàng “chỉ được ỡm ờ” tối đa trong khoảng thời gian này. Sau thời gian này, mọi thứ cần phải rõ ràng.
…
Trên là ví dụ điển hình gần đây nhất mình gặp phải. Còn anh em gặp trúng những ca củ chuối nào, kể bên dưới còm men nhé.
Rõ ràng là xuyên suốt dự án có rất nhiều trường hợp mà anh em BA phải ra quyết định một mình.
Kỹ năng giải quyết vấn đề thì luôn đi kèm với kỹ năng ra quyết định. Còn việc ra quyết định thì luôn đi kèm với hai chữ “trách nhiệm” 🙂
Đừng để người khác phải đổ vỏ cho những quyết định của mình, meo meo…
Mỗi quyết định đưa ra đều dẫn đến một cánh cửa nào đó.
Cửa dẫn dự án đến đích có, dẫn xuống vực cũng có. Một lần nữa, đi cánh cửa nào là tùy vào kinh nghiệm và khả năng chịu khó quan sát, học hỏi của chính bản thân mình.
Nên làm để rèn luyện
✅ Chịu khó quan sát, hỏi người khác vì sao họ lại làm như vậy.
✅ Xông pha nhận các dự án mới, task mới.
✅ Dám làm những cái mới >> dễ sai >> dám nhận trách nhiệm >> học cái sai >> có kinh nghiệm >> lần sau quyết định đỡ sai hơn.
✅ Nên có mentors cho mình.
✅ Tập hỏi 5 Whys cho các vấn đề cá nhân thường ngày.
✅ Chịu khó đọc sách(học được nhiều câu từ, cách diễn giải hay >> tăng khả năng ăn nói, diễn đạt hiệu quả hơn).
✅ Suy nghĩ kỹ trước khi nói. Đặc biệt là những anh em hay hấp tấp như mình, và cả những anh em hay nóng tính.
✅ Tải game Plant vs. Zombies 2, Clash Royale, Football Manager… về chơi, hoặc các game puzzle, chiến thuật khác >> tăng khả năng tư duy logic, dàn xếp đội hình.
✅ Tập vẽ mind map.
✅ Ngủ sớm, dậy sớm >> tỉnh táo hơn >> quyết định sáng suốt hơn >> vấn đề được giải quyết tốt hơn.
✅ Ăn trái cây nhiều >> tránh lão hóa, tăng đẹp chai, cu te, tăng độ minh mẫn, suy nghĩ thấu đáo hơn.
✅ Chơi đá banh, nhảy dây, bắn thun các kiểu…, miễn là thể thao lành mạnh.
1.5. System Thinking
Kỹ năng cuối cùng trong nhóm Analytical Thinking đó là System Thinking 😎
System Thinking nghĩa là Tư duy hệ thống.
Tư duy hệ thống là khi mình hiểu và nhìn nhận vấn đề trên một góc nhìn tổng quan nhất. Để khi có một vấn đề phát sinh, tư duy hệ thống sẽ giúp chúng ta hầu như tự động nhìn nhận được những thứ bên trong hoặc những thứ liên quan đến đối tượng đó, mà có thể bị tác động. Từ đó tính toán hay làm gì tiếp là tùy vào anh em.
Như mình có note ở bài Bí kíp chân truyền của BA, cái quan trọng nhất là mình nhìn bất kỳ một hệ thống nào dưới góc độ các components và relationship giữa chúng với nhau.
Tư duy này giúp ích anh em BA rất nhiều trong quá trình làm dự án.
Ví dụ ngay lúc đầu, chúng ta vẽ ABCDEFGH để làm. Tầm 3 tháng sau, khách hàng thay F bằng K ==> vấn đề bắt đầu phát sinh.
Nếu không có tư duy hệ thống, chúng ta sẽ rất mịt mờ, và thường không có khuynh hướng cân nhắc xem thử:
Rút ông F ra, thế ông K vào thì nó sẽ ảnh hưởng gì tới những ông A, B, C, D, E, G, H còn lại.
Và ảnh hưởng gì tới nguyên cụm ABCDEFGH ban đầu?
Đây là việc anh em phải làm rất thường xuyên với bất kỳ change request nào, dù to hay nhỏ.
Do đó, những ai có tư duy hệ thống sẽ có khuynh hướng phân tích điều này một cách tự nhiên, đầy đủ và rõ ràng hơn bao giờ hết.
Sau cùng thì, những gì mình phân tích được sẽ giúp ích cho chính chúng ta.
Nên, tư duy theo hướng hệ thống là tốt, nhưng không phải là thứ bắt buộc, vì đâu ai kiểm chứng được là anh đã tư duy hệ thống hay chưa!?!?
Stakeholders chỉ quan tâm: có vấn đề mới nảy sinh đó, giờ BA nó trả lời như vầy, team nó xử lý như vầy ==> rồi kết qua đem lại có đáp ứng đúng kỳ vọng các bên hay không?
==> Người ta chỉ quan tâm kết quả sau cùng mà thôi.
Nên chuyện tư duy có tổng quát hay không không ai kiểm chứng được ngay, mà người ta chỉ dựa vào kết quả làm được.
Nên khi có vấn đề phát sinh, thường thì BA (đặc biệt là mình) sẽ có khuynh hướng “skip” qua bước này. Đặc biệt là lúc bị Mr. Deadline dí sát đít. Vì lo mà cắm đầu làm cho xong chứ ngồi đó tư duy với chả hệ thống@79mahf*#mjd@@….
Do đó qua bài note này, hi vọng anh em sẽ chú ý hơn về khoản này để tránh phiền hà về sau 🙂
…
Có những thứ tưởng như nhỏ nhặt nhưng phiền phức vô cùng.
Như trường hợp mình gặp: khách hàng đòi đổi một trường dữ liệu từ Option Set sang Multi Option Set. Cấu trúc dữ liệu thay đổi, chấp nhận. Nhưng đó chưa phải ác mộng.
Cái kinh khủng nhất là những report có dính tới field đó.
Lúc mình làm thì hệ thống không query data theo dữ liệu Multi Option Set được, nên không thể visualize lên report. Buộc phải dùng một field text trung gian >> copy giá trị trên field Multi Option Set đó ra field text >> rồi mới query data dựa tên field text này.
Và team phải làm như vầy cho… toàn bộ những field Option Set liên quan tới field mà khách hàng thay đổi, đắng lòng…
Do đó, nếu BA nhìn nhận vấn đề chưa đầy đủ, chưa thấy được những khía cạnh hoặc các thành tố khác có thể bị tác động ==> anh em team nhà sẽ rất dễ bị bóp.
Và quan trọng trên hết, anh em phải trang bị đủ kiến thức thì mới có được một góc nhìn bao quát và đầy đủ nhất được.
Nên làm để rèn luyện
✅ Phải trao đổi mọi thứ thật rõ ràng với team nhà trước khi confirm bất cứ thứ gì với khách hàng.
✅ Luôn phản hồi, nói cho người khác hiểu anh em đang nghĩ gì trong các buổi họp >> mọi người sẽ xem xét góc nhìn đó đã bao quát hay chưa, hay còn phiến diện quá. ==> Đi họp đừng có im im, ngồi rung đùi từ đầu tới cuối buổi nhé anh em (anh em tìm hiểu thêm về Thinking Out Loud)
✅ Đọc nhiều về lĩnh vực, sản phẩm mình đang làm.
✅ Quan sát xem những senior thường nghĩ gì khi có vấn đề phát sinh.
✅ Đa phần mọi người sẽ suy nghĩ rất phiến diện ==> thử suy nghĩ ngược 180 độ với hướng suy nghĩ của họ ==> anh em sẽ suy nghĩ bao quát hơn (ít nhất là so với người đó).
✅ Hằng ngày, đi ăn bún bò, hủ tiếu, đi uống cà phê, mua trà sữa, hoặc thấy cô lao công chùi nhà vệ sinh, hãy chú ý nhiều hơn tới quy trình công việc của họ.
✅ Tải game ăn cặp Pokemon, hoặc các game tìm điểm chung ==> tăng độ nhạy trong việc nhận diện điểm giống nhau ==> khả năng phát hiện ra các pattern trong đời sống xung quanh sẽ cao hơn.
✅ Lâu lâu thử tìm điểm chung giữa những phần mềm có trong trong điện thoại, giữa các loại xe máy trên đường, hoặc giữa mấy đứa bạn trẻ trâu xung quanh mình, xem thử những thứ đó có đặc tính gì giống nhau hay không.
2. Communication
Cuối cùng cũng đến, đó là nhóm các kỹ năng về giao tiếp 😎
Thường anh em sẽ chỉ chú ý đến chuyện giao tiếp qua đường nói thôi. Nhưng thực ra còn những khoản khác mình cũng cần chú ý như sau.
2.1. Verbal
Đầu tiên là đường nói.
Rõ ràng anh em BA chúng ta cần đường nói rất nhiều. Từ lúc elicit requirement, đến lúc trao đổi nội bộ, làm việc với đồng bọn ở nhà.
Nói không ai hiểu, coi như tèo.
Nói người ta hiểu sai ý, cũng tèo.
Nói một ý, nhưng phải diễn tả đi diễn tả lại 8 tỷ lần người ta mới hiểu, cũng tèo luôn.
Nói ẩn dụ nhiều quá, người ta tưởng mình đá đểu, cũng tèo luôn.
Đi cà phê với anh em, nói chuyện nhạt quá, không ai thèm chơi, thèm nói chuyện với mình ==> tèo của tèo luôn.
Đi lấy requirement, không dẫn dắt được buổi workshop, nội dung đi lệch hướng ==> tèo nguyên buổi workshop.
Gặp vấn đề, biết root cause ở đâu, thậm chí biết luôn cách giải quyết cho máu, nhưng không thể nào giải thích cho đồng bọn hiểu ==> cả đám cùng tèo.
…
Và còn hàng ngàn những ví dụ khác, mà khi anh em không giao tiếp tốt bằng đường nói, sẽ rất là ác mộng với người làm BA.
Có 2 điểm mình thấy rất quan trọng đối với đường nói, đó là: Âm điệu và Âm lượng.
Âm điệu của giọng nói là tiếng trầm bổng của giọng mình nói
Âm lượng của giọng nói là mình nói có nhỏ xí, lí nhí trong miệng không, hay mình nói to, rõ ràng…
Mình thấy 2 điều này là cực kỳ quan trọng. Vì nó phần nào sẽ giúp anh em thu hút được sự chú ý của người nghe.
Anh em thử để ý trong các buổi meeting, sẽ có những người nói mà chả có ma nào nghe. Những thanh niên này nói một hồi thì bà con mới để ý là… người đó đang nói.
Ngược lại, có những người, mà vừa mới mở miệng ra nói vài chữ, là đã thu hút được sự chú ý của đông đảo quần chúng nhân dân rồi.
Sự khác biệt do đâu?
Có thể người đó rất xịn xò mà ai cũng nể. Có thể là sếp, sếp của sếp, vợ của sếp, ghệ của sếp, vâng vâng.
Nhưng ngoài những yếu tố “nho nhỏ” trên thì theo mình quan trọng nhất vẫn nằm ở âm điệu và âm lượng của giọng nói.
Tuy nhiên, không phải cứ nói to, trầm, mạnh mẽ là sẽ thu hút được mọi người.
Mình có quen chị kia, hễ chỉ nói là đùng cái mọi người chú ý liền. Lạ lùng vậy đó. Mà được cái là chỉ nói không to, thậm chí là có phần hơi nhỏ, nhưng khi chỉ nói thì lại có sức hút lạ lùng.
Ngoài nội dung có giá trị cho người khác, thì đâu đó mình tin rằng âm điệu và âm lượng góp phần nhiều tạo nên “hiệu ứng thu hút” hiệu quả như vầy.
Nên làm để rèn luyện
✅ Phải tranh-thủ-từng-tí-cơ-hội-một để thuyết trình, nói chuyện trước đám đông. Đám càng đông, càng nguy hiểm >> càng tốt (vì đám đông sẽ phản hồi lại, chém lại, ném mắm tôm sầu riêng lại những gì anh em nói ==> anh em sẽ tập dần cách đỡ, cách phản hồi, và quan trọng nhất là cách xử lý của mình sẽ ngày một tốt hơn)
✅ Chịu khó đi hát ka ra ô kê với đồng bọn. Chú ý tập hát lấy hơi từ bụng, anh em sẽ hát khỏe hơn, nguy hiểm hơn, và lòe được nhiều người hơn 😎
✅ Đi cà phê thì chịu khó nói chuyện, chém gió với nhau ==> tập hình thành lối diễn giải, và cân bằng ngữ điệu của mình cho phù hợp.
✅ Tập phát âm rõ, chữ nào hay ngọng thì nói chậm lại.
✅ Đi present cho khách hàng, có run quá thì phải NÓI CHẬM lại. Vì bản năng mình khi run sẽ auto bắn rất nhanh, nhưng không, cần phải chậm lại.
✅ Sáng dậy chịu khó chạy bộ, hoặc đi làm chịu khó leo thang bộ ==> tập thở, điều phối cách lấy hơi cho đều, cho khỏe.
✅ Và sau tất cả, một trong những điều quan trọng nhất để nói tốt là phải…
2.2. Listening
Listening – lắng nghe người khác.
Nãy là mình nói tốt rồi, giờ thì mình phải nghe tốt. Làm BA mà nghe ẩu là dễ dính chưởng lắm. Vì có những cái, tưởng như đơn giản, mà nếu không nghe kỹ thì là một mớ hầm bà lằng trong đó.
Chưa kể nếu làm với khách hàng nước ngoài, partner nước ngoài, chắc gì mình đã hiểu rõ những yêu cầu (và cả những ý đồ, mong muốn đằng sau lời họ nói).
Do đó, nguyên tắc của BA là cứ phải xác nhận lại những gì mình nghe, để đảm bảo rằng: mình nghe đúng những gì đối phương diễn giải.
Anh em đừng lo. Nếu có thanh niên nào phàn nàn kiểu như: ơ thằng này cùi bắp, tiếng anh, tiếng em cùi bắp, gì mà cứ hỏi tới hỏi lui, rồi xác nhận tới lui tùm lum tùm la…. Thì cứ kệ bà nó.
Mình cứ xác nhận lại cho chắc những gì mình nghe đi cái đã. Công việc của mình, mình cứ làm, không cần quan tâm bố con thằng nào ồn ào hết.
Vì nếu nghe không cẩn thận, hiểu sai ý, thì những gì mình phản hồi lại sẽ rất trớt quớt, khi đó thì càng tệ nữa. Khách hàng sẽ nghĩ sai về mình. Sau này làm việc còn khó hơn.
Chưa kể, nghe ẩu – hiểu sai ==> sẽ mang về một mớ thông tin đầy rẫy sự nguy hiểm cho đồng bọn đang ngóng trông ở nhà. Lúc đó vô dự án càng teooooo nữa.
Nên gì đi chăng nữa thì hãy nhớ: Listening một cách đàng quàng, cẩn thận, và luôn luôn phản hồi lại để đảm bảo mình hiểu đúng ý người nói.
Mindful Listening: Lắng nghe một cách chuyên tâm nhất – phiên bản tàu khựa (Nguồn ảnh: Pinterest/JohnDonaldson14)
Có thể anh em sẽ quen với hình trên. Bà con đồn nhau rằng: chữ “lắng nghe” tiếng Trung rất có ý nghĩa, bởi vì nó là sự kết hợp của:
Lắng nghe đơn thuần,
Kết hợp suy nghĩ,
Kèm theo quan sát,
Không thể thiếu sự tập trung – tôn trọng người nói,
Và cảm nhận bằng cả trái trym.
Sau cùng, lắng nghe tốt là cội nguồn của cả nhóm kỹ năng Giao tiếp này.
Nên làm để rèn luyện:
✅ Những buổi workshop quan trọng, hãy luôn ghi âm để về nghe lại ==> tránh nghe sót, nghe sai ý (nhưng nhớ xin phép bà con trước nhé anh em).
✅ Luôn phản hồi lại nếu mình không chắc về những gì nghe được.
✅ Mạnh dạn nói: “Tiếng Anh tao không được tốt lắm, vui lòng nói chậm giúp tao”. Khi mình làm việc với các Support Partners của Microsoft, mình toàn miss, hiểu sai ý nó. Nó hỏi A, mình đi cắm đầu trả lời B, rất nhiều và rất nhiều lần như vậy.
Và khi mọi thứ được chậm lại, công việc sẽ dễ dàng hơn cho cả hai. Đặc biệt là khi nói chuyện với những accent mà anh em nghe không quen (như Ấn, Mexico, hay Bồ Đào Nha chẳng hạn…)
✅ Nếu trao đổi qua điện thoại, hoặc online meeting, hãy luôn đảm bảo là sẽ có người ghi Meeting Minutes sau cuộc trao đổi. Vì nói qua điện thoại, hay online meeting sẽ khó nghe hơn rất nhiều ==> nên có biên bản để đảm bảo mọi người cùng đi chung một hướng.
.
.
.
Tập 2 tạm kết tại đây. Nếu có phản hồi gì thì anh em cứ còm men bên dưới cho mình biết nhé 🙂
Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh
Thời gian qua có nhiều anh em hỏi mình về ngành MIS. Và đặc biệt là câu hỏi: sau này ra trường, làm BA thì cần có những kỹ năng – kiến thức chuyên ngành như thế nào???
…
Do đó, như lời giới thiệu ở trên, chuỗi bài này mình sẽ note về chủ đề: những kỹ năng cần có của một người làm công việc Business Analyst.
Là một bài khá fundamental, nhưng cũng là dịp để bản thân mình dòm lại: thật sự BA cần có những kỹ năng nào, và liệu mình đã có đủ hết những kỹ năng đó hay chưa.
Bắt đầu thôi nào!
Tổng quan một chút
Trong bất kỳ ngành nghề nào, chúng ta đều cần tới: Kiến thức và kỹ năng cần có của ngành nghề, công việc đó.
Business Analyst cũng vậy, sẽ có:
Nhóm các Kiến thức chuyên môn – Knowledge Areas (có thể hiểu là kỹ năng cứng).
Và nhóm các Kỹ năng cần thiết – Underlying Competencies (có thể hiểu là kỹ năng mềm).
List dài những kỹ năng dưới đây là mình tham khảo từ BABOK v3.0. Nhìn khá dài và chuối, nhưng anh em khoan hẳn hoang mang, vì mình sẽ cố gắng đưa nó về sát thực tế nhất cho anh em dễ hình dung.
Nếu đọc có gì không ổn, chưa rõ, hoặc cần thảo luận thêm thì cứ quăng mình cái boong, à nhầm, quăng mình cái còm men để tăng tính tương tác nhé anh em.
Ô keiii, lét sờ gâu anh em eiiii 😎
1. Analytical Thinking
Đầu tiên là nhóm kỹ năng về Tư duy phân tích.
“Tư duy phân tích” nghe thì có vẻ hơi đao to búa lớn, nhưng thực tế anh em cứ hình dung vầy cho đơn giản. Mấu chốt nằm ở từ phân tích, nên hiểu “phân tích” như thế nào cho thực tế nhất.
“Phân tích đơn giản là sắp xếp & phân loại mọi thứ lại cho đẹp đẽ, sạch sẽ mà thôi 🙂 “
Từ một BA Manager nọ
…hoặc
“Analysis means simply breaking down the information of an object, entity, process, or anything else to understand its functioning“
Sandhya Jane – Author of Business Analysis: The Question and Answer book
Mục đích sau cùng của việc phân tích là để mình hiểu được cái mình phân tích, hiểu được bản chất vấn đề.
Còn “tư duy” là hoạt động của hệ thần kinh, giúp chúng ta nhìn nhận những thứ xung quanh mình. Từ đó định hướng cho các hành động phù hợp hơn, hiệu quả hơn với tình huống mà mình đang gặp.
Vậy nên, người có tư duy phân tích là người có thiên hướng sắp xếp và phân loại các tiểu tiết của vấn đề, để qua đó: hiểu được bản chất của vấn đề.
Và 5 thứ sau đây sẽ giúp hình thành nên tư duy phân tích của anh em.
1.1. Conceptual & Visual Thinking
Trong bối cảnh Business Analyst, tư duy phân tích thể hiện rõ ở hai mặt: Conceptual và Visual.
Conceptual là góc nhìn theo hơi hướng trừu tượng – khái quát vấn đề
Còn Visual là góc nhìn mang hơi hướng trực quan – dùng hình ảnh cụ thể để mường tượng rõ vấn đề.
Khi làm việc với khách hàng, nói về concept chung của phần mềm có thể sẽ gây bối rối cho khách hàng. Vì họ chưa hình dung được nó là cái gì. Mọi thứ vẫn còn chung chung và trừu tượng quá.
Thay vào đó, việc demo ngay các chức năng có trên phần mềm sẽ khiến khách hàng dễ hình dung hơn (đó là Visual)
Visual thinking cho phép khách hàng “nhìn được”, “tưởng tượng được” và “ánh xạ” hình ảnh đó ngay trong đầu.
Visual Thinking
Nói về Visual Thinking thì đây là thứ anh em sẽ rất-rất-rất cần khi làm BA.
Vì có nhiều thứ mình sẽ rất khó để hình dung rõ vấn đề. Đặc biệt là các vấn đề quá sâu về chuyên môn, như chuyện coding chẳng hạn.
Chưa kể anh em còn phải giải thích, document lại cho các bên hiểu rõ vấn đề đang gặp phải.
Khi trao đổi với anh em đì ve lốp pơ, sẽ có những thuật ngữ, mà nếu mình chưa từng tận tay làm thực tế, thì thề luôn, là hầu như rất khó để mường tượng, và hiểu nó một cách “bản chất nhất”.
Nó nằm ở cả quá trình lấy yêu cầu với khách hàng. Ví dụ những thứ như API, Web Service… Hai thứ này thật sự rất khó gặm với những ai chưa làm thực tế bao giờ.
Những thứ thư: nhận và gửi data như thế nào, hay những hạn chế của những “available API” ảnh hưởng đến solution requirement ra sao???
Tất cả những thứ này sẽ gây rất nhiều khó khăn cho anh em nếu không hiểu rõ nó.
Đối với những trường hợp khá là trừu tượng như vầy thì hãy nhờ đến Visual Thinking.
Hãy nhờ một chuyên gia về khái niệm, lĩnh vực đó, diễn tả lại cho anh em hiểu thông qua… hình vẽ.
Vẽ là thứ rất quan trọng với anh em BA mình. Khi mọi thứ đã được phác thảo rõ ràng ra về hình ảnh, thì bản chất vấn đề sẽ dần lộ diện.
Mấu chốt là vẽ như thế nào cho hiệu quả. Cái này thì rõ ràng cần phải học và tích lũy rất nhiều.
Conceptual Thinking nghĩa là tư duy theo hơi hướng trừu tượng, bao quát vấn đề.
Trừu tượng nghĩa là tổng quát hóa một cái gì đó, không cần care chi tiết bên trong nó có gì. Và thường thì bà con vẫn hiểu khái niệm trừu tượng đó khi chúng ta nói ra. Vì trừu tượng là thứ dựa trên một hình tượng nào đó, và được hình dung trong đầu.
Cái này có vẻ lạ. Thường thì khi trừu tượng quá, khó hiểu quá thì mình mới cần áp dụng Visual Thinking để mọi thứ được phác thảo ra rõ ràng, để dễ mường tượng hơn.
Vậy thì ngược lại, Conceptual Thinking – tư duy theo hướng trừu tượng thì được dùng khi nào?
Đó là khi anh em cần nhìn vấn đề dưới bức tranh tổng quan. Để xác định được các component chung nhất trong bức tranh tổng quan đó. Và relationship giữa chúng với nhau.
Ví dụ trong giai đoạn pre-sales, anh em thường phải gặp những người là C-Level bên phía khách hàng. Mà đã là C-Level rồi thì góc nhìn của họ thường rất bao quát và trừu tường.
Họ luôn nhìn bài toán từ trên cao, và đó phải là cách tiếp cận của BA khi làm việc với những người này.
Mình từng bị dập tơi bời không biết bao nhiêu lần khi cứ nói detail thế này thế kia với “nhầm đối tượng”.
Cách tiếp cận chỉ là một chuyện. Nếu anh em không suy nghĩ bao quát, tổng quát hóa, sẽ rất khó để hiểu được ý đồ thật sự mà khách hàng mong muốn.
…
Cuối cùng, Conceptual Thinking và Visual Thinkingthường phải đi chung, và bổ trợ cho nhau. Không phải cứ tổng quát hóa là không cần visualize, mà hễ visualize thì không được visualize một bức tranh tổng quát.
Vậy chốt lại, để rèn luyện được Tư duy phân tích, anh em cần có Tư duy tổng quát hóa và Tư duy bằng hình ảnh🙂
Nên làm để rèn luyện
✅ Đọc thêm về Design Thinking.
✅ Tập vẽ bằng bút, tập thể hiện ý đồ bằng nét vẽ của mình.
✅ Tập vẽ mind map.
✅ Đọc bộ Hình vẽ thông minh của Dan Roam (hiểu cách ổng dùng hình ảnh để giải quyết vấn đề như thế nào)
✅ Chịu khó quan sát(cả top-down và bottom-up)
✅ Tập làm Power Point, thể hiện ý tưởng bằng hình vẽ trên Power Point.
✅ Tập present trước đồng bọn.
✅ Thử nghe một câu chuyện phức tạp nào đó, rồi thể hiện lại bằng hình ảnh cho người khác hiểu.
1.2. Creative & Innovative
Tiếp theo là Creative và Innovative. Cả 2 đều kiểu kiểu sáng tạo, nhưng nó khác nhau ở chỗ:
Creative là biết làm, biết cách để làm, nói về cách làm, thường nghiêng về smart, tiếng Việt dịch là SÁNG TẠO.
Còn Innovative nghĩa là nghĩ khác, tạo ra cái mới, cách làm mới, là sáng tạo của sáng tạo, tiếng Việt dịch là ĐỘT PHÁ.
Và dĩ nhiên, dù có sáng tạo hay đột phá thứ dữ cỡ nào thì cũng phải mang lại kết quả tích cực; chứ hổng có sáng tạo tầm bậy tầm bạ.
Mình cũng không ít lần phát sinh “ý tưởng vĩ đại” để update dữ liệu của khách hàng, theo kiểu bulk update. Nghĩa là update nguyên cục. Và cũng không ít lần ôm mỏ máo khi làm tầm bậy tầm bạ.
Cứ tưởng sáng tạo để tiết kiệm thời gian, mà ai dè còn tốn thời gian hơn cả chục lần để đi đổ đống vỏ mình gây ra, đắng lòng…
Nhiều lúc overload với đống công việc theo kiểu hành chính, hoặc update dữ liệu khá thủ công. Chúng ta cần tìm ra cách làm cho nhanh, cho hiệu quả. Dù có hỏi người này, người kia, tự mình google, hay tự mình nghĩ ra thì cũng đều rất cần thiết cho công việc BA hằng ngày.
Nó giúp chúng ta tiết kiệm được thời gian, để tập trung vào cái cần thiết hơn, và tạo ra được nhiều kết quả hơn.
Nên làm để rèn luyện
✅ Chịu khó đọc chuyên mục các mẹo (tips) của các tools hay dùng như Office365, Draw.IO, Jira…
✅ Chú ý quan sát, copy cách người khác làm.
✅ Bản thân mình tự thử nhiều cách khác nhau để làm một cái gì đó (mặc dù có thể fail, tốn thời gian hơn, nhưng ít nhất cũng biết được vài cách không thành công. Và đặc biệt là bản thân mình dạn hơn, dám thử nhiều cái mới hơn)
✅ Nên tracking những task mình làm trong ngày(để đo lường được hiệu quả >> cuối ngày xem lại >> tìm cách nâng cao hiệu suất).
✅ Có một chỗ ghi note thật nhanh trên điện thoại. Có ý tưởng một phát là rút điện thoại ra, rẹt rẹt, ghi âm lại liền. Hoặc chỉ cần 2-3 chạm là đã nhập ý tưởng được rồi.
✅ Lâu lâu đi lòng vòng nói chuyện với đồng bọn để refresh. Sẵn xem thử đồng bọn có gì hay không để về bắt chước.
✅ Đặt deadline cho các task mình làm >> càng gấp >> càng dễ nghĩ cách khác làm nhanh hơn.
1.3. Problem Solving
Chắc chắn không chỉ BA, mà ai cũng cần kỹ năng này hết, kỹ năng giải quyết vấn đề.
Kỹ năng này cần xuyên suốt mọi lúc mọi nơi. Từ lúc chưa có dự án, tới lúc làm dự án. Thậm chí đóng dự án rồi mà vẫn còn một đống vấn đề phát sinh cần giải quyết.
Người có kỹ năng giải quyết vấn đề tốt là người nhạy với các thông tin nhận được.
Giả dụ khi mình nhận được thông tin, về một vấn đề cần phải giải quyết đi chẳng hạn. Là ngay lập tức trong đầu mình xác định được ngay vấn đề đang gặp là vấn đề gì. Hoặc chí ít nhìn nhận được nó thuộc khía cạnh, lĩnh vực nào, liên quan tới mình không, liên quan nhiều hay ít, abc, xyz...
Vì thực sự trong quá trình làm dự án sẽ có rất nhiều “problem” xảy ra. Nhỏ có, to có, bự chà bá cũng có.
Là người “đầu mối thông tin”, hầu như anh em BA sẽ phải can thiệp đến 96,69% các vấn đề xảy ra.
Từ những thứ nho nhỏ như sắp tới hạn deliver rồi mà anh em đì ve lốp pơ cứ nghỉ liên tục, cả team bị pending không ăn nhậu được gì. Hoặc tới deadline rồi mà khách hàng vẫn chưa chịu gửi master data, vâng vâng…
Cho đến những thứ mệt não hơn như: đang lúc demo cho khách hàng mà server ở nhà bị… tụt bà nó, không connect zô được.
Đây là trường hợp mình gặp rất nhiều, nội kể lại không cũng thấy ớn ớn.
Lần đó đi khách hàng cũng toàn nhân vật thứ dữ. Mặc dù đã nhắn nhủ anh em ở nhà là ráng support tốt, để anh em ra chiến trường demo cho suôn sẻ. Thì y như rằng, lần nào cũng có chuyện.
Lần đó có một ông Marketing Director. Khi đi tới phần nói về Social Listening, tích hợp với Facebook thì ổng có vẻ khoái. Vì trước giờ chưa có partner nào show cho ổng xem được cái này. Và thực sự business của họ đang rất có nhu cầu về khoản này.
Một phần cũng tự tin vì giải pháp mà team đã chuẩn bị. Phần khác vì thấy ổng khoái nên mình chém khá cao hứng.
Đến hồi quan trọng nhất: “bây giờ em sẽ demo cho anh xem ví dụ cụ thể mà bên em đã chuẩn bị cho bên mình”.
Nghe vậy ổng khoái lắm, gật đầu lia lịa.
Cái ai dè, login vô hệ thống bị failed, báo lỗi thiếu quyền các kiểu. Lúc này mình cũng hơi tái táiii. Nhờ anh PM chém gió câu giờ, mình ping về nhà nhờ anh em Dev support.
Mà hình như anh em đang vi vu đâu đó, gọi cháy máy không được. Thấy sốt ruột quá, nghĩ bụng: “chết mẹ rồi, lỡ chém mạnh quá mà không show được gì thì hố chết...”
Hồi sau anh em gọi lại, đưa cho cái account khác, thử login nhưng vẫn failed. Thử vào trình duyệt ẩn, vẫn failed.
Thôi thì cũng đã hơn 20 phút trôi qua, bèn dùng phương án B. Show hình, thay cho live demo. May hôm trước có nghe lời anh PM, chịu khó screenshot trước vài tấm sơ cua, hú vía.
…
Với những trường hợp gặp sự cố với khách hàng như vậy, mình nghĩ sẽ thiên nhiều về kinh nghiệm chinh chiến của anh em.
Còn những thứ trao đổi nội bộ với nhau, để cùng giải quyết 1 vấn đề nào đó thì có phần thiên nhiều về soft skills của mình hơn (dĩ nhiên là kinh nghiệm dự án cũng rất quan trọng).
Có những người khi gặp vấn đề, họ sẽ cứ phang phang vào mình, nói đủ thứ trên trời dưới đất, búa lua xua hết.
Nhiệm vụ của mình là cần phải bình tĩnh lại>> từ từ nhìn nhận đâu là vấn đề cốt yếu mà người đó đang gặp.
Cái này rất khó, vì khi gặp những thứ mà anh em không phải chuyên môn, như những term về kỹ thuật đi chẳng hạn. Hoặc có quá nhiều thông tin chồng chéo nhau, mother of phức tạp của phức tạp. Thì cái cần ở đây là mình phải đủ bình tĩnh và tỉnh táo dể nhận diện vấn đề.
Khi đã hiểu vấn đề, anh em mới nghĩ tới phương án giải quyết.
Có thể có nhiều phương án, nhưng việc chọn phương án nào là tốt nhất ở thời điểm hiện tại mới là quan trọng. Mỗi phương án nó đều mở ra 1 cánh cửa mới.
Và không bao giờ có công thức chung cho từng hoàn cảnh cụ thể.
Cùng tình huống đó, nhưng ở bối cảnh A, con người A’ thì giải quyết khác. Nhưng với bối cảnh B, và con người B’, thì lại phải giải quyết khác.
Nên khoản này đòi hỏi anh em phải chú ý quan sát nhiều. Học hỏi và gặp nhiều sự cố thì sẽ rèn luyện được kỹ năng này.
Ngoài ra, kỹ năng Giải quyết vấn đềsẽ luôn đi kèm với một thứ quan trọng không kém, đó là…
Việc lựa chọn một chiếc laptop phù hợp cho việc học Công nghệ Thông tin (CNTT) là điều rất quan trọng, đặc biệt là với sinh viên hoặc người mới bắt đầu. Với ngân sách dưới 15 triệu, có rất nhiều sự lựa chọn tuyệt vời giúp bạn có thể lập trình và làm việc hiệu quả. Trong bài viết này, chúng ta sẽ cùng tìm hiểu những tiêu chí cần xem xét khi mua laptop và điểm qua danh sách các mẫu laptop học CNTT dưới 15 triệu tốt nhất.
Tiêu chí lựa chọn cấu hình laptop lập trình dưới 15 triệu
Trước khi đi vào danh sách laptop học lập trình dưới 15 triệu nên chọn mua, chúng ta phải xác định rõ một chiếc laptop học lập trình thì nên sở hữu những đặc điểm, thông số kỹ thuật nào.
Dưới đây là những yếu tố cơ bản bạn cần xem xét khi chọn mua laptop để học lập trình:
Bộ vi xử lý (CPU)
CPU là trái tim của bất kỳ máy tính nào. Đối với lập trình, bạn cần một chiếc laptop có bộ vi xử lý đủ mạnh để xử lý các tác vụ đa nhiệm và chạy các phần mềm phát triển như Visual Studio, Android Studio hoặc Eclipse một cách mượt mà. Trong tầm giá dưới 15 triệu, các CPU như Intel Core i5 hoặc AMD Ryzen 5 là lựa chọn phù hợp.
Bộ nhớ RAM
RAM quyết định khả năng xử lý đa nhiệm của laptop. Để học lập trình, tối thiểu bạn cần một máy tính có 8GB RAM. Nếu có thể, hãy tìm những mẫu laptop có khe cắm hỗ trợ nâng cấp RAM, nếu máy không thể nâng cấp thì nên chọn tối thiểu 16GB.
Ổ cứng SSD
Những chiếc laptop trong tầm giá 15 triệu hiện nay đa số đều đã trang bị ổ cứng SSD thay vì ổ cứng HDD truyền thống, mang lại tốc độ truy xuất dữ liệu nhanh hơn rất nhiều.
Với việc học tập lập trình, bạn nên chọn laptop có ổ SSD ít nhất 256GB để đảm bảo dung lượng lưu trữ đủ cho các tài liệu học tập và phần mềm.
Card đồ họa (GPU)
Đối với sinh viên học CNTT, một chiếc laptop có card đồ họa rời không quá cần thiết trừ khi bạn làm việc nhiều với đồ họa hoặc lập trình game.
Màn hình
Màn hình là yếu tố quan trọng giúp bạn làm việc thoải mái trong thời gian dài. Kích thước màn hình 14 inch hoặc 15.6 inch với độ phân giải Full HD (1920 x 1080) là lý tưởng để làm việc và học tập.
Dưới đây là tóm tắt các tiêu chí cơ bản để lựa chọn laptop lập trình dưới 15 triệu:
CPU
Tối thiểu là core i5
RAM
Từ RAM 8GB trở lên, nên có khe nâng cấp
Ổ cứng
Tốt nhất từ SSD 256GB
Màn hình
Chuẩn Full HD
Card đồ hoạ
Cần thiết nếu bạn học lập trình game
Danh sách laptop dưới 15 triệu phù hợp học lập trình
Dưới đây là danh sách 8 mẫu laptop tốt nhất dưới 15 triệu, phù hợp cho việc học lập trình và các nhu cầu học tập khác.
Laptop Dell Precision 3560 – Intel Core i5-1135G7
Dell Precision 3560 là một trong những dòng laptop workstation nổi bật của Dell, được thiết kế dành cho các tác vụ chuyên dụng như lập trình, thiết kế đồ họa, và kỹ thuật. Với bộ vi xử lý Intel Core i5-1135G7, đây là sự lựa chọn tuyệt vời cho những người dùng cần hiệu suất ổn định trong một thiết kế mỏng nhẹ và bền bỉ.
Cấu hình chi tiết:
CPU: Intel Core i5-1135G7 (4 lõi, 8 luồng, xung nhịp cơ bản 2.4 GHz và tối đa 4.2 GHz).
RAM: 8GB DDR4, có thể nâng cấp lên 32GB.
Ổ cứng: SSD 256GB, cho tốc độ truy xuất dữ liệu nhanh.
Card đồ họa: Intel Iris Xe Graphics tích hợp, đủ để xử lý đồ họa cơ bản và chạy các phần mềm lập trình.
Màn hình: 15.6 inch Full HD (1920 x 1080), mang đến hình ảnh sắc nét.
Pin: Pin 4-cell 64 Wh, thời lượng sử dụng kéo dài từ 8 đến 10 giờ tùy vào tác vụ.
Trọng lượng: Khoảng 1.59 kg, tương đối nhẹ so với các dòng máy workstation.
Giá thành: Hiện laptop Dell Precision 3560 đang có giá tầm 11-12 triệu cho phiên bản chip core i5, nếu bạn nâng cấp lên phiên bản core i7 thì sẽ cộng thêm khoảng 2 triệu đồng.
Dell Latitude 7420 – Intel Core i5-1145G7
Dell Latitude 7420 là một trong những mẫu laptop doanh nghiệp cao cấp của Dell, nổi bật với thiết kế mỏng nhẹ, tính di động cao, và hiệu năng mạnh mẽ. Được trang bị bộ vi xử lý Intel Core i5-1145G7 thế hệ thứ 11, Latitude 7420 mang đến khả năng xử lý mạnh mẽ, tiết kiệm năng lượng và khả năng bảo mật cao, phù hợp cho cả người dùng doanh nghiệp và cá nhân cần một thiết bị mạnh mẽ, linh hoạt trong công việc. Ngoài ra, với thiết kế thời thượng và trọng lượng nhẹ, đây là lựa chọn lý tưởng cho những người thường xuyên di chuyển.
Thông số kỹ thuật chi tiết của Dell Latitude 7420:
Cảm ứng, 14 inch FHD (1920 x 1080), WVA, 250nits, NTSC 45%, 60Hz, Anti-Glare
Pin
3-cell, 42 WHr
Trọng lượng
Khoảng 1.31 kg
Với màn hình chất lượng, hiệu suất mạnh mẽ, và các tính năng bảo mật tiên tiến, đây là một trong những lựa chọn hàng đầu trong phân khúc laptop học CNTT dưới 15 triệu. Hiện laptop Dell Latitude 7420 Core i5-1145G7 likenew (hiện model này đã ngưng sản xuất hàng mới) đang được bán với giá dao động từ 12-14 triệu, tùy cửa hàng và chương trình ưu đãi.
Tiếp theo cũng là một con máy đến từ hãng Dell, dòng Inspiron, Dell Inspiron 15 3530 – Intel Core i5-1335U, là mẫu laptop tầm trung được thiết kế dành cho người dùng phổ thông, sinh viên và nhân viên văn phòng với nhu cầu sử dụng đa dạng. Được trang bị bộ vi xử lý Intel Core i5-1335U thế hệ 13, máy cung cấp hiệu suất mạnh mẽ cho các tác vụ hàng ngày như lướt web, soạn thảo văn bản, và tất nhiên cũng phù hợp để viết code và chạy chương trình.
Cùng tham khảo thông số kỹ thuật chi tiết của Dell Inspiron 15 3530:
15.6 inch Full HD (1920 x 1080), LED, chống chói, 120Hz 250 nits
Pin
Pin 3-cell 41 Whr
Trọng lượng
Khoảng 1.65 kg
Với ưu điểm là thiết kế sang trọng, Dell Inspiron 15 3530 là một lựa chọn tuyệt vời cho người dùng cần một chiếc laptop màn hình lớn, hiệu năng ổn định với giá cả phải chăng chỉ khoảng 13-15 triệu đồng.
Laptop Acer Aspire 3 A315
Acer Aspire 3 A315 là một trong những sản phẩm mới nhất của Acer trong phân khúc laptop Acer Aspire tầm trung. Được trang bị bộ vi xử lý Core i5-1235U, laptop này sẽ mang đến hiệu suất xử lý mạnh mẽ cho các tác vụ hàng ngày. Bạn có thể thực hiện các tác vụ đa nhiệm mượt mà và nhanh chóng. Một trong những ưu điểm của chiếc laptop này đó là thời lượng pin, với một lần sạc đầy Acer Aspire A315 có thể hoạt động liên tục lên đến 9 tiếng, cho phép bạn sử dụng cả ngày mà không cần lo lắng về việc sạc pin.
Ổ cứng: SSD 256GB, có thể nâng cấp thêm lên 512GB.
Card đồ họa: Intel Iris Xe Graphics tích hợp, đủ để xử lý đồ họa cơ bản và chạy các phần mềm lập trình.
Màn hình: 15.6 inch Full HD (1920 x 1080), với tấm nền IPS
Pin: Pin 4-cell 64 Wh, thời lượng sử dụng kéo dài từ 8 đến 10 giờ tùy vào tác vụ.
Trọng lượng: Khoảng 1.7kg
Với những ưu điểm và thông số cơ bản đáp ứng được tiêu chí của một chiếc laptop lập trình, nhưng Acer Aspire 3 A315 lại có một mức giá vô cùng bất ngờ, chỉ hơn 10 triệu đồng là bạn đã có thể sở hữu em máy mạnh mẽ bên trong, tao nhã, tinh tế bên ngoài.
HP Laptop 15s-fr5005TU Core i7-1260P
Laptop HP là một dòng sản phẩm laptop cao cấp đến từ Mỹ, được biết đến với thiết kế thanh lịch và thời thượng cùng hiệu năng sử dụng cực đỉnh. Nếu bạn muốn tìm một chiếc laptop lập trình 15 triệu trở xuống, HP Laptop 15s-fr5005TU Core i7-1260P là một trong những lựa chọn đáng cân nhắc.
Laptop HP 15s-fr5003TU được trang bị bộ vi xử lý Intel Core i7-1260P thế hệ thứ 12 của Intel, kết hợp với 16GB RAM và ổ cứng SSD 512GB. Từ đó mang lại cấu hình mạnh mẽ cho các tác vụ từ cơ bản đến nâng cao. Tham khảo cấu hình chi tiết của chiếc laptop này:
15.6 inch Full HD (1920 x 1080), màn IPS, chống chói, chống lóa 250 nits
Pin
Pin 3-cell 41 Whr
Trọng lượng
Khoảng 1.8 kg
HP Laptop 15s-fr5005TU Core i7-1260P chắc chắn là một lựa chọn không thể bỏ qua cho sinh viên học lập trình. Với bộ vi xử lý Intel Core i7 thế hệ mới, RAM 16GB và ổ cứng SSD 512GB, nhưng laptop này chỉ có giá khoảng 14-15 triệu đồng, có thể các cửa hàng khác nhau sẽ có chênh lệnh về giá nhưng vẫn đáp ứng tiêu chí máy học lập trình tốt giá rẻ.
Laptop Lenovo V14 G4 IRU 83A000BGVN
Laptop Lenovo V15 G4 IRU thuộc dòng laptop sinh viên, giá rẻ cấu hình mạnh được nhiều người dùng lựa chọn. Với chip Intel Core i5-13420H với 8 lõi, 12 luồng, tần số turbo tối đa 4.6GHz và RAM 16GB DDR4 3200MHz, đây là một chiếc laptop đáp ứng hoàn hảo cho việc lập trình.
Màn hình: 14 inches, 1920 x 1080 pixels (FullHD), IPS, độ sáng 350 nits, chống chói, độ phủ màu 45% NTSC
Pin: 38Wh
Trọng lượng: 1.43kg
Laptop Lenovo V14 G4 IRU 83A000BGVN là một mẫu laptop học tập trang bị bộ vi xử lý mạnh mẽ, dung lượng RAM lớn trong một thiết kế bền bỉ, với mức giá khoảng 13 triệu đồng, hẹn đáp ứng tốt mọi nhu cầu lập trình cho các lập trình viên tương lai.
Việc chọn lựa laptop phù hợp cho việc học CNTT dưới 15 triệu đòi hỏi sự cân nhắc kỹ lưỡng về cấu hình, nhu cầu sử dụng và tính năng. Những dòng máy tính trên đều là các lựa chọn tốt cho sinh viên hoặc những ai mới bắt đầu học lập trình. Tùy theo mục đích sử dụng, bạn có thể lựa chọn cho mình một chiếc laptop phù hợp để hỗ trợ tốt nhất cho công việc học tập và phát triển kỹ năng lập trình.
Bài viết được sự cho phép của tác giả Nguyễn Thành Nam
GitHub không chỉ là nơi để chia sẻ mã nguồn mà còn là một kho tàng tài nguyên quý giá cho lập trình viên muốn nâng cao kỹ năng của mình. Từ các dự án mã nguồn mở cho đến tài liệu học tập chuyên sâu, GitHub cung cấp một nền tảng tuyệt vời để bạn cải thiện khả năng lập trình và tiếp cận những kiến thức mới.
Trong bài viết này, chúng ta sẽ khám phá một số repositories nổi bật mà bạn có thể tham khảo để phát triển kỹ năng lập trình.
1. FreeCodeCamp
FreeCodeCamp là một nền tảng học lập trình nổi tiếng, và repository của nó là một trong những nguồn tài liệu học tập phong phú nhất trên GitHub. Với hơn 40,000 giờ học miễn phí và hàng loạt bài tập thực hành từ cơ bản đến nâng cao, FreeCodeCamp giúp bạn nắm vững các kỹ năng lập trình như HTML, CSS, JavaScript, và nhiều ngôn ngữ khác. Repository này không chỉ là tài liệu học tập mà còn chứa nhiều dự án thực tế, giúp bạn áp dụng kiến thức vào thực tiễn.
“Aweome” là một danh sách tuyển chọn các tài nguyên học tập, công cụ phát triển, và dự án mã nguồn mở trên nhiều lĩnh vực khác nhau của lập trình. Danh sách này liên tục được cập nhật bởi cộng đồng, bao gồm mọi thứ từ lập trình web, học máy, cho đến các công cụ DevOps. Nếu bạn đang tìm kiếm các tài liệu hoặc công cụ giúp nâng cao kỹ năng, thì đây chính là nơi bắt đầu.
The Algorithms là một repository tuyệt vời cho những ai muốn hiểu sâu hơn về cách các thuật toán hoạt động. Dự án này chứa các triển khai của nhiều thuật toán phổ biến bằng nhiều ngôn ngữ lập trình khác nhau, từ Python đến Java và C++. Bạn có thể học được cách áp dụng các thuật toán trong thực tế và cải thiện kỹ năng lập trình thuật toán của mình.
CS50x là một khóa học nhập môn khoa học máy tính nổi tiếng của Harvard, và repository của nó chứa toàn bộ tài liệu học tập và bài tập thực hành của khóa học. Dù bạn mới bắt đầu hay đã có nền tảng, CS50x cung cấp một lộ trình học tập có cấu trúc rõ ràng, giúp bạn xây dựng kiến thức từ cơ bản đến nâng cao trong lập trình và khoa học máy tính.
Developer Roadmap là một dự án hướng dẫn chi tiết về các kỹ năng và công nghệ mà bạn cần nắm vững để trở thành một lập trình viên chuyên nghiệp. Repository này cung cấp các bản đồ lộ trình học tập cho nhiều lĩnh vực khác nhau như front-end, back-end, DevOps, v.v. Mỗi bản đồ đều được xây dựng dựa trên các công nghệ và kỹ năng được yêu cầu nhiều nhất trong ngành, giúp bạn định hướng học tập một cách hiệu quả.
Nếu bạn là người thích học qua thực hành, Project-Based Learning sẽ là repository phù hợp với bạn. Nó cung cấp một danh sách các dự án thực tế mà bạn có thể tự tay thực hiện để nâng cao kỹ năng lập trình. Từ việc xây dựng ứng dụng web, trò chơi, cho đến các công cụ CLI, bạn sẽ tìm thấy những dự án thú vị và thách thức để thử sức.
JavaScript30 là một khoá học miễn phí với 30 dự án thực hành bằng JavaScript. Không cần bất kỳ thư viện hay framework nào, bạn sẽ học cách xây dựng các ứng dụng chỉ với JavaScript thuần. Đây là cách tuyệt vời để nắm vững ngôn ngữ này và cải thiện kỹ năng lập trình của mình một cách nhanh chóng.
LeetCode Patterns là một công cụ hữu ích cho những ai muốn rèn luyện kỹ năng giải quyết vấn đề và chuẩn bị cho các kỳ thi lập trình. Repository này phân loại các bài tập trên LeetCode theo các mẫu phổ biến, giúp bạn dễ dàng tiếp cận và học hỏi các kỹ thuật giải quyết vấn đề hiệu quả.
Repository này lấy cảm hứng từ cuốn sách “Clean Code” của Robert C. Martin, áp dụng các nguyên tắc của lập trình sạch vào JavaScript. Đây là một tài nguyên tuyệt vời cho bất kỳ ai muốn viết mã nguồn sạch, dễ hiểu và bảo trì. Các ví dụ trong repository giúp bạn thấy rõ cách áp dụng lý thuyết vào thực tế, từ đó nâng cao chất lượng mã nguồn của mình.
“You Don’t Know JS” là một series sách nổi tiếng giúp bạn hiểu sâu về JavaScript. Repository này chứa toàn bộ nội dung của series, được tổ chức theo từng cuốn sách, từ cơ bản đến nâng cao. Dù bạn đã có kinh nghiệm hay mới bắt đầu, series này sẽ giúp bạn khám phá các khía cạnh chưa biết của JavaScript và nâng cao kỹ năng lập trình của mình.
Nó cung cấp một danh sách các tài liệu và nguồn học tập đã được chọn lọc kỹ lưỡng, thích hợp cho những ai đang chuẩn bị cho các buổi phỏng vấn lập trình hoặc muốn củng cố kiến thức cơ bản về khoa học máy tính.
Các thuật toán và cấu trúc dữ liệu sử dụng ngôn ngữ JavaScript kèm theo giải thích và liên kết đến các tài liệu tham khảo.
Bộ sưu tập này chứa các thuật toán và cấu trúc dữ liệu là lựa chọn hoàn hảo cho các lập trình viên muốn hiểu rõ cách hoạt động của các thuật toán và cách triển khai chúng một cách hiệu quả.
Nó là công cụ tuyệt vời cho cả việc học tập và chuẩn bị cho các buổi phỏng vấn.
Kho lưu trữ này là một hướng dẫn toàn diện để chuẩn bị phỏng vấn Front End, bao gồm các câu hỏi kiểm tra, thử thách lập trình, và các khái niệm về thiết kế hệ thống.
Nó là sự lựa chọn lý tưởng cho các lập trình viên Front End đang chuẩn bị cho các buổi phỏng vấn kỹ thuật và muốn nâng cao kỹ năng giải quyết vấn đề.
Tech Interview Handbook cung cấp các tài liệu được chọn lọc kỹ càng để chuẩn bị cho phỏng vấn lập trình, bao gồm thuật toán, cấu trúc dữ liệu, và các kỹ thuật phỏng vấn.
Đây là nguồn tài nguyên quý giá cho các lập trình viên muốn chuẩn bị một cách hiệu quả cho các buổi phỏng vấn kỹ thuật.
GitHub là một kho tài nguyên vô giá cho lập trình viên ở mọi cấp độ. Các repositories được liệt kê trong bài viết này cung cấp cả lý thuyết lẫn thực hành, giúp bạn nâng cao kỹ năng một cách toàn diện. Dù bạn đang ở giai đoạn nào trong hành trình lập trình, việc sử dụng hiệu quả các tài nguyên này sẽ giúp bạn tiến bộ nhanh chóng và đạt được mục tiêu của mình.
Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh
Chuyện là nhà mình có cái xô bể, chắp vá cũng được 7-8 lớp. Về bản chất, nó vẫn đựng nước được. Nhưng ngoài điểm đó ra, nó trông như đồ bỏ.
Mẹ mình thì vẫn khoái dùng cái xô này, và không nỡ vứt nó đi :3
Nhưng mỗi lần về quê mình lại chẳng muốn dùng nó tí nào? Kỳ cục zậy đó? Cùng là một cái xô bể, nhưng có người muốn dùng, có người không.
Đó là vấn đề của Quality of Service. Ánh xạ qua thế giới phần mềm, nó chính là Non-Functional Requirement 😎
1. Các loại requirement trong một dự án phần mềm
Như anh em đã biết, hoặc chưa biết: một giải pháp, một sản phẩm, hay một phần mềm nào đó đều có các yêu cầu cụ thể (requirement) cho các giải pháp, sản phẩm hay phần mềm đó.
Là một người làm Business Analyst, chúng ta sẽ làm rất nhiều thứ xoay quanh các requirement này.
Bất kỳ phần mềm nào cũng vậy? Sinh ra đều phải có mục đích. Tức mỗi phần mềm đều có các yêu cầu của riêng nó. Mà các yêu cầu này không phải là ít.
Một phần mềm có rất-rất-rất nhiều yêu cầu. Nào là phải làm được cái này, cái kia, nào là phải đẹp, phải nhanh, phải abc, xyz…
Chính vì có quá nhiều requirement, xuất phát từ nhiều đối tượng khác nhau. Lộn xộn quá, nên người ta mới gom nó lại, rồi chia thành 4 loại requirement như trên, để anh em BA chúng ta có thể dễ dàng moi móc và quản lý được nó.
Cụ thể 4 loại nó như thế nào thì mình sẽ để dành nói ở bài sau. Bài này mình sẽ tập trung nói về Solution Requirement.
Ô kê, Solution Requirement được chia nhỏ thành 2 loại sau:
Functional requirement
và Non-Functional requirement.
Có một số ví dụ cho anh em dễ hình dung hơn:
Ly nước:
Functional Req: ly đựng được nước
Non-Functional Req: ly rớt không bể.
Mũ bảo hiểm:
Functonal Req: có đèn chiếu sáng, nhấp nháy lòe loẹt trong đêm
Non-Functional Req: chịu được lực va đập lên tới 3000 Newton.
Non-Functional Req: ăn xong có khăn giấy lau miệng, hoặc ăn xong không đau bụng.
Phần mềm ABCDXYZ:
Functional Req: quản lý thông tin khách hàng
Non-Functional Req: có nút Help – hướng dẫn người dùng online ngay trên hệ thống.
Đó là một vài ví dụ để anh em hình dung được thế nào là Functional Req và Non-Functional Req.
Vậy Functional Requirement là gì?
2. Functional Requirement là gì?
Functional Requirement là:
The capabilities that a solution must have in terms
of the behavior and information that the solution will manage
Trên là định nghĩa của BABOK, nhưng thôi, đọc nghe dài dòng tùm lum tùm la quá. Rút gọn lại anh em có thể hiểu Functional Requirement là những thứ mà giải pháp có thể làm được.
Hay cụ thể hơn, Functional Requirement là nói về: Behaviors và Functions (Hành vi và Chức năng) của giải pháp.
Ví dụ:
Ly thì phải đựng được nước
Mũ bảo hiểm phải có đèn phát sáng
Ly chè ăn zô là đỡ đói
Hệ thống ABCDXYZ quản lý được thông tin khách hàng.
BABOK ver3.0 định nghĩa Non-Functional Requirement như sau:
Not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.
Lại dài loằng ngoằng, nhưng không sao, đọc cũng dễ hiểu. Càng về sau BABOK định nghĩa càng dễ hiểu mà, hehe.
Non-Functional Requirement là những thứ:
Không liên quan trực tiếp tới hành vi – chức năng của giải pháp
Nhưng lại là các điều kiện giúp hệ thống chạy tốt và đảm bảo được chất lượng như yêu cầu.
Rút gọn 2 dòng trên, mình có cách định nghĩa trực quan hơn như sau:
Non-Functional Requirement = Quality of Services
Tức Non-Functional Requirement là những thứ liên quan đến CHẤT LƯỢNG sản phẩm.
Sản phẩm đó đáp ứng được mục đích sử dụng là 1 chuyện, nhưng nó phải đảm bảo tốt về mặt trải nghiệm người dùng thì mới thật sự đẳng cấp 😎
3.1. Non-Functional Requirement quan trọng đến mức nào?
Quay lại cái xô ở đầu bài. Xô, là giải pháp để đựng nước và được dùng cho các mục đích khác nhau.
Functional Req của cái Xô là đựng được nước. Chỉ nhiêu đó thôi.
Còn Non-Functional Req của cái Xô là: xô làm bằng nhựa không giòn, phơi nắng không bể, không mọc rêu, không trơn, kiểu dáng thon gọn, vừa tay cầm.
Rõ ràng, cái xô ở nhà mình chỉ đạt được mỗi Functional Requirement, còn Non-Functional Requirement thì.. thấy gớm.
Mẹ mình thích dùng vì mẹ mình chỉ quan tâm đến Functional Requirement, tức là chức năng của nó, chỉ cần đựng được nước là được.
Còn mình không thích dùng vì nó không đáp ứng được Non-Functional Requirement, những requirement mà đáng lý ra một cái xô phải có. Đã zậy, còn lủng lỗ, chấp vá tùm lum tùm la, thấy ớn.
Điều này nói lên được vấn đề gì?
Nó nói lên được: User họ quan tâm điều gì?
À há…
Mấu chốt là ở chỗ này.
Nếu user giống mẹ mình, không care nhiều đến Non-Functional, ok anh em trong vùng an toàn.
Cứ thoải mái, chỉ cần cho hệ thống chạy được là được. Tức là hệ thống chỉ cần làm được những thứ mà khách hàng yêu cầu là được.
Còn nếu user giống mình, rất rất quan tâm đến Non-Functional thì…, well, có vẻ hơi mệt với anh em. Đối với họ, không những hệ thống phải chạy được, mà hệ thống còn phải chạy nhanh, gọn, và đẹp nữa.
Và một khi mình nắm được mức độ kỳ vọng của users, mình sẽ biết cách làm họ hài lòng hơn.
Đã không ít lần mình và đồng bọn đang bon bon về đích, tưởng chừng sẽ Go-Live êm xuôi trót lọt. Mà phải khựng lại cả thảy 4-5 lần cũng chỉ vì cái chữ Non-Functional Requirement này.
Khách hàng liên tục complain về nhóm users sử dụng iPad nhập liệu quá lâu, và touch quá nhiều trên màn hình để có thể… hoàn thành được một giao dịch.
Hay việc tìm kiếm các keyword trên hệ thống cũng gặp trở ngại.
Ví dụ, có một dữ liệu mang tên: “Chú Bảy đẹp chai cute hột me tốt bụng”. Thì khi user nhập keyword: “đẹp chai me” thì hệ thống không tìm ra kết quả.
Nhưng nếu user nhập keyword: “đẹp chai cute hột me” thì kết quả mới nhả ra. Tức hiện tại hệ thống chỉ tìm được kết quả theo các keyword là một string theo đúng thứ tự từ trái sang phải.
Trong khi users họ lại muốn: chỉ cần nhập keyword “đẹp chai me”, thì hệ thống sẽ nhả ra tất cả các kết quả chứa 3 từ khóa “đẹp”, “chai”, và “me” riêng biệt, không cần care đến thứ tự. Ví dụ:
Ông Sáu đẹp chai cute hột me khiêm tốn
ABC đẹp cute chai me hột khiêm tốn
XYZ đẹp me chai cute khiêm tốn hột…
Rõ ràng đó chính là các Non-Functional Requirement mà mình, một người BA không hề nắm được, cũng như không làm rõ ngay từ đầu, khiến cho anh em tốn khá nhiều effort để setup lại mọi thứ cho phù hợp với các “quality of services” này.
Đau thương, chỉ có thể chốt lại được bằng từ đau thương 😥
….
Do đó nếu có ai hỏi mình: Non-Functional Req quan trọng đến mức nào? Thì mình tự tin trả lời ngay: quan trọng như Functional Requirement vậy.
Nhiều lúc chưa cần quan tâm behind the scenes chạy như thế nào, lớp front end mà chuối là users cũng bỏ chạy rồi 🙂
Mình tự tin đặt 2 thằng này ngang hàng nhau. Và đây thường là điểm GAP rất lớn giữa…
3.2. Non-Functional Requirement tạo ra GAP lớn giữa…
Thường những người làm triển khai/ outsource – như mình không quan tâm nhiều đến các Non-Functional Requirement. Vì end user của các giải pháp mình làm thường không phải là “end consumer”.
Mà end user thì không phải trả tiền để sử dụng hệ thống, end consumer mới là người trả tiền để sử dụng hệ thống.
Tức là end consumer mới là người sử dụng thông qua hệ thống.
Ví dụ anh em outsource làm hệ thống quản lý khách sạn Millennium, thì end user của hệ thống này là các Quản trị viên của hệ thống, các nhân viên phòng ban. Tức họ là ai? Là người của khách sạn. Không phải khách hàng.
Họ sẽ dụng hệ thống như một công-cụ-trung-gian giúp họ quản lý khách sạn tốt hơn mà thôi.
Còn đối với anh em làm product. Product ở đây có thể là ứng dụng đặt phòng trực tuyến của khách sạn Millennium. End user chính là end consumer. Họ vừa là người dùng ứng dụng, vừa là người trả tiền để sử dụng dịch vụ của Millennium.
Do đó, vấn đề “quality of service” của ứng dụng, hay các yếu tố non-functional của ứng dụng có làm họ vui hay không? Có làm họ thấy thoải mái khi sử dụng hay không? Ứng dụng chạy mượt không? vâng vâng… luôn được chú trọng hàng đầu.
Những yếu tố này góp phần KHÔNG-HỀ-NHỎ trong việc khách hàng ra quyết định: có tiếp tục sử dụng dịch vụ nữa hay không.
Chưa kể, làm product phục vụ end consumer, anh em phải phục vụ tới hơn cả triệu người dùng. Chứ không phải lẻ tẻ vài ba chục, hay chỉ vài trăm người dùng như những hệ thống quản lý back-end.
Chắc hẳn anh em còn nhớ vụ Momo lắc lì xì.
Chỉ trong vòng một ngày 24/1, Momo phải chịu tải lên đến hơn 2 triệu lượt đăng nhập và lắc cùng một lúc. Tức là hơn 2 triệu lượt CCU (concurrent users). Điều này có nghĩa đội ngũ anh em Momo phải liên tục xử lý tình trạng tắt nghẽn server. Kinh khủng!
Hoặc lâu lâu app có vấn đề gì thì phải lo cắm đầu fix ngay, kể cả có holiday hay weekend.
Vì giả dụ anh em down cái app được quảng cáo thiệt ngon về xài, mà mới chạm có 3-4 cái thấy lag banh chành, nút bấm gì mà tùm lum tùm la. Thì ngay lập tức: app bị delete cái một, và suốt đời nằm gọn trong blacklist.
Do đó, đây là GAP không hề nhỏ, liên quan đến “tư duy hành nghề” của những anh em làm outsource muốn chuyển qua làm product. Tuy nhiên, miễn là đừng ẩu và luôn chú ý cẩn thận thì mình nghĩ GAP cũng không quá lớn 🙂
.
Ô kê, hi vọng mình đã chém đủ mạnh để anh em hiểu về tầm quan trọng của Non-Functional Requirement (NFR). Biết nó quan trọng, chúng ta sẽ chú ý đến nó hơn.
Chú ý kể cả khi anh em đang làm triển khai những SaaS nhé. Những Software as a Service như Dynamics 365 của Microsoft. Có những thứ NFR mà mình chẳng thể can thiệp được, ví dụ như Security hay Accessibility của những SaaS này.
Những yếu tố NFR này đều được các hãng build sẵn thành một gói để chúng ta tiện triển khai và sử dụng.
Tuy nhiên, BA cũng cần nắm rõ những yếu tố NFR này ngay từ đầu dự án để tránh out of scope sau này, cũng như giải thích trước cho khách hàng để họ hiểu những điểm mạnh và hạn chế của giải pháp (tránh đòi thêm sau này).
Những NFR này thì các hãng đều có sẵn official document, anh em có thể dễ dàng tìm thấy bằng cụ Gồ 🙂
Câu hỏi cuối cùng, Non-Functional Requirement (NFR) gồm những loại nào?
Phần dưới đây mình sẽ nói sơ lược về các loại NFR hay gặp nhất, từ những gì mình lượm lặt được trong quá trình làm việc cũng như chia sẻ từ các bậc tiền bối 😎
4. Các loại Non-Functional Requirement?
Sorry anh em, vì phần bốn này dài quá nên mình sẽ tách ra ở bài tiếp theo. Mình sẽ để link ở đây, vị trí này, anh em đón đọc nhé.
Phần này sẽ nói về các loại NFR, kèm các ví dụ cụ thể luôn cho anh em dễ hình dung 😎
Tóm tắt
Bài này mình sẽ đúc kết bằng những dòng sau cho anh em dễ nhớ:
Có 4 loại requirement: Business Req, Stakeholder Req, Solution Req và Transition Req (mình sẽ nói rõ hơn ở bài sau)
Solution Requirement gồm: Functional và Non-Functional Req.
Functional Requirement nói lên behaviors và functions của giải pháp (what the system do?)
Non-Functional Requirement nói lên quality of services của giải pháp (how the system work?)
Quanh mình đâu đâu cũng thấy việc marketing, thông tin về ngành nghề marketing. Cứ mỗi 10 bạn mình tư vấn CV, cũng có ít nhất 6-7 bạn mong muốn làm hoặc đã từng làm một số công việc nhỏ liên quan đến ngành này. Thiết nghĩ marketing nhiều như vậy, mình nên viết một bài chia sẻ ngắn ngắn của mình về lĩnh vực này.
Bài viết này mình sẽ không viết về ngành marketing đâu, mà mình muốn đề cập đến việc mình có thể dùng ‘các kĩ thuật marketing’ nào để quảng bá CV của mình. Để quảng bá được hàng tốt, thì phải quảng báo được bản thân tốt trước đã chứ nhỉ? Các kĩ thuật này có thể dùng cho CV ở mọi ngành nghề, không riêng gì marketing đâu nhé.
1) Làm SEO cho CV
Chắc nhiều bạn cũng có nghe về khái niệm SEO rồi, nhưng cũng có thể chưa biết kĩ lắm. SEO tức là search engine optimization ấy, nôm na là viết nội dung website sử dụng các từ khoá sao cho website của mình lúc search ra phát là xuất hiện ngay trên Google.
Tương tự như làm SEO cho website vậy, CV của chúng mình cũng cần được SEO để được nhà tuyển dụng chú ý hơn, đọc lướt mà vẫn chú ý giữa hàng ngàn CV khác bên cạnh. Có 2 kĩ thuật mình thường áp dụng để giúp cho content của CV tốt hơn, đó là:
1.1 – Dùng ‘key words’ phù hợp
Nôm na kĩ thuật này là phải làm sao để biến cho CV của mình có một chút na ná và những ngôn từ kĩ thuật giống như trong tin tuyển dụng của nhà tuyển dụng đăng lên ấy. Một ví dụ cụ thể, dưới đây là tin tuyển dụng cho vị trí International Marketing Executive cho một công ty giáo dục ở HCMC:
Nếu nhìn nhanh, mình sẽ thấy một số từ khoá đặc thù của công việc này – tức việc marketing đó là ‘exhibitions’, ‘events’, ‘newsletters’, ‘direct mail’, ‘press releases’. Khi đã tìm ra từ khoá rồi, thì nhiệm vụ của chúng mình là phải edit/ sửa lại cho nội dung CV sao cho xuất hiện những từ giống như thế này. Ví dụ thay vì viết:
Manage the promotional activities of the ABC company.
Mình có thể viết lại:
Prepare promotional tasks for ABC company including writing 2 newsletters and 1 press release monthly, sending direct mail through MailChimp system to a database of 1000+ clients.
Vì tiếng Anh không phải ngôn ngữ mẹ đẻ của chúng mình, nên mình hiểu tại sao khi đọc CV, các từ như ‘support’, ‘manage’, ‘help’, ‘do’, etc. lại xuất hiện vô cùng nhiều. Chính mình đến tận bây giờ để mà viết CV, cũng rất bế tắc nếu muốn tìm những động từ khác hay ho hơn để có thể thay thế.
Tuy nhiên nhờ sự xuất hiện của Google, mình bớt bế tắc hơn một chút. Bạn có thể click vào link này, để xem 185 động từ có thể dùng thay thế cho các động từ nhàm chán trên.
Một ví dụ đơn giản, thay cho việc dùng từ increased, mình sẽ có một vài cách dùng khác như “rocketed sales by 30%,” “slashed sales cycle by 20%,” hoặc là “supercharged sales staff performance.”
2) Chèn link vào CV
Bây giờ không như xưa nữa rồi, công nghệ ngày càng phát triển hơn, CV ngày càng đa dạng. Đơn giản nhất bây giờ vẫn là viết ra Word và nộp qua email. Một số cách sáng tạo hơn có thể là viết trên Powerpoint theo dạng portfolio (mình thấy có bạn viết cả trên Excel @@), bạn nào giỏi thiết kế thì dùng Photoshop, Illustrator, bạn nào giỏi web thì làm hẳn một website portfolio cá nhân luôn.
Vậy nên khi viết CV, chúng mình cũng có thể chèn link vào CV để giới thiệu thêm về website cá nhân, dự án video, bài viết đã làm, đã viết để quảng bá thêm bản thân. Tốt nhất là bạn Ctrl + K thôi chứ đừng copy paste cả cái link dài ngoằng vào CV nhé. Đây là ví dụ trực tiếp từ CV cũ của mình:
Mạng xã hội đang ngày càng phát triển nhanh chóng, ở Việt Nam hiện tại dùng nhiều nhất là Facebook, rồi đến Instagram, LinkedIn, Twitter, Tumblr, etc.
Một số nhà tuyển dụng tọc mạch, ví dụ giống mình, sẽ hay lên Google và tìm các trang mạng cá nhân của ứng viên, để tìm hiểu thêm những thông tin bên lề. Vậy nên theo mình để tiết kiệm thời gian cho nhà tuyển dụng, bạn nên để luôn một vài thông tin các trang mạng xã hội bạn đang dùng lên CV để NTD xem. Ấy nhưng mà khoan?
Đừng vội vàng hấp tấp kẻo nó sẽ thành con dao 2 lưỡi. Mình chỉ khuyên các bạn cho link mạng xã hội vào CV nếu bạn thực sự thấy trang của bạn chuyên nghiệp và có ích cho NTD khi họ tìm kiếm thông tin. Tốt nhất và thời điểm này là bạn nên tạo một tài khoản LinkedIn, cập nhật thông tin cá nhân của mình vào đó – là cách chuyên nghiệp nhất hiện tại.
Bài viết được sự cho phép bởi tác giả Vũ Thành Nam
Bài viết này mình sẽ giới thiệu cho các bạn cách kiến trúc sharding trong distributed database.
Điều đầu tiên, khi bạn đã quyết định chia nhỏ cơ sở dữ liệu với sharding, bạn cần phải hiểu rõ nó nên và sẽ làm như thế nào. Khi bạn bắt đầu chạy truy vấn dữ liệu trong các bảng được chia nhỏ, điều quan trọng là bạn phải xác định đúng phân đoạn mà bạn cần truy vấn. Nếu không nó có thể dẫn đến việc mất dữ liệu hoặc truy vấn chậm chạp một cách đáng tiếc.
Trong phần này mình sẽ cùng các bạn làm rõ kiến trúc sharding phổ biến và quy trình sử dụng nó nhằm đảm bảo việc phân phối và truy vấn dữ liệu trên cơ sở dữ liệu phân tán sao cho phù hợp nhất (mình nhấn mạnh là phù hợp nhất nhé, chứ không phải tốt nhất).
Đối với sharding, mình xin được chia nó ra thành 3 loại cơ bản: Key Based Sharding, Range Based Sharding, Directory Based Sharding. Mình sẽ đi cụ thể từng loại như sau:
Key Based Sharding
Đối với loại sharding này hay còn được biết đến là Hash Based Sharding. Đây là một loại sharding phổ biến nhất trong Citus Data. Nếu bạn từng thiết kế một cơ sở dữ liệu với các bảng liên kết với nhau theo hình thức khóa chính khóa ngoại, bảng cha bảng con thì có lẽ bạn đã từng hiểu rằng khi truy vấn tập dữ liệu bảng con theo khóa ngoại là id của bảng cha thì nó khá là đơn giản.
Một câu lênh truy vấn kèm thêm điều kiện khóa ngoại sẽ giúp bạn làm điều đó, bản chất vấn đề là cơ sở dữ liệu vấn phải duyệt qua từng bản ghi (record hay row) sau đó so sánh với điều kiện khóa ngoại có bằng với id kia không để có thể lấy ra bản ghi đó. Quá trình này khiến cơ sở dữ liệu truyền thống mất khá nhiều thời gian nếu bạn chứa rất nhiều records trong table.
Dựa trên khó khăn đó Citus có thể giải quyết vấn đề này cho bạn bằng cách sharding key, bạn chia từng phần từng phần các record theo nhóm khóa ngoại nằm trên các node khác nhau. Khi đó nếu bạn cần truy vấn dữ liệu với loại khóa ngoại đó thì Citus sẽ nhắm đúng node có khóa ngoại mà bạn sharding để tới đúng vị trí lấy đúng tập dữ liệu mà bạn cần. Khi bạn chọn một trường làm sharding key, Citus sẽ có một function hash key đó lại nhằm đánh dấu tập dữ liệu của bạn được shard trên node số mấy. Vấn đề truy vấn chỉ là lấy tập dữ liệu hash sẵn đó ra mà thôi.
Ví dụ rằng bạn có 10,000,000 record với 5 kiểu khác nhau, thì việc đánh sharding cho mỗi kiểu sẽ giúp bạn truy vấn số record trên mỗi kiểu nhanh hơn, nó sẽ quét đúng tập dữ liệu 2,000,000 records thay vì quét hết cả 10,000,000 records. Điều này dẫn tới tốc độ truy vấn sẽ nhanh hơn hẳn.
Cách sharding key này được dùng rất phổ biết và khá đơn giản với cú pháp này
Bạn có thể thấy tenant_id chính là khóa ngoại của bảng questions được liên kết tới bảng tenants. Và khi chúng ta sharding thì bạn có thể lấy chính khóa ngoại này làm trường shard key.
Tuy nhiên không phải chúng ta chỉ được lấy khóa ngoại làm trường shard key đâu nhé. Tùy thuộc vào dữ liệu của bạn có sự gom nhóm phù hợp mà bạn chọn trường nhóm đó làm sharding. Chỉ cần trường đó của bạn là duy nhất và ít thay đổi, chính xác hơn là không được thay đổi, nếu thay đổi bạn cần sharding lại để Citus có thể hiểu được và sắp xếp hash values lại sao cho phù hợp với lần truy vấn tiếp theo. Cách truy vấn thì cũng đơn gian thôi, chỉ cần bạn thêm điều kiện where với trường shard key, còn lại citus sẽ lo hết giúp bạn. Nó sẽ dựa trên hash value để tìm đúng địa chỉ node và truy vấn tập dữ liệu mà bạn cần.
Range Based Sharding
Khác với Key Based Sharding, đối với Range Based Sharding thì Citus sẽ gom nhóm các khoảng giá trị của bạn định nghĩa theo từng nhóm khoảng giá trị thay vì theo key. Ví dụ bạn có khoảng 10,000,000 record thì citus sẽ giúp bạn sharding chia thành từng khoảng giá trị với trường định nghĩa, từ 1 đến 1000, từ 1001 đến 2000,… cứ như thế các nhóm giá trị được hình thành và được phân bổ vào các node. Tương tự thì cách truy vấn citus giúp bạn tìm kiếm tập giá trị thuộc nhóm range nào để trỏ đúng nodes cần tìm và lấy giá trị đó lên
Điểm khó khăn của cách phân bổ này là khoảng dữ liệu sẽ bị mất cân bằng khi yêu cầu truy vấn bị lệch về một khoảng giá trị nào đó, và có những khoảng giá trị thì không bao giờ được truy vấn. Như hình minh họa trên, do mình chia khoảng giá thành 3 phần nhưng nghiệp vụ của mình chỉ toàn truy vấn trong khoảng từ 0 đến 49.99$ mà thôi. Vậy là tự nhiên sự phân bổ này bị mất cân bằng và làm cho ý nghĩa của việc sharding không còn phát huy đúng hiệu quả của mình nữa.
Directory Based Sharding
Tương tự như Key Based Sharding, Directory Based Sharding chia các nhóm cơ sở dữ liệu có điểm chung vào thành những nhóm và shard key chúng, nhưng thay vì sử dụng hash values thì loại sharding này lại sử dụng delivery zone. Bạn hình dung Key Based Sharding như việc chia những dữ liệu thành nhiều file, còn Directory Based Sharding lại chia dữ liệu ra thành nhiều folder, mỗi folder sẽ có chứa nhiều file, và trong file mới thực sự là dữ liệu bạn cần.
Loại sharding này còn có thêm một bảng tra cứu giống như mục lục vậy, shard key nào thuộc zone nào, từ đó giúp cho việc phân loại và truy vấn được dễ dàng hơn. Mặt khác, phân đoạn dựa trên thư mục cho phép bạn sử dụng bất kỳ hệ thống hoặc thuật toán nào bạn muốn để gán các mục nhập dữ liệu cho các phân đoạn và việc thêm động các phân đoạn bằng cách sử dụng phương pháp này tương đối dễ dàng.
Mặc dù Directory Based Sharding là phương pháp linh hoạt nhất trong số các phương pháp sharding được thảo luận ở đây, nhưng nhu cầu kết nối với bảng tra cứu trước mọi truy vấn hoặc ghi có thể có tác động bất lợi đến hiệu suất của ứng dụng. Hơn nữa, bảng tra cứu có thể trở thành một điểm lỗi, một điểm chí mạng: nếu nó bị hỏng hoặc không thành công, nó có thể ảnh hưởng đến khả năng ghi dữ liệu mới hoặc truy cập dữ liệu hiện có.
Vì vậy việc gom nhóm này thường chỉ sử dụng cho các cơ sở dữ liệu có độ phức tạp cao, cấu trúc phân nhóm nhiều, để có thể dễ dàng phân loại chúng. Còn nếu bạn có cơ sở dữ liệu đơn giản thì có lẽ Key Based Sharding là đủ cho bạn.
Việc có hay không nên triển khai sharded database architecture vẫn còn là một chủ đề tranh cái của nhiều lập trình viên. Đa số các lập trình viên coi sharding là một kết quả không thể tránh khỏi trước sự bùng nổ dữ liệu lớn quá nhanh và mạnh mẽ và khi chúng đạt đến một kích thước nhất định, nhưng có một số lập trình viên thì lại coi đó là một vấn đề nên tránh do nó rất phức tạp và đau đầu để xử lý những thứ liên quan trừ khi nó thực sự cần thiết và bất đắc dĩ. Cũng dễ hiểu thôi, sharding thực sự phức tạp hơn bạn nghĩ trong cách hoặt động và việc thêm bớt các node shard.
Do sự phức tạp tăng thêm này, nên sharding thường chỉ được thực hiện khi xử lý lượng dữ liệu rất lớn. Dưới đây là một số tình huống phổ biến trong đó việc chia nhỏ cơ sở dữ liệu có thể có lợi:
– Số lượng dữ liệu của ứng dụng tăng lên vượt quá khả năng lưu trữ của một node cơ sở dữ liệu duy nhất.
– Khối lượng ghi hoặc đọc vào cơ sở dữ liệu vượt quá những gì mà một node đơn hay cluster có thể xử lý, dẫn đến thời gian phản hồi hoặc thời gian chờ bị chậm lại.
– Băng thông đường truyền mạng mà ứng dụng yêu cầu lớn hơn băng thông có sẵn cho một node database.
Trước khi nghĩ đến sharding, có lẽ bạn nên nghĩ đến một số sự lựa chọn khác để tối ưu hóa cơ sở dữ liệu của mình, do sharding là một giải pháp đáng cân nhắc lại. Dưới đây là một số giải pháp tối ưu hóa khác mà bạn có thể xem xét trước khi sử dụng sharding:
– Setting up a remote database:
Nếu bạn đang làm việc với ứng dụng monolithic trong đó tất cả các thành phần nằm trên cùng một máy chủ, bạn có thể cải thiện hiệu suất cơ sở dữ hiệu bằng cách chuyển server cơ sở dữ liệu sang chính máy khởi chạy ứng dụng. Điều này không làm phức tạp thêm nhiều như sharding vì các bảng của cơ sở dữ liệu vẫn còn nguyên vẹn. Tuy nhiên, nó vẫn cho phép bạn chia tỷ lệ cơ sở dữ liệu của mình theo chiều dọc so với phần còn lại của cơ sở hạ tầng. Hơn nữa đường truyền dữ liệu sẽ tốt hơn do chúng nằm trên cùng một máy chủ.
– Implementing caching:
Nếu hiệu suất đọc của ứng dụng là nguyên nhân khiến bạn gặp rắc rối, thì bộ nhớ đệm là một chiến lược có thể giúp cải thiện điều đó. Bộ nhớ đệm bao gồm việc lưu trữ tạm thời dữ liệu đã được yêu cầu trong bộ nhớ trước đó cho phép bạn truy cập dữ liệu đó nhanh hơn nhiều sau này.
– Creating one or more read replicas:
Một chiến lược khác có thể giúp cải thiện hiệu suất đọc, điều này liên quan đến việc sao chép dữ liệu từ một máy chủ cơ sở dữ liệu (máy chủ chính) sang một hoặc nhiều máy chủ phụ.
Sau đó, mọi bản ghi mới sẽ được chuyển đến bản chính trước khi được sao chép sang bản thứ hai, trong khi các lần đọc được thực hiện riêng cho các máy chủ thứ cấp. Việc phân phối các lần đọc và ghi như thế này giúp cho bất kỳ máy nào không phải chịu quá nhiều tải, giúp tránh bị chậm và treo máy.
Giải pháp này thường sử dụng trong các mạng xã hội, họ lợi dụng điểm mạnh của no-sql là truy vấn nhanh để lưu một cơ sở dữ liệu phụ và đồng bộ chúng về cơ sở dữ liệu chính dưới background chạy nền ngay sau đó.
Lưu ý rằng việc tạo bản sao đọc liên quan đến nhiều tài nguyên máy tính hơn và do đó tốn nhiều chi phí tiền bạc hơn, đây có thể là một hạn chế đáng kể đối với một số người.
– Upgrading to a larger server:
Trong hầu hết các trường hợp, việc mở rộng máy chủ cơ sở dữ liệu của một người thành một máy có nhiều tài nguyên hơn đòi hỏi ít nỗ lực hơn so với sharding.
Giống như việc tạo bản sao đọc, một máy chủ được nâng cấp với nhiều tài nguyên hơn có thể sẽ tốn nhiều tiền hơn. Do đó, bạn chỉ nên thực hiện việc thay đổi kích thước nếu nó thực sự trở thành lựa chọn tốt nhất của bạn.
Cái gì giải quyết được bằng tiền thì luôn dễ dàng hơn đúng không ạ 😀
Hãy nhớ rằng nếu ứng dụng hoặc trang web của bạn phát triển vượt qua một thời điểm nhất định, không có chiến lược nào trong số này sẽ đủ để tự cải thiện hiệu suất của chúng. Trong những trường hợp như vậy, sharding thực sự có thể là lựa chọn tốt nhất cho bạn.
Tóm lại Sharding có thể là một giải pháp tuyệt vời cho những người muốn mở rộng cơ sở dữ liệu của họ theo chiều ngang. Tuy nhiên, nó cũng thêm nhiều phức tạp và tạo ra nhiều điểm thất bại tiềm ẩn cho ứng dụng của bạn. Sharding có thể là cần thiết đối với một số người, nhưng thời gian và nguồn lực cần thiết để tạo và duy trì một kiến trúc phân đoạn có thể lớn hơn lợi ích cho những người khác.
Hi vọng bài viết này có thể giúp bạn hiểu rõ hơn nữa về sharding, nên và không nên sử dụng hướng tới giải pháp sharding này.
Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh
Bài này mình sẽ đi sơ lược cho anh em: BPMN là gì, tại sao nó ra đời, dành cho đối tượng nào. Và quan trọng hơn hết, BPMN được dùng cho mục đích gì?
Okay, let’s gooooo!!!
1. BPMN là gì?
BPMN là viết tắt của Business Process Modeling Notation. “Notation” nghĩa là ký hiệu. Tức BPMN là tập hợp các ký hiệu chuẩn để mô tả quy trình của doanh nghiệp. Hay để mô hình hóa quy trình của doanh nghiệp.
Để hiểu chi tiết hơn thì anh em bấm vào hình dưới đây để xem ví dụ.
À nhầm, không phải hình đó, hình dưới này nha anh em ?
Quy trình từ lúc khách hàng đặt bánh pizza đến khi ăn bánh pizza. (Nguồn ảnh: BusinessProcessIncubator.com)
2. Tại sao nó quan trọng?
BPMN là một trong những vũ khí tối quan trọng của anh em nào làm BA. Vì sao? Vì trong công việc, mình phải tiếp cận và lắng nghe rất nhiều quy trình nghiệp vụ của khách hàng.
Lắng nghe xong, nhiệm vụ của anh em là phải document lại. Mà mỗi khách hàng mỗi khác nhau, mỗi quy trình mỗi phức tạp. Document sao cho gọn, cho dễ đọc mà vẫn đảm bảo được nội dung gốc ban đầu? BPMN chính là câu trả lời.
Chỉ khi anh em thật sự hiểu được khách hàng, hiểu được quy trình họ làm hằng ngày. Thì mình mới nhìn nhận ra được, đâu là điểm chưa tối ưu trong quy trình của họ.
Và không chỉ có một mình mình cần hiểu, BA phải truyền đạt lại những “hiện trạng” và yêu cầu của khách hàng cho cả team cùng hiểu. Khi đó, BPMN là phương pháp tối ưu nhất để truyền đạt lại mớ bồng bông các quy trình này.
Có lần mình làm dự án cho khách hàng là 1 công ty nhà nước. Phải nói quy trình của khách hàng này là mother of lộn xộn, tuầy huầy, tùm lum tùm la hết. Một mớ công văn, một mớ giấy tờ. Mà bản nào cũng 5-6 trang A4.
Quy trình của họ thể hiện bằng chữ trong văn bản. Đọc thì cũng hiểu thôi. Nhưng khi số lượng quy trình ngày một tăng thì càng đọc càng rối ?
Chưa kể các quy trình không bao giờ đứng riêng lẻ, mà luôn kết nối với nhau. Output của thằng này sẽ luôn là input của thằng tiếp theo.
Một khi quy trình thể hiện bằng văn bản, thì phải nói là rất khó cho team để mapping các quy trình lại với nhau. Vì đọc chữ sẽ tốn sức hơn nhiều so với xem hình ảnh. Chưa kể đọc xong phải mường tượng luồng đi của quy trình, rồi từ đó mới mapping được.
Thế là team mất gần cả tháng trời để tổng hợp, phân loại và sắp xếp nó cho ra hồn, rồi mới modeling bằng BPMN được. Giờ nghĩ lại vẫn còn thấy ớn ớn…
Nói theo kiểu ba láp ba xàm thì già trẻ, lớn bé, đẹp chai, đẹp gái gì cũng dùng BPMN được hết, vì nó khá là dễ. Còn nói theo kiểu đàng quàng thì BPMN dành cho cả người dùng high level lẫn lower level đọc.
High level là sao? Họ là những người quản lý tầng trên, họ chỉ cần care đến bức tranh tổng quan, và nắm được trong đó có những quy trình nào là chủ yếu.
High Level chỉ cần quan tâm, để ra được báo giá thì cần có mấy bước, tương tác với những đối tượng nào, hoặc có những document nào liên quan…
Còn lower level là những người dùng trực tiếp, họ follow theo quy trình để làm. Do đó, BPMN cho những đối tượng này thường rất chi tiết và cover được toàn bộ các trường hợp có thể xảy ra.
4. Bà con với UML?
Mình thấy có nhiều anh em hay nhầm BPMN với UML. Hồi xưa mình cũng hay nhầm, nhưng giờ chịu khó google nên cũng phân biệt được hai anh này.
UML là Unified Modeling Language – ngôn ngữ mô hình thống nhất. Tên tiếng Việt dịch ra nghe hơi chuối, nên thôi anh em cứ đọc là UML cho chắc. Nôm na, UML là tập hợp các diagram và các ký hiệu để mô tảphần mềm. Nôm na là như vậy.
Anh em nghe có thấy nó giống với BPMN hông. Cơ bản cũng là mấy cái hình vẽ thôi, nhưng mục đích của nó lại khác nhau.
Trong khi BPMN hướng tới quy trình nghiệp vụ,
thì UML hướng tới việc xây dựng phần mềm.
Cụ thể, BPMN tiếp cận theo hướng process-oriented, còn UML thì tiếp cận theo hướng object-oriented.
Process-oriented là tập trung trả lời cho câu hỏi: khách hàng phải làm bao nhiêu bước, đó là những bước gì, trong thời gian bao lâu để hoàn thành được công việc, mục tiêu.
Còn Object-oriented tập trung cho việc mổ xẻ một đối tượng theo nhiều góc nhìn, chiều kích khác nhau để rõ ràng hơn cho việc thiết kế và xây dựng hệ thống.
Do đó, để có nhiều góc nhìn khác nhau, thì UML có hẳn một bộ các diagram khác nhau. Mỗi diagram có một chức năng riêng. Ví dụ lấy đối tượng Customer ra mổ xẻ. Anh em có thể mô hình hóa được đối tượng Customer này (bằng UML) ở nhiều khía cạnh khác nhau:
Customer có những thuộc tính gì, mối quan hệ giữa đối tượng Customer và các đối tượng khác ra sao (Class Diagram).
Customer có thể làm được những tính năng gì, tương tác với hệ thống và các đối tượng khác ra sao (Use Case Diagram).
Hoạt động của Customer theo trình tự thời gian là như thế nào (Sequence Diagram).
Và còn rất nhiều khía cạnh với nhiều diagram khác nữa, mình sẽ nói ở bài sau nhé anh em.
Còn BPMN, như anh em thấy chỉ có 1 diagram duy nhất. Bởi vì nó chỉ có 1 mục đích duy nhất: thể hiện được quy trình nghiệp vụ.
Tóm lại, UML và BPMN là hai khái niệm hoàn toàn khác nhau. Nó không tương phản mà lại ăn nhậu rất hợp rơ với nhau. Trong dự án, anh em vừa phải dùng UML, vừa phải dùng BPMN thì document mới đầy đủ, và cover hết các khía cạnh được 🙂
Kể cho anh em chuyện này nghe mất hồn chơi.
Hồi xưa mình làm 1 dự án theo kiểu Agile… hơi nửa vời chút xíu :v Document làm toàn BPMN, và mình thề là nguyên bộ Solution Design không quá… 100 chữ. Vì chỉ toàn hình là hình. Nghĩ thế là khỏe, vì document quá tiện và gọn nhẹ.
Tuy nhiên vấn đề bắt đầu xuất hiện khi có change request, mà toàn liên quan tới những cái vặt vặt mới ghê. Ví dụ như message thông báo, nội dung email template, status của record…
Mà BPMN thì không thần thánh tới mức… cover được hết những tiểu tiết này. Nên hồi đó mình phải note chi chít các chi tiết nhỏ này vào quy trình BPMN. Khiến cho nó rối, sai quy tắc notation, và đặc biệt là rất… oải để đọc nó.
Và khi có change request, thì rất khó để anh em trace lại được những sự thay đổi. Những sự thay đổi mà BPMN không ghi nhận được, như những chi tiết nhỏ mình nói ở trên. Do đó, không phải cứ dùng BPMN là hay, cái gì lạm dụng quá cũng sẽ bị phản dam. Cũng may dự án đã Go-Live thành công, chứ không cả đám ăn cám hết.
Thường thì software implementation ít dùng UML nhiều như software development. Nhưng khi nảy sinh một yêu cầu mới cần phải build từ đầu, thì lấy UML ra dùng cũng là một sự lựa chọn không tồi. Đừng khư khư mãi vào BPMN nhé anh em.
BPMN tập trung vào quy trình, còn UML tập trung vào từng đối tượng cụ thể để phục vụ cho việc build phần mềm (Nguồn ảnh: bonkersworld.net)
5. BPMN cứu rỗi đời mình như thế nào?
Trước khi kết thúc bài này thì mình sẽ kể cho anh em nghe một câu chuyện hư cấu có thật.
Đó là lần team dự án mình gặp phải một kèo chua cay như gói mì hảo hảo.
Đây là một khách hàng B2B, vừa sản xuất vừa bán B2B luôn. Mà bán B2B thì quy trình duyệt giá cho một đơn hàng khá phức tạp. Vì giá trị đơn hàng là rất lớn, và phải luôn đảm bảo giá tốt nhất cho khách mua hàng.
Lần đó team mình qua phải 3, 4 lần gì mới lấy được requirement cụ thể cho quy trình làm báo giá này. Nó qua rất nhiều bước.
Từ lúc Salesperson nhận một yêu cầu hỏi hàng, sau đó sẽ làm báo giá cho khách hàng. Đa phần các báo giá đều sẽ được áp các mức chiết khấu mặc định, phụ thuộc vào khách hàng và số lượng sản phẩm khác nhau.
Nếu Salesperson không muốn giảm giá gì thêm thì họ sẽ gửi báo giá cho khách hàng duyệt. Nếu khách hàng đồng ý thì nhập ngày giao hàng (mà khách yêu cầu), rồi kiểm tồn kho (check on hand), và cuối cùng là làm Order. Nếu không đồng ý thì Salesperson phải deal lại ngày giao hàng.
Còn nếu Salesperson muốn có một mức giá tốt hơn mức giá chuẩn (tức là discount nhiều hơn mức discount chuẩn cho phép), thì Salesperson phải xin giá. Mà để xin giá thì phải raise yêu cầu cho Team Leader.
Tức là Salesperson sẽ nhập mức discount họ mong muốn. Sau đó chuyển qua Team Leader để duyệt giá chặng một. Team Leader sẽ dựa vào mức discount mà Salesperson đề xuất để duyệt giá.
Nếu mức discount làm cho giá trị của từng line sản phẩm vẫn cao hơn hoặc bằng giá vốn hàng bán (COGS), Team Leader sẽ tự cân đối revenue trong quý mà duyệt hoặc không.
Nếu mức discount mà Salesperson yêu cầu cao quá, làm cho giá trị của từng line sản phẩm thấp hơn cả giá vốn hàng bán (tức là bán chịu lỗ, không để mất khách) thì Team Leader không có quyền duyệt, mà phải đẩy lên Sales Manager để duyệt giá chặng hai. Anh sếp ảnh cho thì bán, không thì phải xin giá lại từ đầu.
Đó chỉ mới là bán hàng OBL (Own Brand Labelling), tức là hàng chuẩn, hàng mình tự sản xuất rồi bán. Còn bán hàng OEM thì phức tạp hơn. OEM là Orginal Equipment Manufacturing, tức là mình sản xuất theo thiết kế, yêu cầu đặc thù của khách hàng.
Ví dụ sản xuất 5000 cái bô dài 50 cm, rộng 40 cm, cao 30 cm, có in hình mặt cười nham nhở chẳng hạn.
Đối với hàng OEM thì phải đưa yêu cầu thiết kế qua bên R&D, rã ra BOM (bill of materials), rồi chạy Pilot (làm hàng mẫu). Nếu fail ở bước nào, thì quy trình trả về Salesperson, yêu cầu trao đổi lại với khách hàng.
Chạy Pilot xong mà khách hàng ok mẫu mã này nọ xong xuôi, thì tiếp tục tới phần giá như ở trên. Nhưng đâu dễ ăn của ngoại.
Vì là hàng OEM, nên cần phải phân rã BOM ra và đưa qua bộ kế toán để xin giá vốn hàng bán (vì là sản phẩm mới toanh nên đâu biết giá gốc bao nhiêu đâu mà bán).
Tức là cái bô có thành bô, miệng bô, thân bô. Mỗi bộ phân bao nhiêu tiền, ghép lại thành một cái bô, sẽ ra được giá gốc là bao nhiêu tiền. Rồi gom góp các loại chi phí sản xuất, môi trường, nhân công, điện nước này nọ. Ra được một mức giá, gọi là giá vốn hàng bán (COGS). Rồi mới đưa cái cục giá đó cho ông Salesperson, ổng sẽ lấy mức giá này để bắt đầu deal với khách hàng. Rồi đoạn deal phía sau, sẽ tiếp tục quy trình báo giá cho sản phẩm OBL như phía trên.
Đó là tóm tắt quy trình của khách hàng, bằng chữ. Anh em thấy quá mệt đúng không. Đưa một mớ này vô document chắc chả ai thèm đọc hết.
Khi đó, BPMN xuất hiện như một vị cứu tinh. Những notation của BPMN đều cover được hết quy trình bên trên.
Bấm hình dưới đây xem chi tiết nhé anh em.
Anh em thông cảm, hình hơi mờ. Chờ xíu cho nó load đủ >> bấm vào nút View Full Size để xem full HD.
Do đó, không có BPMN, mình cũng chả biết transfer lại quy trình này cho team như thế nào cho hiệu quả. Mặc dù mình vẫn có thể chế ra các ký hiệu để vẽ vời, miễn đáp ứng được yêu cầu trên.
Nhưng khi deliver tài liệu cho bất kỳ một stakeholders nào khác, chẳng lẽ lại phải mất công giải thích: cái ô vuông nghĩa là A, cái hình chữ nhật nghĩa là B. Như vậy rất tốn thời gian. Trong khi BPMN đã là một cái chuẩn, vẽ con mèo là mọi người hiểu ngay con mèo, không thể nào hiểu ra con chó được.
Do đó, in BPMN, we trust ?
6. Tạm kết
Mình sẽ tạm dừng bài 1 về BPMN ở đây. Qua bài này hi vọng anh em nắm được:
BPMN là gì? (Business Process Modeling Notation)
Tại sao nó lại quan trọng? (giúp BA document và transfer thông tin hiệu quả hơn)
Dành cho đối tượng nào? (hầu hết là mọi người)
BPMN khác với UML ra sao? (một ông làm về process, còn một ông làm về software)
Ở bài sau chúng ta sẽ đi chi tiết vào “BPMN in action”. BPMN gồm những thành phần gì và các nguyên tắc khi vẽ BPMN.
Nếu cảm thấy “con hàng” BPMN này có thể giúp ích nhiều được cho mình trong công việc, thì anh em có thể mạnh dạn tham khảo các khoá học BPMN ngắn hạn nhé.
Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh
Hế lôôôôô anh em. Hôm nay mình sẽ note về một đề tài khá “muôn thuở”. Đó là chuyện yêu cầu kinh nghiệm khi đi phỏng vấn làm Business Analyst.
Bài này mình muốn chia sẻ chủ yếu cho hai đối tượng.
Một là những anh em còn đang ngồi giảng đường, mong muốn làm BA, nhưng đang lo lắng, bồn chồn. Không biết chưa có kinh nghiệm thì có ứng tuyển BA ổn không.
Hai là những anh em đã đi làm, nhưng không phải làm BA. Giờ muốn chuyển sang làm BA, nhưng lại sợ kinh nghiệm không phù hợp.
Anh em nào không thuộc hai nhóm trên, vẫn có thể đọc tiếp. Vì đơn giản, đây là blog của mình nên mình thích nói gì thì nói thôi, hố hố.
Bài này mình chia sẻ cho anh em với tư cách: từng là một chàng sinh ziên đẹp chai thanh lịch zô địch khắp vũ trụ, chân ướt chân ráo mới ra trường ăn may sao được nhận vào làm BA.
Ngoài ra, hồi đại học mình cũng được làm một job BA internship. Và đặc biệt là mình cũng từng bị rớt phỏng vấn BA lúc mới ra trường. Do đó, mình rất hiểu những gì sinh viên có, và không có, để phù hợp với vị trí BA.
Bài này mình sẽ gom góp, sắp xếp lại mọi thứ theo góc nhìn của mình. Để từ đó, anh em có sự chuẩn bị tốt hơn khi ra trường, cũng như khi apply vị trí BA.
Okay, let’s goooooo!!!
1. Ý đồ thật sự của chữ “kinh nghiệm”
1.1. Công thức chung
Tất cả đều bắt đầu từ Job Description.
Nhà tuyển dụng viết JD không chỉ để anh em đọc vào rồi xem thử: à cái này tui đã từng làm chưa, à cái kia tui chưa làm bao giờ hết, hay cái này khó quá nên chắc không phù hợp.
Hổng phải zậy!!!
Nhà tuyển dụng viết JD là để anh em dòm vào đó, một cách cẩn thận. Rồi từ từ suy xét xem: Kinh nghiệm của mình có làm được những việc này hay không? Chứ hổng phải: Mình đã từng làm những việc này hay chưa?
Do đó, để làm BA (hoặc bất kỳ công việc nào khác), đầu tiên anh em phải hiểu công việc đó làm gì cái đã. Cái này đơn giản, bỏ qua.
Sau khi biết được công việc đó làm gì, anh em phải ngồi chiêm nghiệm lại các kinh nghiệm mình có. Sau đó, phân tích và mapping kinh nghiệm của mình vào công việc trong Job Description. Cuối cùng là rút ra kết luận, mình có thực sự phù hợp hay không. Vậy là ok!
Ngâm cứu Job Description >> Chiêm nghiệm >> Phân tích >> Kết luận
Sẽ không ai tuyển một thợ Nail đi làm BA, và cũng không ai tuyển một BA đi làm thợ Nail cả. Tuyển thợ điện đi làm thợ sửa ống nước, thợ sửa xe máy thì được. Chứ tuyển thợ điện đi làm kỹ sư cầu đường thì quả thật rất khó.
Giữa kinh nghiệm và yêu cầu công việc, nó phải có gì đó ăn nhậu với nhau. Chứ trớt quớt quá thì fail là cái chắc. Do đó, biết mình biết ta, trăm trận không thua. Khi đó anh em mới dám mạnh dạn tự tin mà đi phỏng vấn được.
1.2. Yêu cầu công việc của BA
Hiểu được điều cơ bản trên, anh em sẽ tự vạch ra cho mình những nước đi đúng đắn nhất từ thời sinh viên. Cái mình cần ở đây là kinh-nghiệm-liên-quan-tới-yêu-cầu-công-việc của BA.
Thành thạo tiếng Anh, nói được tiếng Nhật và đọc được tài liệu tiếng Pháp.
Có domain knowledge về ngành sản xuất, y tế, giáo dục, nhân sự, tài chính, ngân hàng,…nói chung là biết tuốt.
Hiểu tường tận về blockchain là một lợi thế.
Thuần thục Agile/ Scrum.
Có khả năng multitask, như vừa lấy yêu cầu, vừa document ngay tại chỗ luôn.
Yêu cầu năng suất làm việc cao, có thể làm việc liên tù tì từ 9 giờ sáng tới 9 giờ tối mà không lèm bèm, càm ràm gì hết.
…
Đó, ví dụ về một Job Description. Mặc dù nghe giống tuyển siêu nhân hơn là tuyển BA. Nhưng không sao, anh em chỉ cần để ý tới phần mô tả công việc thôi.
Đó là những công việc mà một người BA sẽ làm. Do đó, mình cần phải build up những kinh nghiệm liên quan tới các đầu việc này. Phân tích một tí về các công việc đặc trưng của BA thì gồm 2 nhóm kỹ năng.
Thu thập yêu cầu từ khách hàng ==> Kỹ năng giao tiếp, thuyết phục, thuyết trình, đặt câu hỏi, lắng nghe, thấu hiểu…
Viết tài liệu dự án ==> Kỹ năng và kiến thức về Word, Excel, Power Point, kỹ năng đánh máy, tối ưu công việc, làm sao cho nhanh, cho hiệu quả.
Làm việc với các stakeholders (khách hàng, Dev, PM, QA, QC…) ==> Kỹ năng làm việc nhóm, xử lý xung đột, kiểm soát cảm xúc, tư duy logic…
Lên kế hoạch công việc ==> Kỹ năng planning, time management.
Kỹ năng cứng
Viết tài liệu dự án ==> Kiến thức và thực hành về UML, BPMN và các loại document có trong dự án.
Hiểu nghiệp vụ ==> Hiểu các nghiệp vụ về Sales, Kế toán, Sản xuất, Marketing, Customer Service, Field Service, Supply Chain…
Domain Knowledge ==> Hiểu về đặc thù các ngành nghề như Banking, Finance, Insurance, Manufacture, Horeca (hotel-restaurant-cafe), Retail, Human Resource, Real Estate, Education…
Thiết kế database ==> Kiến thức và thực hành về database, hiểu về SQL…
Có kiến thức về công nghệ ==> Hiểu cách một application, web app hay mobile app hoạt động. Đối với làm triển khai thì hiểu công nghệ của các hãng (như Microsoft, SAP, Oracle…). Hoặc hiểu về các khái niệm như API, Web Service…
Thiết kế mockup, prototype ==> Kiến thức căn bản về UX/UI và thực hành trên các tool như Visio, Balsamiq Mockup, Axure…
Hiểu quy trình làm việc ==> Kiến thức về Agile/Scrum, Waterpark, à nhầm, Waterfall, hoặc các development management tool như TFS, GitHub, SVN, Jira…
Thường thì dưới phần Mô tả công việc, sẽ luôn có phần Yêu cầu kỹ năng/ kinh nghiệm cụ thể. Tuy nhiên theo mình thì anh em vẫn nên tự phân tích các đầu mục công việc này. Để xem mình có thực sự hiểu những gì người ta đang cần hay không.
Okay, vậy là coi như anh em đã hiểu được Job Description một cách cụ thể.
Tiếp theo, mình sẽ nói về những hành động cụ thể mà anh em có thể làm ngay, để đáp ứng được với các yêu cầu công việc này.
2. Your next step
Khi còn ngồi ghế giảng đường thì có khá nhiều con đường để anh em lựa chọn, cụ thể gồm 6 con đường cơ bản sau:
Tham gia các CLB trong trường
Tham gia các hoạt động tình nguyện
Đi làm thêm, đi làm “pặc-tham”
Xung phong thuyết trình
Học theo nhóm, làm đồ án, làm bài tập theo nhóm
Và cuối cùng là đi thực tập.
Mình chưa thấy ai thời đại học, không làm những việc trên (chí ít là một việc) mà ra trường kiếm được việc ngay cả.
Mình cực kỳ recommend anh em thời đại học nên quẩy những thứ trên. Tệ nhất cũng phải được 2/6 các mục trên. Thì khi đó, ra trường mới có thể tìm được việc ưng ý.
2.1. Chiêm nghiệm
Mình có thằng bạn, hồi năm nhất đại học nó toàn chơi game rồi ngủ. Sang năm hai thấy chán quá nên nó mới quyết định “try something new” bằng cách tham gia điên dại vào các CLB sinh viên trong trường lúc đó.
Mà các CLB này thì hoạt động phải nói là muôn màu phong phú. Từ tổ chức sự kiện, đến đi thiện nguyện, tham gia các cuộc thi, tổ chức training, bán hàng…, nói chung là tùm lum tùm la hết.
Còn trên lớp thì thằng này được cái rất chịu khó làm việc nhóm. Đối tượng thuyết trình chính luôn là nó. Không đẩy nó lên, thì cũng tự nó xung phong, nên anh em trong team đỡ vả lắm.
Ngoài ra, nó cũng chịu khó tham gia các cuộc thi, kiếm tiền đi phượt. Mà được cái nó biết chọn lọc, không phải cuộc thi nào cũng tham gia. Nó chỉ tham gia những cuộc thi liên quan đến ngành nó học thôi, may sao cũng ruồi ruồi được 1-2 giải nhỏ.
Nó cũng chịu khó tham gia mấy tổ chức lợi nhuận phi giáo dục, ủa lộn, mấy tổ chức giáo dục phi lợi nhuận.
Đi dạy mấy đứa nhỏ cấp 1 ở mấy trường dưới Bình Triệu. Nhờ đó mà kỹ năng chém gió của nó cũng lên được kha khá.
Mình để ý là thằng này cũng khá tốt trong việc giao cấu với bạn bè, đồng bọn mới. Kèo đá banh đá bóng gì là đều do nó cầm đầu hết.
Sơ bộ thì thằng bạn mình cũng có đủ các kỹ năng mềm để làm BA chứ hả anh em. Nhưng đó chỉ là một nửa câu chuyện. Nửa còn lại là kỹ năng cứng thì để mình ngó xem nó có gì ?
Vì thằng này là một thằng hay quan sát nên lâu lâu nó hay ba láp ba xàm về mấy thứ xung quanh nó. Như cái máy quẹt thẻ giữ xe nó hoạt động ra sao chẳng hạn.
Nó cũng chịu khó đọc sách. Mà sách nó đọc thì cũng nhiều loại, xàm cũng có, mà cực xàm cũng có.
Nói về chuyện thực tập thì nghe kể đâu nó apply tới tận mười mấy công ty. Mà có đúng 2-3 công ty gì đó là chịu nhận nó.
Chưa kể lúc thực tập về, nó còn làm khóa luận nữa. Hồi đó nghe nói nó làm đề tài về thiết kế hệ thống vận hành dữ liệu đầu vào gì đó cho công ty nghiên cứu thị trường.
Lăn lê bò trường với khóa luận khoảng hơn 3 tháng, nó cũng thu hoạch được khá nhiều vốn liếng. Từ kiến thức nền tảng chung về IT, đến các kiến thức về phân tích, thiết kế hệ thống thực tế.
Chưa kể vì nhiều lần đau thương với Microsoft Word nên nó cũng rút kinh nghiệm nhiều khi làm Word. Nó còn kể lúc thực tập, vì được làm Vlookup nhiều nên Excel nó tự tin lắm.
2.3. Kết luận
Cuối cùng, gom góp lại những gì nó từng trải, từng làm, ngồi chiêm nghiệm một hồi. Thấy kỹ năng mềm của nó quá hợp với BA đi chứ. Kỹ năng cứng là thứ nó không tự tin, nhưng đó là những gì nó có thể làm để chuẩn bị cho một buổi phỏng vấn BA. ==> Mức độ tự tin khoảng 85%.
Note một ý nhỏ với anh em, kỹ năng cứng với anh em sinh viên mới ra trường thực ra cũng không cần yêu cầu quá nhiều. Quan trọng nhất vẫn là thái độ và kỹ năng mềm của mình thôi. Vì hai cái đó sinh viên hoàn toàn có được, từ rèn được.
Còn về kỹ năng cứng thì đa phần là ở mức độ tự tìm hiểu. Rồi cố gắng ứng dụng được nhiều nhất có thể khi đi thực tập mà thôi 🙂
Thời buổi giờ có quá nhiều resource cho anh em ngâm cứu. Từ free tới tính phí. Quan trọng là anh em có chịu bỏ thời gian ra học hay không thôi.
Rảnh rảnh cứ lên Udemy, Pluralsight hoặc chỉ cần Youtube là có nhiều clip hay để học rồi. Hoặc nếu máu hơn thì cứ để dành một ít vốn liếng đi học khóa học BA. Cũng hết sảy con bà bảy.
Mẹo nhỏ đọc nghe hú hồn chơi
Muốn chuẩn bị kiến thức về nghiệp vụ, chỉ cần đăng ký TRIAL các hệ thống rồi vào vọc là ô kê.
Cách đăng ký cũng dễ ẹc, chỉ cần đọc hướng dẫn là trong vòng 3 nốt nhạc, anh em đã có ngay một hệ thống, tha hồ vào vọc.
Có các hãng nổi tiếng sau anh em có thể chọn (bấm vào các link sau rồi làm theo hướng dẫn)
Nói vòng vòng nãy giờ túm cái váy lại, là anh em phải làm.
Làm những thứ liên quan đến công việc BA như mình nói ở trên.
Làm MC, quá good
Làm quản trò, quá good
Làm gia sư, quá good
Làm tình nguyện viên, quá good
Làm sales, quá good
Làm biếng, quá bad, cái này thì là quá bad.
Những cái “bad” khác mà anh em có thể dễ dàng nhận ra như: làm biếng, làm biếng, hoặc làm biếng. Tức là làm gì cũng tốt, miễn có làm là được, nhưng đừng làm biếng.
Nhưng bên cạnh cái làm biếng, còn một cái làm khác, cũng “bad” không kém.
Đó là làm không liên quan.
Ví dụ làm bồi bàn quán ăn, quán cà phê. Cũng tốt thôi, nhưng thật sự nó không liên quan lắm đến những thứ mình có nói ở trên. Anh em có thể có kỹ năng giao tiếp, kỹ năng xử lý tình huống. Nhưng bù lại công việc chỉ gói gọn chừng đó, không mở rộng ra được. Mà không mở rộng, thì sẽ không tự phát triển lên được. Làm dưới 3 tháng thì ô kê, trên 3 tháng thì nên cân nhắc.
Sẽ có anh em hỏi: “Làm part time ở tiệm photocopy ổn không anh?” Cái này thì mình lại nghĩ là quá good đi chứ. Như anh sếp của mình, thời đi học cũng từng làm partime ở tiệm photocopy.
Nói về Word thì ổng trùm lắm. Nhắm mắt vẫn dùng phím tắt múa như thường. Heading, căn lề, font chữ, size chữ, theme, paragraph các kiểu làm rẹc rẹc.
Hồi đó làm document, mình cứ đinh ninh là ổn, đưa qua ảnh review một cái thì thôi rồi, y như rằng phải làm lại… bản mới.
3. Túm cái váy
Phải thử rồi mới biết.
Đừng ngại chuyện không có kinh nghiệm. Giờ không chỉ BA, mà các ngành nghề khác cũng vậy, cũng không quá yêu cầu kinh nghiệm như trước nữa.
Mà dù có yêu cầu kinh nghiệm nhiều thì anh em cũng chả việc gì phải ngại. Như mình chia sẻ ở trên, có kinh nghiệm liên quan đến công việc BA thì cứ tự tin, mạnh dạn mà phỏng vấn.
Quay lại trường hợp của mình: mình bị rớt phỏng vấn BA là vì mình chưa thể hiện được mức độ phù hợp của mình với công việc. Mình chưa thật sự show cho họ thấy được: “à, tui đã hiểu, đã sẵn sàng làm cái này, cái kia, làm công việc của một BA thật sự”.
Đó là lý do mà mình, và nhiều anh em khác bị rớt phỏng vấn, do cả hai (cả người phỏng vấn và người được phỏng vấn) chưa tìm được nhu cầu của nhau.
Đừng nghĩ làm BA là một công việc gì đó cần kinh nghiệm ghê gớm. Cứ mạnh mẽ, tự tin mà apply, phải manh động lên.
Sẽ không ai nghĩ một con voi biết bơi, cho đến khi người ta thấy nó dưới nước.
Hãy cho nhà tuyển dụng thấy những gì bạn đã làm. Hãy thuyết phục công ty chọn bạn làm BA. Và họ sẽ không hối hận khi thấy những gì bạn làm.
…hoặc ngược lại ?
That’s all! Hẹn gặp anh em ở những bài sau. Có gì cần trao đổi, chém gió thêm thì anh em cứ comment bên dưới nhé.
Mình mới gắn nút like cho blog. Anh em nào thấy thích bài này thì cứ like mạnh tay nhé ? See yaaaa!!!
Bài viết được sự cho phép của tác giả Trần Nhật Trường
I. GIỚI THIỆU
Thay vì sử dụng Service Account keys, Workload Identity cho phép các workload xác thực bằng cách sử dụng danh tính của chúng mà không cần lưu trữ các khóa bí mật.
Workload Identity là một tính năng của Google Cloud cho phép bạn quản lý và cấp phát danh tính cho các workload (ứng dụng, dịch vụ) chạy trên Google Cloud hoặc trên các môi trường khác như Kubernetes hay các cloud khác. Workload Identity giúp giảm thiểu việc quản lý và sử dụng các khóa dịch vụ (Service Account keys), thay vào đó, nó sử dụng danh tính liên kết để ủy quyền và truy cập tài nguyên.
II. HƯỚNG DẪN
1. Cấu hình trên GCP
Để chuyển đổi Service Account (SA) key sang Workload Identity trên Google Cloud, bạn cần làm theo các bước sau:
Bước 1: Tạo một Workload Identity Pool
– Mở Google Cloud Console.
– Điều hướng tới “IAM & Admin” > “Workload Identity Federation”.
– Nhấp vào “Create Pool” và cung cấp các thông tin cần thiết như tên pool, ID, và mô tả.
Cập nhật ứng dụng của bạn để sử dụng chứng chỉ của provider thay vì sử dụng SA key.
Tùy thuộc vào ngôn ngữ lập trình và môi trường, cấu hình có thể khác nhau, ta sẽ cần cung cấp đường dẫn tới file cấu hình hoặc thiết lập các biến môi trường.
Bước 4: Cấu hình ứng dụng để sử dụng Workload Identity
Ví dụ 1: Sử dụng Google Cloud Storage trong Spring Boot:
Ta không cần thêm cấu hình đặc biệt nào trong ứng dụng Spring Boot vì thư viện Google Cloud Client Library sẽ tự động phát hiện các chứng chỉ từ môi trường khi chạy trên GKE với Workload Identity.
Lưu ý:
Đảm bảo rằng ta đã cài đặt và cấu hình gcloud, kubectl. Kiểm tra và thay thế tất cả các biến PROJECT_ID, SERVICE_ACCOUNT_NAME, K8S_NAMESPACE, KSA_NAME, POD_NAME, CONTAINER_NAME, IMAGE
Sử dụng thư viện trong ứng dụng Golang: Trong ví dụ này, storage.NewClient(ctx) tự động phát hiện các chứng chỉ từ môi trường của GKE, nhờ cấu hình Workload Identity.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
package main
import (
"context"
"log"
"cloud.google.com/go/storage"
)
func main() {
ctx := context.Background()
// Tạo client mới cho Google Cloud Storage
client, err := storage.NewClient(ctx)
if err != nil {
log.Fatalf("Failed to create client: %v", err)
}
// Sử dụng client để tương tác với Google Cloud Storage
Thay vì sử dụng option.WithCredentialsFile(“path/to/your/credentials/file.json”) (case sử dụng SA key), ta có thể cấu hình ứng dụng sử dụng chứng chỉ được tự động phát hiện từ môi trường khi chạy trên GKE với Workload Identity.
BONUS
Vậy với GCE (Compute engine) a.k.a VM thì có phương pháp nào không phải sử dụng SA key không? Câu trả lời là có.
Để một ứng dụng chạy trên VM của Google Cloud Platform (GCP) sử dụng service account của VM đó mà không cần sử dụng Service Account key (SA key), bạn có thể cấu hình VM để sử dụng Application Default Credentials (ADC). Đây là phương pháp được khuyến nghị vì nó đơn giản hơn và an toàn hơn so với việc quản lý và sử dụng SA key thủ công. Đọc thêm bài viết này để hiểu ADC hoạt động như nào https://cloud.google.com/docs/authentication/application-default-credentials.
Vậy ADC có thể apply cho cả GKE, vậy sao không dùng luôn ADC mà lại dùng Workload Identity? Lý do là:
– ADC thiếu Pod-level Identity: ADC không hỗ trợ việc ánh xạ danh tính tới mức pod. Tất cả các pod trên cùng một node sẽ chia sẻ cùng một service account, dẫn đến quyền truy cập rộng hơn và khó kiểm soát chi tiết.
– ADC không Hỗ trợ Kubernetes RBAC: ADC không tích hợp với hệ thống Role-based Access Control (RBAC) của Kubernetes, dẫn đến khó khăn trong việc quản lý và gán quyền truy cập chi tiết.
– Workload Identity có khả năng liên kết với các nhà cung cấp danh tính bên ngoài như AWS, Azure, hoặc hệ thống OIDC, giúp mở rộng khả năng xác thực và quản lý danh tính cho các workload đa đám mây. ADC không cung cấp khả năng này.
Trong lập trình Java việc hiểu rõ về các từ khóa như final, static, và static final là rất cần thiết. Ở bài viết trước ta đã tìm hiểu về static, trong bài viết này, chúng ta sẽ tiếp tục tìm hiểu chi tiết về ý nghĩa và cách sử dụng của từ khóa final trong Java.
Từ khóa final trong Java
Trong Java, từ khóa final được sử dụng để tạo ra các hằng số hoặc ngăn chặn sự thay đổi, kế thừa, hoặc ghi đè trong một số trường hợp cụ thể. Final có thể được áp dụng cho biến, phương thức, và lớp, và mỗi trường hợp sử dụng final đều có ý nghĩa riêng.
Các trường hợp sử dụng:
Biến final: khi một biến được khai báo với từ khoá final, nó chỉ chứa một giá trị duy nhất trong toàn bộ chương trình (hay dễ hiểu hơn gọi là biến hằng).
Phương thức final: khi một phương thức được khai báo với từ khoá final, các class con kế thừa sẽ không thể ghi đè (override) phương thức này.
Lớp final: khi từ khoá final sử dụng cho một lớp, lớp này sẽ không thể được kế thừa.
Biến static final trống: Một biến final mà không được khởi tạo tại thời điểm khai báo được gọi là biến final trống.
Từ khóa final có thể được áp dụng với các biến, một biến final mà không có giá trị nào được gọi là biến final trống hoặc biến final không được khởi tạo. Nó chỉ có thể được khởi tạo trong constructor. Biến final trống cũng có thể là static mà sẽ chỉ được khởi tạo trong khối static. Chúng ta sẽ tìm hiểu chi tiết về những điều này.
Khi một biến được khai báo với từ khóa final, giá trị của nó không thể thay đổi sau khi đã được khởi tạo. Nói cách khác, biến đó trở thành một hằng số.
Ví dụ: Trình biên dịch sẽ thông báo lỗi khi bạn cố ý thay đổi giá trị của biến này, bởi vì biến final một khi được gán giá trị thì không bao giờ thay đổi được.
Bạn sẽ nhận được thông báo lỗi khi cố tình thay đổi giá trị của biến final: The final field UsingFinalExample.WEBSITE cannot be assigned.
Ví dụ: Có thể thay đổi giá trị của thuộc tính của một object là final, nhưng bạn không thể khởi tạo lại object đó một lần nữa.
Phương thức final (Final method) trong Java
Khi một phương thức được khai báo là final, nó không thể bị ghi đè (override) trong các lớp con. Điều này đảm bảo rằng phương thức này không thể thay đổi hành vi bởi bất kỳ lớp nào kế thừa nó.
Ví dụ về không thể ghi đè phương thức final.
Bạn sẽ nhận được thông báo lỗi khi cố tình ghi đè phương thức final: Cannot override the final method from Parent.
Lớp final (Final class) trong Java
Khi một lớp được khai báo là final, lớp đó không thể bị kế thừa. Điều này có nghĩa là không thể tạo ra bất kỳ lớp con nào từ lớp final.
Ví dụ về không thể kế thừa lớp final.
Bạn sẽ nhận được thông báo lỗi khi cố tình kế thừa từ lớp final: The type Child cannot subclass the final class Parent.
Biến static final trống trong Java
Một biến static final mà không được khởi tạo tại thời điểm khai báo thì đó là biến static final trống. Nó chỉ có thể được khởi tạo trong khối static và một khi nó đã được khởi tạo thì không thể bị thay đổi.
Một số câu hỏi thường gặp khi đi phỏng vấn liên quan đến từ khóa final
Phương thức final có được kế thừa không?
Trả lời: Có, phương thức final được kế thừa nhưng bạn không thể ghi đè nó.
Biến final trống hoặc không được khởi tạo là gì?
Trả lời: Một biến final mà không được khởi tạo tại thời điểm khai báo được gọi là biến final trống. Biến được khởi tạo tại thời điểm tạo đối tượng và một khi nó đã được khởi tạo thì không thể bị thay đổi.
Ví dụ:
Bạn sẽ nhận được thông báo lỗi khi cố tình thay đổi giá trị của biến final: The final field WEBSITE may already have been assigned.
Tham số final là gì?
Nếu bạn khai báo bất cứ tham số nào là final, thì bạn không thể thay đổi giá trị của nó.
Bạn sẽ nhận được thông báo lỗi khi cố tình thay đổi giá trị của tham số final: The final local variable website cannot be assigned. It must be blank and not using a compound assignment.
Trên đây là những lý thuyết cơ bản về từ khóa final trong Java. Khi tham gia vào các dự án thực tế sẽ có nhiều trường hợp áp dụng khác nhau. Cám ơn các bạn đã theo dõi bài viết. Hẹn gặp lại ở bài viết tiếp theo.
Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh
Bản thân mình thời gian đầu dùng Use Case cũng gặp rất nhiều khó khăn. Một mớ bồng bông câu hỏi cứ lởn quởn trong đầu: bản chất của Use Case là gì, dùng cho mục đích nào, vẽ vậy đúng hay chưa, có chi tiết quá không, hoặc thậm chí vẽ Use Case xong cũng chẳng biết để làm gì???
Do đó bài này mình sẽ note về những thứ mình học được, làm được và dĩ nhiên quan trọng nhất là những sai lầm mà mình từng mắc phải khi làm Use Case.
Use Case là kỹ thuật dùng để mô tả sự tương tác giữa người dùng và hệ thống với nhau, trong một môi trường cụ thể và vì một mục đích cụ thể.
Sự tương tác ở đây có thể là:
Người dùng tương tác với hệ thống như thế nào?
Hoặc, hệ thống tương tác với các hệ thống khác như thế nào?
Và dĩ nhiên, sự tương tác này phải nằm trong một môi trường cụ thể, tức là nằm trong một bối cảnh, phạm vi chức năng cụ thể, hoặc rộng hơn là trong một hệ thống/ phần mềm cụ thể.
Sau cùng, việc mô tả sự tương tác này phải nhằm diễn đạt một mục đích cụ thể nào đó. Use Case phải diễn rả được Requirement theo góc nhìn cụ thể từ phía người dùng.
Ví dụ sơ đồ Use Case diễn tả sự tương tác giữa người dùng là độc giả với trang blog Thinhnotes chẳng hạn.
Ví dụ đơn giản về Use Case
Tương tác ở đây là gì?
Độc giả đọc bài notes
Độc giả yêu thích bài notes
Độc giả chia sẻ bài notes
Độc giả nhận xét bài notes
Độc giả gửi bài notes cho độc giả khác qua email
Môi trường cụ thể? Quá đơn giản, đó là trang blog Thinhnotes.com (không phải trang Admin).
Mục đích cụ thể?
Người dùng có thể đọc được bài notes trên blog (đơn giản bỏ qua)
Người dùng có thể bày tỏ được sự yêu thích bài notes
Người dùng có thể chia sẻ bài notes này trên các nền tảng khác để nhiều người khác có thể đọc được
Người dùng có thể viết nhận xét khen chê gạch đá các kiểu cho tác giả
Người dùng có thể gửi bài notes này qua email cho một người bất kỳ.
Đó là tất tần tật những nội dung mà một Use Case sẽ thể hiện.
Về hình thức thì Use Case tồn tại ở 2 dạng:
Hình vẽ Use Case (Use Case Diagram)
Đặc tả Use Case (Use Case Specification).
Ở bài sau mình sẽ nói Use Case Specification sau nhé anh em. Bài này mình sẽ tập trung nói về Use Case Diagram.
Use Case Diagram là một thành viên trong họ UML (Unified Modeling Language).
Use Case thuộc họ Behavior trong bộ UML
Mỗi Diagram trong bộ UML này đều có những mục đích khác nhau. Tùy trường hợp, tùy dự án mà anh em sẽ “rút hàng” ra chiến như thế nào cho hợp lý.
Hiểu sơ bộ Use Case là gì và mục đích của nó, chúng ta cùng tìm hiểu chi tiết Use Case Diagram và cách vẽ nhé anh em 😎
2. Các thành phần của Use Case Diagram
2.1. Actor, Use Case, Communication Link và Boundary
Cũng không có gì quá phức tạp, Use Case Diagram gồm 5 thành phần chính:
Actor
Use Case
Communication Link
Boundary of System
Và, Relationships.
Các thành phần có trong một Use Case Diagram
Actor thì có thể là Người dùng, hoặc một System nào đó. Vì UML quy định Actor là hình thằng người nên có thể anh em sẽ nhầm lẫn chỗ đó phải là người dùng nhưng hổng phải.
Một số câu hỏi anh em có thể tự lẩm bẩm trong đầu để xác định Actor như sau:
Ai là người sử dụng hệ thống?
Ai sẽ là người Admin của hệ thống (tức người cài đặt, quản lý, bảo trì… hệ thống)?
Hệ thống này có được sử dụng bởi bất kỳ một hệ thống nào khác không? (*)
Hệ thống lưu trữ dữ liệu, vậy ai là người input dữ liệu vào hệ thống?
Hệ thống lưu trữ dữ liệu, vậy ai là người cần những dữ liệu output?
Ở mục (*), mình muốn highlight cho anh em chỗ này. Không phải giải pháp/ phần mềm nào làm ra đều được sử dụng bởi con người. Có những phần mềm làm ra, để cho… phần mềm khác sử dụng.
Chẳng hạn như làm các services. Mình có một anh bạn làm BA, giải pháp mà ảnh cùng đồng bọn làm ra là 1 services không được dùng bởi con người, mà được dùng bởi một hệ thống khác để xác thực người dùng.
Ký hiệu của Actor chủ yếu là hình thằng người, nhưng để Diagram thêm phong phú, đa dạng thì anh em có thể sử dụng các hình dưới đây, miễn có ghi chú rõ ràng là được.
Các ký hiệu thể hiện Actor.
Còn Use Case là anh em sẽ thể hiện dưới dạng hình Oval, thể hiện sự tương tác giữa các Actor và hệ thống.
Communication Link thể hiện sự tương tác giữa Actor nào với System. Nối giữa Actor với Use Case.
Boundary of System là phạm vi mà Use Case xảy ra. Ví dụ trong hệ thống CRM, phạm vi có thể là từng cụm tính năng lớn như Quản lý khách hàng, Quản lý đơn hàng, hoặc cả một module lớn như Quản lý bán hàng.
…
Ô kê nãy giờ dễ ẹc, mấy cái này nhìn sơ qua là anh em biết ngay cái một.
Cái cuối cùng mới chính là cái mà mình tin là nhiều anh em vẫn còn rất dễ lộn, đó là Relationship.
Relationship gồm 3 loại: Include, Extend, và Generalization.
a) Include
Include nghĩa là mối quan hệ bắt buộc phải có giữa các Use Case với nhau.
Xét về nghĩa, Include nghĩa là bao gồm, tức nếu Use Case A có mối quan hệ include Use Case B, thì nghĩa là: Use Case A bao gồm Use Case B.Để Use Case A xảy ra, thì Use Case B phải đạt được.
Ví dụ về Include trong Use Case
Xét ví dụ trên, chúng ta có Use Case: Nhận xét bài notes. Use Case này include 2 Use Case khác là: Đăng nhập WordPress và Soạn thảo nhận xét.
Rõ ràng anh em thấy: để nhận xét được một bài viết, anh em cần phải đăng nhập vào 1 tài khoản nào đó, để blog nhận diện anh em là ai, tên gì, quê quán, giai gái ra sao.
Ví dụ ở blog mình là anh em sẽ cần đăng nhập vào tài khoản WordPress. Sau khi đăng nhập xong, anh em phải soạn thảo nhận xét, tức là gõ nhận xét, chỉnh sửa, xóa tới xóa lui. Sau khi viết xong nhận xét, anh em sẽ bấm nút Submit để hoàn thành chẳng hạn.
Chỉ khi nào xong 2 bước trên (đăng nhập và soạn thảo nhận xét), thì anh em mới có thể xong bước Nhận xét bài notes được.
Hay nói cách khác để Use Case: Nhận xét bài notes xảy ra, thì Use Case: Đăng nhập WordPress và Use Case: Soạn thảo nhận xét phải bắt buộc hoàn thành trước tiên.
Đó chính là mối quan hệ Include. Anh em xem tiếp 1 số ví dụ dưới cho dễ hình dung nhé.
Muốn rút được tiền thì đầu tiên khách hàng phải xác thực tài khoản đi cái đãMuốn đặt được xe thì phải hoàn thành được 3 bước này rồi hệ thống mới cho đặtHoặc khách hàng muốn đánh giá được chuyến đi thì trước đó họ phải đặt xe cái đãHoặc tương tự là Use Case thể hiện tính năng Theo dõi tiến độ giao hàng trên một trang e-Commerce bất kỳ
Một số điểm cần chú ý khi vẽ Include cho Use Case
Thực sự không có quy tắc nào rõ ràng cho việc khi nào cần tách Use Case ra thành các Use Case nhỏ và cho nó một mối quan hệ Include cả.
Việc tách hay không tách phụ thuộc duy nhất vào người vẽ. Và lý do lớn nhất để mối quan hệ Include ra đời là giúp cho các Use Case của chúng ta DỄ QUẢN LÝ hơn; làm cho Use Case Diagram trông có vẻ nguy hiểm hơn mà thôi 😎
Và anh em chỉ nên tách Use Case khi nó có độ phức tạp lớn và những thứ tách ra được có thể được tận dụng ở các Use Case sau này.
Độ phức tạp lớn thì khi tách ra mình mới có được những Use Case vừa phải, đủ để diễn đạt dễ hiểu cho các stakeholders. Còn tận dụng được ở các Use Case sau là sao?
Sử dụng Include như thế nào cho hợp lý?
Ví dụ Use Case A gồm 2 Use Case nhỏ bên trong là X và Y. Do đó Use Case A được tách thành Use Case X và Use Case Y.
Tương tự, Use Case B gồm Use Case Y bên trong, nên được tách thành Use Case Y.
Nhưng, Use Case C gồm Use Case X và Use Case Z bên trong, nhưng chỉ có Use Case X là được tách ra cho mối quan hệ Include. Vì có thể Use Case Z “không đáng” để tách ra thành một Use Case nhỏ hơn.
Chúng ta tách Use Case X từ Use Case A để Use Case C có thể tận dụng được mà không cần vẽ lại. Tương tự, tách Use Cas Y từ Use Case B để Use Case A có thể tận dụng mà cũng không cần vẽ lại.
Điều này giúp Use Case Diagram của chúng ta trở nên chặt chẽ, logic và gọn nhẹ hơn rất nhiều.
Còn Use Case Z, vì nó không được “dùng lại” ở một Use Case bất kỳ nào sau đó, nên người vẽ có thể cân nhắc có tách nó ra hay không!
Nếu Use Case đó đủ lớn và khá là high-level, thì có lẽ chúng ta nên tách. Còn nếu ngược lại, Use Case đã rõ ràng, là một requirement từ phía User cụ thể thì không đáng để anh em tách nó ra thành một Use Case nhỏ, chỉ làm hình thêm thêm rối mà thôi.
Khi tách Use Case ra thành các Use Case nhỏ để tận dụng mối quan hệ Include, anh em hãy nhớ 2 thứ: độ lớn của Use Case và khả năng tái sử dụng lại của nó
Còn cách vẽ thì anh em cứ nhớ là include tới thằng nào thì dấu mũi tên hướng tới thằng đó nhé anh em. Nhớ để qua phần Extend cho khỏi lộn.
b) Extend
Extend là mối quan hệ mở rộng giữa các Use Case với nhau.
Nếu Include là mối quan hệ bắt buộc, thì Extend là một mối quan hệ không bắt buộc. Nó thể hiện mối quan hệ có thể có hoặc có thể không giữa các Use Case với nhau.
Một Use Case B là extend của Use Case A thì có nghĩa Use Case B chỉ là một thứ optional, và chỉ xảy ra trong một hoàn cảnh cụ thể nào đó.
Lấy ví dụ Grab phía trên, anh em sẽ dễ dàng có được một mối quan hệ Extend như sau.
Ví dụ về mối quan hệ Extend giữa các Use Case
Trong trường hợp này, Use Case: Gửi tiền tip cho lái xe là một Use Case có mối quan hệ Extend với Use Case: Đánh giá chuyến đi. Tức, Use Case: Gửi tiền tip cho lái xe chỉ là một Use Case có thể xảy ra, hoặc không; và nó liên quan đếnUse Case: Đánh giá chuyến đi, chứ không phải bất kỳ một Use Case nào khác.
À…à…Nhắc tới lúc có lúc không, tức là nhắc tới điều kiện xảy ra.
Anh em có thể thể hiện rõ ý chỗ này bằng một thứ luôn đi kèm với Extend, đó là Extension Point 😎
Extension Point nôm na là điều kiện mà Use Case có mối quan hệ Extend sẽ xảy ra. Còn để sát nghĩa thì anh em có thể hiểu chữ Point ở đây nghĩa là điểm dữ liệu thể hiện sự khác biệt.
Tức nếu dữ liệu này là A thì Use Case không xảy ra, nhưng nếu dữ liệu này là B thì Use Case sẽ xảy ra.
//Theo mình nhớ là hình như anh em chỉ có thể gửi tiền tip cho tài xế, nếu cuốc xe đó anh em chấm họ maximum là 5 sao.//
Vậy thì anh em sẽ vẽ Use Case Diagram chỗ đó như sau.
Use Case Diagram có thể hiện rõ khi nào thì mối quan hệ Extend diễn ra
Extension Point ở đây là dữ liệu Driver Rating. Nếu Driver Rating đạt giá trị 5 sao, thì Use Case: Gửi tiền tip cho lái xe sẽ xảy ra, và hoàn toàn optional, tùy thuộc vào khách hàng.
Và nó liên quan mật thiết đến Use Case: Đánh giá chuyến đi, là một phần mở rộng của Use Case: Đánh giá chuyến đi.
Extension Point không nhất thiết phải là một dữ liệu nào đó trên hệ thống, mà có thể là một “điều kiện” bất kỳ, miễn là nó thể hiện được trường hợp cụ thể mà Use Case sẽ xảy ra.
Ở một ví dụ khác.
Mối quan hệ Extend trong Use Case Diagram của A kia rồi chấm côm
Còn nếu Use Case có quá nhiều mối quan hệ Extend, làm cho Diagram nhìn rối bời quá, anh em có thể bỏ luôn phần comment của Extension Point luôn cũng được.
Vẽ vầy cũng hông sao
c) Generalization
Generalization đơn giản là quan hệ cha con giữa các Use Case với nhau. Nhưng khác biệt với Include và Extend là nó còn được dùng để thể hiện mối quan hệ giữa các… Actor với nhau.
Đầu tiên là mối quan hệ cha-con giữa các Use Case. Ví dụ:
Đăng nhập thì có thể đăng nhập qua số điện thoại, hoặc đăng nhập qua email.
Đặt hàng thì có đặt hàng qua điện thoại, hoặc đặt hàng qua website.
Thanh toán thì thanh toán qua thẻ ATM, qua thẻ thanh toán quốc tế, hoặc qua ví điện tử.
Hoặc tìm kiếm thì có thể tìm kiếm bằng từ khóa, hoặc tìm kiếm theo nhóm sản phẩm.
Hoặc mối quan hệ cha-con giữa các Actor. Ví dụ:
Khách hàng gồm khách hàng cũ và khách hàng mới
Hoặc Vendor thì có thể gồm Retailers và Wholesalers.
Ví dụ về quan hệ cha-con (Generalization) trong Use Case
Nhìn chung, Generalization giúp anh em thể hiện rõ hơn các yêu cầu bằng việc gom nhóm các Use Case lại theo quan hệ cha-con. Cá nhân mình thì rất ít khi vẽ relationship này, chủ yếu chỉ dùng Include và Extend là chính.
Còn một điểm nữa là Generalization có tính kế thừa. Tức thằng cha có gì thì thằng con có cái đó, kể cả Use Case hay Actor.
Ví dụ Use Case A có include đến Use Case B và C. Thì Use Case A’ là con của Use Case A cũng sẽ có mối quan hệ Include đến Use Case B và C, mặc dù không được thể hiện trên hình.
…
Ô kê, vậy là xong phần Relationship – một trong những phần chuối nhất, dễ lộn nhất trong Use Case. Hi vọng những ví dụ trên giúp anh em hiểu được cụ thể như thế nào là Include, Extend và Generalization trong một Use Case Diagram 😎
3. Một số sai lầm phổ biến khi vẽ Use Case
Use Case Diagram là thứ để anh thể hiện được requirement của khách hàng.
Vẽ sao mà khách hàng nhìn vô một phát là thấy khoái liền. Khách hàng mà chân nhịp nhịp, miệng lẩm bẩm: “Đúng rồi…đúng rồi…, tính năng này có,… tính năng kia có luôn, à… tích hợp lấy dữ liệu này có, ô kê ô kê,… vầy là đủ rồi!”, thì coi như anh em đã vẽ khá good 🙂
Chém nãy giờ mạnh vậy chứ mình vẽ chẳng bao giờ là ổn cả. PM cứ phải duyệt đi duyệt lại cả chục lần. Nhờ đó mới có những sai lầm phổ biến mà mình hay gặp khi vẽ Use Case Diagram cho anh em tham khảo dưới đây, hehe.
3.1. Chuyện đặt tên
Trong mô hình hóa, chuyện đặt tên là rất-rất-rất quan trọng.
Vì đã nói “mô-hình-hóa” tức là chúng ta dùng hình ảnh để nói chuyện, thì khi đó hàm lượng chữ chiếm rất ít. Và chính vì nó ít, nên những gì chúng ta ghi trên diagram phải rất súc tích, cô đọng và có giá trị ngay tức thì.
Chỉ cần người đọc họ nhìn vô diagram mà thấy ngay 1 dòng chữ khó hiểu, thì ngay lập tức tụt bà nó hết mood, hết muốn xem tiếp rồi.
Nói về Use Case thì có 1 vài lưu ý sau cho anh em:
Actor thì phải đặt tên bằng danh từ, không dùng động từ, và cũng không mệnh đề quan hệ gì hết.
Tên Use Case thì phải ghi rõ ràng, rành mạch, đẹp nhất là dưới format: Verb + Noun.
Ví dụ: Đổi điểm thành viên, Chuyển tiền nội địa, Chuyển tiền quốc tế, Duyệt nhận xét bài viết.
BA chúng ta vẽ Use Case nhằm mục đích diễn tả yêu cầu cho stakeholders hiểu, do đó anh em không được dùng những từ kỹ thuật trong đây, không thể hiện sự nguy hiểm ở đây, người ta đọc zô hông hiểu gì hết là trớt quớt.
Và đặc biệt là tránh đặt tên quá dài và không nên dùng kiểu bị động.
Ví dụ về quan hệ cha-con (Generalization) trong Use Case
3.2. Vẽ Use Case mà thành phân rã chức năng
Đây chính xác là lỗi mà mình hay gặp nhất, rất thường xuyên gặp khi vẽ Use Case.
Sai lầm 2: không phân biệt được phân rã chức năng và Use Case
Dấu hiệu nhận biết rõ ràng nhất là khi Use Case Diagram của anh em đầy rẫy chữ “manage”, manage cái này, manage cái kia…
Đầu tiên là chữ Manage rất rộng nghĩa. Yêu cầu quản lý A gồm 5 việc, thì không có nghĩa yêu cầu quản lý B cũng gồm 5 việc. Use Case là diagram thể hiện yêu cầu của End-Users, nhằm đạt được một mục đích nào đó.
Ở ví dụ trên, nếu nói Manage Gears, Manage Brakes, hay Manage Air Conditioner thì quá tối nghĩa, chả ai hiểu nhằm mục đích sau cùng là để làm gì.
Thứ hai, hình minh họa trên vẽ Use Case nhưng lại chưa mang được góc nhìn của End-Users, tức chưa cho thấy được End-Users muốn đạt được gì sau ngần ấy Use Case được liệt kê ra.
Nguyên nhân có thể do người vẽ chưa nắm đủ thông tin về yêu cầu của End-Users, ảnh chưa hiểu rõ rốt cuộc thì người dùng họ muốn làm gì trên hệ thống, hay hệ thống phải tương tác những gì với hệ thống khác.
Từ đó mới có chuyện anh em nhìn vô Use Case Diagram ở trên mà cảm thấy mông lung như một trò đùa. Do đó, chúng ta chỉ vẽ Use Case khi đã có đủ thông tin cần thiết:
End-users muốn làm gì? Nhằm mục đích gì? ==> tương tác giữa end-users và hệ thống
Hệ thống phải nhận/ lấy data từ những nguồn nào? ==> tương tác giữa hệ thống với những hệ thống bên ngoài khác.
Ngoài ra, khi đã có đủ thông tin nhưng Use Case mình vẽ vẫn bị confuse. Lý do có thể do các Use Case mình vẽ bị lệch các cấp độ Requirement với nhau.
Ví dụ Use Case A thì thể hiện Business Requirement, tức là rất high level. Nhưng sang Use Case B và C thì lại nói rất detail tới mức Solution Requirement như.
3 Use Case này bị lệch cấp độ với nhau, gây “rối bời” cho người xem
Để sửa lại Use Case trên, đơn giản mình chỉ cần bỏ Use Case A: Quản lý học viên ra, vì nó là thứ rất chung chung, không thể hiện được mục đích cụ thể, so với 2 Use Case còn lại.
Tuy nhiên, chữ “Manage” trong Use Case lại rất công dụng, công dụng đến mức không thể không dùng trong các document mình làm, nó sẽ giúp mình giải quyết vấn đề ở mục số 3.4 phía dưới, đọc tiếp nhé anh em.
3.3. Rối nùi Use Case
Anh em tham khảo một số hình sau sẽ rõ.
Sai lầm 3: Rối nùi Use Case
Vấn đề của hình này là ôm đồm quá nhiều. Dẫn đến quá nhiều Use Case xuất hiện trong cùng một Diagram, đã vậy cũng không có Boundary of System rõ ràng.
Như anh em thấy, Use Case này vẽ rất sai ở những điểm như sau:
Xác định sai Use Case (nên mới nhiều UC như vậy): những thứ như single, double, num of guest… rõ ràng đâu phải là một Use Case, đâu phải là một sự tương tác.
Đặt tên Use Case sai: quá nhiều cụm danh từ cho Use Case.
Không có Boundary of System.
Những Use Case có extend không ghi chú cụ thể điều kiện khi nào thì UC extend xảy ra.
Một note nhỏ quan trọng cho anh em, Use Case Diagram sạch đẹp là chỉ nên có trên dưới 10 Use Case trong đó. Các Use Case còn lại anh em hãy dùng Boundary of System để phân chia theo phân hệ một cách hợp lý nhất có thể.
Hình này rõ ràng là quá thứ dữ. Thật ra trường hợp này cũng khá phổ biến, mình trước kia bị hoài. Mấu chốt đến từ một số điều sau:
Một số Use Case đặt tên sai
Chưa tận dụng các Relationship để thể hiện, khiến cho các Use Case quá rời rạc nhau, và trông rất không hợp logic.
Người vẽ không dùng Boundary of System để phân nhóm, giới hạn các Use Case.
Và đặc biệt, người vẽ quá chú trọng đến các chức năng cơ bản nhất, đó là: CRUD – Create/Read/Update/Delete.
3.4. Quá chi tiết các chức năng CRUD
Như ví dụ trên, mỗi thực thể là một lần CRUD. Như vậy quá tốn effort, trong khi 96,69% là ở phân hệ nào, hay dữ liệu nào, anh em cũng đều cần phải CRUD dữ liệu hết.
Điều này tạo ra một sự lặp đi lặp lại ở các Use Case Diagram, nhưng không thể hiện được gì nhiều cho người xem. Để giải quyết vấn đề này, anh em có thể có làm 1 trong 2 cách sau.
Cách 1
Thêm một dòng note trước đoạn mô tả Use Case trong tài liệu: “Toàn bộ dữ liệu đều có chức năng Thêm/ Đọc/ Sửa/ Xóa và chịu tác động bởi sự phân quyền từ phía Quản trị hệ thống” hoặc đại loại vậy. Để cho các stakeholder biết được rằng hệ thống có chức năng CRUD các dữ liệu này.
Nhưng nên nhớ CRUD ở đây là đứng từ góc nhìn End-Users: hệ thống có cho phép End-Users CRUD dữ liệu hay không?
Ví dụ hệ thống CRM lấy dữ liệu khuyến mãi từ hệ thống ERP. Thì về bản chất CRM phải có khả năng Create dữ liệu khuyến mãi, thì mới lấy dữ liệu khuyến mãi từ ERP về được.
Nhưng theo góc nhìn của End-Users, thì không một người dùng nào (kể cả System Admin) có thể tạo thủ công dữ liệu khuyến mãi trên CRM, mà End-Users họ chỉ Đọc/ Sửa/ Xóa dữ liệu được lấy về này thôi.
Do đó ở đây anh em cần mô tả rõ là có phải tất cả dữ liệu đều cho phép End-Users CRUD được hay không (không tính phân quyền).
Cách 2
Tạo hẳn một Use Case với tên là: Manage “X”, với X là một đối tượng bất kỳ.
Thay vì vẽ như bên trái, thì hãy vẽ như bên phải
Nếu không đầy đủ 4 tính năng CRUD, thì anh em có thể làm 1 cái note nhỏ bên trên, nói rõ Manage là có những tính năng gì, không có những tính năng gì.
3.5. Thẩm mỹ
Cuối cùng vẫn quay về vấn đề thẩm mỹ. Nguyên nhân việc Use Case mất thẩm mỹ đến từ 2 lý do:
Mắt thẩm mỹ kém: chiếm 0,00000000000069%
Ẩu, cẩu thả: chiếm 99,00000000000000069%
Làm gì cũng vậy, đặc biệt là mô hình hóa để làm document. Ẩu là thứ mình nên cố gắng hạn chế nó nhất. Vì làm đúng 1 lần, đẹp 1 lần, sau này đỡ mắc công làm lại chứ hông có gì hết.
Một số điểm anh em cần chú ý sau:
Kích cỡ các Use Case trong Diagram là phải như nhau, kể cả cha-con, lẫn các mối quan hệ Include. Tuy nhiên, Use Case có Extend sẽ được vẽ to hơn một chút.
Nhớ phải đánh dấu Use Case ID trong hình vẽ.
Các mối quan hệ không được chồng chéo lẫn nhau. Anh em có thể vẽ 1 Actor ở 2 vị trí khác nhau để tránh các đường nối bắt chéo lên nhau.
Khi vẽ Use Case Diagram, tập trung vào câu hỏi What để tìm ra Use Case, tránh câu hỏi How, vì khi đó anh em rất dễ đi vào detail.
Và nếu được, hãy tô màu lên Use Case để nhìn Diagram được rõ ràng, sáng sủa và mạch lạc 🙂
Hi vọng qua bài này anh em đã hiểu rõ bản chất của Use Case, và biết cách vẽ Use Case Diagram. À mà không những biết cách vẽ, mà còn vẽ đúng, vẽ đẹp và tránh được những lỗi sai thường gặp nữa.
Bài sau mình sẽ note lại cách viết Use Case Specification sau cho nhanh gọn và đơn giản nhất. Nếu có gì thắc mắc cứ thả còm men bên dưới hoặc email cho mình nhé.
Nếu bạn là một lập trình viên thích viết clean code, cố gắng viết code một cách ngắn gọn nhất có thể thì việc tối ưu hóa các khối lệnh điều kiện là điều cơ bản quan trọng trong JavaScript. Bằng cách thay đổi điều kiện check, bạn có thể giản lược rất nhiều đoạn code của mình cũng như giúp source code của bạn trở nên rõ ràng hơn. Bài viết dưới đây, mình sẽ chia sẻ một vài kinh nghiệm nhỏ giúp bạn cấu trúc lại những đoạn câu lệnh if/ else trong JavaScript một cách hiệu quả nhé.
Không nên sử dụng các điều kiện phủ định
Bạn không nên sử dụng điều kiện phủ định (giá trị false) cho các câu lệnh if của mình; điều này đơn giản giúp cho việc đọc lại source code của bạn sẽ trở nên tự nhiên hơn. Thêm vào đó, với các biến boolean, không cần thiết phải viết điều kiện check với giá trị true/ false, sử dụng toán tử phủ định sẽ giúp ngắn gọn cho dòng code của bạn.
Không nên viết code thế này:
constisEmailNotVerified= (email) => {// implementation}if (!isEmailNotVerified(email)) {// do something...}if (isVerified===true) {// do something...}
Mà hãy chuyển sang cách viết như dưới đây:
constisEmailVerified= (email) => {// implementation};if (isEmailVerified(email)) {// do something...}if (isVerified) {// do something...}
Hãy sử dụng Array.includes để gộp nhiều điều kiện
Giả sử chúng ta muốn kiểm tra xem mẫu xe đầu vào là renault hay peugeot, điều kiện if có thể xử lý đơn giản như sau:
Trong trường hợp nếu chúng ta cần check trong 1 tập hợp nhiều mẫu xe khác nhau, lúc này cách viết trên sẽ khiến code của bạn trở nên dài và cồng kềnh hơn. Để giải quyết vấn đề này, chúng ta sử dụng Array.includes để kiểm tra xem trong mảng đầu vào có giá trị cần tìm hay không.
Tinh chỉnh thêm đoạn code một chút nữa, ta có thể tách biệt phần khai báo dữ liệu và phần xử lý logic (kiểm tra điều kiện), code sẽ trở nên sáng sủa hơn rất nhiều.
Hãy sử dụng Array.every hoặc Array.find để bắt điều kiện khớp tất cả tiêu chí
Ở ví dụ dưới đây, chúng ta cần kiểm tra xem danh sách các xe đầu vào (cars) có đều thuộc về cùng một hãng xe (model) được nhập vào hay không. Để thực hiện việc kiểm tra, đoạn code dưới đây sử dụng một vòng lặp for để duyệt qua tất cả các phần tử trong mảng; biến isValid được dùng làm biến để trả về giá trị cho hàm check.
Để viết code một cách gọn gàng hơn, chúng ta có thể sử dụng phương every có sẵn trong lớp Array. Hàm này trả về true nếu như tất cả các phần tử trong mảng đều thỏa mãn điều kiện truyền vào.
Bạn cũng có thể sử dụng phương thức find để kiểm tra xem có tồn tại phần tử nào mà giá trị model không giống với giá trị đầu vào hay không. Kết quả trả về có ý nghĩa tương tự.
Về mặt hiệu năng, cả 3 cách trên đều cho kết quả như nhau vì cả hai hàm every và find đều thực hiện vòng lặp gọi từng phần tử của mảng, cũng đều trả về false ngay lập tức nếu tìm thấy giá trị điều kiện sai.
Sử dụng Array.some để check điều kiện tồn tại
Tương tự như cách sử dụng Array.every, chúng ta có thể sử dụng Array.some cho việc kiểm tra xem có tồn tại phần tử nào trong mảng thỏa mãn điều kiện truyền vào hay không. Ví dụ dưới đây kiểm tra xem có mẫu xe “renault” (giá trị đầu vào) nào trong danh sách xe (cars) ban đầu hay không.
Nhiều bạn có thói quen khi viết một function sẽ tạo biến giữ giá trị trả về của hàm, sau đó lần lượt qua các câu lệnh if khác nhau, biến đó sẽ được thay đổi, gán giá trị và cuối cùng trả về qua câu lệnh return ở cuối hàm.
constcheckModel= (car) => {letresult; // first, we need to define a result value// check if car existsif (car) {// check if car model existsif (car.model) {// check if car year existsif (car.year) {result=`Car model: ${car.model}; Manufacturing year: ${car.year};`; } else {result="No car year"; } } else {result="No car model"; } } else {result="No car"; }returnresult; // our single return statement};console.log(checkModel()); // outputs 'No car'console.log(checkModel({ year:1988 })); // outputs 'No car model'console.log(checkModel({ model:"ford" })); // outputs 'No car year'console.log(checkModel({ model:"ford", year:1988 })); // outputs 'Car model: ford; Manufacturing year: 1988;'
Bạn có thể thấy rằng cách viết trên khiến đoạn code của chúng ta trở nên rất dài và khó đọc. Các điều kiện if lồng nhau khiến việc debug luồng chạy của chương trình trở nên khó khăn hơn. Để giải quyết vấn đề này, bạn nên dùng kết hợp việc return sớm theo từng điều kiện, kết hợp sử dụng toán tử ba ngôi (if/ else rút gọn) để giúp code của bạn clear hơn.
constcheckModel= ({ model, year } = {}) => {if (!model&&!year) return"No car";if (!model) return"No car model";if (!year) return"No car year";// here we are free to do whatever we want with the model or year// we made sure that they exist// no more checks required// doSomething(model);// doSomethingElse(year);return`Car model: ${model}; Manufacturing year: ${year};`;};console.log(checkModel()); // outputs 'No car'console.log(checkModel({ year:1988 })); // outputs 'No car model'console.log(checkModel({ model:"ford" })); // outputs 'No car year'console.log(checkModel({ model:"ford", year:1988 })); // outputs 'Car model: ford; Manufacturing year: 1988;'
Sử dụng Indexing hoặc Maps thay thế cho câu lệnh Switch
Ví dụ dưới đây, hàm getCarsByState trả về các hãng xe theo giá trị quốc gia truyền vào, trong đó giá trị trả về dưới dạng một mảng các tên hãng xe. Sử dụng cấu trúc switch là một cách giải quyết tự nhiên cho bài toán này.
Vấn đề vẫn là bài toán khi dữ liệu tăng lên và logic code của bạn sẽ không tách biệt khỏi phần khai báo dữ liệu. Hãy sử dụng Indexing hoặc Map để tái cấu trúc đoạn code trên, các bạn sẽ được đoạn code như dưới đây:
Dễ thấy sự thay đổi trong 2 đoạn code dưới so với sử dụng khối switch/ case; vừa ngắn gọn hơn và tách biệt được khai báo dữ liệu ra khỏi logic code. Bạn sẽ dễ dàng bổ sung phần dữ liệu vào chương trình mà không làm thay đổi nội dung hàm.
Kết bài
Hy vọng bài viết này mang lại những kinh nghiệm hữu ích dành cho bạn trong việc xử lý các khối lệnh điều kiện trong JavaScript. Việc tận dụng được đặc trưng, các phương thức có sẵn của ngôn ngữ lập trình sẽ giúp bạn tối ưu hóa được source code mà bạn viết ra. Cảm ơn các bạn đã đọc bài và hẹn gặp lại trong các bài viết tiếp theo của mình.
Dart là một ngôn ngữ lập trình mới, được phát triển bởi Google dành cho việc phát triển các ứng dụng đa nền tảng. Dart thường được gắn liền với Flutter framework, một lựa chọn cho việc xây dựng mobile app. Tuy nhiên, Dart không chỉ dùng cho việc xây dựng ứng dụng di động, ngôn ngữ này còn được áp dụng cho nhiều dự án phát triển phần mềm đa lĩnh vực khác. Bài viết hôm nay chúng ta cùng nhau tìm hiểu Dart là gì và ứng dụng của ngôn ngữ lập trình Dart trong thực tế nhé.
Dart là gì?
Dart là một ngôn ngữ lập trình mã nguồn mở được Google phát triển và ra mắt lần đầu tiên vào năm 2011. Dart có cú pháp viết mã đặc trưng kiểu C nên dễ học, dễ đọc và dễ viết nhất là với những bạn đã có kinh nghiệm với lập trình C hay Java trước đó thì việc tiếp cận Dart sẽ nhanh hơn. Google phát triển Dart dành cho sự phát triển ứng dụng đa nền tảng bao gồm ứng dụng Web, di động, máy chủ và cả máy tính để bàn.
Trải qua hơn 10 năm phát triển, hiện nay phiên bản mới nhất của Dart là version 3.5.2 trên stable channel ra mắt vào 28/8/2024. Qua từng phiên bản cập nhật lớn, Dart đã có sự thay đổi khá nhiều so với định hướng của ngôn ngữ này từ ban đầu, có thể kể đến các cột mốc cập nhật lớn như:
Version 1.0: phát hành tháng 11/2013 với các công cụ hỗ trợ mạnh mẽ như trình biên dịch Dart-to-JavaScript, Dart Virtual Machine và Dart Editor. Mục tiêu ban đầu của Dart là thay thế JavaScript như một ngôn ngữ lập trình Web.
Version 2.0: công bố vào năm 2017, Dart chuyển hướng tập trung vào việc phát triển ứng dụng di động. Cùng với sự ra mắt của bộ công cụ phát triển ứng dụng di động Flutter của Google, Dart (ngôn ngữ chính của Flutter) giúp chúng ta phát triển ứng dụng cross-platform cho cả Android và iOS.
Version 3.0: ra mắt vào năm 2023, Dart có sự bổ sung nhiều tính năng mới quan trọng như Patterns, Records và Class modifiers tập trung nâng cao khả năng kiểm soát chương trình của ngôn ngữ này.
Tính năng của ngôn ngữ Dart
Dart là một ngôn ngữ mới, được sự đầu tư phát triển bởi đội ngũ từ Google nên có nhiều tính năng của một ngôn ngữ lập trình hiện đại. Chúng ta cùng điểm qua một số tính năng nổi bật của ngôn ngữ lập trình Dart nhé:
Object-Oriented
Dart là một ngôn ngữ lập trình hướng đối tượng (OOP) thuần túy với mọi giá trị là một đối tượng, nó hỗ trợ đầy đủ các đặc điểm của OOP như class-based, tính kế thừa, tính đa hình. Lập trình hướng đối tượng giúp chúng ta tổ chức mã nguồn một cách rõ ràng và dễ quản lý cũng như có khả năng tái sử dụng mã một cách hiệu quả. Bạn cũng sẽ thấy quen thuộc khi viết code vì các khái niệm trong Dart sẽ giống đến 80% như trong Java – một ngôn ngữ lập trình hướng đối tượng phổ biến.
Strong Typing
Ngôn ngữ Dart là một ngôn ngữ strongly typed, nghĩa là nó đảm bảo rằng kiểu của một object không bị thay đổi đột ngột trong chương trình. Dart có các quy tắc và những hạn chế để đảm bảo rằng giá trị của một biến luôn khớp với static type của biến đó.
Garbage Collection
Dart có 1 bộ gom rác tương tự như Java; Garbage Collection trong Dart là chương trình chạy nền, theo dõi toàn bộ trạng thái hoạt động của các Object, tìm ra những Object không được dùng đến và xóa nó đi. Điều này giúp tối ưu khả năng sử dụng bộ nhớ của thiết bị với các ứng dụng viết bằng Dart.
JIT & AOT Compilation
Dart hỗ trợ cả hai phương pháp biên dịch là Ahead-Of-Time (AOT) và Just-In-Time (JIT) giúp tối ưu hóa quy trình phát triển ứng dụng. AOT cho phép biên dịch mã nguồn thành mã máy gốc trước khi ứng dụng được khởi chạy, giúp cải thiện tốc độ và hiệu suất của ứng dụng. JIT là kỹ thuật biên dịch thời gian thực, nó cho phép hot reloading nhờ biên dịch ngay sau khi code được lưu; từ đó tăng tốc độ viết code của lập trình viên.
Asynchronous Programming
Lập trình bất đồng bộ (Asynchronous) giúp bạn thực hiện các action (hành động) trong cùng một lúc mà không cần theo tuần tự; ví dụ như các hành động lấy dữ liệu từ phía Backend thông qua API. Ngôn ngữ Dart hỗ trợ lập trình bất đồng bộ thông qua lớp Future (giống với Promise trong JavaScript) hay sử dụng async/ await tương tự trong nhiều ngôn ngữ lập trình khác.
Nhắc đến ứng dụng của Dart thì điều đầu tiên chúng ta phải nhắc đến công cụ Flutter – một framework dành cho việc phát triển ứng dụng di động đa nền tảng (Android và iOS) sử dụng Dart làm ngôn ngữ lập trình. Ngoài Flutter ra, Dart còn được Google sử dụng làm ngôn ngữ cho nhiều lĩnh vực phát triển khác nhau bao gồm cả Web, Server side và các ứng dụng desktop.
Xây dựng ứng dụng di động
Xây dựng ứng dụng di động bằng Flutter framework là ứng dụng phổ biến và nổi bật nhất của ngôn ngữ lập trình Dart. Flutter cho phép lập trình viên viết code một lần bằng ngôn ngữ Dart và build ứng dụng ra để chạy được trên cả nền tảng Android lẫn iOS. Điều này giúp tiết kiệm thời gian, chi phí cũng như tăng tính đồng nhất giữa các ứng dụng khi phát triển bằng Flutter.
Xây dựng ứng dụng Web
Ngôn ngữ Dart ban đầu được thiết kế nhằm mục đích thay thế cho JavaScript trong phát triển Web. Trải qua những lần cập nhật lên phiên bản mới, ý định này đã không còn là hướng đi chính của đội ngũ phát triển Dart. Mặc dù vậy, với bộ công cụ như DartPad hay các thư viện như AngularDart (nếu bạn chưa biết thì Angular cũng là một sản phẩm của Google) thì Dart hoàn toàn có khả năng xây dựng các ứng dụng Web tương tác với người dùng một cách hiệu quả. Ngoài ra, bạn cũng có thể sử dụng Dart để biên dịch thành JavaScript để tái sử dụng source code một cách hữu ích.
Xây dựng ứng dụng server-side
Google cung cấp sẵn cho chúng ta thư viện dart:io cùng các gói mở rộng Aqueduct trong Dart giúp ngôn ngữ này có khả năng xây dựng các ứng dụng service-side một cách hiệu quả. Aqueduct là một framework HTTP mở rộng dùng để xây dựng các REST API trên Dart VM (máy ảo Dart), trong đó tích hợp sẵn một ORM (Object-Relational Mapping – ánh xạ đến CSDL) kiểu tĩnh. Sử dụng Dart cho ứng dụng server-side có thể giúp bạn tận dụng được một số ưu điểm về hiệu năng của ngôn ngữ này.
Framework Flutter không chỉ cho phép bạn build ứng dụng ra các nền tảng mobile mà còn có thể build ra ứng dụng dành cho Desktop. Flutter for Desktop cho phép lập trình viên xây dựng ứng dụng chạy được trên nền tảng Windows, macOS và Linux từ cùng một source code ban đầu viết bằng Dart.
Xây dựng công cụ dòng lệnh
Dart còn được nhiều nhà phát triển sử dụng để tạo ra các công cụ hoặc tiện ích dòng lệnh (CLI – Command Line Interface) giúp tự động hóa các tác vụ liên quan đến quản lý dự án hay các công việc khác một cách hiệu quả. Khi bạn đã quen với Dart thì việc sử dụng ngôn ngữ này cho nhiều mục đích khác nhau sẽ dễ dàng hơn so với việc dùng một ngôn ngữ hoàn toàn độc lập.
Kết bài
Dart là một ngôn ngữ lập trình mạnh mẽ và đa năng, với sự hậu thuẫn của team phát triển đến từ Google, hứa hẹn tương lai tươi sáng cho cho ngôn ngữ lập trình này. Vì thế nếu bạn đang có ý định học và sử dụng ngôn ngữ này cho dự án, công việc của mình; hãy bắt đầu ngay từ bây giờ. Cảm ơn các bạn đã đọc bài và hẹn gặp lại trong các bài viết tiếp theo của mình.
Hãy để CV của bạn tỏa sáng trong mắt nhà tuyển dụng bằng cách khai thác tối đa các công cụ Tạo CV Online và Chuẩn hóa CV từ TopDev. Không chỉ dừng lại ở đó, khi trải nghiệm các tính năng độc đáo này, bạn sẽ có cơ hội tham gia chương trình “Chuẩn hóa CV, Chốt ngay phím chất” với nhiều phần quà giá trị đang chờ đón. Đừng bỏ lỡ cơ hội quý giá để định hình tương lai sự nghiệp của bạn. Hãy đăng ký ngay và khám phá những tính năng ưu việt của TopDev!
MySQL và MongoDB là hai hệ thống quản lý cơ sở dữ liệu phổ biến được sử dụng rộng rãi hiện nay, đều có khả năng mang lại hiệu năng và khả năng quản trị tốt. Tuy nhiên mỗi hệ thống sẽ có những đặc điểm khác nhau và phụ thuộc vào trường hợp bài toán thực tế để sử dụng một cách hiệu quả. Để xác định xem dự án sắp tới của bạn cần sử dụng hệ thống nào thì trong bài viết này chúng ta cùng so sánh giữa MySQL và MongoDB nhé.
MySQL là gì?
MySQL là một hệ thống quản trị cơ sở dữ liệu (CSDL) quan hệ mã nguồn mở (RDBMS) đầy đủ tính năng thuộc sở hữu của Oracle. Dữ liệu trong MySQL được lưu trữ dưới dạng các bảng và sử dụng ngôn ngữ truy vấn có cấu trúc (SQL) để thực hiện việc truy cập đến CSDL. MySQL được sử dụng cho việc lưu trữ các thông tin trên trang Web, tương thích với gần như tất cả các hệ điều hành (Windows, Linux, Unix,…) và hỗ trợ hầu hết các ngôn ngữ lập trình phổ biến (PHP, C, Java, JS,…).
MongoDB là gì?
MongoDB là một hệ thống CSDL phi quan hệ (NoSQL) mã nguồn mở được phát hành từ năm 2009. Dữ liệu trong MongoDB được lưu trữ dưới dạng tài liệu (document) JSON cho phép các ứng dụng lưu trữ và truy vấn một cách linh hoạt (không ràng buộc theo một ngôn ngữ truy vấn nào). MongoDB hiện nay cũng hỗ trợ hầu hết các ngôn ngữ lập trình phổ biến và được nhiều công ty lớn sử dụng như Facebook, Google hay Adobe,…
Điểm giống nhau giữa MySQL và MongoDB
Cả MySQL và MongoDB đều là các hệ thống quản trị CSDL phổ biến được sử dụng rộng rãi; chúng đều có sẵn các tính năng giúp người dùng thao tác và phân tích dữ liệu. Các tính năng, đặc điểm giống nhau mà cả 2 hệ thống này đều có hỗ trợ như:
Giấy phép mã nguồn mở: MySQL và MongoDB đều có giấy phép mã nguồn mở, chúng ta có thể tải xuống miễn phí để sử dụng, đồng thời có thể sửa đổi source code tùy theo nhu cầu sử dụng
Hỗ trợ lập chỉ mục (index): MySQL và MongoDB đều sử dụng lập chỉ mục để cải thiện tốc độ truy vấn và hiệu năng truy cập dữ liệu thường xuyên.
Hỗ trợ hầu hết các ngôn ngữ lập trình phổ biến: cả 2 nền tảng này đều tương thích với nhiều ngôn ngữ lập trình: Java, Python, PHP, C,…
Tính bảo mật cao: cả MySQL và MongoDB đều cho phép bạn thiết lập các cấp độ khác nhau cho quyền truy cập của người dùng. Để bảo vệ việc lưu trữ và thao tác với dữ liệu, mã hóa TLS/SSL được cả 2 hệ thống tích hợp sẵn.
Sự hỗ trợ lớn từ cộng đồng: MySQl với lịch sử phát triển gần 30 năm tạo ra một cộng đồng lập trình viên sử dụng vô cùng lớn, đứng sau là hãng Oracle uy tín. MongoDB mặc dù ra mắt sau nhưng sự tích cực và sẵn sàng lắng nghe của đội ngũ support cũng được đánh giá rất cao. Bạn có thể dễ dàng tìm được sự trợ giúp trong quá trình sử dụng 2 hệ thống này.
Chúng ta cùng xem xét sự khác biệt giữa 2 hệ thống này qua từng tiêu chí chính nhé:
Mô hình dữ liệu
MongoDB biểu thị dữ liệu dưới dạng tài liệu JSON, trong khi đó MySQL sử dụng các bảng bao gồm các hàng và cột để lưu trữ dữ liệu. Điều này dẫn đến sự khác nhau cơ bản giữa 2 nền tảng này khi bạn bắt đầu: với MySQL, bạn bắt buộc phải xác định lược đồ, cấu trúc, mô hình dữ liệu trước; ngược lại thì MongoDB không yêu cầu bạn xác định từ trước, có thể linh hoạt trong việc lưu trữ dữ liệu.
Các khái niệm giữa 2 hệ thống này gọi tên khác nhau nhưng cũng có sự tương đồng dựa theo mục đích sử dụng. Bạn có thể theo dõi hình trên để hiểu hơn các khái niệm trên nền tảng CSDL tương ứng.
Cả 2 hệ thống này đều cung cấp nhiều tính năng và chức năng từ đơn giản đến phức tạp. MongoDB được đánh giá cao hơn với nhiều tính năng liên quan đến việc phân tích dữ liệu, xử lý tìm kiếm nhiều mặt trên nhiều loại dữ liệu đa dạng. MongoDB cũng hỗ trợ mở rộng quy mô hệ thống dữ liệu theo chiều ngang thông qua Sharding (lưu trữ các bản ghi dữ liệu qua nhiều thiết bị) hay tính năng data locality giúp sắp xếp dữ liệu cho hệ thống phân tán một cách hiệu quả.
Ngôn ngữ truy vấn
Cả MySQL và MongoDB đều có một ngôn ngữ truy vấn riêng: MySQL sử dụng ngôn ngữ truy vấn có cấu trúc SQL; MongoDB sử dụng MQL- mặc dù là NoSQL nhưng nó cũng có đầy đủ các tính năng thao tác với dữ liệu như SQL. Một vài ví dụ sử dụng tương đương của 2 ngôn ngữ truy vấn này:
Thao tác truy cập dữ liệu:
MySQL: SELECT * FROM products
MongoDB: db.products.find()
Thao tác chèn, thêm mới:
MySQL: INSERT INTO products(id, name, amount)VALUES (‘001’, ‘Iphone 12’, 20)
MySQL được thiết kế giúp thực hiện các thao tác ghép nối, làm việc giữa các bảng dữ liệu với hiệu năng cao; tuy nhiên điều này cũng phần nào ảnh hưởng đến hiệu năng khi chèn, thêm mới, cập nhật dữ liệu. Ngược lại, MongoDB được thiết kế với mô hình dữ liệu phân cấp, thông tin được lưu trữ hầu hết ở một tài liệu duy nhất; điều này giúp hiệu suất chèn, thêm mới, thao tác với dữ liệu đơn trở nên nhanh vượt trội; nhưng lại không được tối ưu hóa cho các phép ghép nối dữ liệu từ nhiều tài liệu khác nhau.
Nên sử dụng MySQL hay MongoDB
MongoDB ra mắt sau nhưng thu hút được người dùng hiện nay với triết lý đơn giản và cởi mở và linh hoạt hơn. Cộng đồng lập trình viên cũng như đội ngũ hỗ trợ của MongoDB tỏ ra tích cực hơn so với tình trạng bế tắc trong việc cập nhật của MySQL. Mặc dù vậy, MySQL vẫn là một giải pháp tỏ ra phù hợp cho nhiều công ty trên toàn thế giới với bề dày lịch sử phát triển của mình.
Hãy lựa chọn MongoDB nếu bạn cần làm việc với lượng dữ liệu lớn và không có cấu trúc; hoặc bạn chưa thể xác định được cấu trúc dữ liệu của bạn và có định hướng cho các mục tiêu xa hơn trong tương lai. Ngược lại thì MySQL sẽ nên lựa chọn nếu quy mô dữ liệu của bạn không quá lớn, có tính cấu trúc rõ ràng; sử dụng MySQL có thể mang lại khả năng bảo vệ dữ liệu đáng tin cậy, dễ quản lý và tính sẵn sàng cao hơn.
Kết bài
Qua bài viết trên, hy vọng bạn đã có cái nhìn chi tiết hơn về 2 hệ thống quản trị CSDL phổ biến này. So sánh giữa MySQL và MongoDB trong từng trường hợp sử dụng cụ thể sẽ giúp bạn lựa chọn được công cụ phù hợp cho bài toán sắp tới của bản thân. Cảm ơn các bạn đã đọc bài và hẹn gặp lại trong các bài viết tiếp theo của mình.
Bài viết được sự cho phép của tác giả Nguyễn Hoàng Phú Thịnh
Chắc hẳn 500 anh em thường rất hay nghe tới “thuyết”: “Làm BA, là á hả, phải rành kỹ thuật dữ lắm, phải biết công nghệ này, công nghệ kia, thậm chí á hả, phải đọc hiểu được code đó nha, đâu zỡn chơi được, không là không mần được khỉ khô gì đâu, bla…bla….”
Thoạt nhìn thì câu trên có vẻ sai, nhưng thực tế thì nó… không đúng tí nào hết anh em.
Mình thấy xung quanh mình hầu như ai cũng nghĩ zậy (rất nhiều người nghĩ zậy). Và đặc biệt là các bạn chẻ trên mạng đang ấp ủ ý định làm BA.
Nó sẽ gây ra một cục hoang mang siêu to khổng lồ và ảnh hưởng ghê gớm đến sự tự tin của anh em…
Mình không biết tí gì về IT, sao làm BA bây giờ *icon run lẩy bẩy*
Kỹ thuật là đụng tới lập trình đúng hônggg, em học dở toán với tin lắm, a hu hu.
Trước giờ em chả biết gì về phần mềm các kiểu hết, giờ làm BA nổi hông…
Bài này mình sẽ note về những gì mình đã từng trải, và về thứ gọi là “kỹ thuật” đối với một người làm BA.
Mình tin là hỏi 10 người thì hết 10 ngàn người trả lời: “kỹ thuật” nghĩa là coding, là lập trình. Tức là phải hiểu, thậm chí phải rành về thuật toán các kiểu… Để nói chuyện với dev người ta còn hiểu nữa, “BA là cầu nối mà”.
Nhưng không, “kỹ thuật” ở đây hoàn toàn không phải là cốt-kiếc gì hết. Mà là: kỹ thuật của công việc BA. Tức là sao?
Bất cứ công việc nào cũng đều có kỹ thuật của nó hết.
Nghề viết có các kỹ thuật riêng, như: viết lách, viết ký sự, phóng sự…
Nghề sư phạm cũng có các kỹ thuật riêng của nó, áp dụng cho từng đối tượng
Chụp ảnh cũng phải có kỹ thuật thì chụp mới ra hồn được
Thậm chí… chích xì ke cũng phải có “kỹ thuật chích” thì chích mới… phê được. Đâu phải dễ ăn mà bay zô, cầm kim tiêm chích phát một là được.
Do đó, nghề BA cũng phải có các kỹ thuật của nó. Bên cạnh bộ kiến thức chuyên môn và bộ kỹ năng cũng rất quan trọng cho công việc BA này.
Theo từ điển Cambridge (không phải cứ từ điển là đúng, nhưng ít nhiều cũng có cái cho anh em mình tham khảo 😀 )
Technical (adj) = relating to practical skills and methods that are used in a particular activity. Còn theo tiếng Việt mình một cách đơn giản: “Kỹ thuật” là phương pháp được sử dụng để đạt được một kết quả nhất định.
Ví dụ muốn moi móc yêu cầu => sẽ có 11 kỹ thuật thường được áp dụng.
Do đó, mệnh đề trên là mình thấy hoàn toàn sai.
BA cần kỹ thuật không? Cần? Nhưng “kỹ thuật” ở đây không phải liên quan tới lập trình. Mà “kỹ thuật” ở đây là các kỹ thuật trong công việc của BA.
2. “Loại BA” nào thì cần kỹ thuật?
Trên thị trường hiện nay có hằng hà loại BA.
Có người thì chuyên làm về tối ưu quy trình. Có người thì chuyên hẳn về một platform công nghệ. Có người thì tập trung làm product. Hoặc cũng có người chỉ chuyên giải quyết các vấn đề tích hợp…
Nhưng dù có làm gì đi nữa, hễ ai mà làm một loạt các chuỗi công việc: Xác định Business Objective >> Làm việc với Stakeholders >> Đề xuất Solution >> Tiến hành Transition để đưa vào thực tế, thì người đó đều đang làm công việc BA. Bất kể giải pháp có là IT, hay non IT đi chăng nữa.
Bài note này mình nói về: yêu cầu “kỹ thuật” đối với BA. Và khái niệm “kỹ thuật” như nãy giờ anh em mình làm rõ, được áp dụng cho hầu hết các loại BA nhé anh em, bao gồm cả IT BA lẫn Non-IT BA.
Use Case, thứ có vẻ… “không đụng tới là không được” trong công việc BA.
Vì sao nó lợi hại như vậy? Vì nó giúp anh em mô tả sự tương tác giữa người dùng và hệ thống với nhau.
Một cách trực quan, nó thể hiện được các actor tương tác những gì, với những ai, trong một môi trường cụ thể – thông qua Use Case Diagram.
Và cũng một cách rất chi tiết, nó giúp anh em thể hiện được mọi ngóc ngách của sự tương tác đó, như: actor là ai, trigger point là gì, pre-condition ra sao, post-condition thế nào…. thông qua Use Case Specification.
Và đặc biệt là thể hiện được sự tương tác này diễn ra step-by-step như thế nào (Basic Flow)? Hoặc có thể có những cách làm nào khác không (Alternative Flow)? Và cũng thể hiện được luôn: các bước làm nào khiến cho sự tương tác này diễn ra thất bại (Exception Flow)?
…
Xưa giờ anh em hay gói gọn Use Case trong ngữ cảnh “software development”. Giờ thử áp dụng Use Case để phân tích một thứ gì đó trong cuộc sống nhé.
Giả dụ: Mình mở một nhà hàng bán đặc sản Lào ngon nhất Vịnh Bắc Bộ. Và để thu hút 500 anh em tới ăn đông đảo, mình muốn các khâu trong nhà hàng phải thật chỉn chu và kỹ lưỡng. Đặc biệt là khâu tiếp đón khách tới quán ăn.
Vì là BA mà, nên mình muốn phân tích xem thử khâu tiếp đón khách vô quán cụ thể nó ra sao, bao gồm:
Thực tế nó được bắt đầu khi nào?
Khi nào thì quán sẵn sàng đón khách?
Khi nào thì xem như khâu đón khách diễn ra thành công?
Các bước đón khách diễn ra như thế nào?
Hoặc có cách nào khác đổi mới để đón khách ngầu lòi hơn hay không?
Hoặc những thứ cấm kỵ nhân viên làm khi đón khách vào quán?
Và hàng trăm thứ khác nữa mà mình muốn biết (vì mình muốn làm khâu này thật kỹ) mà giờ chưa nghĩ ra!!!
Ánh xạ qua kỹ thuật Use Case, nó sẽ như thế này (ví dụ nhé anh em):
Thực tế nó được bắt đầu khi nào? – Trigger
Khi khách gửi xe xong và… bước vào quán
Hoặc xe taxi/ grab car chở khách tới ngay trước sảnh.
Khi nào quán sẵn sàng đón khách – Pre-Condition(s)
Khi đầu bếp báo đồ ăn đã sẵn sàng
Và phục vụ báo bàn ghế đã được dọn dẹp.
Khi nào thì xem như khâu tiếp đón khách diễn ra thành công – Post-Condition(s)
Khi khách đã vô tới bàn của mình
Và quay sang cảm ơn hoặc cười với nhân viên (vì service khủng mà, nên điều này là bắt buộc)
Các bước đón khách diễn ra như thế nào – Basic Flow
Chào anh/ chị >> hỏi xem có đặt bàn trước chưa >> hỏi xem có bạn chưa >> hỏi đi mấy người >> dẫn vô đến tận bàn >> cảm ơn anh/ chị. (Về lý thuyết, anh em có thể mô tả rõ: tương tác giữa nhân viên và khách thế nào. Ví dụ nếu nhân viên hỏi mà khách trả lời A thì sao, trả lời B thì làm gì…. Phân tích chi tiết sẽ giúp anh em cover đủ được các trường hợp hơn nữa ở bước sau)
Hoặc có cách nào khác đổi mới để đón khách ngầu lòi hơn hay không?– Alternative Flow
Ví dụ:
Mô tả các bước đón khách từ xe taxi/ grab car khi xe dừng ở trước sảnh
Hoặc đổi mới cách đón khách: Nếu ngày lễ halloween thì khách vô sẽ cho kẹo, hoặc ngày valentine thì khách vô sẽ tặng sô cô la…
Hoặc những thứ cấm kỵ nhân viên làm khi đón khách vào quán? – Exception Flow
Khi khách vào tới trước cửa quán mà nhân viên còn nói chuyện riêng >> failed
Khi hỏi khách mà không cười và nhìn khách >> failed
Khi dẫn khách vào mà trang phục lôi thôi, đầu tóc không đúng quy định >> failed.
Trên là ví dụ cho việc áp dụng Use Case để phân tích một thứ gì đó ngoài phạm vi phần mềm.
Khi phân tích ra chi tiết như vầy, mình sẽ có cái nhìn đầy đủ hơn để dễ dàng: training cho nhân viên, hoặc cải thiện các khâu chưa đạt, hoặc cũng có thể tối ưu lại nhân sự…..vâng vâng và mây mây.
Nếu anh em muốn phân tích gì đó thật kỹ lưỡng và chi tiết, hãy thử sử dụng kỹ thuật Use Case này. Nó sẽ giúp anh em nhìn được hầu hết mọi ngóc ngách của vấn đề. Để từ đó tính trước những việc cần làm nếu chẳng may gặp sự cố 🙂
UML là Unified Modeling Language, còn BPMN là Business Process Model and Notation. Nôm na UML và BPMN sẽ giúp anh em chuyển thể quy trình và hàng tá thứ khác sang dạng hình vẽ.
Hay nói sang hơn, UML và BPMN là các kỹ thuật dùng để “mô hình hóa”.
Mô hình hóa cái gì? Mô hình hóa những thứ phức tạp, rối rắm như:
Quy trình chẳng hạn (dùng BPMN, hoặc UML Activity Diagram)
Hoặc để mô tả các bảng dữ liệu quan hệ với nhau ra sao (UML ERD)
Hoặc để mô tả luồng tương tác giữa người dùng với hệ thống (UML Sequence Diagram)
Hoặc mô tả luồng dữ liệu đi như thế nào (UML DFD)
Và còn rất nhiều thứ phức tạp khác, mà anh em sẽ cần chuyển hóa nó thành hình vẽ để có thể “tiêu hóa” dễ dàng hơn.
Nói về UML/ BPMN thì sẽ có 2 thứ:
Tools để vẽ
Và cách vẽ.
Đa phần mọi người sẽ rất rành về các tools để vẽ, tools nào cũng biết, cũng đã từng xài. Nhưng để “vẽ không sai” và thể hiện đúng ý đồ thì không phải ai cũng làm được. Nó nằm ở cách vẽ.
Vẽ một diagram chuẩn là 5 người nhìn vào diagram, là cả 5 người cùng hiểu chung một ý. Chứ không phải mỗi người hiểu mỗi ý khác nhau. Nhưng thực tế thì anh em biết đó, thường sẽ là… mỗi người hiểu một ý khác nhau. Vụ này mình bị miết nên rành lắm.
Mấu chốt là diagram mình vẽ, nó còn có những cách đọc, cách nhìn khác nữa, mà mình “chưa nhìn ra”. À háaaa, kiểu như bị hở chỗ này, hở chỗ kia.
Giống như hình mình vẽ theo cách hiểu A của mình, nhưng thực tế hình này còn có cách hiểu B, C, và thậm chí cách hiểu D nữa. Người khác nhìn vào, chẳng may họ không nhìn theo cách hiểu A của mình, mà lại đi hiểu theo cách B, C, D của họ là toang ngay.
Lúc đó, mô hình hóa không giúp cho vấn đề dễ tiêu hóa hơn, mà còn làm “tan chảy” độ nguyên bản của nó, làm “tam sao thất bản”, làm cho vấn đề trở nên rối rắm hơn khi mỗi người hiểu một ý.
Đó là lý do mà thế giới có các: bộ quy chuẩn để vẽ UML hay BPMN.
Tình huống nào thì dùng cái gì? Dùng diagram này thì có những ký hiệu chuẩn nào, quy tắc dùng ra sao, khi dùng thì chú ý điểm gì…..? Có những chuẩn này, anh em sẽ dễ dàng align cách diễn đạt và cách hiểu với nhau hơn.
Anh em đọc thêm seri mình viết về BPMN tại đây nhé.
Tóm gọn, kỹ thuật UML/ BPMN không chỉ là biết dùng tools để vẽ, mà phải vẽ sao cho đúng và thể hiện được trọn vẹn ý đồ của mình.
3.3. Data Modeling
Ở kỹ thuật này, chủ yếu anh em BA làm phần mềm sẽ dùng nhiều.
Vì Data Modeling sẽ giúp anh em đi sâu vào cách dữ liệu được lưu như thế nào dưới database của một giải pháp phần mềm. Rộng hơn một chút dưới góc nhìn của BA, Data Modeling sẽ giúp anh em nắm được:
Những đối tượng nào được “ghi lại” dưới database, mức độ chi tiết của từng đối tượng?
Quan hệ giữa các đối tượng ra sao => phần nào sẽ giúp anh em mường tượng được function liên quan đến những đối tượng đó
Những business rules nằm sau các bảng dữ liệu là gì?
Data Modeling có thể được sử dụng để anh em tiếp cận vấn đề => phân tích xem thử có những đối tượng nào cần mổ xẻ >> lưu trữ >> phân tích. Hoặc cũng có thể là phương tiện để anh em catch up một system nào đó.
“BA giải quyết vấn đề”, giả sử nếu cần một giải pháp công nghệ để giải quyết một bài toán bất kỳ đi chẳng hạn.
Giả dụ: bạn mình đang gặp vấn đề trong việc quản lý hồ sơ ứng viên. Có một số “pain points” như sau:
Trung bình một bộ hồ sơ có quá nhiều thông tin. Trong đó có những thông tin bắt buộc lẫn những thông tin không bắt buộc.
Bộ hồ sơ có những “rules” liên quan ăn nhậu với nhau rất chặt chẽ, ví dụ:
Ứng viên nữ thì không quá 30 tuổi, ứng viên nam thì phải dưới 35
Ứng viên nữ cho bộ phận Admin thì tối thiểu phải IELTS 7.0, kinh nghiệm tối thiểu 4 năm, và chưa có gia đình
Ứng viên cho bộ phận Purchasing thì không được có kinh nghiệm làm ở các công ty: ABC và XYZ.
Ngoài ra còn phải check trùng thông tin ứng viên theo một bộ thông tin định danh, bao gồm: Họ và tên, CMND, Giới tính và DOB.
Và đặc biệt là: vì quản lý hồ sơ giấy nên mỗi lần check thông tin là mất cả buổi và rất dễ sai sót.
Nắm được một mớ pain points trên, chiếu qua lăng kính Biz Analyst, mình sẽ rõ được Business Objectives ở đây là phải có “một cái gì đó” giúp giải quyết gọn lẹ những yêu cầu trên.
“Một cái gì đó” ở đây sẽ là: Excel.
Đầu tiên mình sẽ xem bộ hồ sơ sẽ có những thông tin nào, tức bao gồm những đối tượng nào? Ví dụ có 5 đối tượng cần lưu trữ: Ứng viên, Kinh nghiệm làm việc, Học vấn, Sơ yếu lý lịch, và Lịch sử trao đổi.
5 đối tượng này sẽ tương đương với 5 sheets trong file excel.
Tiếp theo, 5 đối tượng này quan hệ với nhau như thế nào? Ví dụ ứng viên sẽ có nhiều kinh nghiệm làm việc, nhiều học vấn và nhiều lịch sử trao đổi công việc với nhau… Nếu quan hệ như vậy thì record giữa các sheet sẽ “link” với nhau như thế nào?
Chưa hết, mỗi thông tin trong bộ hồ sơ có quy định gì đặc biệt không, hay có dây mơ rễ má tới các thông tin khác như thế nào không? Mình sẽ liệt kê ra hết, thành một bộ validation rules cho từng dữ liệu.
Và sau cùng mình sẽ build một file Excel, sử dụng VBA để làm một cái form. Bạn mình sẽ nhập hồ sơ qua form, và validate thông tin ngay trên form nhập liệu này.
Kỹ thuật Data Modeling sẽ giúp anh em tóm gọn một mớ thứ rối rắm bên trên dưới góc nhìn data. Nó có thể thông qua Entity Relationship Diagram, Data Flow Diagram, hoặc Data Dictionaries.
Hoặc ở một ví dụ khác, khách hàng cần quản lý quy trình: Bước A >> Bước B >> Bước C >> Bước D.
Cơ bản anh em có 2 cách để thiết kế dữ liệu chỗ này:
Cách 1: Làm 4 tables, tượng trưng cho 4 objects: A, B, C, D. 4 đối tượng này link với nhau (quan hệ với nhau) theo một rules nhất định.
Cách 2: Chỉ cần 1 table, tượng trưng cho cả 4 objects: A, B, C, D. Và phân biệt từng chặng trong quy trình dựa vào 1 field status của table này. Status = A là đang ở bước A. Status = B là đang ở bước B, tượng tự cho C, và D.
Nếu requirement chỉ cần quản lý quy trình này thôi thì cả 2 cách đều ổn.
Nhưng nếu sau này khách hàng cần phân tích dữ liệu theo dạng Pipeline Chart thì có vẻ: cách 2 sẽ… khó hơn một tí so với cách 1. Vì rõ ràng, tổ chức dữ liệu như cách 1 sẽ tự nhiên hơn cách 2, nhưng lại tốn nhiều effort để thực hiện hơn cách 2.
Do đó, anh em cần phải hiểu và làm được Data Modeling để nhìn nhận những vấn đề tương tự như vầy.
Khi đã hiểu về data, hiểu về thứ nhỏ nhất xây nên một giải pháp phần mềm, hiểu về từng viên gạch nhỏ nhất để xây nên một ngôi nhà. Anh em mới có cơ hội làm đúng được khái niệm “phân tích và thiết kế”trong công việc BA của mình 🙂
3.4. Wireframe
Kỹ thuật cuối cùng là thiết kế Wireframe cho giao diện phần mềm. Cũng giống Data Modeling, kỹ thuật này áp dụng cho anh em IT BA là nhiều.
Nôm na thì Wireframe sẽ giúp anh em thể hiện được CẤU TRÚC và NHÓM THÔNG TIN có trên UI của phần mềm. Điều này giúp anh em truyền tải được yêu cầu người dùng đến Development Team, một cách chính xác và rõ ràng hơn bao giờ hết.
Vì kỹ thuật này cũng không quá đặc biệt. Và theo mình cũng không quá khó.
Với những thứ chưa biết, chưa rõ nó có thể chạy ra sao, behaviour như thế nào, anh em có thể xem thêm các framework hoặc các thư viện sẵn có về UI như Ant Design, hoặc Semantic-UI để tham khảo các components sẵn có của họ cũng rất hay.
Mình có note một bài về: Sketch – Wireframe – Mockup – Prototypeở đây. Anh xem thêm nhé.
4. Tạm kết
Nói về “kỹ thuật”, nhưng bài này không nói về lập trình, hay cách một application hoạt động.
Thực tế mình quan sát, đa phần những BA chính hiệu xung quanh mình thường ít khi quan tâm đến những thứ sâu xa về kỹ thuật, lập trình. Nếu có thì cũng đâu đó tìm hiểu thêm, chứ hiếm khi chủ động tìm hiểu vì phạm vi công việc.
Vì đơn giản, ai trong team cũng có vai trò riêng của mình.
Họ nhận thức rõ được phạm vi công việc của họ, họ không care (không thể và cũng không muốn care) đến những chuyện thuần về giải pháp kỹ thuật. Đó là nhiệm vụ nên làm và sẽ được làm tốt nhất bởi Solution Architect và các anh em Developer.
Nếu ai cũng rõ nhiệm vụ của mình, và tập trung hoàn thành tốt nhiệm vụ, sản phẩm làm ra sẽ trơn tru và hoàn thiện hơn rất nhiều.
Tuy vậy, mình không phủ định hoàn toàn chuyện kiến thức về lập trình có ảnh hưởng tích cực đến công việc của BA.
Như đầu bài, note này hy vọng sẽ giúp anh em đỡ lo lắng, và căng thẳng hơn khi nhắc đến 2 chữ “kỹ thuật” đối với BA. Thay vào đó, hãy cứ nắm vững 4 “kỹ thuật” trên là mình tin anh em có thể làm tốt được vai trò BA của mình trong bất kỳ công ty nào.
Hi vọng bài note này sẽ có ích với anh em. Tương tác và chia sẻ góc nhìn của anh em bên dưới nhé.
CSS là một trong ba kiến thức nền tảng của lập trình viên Frontend bên cạnh HTML và JavaScript, giúp bạn tạo ra phong cách cho trang Web. Để có thể khai báo và áp dụng CSS style đúng cho từng phần tử HTML trên DOM, chúng ta cần đến các CSS Selector. Vậy CSS Selector là gì? Bài viết hôm nay chúng ta cùng nhau tìm hiểu về nó và cách sử dụng các loại CSS Selector phổ biến hiện nay nhé.
CSS Selector là gì?
CSS Selector là một mẫu (template) hoặc quy tắc (rules) được sử dụng để xác định các phần tử HTML cụ thể trên trang, từ đó áp dụng các thuộc tính CSS lên chúng.
Như chúng ta đã biết, có 3 cách để khai báo CSS bao gồm: inline (viết trực tiếp vào thẻ HTML thông qua thuộc tính style), internal (viết tại file HTML và nằm trong cặp <style></style>) và external (viết thành file css riêng và import vào thông qua các thẻ <link></link>). Ngoại trừ cách khai báo inline, gắn trực tiếp CSS vào phần tử được chỉ định thì cách viết internal và external đều khai báo CSS tách biệt với HTML; từ đó yêu cầu cần có cách để xác định được rằng đoạn CSS này sẽ áp dụng cho phần tử (hay nhóm phần tử) HTML nào. Và đấy chính là công việc của CSS Selector.
Cú pháp khai báo CSS Selector
Lợi ích khi sử dụng CSS Selector
CSS Selector giúp bạn chỉ định chính xác và nhanh chóng nhiều phần tử HTML trên trang để áp dụng các thuộc tính CSS, lợi ích khi sử dụng CSS Selector bao gồm:
Tách biệt phần HTML và CSS giúp cho source code của trang Web trở nên dễ đọc hiểu và dễ quản lý
Tăng tính nhất quán trong thiết kế và bố cục (layout) cho trang Web
Có khả năng xây dựng nhiều mẫu CSS khác nhau (các themes) và áp dụng một cách thống nhất trên toàn trang Web
Tăng tính linh hoạt trong việc định dạng phần tử HTML và có khả năng tái sử dụng CSS giúp tiết kiệm thời gian cũng như giảm rủi ro lỗi
CSS Selector có thể xem là không thể thiếu trong việc phát triển, xây dựng Website hiện nay, vì vậy việc nắm được cách sử dụng các loại CSS Selector để áp dụng vào thực tế là điều vô cùng quan trọng. Chúng ta cùng tìm hiểu những CSS phổ biến cùng cách sử dụng chúng nhé.
Có 5 loại CSS selector chính thường xuyên được sử dụng giúp bạn có thể chọn các nhóm phần tử khác nhau trên một trang Web. Chúng ta cùng đi lần lượt từng loại nhé.
Id Selector
Id selector sử dụng thuộc tính id để chọn một element trên DOM. Thông thường giá trị id của element trên DOM là duy nhất, vì vậy khi sử dụng id selector, kỳ vọng trả về là sẽ áp dụng css cho một phần tử cụ thể. Lưu ý rằng selector này chỉ hoạt động được khi giá trị id khai báo phải khớp với thuộc tính id của element.
Cú pháp của Id selector:
#id_name { style: properties; }
Trong đó:
ký tự # (dấu thăng) thể hiện cho việc sử dụng loại Id selector
id_name: giá trị id khai báo để áp dụng css
Class Selector
Class selector sử dụng thuộc tính class để chọn các elements trên DOM. Giá trị class thường sẽ được tái sử dụng ở nhiều phần tử, vì thế class selector sẽ chọn ra được nhiều elements và gán các css cho các thành phần đó. Sử dụng class selector giúp bạn linh hoạt, đồng thời có khả năng tái sử dụng cao trong việc khai báo CSS. Selector này cũng là loại được sử dụng nhiều nhất trong thực tế.
Cú pháp của class selector:
.class_name { style: properties; }
Trong đó:
ký tự . (dấu chấm) thể hiện cho việc sử dụng loại class selector
class_name: giá trị class khai báo để áp dụng css
Class selector cũng là nền tảng cho nhiều bộ CSS Framework/ Library như Bootstrap, Tailwind,… sử dụng thông qua classname để quy định các CSS cho phần tử.
Element Selector sử dụng thẻ tên (HTML Tags) cho việc chọn các phần tử trên DOM. Việc sử dụng element selector sẽ có thể làm ảnh hưởng đến rất nhiều phần tử cùng thẻ tên, vì thế thông thường loại selector này dùng cho một số css chung trên trang (như font family) hoặc style toàn trang (như themes).
Cú pháp của element selector:
tag_name { style: properties; }
Trong đó:
tag_name: giá trị thẻ tên khai báo để áp dụng css
lưu ý trước tagname không chứa ký tự nào khác
Universal Selector
Universal Selector sử dụng cho việc chọn tất cả các phần tử trên trang. Bạn cũng có thể sử dụng universal selector bên trong một thẻ, một classname, một id để áp dụng css cho tất cả các phần tử con bên trong đối tượng tương ứng.
Cú pháp của universal selector:
* { style: properties; }
Trong đó:
ký tự * (hoa thị) thể hiện cho việc sử dụng loại universal selector
lưu ý universal selector áp dụng cho tất cả phần tử con, cháu, … trong đối tượng khai báo
Pseudo Classes
Pseudo class là tên được thêm vào css selector để cho biết mã CSS sẽ được áp dụng vào phần tử khi phần tử ở trạng thái nào đó cụ thể. Ví dụ khi một phần tử đang được focus, hoặc đang được hover, hay một ô input đang ở trạng thái disabled, …
Cú pháp của pseudo class:
selector:pseudo { style: properties; }
Trong đó:
selector: phần tử được sử dụng khai báo CSS thông qua các CSS selector
ký tự : đánh dấu việc khai báo trạng thái của phần tử
pseudo: thuộc tính trạng thái của phần tử, ví dụ hover, focus, active, …
Lưu ý rằng mỗi phần tử (HTML tag) sẽ có những thuộc tính trạng thái khác nhau. Bạn có thể tham khảo thêm danh sách các trạng thái của từng loại phần tử như dưới đây:
Kết bài
Qua bài viết này, hy vọng các bạn đã hiểu rõ hơn về CSS Selector và cách sử dụng của một số loại CSS Selector phổ biến. Sử dụng đúng và hiệu quả các CSS Selector sẽ giúp bạn áp dụng CSS vào trang Web của mình một cách linh hoạt và chính xác. Cảm ơn các bạn đã đọc bài và hẹn gặp lại trong các bài viết tiếp theo của mình.