15 sự thật về nghề lập trình có thể bạn chưa bao giờ để ý

15 sự thật thú vị về nghề lập trình dưới đây, thật không may, không phải được nhiều người trong giới lập trình viên biết đến. Tuy nhiên, cũng cần phải nhắc rằng những kết quả dưới đây được đưa ra dựa trên những thử nghiệm và lý thuyết dựa trên một hoàn cảnh cụ thể. Điều đó có nghĩa là vẫn có những điểm cần được thảo luận về tính thực tiễn và ứng dụng của những lý thuyết này.

1) Lập trình viên khá ngại tìm một sự giúp đỡ khi đối mặt với khó khăn

Điều này có thể liên quan đến cách mọi người học lập trình. Về cơ bản, việc dạy lập trình thường đi theo cách dạy của môn toán: lý thuyết + một hoặc hai ví dụ + rất nhiều bài tập.

Cách dạy này yêu cầu mọi người phải nỗ lực để hoàn thành tất cả những bài tập được đưa ra và thường xuyên làm việc đó một mình thay vì tìm kiếm sự giúp đỡ. Thái độ này không phải là xấu, thậm chí nó còn được khuyến khích, tuy nhiên, chúng ta nên biết giới hạn của mình và tìm kiếm trợ giúp từ những người khác.

2) Developer thường có xu hướng không nói ra toàn bộ vấn đề của mình

Điều này có liên quan đến nghiên cứu về tâm lý học. Khi một người nào đó gặp phải một vấn đề, họ thường không đưa ra toàn bộ những thông tin về vấn đề đó, đặc biệt là khi họ trực tiếp hay gián tiếp phải chịu trách nhiệm về nó.

Điều này đã được công nhận qua nghiên cứu ở những người làm lập trình chúng ta, và một trong những lý do chính mà đa phần mọi người trả lời là việc báo cáo toàn bộ vấn đề của mình là một dấu hiệu của sự kém cỏi và sẽ dẫn đến việc bị đánh giá thấp về kỹ năng cũng như khả năng làm việc bởi những người khác. Tình huống này càng phổ biến hơn khi liên quan đến những lỗi nghiêm trọng mắc phải bởi những người mới vào nghề.

3) Developers thường tìm kiếm những cách khác trước khi hỏi đồng nghiệp

Sự thật rằng những lập trình viên không ưu tiên việc trao đổi thông tin với người khác khi họ gặp phải vấn đề. Lại một lần nữa có liên quan đến suy nghĩ rằng họ sẽ bị đánh giá.

Tuy nhiên, ở khía cạnh coding, StackOverflow đã rất thành công trong việc ứng dụng đặc điểm này để tập hợp sự trợ giúp trên nhiều lĩnh vực khác nhau cho các dev nhà ta.

4) Lập trình có thể chia thành 4 giai đoạn

Việc phân chia này khá quan trọng trong việc trợ giúp các hệ thống liên quan đến lập trình và qua đó người quản lý có thể có cái nhìn tổng quan về tiến độ và tính hiệu quả của toàn dự án.

Hơn nữa, việc biết các developer đang ở giai đoạn nào của tiến trình để có thể hỗ trợ khi cần, tránh mất nhiều thời gian vào những điều không cần thiết. Quá trình lập trình có thể chia ra làm 4 giai đoạn như sau:

a) Complex Programming – Lập trình phức tạp b) Making Progress – Có tiến triển c) Slow Progress – Gặp khó khăn d) Stuck – Ngõ cụt

5) Developer thường trả lời không thật lòng khi được hỏi về những khó khăn

Điều này có vẻ khá là hiển nhiên nhưng lại rất quan trọng. Những khó khăn trong quá trình lập trình có thể dẫn đến những vấn đề nghiêm trọng về sự nhiệt tình và tự tin của cả nhóm.

Một trong những khó khăn lớn nhất của việc xác định và phân loại những giới hạn chính là việc những thông tin này có thể là hoàn toàn chủ quan. Hay nói theo cách khác, nếu một lập trình viên được hỏi trực tiếp rằng họ đang gặp phải một giới hạn có thể hay không thể vượt qua chắc chắn sẽ đưa đến một câu trả lời không thật lòng. Lòng tự trọng và đạo đức nghề nghiệp đôi khi cũng có ảnh hưởng đến vấn đề này.

6) Những khó khăn trong lập trình có thể chia làm 6 loại

Bên cạnh việc xác định khả năng vượt qua những khó khăn trong quá trình lập trình, các nghiên cứu còn chỉ ra đặc điểm của những vấn đề có thể gặp phải. Để hiểu rõ hơn về những khó khăn này, các nhà nghiên cứu đã chỉ ra một số câu thường gặp như sau:

a) Design: “Tôi không biết máy tính nên làm gì”. b) Lựa chọn: “Tôi biết phải làm gì nhưng không biết phải sử dụng công cụ nào”. c) Kết hợp: “Tôi biết phải sử dụng những gì nhưng không biết làm thế nào để kết hợp chúng lại với nhau”. d) Sử dụng: “Tôi biết phải sử dụng những gì nhưng không biết sử dụng chúng như thế nào”. e) Hiểu biết: “Tôi nghĩ là tôi biết cách sử dụng X, nhưng nó không như tôi mong đợi”. f) Thông tin: “Tôi biết chuyên gì đang xảy ra nhưng tôi không thể kiểm tra được”.

7) Các lập trình viên dành khoảng 30% thời gian để đọc mã nguồn

Những người lập trình biết rằng việc chỉnh sử công cụ mã nguồn rất quan trọng. Tuy nhiên, thời gian được phân chia như thế nào cho việc chỉnh sửa vần là một dấu hỏi đối với các nhà nghiên cứu.

Dựa trên một nghiên cứu đã được thực hiện, các lập trình viên thường dành khoảng 30% thời gian làm việc để đọc các tập tin trong mã nguốn chứ không phải để viết các dòng lệnh. Việc này liên quan đến nghiên cứu, quan sát, tập hợp thông tin, ghi nhớ và nhiều hoạt động khác. Qua đó, bạn có thể cho rằng việc lập trình là một công việc cần suy nghĩ rất nhiều.

8) Năng suất làm việc của những lập trình viên làm việc từ xa thường thấp hơn so với những người làm in-house

Ý kiến về năng suất làm việc này vẫn đang gây tranh cãi, đặc biệt khi những lập trình viên làm việc ở nhà hay từ xa cũng như những dự án phát triển phần mềm quốc tế đang tăng nhanh hơn bao giờ hết.

Dù sao thì những bằng chứng xác đáng dựa trên các phạm trù của phần mềm chỉ ra rằng trên thực tế nhưng lập trình viên làm việc từ xa làm việc kém năng suất hơn những người làm việc cùng nhau tại một địa điểm.

Tuy nhiên, điều này lại không hợp lý khi chúng ta phân tích những yếu tố khác trong bài viết này, chẳng hạn như xu hướng hạn chế giao tiếp với người khác. Trên thực tế, những đoạn hội thoại đời thường là một yếu tố quan trọng ảnh hưởng đến kết quả của nghiên cứu này. Nguyên nhân có thể là do việc trao đổi những phát hiện của mình trong giờ nghỉ giải lao giữa các cuộc họp tương đối quan trọng.

9) Hầu hết những nhà lập trình là người da trắng, giới tính nam và còn trẻ

Tuyên bố về sự đa dạng trong cộng đồng lập trình viên này không chỉ đến từ các nghiên cứu khoa học mà còn được đưa ra bởi người sáng lập trang web tuyển dụng Skillcrush. Điều này đã được giới thiệu trong video “Liệu CODE có phải là ngôn ngữ quan trọng nhất trên thế giới?”.

Ngày này, rất dễ để phát hiện những nhóm người thiểu số trong cộng đồng lập trình viên, đặc biệt là số lượng phụ nữ. Tuy nhiên, một số dữ liệu lại chỉ ra rằng, đó không phải là nhóm người duy nhất ít góp mặt trong giới lập trình và việc này còn có thể có ảnh hưởng nghiêm trọng khi liên quan đến những đoạn code cho các ứng dụng tiếp cận với một nhóm đối tượng người sử dụng nhất định.

10) Thông báo lỗi, thời gian phát hiện lỗi trình dịch và lỗi chương trình, thời gian trung bình để giải quyết lỗi

Các thông báo lỗi trong các trường hợp lỗi ngôn ngữ và lỗi chương trình khá là cụ thể. Để nêu ra một số trường hợp, các bạn có thể tìm thấy trong luận án thạc sỹ của Suzanne Marie Thompson. Cô ấy đã nghiên cứu rất nhiều lập trình viên Java trong các môi trường và bối cảnh khác nhau để đưa ra nhưng sự thật thú vị về họ.

Mặc dù nghiên cứu này tập trung vào một bối cảnh cụ thể (ngôn ngữ lập trình Java), chúng ta có thể so sánh với những bối cảnh khác và chứng minh được rằng hầu hết những lỗi thông dụng này đều xuất hiện.

11) Hơn 50% công việc là bảo trì phần mềm

Việc bảo trì có liên quan đến việc điều chỉnh “legacy code” (một đoạn code liên quan đến một hệ điều hành không còn được sử dụng hay sản xuất nữa). Một nghiên cứu về chỉ ra rằng có sự mất cần bằng giữa việc viết chương trình và bảo trì nó.

Trong nghiên cứu có chỉ ra 50% công sức của lập trình viên là để bảo trì còn đưa ra một nội dung thảo luận về sự phát triển của phần mềm trong việc bảo trì và sự cần thiết của việc đó. Chắc chắn rằng việc tìm hiểu trước khi đưa ra quyết định đi tìm giải pháp từ một lỗ hổng hay tiếp tục xử lý một nền tảng code có sẵn.

12) Bảo trì phần mềm tiêu tốn từ 40% đên 90% tổng chi phí

Có một trong những quy tắc quan trọng trong giới kinh doanh: việc tìm một khách hàng mới sẽ tốn kém hơn rất nhiều so với việc tiếp tục với một khách hàng cũ. Tuy nhiên, theo các nghiên cứu về kỹ sư phần mềm, thực tế đôi khi trái ngược lại với quy tắc đó khi liên quan đến code. Việc bảo trì có thể chiếm đến 90% tổng giá trí dự án.

Những số liệu này khá phổ biến và được thu thập từ bối cảnh nhất định từ 487 tổ chức nghiên cứu về lĩnh vực này (từ những năm 1980). Chắc chắn rằng có rất nhiều yếu tố cần cân nhắc, nhưng có một điểm khởi đầu để phân tích và thảo luận khi đề cấp đến việc bảo trì phần mềm.

13) Bảo trì phần mềm chia ra làm 4 nhiệm vụ cơ bản

Một nghiên cứu về bảo trì mã nguồn có ảnh hưởng rất lớn đến cộng đồng lập trình viên có phân loại các nhiệm vụ này dựa trên các phiếu câu hỏi về công việc chính của bảo trì phần mềm. 4 nhiệm vụ bao gồm:

a) Cải tiến: Bao gồm những thay đổi về chức năng b) Tính ứng dụng: Những thay đổi để đáp ứng với yêu cầu c) Chỉnh sửa: Khắc phục lỗi d) Phòng tránh: Cải tiến để ngăn chặn các vấn đề có thể phát sinh trong tương lai

Việc phân chia này đặc biệt quan trọng trong việc hỗ trợ đo lường, đánh giá, tổ chức và tìm ra lỗi, nhóm các chức năng trong phiên bản mới và quản lý công việc của lập trình viên.

14) Chi phí cho việc xử lý lỗi trong quá trình sử dụng cao gấp 10 lần so với giai đoạn xây dựng chương trình và gấp 100 lần giai đoạn thiết kế

Sự thật này là một vấn đề cơ bản trong lĩnh vực công nghệ và nó dẫn đến những cải tiến trong quá trình xây dựng phần mềm để đạt đến giai đoạn như ngày nay chúng ta có. Điều quan trọng nhất ở đây là việc nhận thực được cái giá phải trả cao như thế nào khi không chú trọng đến giai đoạn thiết kế và xây dựng.

15) Việc kiểm tra lại có thể phát hiện ra 60% lỗi

Việc kiểm tra lỗi được thực hiện bởi người khác, có thể là người trong nhóm hoặc không, thực sự có hiệu quả. Đã có rất nhiều nghiên cứu về vấn đề này, nhưng một nghiên cứu quan trọng đã chỉ ra rằng 60% lỗi có thể được phát hiện khi có nhiều hơn một người rà soát lại mã nguồn (không nhất thiết là các lỗi phát hiện đều được khắc phục).

Nghiên cứu này cũng đã có từ khá lâu và có thể nói rằng đây là một nghiên cứu có ảnh hưởng lớn đến những kỹ thuật trong quá trình cũng như cách thức viết phần mềm có liên quan đến các hoạt động, các bước và cách tổ chức cũng như các kỹ năng khác không mang tính kỹ thuật cao như lập trình.

Nguồn: http://blog.getlinks.co/vn/15-su-that-ve-nghe-lap-trinh-co-the-ban-chua-bao-gio-de-y/