Làm thế nào để bạn cân bằng giữa những người làm điều đó đúng, và làm điều đó càng sớm càng tốt trong công việc hàng ngày của bạn? [đóng cửa]


180

Thỉnh thoảng tôi lại suy nghĩ về câu hỏi này, hết lần này đến lần khác. Tôi muốn làm mọi thứ đúng cách: viết mã sạch, dễ hiểu và chính xác, dễ bảo trì. Tuy nhiên, những gì tôi kết thúc là viết bản vá trên một bản vá; chỉ vì không có thời gian, khách hàng đang chờ đợi, một lỗi nên được khắc phục qua đêm, công ty đang mất tiền cho vấn đề này, một người quản lý đang nhấn mạnh, v.v.

Tôi biết rất rõ rằng về lâu dài tôi đang lãng phí nhiều thời gian hơn cho các bản vá này, nhưng vì thời gian này kéo dài hàng tháng làm việc, không ai quan tâm. Ngoài ra, như một trong những người quản lý của tôi đã từng nói: "chúng tôi không biết liệu sẽ có dài hạn hay không nếu chúng tôi không sửa chữa nó ngay bây giờ."

Tôi chắc chắn rằng tôi không phải là người duy nhất bị cuốn vào những chu kỳ lựa chọn thực tế / lý tưởng vô tận này. Vì vậy, làm thế nào để bạn, các lập trình viên đồng nghiệp của tôi, đối phó với điều này?

CẬP NHẬT: Cảm ơn tất cả các bạn cho cuộc thảo luận thú vị này. Thật đáng buồn khi rất nhiều người phải lựa chọn hàng ngày giữa số lượng và chất lượng mã của họ. Tuy nhiên, nhiều người ngạc nhiên, mọi người nghĩ rằng có thể giành chiến thắng trong trận chiến này, vì vậy cảm ơn tất cả các bạn vì sự khích lệ này.


12
Đơn giản: làm điều đó đúng làm điều đó nhanh
ren

158
@ren: Chà, tôi cho rằng bạn không phải là lập trình viên, bạn là người quản lý :-)
Flot2011

44
Bắt buộc. xkcd.com/844
MikeTheLiar

5
Làm điều đó càng sớm càng tốt. Sau đó, nếu bạn vẫn còn thời gian, hãy làm điều đó đúng.
Laurent Couvidou

8
Như chú bob nói: Con đường chậm là con đường nhanh. Dành thời gian để viết các bài kiểm tra đơn vị đó và viết mã của bạn thật tốt. Điều này có thể khiến tính năng này mất thêm thời gian để triển khai tính năng này, nhưng sẽ tiết kiệm thời gian trong thời gian dài vì người khác sẽ dễ dàng sửa đổi và sửa lỗi hơn.
martiert

Câu trả lời:


106

Thật ra, đây là một câu hỏi rất khó vì không có câu trả lời hoàn toàn đúng. Trong tổ chức của chúng tôi, chúng tôi đã đưa ra các quy trình tốt hơn để tạo ra mã tốt hơn. Chúng tôi đã cập nhật các tiêu chuẩn mã hóa của mình để phản ánh cách chúng tôi, với tư cách là một nhóm, viết mã và chúng tôi đã thiết lập một vòng lặp kiểm tra / tái cấu trúc / thiết kế / mã rất mạnh. Chúng tôi cung cấp liên tục hoặc ít nhất là cố gắng. Ít nhất, chúng tôi có một cái gì đó để hiển thị các bên liên quan cứ sau hai tuần. Chúng tôi cảm thấy rằng chúng tôi là thợ thủ công phần mềm và tinh thần rất cao. Nhưng, mặc dù tất cả các kiểm tra và số dư này, chúng tôi chịu cùng một vấn đề bạn làm.

Vào cuối ngày, chúng tôi đang cung cấp một sản phẩm cho một khách hàng trả tiền. Khách hàng này có nhu cầu và mong đợi, thực tế hay không. Thường thì đội ngũ bán hàng khiến chúng tôi gặp rắc rối chỉ để nhận tiền hoa hồng. Đôi khi khách hàng có những kỳ vọng trực tiếp không thực tế hoặc thay đổi nhu cầu mặc dù chúng tôi có hợp đồng. Mốc thời gian xảy ra. PTO và mất ngày trong một lần chạy nước rút có thể xảy ra. Tất cả các loại việc nhỏ có thể lên đến đỉnh điểm trong một tình huống mà chúng ta bị ép buộc vào câu hỏi hóc búa "làm đúng" hoặc "làm điều đó càng sớm càng tốt". Hầu như luôn luôn, chúng tôi buộc phải "làm điều đó càng sớm càng tốt".

Là thợ thủ công phần mềm, nhà phát triển, lập trình viên, những người viết mã cho một công việc - đó là thiên hướng tự nhiên của chúng tôi để "làm đúng". "Làm điều đó càng sớm càng tốt" là những gì xảy ra khi chúng ta làm việc để tồn tại, như hầu hết chúng ta làm. Sự cân bằng là khó khăn.

Tôi luôn bắt đầu bằng cách tiếp cận quản lý điều hành (tôi là Giám đốc Phát triển Phần mềm và là nhà phát triển tích cực trong nhóm đó) để bảo vệ lịch trình, nhóm và công việc đang được thực hiện. Thông thường vào thời điểm đó tôi đã nói với khách hàng phải có nó ngay bây giờ và nó phải hoạt động. Khi tôi biết không có chỗ để thương lượng hay cho, tôi quay lại và làm việc với nhóm để xem những góc nào có thể được cắt. Tôi sẽ không hy sinh chất lượng trong tính năng thúc đẩy nhu cầu của khách hàng để có được nó càng sớm càng tốt, nhưng một cái gì đó sẽ đi và nó sẽ bị đẩy vào một cuộc đua nước rút khác. Điều này hầu như luôn luôn OK.

Khi bạn không thể cung cấp vì có quá nhiều lỗi, chất lượng mã kém và ngày càng tệ hơn và các mốc thời gian ngày càng ngắn hơn, thì bạn đang ở trong một tình huống khác với những gì tôi mô tả. Trong trường hợp đó, quản lý sai lầm hiện tại hoặc trong quá khứ, thực tiễn phát triển kém dẫn đến chất lượng mã kém hoặc các yếu tố khác có thể đưa bạn vào cuộc hành quân chết chóc.

Ý kiến ​​của tôi ở đây là làm hết sức mình để bảo vệ mã tốt và thực hành tốt nhất để bắt đầu kéo công ty của bạn ra khỏi chiến hào. Nếu không có một đồng nghiệp nào sẵn sàng lắng nghe hoặc làm nũng cho nhóm chống lại quản lý, thì có lẽ đã đến lúc bắt đầu tìm kiếm một công việc mới.

Cuối cùng, cuộc sống thực sự vấp ngã tất cả. Nếu bạn đang làm việc cho một công ty cần bán những gì bạn đang phát triển, thì bạn sẽ gặp phải sự đánh đổi này hàng ngày. Chỉ bằng cách phấn đấu để sớm đạt được các nguyên tắc phát triển tốt, tôi mới thành công trong việc đi trước đường cong chất lượng mã.

Sự thúc đẩy giữa các nhà phát triển và nhân viên bán hàng làm tôi nhớ đến một trò đùa. "Sự khác biệt giữa một nhân viên bán xe đã qua sử dụng và một nhân viên bán phần mềm là gì? Ít nhất là nhân viên bán xe đã qua sử dụng biết rằng anh ta đang nói dối." Giữ cằm của bạn và cố gắng "làm điều đúng đắn" khi bạn đi.


14
"Thường thì đội ngũ bán hàng khiến chúng tôi gặp rắc rối chỉ để nhận tiền hoa hồng" - Tại thời điểm nào bạn sẽ nghĩ rằng việc bán hàng phải chịu trách nhiệm bán một thứ gì đó mà doanh nghiệp không thể cung cấp - giả sử có một? Bạn có ví dụ về việc họ đã vượt qua ranh giới giữa tiếp thị tích cực và bán quá mức không?
Tom W

8
@TomW Tôi có một vài ví dụ cụ thể, những chi tiết cụ thể mà tôi không thể đăng ở đây nhưng khi nó xảy ra thì hầu như luôn xảy ra khi chúng tôi cần một tài khoản tham chiếu hoặc gần cuối quý. Chúng tôi có một số người bán hàng rất tốt và một số người không tốt. Gần đây đã có một sự thay đổi lớn trong việc dọn dẹp nhà cửa một khi đã xác định rằng Phát triển không phải là vấn đề và toàn bộ cấu trúc bán hàng đã thay đổi tốt hơn. Mọi thứ đã diễn ra tuyệt vời kể từ đó. Tôi muốn được cụ thể hơn nhưng tôi không thể.
Akira71

9
+1 - "Tôi sẽ không hy sinh chất lượng trong tính năng đang thúc đẩy khách hàng cần có được nó càng sớm càng tốt, nhưng điều gì đó sẽ đi" ... thật tuyệt vời.
Joel B

59
@TomW - Tôi luôn muốn chỉ ra rằng kiến ​​trúc sư hải quân trưởng của Titanic đã cảnh báo chống cắt giảm chi phí (Thomas Andrew) đã xuống tàu trong khi người bán hàng / tiếp thị hàng đầu đã thúc giục cắt giảm chi phí và hoàn thành công việc càng sớm càng tốt (Bruce Ismay) trong một chiếc xuồng cứu sinh.
jfrankcarr

4
Tôi rất thích có thời gian gõ một câu trả lời như thế này, nhưng tôi có một khách hàng đang nói với sếp của tôi qua điện thoại. "Thường thì đội ngũ bán hàng khiến chúng tôi gặp rắc rối chỉ để nhận tiền hoa hồng." Tương tự ở đây ... nhưng bằng cách nào đó họ vẫn nhận được những phần thưởng đó!
Kenzo

62

Một điều tôi đã nhận ra trong sự nghiệp của mình là luôn có thời gian để làm điều đó đúng. Vâng, người quản lý của bạn có thể đang đẩy. Các khách hàng có thể được tức giận. Nhưng họ không biết mọi thứ sẽ mất bao lâu. Nếu bạn (nhóm nhà phát triển của bạn) không làm điều đó, nó sẽ không được thực hiện; bạn giữ tất cả các đòn bẩy.

Bởi vì bạn biết điều gì thực sự sẽ khiến người quản lý của bạn đẩy bạn hoặc khách hàng của bạn tức giận? Chất lượng kém .


43
Mặc dù thường có thời gian để làm một công việc tốt, nhưng thường không có thời gian để làm điều đó một cách hoàn hảo. Có một thế giới khác biệt giữa hai.
Donal Fellows

2
@DonalFellows tất nhiên. "Quyền" luôn luôn "tuân theo các thực tiễn tốt nhất, sử dụng sự hiểu biết tốt nhất của chúng tôi về vấn đề tại thời điểm này, với khả năng tốt nhất của chúng tôi". Mọi người mắc sai lầm. Yêu cầu thay đổi. Thực hành tốt nhất thay đổi. Không cắt góc và cấu trúc lại khi những thứ xảy ra.
Telastyn

3
@DonalFellows - "Kẻ thù của sự xuất sắc là sự hoàn hảo". Một chương trình được viết theo kiểu có thể bảo trì, đáp ứng yêu cầu của khách hàng và thực hiện với hiệu suất chấp nhận được, là một chương trình được "thực hiện". Không có gì ngà tháp về nó.
KeithS

1
@DonalFellows Không ai sử dụng từ hoàn hảo, một giải pháp hoàn hảo là một giải pháp sai, Telastyn đang nói về một giải pháp đúng. Giải pháp phù hợp là giải pháp đáp ứng yêu cầu và không có khả năng gây ra sự cố trong tương lai trong khi dễ xử lý trong trường hợp xảy ra. Tuyệt đối luôn luôn sai.
Jimmy Hoffa

7
+1 - Đối với Telastyn, trong khi tất cả khách hàng muốn công cụ của họ được thực hiện ngay bây giờ. HÃY NHIỀU khách hàng muốn công cụ của họ hoạt động nhiều hơn là hoàn thành nó ngay bây giờ. Dường như tất cả những người không đồng ý với Telastyn đều tuyên bố rằng họ sẽ mất một khách hàng nếu điều đó không được thực hiện nhanh chóng. Đó là ngoại lệ và không phải là quy tắc. Quy tắc là gì, mà hầu hết những người không đồng ý, là họ đang phớt lờ rằng họ sẽ mất nhiều khách hàng hơn bằng cách cung cấp các sản phẩm kém chất lượng. Khiếu nại mà khách hàng muốn bây giờ là lý do thông thường của những người không quan tâm đến chất lượng. Vì vậy, tôi nghi ngờ về rủi ro được yêu cầu.
Dunk

21

Điều này dẫn đến những gì tôi đã bắt đầu nghĩ là "Xung đột vĩnh cửu" (giữa kinh doanh và kỹ thuật). Tôi không có giải pháp vì đây là vấn đề không bao giờ biến mất nhưng bạn có thể làm mọi thứ để giúp giảm thiểu.

  • Truyền đạt giá trị

Điều mọi người thường không nhận ra là với tư cách là các kỹ sư, chúng tôi chỉ cho rằng vấn đề "kinh doanh thành công" luôn là vấn đề được đưa ra. Chúng tôi muốn mã của chúng tôi phải đẹp, gọn gàng và có thể bảo trì để chúng tôi có thể nhanh chóng thêm các tính năng mới và điều chỉnh các tính năng hiện có và với tối thiểu khách hàng thực hiện QA cho chúng tôi bằng cách khám phá các trường hợp rìa kỳ quái sẽ bị cản trở bởi mã tốt hơn. Giữ khách hàng và duy trì lợi thế cạnh tranh với các tính năng và sự tinh tế không ai khác có thể sản xuất đủ nhanh là cả hai chiến thắng kinh doanh mà mã tốt trực tiếp đóng góp và thông báo nhiều lý do chúng tôi muốn mã tốt hơn ngay từ đầu.

Vì vậy, đánh vần nó ra. "Chúng tôi muốn thực hiện X trong cơ sở mã của mình bởi vì nếu chúng tôi không làm điều đó sẽ ảnh hưởng tiêu cực đến doanh nghiệp do Y" hoặc "... bởi vì điều đó sẽ tăng cường khả năng cạnh tranh của chúng tôi bằng cách cải thiện khả năng của chúng tôi để cải thiện các tính năng và cải tiến mới nhanh hơn . "

Và cố gắng hết sức để thử và có được bằng chứng hữu hình rằng các cải tiến đang hoạt động. Nếu việc cải thiện một số tập hợp con của ứng dụng dẫn đến tính năng / cải tiến nhanh hơn, hãy kiểm tra bất kỳ công cụ tồn đọng nào bạn có thể đang sử dụng để làm bằng chứng và chỉ ra nó trong các cuộc họp thích hợp.

  • Nhận nhóm trên cùng một trang chết tiệt

Egos thường là một vấn đề. Một điều mà các đội kỹ thuật rất cần là thiết lập giá trị của việc có một số cách tiếp cận nhất quán theo thỏa thuận để giải quyết một số loại vấn đề đối với mọi người khi thực hiện tách Kool Aid của riêng họ vì họ biết rõ hơn. Bạn có thể tin rằng sở thích của người kia tệ hơn bạn nhưng giá trị nhất quán hơn là đúng nếu cách tiếp cận của anh ta khả thi và đó là một lý lẽ bạn không thể thắng. Thỏa hiệp vì lợi ích của sự nhất quán là chìa khóa. Khi mọi thứ đều nhất quán, khó có thể làm sai vì cách thiết lập nhất quán thường cũng sẽ là cách nhanh nhất.

  • Chọn công cụ phù hợp

Có hai trường khung / bộ công cụ / thư viện / bất cứ điều gì. "Đặt 99% số tiền đó cho tôi để tôi phải biết / làm rất ít" so với "tránh xa tôi khi tôi không muốn bạn ở đó, nhưng hãy giúp tôi DIY rất nhanh chóng và nhất quán với những thứ tôi thực sự muốn để sử dụng trên cà rốt chứ không phải là nguyên tắc dính. " Ủng hộ cái thứ hai. Không bao giờ nên hy sinh tính linh hoạt và kiểm soát chi tiết tại bàn thờ của sự quay vòng nhanh chóng bởi vì với biz, "chúng ta không thể làm điều này bởi vì các công cụ của chúng ta sẽ không cho phép chúng ta" không bao giờ là câu trả lời chấp nhận được và câu hỏi sẽ luôn được đưa ra cho kỹ thuật sản phẩm tầm thường / dùng một lần. Theo kinh nghiệm của tôi, các công cụ không linh hoạt hầu như luôn được mở rộng hoặc làm việc không ngừng nghỉ và tạo ra một mớ hỗn độn lớn không thể nhầm lẫn. Thường xuyên hơn không, các giải pháp linh hoạt / dễ dàng hơn để sửa đổi chỉ là hoặc gần như nhanh chóng trong thời gian ngắn, bất kể. Nhanh chóng, linh hoạt và có thể bảo trì là có thể với các công cụ phù hợp.

  • FFS, nếu các kỹ sư không quyết định, ít nhất hãy lấy kỹ sư nhập liệu vào việc chọn công cụ

Tôi hiểu rằng đây là một câu hỏi về quan điểm của nhà phát triển nhưng tôi đã gặp quá nhiều tình huống trong đó các quyết định công nghệ được đưa ra với đầu vào kỹ sư bằng không. Cái quái gì thế? Vâng, cuối cùng ai đó phải thực hiện cuộc gọi cuối cùng, nhưng nhận được một số ý kiến ​​đủ điều kiện nếu bạn là người quản lý phi kỹ thuật, không phải những gì một người bán hàng hoặc trang web demo nói về sản phẩm của chính họ. Bất cứ điều gì hứa hẹn sẽ giúp bạn tiết kiệm tiền vì mọi người không cần phải thông minh hoặc bởi vì nó bảo vệ các nhà phát triển khỏi chính họ là một lời nói dối bẩn thỉu, bẩn thỉu. Thuê tài năng bạn có thể tin tưởng. Đánh vần với họ những gì bạn muốn từ một ngăn xếp hoặc giải pháp công nghệ khác và thực hiện nghiêm túc đầu vào của họ trước khi quyết định nhóm nhạc công nghệ nào sẽ nhảy vào.

  • Tập trung vào thiết kế thực hiện

Các công cụ là để thực hiện và như vậy chúng có thể giúp bạn, nhưng ưu tiên hàng đầu phải là kiến ​​trúc bất kể bạn có bất kỳ bộ đồ chơi nào để xây dựng kiến ​​trúc đó. Vào cuối ngày, KISS và DRY và tất cả các triết lý xuất sắc mở rộng từ những vấn đề đó nhiều hơn là dù là trong .NET hay Java hay có lẽ là thứ gì đó miễn phí VÀ không hút.

  • Đăng nhập mối quan tâm của bạn

Khi phía biz khăng khăng bạn làm điều đó theo cách xấu, hãy lưu e-mail đó, đặc biệt là phần bạn nói tại sao nó sẽ khiến bạn phải trả giá. Khi tất cả các dự đoán của bạn trở thành sự thật và gây ra các vấn đề nghiêm trọng về kinh doanh, đó là khi bạn có một đống lý lẽ lớn để khiến các kỹ sư lo ngại nghiêm trọng hơn. Nhưng thời gian mọi thứ cẩn thận. Ở giữa địa ngục rực sáng là thời điểm tồi tệ cho một "I-Tell-you-so" về việc tuân theo mã lửa. Hãy dập tắt và đưa danh sách các mối quan tâm bị bỏ qua trước đó của bạn đến một cuộc họp / cuộc trò chuyện hồi tưởng, và cố gắng tập trung vào các mối quan tâm kỹ thuật được thể hiện và bỏ qua và lý do bạn hiểu tại sao chúng bị bỏ qua, không phải tên của những người thực tế đưa ra quyết định bỏ qua. Bạn là một kỹ sư. Ở lại trên các vấn đề, không phải là người dân. " Chúng tôi bày tỏ sự lo lắng về X vì chúng tôi sợ nó sẽ dẫn đến các vấn đề về Y. Chúng tôi đã nói với Z và ngừng giao dịch với nó. "


Câu trả lời rất hay và sâu sắc. Tôi có thể nói thêm rằng tôi đã trải qua một trường hợp xấu khi chọn đúng công cụ , điều đó gây ra sự lãng phí lớn thời gian. Chúng tôi có thể giao sản phẩm một tháng sau đó, sau khi quyết định được đưa ra là chúng tôi từ bỏ sản phẩm này và sử dụng thứ gì đó không khóa chúng tôi.
mh

1
Tôi cảm thấy tốt về câu trả lời này nhưng tôi cũng vừa tìm được công việc đầu tiên của mình khi biz và dev không liên tục ở bên nhau và tác động rất thú vị. Chúng tôi chỉ cần hoàn thành công việc. Không phải luôn luôn sớm như chúng tôi muốn nhưng chúng tôi thực sự tính đến tương lai và nó thể hiện cả trong sản phẩm và khả năng sửa đổi nó khi nhu cầu thay đổi. Big Ball of Mud không thể tránh khỏi là một lời nói dối, IMO.
Erik Reppen

19

Chỉ có duy nhất một giải pháp. Dành khoảng 10-20% thời gian dự án / công việc để tái cấu trúc. Nếu khó thuyết phục ban quản lý rằng đó là một nhiệm vụ chính đáng, hãy cho họ lập luận thực sự duy nhất: không tái cấu trúc chi phí bảo trì mã sẽ tăng theo cấp số nhân theo thời gian. Thật tốt khi có một vài số liệu / bài báo / kết quả nghiên cứu để sao lưu luận điểm này trong cuộc họp với người quản lý :)

Chỉnh sửa: có một vài tài nguyên tốt về "tái cấu trúc so với chi phí bảo trì tăng" được đề cập trong whitepaper này: http://www.omnext.net/doads/Whitepaper_Omnext.pdf


12
Có một lựa chọn tốt hơn: biến việc tái cấu trúc thành một phần thói quen mã hóa thông thường của bạn. Hàng ngày. Hàng giờ. Bất cứ khi nào bạn thêm hoặc thay đổi một chức năng. Vì vậy, bạn không phải dành thêm thời gian cho nó, hoặc "thuyết phục quản lý".
Doc Brown

Nó chỉ hợp lệ khi bạn không phải xử lý mã đã được viết. Nhiệm vụ chung là thêm giá trị mới vào mã nguồn cũ / cũ / kế thừa. Nhưng khi bạn nhìn vào mã đó, bạn không biết bắt đầu từ đâu và bạn cảm thấy việc viết lại mã đó dễ dàng hơn là tìm hiểu cách thức hoạt động của mã đó. Cố gắng biện minh cho các ước tính này: hai ngày để thêm giá trị mới, sáu ngày để cấu trúc lại mã cũ để duy trì nó. Người ta thường nghe "không tái cấu trúc, chỉ cần thêm giá trị mới, chúng ta sẽ tìm hiểu xem nên làm gì với mã cũ đó".
Andrzej Bobak

1
@ Flot2011 Sau đó, bạn chỉ có một giải pháp. Hãy để tái cấu trúc "hàng ngày" là công việc thường xuyên của bạn. Ví dụ, mỗi thứ ba chỉ tập trung vào việc cải thiện chất lượng của mã. Hãy chắc chắn rằng nó được quản lý tôn trọng và đảm bảo rằng họ biết tái cấu trúc không phải là một sự lãng phí thời gian. Không có hai điều kiện này sớm hay muộn, họ sẽ từ bỏ ý tưởng cải thiện "một cái gì đó đã ở đây và nó đang hoạt động".
Andrzej Bobak

1
@DocBrown Nó hoạt động khi bạn nói chuyện với quản lý. Nếu bạn nói chuyện với nhà phát triển cấp cao và nói với anh ta, bạn sẽ thêm hai trường vào biểu mẫu và bạn sẽ mất 3 ngày ... Chúc may mắn :).
Andrzej Bobak

2
Phải thổi phồng ước tính của bạn để có được thời gian bảo trì là vấn đề vì một số lý do. Đôi khi nợ kỹ thuật trong thực tế có giá trị phát sinh. Điều gì xảy ra khi biz bất ngờ thông báo rằng trong tình huống khẩn cấp, phải mất 15 phút để tát hai lĩnh vực mới khi lần cuối cùng mất 8 ngày. IMO, biz cần có ý thức về nợ công nghệ và tác động lâu dài của nó. Vấn đề cần được hiểu là bạn trả tiền ngay bây giờ hoặc bạn trả gấp 5 lần sau đó khi tất cả được nói xong.
Erik Reppen

14

Bất cứ khi nào bạn có thời gian để làm điều gì đó đúng, hãy sử dụng nó - viết mã tốt nhất bạn có thể, và cải thiện nó đều đặn. Đừng làm cho công việc của bạn khó khăn hơn bằng cách nuôi ong cẩu thả và giới thiệu nợ kỹ thuật khi không cần thiết.

Các cuộc gọi khẩn cấp để sửa một lỗi nghiêm trọng không phải là điều bạn có thể tự kiểm soát, khi chúng xảy ra, bạn phải phản ứng lại càng sớm càng tốt. Tất nhiên, nếu bạn có ấn tượng rằng toàn bộ công việc của bạn bao gồm các cuộc gọi khẩn cấp và bạn không bao giờ có đủ thời gian để làm việc đúng, thì bạn đang trên đường kiệt sức và nên nói chuyện với sếp.

Nếu điều đó không có ích, vẫn còn "chiến lược của Scotty" để có đủ thời gian để thực hiện đúng: nhân tất cả các ước tính của bạn với hệ số 4:

http://bloss.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-recectations/


Chiến lược của Scotty hoạt động. Chỉ cần đừng để sếp của bạn biết bạn đang làm điều này. Thường thì thời gian trong thực tế là gấp đôi. Luôn luôn tốt hơn để hoàn thành sớm hơn muộn.
Lu-ca

11

Tôi thấy công việc của mình là cung cấp phần mềm chất lượng tốt nhất có thể trong thời gian hạn chế cho phép của dự án. Nếu tôi lo ngại rằng mức độ chất lượng sẽ thấp, thì tôi sẽ thu hút chủ dự án. Tôi mô tả mối quan tâm của mình và thảo luận về những rủi ro tiềm ẩn khi triển khai phần mềm ở trạng thái đó. Một trong 3 điều sẽ xảy ra vào thời điểm này:

  1. Chủ dự án sẽ không muốn chấp nhận rủi ro và sẽ chuyển lịch trình trở lại để cho phép chúng tôi dành nhiều thời gian hơn cho chất lượng phần mềm.

  2. Chủ dự án sẽ không muốn chấp nhận rủi ro nhưng không thể chuyển lịch trình trở lại. Nếu điều này xảy ra, thì chúng ta cần đàm phán về những tính năng / chức năng cần loại bỏ khỏi phạm vi dự án để dành nhiều thời gian hơn cho chất lượng phần mềm cho các phần chính của ứng dụng.

  3. Chủ dự án sẽ chấp nhận rủi ro và phần mềm chất lượng thấp sẽ ra ngoài đúng tiến độ. Đôi khi rủi ro kinh doanh khi triển khai không có gì (hoặc triển khai muộn) lớn hơn nhiều so với rủi ro kinh doanh khi triển khai phần mềm chất lượng thấp và chỉ chủ dự án mới có thể đưa ra quyết định đó.

Viết phần mềm rất giống như vẽ một bức chân dung. Không thể nói rằng một bức chân dung được thực hiện "đúng" hay "hoàn hảo". Hoàn hảo là kẻ thù của thực hiện. Bạn thực sự có thể dành 1 tháng để làm việc với một phương pháp duy nhất và nó vẫn chưa được coi là "hoàn hảo". Công việc của tôi là vẽ một bức chân dung mà khách hàng hài lòng.


7

Điều này sẽ không hoạt động trong mọi trường hợp, nhưng tôi đã có một chút may mắn khi sử dụng chiến lược này nếu vấn đề là sự cố sản xuất bị hỏng phải được khắc phục khẩn cấp. Ước tính thời gian để thực hiện một sửa chữa nhanh chóng để chạy sản xuất và thời gian để thực hiện sửa chữa chất lượng cho tương lai. Trình bày các ước tính cho sếp / khách hàng của bạn và nhận được thời gian phê duyệt cho cả hai. Sau đó, bạn thực hiện sửa chữa nhanh chóng để có được sản xuất và sửa chữa dài hạn ngay lập tức sau khi áp lực thời gian khẩn cấp được tắt. Tôi thấy rằng nếu tôi trình bày nó khi tôi cần thời gian này để hoàn thành công việc ngay, nhưng tôi có thể khắc phục tạm thời cho đến khi tôi có thể làm điều đó, rằng khách hàng của tôi có vẻ thích cách tiếp cận đó. Nó được prod chạy lại và nó được chăm sóc lâu dài.


7

Sự cân bằng tối ưu có thể là dành nhiều thời gian hơn để làm điều đó đúng vì bạn sẽ lãng phí việc sửa các lỗi bạn loại bỏ bằng cách thực hiện đúng. Tránh mạ vàng dung dịch. Trong hầu hết các trường hợp, giải pháp của Volkswagen được thực hiện đúng như giải pháp Cadillac. Bạn thường có thể nâng cấp sau khi được chứng minh rằng bạn cần Cadillac.

Việc sửa mã không tuân theo các thực tiễn tốt nhất thường mất nhiều thời gian hơn. Cố gắng tìm nơi null đến từ khi cuộc gọi trông giống abcde (), có thể mất nhiều thời gian.

Áp dụng DRY và sử dụng lại mã hiện có thường nhanh hơn nhiều so với mã hóa và thử nghiệm một giải pháp khác. Nó cũng làm cho nó dễ dàng hơn để áp dụng các thay đổi khi chúng xảy ra. Bạn chỉ cần thay đổi và kiểm tra một bộ mã, không phải hai, ba hoặc hai mươi.

Nhằm mục đích cho mã cơ bản vững chắc. Rất nhiều thời gian có thể bị lãng phí khi cố gắng làm cho nó hoàn hảo. Có những cách thực hành tốt nhất dẫn đến mã nhanh, nhưng không nhất thiết phải nhanh nhất có thể. Ngoài ra, cố gắng lường trước các tắc nghẽn và tối ưu hóa mã khi nó được xây dựng có thể bị lãng phí thời gian. Thậm chí tệ hơn, việc tối ưu hóa có thể làm chậm mã.

Bất cứ khi nào có thể, cung cấp các giải pháp làm việc tối thiểu. Tôi đã thấy tuần lãng phí giải pháp mạ vàng. Hãy cực kỳ cẩn thận về phạm vi.

Tôi đã dành thời gian làm việc cho dự án lẽ ra phải mất sáu tháng. Khi tôi tham gia, nó đã được tiến hành trong một năm rưỡi. Trưởng dự án đã hỏi người quản lý dự án một câu hỏi khi bắt đầu: "Bạn muốn tôi làm điều đó đúng hay đáp ứng?" Trong một tuần, một tính năng đã được triển khai vào Thứ Hai, Thứ Tư và Thứ Sáu; Thứ ba và thứ năm tính năng đã được gỡ bỏ.

EDIT: Khi mã được thực hiện ở mức thỏa đáng, hãy để lại nó. Đừng quay lại để sửa nó nếu bạn nghĩ ra cách tốt hơn để làm điều đó. Nếu bạn phải làm cho mình một lưu ý. Nếu thay đổi là bắt buộc, hãy xem lại ý tưởng của bạn và thực hiện nó sau đó nếu nó vẫn có ý nghĩa.

Nếu có những nơi bạn sẽ triển khai các tiện ích mở rộng cho các tính năng sắp tới, đừng triển khai các tiện ích mở rộng. Bạn có thể để lại một bình luận đánh dấu để nhắc bạn nơi thực hiện các thay đổi.


Trừ khi DRY có nghĩa là khó hiểu, không thể thực hiện được, thực hiện các kế hoạch thừa kế tầng lớn. Đừng làm vậy. Xin lỗi, tôi nói điều đó rất nhiều, nhưng tôi thực sự ghét điều đó. Ngoài ra, +1 cho giải pháp làm việc tối thiểu trong hầu hết các trường hợp. Đôi khi một số tính năng kiến ​​trúc hướng về phía trước có thể hữu ích miễn là bạn không làm quá.
Erik Reppen

1
@ErikReppen Mã gây nhầm lẫn, không thể đọc được và việc triển khai các kế hoạch thừa kế xếp tầng lớn sẽ làm thất bại định nghĩa về DRY của tôi. Nếu bạn cần tìm ra mã mỗi lần bạn sử dụng nó, thiết kế rõ ràng không thành công DRY ngay cả khi việc triển khai được thực hiện.
BillThor

Nó có thể liên quan đến rất nhiều mã tái sử dụng mặc dù. Phần khó chịu là trèo lên một cây gồm 18 lớp hoặc nguyên mẫu để tìm định nghĩa thực sự của một phương thức đang làm điều gì đó thực sự gây phiền nhiễu, đặc biệt là nếu có ghi đè.
Erik Reppen

6

Làm cho nó hoạt động sau đó làm cho nó hoàn hảo

Tôi có thể rút ra một chút chùng cho việc này - nhưng nếu thời gian là điều cốt yếu, thì ưu tiên chính của bạn là làm cho nó hoạt động, đơn giản như vậy. Nhận xét rộng rãi về những thiếu sót trong mã của bạn và ghi chú lại những gì bạn đã làm trong bất kỳ phần mềm quản lý dự án / thời gian nào bạn đang sử dụng.

Hy vọng rằng điều này sẽ cho bạn thêm thời gian để trở lại những vấn đề này và làm cho chúng hoàn hảo.

Rõ ràng không có câu trả lời chính xác tuyệt đối cho vấn đề này, nhưng đó là câu trả lời tôi cố gắng và tuân theo. Bạn có thể không thấy nó phù hợp với phong cách làm việc hiện tại của bạn. Điều này dẫn tôi đến sự thay thế ...

Chỉ cần tìm một phương pháp phù hợp với bạn ; và sau đó gắn bó với nó. Mọi người đều có cách xử lý riêng với các dự án và không có cách tiếp cận "một kích thước phù hợp với tất cả". Tìm một cách tiếp cận, và làm cho nó của bạn.


3
Khi quản lý biết, nó hoạt động. Họ coi đó là xong và không muốn bạn dành bất kỳ nỗ lực nào khác cho việc tái cấu trúc, v.v.
Adronius

5

"Làm đúng" có nghĩa là thực hiện đánh đổi đúng cho một tình huống cụ thể. Một số trong số họ là:

  1. Thời gian và chi phí phát triển
  2. Dễ đọc, gỡ lỗi và cập nhật mã sau này (mọi thứ từ tên biến đến kiến ​​trúc)
  3. Tính kỹ lưỡng của giải pháp (trường hợp cạnh)
  4. Tốc độ thực hiện

Rõ ràng, nếu một đoạn mã sẽ được sử dụng một lần và vứt đi, # 2 có thể được hy sinh cho bất kỳ ai khác. (Nhưng hãy cẩn thận: bạn có thể nghĩ rằng bạn sẽ vứt nó đi, sau đó thấy rằng bạn phải tiếp tục sử dụng và duy trì nó, tại thời điểm đó sẽ khó thuyết phục mọi người cho bạn thời gian để cải thiện một cái gì đó "hoạt động".)

Nếu bạn và / hoặc nhóm của bạn sẽ tiếp tục sử dụng và cập nhật một số mã, sử dụng phím tắt ngay bây giờ chỉ có nghĩa là làm chậm bản thân bạn sau này.

Nếu bạn hiện đang phân phối mã lỗi (yếu ở số 4) và mất nhiều thời gian để làm điều đó (yếu ở số 1), và đó là vì bạn đang cố cập nhật mã yếu ở số 2, tốt, bạn đã có một lập luận vững chắc, thực dụng để thay đổi thực hành của bạn.


1
Tôi sẽ đề nghị: "Nếu NOBODY sẽ duy trì một đoạn mã ...": Viết rác, đổ rác và chạy không nên là một lựa chọn (đối với bất kỳ ai có lương tâm), nhưng nó xảy ra quá thường xuyên; nhà thầu / chuyên gia tư vấn / quản lý đảm bảo rằng họ an toàn ra khỏi cửa ngay trước khi "nó" chạm vào quạt.
Phill W.

@PhillW. - hoàn toàn đồng ý. Chỉnh sửa cho phù hợp.
Nathan Long

4

Nếu đó là một lỗi, hãy làm nó càng sớm càng tốt, nếu đó là một tính năng mới, hãy dành thời gian của bạn.

Và nếu bạn làm việc cho một công ty không tôn trọng công việc của nhà phát triển, bạn có thể không lựa chọn nào khác ngoài việc làm nhanh và hy sinh chất lượng.

Tôi đã làm việc cho một số công ty sẽ đi từ dự án này sang dự án khác và làm mọi thứ nhanh chóng. Cuối cùng, họ đã có rất ít thành công trong mọi dự án vì việc triển khai (không chỉ là lập trình) đã được gấp rút hoàn thành.

Các công ty tốt nhất hiện có hiểu rằng phần mềm tốt cần có thời gian và sự khéo léo.


3

Khi khẩn cấp tạo ra giải pháp vá. Tạo một lỗi mới trong theo dõi lỗi đề cập đến điều này. Làm cho nó đúng, bất cứ khi nào bạn có thời gian thích hợp.


5
Vấn đề là, hầu như không bao giờ có thời gian thích hợp, đó chính xác là vấn đề và các lỗi thuộc loại này sẽ luôn được ưu tiên thấp nhất.
Flot2011

Tôi chỉ nói điều này đúng nếu "khẩn cấp" bạn có nghĩa là "điều gì đó xảy ra không quá sáu tháng một lần" và "khi bạn có thời gian" bạn có nghĩa là "trong vòng một tuần hoặc lâu hơn". Nếu không, câu hỏi tiếp theo của bạn trở thành "trợ giúp, khách hàng cần một cái gì đó càng sớm càng tốt, nhưng mã tôi phải thay đổi là một mớ hỗn độn khó hiểu và tôi sẽ mất vài tuần để sắp xếp!"
Nathan Long

3

Tôi nghĩ tôi làm những gì mọi người đang mắc kẹt trong ngành này làm. Tôi hoàn thành nó nhanh nhất có thể và nếu tôi phải bỏ đi một số điều tốt đẹp sẽ giúp ngăn ngừa các vấn đề trong tương lai, hoặc làm cho việc giải quyết vấn đề dễ dàng hơn trong tương lai, tôi sẽ làm. Đó không phải là một tình huống tối ưu nhưng khi bạn bị mắc kẹt với thời hạn dựa trên ước tính dựa trên ước tính, dựa trên rất nhiều biến số chưa biết, đó là cách tốt nhất bạn có thể làm.


3

Đây là một kế hoạch tốt:

  1. Làm cho kế hoạch thực hiện đúng của bạn mất một khoảng thời gian chính xác so với thực hiện càng sớm càng tốt.
  2. Tối ưu hóa thời gian của bạn để làm điều đó cho đến khi môi trường của bạn hạnh phúc; giữ chất lượng
  3. ???
  4. Sự thành công

1

Tôi làm hầu hết mọi thứ theo cách thông thường, cách đầu tiên xuất hiện trong đầu. Điều đó thật nhanh chóng, và tôi muốn nghĩ rằng tôi là một lập trình viên đàng hoàng và tôi làm hầu hết mọi thứ một cách hợp lý OK ngay lần thử đầu tiên.

Thỉnh thoảng (tôi muốn nói hai lần mỗi ngày, nhưng hai lần mỗi tuần là thực tế hơn), đặc biệt là khi tôi thấy điều gì đó cực kỳ nhàm chán để làm theo cách thông thường, tôi nghĩ "điều gì sẽ là một cách TUYỆT VỜI để làm điều này ? " và tôi dành thêm thời gian để tìm hoặc phát minh ra một cách tốt hơn để làm điều đó.

Nếu tôi tiếp tục làm điều đó thường xuyên đủ, mã hóa thông thường của tôi sẽ tiếp tục cải thiện, tôi nghĩ vậy.


1

Phần mềm là thứ kỳ lạ và quá trình phát triển phần mềm là lạ hơn.

Không giống như hầu hết mọi thứ trong cuộc sống thực, nhưng giống như hầu hết mọi thứ để làm với máy tính

Nhanh hơn là đáng tin cậy

Điều này đi ngược lại mọi trực giác mà cuộc sống của bạn cho đến nay đã dạy cho bạn, những chiếc xe được điều chỉnh cao thường xuyên bị hỏng hơn những chiếc tiêu chuẩn, những ngôi nhà được xây dựng nhanh chóng sụp đổ nhanh hơn, bài tập về nhà ở phía sau xe buýt không đạt điểm cao.

Nhưng các thủ tục phương pháp chậm không tạo ra phần mềm tốt hơn. Những người dành hàng tuần để đưa ra các tài liệu yêu cầu và ngày trên sơ đồ lớp trước khi viết mã không tạo ra phần mềm tốt hơn. Anh chàng nhận được yêu cầu cơ bản, làm rõ một vài vấn đề, viết nguệch ngoạc một sơ đồ lớp trên bảng trắng và mã hóa nhóm của anh ta sẽ luôn luôn tạo ra phần mềm đáng tin cậy hơn và tốt hơn, và làm như vậy trong vài ngày thay vì vài tháng.


Tôi không chắc chắn tôi đồng ý với bạn nhưng đó là một quan điểm thú vị, không chính thống. +1 để suy nghĩ ra khỏi hộp.
Flot2011

-1

Công việc không phù hợp với bạn.

Mã chất lượng thấp được viết "vì không có thời gian, khách hàng đang chờ đợi, một lỗi nên được khắc phục qua đêm, công ty đang mất tiền cho vấn đề này, một người quản lý đang rất khó khăn" là một triệu chứng của một công ty được quản lý kém.

Nếu bạn sẵn sàng tự hào về công việc của mình và viết mã chất lượng cao, thì điều tốt nhất nên làm là tìm một nhà tuyển dụng hiểu điều đó và sẽ trả tiền cho bạn để làm điều đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.