Kỹ sư phần mềm là ai? Công nghệ phần mềm VS lập trình “chỉ”

Chúng tôi mang đến cho bạn sự chú ý từ bản chuyển thể từ một bài báo của Samer Buna về sự khác biệt giữa công nghệ phần mềm và lập trình, hoặc việc phát triển một khái niệm phần mềm khác với việc “chỉ viết mã” như thế nào. Tất cả các kỹ sư phần mềm đều có thể viết mã, nhưng không phải tất cả các lập trình viên đều có thể phát triển các khái niệm phần mềm. Một số người không thích thuật ngữ "Kỹ sư phần mềm" (hay còn gọi là Kỹ sư phần mềm) vì hầu hết chúng ta thường sử dụng từ "kỹ sư" khi nói về một thứ gì đó mang tính vật lý hơn - chẳng hạn như xây dựng. Tất nhiên, bài viết của chúng tôi không phải về thuật ngữ này. Nếu nó đột nhiên khiến bạn bị từ chối, bạn có thể dễ dàng thay thế nó bằng thứ gì đó liên quan đến sự sáng tạo. “Người tạo phần mềm”, “Tác giả phần mềm”... hay thậm chí là “Người tạo phần mềm”! Khả năng lập trình không tự động biến một người thành kỹ sư phần mềm. Bất cứ ai cũng có thể học cách viết mã và việc này dễ dàng hơn nhiều so với tưởng tượng. Bất kỳ ai cũng có thể tạo một chương trình đơn giản để sử dụng cho riêng mình, nhưng điều này không đảm bảo rằng chương trình tương tự sẽ hoạt động cho những người khác. Ví dụ yêu thích của tôi là thế này: nhiều người trong chúng tôi hát trong khi tắm, nhưng than ôi, buổi biểu diễn này không phải lúc nào cũng xứng đáng với một sân khấu chuyên nghiệp. Tất nhiên, để có trải nghiệm âm nhạc chất lượng cao, rất có thể bạn sẽ chuyển sang chơi nhạc chuyên nghiệp. Bạn có cần thêm các ví dụ?

• Tất cả chúng ta đều học toán và viết ở trường, nhưng điều đó không khiến chúng ta trở thành nhà toán học và nhà văn.
• Hầu hết chúng ta đều có khả năng chuẩn bị một món ăn vừa phải và đôi khi rất ngon, nhưng không phải ai cũng dám nấu một bàn cho 100 người trong bữa tiệc tối của đại sứ quán. Trong trường hợp này, chúng tôi thuê một đầu bếp.
• Ngay bây giờ bạn đã sẵn sàng giao phó hoàn toàn việc xây dựng ngôi nhà mới của mình cho đứa trẻ hàng xóm, người đã tạo ra những kiệt tác ấn tượng từ Lego chưa?

Điểm chính mà tôi đang cố gắng truyền tải trong bài viết này là các chương trình đơn giản rất khác với các chương trình do các kỹ sư thiết kế. Định nghĩa đơn giản nhất về quy trình lập trình: vẽ ra một chuỗi hành động theo thứ tự cho máy tính để thu được một cái gì đó cụ thể làm đầu ra, với các tham số đầu vào nhất định. Quá trình công nghệ phần mềm là thiết kế, viết, thử nghiệm và quản lý một chương trình máy tính để giải quyết các vấn đề cho nhiều người dùng. Đó là về việc tạo ra các giải pháp đáng tin cậy và an toàn, có thể vượt qua thử thách của thời gian và có tác dụng đối với một số thách thức có thể chưa biết ngoài những thách thức hiển nhiên. Các kỹ sư phần mềm biết mọi thứ về vấn đề họ giải quyết, giải pháp họ đề xuất, hạn chế của các giải pháp đó, quyền riêng tư và bảo mật của họ. Theo tôi, nếu một người không hiểu bản chất của vấn đề, anh ta thậm chí không nên bắt đầu lập trình giải pháp cho nó.

Tư duy kỹ thuật - tìm kiếm giải pháp ứng dụng

Các kỹ sư phần mềm không coi việc viết phần mềm là mục tiêu chính của họ. Họ suy nghĩ về việc đáp ứng nhu cầu và giải quyết vấn đề . Điều này rất quan trọng vì không phải mọi vấn đề đều cần đến giải pháp phần mềm. Một số trong số chúng có thể được giải quyết bằng cách sử dụng các chương trình hiện có. Sự xuất hiện của một số vấn đề đôi khi có thể được dự đoán trước và với sự trợ giúp của thiết kế chương trình phù hợp, chúng có thể tránh được trong tương lai. Những vấn đề phức tạp thường đòi hỏi phải viết rất nhiều chương trình. Có những tác vụ yêu cầu các ứng dụng chạy song song, trong khi những tác vụ khác yêu cầu thực hiện tuần tự một số chương trình. Một số vấn đề có thể được giải quyết đơn giản bằng cách đào tạo người dùng. Trước khi bắt đầu tạo một chương trình, một kỹ sư phần mềm sẽ tự hỏi mình một số câu hỏi:

• Tôi nên giải quyết những vấn đề gì?
• Bạn có thể làm gì khác ngoài việc viết mã để giải quyết chúng?
• Tôi có thể làm gì để thực hiện những tác vụ này dễ dàng hơn với ứng dụng?

Chất lượng chương trình và chất lượng mã

Các chương trình tốt thì rõ ràng và dễ đọc. Chúng dễ dàng mở rộng, hoạt động tốt với các chương trình khác và sẽ không phải là cơn ác mộng khi làm việc cùng. Chất lượng mã không thể thương lượng. Nó phải cao, thế thôi. Khi xem xét nó, những lý do như tâm trạng không tốt của lập trình viên hoặc thời hạn quá chặt chẽ (ồ, những thời hạn đó!) đều không thể chấp nhận được. Một trong những khía cạnh quan trọng nhất của phát triển phần mềm là thiết kế chương trình sao cho dễ bảo trì và sửa đổi trong tương lai (xin chào, OOP!). Ngày nay, hầu hết mọi phần mềm đều có thể sửa đổi được, thường thì quá trình này diễn ra ngay cả khi không có sự tham gia của người dùng hoặc không yêu cầu bất cứ điều gì từ người dùng ngoài “chương trình của bạn đã được cập nhật, hãy nhấp vào OK hoặc Hoãn lại”. Tất nhiên, người dùng có quyền yêu cầu các tính năng mới từ các ứng dụng (đặc biệt nếu chúng ta đang nói về phần mềm doanh nghiệp chạy lâu dài được viết bằng Java hoặc các trò chơi trực tuyến có thể chơi trong nhiều năm). Bản thân một đoạn mã khó có thể được coi là hữu ích. Chức năng hữu ích của phần mềm bắt đầu khi các phần ứng dụng khác nhau giao tiếp với nhau, trao đổi dữ liệu và làm việc cùng nhau để thực hiện nhiệm vụ trình bày dữ liệu và giao diện cho người dùng. Các chương trình nên được thiết kế có tính đến những điểm này! Họ nhận được tin nhắn gì? Những sự kiện nào được theo dõi? Việc xác thực và ủy quyền diễn ra như thế nào? Một dấu hiệu quan trọng không kém khác của một chương trình tốt là tính rõ ràng của mã chứ không phải số lượng thử nghiệm mà ứng dụng đã vượt qua hay thậm chí là phạm vi kiểm tra tốt. Những câu hỏi tưởng chừng như đơn giản: “Liệu ai đó ngoài tôi có thể hiểu được mã của tôi không?”, “Liệu tôi có thể viết mã này ngay hôm nay và hiểu nó sau vài tuần nữa không?” Một câu nói phổ biến về hai điều khó nhất trong lập trình nói: Khả năng đọc mã quan trọng hơn nhiều so với những gì người ta thường tin. Thật không may, không thể xác định số liệu hoặc tham số chính xác để làm rõ mã. Việc ghi nhớ các chuẩn mực ngôn ngữ được chấp nhận chung, các mô hình phần mềm tốt và các phương pháp phát triển sẽ giúp ích một phần. Nhưng thường thì điều này là không đủ. Theo thời gian và kinh nghiệm, có thể nói, các chuyên gia thực thụ sẽ phát triển “cảm giác rõ ràng”, một thứ gì đó giống với trực giác. Phép ẩn dụ viết lách có tác dụng tốt ở đây: biết nhiều từ sẽ không giúp bạn viết được thứ gì đó ngắn gọn và rõ ràng về ý nghĩa. Khả năng sửa lỗi nhanh chóng và dễ dàng là tính năng chính của phần mềm tốt. Các lỗi trong chương trình sẽ gửi thông báo rõ ràng và được ghi lại tập trung để theo dõi. Khi một lỗi mới được báo cáo, người sửa lỗi đó phải có khả năng gỡ lỗi. Anh ta cần dễ dàng kết nối với hệ thống, truy cập thông tin thực thi bất kỳ lúc nào và cũng có thể dễ dàng kiểm tra chức năng của bất kỳ bộ phận nào của hệ thống.

Môi trường và thử nghiệm

Khi các kỹ sư phần mềm phát triển ứng dụng, họ cố gắng hết sức để đảm bảo rằng chúng hoạt động trên các máy tính có kiến ​​trúc khác nhau và với các hệ điều hành khác nhau. Điều quan trọng là phần mềm phải hoạt động ở các độ phân giải và hướng màn hình khác nhau, đồng thời không “ngốn” nhiều bộ nhớ và sức mạnh xử lý hơn mức cần thiết. Khi nói đến các ứng dụng web, chúng phải hoạt động trên tất cả các trình duyệt chính. Khi tạo một ứng dụng dành cho máy tính để bàn, bạn cần đảm bảo rằng ứng dụng đó khởi chạy và hoạt động chính xác trên Mac, Windows và Linux. Chà, chương trình phụ thuộc vào dữ liệu, khi đó ứng dụng sẽ hoạt động ngay cả trong trường hợp kết nối dữ liệu chậm hoặc không có dữ liệu. Để viết một phần mềm, các kỹ sư phải suy nghĩ qua tất cả các loại kịch bản và lên kế hoạch thử nghiệm chúng. Tất cả bắt đầu bằng việc chọn tùy chọn lý tưởng, trong đó mọi thứ đều hoạt động không có lỗi. Sau đó, họ ghi lại mọi vấn đề tiềm ẩn và viết chúng vào kế hoạch kiểm tra. Một số kỹ sư bắt đầu bằng cách viết mã mà họ gọi là trường hợp thử nghiệm, mô phỏng các tình huống cho tất cả các vấn đề và lỗi có thể xảy ra. Và sau đó một chương trình được viết có thể hoạt động với bất kỳ tùy chọn nào được xem xét. Khả năng đặc biệt của một kỹ sư phần mềm tài năng không phải là biết cách viết mã mà là hiểu chính xác những gì ứng dụng phải làm ở đầu ra và cách đạt được nó. Khi các yêu cầu phần mềm của khách hàng không đầy đủ và có thể mơ hồ, kỹ sư cần đánh giá và “hiểu” chính xác chúng.

Chi phí và hiệu quả

Một kỹ sư phần mềm có thể khắc phục sự cố nhanh chóng trong hầu hết các trường hợp. Nếu bạn cho rằng việc thuê một lập trình viên giàu kinh nghiệm “đắt tiền” sẽ làm tăng chi phí của bạn thì hãy nghĩ lại. Lập trình viên được thuê càng có nhiều kinh nghiệm thì anh ta càng có thể cung cấp giải pháp đơn giản, gọn gàng, đáng tin cậy và dễ sử dụng nhanh hơn. Về lâu dài, điều này chắc chắn sẽ giảm chi phí phát triển phần mềm. Cũng cần phải xem xét chi phí thực hiện chương trình. Bất kỳ chương trình nào cũng sử dụng tài nguyên máy tính và chúng không miễn phí. Ví dụ: lưu vào bộ nhớ đệm dữ liệu được truy cập thường xuyên là một trong những chiến lược khả thi được sử dụng để đạt được kết quả mong muốn. Nhưng đây chỉ là một trong hàng trăm công cụ và giải pháp có thể giúp chương trình nhanh hơn và hiệu quả hơn. Một lập trình viên mới vào nghề có thể cung cấp cho bạn một giải pháp rẻ tiền, nhưng việc sử dụng một giải pháp như vậy cuối cùng sẽ khiến bạn và khách hàng của bạn tốn nhiều tiền hơn so với việc bạn làm việc với một nhà phát triển có kinh nghiệm, người đã tạo ra giải pháp hiệu quả ngay từ đầu.

Tập trung vào trải nghiệm người dùng

Một lập trình viên giỏi phát triển dựa trên Trải nghiệm người dùng (UX). Tương tác giữa người và máy là một chủ đề có vô số nghiên cứu và giải pháp. Càng áp dụng nhiều giải pháp thì chương trình sẽ càng tốt hơn. Dưới đây là một vài ví dụ, chỉ để giúp bạn cảm nhận được hướng đi này là gì:

• Khi thiết kế các biểu mẫu nhập dữ liệu như e-mail, một chương trình tốt nên bỏ qua trường hợp địa chỉ e-mail. Nó sẽ không báo lỗi nếu nhấn phím CAPSLOCK vì địa chỉ email là duy nhất ở dạng chữ thường. Nếu chương trình chấp nhận địa chỉ email mới làm đầu vào, hãy kiểm tra sớm địa chỉ đó trong quá trình nhập để cảnh báo người dùng rằng họ đang sử dụng định dạng địa chỉ sai. Giải pháp này bao gồm cả việc kiểm tra rõ ràng như dấu “@” bị thiếu và cả những kiểm tra không quá rõ ràng, chẳng hạn như kiểm tra thứ tự sai của các ký tự như “gmail.ocm”

• Khi người dùng được chuyển hướng để thực hiện một số hành động, một chương trình tốt sẽ ghi nhớ vị trí hiện tại của người dùng và đưa anh ta trở lại sau khi hoàn thành. Một chương trình tốt cũng phải ghi nhớ dữ liệu đã được người dùng truyền đi, điều này rất quan trọng để tương tác thêm với anh ta.

  Giả sử bạn đang tìm kiếm chuyến bay bằng máy bay với tư cách là Khách trên Expedia. Sau đó bạn quyết định tạo một tài khoản. Ứng dụng sẽ lưu tất cả các tìm kiếm trước đó của bạn vào tài khoản mới và bạn sẽ có thể truy cập chúng từ các thiết bị khác.




• Một chương trình tốt được thiết kế có tính đến các kịch bản hành vi của người dùng. Bạn không chỉ cần thêm các tính năng mới trên cơ sở “bình thường”; hãy đặt mình vào vị trí của người dùng. Một ngày nọ, tôi đang đặt vé máy bay và quên ghi số khách hàng thường xuyên của mình. Sau khi nhận được xác nhận, tôi quyết định vào trang web của hãng hàng không và thêm nó để được giảm giá. Để tìm ra cách thực hiện việc này, tôi đã loay hoay tìm hiểu trang web trong 10 phút. Ứng dụng này không rõ ràng đến mức tôi chỉ lang thang không mục đích qua các trang khác nhau của trang web để tìm thấy thứ mình cần. Sau đó, tôi phát hiện ra rằng tôi đã vào đúng trang một vài lần, nhưng tôi thậm chí còn không hiểu nó, vì trường tôi cần đã bị mất giữa các trường tương tự khác có hình dạng khổng lồ.

  Hóa ra để chỉnh sửa thông tin chuyến đi, tôi cần phải cuộn qua khoảng hai mươi dòng của biểu mẫu, nhập số thẻ khách hàng thân thiết và số điện thoại, nếu không có thì không thể gửi biểu mẫu để xác minh. Đây là ví dụ về một chương trình được phát triển mà không cần suy nghĩ xem người dùng sẽ cảm thấy thoải mái như thế nào khi sử dụng nó.

Độ tin cậy, an ninh và an toàn

Theo tôi, sự khác biệt quan trọng nhất giữa một nhà phát triển phần mềm chuyên nghiệp và một người nghiệp dư là tính đến các thông số như độ tin cậy, bảo mật và an toàn của ứng dụng khi tạo nó. Các phần của chương trình phải chấp nhận đầu vào không chính xác, trạng thái không chính xác và tương tác không chính xác. Điều này thực sự rất khó thực thi và là lý do chính khiến chúng ta nghe thấy những câu chuyện về những người chết vì lỗi phần mềm. Người dùng đã, đang nhập và sẽ tiếp tục nhập sai dữ liệu vào chương trình. Điều này phải được chấp nhận như một sự thật. Hơn nữa, một số người sẽ cố tình làm điều này, với mục tiêu phá vỡ ứng dụng và lấy được các tài nguyên có sẵn cho nó. Đây là một ví dụ thực tế: Người được cho là chịu trách nhiệm về vụ vi phạm dữ liệu Equachus gần đây bị cáo buộc đã không hoàn thành trách nhiệm công việc của mình, đó là phát triển các giải pháp để chống lại đầu vào xấu và độc hại trong tất cả các sản phẩm phần mềm được cung cấp cho công chúng. Các sự cố liên quan đến bảo mật thông tin không chỉ liên quan đến việc nhập dữ liệu không chính xác và độc hại mà còn liên quan đến dữ liệu được nhập không chính xác. Nếu người dùng quên mật khẩu, anh ta có thể thử nhập lại bao nhiêu lần? Bạn sẽ chặn anh ta sau chuyện này chứ? Điều gì sẽ xảy ra nếu người khác cố gắng chặn tài khoản của anh ấy? Người dùng có thể truyền thông tin xác thực của họ qua kênh dữ liệu không được mã hóa không? Điều gì sẽ xảy ra nếu yêu cầu đăng nhập đến từ một vị trí bất thường? Bạn sẽ làm gì nếu nỗ lực đăng nhập có vẻ là tự động? Bạn đã làm gì để bảo vệ người dùng của mình khỏi tập lệnh chéo trang, giả mạo yêu cầu giữa các trang và lừa đảo thông thường? Bạn có chiến lược dự phòng trong trường hợp máy chủ của mình bị tấn công DDoS không? Những câu hỏi này chỉ nêu bật một số vấn đề cần được xem xét. Chương trình được bảo vệ không lưu thông tin quan trọng ở dạng văn bản. Nó bảo vệ nó bằng mật mã một chiều phức tạp (dễ mã hóa nhưng gần như không thể giải mã nếu không có khóa). Đây là những biện pháp dự phòng trong trường hợp chương trình bị hack. Tin tặc sẽ phát hiện ra dữ liệu được mã hóa mà chúng vô dụng. Những vấn đề không mong muốn phát sinh ngay cả trong những chương trình tốt nhất. Một lập trình viên không chuẩn bị sẵn sàng cho sự xuất hiện của chúng khó có thể được gọi là chuyên nghiệp. Cho đến khi anh ta mong đợi hành vi bất ngờ, anh ta không phải là một kỹ sư. Anh ta là “tác giả của những chương trình không an toàn”. Lỗi trong chương trình không phải lúc nào cũng rõ ràng. Khả năng trí tuệ của chúng ta để dự đoán và ngăn chặn những lỗi đã biết còn hạn chế. Đây là lý do tại sao các kỹ sư phần mềm hiểu tầm quan trọng của các công cụ tốt giúp họ viết phần mềm chính xác và an toàn.

công cụ bắt buộc

Không còn nghi ngờ gì nữa, chúng ta cần các công cụ phát triển tốt và khác biệt. Vai trò của họ thường bị đánh giá thấp nhưng trên thực tế, họ tiết kiệm rất nhiều thời gian và công sức, đơn giản hóa một số nhiệm vụ ở mức độ lớn. Hãy tưởng tượng nếu bạn vẫn phải tải tệp lên qua FTP để triển khai, có thể nói, theo cách cũ. Hãy tưởng tượng việc gỡ lỗi các vấn đề về mạng và hiệu suất mà không cần Chrome DevTools! Và ngày nay việc viết mã JavaScript mà không có ESlit và Prettier sẽ kém hiệu quả biết bao! Bất kỳ công cụ nào giúp giảm thời gian phản hồi khi bạn viết mã đều được hoan nghênh. Khi tôi tìm thấy một công cụ trước đây xa lạ với tôi nhưng thực sự hữu ích và hiệu quả, tôi chỉ có thể tiếc nuối vì đã không sử dụng nó trước khoảnh khắc hạnh phúc đó.

Sự phát triển của công nghệ phần mềm

Không ai có thể học công nghệ phần mềm trong hai tháng, sáu tháng hay thậm chí một năm. Bạn sẽ không được dạy cách trở thành kỹ sư phần mềm trong một khóa học, trường đại học hoặc chương trình đào tạo nào. Tôi đã học hơn hai mươi năm qua và vẫn tiếp tục học cho đến bây giờ. Tôi có thể thoải mái gọi mình là một lập trình viên giàu kinh nghiệm chỉ sau một thập kỷ học hỏi và phát triển, tạo và duy trì các ứng dụng được hàng nghìn người dùng sử dụng. Công nghệ phần mềm không dành cho tất cả mọi người, nhưng mọi người nên học cách giải quyết vấn đề của mình bằng máy tính. Nếu bạn có thể học cách viết các chương trình đơn giản thì bạn nên học. Nếu bạn có thể học cách sử dụng phần mềm có sẵn công khai, bạn nên làm như vậy. Nếu bạn có thể học cách sử dụng phần mềm nguồn mở và tùy chỉnh nó cho riêng mình thì bạn có một siêu năng lực! Mỗi ngày đều mang đến cho các nhà phát triển những thách thức mới, những vấn đề mới, đó là lý do tại sao cần có công nghệ phần mềm. Nhiệm vụ chính của nghề này là tạo ra phần mềm để một người bình thường không phải đối mặt với nó trong nhiều năm. Vì vậy, không cần phải nghiên cứu lâu dài để tương tác với các chương trình. Chưa hết, các kỹ sư phần mềm vẫn không ngừng suy nghĩ về việc tạo ra những công cụ tốt hơn có thể giải quyết các vấn đề phức tạp hơn đã biết và làm mọi thứ có thể để đảm bảo rằng các vấn đề mới hiếm khi xuất hiện nhất có thể.