Là nhà phát triển phần mềm bỏ qua chất lượng / tiêu chuẩn tốt hơn cho công ty? [đóng cửa]

Các nhà phát triển phần mềm chọn không đặt tối ưu hóa mã, tiêu chuẩn và thực tiễn tốt nhất làm ưu tiên hàng đầu, tạo mã hữu ích hơn so với các nhà phát triển muốn lo lắng về tối ưu hóa, thực hiện các tiêu chuẩn mã hóa và thực hành trên hoàn thành nhiệm vụ đúng hạn?

Làm thế nào để các phương pháp khác nhau so sánh khi nói đến đánh giá hiệu suất cá nhân?

Làm thế nào để những phong cách so sánh trong đánh giá ngang hàng?

Cách tốt nhất để tác động đến nhóm của bạn để triển khai các thực tiễn tốt hơn trong SDLC là gì?

Không, họ sẽ chỉ nhận được sự tôn trọng từ chủ sở hữu của dự án thời điểm này.

Họ sẽ bị vùi dập trong nhiều năm bởi:

• người duy trì trong tương lai,
• người thử nghiệm trong tương lai,
• chủ dự án tương lai,
• quản lý tương lai,
• và khá nhiều người liên quan đến codebase trong tương lai.

Họ thậm chí có thể nhận được điều trị tương tự từ:

• những người thử nghiệm hiện tại,
• các nhà văn tài liệu kỹ thuật hiện tại.

Sai phân đôi: phẩm chất là trực giao.

                Chất lượng cao Chất lượng thấp

Phác thảo TUYỆT VỜI

Iffy không được hưởng lợi

Không. Thực tiễn tốt nhất là tốt nhất bởi vì theo định nghĩa , chúng giúp các dự án được thực hiện chính xác hơn, trong thời gian ngắn hơn, với sự điều chỉnh nhanh hơn, vì vậy việc bỏ qua chúng được đảm bảo để giảm lợi nhuận. Tất nhiên, người quản lý của bạn có thể quy định các thực tiễn mà họ cho là tốt nhất, nhưng thực tế là không, hoặc họ có thể đánh giá sai những gì khách hàng sẽ trả cho và những gì không - sau đó tất cả các cược đã tắt.

Tiêu chuẩn mã hóa là khó khăn hơn; có thể quy định quá nhiều chi tiết cho các lập trình viên của bạn, dẫn đến giảm hiệu quả. Nhưng với kinh nghiệm, việc đưa ra các hướng dẫn hữu ích từ quản lý vi mô qua đường hậu môn trở nên khá dễ dàng, do đó, áp dụng tương tự: các thực hành tốt nhất thực tế luôn luôn có giá trị, các thực hành tốt nhất giả thường không.

Tối ưu hóa mã thường không có giá trị thực hiện trừ khi bạn đã đo được các tắc nghẽn của mình là gì, xác nhận rằng thực hiện tối ưu hóa là cần thiết và đo lường rằng thủ thuật thông minh của bạn thực sự đáp ứng yêu cầu về hình thức. Mặt khác (phần lớn) nó không đáng làm, và do đó không tối ưu.

Tôi có đồng ý với các nhà phát triển không quan tâm đến việc tối ưu hóa và thực hành mã không? Không.

Họ có làm công việc họ cần làm không? Đúng.

Một doanh nghiệp là kiếm tiền, và cách duy nhất để kiếm tiền là phát hành sản phẩm. Điều này thường có nghĩa là các dự án có lịch trình nghiêm ngặt, có nghĩa là những gì có thể là cách tốt nhất để làm một cái gì đó có thể không phải là cách nhanh nhất để làm một cái gì đó.

Mặc dù tôi không đồng ý với phong cách phát triển này, công ty có thể được coi là đáng kính nếu sản phẩm được phát hành.

Không, và tôi sẽ tìm ra con đường nhanh nhất cách xa công ty nói rằng đánh giá cao những tật xấu đó.

Có và không, đó là một chút mơ màng nhưng đó là một thực hành tốt nhất và không phải là một thực hành hoàn hảo. Tốt nhất là bạn nên theo dõi họ liên tục, nhưng sẽ luôn có một tình huống mà doanh nghiệp muốn đưa ra nhu cầu của mình trước nhu cầu sản phẩm của bạn.

Bạn sẽ bị ghét bởi những người bảo trì nhưng được sếp yêu quý.

Thực tiễn tốt nhất có phần giống như lẽ thường, mọi người đều đồng ý rằng mọi người nên biết điều đó cho đến khi bất kỳ hai người bắt đầu thảo luận chi tiết. Không có hai người hoàn toàn đồng ý về định nghĩa và không có nguồn sự thật logic nào áp dụng cho tất cả các tình huống.

Bạn đang viết hệ thống hướng dẫn cho một vệ tinh không gian (có thể bạn không)? Vậy thì địa ngục Không có mã chất lượng / hiệu suất kém không bao giờ được chấp nhận trong loại công việc này.

Bạn đang viết một trang web vứt đi để thúc đẩy tiếp thị một lần (có thể bạn sẽ không làm điều này hoặc bạn sẽ không đặt câu hỏi, nhưng nó có nhiều khả năng hơn vệ tinh)? Sau đó, Hell Yes, đưa mảnh đó ra khỏi cửa thông qua bất kỳ phương tiện cần thiết nào để đáp ứng thời hạn, giám đốc tiếp thị tiếp theo có thể sẽ làm một cái gì đó khác với một công ty khác. NHỮNG GÌ BẠN KHÔNG PHẢI LÀ NGHỆ THUẬT HOẶC KHOA HỌC - NHẬN ĐƯỢC TRẢ TIỀN.

Mọi thứ khác ở giữa: có thể thương lượng, đặc biệt là miễn là nhà phát triển sẵn sàng hỗ trợ ban đầu.

Cho đến khi lần thứ hai xảy ra bất cứ điều gì linh thiêng mà bạn thích xảy ra và anh ấy / cô ấy / họ / nó xác định các thực tiễn phát triển theo cách kỳ diệu, sẽ có chỗ để tranh luận về bất kỳ dự án nào không chịu trách nhiệm trực tiếp cho các quyết định sống và chết không phải là quá quan trọng để được dùng một lần

Tất cả mọi thứ bên ngoài các thực tiễn tốt nhất được dán nhãn quan trọng trong cuộc sống thường giống như chính sách của công ty, thông số kỹ thuật của khách hàng hoặc ý kiến ​​cá nhân. Nhiều người trong số họ là ý kiến ​​cá nhân mà nhiều người hiện đang đồng ý, nhưng điều đó không làm cho nó trở thành một hướng dẫn bất di bất dịch cho mọi tình huống.

Họ kiếm được bao nhiêu tiền cho công ty. Nếu có một mức độ xem lại mã được đề cập, chi phí bảo trì sẽ tăng lên và ai đó sẽ không vui. Chi phí bảo trì dài hạn cao sẽ tốn kém hơn so với thực hiện trước.

Bao nhiêu sự tôn trọng họ có thể là trường hợp cụ thể. Tại một số điểm, tuy nhiên, sẽ có người chú ý.

Không quan tâm đến những điều này có thể làm cho công ty có nhiều tiền hơn trong thời gian ngắn, nhưng có thể khiến công ty tốn nhiều tiền hơn trong dài hạn về việc sửa lỗi nhiều hơn và mã hóa bảo trì.

Đôi khi một công việc nhanh chóng và bẩn thỉu có thể là cần thiết nếu có sự vội vàng với các công ty cạnh tranh để đưa các sản phẩm tương tự ra thị trường cùng một lúc, nhưng chi phí tương lai của các hành động đó nên được xem xét cẩn thận.

Tất cả phụ thuộc vào khách hàng.

Một khách hàng thích nhanh và bẩn (và thường rẻ hơn) không quan tâm rằng nó sẽ gặp vấn đề trong tương lai.

Hãy nghĩ đến việc xây dựng tủ.

Một số sẽ trả tiền, và đánh giá cao, chất lượng tốt tủ tùy chỉnh được xây dựng. Họ không bận tâm đến chi phí thêm của ngăn kéo gỗ cứng và phần cứng đỉnh cao. Họ không bận tâm sẽ mất thêm một tuần hoặc thậm chí một tháng để xây dựng và cài đặt mọi thứ.

Nhiều người sẽ không. Nhiều người sẽ lựa chọn những tấm ván rẻ tiền được sản xuất hàng loạt thứ bạn có được từ một cửa hàng hộp lớn. Họ muốn chúng được cài đặt trong 2 ngày. Một khoảng cách nhỏ ở đây và hoàn toàn chấp nhận được. Họ không quan tâm rằng họ sẽ sụp đổ sau 10 năm nữa.

Vì vậy, nếu người quản lý của bạn đang khen ngợi nhà phát triển hoàn thành công việc nhanh chóng và bẩn thỉu thì khách hàng của bạn sẽ không muốn chất lượng cao hoặc người quản lý đang nói dối khách hàng.

Chỉ có thời gian mới trả lời. Làm những gì các nhà quản lý muốn hoặc tìm một công việc khác.

Không bao giờ. IMO mã tối ưu hóa, thực hành tốt nhất, thực tế khéo léo là MOST điều quan trọng cần có trong một codebase; không có nó, toàn bộ nó biến thành bùn và được giữ lại bằng băng keo. Đó là một thiết kế không bền vững. Nó giống như bỏ qua một khối u vì nó nhỏ và bạn đang khỏe mạnh; chắc chắn bây giờ bạn khỏe mạnh nhưng vài năm sau nó trở thành thiết bị đầu cuối vì bạn đã bỏ qua nó quá lâu.

Tôi không chỉ không đồng ý với các nhà phát triển không quan tâm đến những điều này, mà tôi không tôn trọng họ để khởi động. Một cách chắc chắn để khiến tôi cân nhắc rời khỏi một tổ chức, bất kể thời gian tôi ở đó bao lâu, là được bao quanh bởi một nhóm trong đó tôi là người duy nhất (nếu không phải là người duy nhất trong toàn công ty) quan tâm về các khái niệm kỹ thuật phần mềm thích hợp.

Đọc tốt: http://www.joelonsoftware.com/items/2009/09/23.html

Nhưng IMHO, một người đàn ông thực hành tốt nhất là một cơn ác mộng khác của người đàn ông. Và mọi cơ sở mã không tầm thường sẽ là cơn ác mộng đối với người ngoài.

Bất cứ điều gì bạn nghĩ, đừng là một thằng ngốc về nó.

EDIT: Tôi không bảo vệ bất kỳ vị trí nào, tùy thuộc vào nhiệm vụ mà tôi có thể nghiêng về hai bên.

Tốt hơn cho công ty? Nó phụ thuộc.

Đối với một công ty khởi nghiệp có số tiền hạn chế, hãy hoàn thành nó và đưa nó ra khỏi đó - không thành vấn đề nếu nó lộn xộn, có thể được khắc phục sau này khi có nhiều tài nguyên hơn.

Đối với một sản phẩm trưởng thành, nơi có nhiều người dùng dựa vào chất lượng của phần mềm, mọi thứ nên được thực hiện "đúng cách".

Tốt hơn cho các nhà phát triển cá nhân? Thật ra nó không liên quan. Chỉ cần làm giống như những gì đồng nghiệp của bạn đang làm và để quản lý đối phó với bụi phóng xạ - đó không phải là công việc của bạn. Nếu bạn đang sửa chữa những người khác tào lao suốt thời gian bạn S see bị coi là chậm, và bạn sẽ là người vẫn ở đó trong khi những người khác đã được thăng chức trên bạn. Tham gia chương trình hoặc ra ngoài trong khi bạn có thể nếu nó tệ.

Phụ thuộc vào nhà phát triển và dự án / tình huống.

Thời gian bất thường đòi hỏi các biện pháp phi thường.

Vì vậy, nếu tôi cần một thứ gì đó được giao ngay bây giờ và một người nào đó là ứng dụng java cấp doanh nghiệp kỹ thuật quá mức, sử dụng không dưới 14 khung từ thông dụng mới nhất trong khi một kịch bản python đơn giản sẽ làm công việc tồi tệ hơn như nhà phát triển cắt góc và nghĩ mã lỗi sẽ làm trong thời gian bình thường.

Một phần của việc trở thành một nhà phát triển là linh hoạt. Bạn không nên làm nô lệ cho các công cụ của mình và làm theo một cách mù quáng các thực hành - sẽ luôn có trường hợp chúng làm bạn thất vọng. Biết khi nào nên phá vỡ và bẻ cong các quy tắc là một trong những điều đi kèm với rất nhiều kinh nghiệm và có giá trị.

Trong trường hợp của bạn - nếu anh ta mang lại nhiều giá trị hơn bạn vì tốc độ là rất quan trọng, ngay cả sau khi bao gồm chi phí bảo trì tăng lên thì anh ta xứng đáng được bồi thường tốt hơn. Mặt khác - nếu bạn bị mắc kẹt với việc dọn dẹp mớ hỗn độn của anh ấy - bạn có vấn đề giao tiếp với ban quản lý.

Đó là từng trường hợp. Ngoại trừ phong cách mã hóa - không có lý do nào ở đó.

Tôi xin lỗi nhưng tôi sẽ không đồng ý với hầu hết các câu trả lời cho câu hỏi này, ngoại trừ câu trả lời hàng đầu.

Giá trị chính của phần mềm là nó linh hoạt.

Tôi không nghĩ bạn nên viết lại mã của người khác mà không có lý do. Nếu bạn phải thay đổi một mô-đun vì bất kỳ lý do nào để triển khai tính năng của mình, thì bây giờ, bạn đang tốt hơn hoặc xấu hơn, chủ sở hữu của mô-đun đó. Thay đổi nó, viết lại một số, viết lại tất cả.

Không bao giờ sản xuất chất lượng thấp về tính linh hoạt bao giờ. Không có gì gọi là vứt bỏ bất cứ thứ gì trong phần mềm. Nếu khách hàng nói tạm thời và họ sẽ không cần nó sau một ngày nhất định và họ không quan tâm đến chất lượng, hãy nói "xấu" hoặc viết rằng mã sẽ không bị thay đổi bởi bạn hoặc bất kỳ lập trình viên nào khác một lần nó được triển khai để sản xuất hoặc bạn có quyền kiện họ.

Giả định nghèo nhất mà tôi thấy trong một số câu trả lời này là một số mã sạch bằng cách nào đó làm giảm tốc độ phát triển. Đối với bất kỳ dự án nào của bất kỳ chất nào (lớn hơn 6 giờ làm việc), mã sạch sẽ tăng tốc độ phát triển trong dài hạn (bất cứ điều gì lớn hơn một tuần). Tôi đã thấy nó hết lần này đến lần khác.

Mã kém chất lượng chỉ là thiếu tôn trọng với nghề nghiệp và đồng nghiệp của bạn. Xin lỗi nhưng sự thật.

Vì vậy, không có chất lượng kém, về tính linh hoạt, bao giờ hết!