Có phải là miễn là nó hoạt động như là tiêu chuẩn? [đóng cửa]

Xem câu hỏi gần đây hơn của tôi: Lập trình như một nghề trong một cuộc đua xuống đáy?

Cửa hàng cuối cùng của tôi không có một quá trình. Agile về cơ bản có nghĩa là họ không có kế hoạch gì về cách phát triển hoặc quản lý dự án của họ. Nó có nghĩa là "này, đây là một tấn công việc. Hãy thực hiện nó trong hai tuần. Chúng tôi có nhịp độ nhanh và nhanh nhẹn."

Họ đã phát hành những thứ mà họ biết có vấn đề. Họ không quan tâm đến việc mọi thứ được viết như thế nào. Không có đánh giá mã - mặc dù có một số nhà phát triển. Họ đã phát hành phần mềm mà họ biết là có lỗi.

Ở công việc trước đây của tôi, mọi người có thái độ miễn là nó hoạt động, nó ổn. Khi tôi yêu cầu viết lại một số mã tôi đã viết trong khi chúng tôi chủ yếu khám phá thông số kỹ thuật, họ đã từ chối nó. Tôi muốn viết lại mã bởi vì mã được lặp lại ở nhiều nơi, không có sự đóng gói và mọi người phải mất một thời gian dài để thay đổi mã.

Về cơ bản, ấn tượng của tôi là thế này: lập trình nắm rõ những điều sau:

1. Đọc một số cuốn sách về công cụ / công nghệ mới nhất
2. Kết hợp mã dựa trên điều này, tránh viết bất kỳ mã riêng lẻ nào vì công ty không muốn "duy trì mã tùy chỉnh"
3. Hiển thị nó và chuyển sang điều tiếp theo, "miễn là nó hoạt động."

Tôi đã luôn nói với bản thân mình rằng công việc tiếp theo tôi sẽ có được một cửa hàng tốt hơn. Nó không bao giờ xảy ra. Nếu đây là nó, thì tôi cảm thấy bế tắc. Các công nghệ luôn thay đổi; Nếu sự phát triển chuyên nghiệp duy nhất ở đây là đọc cuốn sách công nghệ MS Press mới nhất, thì bạn đã xây dựng được gì sau 10 năm nhưng một kiến ​​thức hời hợt về các công nghệ khác nhau? Tôi lo lắng về:

1. Cách tốt nhất để có tiêu chuẩn chuyên nghiệp
2. Làm thế nào để phát triển kiến ​​thức và kinh nghiệm có ý nghĩa trong tình huống này

Bạn đã gián tiếp vấp phải những gì tôi nghĩ là khía cạnh quan trọng để trở thành một nhà phát triển giỏi : tạo ra sự cân bằng giữa " miễn là nó hoạt động " và mã thanh lịch, được thiết kế tốt.

Giống như trong chính trị, việc đặt vị trí của bạn vào một đầu của quang phổ sẽ dễ dàng hơn nhiều so với việc giữ một vị trí sắc thái ở giữa. Phần lớn các nhà phát triển tôi gặp phải thuộc một trong hai loại: hack cao bồi và phi hành gia kiến ​​trúc. Tôi cố gắng cân bằng giữa hai. Nó không dễ dàng như âm thanh.

Để trả lời trực tiếp hơn câu hỏi của bạn, vâng, tôi nghĩ "miễn là nó hoạt động" thường là chuẩn mực. Nhưng hãy nhìn nó theo một cách khác: bạn đang ở một vị trí tuyệt vời để giáo dục các đồng nghiệp của mình và cố gắng giới thiệu một số thực tiễn tốt hơn. Nhưng đừng đi đến cực đoan, và hãy nhớ tại sao tất cả chúng ta đều làm điều này: để giải quyết các vấn đề của khách hàng.

>> Ở công việc trước đây của tôi, mọi người có thái độ miễn là nó hoạt động, nó ổn.

Có thể tôi là thiểu số ở đây nhưng tôi có cùng một thái độ và tôi tin tưởng mạnh mẽ rằng để viết lại một cái gì đó nên có bằng chứng rõ ràng tại sao chúng ta cần điều này. Và tôi không có ý gì đó như "uf, tôi không thích cách mã hóa" - mọi nhà phát triển đều có sở thích về mã. Có một số vấn đề với phần chúng tôi muốn viết lại:

• Vấn đề về hiệu suất
• Có nhiều lỗi được tìm thấy hơn bất kỳ phần nào khác của hệ thống
• Các nhà phát triển dành nhiều thời gian hơn khi họ làm việc trong phần này
• v.v.

Agile không chịu trách nhiệm cho bất kỳ con người nào quyết định phát hành phần mềm lỗi; con người là

Điều đó nói rằng, bạn rất quan trọng đối với chất lượng, và nó tốt. Tôi chắc chắn bạn là người cầu toàn và bạn lo ngại về giá trị của chính mình nếu bạn không bắt kịp các công nghệ mới nhất.

Vấn đề là sự cầu toàn dẫn đến sự trì hoãn và sự trì hoãn dẫn đến sự tầm thường .

Đó là lý do tại sao doanh nghiệp sẽ ưu tiên những thứ như thời gian để tiếp thị và sử dụng nhanh để cung cấp giá trị nhanh chóng và với tốc độ có thể dự đoán được.

Vì bạn không mô tả chiến lược kinh doanh của công ty, tôi nghĩ bạn nên bắt đầu bằng cách đặt câu hỏi về điều đó cho người quản lý của mình.

Bằng cách liên kết với các mục tiêu và kế hoạch của họ (họ đã thuê bạn để giúp họ đạt được chúng), bạn sẽ ở vị trí tốt hơn để hiểu cách bạn có thể đóng góp cho họ thay vì tập trung vào các mục tiêu cá nhân và của riêng bạn.

Tôi chắc chắn rằng bằng cách cố gắng với understandgiá trị của họ, bạn sẽ có thể chia sẻ của bạn và đó sẽ là khởi đầu của sự hợp tác hiệu quả.

Và nếu bạn phát hiện ra họ không biết họ đang làm gì, lựa chọn duy nhất của bạn sẽ là bỏ việc .

Tất cả phụ thuộc vào những gì bạn đang xây dựng. Nếu bạn đang xây dựng một microsite sẽ chỉ trực tuyến trong một tháng và bạn có chín ngày để xây dựng nó: thì có, miễn là nó hoạt động sẽ đủ.

Nếu bạn đang viết các thuật toán fly-by-wire cho hệ thống FA-18, thì tốt hơn là nên xây dựng nó một cách hoàn hảo nhất có thể.

Vì vậy, như trường hợp của hầu hết các câu trả lời công nghệ ... nó phụ thuộc.

Nó phụ thuộc vào công ty. Tuy nhiên, nhiều công ty có sự cạnh tranh nghiêm trọng và áp lực thời gian. Đó là một lý do điển hình. Một cái khác sẽ là một khối lượng công việc lớn, có khả năng không có đủ nhân viên. (Một số lý do rất chính đáng tồn tại khi bị bảo lãnh, đó không nhất thiết là lỗi của công ty.) Điều đó nói rằng, một số tổ chức không thể quản lý ra khỏi túi giấy ướt.

Tôi nghĩ rằng quy tắc 80/20 áp dụng ở đây. Về cơ bản, bạn cần phải đưa ra 80% crappy và làm việc theo cách của bạn vào 20%. Tuy nhiên, nhận ra rằng thậm chí họ sẽ phải đánh đổi. Trong kinh doanh, việc bạn có nó hoàn toàn đúng không quan trọng. Vấn đề là bạn có nó ngay bây giờ.

Nếu sự phát triển chuyên nghiệp duy nhất ở đây là đọc cuốn sách công nghệ MS Press mới nhất, thì bạn đã xây dựng được gì sau 10 năm nhưng một kiến ​​thức hời hợt về các công nghệ khác nhau?

Điều đó sẽ khá may mắn nhưng có thể đã có một số thất bại ngoạn mục cần lưu ý trong thập kỷ đó. Tôi đã thấy nhiều nơi mà tôi có thể nhớ những điều khá cụ thể mà tôi thích khi làm việc ở đó hoặc không thích và do đó sẽ đặt câu hỏi đó một lần nữa ở nơi làm việc mới của tôi. Đôi khi, có thể có một cách thực hành mới để thử như nếu một công ty cố gắng thực hiện Scrum hoặc áp dụng phương pháp Phát triển dựa trên thử nghiệm có thể là cơ hội nhưng không nhất thiết phải là phát triển chuyên nghiệp như trong một lớp học chính thức.

Tôi biết nhiều nơi khác nhau, "miễn là nó hoạt động" là phổ biến cùng với các chiến lược mã hóa cao bồi khác nhau. Trong một vài lần khởi nghiệp tôi đã thấy loại tâm lý này có thể có ý nghĩa nếu công ty còn quá trẻ mà họ vẫn đang cố gắng tuôn ra ý tưởng về những gì họ thực sự đang cố gắng làm. Tại các công ty khác tôi từng làm việc đã có nhiều quá trình và sự trưởng thành có thể khá tốt mặc dù không nhất thiết phải dễ dàng tìm thấy tôi sợ. Một số nơi có một số quy trình mà tôi phải xem và đi, "Tôi thích điều đó. Tôi sẽ nhớ rằng trong các tình huống công việc sau này" và những nơi khác tôi sẽ đến, "Tôi thực sự không thích điều đó. Tôi sẽ lưu ý để cố gắng tránh điều đó trong tương lai. "

Tôi đã làm việc tại một cửa hàng như thế này trong một thời gian tại nơi mà nó đang bắt kịp họ. Có những ứng dụng hai hoặc ba năm tuổi với những lỗi đã biết mà theo nghĩa đen chúng không thể giải quyết được. Hãy nghĩ về một vòng lặp dài 4.000 dòng với một phép tính chạy cho chiều rộng và chiều cao bố cục. Việc sửa một đoạn mã để sửa chữa một vấn đề trong một trường hợp sẽ dẫn đến hai mươi vấn đề ở nơi khác vì các nhà phát triển trước đó đã hỗ trợ các vấn đề tương tự bằng cách tùy ý điều chỉnh kết quả tính toán bằng số ma thuật. Mã không thể được mô tả là bất cứ điều gì khác ngoài độc hại.

Cuối cùng tôi đã được trao một dự án mới mà ông chủ của tôi nói với tôi rằng có thể sử dụng mã hiện có này để xử lý bố cục. Bằng cách nào đó tôi đã thuyết phục anh ấy để tôi "thay đổi" nó để anh ấy cho tôi thêm thời gian. Tôi đã sử dụng thời gian để thay vào đó viết một thư viện được thiết kế tốt để hỗ trợ bố trí. Lỗi trong dự án mới này theo nghĩa đen đã khiến tôi mất 10 giây để giải quyết. Tôi có thể xác định các vấn đề trước khi nhìn vào mã để xem những gì đã sai.

Tôi nghĩ rằng điều này sẽ dẫn đến một bước ngoặt cho người quản lý của tôi nhưng tất cả những gì tôi nhận được là một cái vỗ nhẹ vào lưng và về cơ bản anh ấy nói với tôi rằng "Cách của bạn hoạt động quá tôi đoán."

Kể từ khi tôi bắt đầu làm việc cho một cửa hàng khác và mọi thứ ở đây tốt hơn. Quan điểm là, bạn không thể thay đổi suy nghĩ của họ. Chỉ cần đi làm việc ở một nơi khác.

Tôi vẫn có hy vọng, rằng trong nền kinh tế có một loại quá trình tiến hóa, sớm hay muộn sẽ loại bỏ các công ty như vậy ra khỏi kinh doanh. Nhưng có thể tốc độ tiến bộ công nghệ cao tạo ra quá nhiều ngóc ngách mới, nên ngay cả những đối thủ yếu cũng vẫn có thể tìm đủ "thức ăn".

Nếu bạn muốn tăng cơ hội làm việc ở một nơi tốt, hãy tìm một công ty có sản phẩm họ bán cho nhiều khách hàng thay vì viết một cái gì đó mới mỗi vài tuần. Cần có nhiều sự quan tâm hơn để có một cơ sở mã tốt và có thể thêm các tính năng mới mà không phải phá vỡ mã hiện có mọi lúc.

Nhắc nhở tôi về người bạn đời chính của tôi từ trường đại học. Anh ta đang theo học một lớp thiết kế VLSI, và vì bài tập về nhà đầu tiên của anh ta đã đưa ra một thành phần theo thứ tự micromet rộng và dài một dặm. Các mô phỏng thông qua hoàn hảo.

Câu trả lời của ông cho các nhà phê bình của mình là: "Tất cả những gì tôi biết là cứt của tôi hoạt động."

Một tiêu chuẩn khá tốt là nguyên tắc Pareto

Tôi có kinh nghiệm từ một dự án với quy tắc 80-20 và nó hoạt động rất tốt. Tôi nghĩ rằng câu trả lời cho câu hỏi này "Bạn vẽ đường cho sự hoàn hảo của mình ở đâu" cũng có thể hữu ích.

Thuật ngữ "Nguyên tắc Pareto" cũng có thể đề cập đến hiệu quả Pareto. Nguyên tắc Pareto (còn được gọi là quy tắc 80-20, luật của một số ít quan trọng và nguyên tắc về yếu tố thưa thớt) nói rằng, đối với nhiều sự kiện, khoảng 80% các tác động đến từ 20% nguyên nhân. Nhà tư tưởng quản lý kinh doanh Joseph M. Juran đã đề xuất nguyên tắc này và đặt tên theo nhà kinh tế học người Ý Vilfredo Pareto, người đã quan sát vào năm 1906 rằng 80% đất đai ở Ý thuộc sở hữu của 20% dân số; ông đã phát triển nguyên tắc này bằng cách quan sát rằng 20% ​​vỏ hạt đậu trong vườn của ông chứa 80% hạt đậu. Đó là một quy tắc phổ biến trong kinh doanh; ví dụ: "80% doanh số của bạn đến từ 20% khách hàng của bạn". Về mặt toán học, trong đó một cái gì đó được chia sẻ giữa một nhóm người tham gia đủ lớn, phải có một số k trong khoảng từ 50 đến 100 sao cho "k% được lấy bởi (100 - k)% số người tham gia". Số k có thể thay đổi từ 50 (trong trường hợp phân phối bằng nhau, tức là 100% dân số có cổ phần bằng nhau) đến gần 100 (khi một số lượng nhỏ người tham gia chiếm gần như toàn bộ tài nguyên).Không có gì đặc biệt về con số 80% về mặt toán học, nhưng nhiều hệ thống thực sự có k ở đâu đó xung quanh khu vực mất cân bằng trung gian này trong phân phối. Nguyên tắc Pareto chỉ liên quan một cách hữu hình với hiệu quả Pareto, cũng được giới thiệu bởi cùng một nhà kinh tế. Pareto đã phát triển cả hai khái niệm trong bối cảnh phân phối thu nhập và sự giàu có trong dân chúng.

Liên kết đến nguồn

Khi tôi yêu cầu viết lại một số mã tôi đã viết trong khi chúng tôi chủ yếu khám phá thông số kỹ thuật, họ đã từ chối nó. Tôi muốn viết lại mã bởi vì mã được lặp lại ở nhiều nơi, không có sự đóng gói và mọi người phải mất một thời gian dài để thay đổi mã.

Không xúc phạm, nhưng với tư cách là người quản lý, tôi đã đọc câu nói đó ở đâu đó dọc theo dòng:

"Khi tôi yêu cầu được trả tiền hai lần để viết lại một số mã tôi đã viết, công ty của tôi không muốn trả tiền. Tôi muốn có thêm tiền để dọn dẹp mớ hỗn độn mà tôi đã tạo ra khi tôi viết nó lần đầu tiên và các đồng nghiệp đã giận tôi vì làm cho cuộc sống của họ trở nên khó khăn. "

Nếu đó là mã riêng của bạn, bạn đang phàn nàn - bạn không có nhiều thứ để đứng.

CẬP NHẬT

Tôi hiểu rằng POV này là không phổ biến. Nhưng, tôi cũng không nghĩ rằng nó hoàn toàn không phù hợp với trách nhiệm và thái độ của một nhà phát triển chuyên nghiệp.

Nếu bạn viết mã sạch để bắt đầu (và có vô số lý do để làm điều này - bất kể bạn có nghĩ rằng mã của bạn sẽ thấy việc sử dụng sản xuất hay không), thì bạn sẽ gặp vấn đề này ít thường xuyên hơn.

Nếu bạn bao gồm mã sạch và thời gian tái cấu trúc trong các ước tính của mình, bạn cũng sẽ có lịch để giữ cho cơ sở mã hóa gọn gàng. Nếu, vì áp lực lịch trình, bạn không có được thời gian cần thiết - ước tính trong tương lai của bạn sẽ tăng lên do xử lý nợ kỹ thuật phát sinh.

Tại một số điểm, các ước tính trong tương lai của bạn (hoặc không chắc chắn xung quanh các ước tính của bạn) sẽ cho bạn đòn bẩy để tranh luận để viết lại (khi người quản lý của bạn đang cầu xin bạn làm cho quá trình diễn ra nhanh hơn). Nếu không, sau đó chấp nhận rằng doanh nghiệp đã chấp nhận ước tính của bạn và thà trả chi phí liên tục hơn là thay thế. Đó hoàn toàn là một quyết định kinh doanh - không phải là một kỹ thuật.

Hãy nhớ rằng, thời gian để đàm phán lịch trình là trước khi bạn viết mã - không phải sau đó. Sau khi mã được viết (và "công trình"), khách hàng, người quản lý và giám đốc điều hành không muốn thấy một hóa đơn khác cho "bảo trì" tiếp cận hoặc vượt quá chi phí ban đầu. Nếu bạn cảm thấy mạnh mẽ về nó như bạn nghĩ doanh nghiệp nên, hãy thoải mái viết lại nó vào thời gian của riêng bạn - đó là những gì bạn đang yêu cầu doanh nghiệp làm.

Từ quan điểm của người quản lý của bạn, đưa ra lịch trình để viết lại đặt mông của anh ấy lên hàng. Khi bạn không giao hàng, hoặc tăng năng suất nhiều như bạn nói - thì anh ta là người còn lại cầm túi. So với sự bất tiện tương đối nhỏ khi nghe bạn phàn nàn, hãy đoán xem anh ấy sẽ thích cái nào hơn.

Nếu đó là loại công việc mà bạn có thể nhận được, chỉ cần tập trung vào viết mã tốt hơn mỗi lần, thay vì quay lại và viết lại mã cũ. Vẫn còn một phạm vi chất lượng mà bạn có thể chuyển đến trong lĩnh vực dán các gói bên thứ ba lại với nhau.

Nếu bạn có thời gian và muốn cải thiện mã của một thành phần hiện có mà bạn duy trì, bạn không thể làm điều đó mà không cần xin phép, miễn là những gì bạn làm có hiệu quả không? Yếu tố thời gian vào ước tính của bạn cho dự án tiếp theo sử dụng thành phần.

Đối với lập trình cấp thấp hơn, nếu bạn không thể có được sự hài lòng trong học tập từ công việc của mình thì có lẽ đã đến lúc xem xét một dự án nguồn mở?

q303, tôi thấy câu hỏi của bạn thú vị và cảm thấy bạn có thể thấy câu hỏi này của các lập trình viên đáng để đọc, về cách thuyết phục các nhà quản lý để cho các nhà phát triển giải quyết nợ kỹ thuật.

Tôi nghĩ nói chung, vâng, nó là chuẩn mực. Hiểu rằng phần mềm làm việc nhưng kém tối ưu sẽ tốt hơn rất nhiều so với phần mềm không hoạt động. Ngoài ra còn có lập luận rằng định nghĩa "làm việc" có thể thay đổi dựa trên nhận thức và thành kiến ​​của mỗi cá nhân. Khi bạn triển khai một hệ thống mới, sẽ luôn có người nói rằng họ cảm thấy hệ thống cũ tốt hơn. Và khi bạn nói chuyện với một nhà phát triển, anh ấy hoặc cô ấy có thể sẽ miễn cưỡng thừa nhận đã làm việc trên phần mềm crappy.