Chiến đấu với nợ kỹ thuật như nhà phát triển thấp nhất trên thế giới?

Giả sử bạn làm việc cho một công ty và những gì bạn làm là phát triển phần mềm cho họ. Bạn không có ý tưởng về bức tranh lớn hoặc có thể nhẹ. Những gì bạn làm là các nhiệm vụ được giao cho bạn thông qua hệ thống theo dõi vấn đề. Bạn được giao nhiệm vụ, bạn làm cho chúng hoạt động theo cách nhiệm vụ mô tả chúng, bạn gửi lại chúng. Giống như thêm 2 số nguyên:

function add(a,b){return a + b;}

Nhưng sau này, khi dự án tiến triển, bạn nhận thấy rằng khi addtrở nên phức tạp hơn, bạn nhận ra rằng nó cần có một dạng kiến ​​trúc nào đó, không chỉ là một hàm thêm tham số và trả về giá trị. Tuy nhiên, bạn đã không biết điều đó. Ở nơi đầu tiên, tất cả những gì họ cần là đơn giản add. Bạn không mong đợi thêm trở nên phức tạp.

Dự án tiến triển với nhiều tính năng hơn, mà bạn không mong muốn có ở nơi đầu tiên. Và cuối cùng, bạn tiếp tục chồng chất lên các lớp và lớp trên lớp chức năng để tránh phá vỡ / viết lại mã hiện có.

Làm thế nào để bạn đối phó với những tình huống này? Làm thế nào để bạn chống lại nợ kỹ thuật là "nhà phát triển thấp nhất"?

Làm rõ:

• Bạn là "người thực hiện", thấp nhất trong hệ thống phân cấp.

• Bạn thấy vấn đề, nhưng không nói gì với vấn đề này.

• Tôi không định lượng nợ kỹ thuật hoặc tìm kiếm các công cụ.

• Về "bản sao" thứ ba

  • Tái cấu trúc & Viết lại - Bạn bị khóa với các nhiệm vụ của mình. Bạn không được trả tiền để làm thêm.
  • Tổng quan về kiến ​​trúc - Bạn biết hệ thống tổng thể, nhưng không có ý tưởng về kiến ​​trúc.
  • Mã đóng băng - Không phải cuộc gọi của bạn. Bạn không quản lý.
  • Modularization - Không có ý tưởng về kiến ​​trúc. Các mô-đun thay đổi khi yêu cầu thay đổi.
  • Kiểm tra tự động - Không tồn tại.

Mỗi khi bạn nhận thấy điều gì đó tương tự, hãy nhập một vé mới vào hệ thống theo dõi vấn đề của bạn.

Tạo thói quen sử dụng trình theo dõi vấn đề như một công cụ chính để truyền đạt những thứ như vậy, bởi vì từ đó, sẽ dễ dàng chọn, đánh giá và ưu tiên cho các đồng nghiệp cao cấp / lãnh đạo / quản lý / bất kỳ ai chịu trách nhiệm theo dõi các vấn đề trong dự án của bạn .

Sử dụng các công cụ thích hợp cho công việc. Tôi làm điều đó luôn luôn và mạnh mẽ khuyên bạn nên làm như vậy.

Ví dụ, đây là một vé tôi đã tạo ra khoảng một tháng trước. Sau khi hoàn thành tính năng cụ thể, tôi phát hiện ra rằng mã trở nên phức tạp hơn trước đây nhưng tôi không thể sửa nó trong thời hạn đưa ra để thực hiện tính năng.

(Tên của các tính năng, vé và mã được sử dụng trong trình theo dõi thực bị che khuất, nhưng văn bản được sao chép như hiện tại).

Tóm tắt: đơn giản hóa thiết kế liên quan đếnParticularPieceOfCode

Mô tả:
Trong quá trình triển khai theo TICKET-12345, mã liên quan đến việc sử dụng ParticularPieceOfCodetích lũy một chút phức tạp và trở nên khá khó đọc, hiểu và duy trì (xem đoạn mã ví dụ bên dưới).

Tìm cách để đơn giản hóa nó.

Có thể tìm thấy một ví dụ về mã mong muốn thiết kế lại trong ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW lời khuyên của tôi áp dụng độc lập với "cấp độ" của bạn.

Tôi đã sử dụng nó ở cấp độ "thấp nhất" hiện tại của bạn và tôi đang sử dụng nó bây giờ vì cấp độ của tôi khá xa so với "thấp nhất" và tôi đã "nói" thỏa đáng khi bạn gọi nó, và tôi sẽ sử dụng nó luôn luôn không có vấn đề gì

Chỉ cần nghĩ về nó, không có cấp độ, cho dù bạn có bao nhiêu thẩm quyền, không thể có cách nào tốt hơn.

Nếu bạn "nói" này, chúng tôi có một vấn đề , đó chỉ là tiếng rít. Và ngay cả khi sếp / lãnh đạo của bạn đồng ý và nói rằng bạn đúng, chúng tôi đã gặp sự cố , điều này không có gì thay đổi - đó chỉ là tiếng rít lên một lần nữa, và nó không thể là gì khác.

• ^{Bạn có thể nghĩ rằng việc bạn nói bằng văn bản (ví dụ như trong email) sẽ tốt hơn, nhưng nếu bạn nghĩ về nó, nó thực sự không. Nếu dự án của bạn có hoạt động thư đáng kể, những gì đã được viết sẽ bị mất và bị lãng quên một tháng sau đó.}

Sử dụng các công cụ thích hợp cho công việc. Đối với công việc bạn mô tả, trình theo dõi vấn đề chính xác là công cụ phù hợp.

Bạn nhận thấy vấn đề, bạn nhập nó vào hệ thống được thiết kế để theo dõi những vấn đề này và nó sẽ giải quyết phần còn lại, theo cách tốt nhất có thể - đơn giản vì nó được thiết kế cho điều đó :

gói phần mềm máy tính quản lý và duy trì danh sách các vấn đề , cần thiết bởi một tổ chức ... thường được sử dụng ... để tạo, cập nhật và giải quyết các vấn đề của khách hàng được báo cáo hoặc thậm chí các vấn đề được báo cáo bởi các nhân viên khác của tổ chức đó ... hệ thống tương tự như " bugtracker " và thông thường, một công ty phần mềm sẽ bán cả hai và một số trình sửa lỗi có khả năng được sử dụng như một hệ thống theo dõi vấn đề và ngược lại. Việc sử dụng nhất quán một vấn đề hoặc hệ thống theo dõi lỗi được coi là một trong những "dấu hiệu của một nhóm phần mềm tốt" ¹ ...

Dù bạn muốn chọn giao tiếp bằng cách nào khác, việc có một vé trong trình theo dõi sẽ chỉ giúp bạn dễ dàng hơn.

Ngay cả khi bạn thích làm náo loạn không khí , nói rằng "Tôi muốn thảo luận về TICKET-54321 ..." tạo ra một điểm khởi đầu vững chắc hơn so với "Nghe tôi muốn nói về một số đoạn mã tôi đã xử lý trước đây ... "Và bạn có thể chuyển các tài liệu tham khảo đến vé một cách an toàn: ngay cả khi thư bị mất, vấn đề vẫn sẽ có trong trình theo dõi, với tất cả các chi tiết bạn muốn kể.

Điều khiến tôi cảm thấy tồi tệ về kịch bản của bạn là chính xác những gì bạn đã viết trong tiêu đề và nhiều lần trong văn bản câu hỏi:

Bạn là nhà phát triển thấp nhất trong chuỗi

Tại sao điểm đó rất quan trọng? Vâng, trước hết, và từ quan điểm hoàn toàn về mặt kỹ thuật, bạn chắc chắn đúng. Bạn được thuê như những gì bạn gọi là "người thực hiện" mọi thứ, một con ong thợ hoạt động theo các mệnh lệnh được đưa ra.

Nhưng ngay cả khi bạn là nhà phát triển thấp nhất liên quan đến thứ hạng, điều này vẫn không hoàn toàn đúng. Chìa khóa ở đây là nhận ra rằng bạn chỉ nhận thấy mình là nhà phát triển thấp nhất. Bạn đã bao giờ cố gắng vượt qua sự tự nhận thức đó và thực sự chịu trách nhiệm về một cái gì đó ?

Lấy! Không chờ đợi, cho đến khi ai đó làm cho bạn có trách nhiệm.

• Bạn thấy vấn đề, nhưng không nói gì với vấn đề này.
• Tôi không định lượng nợ kỹ thuật hoặc tìm kiếm các công cụ.
• Bạn đang bị khóa với nhiệm vụ của bạn. Bạn không được trả tiền để làm thêm.
• Không phải cuộc gọi của bạn. Bạn không quản lý.

Thông thường thì hoàn toàn ngược lại: Bạn được trả nhiều tiền hơn và ý kiến ​​của bạn được tôn trọng hơn, một khi bạn cho thấy rằng bạn đáng đồng tiền . Đó là "làm trước có", không phải cách khác.

Điều tôi mong đợi từ những người trong nhóm của tôi chính xác là: Ý thức trách nhiệm đối với dự án hoặc sản phẩm chúng tôi đang cố gắng xây dựng và cho tất cả các quy trình liên quan đến nỗ lực đó. Bất cứ khi nào ai đó trong nhóm của tôi gây ấn tượng với tôi bằng cách đảm nhận trách nhiệm, ví dụ như đề xuất cải tiến hoặc thậm chí tốt hơn để tự cải thiện mọi thứ, đây là những người sẽ được thăng chức.

Nói cách khác: Không ai khuyến khích ong thợ, mọi người thụ động chờ đợi nhiệm vụ được giao cho họ, thậm chí không có chớp mắt sáng kiến ​​" vì họ không được trả tiền ", cuối cùng họ than vãn rằng họ không bao giờ có cơ hội.

Tất nhiên, tất cả những điều này một lần nữa phụ thuộc vào văn hóa của công ty bạn, đến những gì Joel liên quan đến trong "Hai câu chuyện" được liên kết bởi Arthur. Nếu các nhà quản lý công ty thực sự ngu ngốc để ngăn chặn người của họ tiến bộ, thì tỷ lệ biến động có lẽ đã rất cao và có lẽ đã đến lúc đưa ra kết luận từ đó. Nhưng nếu đó không phải là vấn đề, vấn đề thực sự có thể nằm ở chính bạn.

Bạn là một người chuyên nghiệp. Chủ của bạn thuê bạn để được chuyên nghiệp. Vì vậy, hãy đối xử với mối quan tâm của bạn giống như cách bạn muốn các chuyên gia bạn thuê để đối xử với các ý kiến chuyên môn của họ . Cụ thể, bạn mong muốn các chuyên gia khác thực hiện các tối ưu hóa và chỉnh sửa cần thiết trên đường đi, miễn là các tối ưu hóa đó không làm tăng chi phí một cách bất ngờ.

Ví dụ, giả sử bạn đưa xe của bạn đến một thợ máy để thay thế đèn. Thợ máy thông báo bốn điều:

1. Dây dẫn đến đèn bị sờn và nguy hiểm. Nhưng, nó có thể được cắt mà không làm tăng đáng kể chi phí. Bạn muốn anh ta mất vài phút để cắt dây, có thể mà không cần chú ý đến nó.
2. Một bu lông bị lỏng. Nó hoàn toàn không liên quan, anh chỉ tình cờ nhìn thấy nó. Đó là 20 giây thời gian của anh ấy để nắm lấy trình điều khiển cần thiết và thắt chặt nó; Vì vậy, bạn mong đợi anh ta làm điều đó.
3. Khung của đèn bị nứt, điều này sẽ khiến đèn bị rít. Nó đắt tiền để thay thế. Và nó không cần thiết. Vì vậy, anh ấy gọi cho bạn để hỏi về điều đó - nếu bạn nói "không", anh ấy đưa ra một đề nghị bằng văn bản về tóm tắt chuyến thăm của bạn.
4. Có một lượng dầu phanh dưới xe. Anh ta nên, và thậm chí có thể được yêu cầu như một chuyên gia, để ngăn bạn sử dụng xe cho đến khi bạn cho phép ai đó sửa chữa rò rỉ.

Mỗi kịch bản này, và tôi chắc chắn các kịch bản khác, có sự tương đồng trong phát triển phần mềm - đặc biệt nếu bạn coi mình là một chuyên gia ở mọi cấp độ . Là một chuyên gia, với rất ít ngoại lệ, công việc của bạn là đạt được mục tiêu cuối cùng là cải thiện sản phẩm theo cách đặc biệt theo sự hiểu biết chuyên môn của bạn .

1. Nếu sửa chữa là không đáng kể, cho dù không liên quan hay không, hãy thực hiện sửa chữa.
2. Nếu việc khắc phục là không tầm thường và không cần thiết, hãy đưa ra khuyến nghị chính thức bằng cách sử dụng bất kỳ cơ chế theo dõi vấn đề / liên lạc chính thức nào mà bạn đã đồng ý.
3. Nếu một trường hợp có thể được thực hiện rằng việc sửa chữa là cần thiết để hoàn thành nhiệm vụ chính, nhưng sẽ bất ngờ tăng chi phí, truyền đạt sự thay đổi phạm vi.
4. Nếu vấn đề được xác định đặt ra một mối đe dọa nghiêm trọng đối với sự thành công của dự án, hãy làm rõ điều đó. Chính thức. Nếu có những lo ngại về đạo đức với việc cho phép vấn đề không được giải quyết (như trong hệ thống y tế, cấp cứu hoặc vận chuyển), hãy nhấn mạnh vào việc giải quyết vấn đề trước khi tàu sản phẩm (thông báo cho giới truyền thông hoặc chính quyền nếu cần thiết về mặt đạo đức).

Bạn làm điều này giống như cách một nhân viên trong văn phòng luật đấu tranh với hành vi phi đạo đức, một nhân viên thức ăn nhanh chống lại hành vi mất vệ sinh hoặc một nhân viên thực thi bãi đậu xe chống lại tham nhũng của cảnh sát.

1. Hãy là một tấm gương tốt. Trong phạm vi bạn có thể, sản xuất mã sạch và hợp lý. Khi được lựa chọn, hãy chọn một trong những đáp ứng yêu cầu của bạn với ít nhược điểm hơn. (Xin lưu ý rằng nợ kỹ thuật không giống như nợ thế chấp - chỉ cần có nó không nhất thiết là điều xấu.)
2. Truyền đạt mối quan tâm của bạn . Bạn nên có ai đó, hoặc là trưởng nhóm hoặc khách hàng hoặc kiến ​​trúc sư, người có trách nhiệm thực sự trong việc quản lý nợ kỹ thuật và phân bổ nguồn lực của doanh nghiệp bạn. Khi bạn thấy một cái gì đó mà bạn tin là xấu, hãy truyền đạt mối quan tâm của bạn đến họ. Đặt nó bằng văn bản (nghĩa là một email) nếu bạn không tự tin rằng họ sẽ hiểu, trả lời và cung cấp tín dụng cho đầu vào của bạn.
3. Đừng căng thẳng. Nợ kỹ thuật hiếm khi gây ra thất bại kết thúc việc làm của một doanh nghiệp. Miễn là bạn đã truyền đạt mối quan tâm của mình và đang thực hiện công việc của mình, các vấn đề về kiến ​​trúc như nợ kỹ thuật thực sự không phải là vấn đề của bạn. Vâng, họ có thể ảnh hưởng đến bạn, nhưng họ không còn lo lắng hơn cuộc bầu cử lại của cảnh sát trưởng là nỗi lo của một sĩ quan cảnh sát cơ sở.

Trong ví dụ bạn cung cấp, với một addchức năng đã bị creep tính năng hoàn chỉnh, hãy dành vài phút và phác thảo phác thảo về những gì sẽ cải thiện nó. Gửi nó cho bất cứ ai bạn cần phê duyệt để thực hiện nó, và tiếp tục.

Giả sử doanh nghiệp của bạn được quản lý bởi những người cực kỳ có năng lực và được cấu trúc chính xác, mối quan tâm của bạn sẽ được chuyển đến nhà thiết kế hệ thống phù hợp để đưa ra quyết định hoặc bạn sẽ được đưa ra để thực hiện đề xuất của mình. Là một nhà phát triển cơ sở, tôi lo lắng nhiều hơn về việc tìm hiểu cách thức hoạt động của doanh nghiệp so với nợ kỹ thuật - và nếu bạn biết trước đây, cách xử lý sau sẽ rõ ràng.

Tôi chưa bao giờ nghe nói về một tổ chức không muốn nhân viên của mình tham gia. Bạn nói rằng bạn chỉ được trả tiền để thực hiện các nhiệm vụ. Tôi chân thành nghi ngờ bạn có nhiệm vụ đúng trong tâm trí. Bởi vì bạn được trả tiền để viết phần mềm tốt.

Chịu trách nhiệm này. Nói không với việc thêm tính năng nếu bạn không thể hỗ trợ cơ sở. Tư vấn cho khách hàng với chuyên môn của bạn. Hãy đạp phanh ngay bây giờ, trước khi quá muộn và bạn phải vứt bỏ toàn bộ dự án, bởi vì nó sẽ không còn có thể bảo trì được nữa.