Tag: Software Engineer

Categories
Dev's Corner

Principal Software Engineer, đỉnh cao của sự xuất sắc về kỹ thuật và khả năng lãnh đạo

Principal Software Engineer
Principal Software Engineer

Principal Software Engineer là một trong những cấp độ cao nhất mà một software engineer (kỹ sư phần mềm) có thể đạt được. Họ phát triển đội ngũ, đồng thời giám sát các bộ phận kỹ thuật trong các dự án phát triển phần mềm của công ty. 

Trong bài viết này, chúng ta sẽ thảo luận về việc trở thành một Principal Software Engineer, cũng như làm rõ trách nhiệm và trình độ của họ. 

Principal Software Engineer là gì?

Principal Software Engineer là một vai trò cấp cao trong lĩnh vực công nghệ phần mềm (software engineering).

Các cá nhân trong vai trò này thường có nhiều kinh nghiệm và chuyên môn về phát triển, kiến trúc và thiết kế phần mềm.

Họ đóng vai trò quan trọng trong việc lãnh đạo và hướng dẫn chỉ đạo kỹ thuật của một dự án hoặc một nhóm kỹ sư.

Principal software engineer là gì?
Principal software engineer là gì?

Nhiều người cho rằng sự khác biệt duy nhất giữa Software engineer, Software architect và Principal software engineer là về ngữ nghĩa.

Trong các công ty nhỏ với ngân sách eo hẹp, một người có thể đội hết những chiếc mũ này. Tuy nhiên, đối với các công ty lớn hơn, thì sự phân biệt thường rõ ràng.

Các cấp độ như sau:

  • Cấp 1: Software Engineer
  • Cấp 2: Senior Software Engineer
  • Cấp 3: Staff Engineer
  • Cấp 4: Principal Software Engineer
  • Cấp 5: Distinguish Engineer hoặc Fellow

Như bạn có thể thấy, principal software engineer có trình độ cao hơn senior engineer. Họ tập trung nhiều hơn vào công ty nói chung. Các senior engineer và các chuyên gia công nghệ khác hướng nỗ lực của họ vào việc cung cấp giải pháp cho một vấn đề hiện có.

Còn các principal software engineer tập trung phát triển các giải pháp hỗ trợ công ty. Họ chịu trách nhiệm phát triển đội ngũ và các khía cạnh kỹ thuật của các dự án công nghệ phần mềm. Nói tóm lại, nhiệm vụ của họ nặng về quản lý đội nhóm và quyết định phương hướng kỹ thuật của công ty.

Vai trò và trách nhiệm của Principal software engineer

Trách nhiệm của Principal software engineer thường bao gồm:

Vai trò & Trách nhiệm của Principal software engineer
Vai trò & Trách nhiệm của Principal software engineer
  • Lãnh đạo kỹ thuật: Họ cung cấp khả năng lãnh đạo và hướng dẫn kỹ thuật cho các kỹ sư khác trong nhóm, thiết lập định hướng kỹ thuật tổng thể, xác định các phương pháp hay nhất và đảm bảo rằng nhóm tuân theo các tiêu chuẩn và hướng dẫn của ngành.
  • Thiết kế kiến trúc: principal software engineer tham gia thiết kế kiến trúc của các hệ thống phần mềm phức tạp. Họ đưa ra quyết định thiết kế tổng thể, chọn công nghệ và khuôn khổ phù hợp, đồng thời đảm bảo rằng kiến trúc phần mềm phù hợp với mục tiêu của dự án.
  • Đánh giá code và đảm bảo chất lượng: Họ đánh giá code do các thành viên khác trong nhóm gửi để đảm bảo chất lượng code, tuân thủ các tiêu chuẩn code và các thực hành tốt nhất. Họ giúp xác định các vấn đề tiềm ẩn, đề xuất cải tiến và cố vấn cho các kỹ sư cấp dưới.
  • Giải quyết vấn đề: principal software engineer thường giải quyết các vấn đề kỹ thuật thách thức nhất phát sinh trong quá trình phát triển dự án. Họ sử dụng sự hiểu biết sâu sắc về hệ thống phần mềm để khắc phục sự cố, tối ưu hóa hiệu suất và đưa ra các quyết định quan trọng.
  • Đổi mới và nghiên cứu: Họ luôn cập nhật những tiến bộ mới nhất trong phát triển phần mềm, công cụ và kỹ thuật. Họ cũng có thể tham gia vào các hoạt động nghiên cứu và phát triển để khám phá các công nghệ mới có thể mang lại lợi ích cho dự án hoặc công ty.
  • Hợp tác: principal software engineer làm việc chặt chẽ với product manager, designer và các bên liên quan khác để hiểu các yêu cầu và chuyển chúng thành các giải pháp kỹ thuật. Họ truyền đạt các khái niệm kỹ thuật phức tạp cho các thành viên nhóm không chuyên về kỹ thuật một cách hiệu quả.
  • Cố vấn và Huấn luyện: Họ cố vấn và huấn luyện các kỹ sư cấp cơ sở và cấp trung, giúp họ phát triển trong sự nghiệp và cải thiện kỹ năng kỹ thuật. Điều này bao gồm việc cung cấp hướng dẫn về thực hành mã hóa, kiến trúc và phát triển nghề nghiệp.
  • Ra quyết định: principal software engineer tham gia vào việc đưa ra các quyết định quan trọng về lựa chọn công nghệ, đánh đổi và ưu tiên dự án. Họ xem xét các yếu tố như khả năng mở rộng, khả năng bảo trì và hiệu suất khi đưa ra những quyết định này.
  • Bảo trì cơ sở mã: Họ có thể nắm quyền sở hữu các phần quan trọng của cơ sở mã, đảm bảo rằng chúng được duy trì, cập nhật và cải thiện tốt theo thời gian. Điều này giúp ngăn ngừa nợ kỹ thuật và đảm bảo tính ổn định lâu dài của phần mềm.

Principal software engineer thường được phân biệt với Senior software enigneer bởi phạm vi trách nhiệm rộng hơn, chuyên môn kỹ thuật sâu hơn và ảnh hưởng lớn hơn đến định hướng kỹ thuật của công ty hoặc dự án. Trách nhiệm và kỳ vọng chính xác có thể khác nhau giữa các công ty, nhưng vai trò này luôn liên quan đến sự kết hợp giữa lãnh đạo kỹ thuật, kiến trúc và cố vấn.

Dưới đây là một số nhiệm vụ mà họ thực hiện hàng ngày:

  • Phát triển và cung cấp các tiêu chuẩn, hướng dẫn kỹ thuật trong mọi hoạt động thiết kế và phát triển phần mềm
  • Hỗ trợ và tạo điều kiện bảo trì và nâng cấp các ứng dụng phần mềm hiện có
  • Cung cấp đánh giá thiết kế và đưa ra khuyến nghị kỹ thuật
  • Hỗ trợ toàn bộ vòng đời phát triển phần mềm (SDLC, software development life cycle)
  • Đảm bảo mọi dự án đều có chất lượng cao
  • Cố vấn và đào tạo kỹ sư phần mềm
  • Hỗ trợ phân tích và khắc phục sự cố của ứng dụng
  • Tạo ra các giải pháp kỹ thuật hiệu quả và có thể áp dụng, phù hợp với nhu cầu và yêu cầu kinh doanh
  • Đề xuất các công nghệ mới giúp nâng cao năng suất
  • Làm việc với các nhóm tròn việc lập kế hoạch, sắp xếp ưu tiên và hoàn thành nhiệm vụ dự án
  • Tham gia vào các hoạt động đánh giá rủi ro và giảm thiểu rủi ro
  • Thường xuyên tham dự các cuộc họp để thảo luận về các dự án, vấn đề và ý tưởng
  • Tham gia kiểm toán kỹ thuật và đảm bảo thực hiện các khuyến nghị
  • Thực hiện các bài thuyết trình kinh doanh cho ban quản lý
  • Phối hợp với QA để phát triển các trường hợp thử nghiệm, quy trình và kế hoạch

Kỹ năng và yêu cầu đối với Principal software engineer

Khi tuyển dụng principal software engineer, đây là những kỹ năng và yêu cầu mà các công ty tìm kiếm:

  • Bằng cử nhân về Kỹ thuật/Khoa học Máy tính hoặc các lĩnh vực liên quan
  • Kỹ năng cấp cao về ngôn ngữ lập trình (Java, JavaScript, v.v.)
  • Có kinh nghiệm về các phương pháp phát triển phần mềm khác nhau
  • Có kinh nghiệm phát triển và bảo trì các hệ thống web phức tạp
  • Hiểu biết cao về cả mặt phụ trợ và mặt trước của quá trình phát triển phần mềm
  • Kiến thức chuyên sâu về các công nghệ và công cụ phát triển phần mềm khác nhau
  • Kỹ năng phân tích xuất sắc
  • Kỹ năng giao tiếp tuyệt vời
  • Kỹ năng tổ chức và lập kế hoạch mạnh mẽ
  • Kỹ năng lãnh đạo và cố vấn đặc biệt

Ngoài ra, họ phải có kỹ năng lãnh đạo và tổ chức tốt vì họ sẽ dành nhiều thời gian làm nhiệm vụ quản lý hơn là nhiệm vụ kỹ thuật.

Mức lương dành cho Principal Software Engineer ở Mỹ

Mức lương cho Principal Software Engineer ở Mỹ có thể rất khác nhau tùy thuộc vào các yếu tố như vị trí, quy mô công ty, ngành, số năm kinh nghiệm và kỹ năng cá nhân. 

  • Phạm vi thấp nhất: 120.000 USD – 150.000 USD mỗi năm
  • Hạng trung: 150.000 USD – 200.000 USD mỗi năm
  • Phạm vi cao: $200,000 – $250,000+ mỗi năm

Hãy nhớ rằng những con số này là gần đúng và có thể thay đổi đáng kể. Tại các trung tâm công nghệ lớn như San Francisco, New York và Seattle, mức lương có xu hướng cao hơn do chi phí sinh hoạt và nhu cầu về nhân tài kỹ thuật cao hơn. Ngoài ra, các công ty công nghệ có uy tín và các tổ chức lớn hơn có thể đưa ra mức lương cao hơn so với các công ty khởi nghiệp nhỏ hơn.

Ngoài ra, do ngành công nghệ phát triển nhanh chóng nên mức lương có thể thay đổi theo thời gian. Để có thông tin chính xác và cập nhật nhất, tốt nhất bạn nên tham khảo bảng việc làm, trang web nghiên cứu về lương hoặc báo cáo ngành cụ thể cho vị trí của bạn và năm hiện tại.

Câu hỏi phỏng vấn dành cho Principal Software Engineer

  • Bạn đã phát triển những loại phần mềm nào trước đây?
  • Theo bạn, những nguyên tắc nào tốt cho việc phát triển phần mềm?
  • Giải thích kiến trúc được sử dụng trong công việc trước đây của bạn. Lý do cho những lựa chọn này là gì?
  • Bạn làm cách nào để thiết kế các ứng dụng có thể mở rộng? Bạn có thể hướng dẫn chúng tôi qua quy trình của bạn không?
  • Bạn sẽ coi ngôn ngữ lập trình nào là ngôn ngữ lập trình hàng đầu của mình? Tại sao?
  • Bạn có thích đào tạo và cố vấn cho các kỹ sư phần mềm khác không?
  • Khi xem lại code của các thành viên trong nhóm, bạn thường xem hoặc kiểm tra những gì?
  • Kinh nghiệm làm việc phức tạp nhất mà bạn có là gì? Bạn đã giải quyết tình huống này như thế nào?
  • Kỹ sư nguyên tắc giỏi cần có những phẩm chất gì?
  • Bạn có thể giúp cải thiện nhóm phát triển phần mềm của chúng tôi như thế nào?

Gamba tổng hợp.

Categories
Events past

TE#18: NAVIGATING YOUR SOFTWARE ENGINEERING CAREER

INSIGHTS FROM A 10-YEAR JOURNEY FROM AN EX-META ENGINEER

I. Introduction

  • Brief introduction of the speaker and his background
  • Overview of the talk objectives and topics that will be covered

II. Finding Your First Software Engineering Job (10 mins)

  • Identifying your skills and passions
  • Tips for creating an impressive resume and portfolio
  • Navigating the interview process

III. Starting Your First Job (10 mins)

  • How to make a good impression as a new hire
  • Tips for effective communication with team members and managers
  • Understanding the company culture and values

IV. Mastering Your Craft (20 mins)

  • Continuous learning and skill development
  • Strategies for tackling complex technical challenges
  • The importance of collaboration and mentorship

V. Moving Up the Career Ladder (20 mins)

  • Setting goals and creating a plan for career growth
  • Building a professional network and personal brand
  • Navigating performance reviews and promotions

VI. Navigating Transitions in Your Career (10 mins)

  • Knowing when it’s time to move on from a job
  • Tips for successfully transitioning to a new role or company
  • Balancing career aspirations with personal and family responsibilities

VII. Reflections on a 10-Year Career Journey (10 mins)

  • Key takeaways and lessons learned
  • Advice for junior software engineers based on experience and observations

VIII. Conclusion (5 mins)

  • Recap of the main points covered in the talk
  • Final thoughts and advice for junior software engineers
  • Encouragement to continue learning, growing, and pursuing their career goals.

Join Gamba’s community to learn more from the experts: https://t.me/gambadev.

Categories
Events past

TE#12: Clean Code In Practices

As an engineer, you definitely know that your code should be “clean”, but what does that actually look like? 

Key principles in clean code are KISS, which stands for Keep It Simple, Stupid, and DRY, Don’t Repeat Yourself. Ask yourself if there is a better solution for solving problems or complexity within your code. Because Clean code won’t write itself, it takes dedicated focus on putting forward what you mean to convey.

Next week, let’s walk this through with Mr. Tu Pham – Head of Engineering at ZaloPay – who has many years of experience (well, in coding of course). We guarantee this essential skill is a must-have for your career!

Categories
Dev's Corner

Kỹ thuật phần mềm là gì? Học Software Engineering như thế nào?

Kỹ thuật phần mềm - Software Engineering là gì?
Kỹ thuật phần mềm - Software Engineering là gì?

Kỹ thuật phần mềm (Software Engineering) liên quan đến việc phát triển và bảo trì tất cả phần mềm chúng ta sử dụng hàng ngày, từ các công cụ năng suất (productivity tool) đến trình duyệt web.

Nhu cầu đối với developer trên thế giới là rất lớn, vì nhiều lĩnh vực kinh doanh tiếp tục phụ thuộc lớn vào công nghệ. Do đó, các kỹ sư phần mềm (software engineer) kiếm được một mức lương ấn tượng và có triển vọng việc làm mạnh mẽ.

Bài viết này sẽ nói về cách trở thành kỹ sư phần mềm, cung cấp cho bạn thông tin cần thiết để quyết định xem nghề nghiệp này có phù hợp với bạn hay không.

Kỹ thuật phần mềm là gì (Software Engineering)?

Kỹ thuật phần mềm (software engineering) là việc áp dụng các khái niệm kỹ thuật vào phát triển phần mềm. Mục tiêu chính của nó là tạo ra, cải tiến và bảo trì phần mềm.

Kỹ thuật phần mềm tính đến các khía cạnh kỹ thuật như môi trường phần cứng và phần mềm khi làm việc trên một chương trình.

Một ngày của Kỹ sư phần mềm (Software Engineer)Một ngày của Kỹ sư phần mềm (Software Engineer)
Một ngày của Kỹ sư phần mềm (Software Engineer). Ảnh: careerkarma.com

Dù mô tả công việc của kỹ sư phần mềm thường trùng lặp nhiều với nhà phát triển phần mềm (software developer), nhưng kỹ sư phần mềm (software engineer) và nhà phát triển phần mềm (software developer) lại không giống nhau.

Sự khác biệt chính là các kỹ sư phần mềm áp dụng các khái niệm và nguyên tắc kỹ thuật khi phát triển phần mềm.

Phạm vi làm việc của kỹ sư không giới hạn ở việc viết code và họ còn làm việc cả trên môi trường mà chương trình sẽ hoạt động.

Kỹ sư phần mềm (Software Engineer) làm gì?

Kỹ sư phần mềm sẽ tạo, duy trì và quản lý nhiều loại ứng dụng phần mềm khác nhau. Dưới đây là một số nhiệm vụ của kỹ sư phần mềm.

  • Cập nhật các chương trình: Kỹ sư phần mềm đảm bảo chương trình chạy trơn tru qua các bản cập nhật và sửa lỗi.
  • Tạo chương trình mới: Kỹ sư phần mềm thiết kế và tạo ra chương trình mới cho người dùng.
  • Phân tích: Kỹ sư phần mềm xem xét các nhu cầu của tổ chức và tạo ra phần mềm để đáp ứng các nhu cầu đó.
  • Theo dõi quá trình phát triển phần mềm: Việc tạo phần mềm thường liên quan đến công việc của nhiều nhóm. Các kỹ sư phần mềm theo dõi mã nội bộ và đảm bảo ứng dụng đáp ứng nhu cầu của người dùng.

Phạm vi nhiệm vụ của kỹ thuật phần mềm sẽ tùy vào tổ chức và quy mô của nhóm phát triển.

Trách nhiệm của kỹ sư phần mềm có thể bao gồm thiết kế, phát triển và bảo trì toàn bộ sản phẩm. Chúng cũng có thể chỉ đơn giản là giúp cấu trúc code của một ứng dụng trong các nhóm lớn hơn.

Thông thường, các kỹ sư phần mềm sẽ phải làm việc với nhà phát triển (developer), khách hàng và các bên liên quan khác để đáp ứng nhu cầu thiết kế cho sản phẩm của họ.

Một số vai trò kỹ thuật phần mềm bao gồm trí tuệ nhân tạo, trong khi những vai trò khác có thể là quản lý các chương trình ở phía máy chủ.

Dù với vai trò nào, một kỹ sư phần mềm sẽ sử dụng các ngôn ngữ lập trình để viết và duy trì nhằm đáp ứng một nhu cầu nhất định.

Các loại kỹ sư phần mềm

Nếu bạn muốn lấn sân sang lĩnh vực kỹ thuật công nghệ, bước đầu tiên là tìm ra lộ trình sự nghiệp mà bạn muốn nhắm đến. Hãy xem qua một số lộ trình phổ biến đối với kỹ sư phần mềm.

Kỹ sư phần mềm

Kỹ sư phần mềm phát triển phần mềm cho các thiết bị điện tử. Các nhà phát triển này sử dụng các ngôn ngữ lập trình như C ++, Java và Python để tạo các ứng dụng chạy trên máy tính.

Họ làm việc trên cả giao diện người dùng lẫn back-end, liên quan tới những gì người dùng nhìn thấy và cơ chế hoạt động đằng sau của một chương trình.

Kỹ sư hệ thống nhúng (Embedded System Engineer)

Các kỹ sư này chịu trách nhiệm thiết kế, phát triển, thử nghiệm và bảo trì các hệ thống nhúng. Hệ thống nhúng là sự kết hợp phần cứng và phần mềm được thiết kế để thực hiện các nhiệm vụ cụ thể.

Ví dụ, một kỹ sư hệ thống nhúng có thể làm việc trên phần mềm hỗ trợ máy ATM hoặc chương trình điều khiển rô bốt.

Kỹ sư bảo mật (Security Engineer)

Kỹ sư bảo mật chịu trách nhiệm tạo ra các hệ thống, phương pháp và chính sách để đảm bảo hệ thống thông tin đáp ứng các tiêu chuẩn nhất định và không có lỗi bảo mật.

Các kỹ sư bảo mật thường hoạt động như hacker “mũ trắng” và cố gắng đột nhập vào các hệ thống hiện có để xác định xem có vấn đề bảo mật nào tồn tại hay không.

Kỹ sư đảm bảo chất lượng (Quality Assurance)

Các kỹ sư Đảm bảo chất lượng (QA) sẽ viết, xem xét, kiểm tra và bảo trì phần mềm.

Các kỹ sư này chịu trách nhiệm đảm bảo nhóm phát triển viết mã có chất lượng nhất quán. Họ tạo ra các tiêu chuẩn và chính sách để đảm bảo tất cả mã hiệu quả và hoạt động chính xác.

Học Kỹ thuật phần mềm

Có nhiều lộ trình bạn có thể đi theo để trở thành một kỹ sư phần mềm, nhưng phổ biến nhất thường tuân theo các bước sau:

  1. Chọn một lộ trình sự nghiệp kỹ thuật phần mềm.
  2. Tìm hiểu về kỹ thuật phần mềm thông qua bootcamp, tự học hoặc đại học.
  3. Phát triển và tinh chỉnh các kỹ năng kỹ thuật của bạn trong khi xây dựng hồ sơ năng lực của bạn.
  4. Chuẩn bị và bắt đầu tìm kiếm việc làm.

Mất bao lâu để học Kỹ thuật phần mềm?

Có thể mất từ ​​sáu tháng đến bốn năm để học kỹ thuật phần mềm.

Nếu bạn tham gia vào một khóa học hoặc chương trình đào tạo về lập trình, trung bình bạn có thể trở thành một kỹ sư phần mềm trong vòng sáu tháng đến một năm.

Ngoài ra, bạn có thể nhận được một nền giáo dục chính quy về kỹ thuật phần mềm bằng cách theo học bằng cử nhân bốn năm trong lĩnh vực này.

Cách học Kỹ thuật phần mềm: Từng bước

Có ba lộ trình phổ biến để học kỹ thuật phần mềm, đó là:

  1. Theo đuổi bằng khoa học máy tính tại một trường cao đẳng hoặc đại học.
  2. Tham dự khóa đào tạo lập trình chuyên về kỹ thuật phần mềm.
  3. Tìm hiểu kỹ thuật phần mềm thông qua tự học.

Mỗi lộ trình đều có những lợi ích và hạn chế của nó.

Trước đây, chỉ những sinh viên tốt nghiệp đại học mới đủ điều kiện cho các vai trò kỹ sư phần mềm chuyên nghiệp, nhưng điều đó đã thay đổi trong vài năm qua.

Nhiều kỹ sư phần mềm gần đây đã phát triển mạnh trong lĩnh vực này mặc dù đã tự học và không được đào tạo chính quy về lập trình.

Tuy nhiên, có một phương án khác ngày càng phổ biến: Coding bootcamps.

Chương trình đào tạo lập trình cung cấp một giải pháp thay thế khả thi cho giáo dục đại học truyền thống.

Trong chương trình đào tạo này, bạn sẽ học được tất cả các kỹ năng thiết thực mà bạn cần để thành công trong sự nghiệp phát triển phần mềm (software developement).

Ngoài ra, hầu hết các bootcamp đều cung cấp một hệ thống hỗ trợ nghề nghiệp mạnh mẽ cho sinh viên và sinh viên mới tốt nghiệp.

Bạn sẽ làm việc với người cố vấn (mentor) và người hướng dẫn để học các kỹ năng mới và xây dựng porfolio để giới thiệu kỹ năng và khả năng của bạn với các nhà tuyển dụng tiềm năng. Họ thậm chí còn trợ giúp khi bạn tìm kiếm việc làm.

Mức lương của Kỹ sư phần mềm?

Bạn có thể kiếm được bao nhiêu từ nghề Kỹ sư phần mềm
Bạn có thể kiếm được bao nhiêu từ nghề Kỹ sư phần mềm. Ảnh: Glassdoor
$ 188,000$ 120,000$ 50,000
Kỹ sư trình độ SeniorKỹ sư trình độ MiddleKỹ sư trình độ Junior

Khóa học và chương trình đào tạo kỹ thuật phần mềm

Các chương trình đào tạo kỹ sư phần mềm là một giải pháp thay thế khả thi cho giáo dục cao đẳng hoặc đại học. Một trong những loại chương trình phổ biến nhất là dưới dạng bootcamps.

Dưới đây là danh sách một số bootcamps được đánh giá cao nhất và phổ biến nhất trong kỹ thuật phần mềm.

Khóa học kỹ thuật phần mềm trực tuyến

App Academy

App Academy là một trường học lập trình cung cấp cả chương trình đào tạo trực tiếp và trực tuyến.

Không có chi phí học phí cho đến khi bạn được thuê trong vai trò kỹ sư phần mềm và kiếm được hơn 50.000 đô la.

App Academy đã đưa hơn 3.000 người vào các vị trí kỹ sư phần mềm toàn thời gian, thu về mức lương trung bình là 80.000 đô la.

Các cựu sinh viên của chương trình bootcamp làm việc tại hơn 1.000 công ty trên khắp thế giới, chẳng hạn như Twitter, Netflix, Apple và Google.

Flatiron School

Flatiron School cung cấp các chương trình trực tuyến và trực tiếp về kỹ thuật phần mềm.

Sinh viên tham gia vào một chương trình giảng dạy nghiêm ngặt phù hợp với nhu cầu của thị trường. Flatiron School dạy học sinh cách suy nghĩ và làm việc như một kỹ sư phần mềm.

Ứng viên phải nộp đơn đăng ký bằng văn bản nêu rõ lý do đăng ký tham gia chương trình đào tạo. Các em cũng phải học một số kỹ năng cơ bản để đủ điều kiện tham gia các chương trình nhập vai thông qua các khóa học dự bị miễn phí của Flatiron School.

Thinkful

Thinkful là một chương trình đào tạo trực tuyến cung cấp khóa học kéo dài bảy tháng về kỹ thuật phần mềm.

Các khóa học được thực hiện toàn thời gian hoặc bán thời gian.

Suốt chương trình, sinh viên sẽ được kèm cặp bởi một cố vấn cá nhân, huấn luyện viên nghề nghiệp và người quản lý thành công trong học tập. Họ cũng tham gia vào một mạng lưới đồng đẳng hỗ trợ để giúp đảm bảo thành công.

Trong một số khóa học, sinh viên đủ điều kiện được Thinkful đảm bảo học phí. Nghĩa là nếu một sinh viên không tìm được việc làm trong vòng sáu tháng sau khi tốt nghiệp, họ sẽ được trả lại tiền.

Rithm School

Rithm School là một chương trình kỹ thuật phần mềm toàn thời gian kéo dài 17 tuần.

Được thành lập bởi một đội ngũ giảng viên giàu kinh nghiệm, chú trọng vào quy mô lớp học nhỏ. Mỗi lớp học giới hạn 18 học viên với ba giảng viên giàu kinh nghiệm.

Chương trình học tập trung vào Python, SQL, Node, React, Cấu trúc dữ liệu và Thuật toán.

Không giống như các chương trình đào tạo lập trình khác, sinh viên dành ba tuần để ký hợp đồng cho các công ty và tích lũy kinh nghiệm chuyên môn.

Những kỹ năng hàng đầu của Kỹ sư phần mềm (Software Engineer)
Những kỹ năng hàng đầu của Kỹ sư phần mềm (Software Engineer). Ảnh: careerkarma.com

Sách kỹ thuật phần mềm

Ngoài các khóa học và chứng chỉ, sách kỹ thuật phần mềm có thể mở rộng kiến ​​thức của bạn một cách đáng kể.

Những cuốn sách này chứa đầy lời khuyên và thông tin hữu ích về lĩnh vực này.

Cho dù bạn là người mới bắt đầu hay một chuyên gia có kinh nghiệm, sau đây là những tài nguyên hữu ích cho bất kỳ kỹ sư phần mềm nào

Cracking the Coding Interview

Cracking the Coding Interview: 189 Programming Questions and Solutions - Gayle Laakmann McDowell
Cracking the Coding Interview - Sách về Kỹ thuật phần mềm
Cracking the Coding Interview – Sách về Kỹ thuật phần mềm

Nếu bạn ứng tuyển vào vị trí kỹ sư phần mềm, bạn có thể phải tham gia một cuộc phỏng vấn viết code.

Cuốn sách này giúp bạn tìm kiếm các chi tiết ẩn trong các câu hỏi viết code, chia nhỏ vấn đề thành các phần có thể quản lý được và cải thiện khả năng học các khái niệm của bạn.

Ngoài ra còn có 189 câu hỏi phỏng vấn và cách giải quyết trong cuốn sách, sẽ giúp bạn chuẩn bị cho cuộc phỏng vấn tiếp theo.

Code Complete

Code Complete: A Practical Handbook of Software Construction - Steve McConnell
Code Complete - Sách về Kỹ thuật phần mềm
Code Complete – Sách về Kỹ thuật phần mềm

Code Complete là một phân tích về xây dựng phần mềm. Nó được viết tốt và được coi là một tiêu chuẩn công nghiệp.

Thực tế, mọi lập trình viên ít nhất nên đọc qua cuốn sách này. Nó bao gồm các chủ đề về thiết kế, coding, testing và debugging.

Cuốn sách này đặc biệt hữu ích cho những người có một số kinh nghiệm chuyên môn ban đầu về lập trình.

Tuy nhiên, những người mới bắt đầu sẽ tự tin hơn khi làm phần mềm sau khi đọc cuốn sách này.

The Clean Coder

The Clean Coder: A Code of Conduct for Professional Programmers - Robert Martin
The Clean Coder - sách học kỹ thuật phần mềmThe Clean Coder - sách học kỹ thuật phần mềm
The Clean Coder – sách học kỹ thuật phần mềm

Cuốn sách này dạy cho bạn tất cả về các nguyên tắc, công cụ, kỹ thuật và thực hành của nghề làm phần mềm, kèm với lời khuyên thực tế về coding, testing, refactoring và estimating.

Sau khi đọc cuốn sách, bạn sẽ học được cách giải quyết những xung đột, những quản lý khó tính và lịch trình chặt chẽ.

Bạn còn học được cách tạo môi trường cho developer phát triển mạnh mẽ, tránh tình trạng kiệt sức và tham gia vào luồng coding.

Introduction to Algorithms

Introduction to Algorithms - Thomas H. Cormen
Introduction to Algorithms - sách học về Kỹ thuật phần mềm
Introduction to Algorithms – sách học về Kỹ thuật phần mềm

Đây là một hướng dẫn tuyệt vời cho tất cả các loại thuật toán. Là một phần cần thiết của kỹ thuật phần mềm, cuốn sách này bao gồm mọi thứ cho người mới bắt đầu cũng như các chuyên gia.

Bạn sẽ tìm hiểu về các thuật toán nhanh, thuật toán thời gian đa thức, lý thuyết đồ thị (graph theory), hình học tính toán (computational geometry) và cấu trúc dữ liệu (data structure). Nó thậm chí còn đưa ra một số ví dụ thông qua mã giả (pseudo-code).

The Pragmatic Programmer

The Pragmatic Programmer - David Thomas và Andrew Hunt
The Pragmatic Programmer - Sách học về Kỹ thuật phần mềm
The Pragmatic Programmer – Sách học về Kỹ thuật phần mềm

Cuốn sách này chứa đầy những lời khuyên chuyên môn và kỹ thuật giúp bạn trở thành một kỹ sư phần mềm giỏi hơn.

Cuốn sách xem xét ý nghĩa của việc trở thành một nhà phát triển hiện đại, khám phá các chủ đề từ kỹ thuật kiến ​​trúc đến phát triển nghề nghiệp. Khi đến trang cuối cùng, bạn sẽ học được cách lập trình thích ứng, linh hoạt và động.

Chứng chỉ Kỹ thuật Phần mềm

Một bước khác giúp bạn nổi bật trong quá trình phỏng vấn xin việc là kiếm chứng chỉ.

Chứng chỉ giống như bài kiểm tra cho phép nhà tuyển dụng biết bạn có đáp ứng một kỹ năng hoặc kiến ​​thức nhất định cần thiết cho một công nghệ cụ thể.

Dưới đây là một số chứng chỉ hữu ích nhất dành cho kỹ sư phần mềm:

Thay vì cố gắng thu thập càng nhiều càng tốt, hãy tập trung vào các chứng chỉ hỗ trợ các công nghệ bạn định sử dụng trong sự nghiệp của mình.

Các tài nguyên về Kỹ thuật Phần mềm (Online)

Dreaimincode.net

http://dreaimincode.net/

Đây là một cộng đồng trực tuyến lớn, với hàng trăm nghìn thành viên trên trang web. Nó kết nối các lập trình viên có kinh nghiệm, cho phép họ chia sẻ thông tin với nhau.

Trang web có các hướng dẫn lập trình chi tiết, các đoạn mã và một diễn đàn giúp bạn có thể nhận được bất kỳ hỗ trợ kỹ thuật phần mềm nào.

Programmr.com

http://programmr.com/

Trang này là một công cụ giáo dục trực tuyến. Nó toàn diện và bao gồm một loạt các chủ đề như Ruby, SQL, C ++, Python, C #, HTML, PHP và một vài chủ đề khác.

Mặc dù việc lập trình có thể phức tạp, nhưng tài nguyên trên đây rất đơn giản và dễ hiểu, giúp bạn dễ dàng bắt đầu.

Stackoverflow.com

http://stackoverflow.com/

Stack Overflow là một phần cộng đồng của mạng Stack Exchange. Nó tập trung vào việc cung cấp thông tin cho các developer ở tất cả các cấp độ kỹ năng.

Trang này được sử dụng bởi các lập trình viên trên toàn thế giới. Nếu bạn có câu hỏi, bạn sẽ được giải đáp thông qua trang web này.

Codecademy.com

http://codecademy.com/

Codecademy là một trang web tương tác dành cho các lập trình viên. Trang web cung cấp quyền truy cập vào một chương trình miễn phí giúp xây dựng kỹ năng phát triển web.

Có các chương trình dạy bạn các ngôn ngữ lập trình cụ thể. Trang web cũng cho phép sinh viên soạn thảo chương trình giảng dạy của họ và làm việc theo tốc độ của họ.

Tóm lại về kỹ thuật phần mềm

Lộ trìnhChứng chỉ Bootcamp, bằng cử nhân hoặc tự học
Các kỹ năng kỹ thuật cần thiếtKiểm thử và gỡ lỗi phần mềm, lập trình, thiết kế hướng đối tượng, cấu trúc dữ liệu và thuật toán, dịch vụ web và API
Kỹ năng mềm cần thiếtLàm việc theo nhóm, chú ý đến chi tiết, giải quyết vấn đề
Mức lương trung bình$ 98,500

Nguồn: careerkarma.com

Categories
Dev's Corner

Cách tương tác với Smart Contract từ một web app

Cách tương tác với Smart Contract từ Web app
Cách tương tác với Smart Contract từ Web app

Juan Cruz Martinez sẽ hướng dẫn chúng ta tạo một smart contract (hợp đồng thông minh) nhỏ để lưu trữ và truy xuất dữ liệu trên Ethereum blockchain và tạo một web app cho phép truy cập và thay đổi dữ liệu trên smart contract này.

Hãy thực hành cùng Gambaru nhé!

Smart Contract

Đầu tiên, tôi sẽ trình bày về smart contract mà ta sẽ sử dụng để xây dựng các ứng dụng web.

Vì bài viết tập trung vào việc liên kết JavaScript với blockchain, nên tôi tạo contract càng đơn giản càng tốt:

Tạo một Smart Contract đơn giản
Tạo một Smart Contract đơn giản. Xem code gốc ở đây

Hợp đồng CoolNumberContract chứa một biến trên blockchain được gọi là coolNumber với giá trị ban đầu là 10.

Biến này là public, nghĩa là ta có thể truy cập giá trị của nó từ blockchain mà không cần tạo hàm getter.

Ngoài ra, contract này chứa một hàm public là setCoolNumber, sẽ thay đổi giá trị của biến trên blockchain.

Điều quan trọng cần nhớ ở đây là bất kỳ thay đổi nào trong dữ liệu blockchain đều cần được thể hiện bằng một giao dịch.

Có nghĩa là việc gọi phương thức setCoolNumber sẽ yêu cầu một giao dịch và giao dịch đó sẽ có phí gas đi kèm.

Hãy triển khai hợp đồng trên một test network trước khi tiếp tục.

Thiết lập project và dependency

Để tương tác với bất kỳ Ethereum blockchain nào từ JavaScript, bạn sẽ cần một library.

Trong trường hợp này, hãy sử dụng web3 https://web3js.readthedocs.io/en/v1.3.0/

Web3 sẽ cho phép tương tác với bất kỳ Ethereum network nào thông qua MetaMask hoặc provider của web3 như Ganache.

Hãy bắt đầu một project mới. Tôi sẽ sử dụng JavaScript và HTML, nhưng mọi người có thể sử dụng bất kỳ framework nào mình muốn như React hoặc Vue.

Tất cả code sẽ đi vào một file là index.html và hãy bắt đầu với cấu trúc sau:

Thiết lập project và dependency
Thiết lập project và dependency. Xem code gốc ở đây

Hãy xem thử thẻ body.

Đây là một giao diện người dùng đơn giản với hai button và một khoảng biểu thị trạng thái.

Cả hai button đều gọi các hàm JavaScript mà hiện tại vẫn chưa được định nghĩa.

Trên thẻ head, thẻ quan trọng là script ta đang import. Đó là thành phần phụ thuộc vào web3.

Hãy thêm thành phần phụ thuộc này vào code như tôi đã làm hoặc nếu đang sử dụng một framework, chỉ cần import package này với:

Import Package
Import Package

Nếu chưa cài đặt library, bạn có thể thông qua NPM:

Cài thông qua NPM
Cài thông qua NPM

Cuối cùng, trước khi tiếp tục, lời khuyên là hãy cài đặt tiện ích mở rộng MetaMask.

Nếu muốn sử dụng bất kỳ provider nào khác, bạn có thể phải thay đổi các phần của code cho phù hợp, vì các sample được cung cấp sử dụng provider web3 được MetaMask đưa vào.

Kết nối web app với Ethereum Blockchain

Khi cấu trúc cơ bản và các thành phần phụ thuộc sẵn sàng, ta có thể thêm code để kết nối ứng dụng với blockchain.

Bên trong script tag ở body, hãy thêm:

Kết nối web app với Ethereum Blockchain
Kết nối web app với Ethereum Blockchain. Xem code gốc ở đây

Các đoạn code trên khá đơn giản ngoại trừ hàm loadWeb3.

Chức năng này chịu trách nhiệm thiết lập kết nối và cấp quyền tương tác với blockchain.

Để làm việc với smart contract này, ta sẽ cần một instance Web3 mới. Khi tạo instance này, cần chỉ định provider ta muốn sử dụng.

Vì đang sử dụng MetaMask làm proxy nên hãy dùng provider window.ethereum được đưa vào bởi tiện ích mở rộng MetaMask.

Khi truy cập trình duyệt và tải trang (bằng file hoặc trình duyệt web), ta sẽ thấy luồng ủy quyền MetaMask như sau:

Cấp quyền kết nối cho app thông qua MetaMask
Cấp quyền kết nối cho app thông qua MetaMask

Hãy nhấn Next và Connect.

Truy cập vào smart contract

Đến lúc này, code đã có quyền truy cập để tương tác với blockchain.

Tạo một chức năng mới để tạo một contract instance phù hợp với giao diện contract.

Tạo Contract Instance
Tạo Contract Instance

Để có được một instance của bất kỳ contract nào trên blockchain, tất cả những gì chúng ta cần là: thông số ABI của contract và địa chỉ contract, cả hai đều có thể trích xuất từ ​​Remix.

Để có thông số kỹ thuật ABI của contract, hãy đến Remix trên tab Compile. Compile và nhấp vào ABI.

Sao chép ABI specification của contract
Sao chép ABI specification của contract

Nút này sẽ sao chép thông số ABI cho contract dưới dạng một JSON array trên clipboard mà ta có thể sử dụng trực tiếp như một phần của tham số đầu tiên.

Tham số thứ hai là địa chỉ contract đã triển khai, có thể lấy từ Remix tại thời điểm triển khai hoặc Etherscan.

Sao chép địa chỉ contract từ Remix
Sao chép địa chỉ contract từ Remix
Sao chép địa chỉ contract từ Remix
Sao chép địa chỉ contract từ Remix

Code chức năng hoàn chỉnh cho contract này sẽ như sau:

Code chức năng hoàn chỉnh cho Contract
Code chức năng hoàn chỉnh cho Contract. Xem code gốc ở đây

Sau khi hoàn tất, ta có thể chỉ cần gọi loadContract từ hàm loader:

Gọi loadcontract từ hàm loader
Gọi loadcontract từ hàm loader

Đọc các giá trị từ smart contract

Nay ta đã sẵn sàng để bắt đầu gọi các chức năng của smart contract và sẽ bắt đầu bằng cách lấy coolNumber từ contract này.

Có thể lấy dữ liệu từ contract rất nhanh nhờ web3. Đây là một ví dụ để lấy giá trị của biến public coolNumber:

Lấy giá trị của biến public coolNumber
Lấy giá trị của biến public coolNumber. Xem code gốc ở đây

Siêu dễ đúng không?

Sử dụng instance contract từ phần trước, hãy lấy các phương thức và gọi một hàm với tên biến (đây là getter đã được đề cập ở phần đầu), và cuối cùng, sử dụng lệnh call để bắt đầu yêu cầu từ xa.

Cập nhật các giá trị vào smart contract

Cuối cùng, cần đảm bảo rằng ta cũng có thể giao dịch với smart contract.

Do đó, hãy hiển thị một instance bằng cách truy cập hàm setter để thay đổi coolNumber được lưu trữ trong contract.

Chức năng change sẽ chỉ định một số ngẫu nhiên mới và lưu nó trên blockchain:

Truy cập hàm setter để thay đổi coolNumber
Truy cập hàm setter để thay đổi coolNumber. Xem code gốc ở đây

Có hai điều cần chú ý:

  • Đầu tiên, chúng ta đề cập đến một hàm getCurrentAccount() hiện chưa được định nghĩa. Ta sẽ làm việc này sau.
  • Thứ hai là cách gọi setter. Hãy chú ý đến dòng gọi phương thức setCoolNumber từ contract, nó trông hơi khác so với những gì đã làm cho caller:
Cách gọi setter
Cách gọi setter

Thay vì sử dụng phương thức call, ta đang sử dụng phương thức send. Ta cần xác định tài khoản người gửi. Tại sao? Phải cần một giao dịch để thay đổi các giá trị trên blockchain. Như đã nói, một giao dịch yêu cầu tài khoản từ và đến phải hợp lệ – từ người khởi tạo giao dịch và trong trường hợp này, là địa chỉ của smart contract này.

Có thể sử dụng bất kỳ tài khoản nào làm từ giá trị không? Không! Đó phải là tài khoản bạn có quyền truy cập (và trong trường hợp này, tài khoản được đăng ký trên ví MetaMask của bạn), vì bạn sẽ cần ủy quyền giao dịch và xác nhận hóa đơn tiền gas.

Vấn đề đã được giải quyết, hãy xây dựng phương thức getCurrentAccount():

Xây dựng phương thức getCurrentAccountxây dựng phương thức getCurrentAccount
Xây dựng phương thức getCurrentAccount

Web3 thực sự tuyệt vời. Mọi người có thể tương tác với blockchain và ví của mình, vì vậy có thể thông qua Web3 để yêu cầu thông tin về các tài khoản đã đăng ký trên ví. Trong trường hợp này, chỉ cần lấy tất cả và sử dụng tài khoản đầu tiên để thực hiện các giao dịch.

Vận dụng những gì đã học

Tôi đã tải code lên GitHub gist để bạn so sánh và tham khảo. Hãy thử xây dựng dự án nhỏ nhưng thú vị này nào!

Application Flow
Application Flow

Nếu thành công, bạn hãy comment phía dưới cho Gambaru biết nhé!

Theo Juan Cruz Martinez

Categories
Gambaru News

Cách giữ vững sự tập trung khi làm việc tại nhà

Cách giữ sự tập trung khi làm việc tại nhà
Cách giữ sự tập trung khi làm việc tại nhà

Làm việc tại một công ty phần mềm, tôi không hề xa lạ với trải nghiệm làm việc ở nhà.

Bản thân công việc của tôi đã có mức độ số hóa, online hóa cao nhất, văn hóa trong công ty cũng lại tập trung vào quản lý đầu ra chứ không quản lý thời gian.

Vô tình, những kỳ nghĩ lễ kéo dài ở quê, những ngày trời mưa to ngập phố, những ngày phải họp từ sáng sớm đến quá giờ quy định… đã đều chuẩn bị cho tôi một trải nghiệm làm việc ở nhà hiệu quả.

Và đây là cách tôi giữ cho mình có thể làm việc hiệu quả nhất, ngay cả khi đang ở trong môi trường… rất dễ chịu của căn nhà.

Cách tập trung khi làm việc tại nhà

Một không gian làm việc thật khác

Hãy tìm cho mình một “góc” riêng, để khi bước vào, tâm trí tự động chuyển sang chế độ làm việc.

Điều đầu tiên cần làm, đó là tạo cho mình một không gian làm việc thật khác.

Cách giữ sự tập trung khi làm việc tại nhà
Cách giữ sự tập trung khi làm việc tại nhà

Ví dụ, ở nhà tôi vốn đã có một không gian riêng để đặt PC chơi game và nghe nhạc.

Nhưng tôi không dùng chiếc bàn này để làm việc, thay vào đó, cứ mỗi sáng (và mỗi chiều) cách ly, tôi lại mang laptop ra bàn phòng khách ngồi.

Dĩ nhiên, không phải ai cũng sẽ có điều kiện để sở hữu nhiều không gian khác nhau, nhưng nguyên tắc vẫn chỉ có một: Hãy cố gắng mọi cách để không gian làm việc tách biệt ra hẳn những không gian thư giãn thường nhật.

Hãy tìm cho mình một “góc”, mà mỗi khi bạn bước vào, tâm trí bạn tự động chuyển sang chế độ làm việc.

Trong nhóm của tôi, nhiều người cũng như vậy.

Có người mang laptop lên kệ loa để đứng làm việc. Có người mua một chiếc ghế có gắn bàn nhỏ, hướng ra ngoài ban công. Còn nếu chỉ có một không gian, chỉ có một chiếc PC (hoặc laptop)…

Nếu bạn chỉ có một chiếc PC

Tôi đã từng phải đi làm việc ở nước ngoài trong một thời gian dài, đã có những ngày không thể lên công ty khách hàng ngồi mà phải làm việc tại khách sạn.

Chiếc laptop tôi mang theo cài đầy game, ban ngày dùng làm để làm việc…

Và đây là lời khuyên đặc biệt quan trọng với những người vốn chỉ dùng PC tại nhà để chơi game hay lướt face: khi phải dùng cỗ máy này cho công việc, hãy tạo một tài khoản người dùng (User Account) khác.

Tài khoản Windows cho công việc
Tài khoản Windows cho công việc

Trên tài khoản này, hãy ẩn đi toàn bộ các đường tắt tới Steam hay Origin, hãy đừng bao giờ đăng nhập vào Facebook hay Reddit.

Thay vào đó, hãy chỉ đặt các ứng dụng liên quan tới công việc mà thôi.

Tài khoản Windows cho giải trí
Tài khoản Windows cho giải trí

Không gian làm việc tối giản nhất có thể

Hãy nghĩ thật kỹ: Bạn thực sự cần thứ gì để làm việc?

Không gian làm việc tối giản
Không gian làm việc tối giản

Mở rộng một chút với lời khuyên bên trên: Hãy giữ cho góc làm việc của bạn luôn gọn gàng, ít vật dụng nhất có thể.

Một cuốn truyện đang đọc dở, một chiếc iPad dùng để “luyện” Netflix, bộ tai nghe “xịn”, đều có thể khiến bạn đứt mạch làm việc.

Dĩ nhiên, kỷ luật bản thân là cần thiết, nhưng hãy làm mọi cách để bản thân có thể tự giữ kỷ luật một cách dễ dàng hơn.

Đến cuối cùng, trong phần lớn trường hợp, thứ duy nhất bạn cần để làm việc chỉ là một chiếc PC mà thôi.

Liên tục “call” với team

Tùy vào mức độ gắn kết giữa các thành viên trong team (và dĩ nhiên là cả đường mạng), cả đội có thể bật cuộc gọi trong suốt chế độ làm việc.

Đây vừa là một cách giữ được sự liên lạc luôn được thông suốt (osmotic communication) trong quá trình làm việc, một nguyên tắc mà các coder tuân theo tư tưởng Agile luôn cố gắng thực hiện.

Liên tục call với team
Liên tục call với team

Hãy giả lập môi trường làm việc của team mình qua các ứng dụng gọi video.

Ngoài ra, đây cũng là một cách để cả đội có thể “nhắc khéo” nhau luôn tập trung cao độ trong quá trình làm việc nữa.

“Quy tắc giao tiếp” với gia đình

Nghe có vẻ hơi tiêu cực, nhưng các thành viên khác trong gia đình có thể khiến công việc (tại nhà) của bạn bị xao nhãng.

Ví dụ, đã có lúc tôi đang họp qua Slack thì mẹ tôi mở cửa vào phòng nói rất to: “Mẹ mua bánh mì về rồi, xuống ăn đi”.

Mọi người nghe thấy đều cười đùa, khiến buổi họp bị đứt mạch đôi chút.

Lời khuyên của tôi: hãy thiết lập một quy tắc giao tiếp với gia đình mình trong giờ làm việc.

Ví dụ, những ngày phải làm việc tại nhà, tôi luôn nhắc mẹ: Mẹ mua đồ ăn sáng thì cứ để ở bếp, xong việc đang làm con sẽ xuống ăn.

Hãy nhờ bố của bạn trả lời mỗi khi có ai bấm cửa.

Hãy dặn các bé (đã đủ lớn) tự ngồi học, ngồi chơi: “Bố ở nhà nhưng vẫn phải làm việc. Vẫn phải đến buổi tối, bố mới có thời gian để đọc truyện cho con”.

Chia nhỏ công việc, và cố gắng không bỏ dở đầu việc nhỏ

Các đầu việc nhỏ sẽ giúp bạn giảm thiểu ảnh hưởng từ các yếu tố xao nhãng.

Chia nhỏ công việc
Chia nhỏ công việc

Sẽ có những trường hợp bạn không thể bị ảnh hưởng.

Ví dụ, khi bạn phải vừa làm việc, vừa “để mắt” tới em bé để bà đi chợ ngày ông đi vắng chẳng hạn.

Để hạn chế ảnh hưởng theo cách này, hãy công việc của mình đủ nhỏ.

Ví dụ, công việc của tôi có thể chia thành các hàm (function) cần thực hiện. Công việc quản lý của bạn có thể chia thành từng hóa đơn, công việc viết lách có thể chia thành từng đầu mục (như 5 đầu mục trong bài viết này).

Hãy hoàn thành từng đầu việc nhỏ này trước khi bước sang việc khác.

Như vậy, khi có những điều xao nhãng xảy ra, ảnh hưởng sẽ chỉ gây ra với 1 đầu việc nhỏ mà thôi.

Nếu bạn đang code dở mà lại chuyển sang trả lời mail khách hàng và con bạn chạy vào, bạn sẽ phải tiếp tục tới 2 đầu việc đang dang dở. Đó sẽ là một trải nghiệm khó chịu hơn rất nhiều.

Và đừng quên những nguyên tắc chung

Chia nhỏ đầu việc chỉ là một trong những nguyên tắc chung mà bạn nên áp dụng khi làm việc ở bất cứ đâu – ở công ty hay ở nhà.

Hãy đặt cho mình các mốc thời gian để bắt đầu và kết thúc. Hãy viết các đầu việc cần làm lên note.

Hãy đảm bảo một môi trường nhiều ánh sáng.

Hãy đặt đồng hồ Pomodoro (ví dụ, làm việc 20 phút rồi tự cho phép mình “nghỉ ngơi 5 phút), nếu bạn tin vào phương pháp này.

Bởi đến cuối cùng, “công việc” ở đâu thì cũng vẫn là công việc.

Để có thể tập trung hơn, làm việc hiệu quả hơn, hãy ghi nhận tất cả sự khác biệt giữa khái niệm “làm việc” và “nghỉ ngơi”.

Và hãy tìm mọi cách để tạo cho mình 2 chế độ, dù rằng bạn vẫn đang chỉ ở nhà mà thôi.

Theo TechTalk via GenK

Categories
Dev's Corner

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

Lập trình viên không thể estime thời gian hiệu quả
Lập trình viên không thể estime thời gian hiệu quả

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

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

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

Tổng quan

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

Vấn đề

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

Hậu quả

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Phân phối chuẩn

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

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

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

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

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

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

Phân phối lệch

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Theo Hesham Meneisi

Categories
Dev's Corner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kiểm thử mô-đun

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

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

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

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

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

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

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

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

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

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

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

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

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

Kết

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

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

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

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

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

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

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

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

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

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

Theo Stein Janssen

Categories
Dev's Corner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Theo javinpaul

Categories
Dev's Corner

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Theo Neal Brooks