Kể từ đầu năm 2018, tôi đã giữ vị trí trưởng/sếp/trưởng nhóm phát triển trong nhóm - bạn muốn gọi thế nào cũng được, nhưng vấn đề là tôi hoàn toàn chịu trách nhiệm về một trong các mô-đun và về tất cả các nhà phát triển làm việc. trên đó. Vị trí này mang lại cho tôi một góc nhìn mới về quá trình phát triển, khi tôi tham gia vào nhiều dự án hơn và tham gia tích cực hơn vào việc ra quyết định. Gần đây, nhờ hai điều này, tôi chợt nhận ra thước đo hiểu biết ảnh hưởng đến code và ứng dụng đến mức nào.
Điểm tôi muốn nhấn mạnh là chất lượng của mã (và sản phẩm cuối cùng) có liên quan chặt chẽ đến mức độ nhận thức của những người đang thiết kế và viết mã về những gì họ đang làm.
Có thể lúc này bạn đang nghĩ: “Cảm ơn, Cap. Tất nhiên, sẽ rất tốt nếu hiểu được những gì bạn đang viết nói chung. Nếu không, bạn cũng có thể thuê một nhóm khỉ đánh các phím tùy ý và để nó ở đó.” Và bạn hoàn toàn đúng. Theo đó, tôi cho rằng bạn nhận ra rằng việc có ý tưởng chung về việc mình đang làm là cần thiết. Đây có thể được gọi là mức độ hiểu biết bằng XNUMX và chúng tôi sẽ không phân tích nó một cách chi tiết. Chúng tôi sẽ xem xét chi tiết chính xác những gì bạn cần hiểu và nó ảnh hưởng như thế nào đến các quyết định bạn đưa ra hàng ngày. Nếu tôi biết trước những điều này, nó sẽ giúp tôi tiết kiệm rất nhiều thời gian lãng phí và những đoạn mã đáng nghi vấn.
Mặc dù bạn sẽ không thấy một dòng mã nào bên dưới, nhưng tôi vẫn tin rằng mọi thứ được nói ở đây đều có tầm quan trọng rất lớn để viết mã có chất lượng cao, mang tính biểu cảm.
Mức độ hiểu biết đầu tiên: Tại sao nó không hoạt động?
Các nhà phát triển thường đạt đến cấp độ này từ rất sớm trong sự nghiệp của họ, đôi khi thậm chí không cần bất kỳ sự trợ giúp nào từ người khác - ít nhất là theo kinh nghiệm của tôi. Hãy tưởng tượng rằng bạn nhận được một báo cáo lỗi: một số chức năng trong ứng dụng không hoạt động, nó cần được sửa. Bạn sẽ tiến hành như thế nào?
Sơ đồ tiêu chuẩn trông như thế này:
- Tìm đoạn mã gây ra sự cố (cách thực hiện việc này là một chủ đề riêng, tôi trình bày nó trong cuốn sách về mã kế thừa của mình)
- Thực hiện thay đổi đối với đoạn mã này
- Đảm bảo rằng lỗi đã được sửa và không có lỗi hồi quy nào xảy ra
Bây giờ hãy tập trung vào điểm thứ hai - thực hiện các thay đổi đối với mã. Có hai cách tiếp cận quá trình này. Đầu tiên là đi sâu vào chính xác những gì đang xảy ra trong mã hiện tại, xác định lỗi và sửa nó. Thứ hai: di chuyển theo cảm nhận - thêm, chẳng hạn, +1 vào một câu lệnh hoặc vòng lặp có điều kiện, xem liệu hàm có hoạt động trong kịch bản mong muốn hay không, sau đó thử cái gì khác, v.v.
Cách tiếp cận đầu tiên là chính xác. Như Steve McConnell giải thích trong cuốn sách Code Complete của mình (nhân tiện, tôi rất khuyến khích điều này), mỗi khi chúng ta thay đổi điều gì đó trong mã, chúng ta có thể tự tin dự đoán nó sẽ ảnh hưởng đến ứng dụng như thế nào. Tôi đang trích dẫn từ trí nhớ, nhưng nếu một bản sửa lỗi không hoạt động như bạn mong đợi, bạn sẽ hết sức cảnh giác và nên đặt câu hỏi về toàn bộ kế hoạch hành động của mình.
Tóm lại những gì đã nói, để thực hiện sửa lỗi tốt mà không làm giảm chất lượng mã, bạn cần hiểu cả toàn bộ cấu trúc của mã và nguồn gốc của vấn đề cụ thể.
Cấp độ hiểu biết thứ hai: Tại sao nó lại có tác dụng?
Cấp độ này được hiểu ít trực quan hơn nhiều so với cấp độ trước. Tôi, khi vẫn còn là một nhà phát triển mới vào nghề, đã học được điều đó nhờ sếp của mình và sau đó liên tục giải thích bản chất của vấn đề cho những người mới đến.
Lần này, hãy tưởng tượng rằng bạn nhận được hai báo cáo lỗi cùng một lúc: báo cáo đầu tiên là về kịch bản A, báo cáo thứ hai là về kịch bản B. Trong cả hai trường hợp, đều có điều gì đó không ổn xảy ra. Theo đó, bạn xử lý lỗi đầu tiên trước tiên. Bằng cách sử dụng các nguyên tắc mà chúng tôi đã phát triển để hiểu Cấp độ XNUMX, bạn tìm hiểu sâu về mã có liên quan đến vấn đề, tìm hiểu lý do tại sao nó khiến ứng dụng hoạt động theo cách nó hoạt động trong Kịch bản A và thực hiện các điều chỉnh hợp lý để tạo ra kết quả mà bạn mong đợi. . Mọi thứ đang diễn ra tuyệt vời.
Sau đó, bạn chuyển sang kịch bản B. Bạn lặp lại kịch bản đó nhằm cố gắng gây ra lỗi, nhưng—ngạc nhiên thay! - bây giờ mọi thứ hoạt động như bình thường. Để xác nhận dự đoán của mình, bạn hoàn tác những thay đổi bạn đã thực hiện khi xử lý lỗi A và lỗi B sẽ quay trở lại. Bản sửa lỗi của bạn đã giải quyết được cả hai vấn đề. May mắn!
Bạn đã không tính đến điều này chút nào. Bạn đã nghĩ ra cách sửa lỗi trong kịch bản A và không biết tại sao nó lại hiệu quả với kịch bản B. Ở giai đoạn này, bạn rất dễ nghĩ rằng cả hai nhiệm vụ đều đã được hoàn thành xuất sắc. Điều này khá hợp lý: mục đích là để loại bỏ lỗi phải không? Nhưng công việc vẫn chưa kết thúc: bạn vẫn phải tìm hiểu xem tại sao hành động của mình lại sửa được lỗi trong tình huống B. Tại sao? Bởi vì nó có thể hoạt động theo những nguyên tắc sai lầm, và khi đó bạn sẽ cần phải tìm kiếm một lối thoát khác. Dưới đây là một vài ví dụ về những trường hợp như vậy:
- Vì giải pháp không được điều chỉnh cho phù hợp với lỗi B nên khi tính đến tất cả các yếu tố, bạn có thể đã vô tình làm hỏng chức năng C.
- Có thể còn có một lỗi thứ ba đang ẩn nấp ở đâu đó, liên quan đến cùng một chức năng và việc sửa lỗi của bạn phụ thuộc vào lỗi đó để hệ thống hoạt động chính xác trong kịch bản B. Hiện tại mọi thứ có vẻ ổn nhưng một ngày nào đó lỗi thứ ba này sẽ được phát hiện và sửa chữa. Sau đó, trong kịch bản B, lỗi sẽ xảy ra lần nữa và nếu chỉ ở đó thì tốt.
Tất cả điều này làm tăng thêm sự hỗn loạn cho mã và một ngày nào đó sẽ rơi vào đầu bạn - rất có thể là vào thời điểm không thích hợp nhất. Bạn sẽ phải huy động sức mạnh ý chí của mình để buộc bản thân dành thời gian tìm hiểu lý do tại sao mọi thứ dường như đều hiệu quả, nhưng nó đáng giá.
Mức độ hiểu biết thứ ba: Tại sao nó hoạt động?
Cái nhìn sâu sắc gần đây của tôi liên quan chính xác đến cấp độ này và có lẽ nó sẽ mang lại cho tôi nhiều lợi ích nhất nếu tôi nảy ra ý tưởng này sớm hơn.
Để rõ ràng hơn, hãy xem một ví dụ: mô-đun của bạn cần phải tương thích với hàm X. Bạn không đặc biệt quen thuộc với hàm X, nhưng bạn được thông báo rằng để tương thích với nó, bạn cần sử dụng khung F. Khác các mô-đun tích hợp với X hoạt động chính xác với anh ta.
Mã của bạn chưa có bất kỳ liên hệ nào với khung F kể từ ngày đầu tiên ra đời, vì vậy việc triển khai nó sẽ không dễ dàng như vậy. Điều này sẽ gây ra hậu quả nghiêm trọng đối với một số phần của mô-đun. Tuy nhiên, bạn lao mình vào quá trình phát triển: bạn dành hàng tuần để viết mã, thử nghiệm, triển khai các phiên bản thử nghiệm, nhận phản hồi, sửa lỗi hồi quy, phát hiện các biến chứng không lường trước được, không đáp ứng thời hạn đã thỏa thuận ban đầu, viết thêm một số mã, thử nghiệm, nhận thông tin phản hồi, sửa lỗi hồi quy - tất cả điều này để triển khai khung F.
Và đến một lúc nào đó, bạn chợt nhận ra - hoặc có thể nghe được từ ai đó - rằng có thể framework F sẽ không cung cấp cho bạn khả năng tương thích với tính năng X. Có lẽ tất cả thời gian và công sức đó đã được dồn vào hoàn toàn sai lầm.
Điều tương tự đã xảy ra một lần khi đang thực hiện một dự án mà tôi chịu trách nhiệm. Tại sao điều này xảy ra? Bởi vì tôi chưa hiểu rõ hàm X là gì và nó liên quan như thế nào đến framework F. Lẽ ra tôi phải làm gì? Yêu cầu người giao nhiệm vụ phát triển giải thích rõ ràng cách thức hành động dự định sẽ dẫn đến kết quả mong muốn, thay vì chỉ lặp lại những gì đã được thực hiện cho các mô-đun khác hoặc tin rằng đây là tính năng X cần làm.
Kinh nghiệm của dự án này đã dạy tôi từ chối bắt đầu quá trình phát triển cho đến khi chúng tôi hiểu rõ lý do tại sao chúng tôi được yêu cầu làm một số việc nhất định. Từ chối thẳng thừng. Khi nhận được một nhiệm vụ, điều thôi thúc đầu tiên là bạn phải thực hiện ngay để không lãng phí thời gian. Nhưng chính sách “đóng băng dự án cho đến khi chúng tôi đi sâu vào tất cả các chi tiết” có thể giảm đáng kể thời gian lãng phí.
Ngay cả khi họ cố gắng gây áp lực cho bạn, buộc bạn phải bắt đầu công việc, mặc dù bạn không hiểu lý do cơ bản của việc này, hãy phản kháng. Đầu tiên, hãy tìm hiểu lý do tại sao bạn được giao nhiệm vụ như vậy và quyết định xem đây có phải là con đường đúng đắn để đạt được mục tiêu hay không. Tôi đã phải học tất cả những điều này một cách khó khăn - tôi hy vọng ví dụ của tôi sẽ giúp cuộc sống của những ai đọc nó dễ dàng hơn.
Mức độ hiểu biết thứ tư: ???
Luôn luôn có nhiều thứ để học trong lập trình và tôi tin rằng tôi chỉ mới hiểu sơ qua về chủ đề hiểu biết. Bạn đã khám phá được những mức độ hiểu biết nào khác sau nhiều năm làm việc với mã? Bạn đã đưa ra những quyết định nào có tác động tích cực đến chất lượng của mã và ứng dụng? Những quyết định nào hóa ra là sai lầm và dạy cho bạn một bài học quý giá? Chia sẻ kinh nghiệm của bạn trong các ý kiến.
Nguồn: www.habr.com