Tag: Programming

Đừng chỉ viết code, hãy tập giải quyết vấn đề

Post author By Gambaru
Post date 26 March, 2021
No Comments on Đừng chỉ viết code, hãy tập giải quyết vấn đề

Những lần gặp khó khăn khi code là những lần ta tích lũy kinh nghiệm, nhận ra được các mẫu có tính lặp lại và khám phá những chiến lược nhất định. Nếu phân loại được đoạn code và những vấn đề tương tự sẽ giúp ích rất nhiều cho lập trình viên.

*Tập trung giải quyết vấn đề để cải thiện kỹ năng lập trình. Ảnh: lloorraa – Pixabay*

Việc học giải quyết vấn đề theo hệ thống như vậy đã được thảo luận từ rất lâu.

Gambaru xin giới thiệu với các bạn một trong những nhà toán học tuyệt vời đã chia sẻ về vấn đề này, George Polya, qua cuốn sách nổi tiếng How to solve it, a new aspect of mathematical method xuất bản lần đầu năm 1945.

Không rõ George Polya có mong đợi lập trình viên thế kỷ 21 đọc được tác phẩm toán của mình hay không, nhưng tôi mong các bạn nhận ra được những góc nhìn của ông có giá trị đến thế nào.

*Sách How to Solve it – A new aspect of mathematical method viết bởi George Polya. Ảnh: Amazon*

Giải quyết vấn đề không phải là một năng khiếu

“Giải toán là một kỹ năng thực tế như bơi lội. Chúng ta thành thục được bất kỳ kỹ năng nào bằng cách bắt chước và thực hành. Khi tập bơi, bạn bắt chước theo cách mọi người dùng tay và chân để giữ cho đầu ở trên mặt nước và cuối cùng, bạn biết bơi nhờ tập luyện. Khi tập giải toán, bạn quan sát và bắt chước những gì người khác làm khi giải toán và cuối cùng, bạn biết giải toán nhờ thực hành.”
– George Polya, How to solve it

Giải quyết vấn đề không chỉ là về “trí óc”

“Dạy giải toán chính là sự rèn luyện ý chí. Để giải quyết những bài khó, người học sẽ học cách kiên trì vượt qua thất bại, trân trọng những tiến bộ nhỏ, chờ đợi ý tưởng cần thiết và tập trung hết sức khi ý tưởng xuất hiện.”
– George Polya, How to solve it

Quyết tâm và cảm xúc đóng một vai trò quan trọng khi giải quyết các vấn đề khó.

Quy trình giải quyết vấn đề

Bất cứ khi nào thực hiện quá trình giải quyết vấn đề, hãy ghi nhớ bốn bước sau:

Hiểu vấn đề
Lập kế hoạch
Thực hiện kế hoạch
Nhìn lại và đánh giá

1. Hiểu vấn đề

Trước khi đi tìm giải pháp, cần phải trình bày được tất cả các yếu tố của vấn đề để hiểu nó rõ hơn.

Bạn có thể nêu vấn đề trong một câu không?

Bài tập nhỏ này rất hữu ích: thuyết phục bản thân rằng bạn đã hiểu mục tiêu và không tốn quá nhiều năng lượng để hiểu nó nữa khi đang tập trung giải quyết vấn đề.

Như được đề cập trong sách The Pragmatic Programmer, khi lập trình viên debug với “vịt cao su” chính là buộc bản thân phải hiểu rõ vấn đề để có thể dạy nó cho người khác.

Debug bằng vịt cao su — *Kỹ thuật debug đỉnh cao với vịt cao su: Bạn có giải thích được vấn đề cho người khác*

Có những ràng buộc nào cần phải đáp ứng không?

Những ràng buộc cần đáp ứng — “Trước hết, hãy hiểu vấn đề một cách tổng thể. Từ đó, ta mới có thể đánh giá những điểm cụ thể nào là quan trọng nhất. Sau khi xem xét một hoặc hai điểm trọng yếu, ta mới có thể đánh giá xem chi tiết nào đáng để điều tra kỹ hơn. Hãy đi vào sâu chi tiết và phân tích vấn đề dần dần, nhưng không đi xa hơn mức mình cần.” – **George Polya**, **How to solve it**. Ảnh: Freepik

Những hạn chế trong vấn đề bạn đang giải quyết là gì?

Hãy viết chúng ra. Nó có thể là một comment phía trên dòng đầu tiên của một hàm bạn viết, một danh sách các gạch đầu dòng trên đầu tài liệu thiết kế.

Điều quan trọng là phải tập trung vào chúng khi cố gắng tìm giải pháp.

Gỡ bỏ nhiều ràng buộc khỏi bộ não cũng là một cách loại bỏ một số quả bóng khi tâm trí ta chơi trò “tung hứng” trong khi cố gắng đưa ra một ý tưởng hay.

Ngoài ra, hãy cẩn thận nếu có quá nhiều ràng buộc.

Theo Polya, nếu xem xét quá nhiều chi tiết cùng một lúc, bạn có thể lạc lối. Chúng có thể khiến bạn mất tập trung vào điểm chính yếu hoặc thậm chí không nhìn thấy điểm chính yếu đó.

Bạn có thể vẽ hình minh họa hay một hệ thống ký hiệu phù hợp?

Vẽ minh họa hay hệ thống ký hiệu “Một bước quan trọng khi giải toán là chọn hệ thống ký hiệu. Điều này cần được thực hiện một cách cẩn thận. Làm được ta sẽ tiết kiệm thời gian cho sau này do tránh được những do dự và nhầm lẫn không đáng.” – **George Polya**, **How to solve it**. Nguồn ảnh: Sarah Pflug – Burst

Các bản vẽ hay phác thảo sẽ giúp bỏ bớt một số suy nghĩ ra giấy và tạo nhiều khoảng trống hơn cho bộ não tập trung vào những phần khó.

Hãy chọn hệ thống ký hiệu giúp bạn hiểu rõ mọi thứ hơn: diagram, flowchart….

2. Lập kế hoạch

Giải quyết vấn đề trên giấy trước. Việc viết code luôn có vẻ dễ dàng hơn trong đầu và trở nên phức tạp hơn nhiều khi làm nó chạy được.

Đừng làm cả hai việc cùng một lúc. Đầu tiên, hãy giải quyết vấn đề. “Chạy thử” một ví dụ trên sổ hoặc trên pseudocode. Sau đó, chạy trên máy.

Bạn có biết một vấn đề liên quan?

Bạn cần biết ít nhất loại vấn đề hoặc nhóm vấn đề bạn đang giải quyết. Đối với dân phần mềm, hãy thử trả lời những câu hỏi sau:

Đây có phải là vấn đề kiến trúc không?
Có những mẫu kiến trúc nào thường được sử dụng trong kịch bản này không?
Vấn đề này có nhiều hơn ở cấp độ của một giải thuật không?
Có giải thuật đã được chứng minh có thể giải quyết loại vấn đề này không?

Khi có thể tìm thấy một vấn đề liên quan đến vấn đề của mình và đã được giải quyết trước đó, bạn nên ăn mừng.

Đặt tiếp câu hỏi: “Mình có thể sử dụng nó không?”

Nhiều vấn đề có thể có một số điểm chung, nhưng những vấn đề có chung các yêu cầu hoặc nền tảng cốt lõi nhất có lẽ sẽ hữu ích nhất.

Bạn có thể trình bày lại vấn đề được không?

Bạn có thể nhìn nhận vấn đề ở một góc độ khác? Có thể bỏ một phần điều kiện hoặc một số yêu cầu không? Có thể nêu vấn đề này theo một kịch bản cụ thể hơn không?

Nếu đang viết các bài test, hãy thử nghĩ đến các ví dụ đơn giản được tạo ra chỉ bởi các điều kiện cụ thể của vấn đề để tìm ra giải pháp cuối cùng, tổng quát hơn.

Điều này dẫn chúng ta đến…

Nếu không thể giải quyết vấn đề được đề xuất, hãy cố giải quyết một số vấn đề liên quan trước tiên

Hoặc một vấn đề liên quan và đơn giản hơn.

Giống như viết phần mềm hiệu quả, việc thực hiện giải quyết vấn đề hiệu quả có thể được coi là một quá trình mang tính tịnh tiến.

Đừng cố làm mọi thứ cùng một lúc.

Xây dựng code cuối cùng hoặc thậm chí là các sơ đồ và ý tưởng thiết kế hệ thống là một quá trình sẽ mang lại lợi ích rất nhiều từ việc thực hiện điều tương tự cho các vấn đề quy mô nhỏ hơn.

3. Thực hiện kế hoạch

Phiên bản dành cho lập trình viên của câu trên là “Nghĩ trước, code sau”. Khi đã hiểu các bước của giải thuật hoặc thiết kế hệ thống, việc triển khai sẽ dễ dàng hơn rất nhiều.

Polya cho rằng những người giải toán giỏi có khả năng kiểm tra từng bước trong giải pháp sau khi hoàn thành và chất vấn từ đầu đến cuối.

Chỉ một dòng suy nghĩ về phân tích, phép toán sai sẽ làm hỏng mọi thứ.

Điều này có vẻ không mang đến nguy hiểm tức thì trong lập trình phần mềm, nhưng nó có thể là nguy hiểm chí mạng, vì bug nghiêm trọng sẽ xuất hiện trong thời điểm tồi tệ nhất – và có thể trong trường hợp rất cụ thể.

Điều này có nghĩa là cần có phạm vi kiểm thử tốt.

Nếu không kiểm thử, bạn sẽ không chất vấn, cứ tự tin coi giải pháp của mình là hoàn hảo.

Rất hữu ích khi có tư duy “Nó sẽ có lỗi chứ?” và liên tục đưa ra tất cả các kịch bản thất bại khác nhau trong giải pháp của mình và tư duy này sẽ được thể hiện rõ trong các bài test phần mềm.

4. Nhìn lại

Không nhìn lại và đánh giá sự đánh đổi của giải pháp thường xảy ra khi mọi thứ được thực hiện trong vội vàng.

Nếu đó là một giải thuật, bạn có thể nói rõ độ phức tạp về thời gian và không gian không? Code có đọc tốt không?

Nếu đang đưa ra quyết định sẽ có tác động đến toàn hệ thống, hãy ghi ra những đánh đổi.

Dành một giờ để xem xét lại kết quả công việc sẽ giúp bạn tiết kiệm hơn rất nhiều sau này.

Bạn có thể nghỉ ngơi rồi quay lại với nó sau. Việc đắm chìm sâu vào vấn đề đang giải quyết có thể sẽ khiến bạn quên mất những chi tiết liên quan.

Ngoài ra, giải pháp cho vấn đề cụ thể đó có thể được tổng quát hóa để được sử dụng trong nhiều tình huống.

Dùng sự nhạy bén và tư duy cẩn thận để tạo ra những abstraction mới là một cách giải quyết vấn đề đó cho những người khác đối mặt với nó sau này.

Kết

Dù là một cuốn sách dạy giải toán, nhưng How to solve it của George Polya với những lời khuyên vượt thời gian của ông lại hữu ích với dân lập trình như tôi khi tập giải quyết vấn đề bởi lập trình thực sự là một quá trình sử dụng nhiều tư duy và kỹ năng giải quyết vấn đề hiệu quả.

Theo Douglas Navarro

Tags Coding, Gambaru, Problem Solving, Programming, Soft skills, Software Development

Gambaru News

5 Xu hướng phát triển phần mềm cần năm 2021

Post author By Gambaru
Post date 18 March, 2021
No Comments on 5 Xu hướng phát triển phần mềm cần năm 2021

Làm việc từ xa và giãn cách xã hội ảnh hưởng lớn đến hầu hết mọi người; song khi nói đến chuyển đổi kỹ thuật số và phần mềm, mọi thứ vẫn diễn ra sôi nổi hơn bao giờ hết.

Đại dịch đã buộc rất nhiều doanh nghiệp phải thay đổi và thích ứng sự hiện diện trực tuyến của mình bằng cách này hay cách khác.

Đồng thời, các dịch vụ phát triển phần mềm trở nên ngày càng quan trọng.

Đây là lý do tại sao việc cập nhật các xu hướng hiện tại đang diễn ra trong ngành là vô cùng cần thiết.

5 Xu hướng phát triển phần mềm thống trị năm 2021

Dưới đây là một số xu hướng dự đoán sẽ thống trị lĩnh vực phát triển phần mềm cho năm 2021. Hãy cùng Gambaru cập nhật và thảo luận!

1. Điện toán không máy chủ (Serverless Architecture)

Điện toán không máy chủ là sự kết hợp của Chức năng như một Dịch vụ (stateless Function as a Service – FasS), chẳng hạn như AWS Lambda và Máy chủ lưu trữ như một Dịch vụ (stateful storage Backend as a Service – BaaS), chẳng hạn như AWS S3.

“Theo định nghĩa của chúng tôi, một dịch vụ được coi là không có máy chủ khi nó cho phép thanh toán dựa trên mức độ sử dụng, tự động mở rộng quy mô mà không cần cấp quyền thủ công.”
– A Berkeley View on Serverless Computing

Điện toán không máy chủ là nơi các dịch vụ đám mây được quản lý hoàn toàn. Nó cho phép ta viết code để phát triển ứng dụng mà không cần quản lý hoặc duy trì các cơ sở hạ tầng, chẳng hạn như máy chủ.
Điện toán không máy chủ hỗ trợ phương thức thanh toán: dùng bao nhiêu thanh toán bấy nhiêu. So với các nền tảng điện toán truyền thống, điện toán không máy chủ cho phép người dùng lựa chọn phương thức thanh toán dựa trên các tình huống cụ thể, giúp giảm chi phí.
Điện toán không máy chủ hướng đến ứng dụng, khác với các nền tảng điện toán hướng đến tài nguyên, chẳng hạn như các máy ảo và container.

Tham khảo sơ đồ kiến trúc của một ứng dụng không máy chủ 100% để biết thêm cách thức hoạt động.

2. Framework đa nền tảng (Multi-Platform Frameworks)

Với lập trình đa nền tảng, cùng một đoạn code sẽ có khả năng chạy được trên nhiều nền tảng khác nhau.

Đa nền tảng ngày càng trở nên phổ biến vì ta có thể sử dụng lại rất nhiều code của dev và các công việc khác.

Ví dụ, một ứng dụng có thể dùng Kotlin/JVM cho back-end và Kotlin/JS cho front-end.

Điều này mang đến một số lợi ích: ngoài cú pháp, nó còn cho phép chia sẻ library và paradigm (chẳng hạn như sử dụng coroutines), trên cả front-end và back-end.

Sử dụng Kotlin cũng giúp viết các lớp và hàm có thể được sử dụng cho cả JVM và JS.

Ta còn có thể sử dụng KMM (Kotlin Multiplatform Mobile) để tạo một ứng dụng di động hoạt động trên cả iOS và Android!

Phát triển ứng dụng hoàn chỉnh mà chỉ sử dụng 1 ngôn ngữ lập trình — *Ta hoàn toàn có thể phát triển một ứng dụng hoàn chỉnh chỉ sử dụng một ngôn ngữ lập trình. Nguồn ảnh: Freepik*

3. Công nghệ Low-Code/No-Code

Lập trình low-code cho phép doanh nghiệp nhanh chóng xây dựng và triển khai các ứng dụng phần mềm mà không cần đến một lập trình viên chuyên nghiệp.

Thay vì viết từng dòng code cho một ứng dụng nhất định, người dùng của nền tảng low code hoặc no code có thể xây dựng các dự án bằng giao diện point-and-click.

Bằng cách này, doanh nghiệp có thể tạo website từ các building block được lập trình sẵn, thiết lập trao đổi dữ liệu với các giải pháp CRM, bổ sung tính năng thanh toán trực tuyến qua Stripe và thậm chí thu thập phản hồi của khách hàng qua Google Forms hoặc một nhà cung cấp khác.

Công nghệ Low Code / No Code — *Các doanh nghiệp có thể tiết kiệm thời gian và nguồn lực với công nghệ low code/no code. Ảnh: Rawpixel*

Gartner dự đoán rằng hơn một nửa số doanh nghiệp vừa đến lớn sẽ áp dụng các nền tảng ứng dụng low-code trong vòng hai năm tới.

Các công cụ như Salesforce Flow Builder giúp người dùng tạo quy trình làm việc kỹ thuật số từ đầu đến cuối.

Công cụ này cũng tự động hóa các quy trình.

Nó có các thành phần và dịch vụ để người dùng lựa chọn và sử dụng lại.

Cộng đồng các nhà phát triển ứng dụng của Salesforce Flow Builder là một cộng đồng lớn, được hỗ trợ tích cực.

4. Sự thống trị của Native App

Trước xu hướng cross-platform và sự nổi lên của Flutter hiện nay, sẽ thật lạ khi tôi đưa ra dự đoán trên; nhưng quả thực, khi nói đến việc cung cấp trải nghiệm người dùng tốt hơn và hiệu suất mạnh mẽ hơn, bạn phải sử dụng native app.

Ngày càng có nhiều doanh nghiệp đầu tư vào các ứng dụng gốc cho iOS và Android để mang đến cho người dùng trải nghiệm xuất sắc.

Tuy nhiên, tôi thực sự cảm thấy rằng Flutter có một tương lai rất hứa hẹn. Flutter đã có cú chạy đà tốt và kết quả rất khả quan.

Tham khảo thêm bài so sánh chuyên sâu về Flutter và các ứng dụng gốc tại đây.

Nếu là dev về native app và chịu khó học thêm về Flutter thì bạn sẽ càng có nhiều lợi thế.

Với sự thống trị ngày càng tăng của hệ điều hành iOS và Android trên thị trường, việc đầu tư vào phát triển ứng dụng dường như khó mà suy giảm.

5. AI và ML

Artificial Intelligence – trí tuệ nhân tạo và Machine Learning – học máy đã trở thành tâm điểm nóng trong một thời gian dài – và sẽ tiếp tục như vậy vì rất nhiều tiềm năng khả thi chúng mang lại.

AI và Machine Learning — *Tiềm năng vô hạn từ Artificial Intelligence và Machine Learning. Nguồn ảnh: Alex Knight – Unsplash*

Chúng ta chỉ mới bắt đầu khám phá các khả năng đó mà thôi.

Ví dụ, ta đang hướng tới một tương lai với xe hơi không người lái, hay sử dụng drone không người lái để giám sát tình hình giãn cách xã hội trong thời kỳ đại dịch.

Klarna, một trong những start-up kỳ lân lớn nhất châu Âu, đã sử dụng AI và ML để cá nhân hóa trải nghiệm thanh toán cho khách hàng.

Các công cụ và nền tảng AI đã sẵn sàng để giúp các doanh nghiệp nắm bắt cách khách hàng của mình đang thích ứng ra sao với thực tại mới hậu đại dịch.

“Nghiên cứu AI mới nhất của chúng tôi cho thấy 86% doanh nghiệp hiện đang gặt hái được những lợi ích từ trải nghiệm khách hàng tốt hơn thông qua AI và 25% doanh nghiệp áp dụng AI sẽ có doanh thu tăng trong năm 2021 nhờ vào công nghệ này. Đại dịch COVID-19 đã hé mở những giá trị của AI, hoàn toàn phù hợp với việc cải thiện các nhiệm vụ liên quan đến lập kế hoạch nguồn nhân lực, lập mô phỏng và dự báo nhu cầu.”
– Rohan Amin, CIO của Chase

Trong năm 2021 này, khả năng bổ sung các năng lực AI tiên tiến vào các dự án và quy trình kinh doanh sẽ là cực kỳ quan trọng đối với các doanh nghiệp, đặc biệt với doanh nghiệp mong muốn đạt được những bước tiến đột phá trong ngành.

Tham khảo:

Theo Manish Jain

Tags #2021, Gambaru, Programming, Software Development, Tech Industry, Tech Trends

Dev's Corner

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

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

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

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

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

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

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

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

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

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

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

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

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

Pseudocode

Java code

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

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

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

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

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

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

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

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

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

Giải thuật

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

Pseudocode

Java code

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

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

Theo Pulsara Sandeepa

Tags Algorithms, Gambaru, Java, Problem Solving, Programming, Searching Algorithms

Dev's Corner

20 năm Tuyên ngôn Agile

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

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

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

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

Tuyên ngôn Agile

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

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

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

12 Nguyên tắc Agile

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

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

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

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

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

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

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

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

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

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

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

Tương lai của Agile

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

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

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

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

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

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

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

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

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

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

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

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

Theo Agilemanifesto.org & Rakia Ben Sassi

Tags Agile Manifesto, Agile Software Development, Business Agility, Gambaru, Programming, Software Development

Dev's Corner

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

Post author By Gambaru
Post date 5 February, 2021
No Comments on 8 Extension Visual Studio Code mọi developer phải có

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

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

8 Extension Visual Studio Code

1. Turbo Console Log

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

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

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

Chọn biến là chủ đề debug
Nhấn Ctrl + Alt + L

2. Import cost

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

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

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

3. Prettier

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

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

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

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

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

4. Bracket pair colorizer

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

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

5. Live share

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

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

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

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

6. Projects

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

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

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

7. Settings Sync

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

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

8. JavaScript (ES6) Code Snippets

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

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

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

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

Theo Ali Haider

Tags Coding, extension visual studio code, Gambaru, JavaScript, Programming, Software Development, visual studio code, Web Development

Gambaru News

Tổng kết 2020: Nhìn lại thế giới lập trình web và ứng dụng

Post author By Gambaru
Post date 25 December, 2020
No Comments on Tổng kết 2020: Nhìn lại thế giới lập trình web và ứng dụng

Rất nhiều điều đã diễn ra trong năm 2020. Ảnh: Sigmund - Unsplash

2020 là một năm khó khăn và đầy biến động. Nhưng khi nói đến thế giới lập trình, chúng ta vẫn có những bản phát hành chính từ những gã khổng lồ công nghệ, những đột phá công nghệ vẫn diễn ra phục vụ cho lập trình viên và người dùng.

Hãy cùng Gambaru nhìn lại lĩnh vực lập trình web và ứng dụng suốt năm 2020 qua bản tổng kết sau. Liệu bạn có bỏ lỡ bất kỳ điều quan trọng nào trong số các bản phát hành này không?

Thế giới lập trình web và ứng dụng qua từng tháng

Tháng 1

Next.js 9.2

Next.js 9.2 được phát hành vào ngày 16 tháng 1. Bản phát hành chính ra mắt vào tháng 1, 2020 và đội ngũ Next tiếp tục phát hành một số bản cập nhật trong suốt các tháng tiếp theo của năm.

Tháng 2

Angular 9

Angular 9 được phát hành vào ngày 6 tháng 2.

Đây là bản đầu tiên trong số các phiên bản nâng cấp lớn của Angular trong năm 2020.

Ionic 5.0

Ionic 5.0 được phát hành vào ngày 11 tháng 2.

Ionic đã phát hành bản phát hành phiên bản chính đầu tiên có tên Magnesium vào tháng 2, với các bản cập nhật cho iOS 13 và các API hoàn toàn mới.

TypeScript 3.8

Cũng trong năm 2020, TypeScript 3.8 được phát hành vào ngày 20 tháng 2.

Sau khi phát hành Angular 9, đội ngũ TypeScript đã cho ra mắt phiên bản tiếp theo: Typescript 3.8.

Tháng 3

React Native v0.62

React Native v0.62 được phát hành vào ngày 26 tháng 3.

Đây là bản phát hành đầu tiên của đội ngũ React Native dành cho năm 2020.

Tháng 4

Node.js v14

Node.js v14 được phát hành vào ngày 21 tháng 4.

Node cực kỳ hữu ích cho cả nền tảng web và di động, và phiên bản thứ 14 đã được phát hành vào tháng 4 năm nay.

Tháng 5

Flutter 1.17

Flutter 1.17 được phát hành vào ngày 6 tháng 5.

Bản phát hành này bao gồm hỗ trợ Metal để đạt được hiệu suất iOS nhanh hơn và các thành phần Material mới.

TypeScript 3.9

TypeScript 3.9 được phát hành vào ngày 12 tháng 5.

Đội ngũ TypeScript đã ra mắt bản phát hành chính thứ hai, Typecript 3.9, vào tháng 5.

Electron.js 9.0

Electron.js 9.0 được phát hành vào ngày 19 tháng 5.

Bản phát hành này bao gồm các phiên bản nâng cấp lên Chromium 83, V8 8.3 và Node 12.14.

*Những phiên bản cập nhật quan trọng được ra mắt ở nửa đầu 2020. Ảnh: Joshua Aragon – Unsplash*

Tháng 6

Angular 10

Angular 10 được phát hành vào ngày 24 tháng 6.

Đây là lần nâng cấp phiên bản lớn thứ hai của Angular trong năm 2020.

Tháng 7

React Native v0.63

React Native v0.63 được phát hành vào ngày 9 tháng 7.

Đây là bản phát hành thứ hai của đội ngũ React Native trong năm nay.

Ember 3.20

Ember 3.20 được phát hành vào ngày 29 tháng 7.

Ember đã phát hành một số phiên bản trong nửa đầu năm như 3,16, 3,17, 3,18 và 3,19. Nhưng bản 3.20 mang đến một số thay đổi quan trọng và đó là lý do tại sao nó xứng đáng có mặt trong danh sách này.

Tháng 8

Flutter 1.20

Flutter 1.20 được phát hành vào ngày 5 tháng 8.

Bản phát hành này bao gồm các cải tiến về hiệu suất và nhiều tiện ích thú vị.

TypeScript 4.0

TypeScript 4.0 được phát hành vào ngày 18 tháng 8.

Đây là bản phát hành TypeScript thứ ba vào năm 2020 và có một số thay đổi lớn trong bản phát hành này.

Electron 10.0

Electron 10.0 được phát hành vào ngày 25 tháng 8.

Bản phát hành này bao gồm các phiên bản nâng cấp lên Chromium 85, V8 8.5 và Node 12.16.

Tháng 9

Vue 3 được phát hành vào ngày 18 tháng 9.

Sau gần một năm rưỡi, Vue.js đã đưa ra phiên bản mới nhất của mình, có tên One Piece.

Tháng 10

Flutter 1.22

Flutter 1.22 được phát hành vào ngày 1 tháng 10.

Bản phát hành này bao gồm hỗ trợ cho cả iOS 14 và Android 11.

React 17

React 17 được phát hành vào ngày 20 tháng 10

Mặc dù có một vài bản phát hành của React trong khoảng thời gian đầu năm 2020, nhưng React 17 là bản phát hành chính mà tất cả chúng ta đều chờ đợi, và bất ngờ rằng không có tính năng mới nào trong phiên bản ra mắt này.

Node v15

Node v15 được phát hành vào ngày 20 tháng 10.

Sau bản phát hành v14, đội ngũ Node đã đưa ra bản phát hành thứ hai trong năm với tên gọi v15 vào tháng 10.

Next.js 10

Next.js 10 được phát hành vào ngày 27 tháng 10.

Kể từ tháng 1, Next đã phát hành các phiên bản mới, nhưng sự thay đổi thực sự đến vào tháng 10 với Next.js 10.

Tháng 11

Angular 11

Angular 11 được phát hành vào ngày 11 tháng 11.

Không giống như những năm khác, Angular đã trở lại với một bản phát hành lớn khác, Angular 11. Có lẽ các bản phát hành React và Vue là nguyên nhân chính thôi thúc nên phiên bản này.

TypeScript 4.1

TypeScript 4.1 được phát hành vào ngày 17 tháng 11.

Chỉ sau hai tháng tạm nghỉ, TypeScript đã phát hành bản phát hành chính cuối cùng của họ vào năm 2020.

Electron 11.0

Electron 11.0 được phát hành vào ngày 17 tháng 11.

Bản phát hành này bao gồm các nâng cấp lên Chromium 87, V8 8.7 và Node 12.18.3.

Theo Chameera Dulanga

Tags 2020, App Development, Gambaru, Programming, Web Development

Dev's Corner

Sự khác biệt giữa Junior, Mid-Level và Senior Developer

Post author By Gambaru
Post date 10 July, 2020
No Comments on Sự khác biệt giữa Junior, Mid-Level và Senior Developer

Sự khác nhau giữa Junior, Mid-level và Senior developer. Ảnh: Soumil Kumar - Pexels

Ở bài viết trước, Gambaru đã cùng các bạn tìm hiểu về vị trí Senior Software Developer.

Hôm nay, mời mọi người theo dõi góc nhìn của Daan, một back-end developer từ Hà Lan về:

Sự khác nhau giữa Junior, Mid-Level và Senior Developer

Số năm kinh nghiệm lập trình không đủ để xác định được ai là một Junior, Mid-level hoặc Senior Developer.

Tôi nghĩ điều quan trọng ở đây là kỹ năng.

Một Senior Developer chẳng phải là chuyên gia về mọi thứ, nhưng ta hoàn toàn có thể nói rằng Senior Developer có kỹ năng thành thục hơn Junior và Mid-level Developer.

Kiến thức

Senior Developer sở hữu lượng kiến thức lớn hơn nhiều so với Mid-level và Junior Developer.

Junior Developer cần mở mang hiểu biết về design pattern, architecture, automating testing, performance, security… mới thu hẹp được khoảng cách kiến thức với Mid-level và Senior Developer.

Đúng là rất quan trọng để biết mọi thứ trong quá trình phát triển phần mềm nên thực hiện như thế nào, nhưng chỉ biết những điều này chưa đủ để bạn trở thành một Senior Developer.

*Kiến thức là một trong những yếu tố cho thấy sự khác biệt lớn nhất giữa các dev, nhưng nó chưa phải là tất cả. Ảnh: NeONBRAND – Unsplash*

Coding

Trái với suy nghĩ của hầu hết mọi người, coding không phải là vấn đề về việc giao tiếp với máy tính.

Coding là việc giao tiếp với con người và hướng dẫn máy tính. Suy cho cùng, code được tổng hợp và biên dịch thành giá trị 0 và 1.

Code phải có ý nghĩa đối với những dev khác làm việc với nó trong tương lai.

Một team mới chưa bao giờ tiếp xúc với đoạn code vẫn có thể mở được nó và tiến hành làm việc với các tính năng mới hoặc fix bug.

Đây là nơi có thể thấy sự khác biệt lớn giữa Junior Developer và Senior Developer.

Tôi sẽ không nói về Mid-level Developer trong đoạn so sánh tiếp theo vì Mid-level Developer là một khu vực xám khi nói đến kỹ năng coding.

Phân biệt Junior Developer?

Junior Developer ít kinh nghiệm, một số vừa tốt nghiệp và lần đầu tiên đi làm.

Một Junior Developer thường chỉ nghĩ là phải làm cho code chạy được. Theo họ, phần mềm chạy được và phần mềm tốt là như nhau.

Viết được code tường minh không đơn giản và Junior Dev thường viết code rườm rà.

Bạn có thể nhận ra Junior Developer vì họ hay viết tất cả mọi thứ trên một dòng hoặc những lớp abstract phức tạp quá mức.

Đây là cách một Junior Developer thể hiện cho các dev khác biết họ có thể viết code tốt như thế nào. Và điều này là sai lầm.

Senior Developer thì sao?

Khi nhìn vào code của một Senior Developer, bạn có thể nghĩ: đây có phải là tất cả không?

Phần code còn lại đâu rồi? Một Senior Developer viết code đơn giản, dễ hiểu và thậm chí có thể là ngớ ngẩn.

Đây là một trong những phẩm chất làm lập trình lớn nhất một developer có.

Senior Developer tuân theo nguyên tắc KISS (Keep It Simple, Stupid).

*Làm đơn giản thôi, ngốc ạ. Ảnh: Myburgh Roux – Pexels*

Senior Developer viết code và cân nhắc về khả năng code maintain được và mở rộng được.

Đây là một tư duy hoàn toàn khác so với Junior Developer – Senior nghĩ về những người phải làm việc với code, còn Junior chỉ nghĩ về việc làm cho nó hoạt động trên máy tính.

Không chỉ là kỹ năng lập trình

Nói chung, Junior Developer thực hiện các task hoặc task đơn giản nhất với độ ảnh hưởng thấp. Họ không thực hiện việc thiết kế kiến trúc hệ thống.

Mid-level Developer cũng không tạo ra solution, họ chỉ thực hiện task.

Sự khác biệt với Junior Developer là họ thực hiện task đó với ít sự giám sát hơn miễn là họ được giao cho các task có tính ổn định tương đối.

Senior Developer thì có thể hoàn toàn tự mình phát triển một ứng dụng.

Điều này không có nghĩa là Senior Developer không có bất kỳ câu hỏi nào trong quá trình làm việc.

Senior Developer biết cách đặt câu hỏi đúng và cách xử lý những câu hỏi này.

Mid-level Developer có thể đặt câu hỏi đúng liên quan đến các task họ thường xuyên làm, nhưng cần hỗ trợ ở những task phức tạp hơn.

Senior Developer không hoang mang và biết cách theo dõi những câu hỏi đặt ra với hành động hợp lý.

Senior Developer vẫn luôn nhờ sự giúp đỡ từ các dev khác vì đôi khi cách tốt nhất là chỉ cần nhờ dev có kinh nghiệm trong lĩnh vực đó giúp đỡ.

Mid-level Developer cũng có thể hỏi đúng câu hỏi, miễn là họ không được giao những task có độ phức tạp cao, đòi hỏi kiến thức chuyên sâu.

Ta không nên mong đợi một Junior Developer sẽ làm được điều này vì họ thiếu kinh nghiệm và cần hướng dẫn từ một dev có kinh nghiệm hơn, cần những nguồn lực cần thiết hoặc một sự thúc đẩy mạnh mẽ để đi đúng hướng.

Nâng cấp từ Junior lên Senior Developer

Tất cả chúng ta đều muốn cải thiện bản thân và trở thành một developer hoàn thiện hơn. Các bước cần thực hiện để đạt đến cấp độ tiếp theo là gì? Ảnh: Jerry Zhang – Unsplash

Junior lên Mid-level

Vì các Junior Developer đều thiếu kinh nghiệm, nên điều quan trọng là phải tự mình trải qua toàn bộ chu trình lập trình ít nhất một vài lần.

Bằng cách này, bạn sẽ mắc nhiều sai lầm và học cách tránh lặp lại chúng vào lần tiếp theo.

Bạn nên học cách viết code đơn giản. Hãy nghĩ về người tiếp theo sẽ làm việc với code đó.

Bạn cũng nên tìm hiểu cách debug vì điều này sẽ giúp ta hiểu rõ hơn về những gì xảy ra trong quá trình lập trình.

Ngoài ra, bạn nên làm quen với những thực tiễn tốt nhất và tìm hiểu về architecture, performance, security v.v. Mục tiêu là thu hẹp khoảng cách kiến thức cần có để đạt đến mid-level.

Mid-level đến Senior

Đi từ Mid-level đến Senior là một chặng đường khá khó khăn. Một số dev sẽ chỉ ở mức Mid-level trong suốt sự nghiệp của mình.

Senior Developer biết khi nào cần đi đường tắt và khi nào thì không.

Đây là những bài học khó nhằn chỉ học được bằng cách mắc sai lầm trong quá khứ.

Nếu muốn lên Senior Level, bạn phải sẵn sàng nhận những task mà không ai biết cách xử lý và nên biết nhiều hơn ngoài việc làm thế nào để hoàn thành công việc.

Là một Senior Developer, bạn cũng có công việc hỗ trợ các dev ít kinh nghiệm hơn.

Và bạn sẽ chẳng ngạc nhiên khi tôi nói rằng Senior Developer làm chủ được công nghệ của mình.

Bên cạnh kỹ năng coding, họ biết tất cả các công cụ và ứng dụng đang được sử dụng trong công ty mình đang làm.

Tôi xin kết bài bằng một câu nói từ Martin Fowler:

Bất kỳ kẻ ngốc nào cũng có thể viết code sao cho máy tính hiểu được. Lập trình viên giỏi viết code con người có thể hiểu được.

Theo Daan

Tags Coder, Coding, Developer, Gambaru, Junior Developer, Mid-level Developer, Programmer, Programming, Senior Developer, Senior Software Engineer, Skills, Software Development, Software Engineer