Khi nào thì chương trình phù hợp của người Viking không còn quan trọng nữa?


49

Tôi đã xây dựng một trò chơi Android trong thời gian rảnh rỗi. Đó là sử dụng thư viện libgdx nên tôi đã thực hiện một số công việc nặng nhọc.

Trong khi phát triển, tôi bất cẩn chọn các kiểu dữ liệu cho một số thủ tục. Tôi đã sử dụng một hashtable vì tôi muốn một cái gì đó gần với một mảng kết hợp. Con người giá trị quan trọng có thể đọc được. Ở những nơi khác để đạt được những điều tương tự, tôi sử dụng một vectơ. Tôi biết libgdx có các lớp vector2 và vector3, nhưng tôi chưa bao giờ sử dụng chúng.

Khi tôi gặp các vấn đề kỳ lạ và tìm kiếm Stack Overflow để được giúp đỡ, tôi thấy rất nhiều người chỉ đưa ra các câu hỏi sử dụng một kiểu dữ liệu nhất định khi một câu hỏi khác về mặt kỹ thuật là "đúng đắn". Giống như sử dụng ArrayList vì nó không yêu cầu giới hạn xác định so với xác định lại int [] với các ranh giới đã biết mới. Hoặc thậm chí một cái gì đó tầm thường như thế này:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Tôi biết nó đánh giá item.length trên mỗi lần lặp. Tuy nhiên, tôi cũng biết các mặt hàng sẽ không bao giờ quá 15 đến 20 mặt hàng. Vì vậy, tôi nên quan tâm nếu tôi đánh giá các mặt hàng. Mỗi lần lặp lại?

Tôi đã chạy một số thử nghiệm để xem ứng dụng hoạt động như thế nào bằng phương pháp tôi vừa mô tả so với phương pháp phù hợp, làm theo hướng dẫn và sử dụng các loại dữ liệu chính xác được đề xuất bởi cộng đồng. Kết quả: Điều tương tự. Trung bình 45 khung hình / giây. Tôi đã mở mọi ứng dụng trên điện thoại và tab galaxy. Không khác nhau.

Vì vậy, tôi đoán câu hỏi của tôi cho bạn là: Có một ngưỡng khi nó không còn quan trọng nữa? Có ổn không khi nói - "miễn là nó hoàn thành công việc, tôi không quan tâm?"


4
Đó là một câu hỏi về tầm quan trọng. Hãy thử tạo cơ sở dữ liệu nhiều terrabyte phục vụ cho thế giới thực với các tìm kiếm và tổng hợp trong thời gian phản hồi thứ hai với hàng ngàn yêu cầu một phút. Vấn đề của bạn không đủ lớn. Mặc dù cách tiếp cận của bạn là tốt, nhưng nếu bạn đi theo con đường đó đến kết luận không thể tránh khỏi thì đó là một điều đau đớn cần có thời gian để tiếp cận.
Jimmy Hoffa

8
Nếu ngôn ngữ của bạn có vòng lặp FOR thực sự, vấn đề đánh giá đó sẽ không xảy ra. Thật không may, cú pháp C yêu cầu nó, bởi vì nó không thực sự là một vòng lặp FOR; đó là một vòng WHILE đeo tóc giả và đeo kính mũi lớn, và bắt buộc phải chấp nhận bất kỳ điều kiện tùy ý nào (hoặc không có gì cả) để chấm dứt vòng lặp.
Mason Wheeler

2
Tôi thấy bản chỉnh sửa của bạn, nhưng nếu bạn đang cố gắng thực hiện trường hợp say rượu và liều lĩnh thì không sao trong bất kỳ bối cảnh nào ngoại trừ tiệc tùng vào tối thứ Sáu với một tài xế được chỉ định, có lẽ bạn đang sủa nhầm cây.
Robert Harvey

17
Làm thế nào để bạn biết nó 'đánh giá' item.length trên mỗi lần lặp? Trình biên dịch khá thông minh. Và thậm chí nếu nó liên tục tìm nạp item.length, vậy thì sao? Tôi ghét nhìn thấy mã như 'int itemsLạng = items.length; for (; i <itemsLpm; ...) 'trừ khi có vấn đề về hiệu suất được đo.
kevin cline

6
Item.length của bạn hoàn toàn không có gì để làm với "lập trình thích hợp". Đó là một tối ưu hóa vi mô và các lập trình viên giỏi biết rõ hơn là lãng phí thời gian cho những người đó cho đến khi họ chạy một trình lược tả và biết các vấn đề hiệu năng thực sự ở đâu . Tối ưu hóa vi mô và phong cách lập trình tốt thường đối lập nhau, không giống nhau.
Michael Borgwardt

Câu trả lời:


65

Bạn viết một chương trình để giải quyết một vấn đề. Vấn đề đó được đi kèm với một bộ yêu cầu cụ thể để giải quyết nó. Nếu những yêu cầu đó được đáp ứng, vấn đề được giải quyết và mục tiêu đạt được.

Đó là nó.

Bây giờ, lý do mà các thực tiễn tốt nhất được quan sát là bởi vì một số yêu cầu phải làm với khả năng bảo trì, kiểm tra, đảm bảo hiệu suất và vv. Do đó, bạn có những người phiền phức như tôi, những người đòi hỏi những thứ như phong cách mã hóa phù hợp. Không cần nỗ lực nhiều hơn để vượt qua chữ T của bạn và chấm vào chữ I của bạn, và đó là một cử chỉ tôn trọng những người phải đọc mã của bạn sau đó và tìm hiểu xem nó làm gì.

Đối với các hệ thống lớn, loại hạn chế và kỷ luật này là điều cần thiết, bởi vì bạn phải chơi đẹp với những người khác để khiến tất cả hoạt động, và bạn phải giảm thiểu nợ kỹ thuật để dự án không sụp đổ dưới sức nặng của chính nó.

Ở phía đối diện của quang phổ là những tiện ích một lần mà bạn viết để giải quyết một vấn đề cụ thể ngay bây giờ, những tiện ích mà bạn sẽ không bao giờ sử dụng lại. Trong những trường hợp đó, phong cách và thực hành tốt nhất là hoàn toàn không liên quan; bạn cùng nhau hack thứ đó, chạy nó và tiếp tục với thứ tiếp theo.

Vì vậy, cũng như rất nhiều thứ trong phát triển phần mềm, nó phụ thuộc.


1
Tôi có xu hướng đồng ý. Trong công việc tôi không đặt câu hỏi, nó bị gạch chéo và rải rác. Nhưng hãy xem xét rằng rất nhiều thứ tôi làm cho công việc là một trong những điều thực sự không cần phải duy trì. Vượt qua các loại xu hướng. Ứng dụng sinh nhật, những thứ đến và đi. Tất cả đều thích hợp ở đó, nhưng họ thực sự không cần phải như vậy.
Kai Qing

21
Người ta có thể làm cho trường hợp bị kỷ luật mọi lúc giúp bạn dễ bị xử lý kỷ luật hơn khi bạn phải như vậy. Một số người đặt câu hỏi về Stack Overflow mà không cần nhấn phím shift, sử dụng lý do rằng họ có thể truyền đạt đầy đủ ý tưởng của mình mà không cần nó, và dù sao thì tiếng Anh cũng là một thứ linh hoạt và phát triển. Tôi không tìm thấy gì đáng lo ngại hơn, ngoại trừ có thể những người viết virus nghĩ rằng thời gian CPU của tôi là miễn phí.
Robert Harvey

2
@KaiQing Ai đó cần trao cho bạn ứng dụng kế thừa 5mloc được sinh ra trong pascal và được chuyển tiếp từ đó, khi bạn cố gắng thêm hoặc thay đổi bất kỳ chức năng nào trên ứng dụng này, bạn sẽ nhận ra ngay tại sao các thực tiễn tốt nhất tồn tại và được giác ngộ.
Jimmy Hoffa

5
@KaiQing, Angry Birds phải chạy trên nhiều nền tảng và nếu trò chơi bị treo trong 2 giây x% khán giả sẽ từ bỏ nó, điều này có nghĩa là sẽ tiết kiệm cho những người chơi Angry Birds ít hơn. Tôi cá là bạn đã viết rất, rất cẩn thận. Có lẽ điều này trả lời câu hỏi của bạn. Nếu mã chỉ dành cho bạn, ai quan tâm bạn làm gì? Nếu có tiền hoặc thời gian của những người khác bị đe dọa thì tốt nhất bạn nên hết sức cẩn thận.
Charles E. Grant

2
@KaiQing Không ai có thể cho bạn biết ngưỡng cho điều đó, đó là biến số từ dự án này sang dự án khác và trên từng dự án theo thời gian. Số lượng biến số ảnh hưởng đến ngưỡng giữa hệ thống có thể duy trì và không phụ thuộc vào: LỘC, Cơ sở người dùng, Cơ sở nhà phát triển, Loại ứng dụng (mật mã so với trình điều khiển), Tính mạnh mẽ, Yêu cầu dự phòng, Mức độ quan trọng của phần mềm (máy chủ email so với . thiết bị hỗ trợ cuộc sống so với tiện ích đồng hồ), Nền tảng được hỗ trợ, Ngăn xếp công nghệ, Lượng dữ liệu được giao dịch hoặc phân tích, Hạn chế kiểm toán lịch sử và nhiều thứ khác ảnh hưởng đến việc mã xấu có thể như thế nào
Jimmy Hoffa

18

Có một câu nói cũ khôn ngoan: "Đừng đi theo bước chân của những người thông thái xưa. Hãy tìm kiếm những gì họ tìm kiếm." Có nhiều lý do cho tất cả các quy tắc về mã hóa 'phù hợp'. Biết tại sao những quy tắc đó tồn tại quan trọng hơn việc biết những quy tắc đó là gì.

Có một quy tắc là bạn không nên đặt một bài kiểm tra có thể được tính toán lại nhiều lần trong một vòng lặp for như thế. Trong các trường hợp quy tắc được phát minh ra để khắc phục (trong đó hiệu suất sẽ thực sự khác biệt), nó có ý nghĩa. Trong trường hợp đó, chỉ có một câu trả lời đúng. Trong ví dụ của bạn, người ta biết rằng không có sự khác biệt về hiệu năng và không thể có nhiều hơn vài chục lần lặp. Trong trường hợp này, có hai câu trả lời đúng, dù là áp dụng quy tắc nào, vì nó đơn giản và sẽ không gây hại gì và có thể giúp hình thành thói quen tốt, hoặc bỏ qua quy tắc, vì không có sự khác biệt về hiệu suất để lo lắng.

Tôi thích câu trả lời đúng đầu tiên, và bạn có vẻ thích câu trả lời thứ hai. Bạn không sai về điều đó. Tôi nghĩ rằng bạn đã sai trong ý tưởng của bạn về việc lập trình 'đúng' là gì. Đó không phải là về việc tuân theo một bộ quy tắc được chọn ngẫu nhiên mà không giúp bạn và không có mục đích. Việc bạn không sửa vòng lặp for trong ví dụ thực sự tuân theo một quy tắc rất tốt chống lại tối ưu hóa sớm.

Lập trình thực sự là về việc tuân theo các quy tắc tốt có ý nghĩa theo một cách thông minh.


Tôi sẽ không nói tôi thích cái thứ hai. Ai đó đã chỉnh sửa bài đăng của tôi để xóa phần nói về việc tôi tạo ra trò chơi Android này gần như hoàn toàn say rượu (chỉ để giải trí) và kết quả là tôi ngạc nhiên khi thấy những lựa chọn say xỉn của mình không có sự khác biệt về hiệu suất. Tôi đã thay thế một số lớp lạ bằng những lớp thích hợp để kiểm tra. Tôi đồng ý mặc dù biết rằng các quy tắc tồn tại quan trọng hơn việc biết các quy tắc là gì ...
Kai Qing

Ngoài ra, ý tưởng về lập trình "đúng đắn" của tôi là đỉnh cao của những ý kiến ​​lặp đi lặp lại của cộng đồng stackoverflow, cũng như bộ sưu tập các lập trình viên đã đến và đi tại công ty tôi làm việc. Một số có bằng CI, một số tự học. Có một ý kiến ​​chung để căn cứ mọi thứ và tôi có xu hướng đồng ý với những gì mọi người nói chung trước khi quyết định rằng một cách là đúng và một cách là sai. Cảm ơn vì đã tham gia.
Kai Qing

1
Nếu nó có vẻ như tôi đang nói với bạn vì đã phá vỡ các quy tắc, thì tôi đã nói sai. Không có điều gì bạn nói về việc làm là những điều tôi sẽ phản đối. Tôi đã cố gắng chỉ ra rằng "tinh thần của luật pháp" quan trọng hơn "thư pháp luật".
Michael Shaw

Heh, không tôi không nghĩ rằng bạn đã nói với tôi. Tôi chỉ đang giao tiếp. Tôi đã hỏi câu hỏi này vì một lý do và tôi rất vui vì nhiều người đã trả lời mà không bỏ phiếu.
Kai Qing

10

Cách thích hợp để xem xét điều này là lợi nhuận giảm dần: so sánh lợi ích gia tăng của việc phát triển chương trình với chi phí phát triển bổ sung.

Lợi nhuận giảm dần đặt ra khi lợi ích cận biên nhỏ hơn thời gian / nỗ lực cận biên.

Bạn có thể làm một trường hợp kinh doanh để di chuyển items.lengthra khỏi forvòng lặp? Về mặt kinh tế, điều đó có thể thay đổi thậm chí biện minh cho thời gian cố gắng biện minh cho nó? Vì không có sự khác biệt trong trải nghiệm người dùng, bạn sẽ không bao giờ nhận được bất cứ điều gì ngay cả thời gian dành cho việc đo lường (ngoài một bài học hữu ích cần nhớ). Người dùng sẽ không thích chương trình nhiều hơn họ và nhiều bản sao sẽ không được bán, do sự thay đổi đó.

Điều này không phải lúc nào cũng dễ dàng để đánh giá, bởi vì các trường hợp kinh doanh chứa đầy những điều chưa biết và rủi ro, và do đó dễ trở thành con mồi cho các yếu tố vô thức sẽ chỉ trở nên rõ ràng trong nhận thức muộn màng. Những thay đổi được đề xuất có thể hoàn toàn không cần thiết, do đó chúng tạo ra sự khác biệt lớn.

Kiểu suy nghĩ giảm dần có thể dẫn đến một cuộc săn tìm lý do để không thực hiện một số hành động, và tránh mạo hiểm, điều này có thể chứng minh là một chuỗi các cơ hội bị bỏ lỡ.

Nhưng đôi khi nó là hiển nhiên khi không làm điều gì đó. Nếu một phần của sự phát triển dường như đòi hỏi một phép màu kinh tế xảy ra chỉ để trả chi phí phát triển (hòa vốn), thì đó có lẽ là một ý tưởng tồi.


Viết rất tốt. Trong trường hợp của tôi không bao giờ có kế hoạch trở lại. Bất kỳ sự trở lại nào cũng có thể là ngẫu nhiên nhưng không nên bị loại bỏ vì tôi nghĩ rằng một số thành công lớn nhất bắt đầu như sán. Về mặt công việc của khách hàng, nơi không có quá nhiều tiền bị đe dọa vì có thể chỉ có tình trạng tăng nặng nếu ứng dụng bị treo hoặc một cái gì đó trở thành một bất tiện nhỏ, đó là một ngưỡng dày hơn. Nếu các điểm chuẩn có vẻ tốt, nhưng mã được biết là không hiệu quả nhất, thì sẽ không có ai đi cùng để kiểm tra nó trước thời điểm tiến trình mã và có thể yêu cầu di chuyển bằng mọi cách ... khó có thể nói về điều đó.
Kai Qing

Thật. Chúng ta không thể luôn luôn tạo ra một số trường hợp khách quan. Không phải ai cũng coi trọng chương trình theo cùng một cách. Giả sử rằng tiện ích chính trong chương trình là niềm vui khi làm việc với nó. Điều đó có thể không có lợi cho bất kỳ ai khác và không ai sẽ trả tiền cho các cải tiến (nếu thậm chí còn có người dùng ngoài lập trình viên), nhưng nó đủ để biện minh cho việc cải thiện nó theo bất kỳ cách nào.
Kaz

Hai từ hữu ích để thêm vào câu trả lời được viết rất tốt của bạn - "Đầu tư đầu cơ" - bạn làm điều đó bởi vì bạn suy đoán sẽ có lợi nhuận trong tương lai.
mattnz

@mattnz - những gì bạn nói là đúng ở chỗ không ai làm điều gì đó mà không trở lại, ngay cả khi sự trở lại là một tiếng cười tốt. Hầu như tất cả các dự án cá nhân của tôi được thực hiện cho sự hài hước. Hầu như tất cả trong số họ làm đủ để biện minh cho yêu cầu của họ. Không ai trong số họ đã cho phép tôi bỏ thuốc lá.
Kai Qing

Chính xác, mọi người. Vì vậy, trước tiên chúng tôi xác định những gì chúng tôi hy vọng sẽ nhận được khi viết chương trình này, hoặc tiếp tục làm điều đó. Rằng một cái gì đó có thể là "thời gian trôi qua thật vui vẻ". Nhưng ngay cả khi đó, chúng ta có thể nghĩ: đang làm việc như vậy và một thứ như vậy trong một chương trình như vậy và là cách tốt nhất để đạt được niềm vui nhất, hoặc chúng ta đặt thời gian vào một thứ khác.
Kaz

3

Khi bạn không nên quan tâm đến mã của mình là "đúng"

  • Nếu bạn quản lý để trả lời mục tiêu kinh doanh và giữ nó theo thời gian với chi phí thấp. (người dùng không xem nguồn trước khi họ trả tiền cho bạn)
  • MVP / POC - Nếu viết mã phù hợp có nghĩa là lãng phí thời gian cho một khái niệm trước khi bạn biết cách kiếm tiền từ nó (nếu bạn dành nhiều năm và 45 triệu đô la để viết ứng dụng của mình và kết thúc việc đóng cửa vì nó không có thị trường, không ai quan tâm đúng là mã)
  • Khi gặp tình huống đe dọa tính mạng (ví dụ nguyên mẫu người sắt 1 là một vụ hack bẩn thỉu, nhưng nó đã đưa anh ta ra khỏi hang phải không?)
  • hoặc nếu bạn chỉ đơn giản là không biết cách viết mã phù hợp (nếu somene quản lý để kiếm sống bằng cách viết mã không đúng, thì trong thất nghiệp ngày nay, tôi nói, viết mã xấu hơn là vô gia cư)
  • nếu bạn chỉ đơn giản biết những gì bạn đang làm hoặc nghĩ rằng bạn có thể thoát khỏi nó giả vờ như bạn làm

Khi nào viết mã đúng

  • Nếu nó sẽ có tác động kinh doanh đáng kể, ví dụ hiệu suất sẽ ảnh hưởng đến doanh thu hoặc ngăn chặn doanh số
  • Nếu nó không phù hợp thì việc duy trì mã trở thành một vấn đề kinh doanh (chi phí bảo trì cao)
  • Nếu bạn là một lập trình viên nổi tiếng làm việc trong một dự án nguồn mở lớn
  • Tương tự đối với một công ty lớn đóng góp một thư viện nội bộ cho thế giới
  • Nếu bạn muốn thể hiện công việc của mình như một danh mục đầu tư trong các cuộc phỏng vấn trong tương lai

1
Đáng buồn thay, có một người khác trong danh sách không quan tâm để trở thành danh sách phù hợp mà nhiều người may mắn không biết: Khi một khách hàng nôn ra một hệ thống cũ vào sự chăm sóc của bạn và nói với bạn rằng họ cần nó được thực hiện trong một tuần. Đôi khi thời gian và / hoặc ngân sách không cho vay tiền mã hóa phù hợp và sự chú ý của bạn đối với dự án là một ân huệ hơn là một giao dịch kinh doanh. Ví dụ: nếu mã của họ sử dụng các phương thức phần lớn không dùng nữa nhưng cần một số bản vá (nói theo kịch bản web). Không thể sửa chữa toàn bộ. Phải bẩn.
Kai Qing

"Nếu nó không phù hợp đến nỗi việc duy trì mã trở thành một vấn đề kinh doanh (chi phí bảo trì cao)." Ngưỡng này thực sự thấp hơn đáng kể so với hầu hết các nhà phát triển thiếu kinh nghiệm có xu hướng tin tưởng. Viết mã rắn thường tự trả lại trong vài giờ, không phải ngày hoặc tháng.
Peter ALLenWebb

2

Là hiệu suất mối quan tâm chính của bạn? Có phải đó là những gì bạn đang cố gắng tối đa hóa?

Nếu vậy, có một bài học cơ bản để học, và nếu bạn làm thế, bạn sẽ là một trong số ít.

Đừng cố gắng "nghĩ" những gì bạn nên làm để làm cho nó nhanh hơn - đó là phỏng đoán. Nếu bạn hỏi "Tôi nên sử dụng lớp container này hay lớp kia?" Hoặc "Tôi có nên đặt lengthđiều kiện vòng lặp không?", Bạn giống như một bác sĩ gặp bệnh nhân và cố gắng quyết định nên điều trị bằng cách nào mà không thực sự đặt câu hỏi hoặc kiểm tra bệnh nhân.

Đó là đoán. Mọi người đều làm nó, nhưng nó không hoạt động.

Thay vào đó, hãy để chương trình tự cho bạn biết vấn đề của nó là gì. Đây là một ví dụ chi tiết.

Bạn có thấy sự khác biệt?


Tôi sẽ nói rằng mối quan tâm duy nhất của tôi là trong các thử nghiệm của tôi, tôi nhận thấy không có sự khác biệt về hiệu năng giữa việc sử dụng đúng kiểu dữ liệu cho kịch bản được chỉ định. Như trong đề xuất của bạn, tôi đã quá tải lớp với nhiều dữ liệu hơn để xem liệu nó có quá ít để tạo ra sự khác biệt hay không. Cuối cùng, cả hai thực hiện như nhau. Cấp, tôi chỉ làm một trò chơi RPG cơ bản. Nó không giống như phần mềm ngân hàng hoặc một cái gì đó phức tạp. Nhưng nó đã khiến tôi tự hỏi liệu sẽ tốt hơn cho việc kinh doanh không phải lúc nào cũng đúng như vậy.
Kai Qing

Vì hiệu suất là mối quan tâm của bạn, bạn nên hỏi chương trình những gì bạn nên xem, không hỏi xem câu hỏi định trước của bạn có làm nên sự khác biệt không. Vui lòng nhấp vào liên kết này và làm những gì nó nói. Nó sẽ cho bạn biết chương trình thực sự dành thời gian vào lúc nào, và điều đó sẽ cho bạn biết làm thế nào để làm cho nó nhanh hơn.
Mike Dunlavey

Vâng, hiệu suất là cơ sở của tôi cho thủ tục đặt câu hỏi, không nhất thiết phải là một mối quan tâm. Tôi không tìm kiếm điểm chuẩn cho mỗi lần nói. Chỉ quan sát rằng mã không hiệu quả làm cho không có sự khác biệt hiệu suất. Nó về cơ bản là minh bạch cho người dùng về mức độ hiệu quả hoặc không hiệu quả của chương trình, do đó làm cho mối quan tâm về hồ sơ như vậy không liên quan. Cấp, tôi đã có một số mối quan tâm để điểm chuẩn ở nơi đầu tiên, nhưng chủ yếu là sự tò mò. Và nếu sản phẩm được hoàn thành và nó chậm một cách đáng chú ý thì có, một hồ sơ có ý nghĩa. Cảm ơn liên kết
Kai Qing

2

Câu hỏi của bạn là "miễn là nó hoàn thành công việc, tôi không quan tâm?"

Câu trả lời của tôi là "bạn không bao giờ biết điều gì sẽ xảy ra với mã của bạn." Tôi đã tham gia vào rất nhiều dự án bắt đầu như "hey hãy để tôi viết điều này nhanh chóng để giải quyết vấn đề của người dùng." Viết nó, đưa nó ra khỏi đó, không bao giờ nghĩ về nó một lần nữa.

Một lần, điều mà tôi đã viết biến thành "ồ, bây giờ toàn bộ bộ phận người dùng muốn sử dụng mã đó", mà trước khi tôi có thể quay lại, "toàn bộ công ty đang sử dụng mã đó và bây giờ tôi phải chứng minh rằng nó sẽ tồn tại trong một cuộc kiểm toán và có một cuộc rà soát mã 20 người dự kiến ​​vào ngày mai và một số phó chủ tịch đã bán nó cho khách hàng của chúng tôi. "

Tôi nhận ra bạn "chỉ viết một trò chơi Android trong thời gian rảnh rỗi" nhưng bạn không bao giờ biết liệu trò chơi đó sẽ cất cánh và trở thành tấm vé cho sự nổi tiếng và tài sản của bạn. Tệ hơn nữa, trò chơi đó có thể trở thành tấm vé khét tiếng của bạn vì nó liên tục làm hỏng điện thoại của mọi người. Bạn có muốn trở thành người nhận được lời mời làm việc vì trẻ em của ai đó không thể ngừng chơi trò chơi của bạn trên điện thoại của họ, hoặc bạn có muốn trở thành người bị phỉ báng trên bảng tin như thế này không?


1

Câu trả lời là nó không bao giờ quan trọng, và nó luôn luôn quan trọng ....

Nó không bao giờ quan trọng bởi vì lập trình, đúng hay không, là một cách để đạt được một mục tiêu, bản thân nó không phải là một mục tiêu. Nếu mục tiêu đó đạt được mà không cần lập trình "đúng" thì tốt (từ góc độ kinh doanh, tốt nhất là nếu mục tiêu có thể đạt được mà không cần lập trình).

Nó luôn luôn quan trọng bởi vì lập trình thích hợp là một công cụ sẽ giúp bạn đạt được mục tiêu của mình. Cách làm việc đúng đắn chỉ đơn giản là một sự công nhận rằng làm theo cách khác gây ra nhiều đau đớn trong thời gian dài hơn là tiết kiệm.

Câu trả lời nào cho câu hỏi khi nào bạn có thể bỏ qua nó - khi bạn chắc chắn rằng cách khác sẽ dễ dàng hơn trong thời gian dài (có thể vì sẽ không có thời gian dài).

Các công cụ tắt thường được thực hiện nhanh và bẩn nhất có thể, với ít hoặc không kiểm tra lỗi hoặc xác nhận khác, không ghi nhật ký ngoại lệ, mã cắt dán với các thay đổi nhỏ hoặc thậm chí không thay đổi thay vì các chức năng chung, v.v. .

Chỉ cần để ý: đôi khi những ứng dụng nhanh và bẩn đó tự mình xử lý, điều đó có nghĩa là tất cả các vết cắt ngắn cắn bạn trong ...


1
"Không bao giờ" và "luôn luôn" hủy bỏ nhau. Làm cho câu trả lời của bạn cả tốt và xấu.
Tulains Córdova

@ user1598390: việc họ hủy bỏ nhau là điểm chính. Hủy bỏ giáo điều, và bạn còn lại vì nó có vẻ hữu ích. Và bạn sẽ hiểu sai và học hỏi từ đó.
jmoreno

Tôi muốn nói rằng tôi đồng ý với bạn nhưng tôi sẽ không đưa nó đến những thái cực như vậy. Tôi không nghĩ rằng một lần tắt thường chỉ là nhổ ra, thoát khỏi thử nghiệm hoặc gỡ lỗi. Chỉ cần nó không được tối ưu hóa và được thiết kế hoàn hảo sẽ không làm cho sản phẩm trở nên kém hơn nếu hiệu suất và độ ổn định không bị ảnh hưởng bởi shortcust. Cuối cùng, đó là quan điểm của tôi và tại sao tôi tự hỏi tại sao mọi người lại tạo ra một mùi hôi như vậy đối với các ví dụ mã hóa không phải là hàng đầu. Nó xảy ra rất nhiều trên stackoverflow.
Kai Qing

@KaiQing: Tất nhiên việc kiểm tra và gỡ lỗi xảy ra, nhưng thường bị giới hạn ở những gì tồn tại vào lúc này - vì vậy, nếu quá trình có thể thất bại với một tệp có mã hóa UTF và không có tệp nào bạn thực sự làm việc làm, bạn không kiểm tra điều đó. Tối ưu hóa nên được thực hiện khi một vấn đề hiệu suất đã được xác định. Về lý do tại sao một mùi hôi thối trên các ví dụ mã hóa hàng đầu trên SO - Tôi nghĩ đó là một chức năng của các mục tiêu trang web. Nó nhằm mục đích trở thành tài nguyên vĩnh viễn, mã trong các câu trả lời (và thậm chí cả câu hỏi) do đó được xem như thể chúng sẽ là một mẫu mà người khác sử dụng.
jmoreno

1

Hoặc thậm chí một cái gì đó tầm thường như thế này:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Tôi biết nó đánh giá item.length trên mỗi lần lặp. Tuy nhiên, tôi cũng biết các mặt hàng sẽ không bao giờ quá 15 đến 20 mặt hàng. Vì vậy, tôi nên quan tâm nếu tôi đánh giá các mặt hàng. Mỗi lần lặp lại?

Trên thực tế trong mã cuối cùng, items.length sẽ không được đánh giá trong mỗi lần lặp vì trình biên dịch tối ưu hóa nó. Và ngay cả khi nó không, chiều dài là một trường công khai trong đối tượng mảng; truy cập nó không chi phí.

Vì vậy, tôi đoán câu hỏi của tôi cho bạn là: Có một ngưỡng khi nó không còn> vấn đề là đúng? Có ổn không khi nói - "miễn là nó hoàn thành công việc, tôi> không quan tâm?"

Nó thực sự phụ thuộc vào những gì bạn mong đợi từ sản phẩm cuối cùng của bạn; sự khác biệt giữa một sản phẩm trung bình và một sản phẩm tuyệt vời phụ thuộc vào chi tiết. Một chiếc xe như Tata Nano và một chiếc xe như Mercedes S "hoàn thành công việc" - nó đưa bạn từ nơi này đến nơi khác. Sự khác biệt phụ thuộc vào chi tiết: sức mạnh động cơ, sự thoải mái, an toàn và những thứ khác. Nó giống nhau với bất kỳ sản phẩm nào tồn tại, bao gồm các sản phẩm phần mềm; ví dụ tại sao mọi người sẽ trả tiền cho Oracle, IBM hoặc Microsoft cho cơ sở dữ liệu Oracle, DB2 hoặc MS SQL Server vì MySQL và Postgre đều miễn phí?

Nếu bạn muốn chú ý đến các chi tiết và có được một sản phẩm chất lượng cao, bạn nên quan tâm đến công cụ này (và về những thứ khác, rõ ràng).


Tôi không nghĩ rằng tôi đồng ý với điều đó mặc dù. Trong bài viết của tôi, tôi đề cập đến không có sự khác biệt trong hiệu suất. Điều đó sẽ cho thấy không có sản phẩm trung bình hoặc tuyệt vời, nhưng một sự cân bằng như nhau mặc dù thiếu sót của một. Tôi sẽ đồng ý với tuyên bố của bạn, tuy nhiên, nếu có một dự án cụ thể có tầm quan trọng lớn, tất cả chúng ta đều sử dụng làm so sánh. Nhưng một cách trừu tượng, quan sát chung là trong dự án ẩn danh này, một lớp không hiệu quả được quyết định thực hiện như nhau với một lớp được tối ưu hóa. Vì vậy, sau đó, có thể chấp nhận một thái độ chậm chạp về điều này hoặc tranh luận cho sự hoàn hảo mỗi lần?
Kai Qing

@Kai Qing Một lớp duy nhất không (hoặc không nên) tạo ra nhiều sự khác biệt. Tôi đã nói điều đó: nếu bạn mong đợi sản phẩm của mình là một sản phẩm chất lượng cao thì hãy chú ý đến các chi tiết (ngay cả khi nó có nghĩa là có thể tối ưu hóa một chút hoặc thiết kế cẩn thận); mặt khác, nếu điều duy nhất bạn muốn là một hệ thống chức năng thì có lẽ bạn không nên chú ý nhiều đến các chi tiết nhỏ.
m3th0dman

Vâng, bạn đúng, nó không nên tạo ra sự khác biệt ngay cả khi chỉ cần một chút quan tâm trong thiết kế của nó. Nhưng nó có thể tạo ra sự khác biệt tùy thuộc vào mục đích của nó hoặc nếu nói chung mục đích của nó biến đổi theo thời gian và trở thành thứ mà nó không có ý định. Nhìn thấy điều đó trước đây, nhưng tôi chỉ tiếp tục ở đây. Công bằng mà nói, một sản phẩm có thể có chất lượng cao mà không cần phải có nhiều hơn chức năng.
Kai Qing

1

Nếu bạn đang lập trình tại nhà cho chính mình thì có lẽ bạn có thể cắt một vài góc; và khi bạn đang thử nghiệm và thử mọi thứ thì điều này hoàn toàn hợp lý.

Tuy nhiên, hãy cẩn thận. Trong ví dụ bạn đưa ra thực sự không cần phải cắt góc đó, và bạn cần cẩn thận. Điều này có thể bắt đầu một xu hướng và những thói quen xấu mà bạn làm ở nhà có thể xâm nhập vào mã của bạn tại nơi làm việc. Tốt hơn nhiều để thực hành và cải thiện các thói quen tốt ở nhà và để chúng thấm vào mã của bạn tại nơi làm việc. Nó sẽ giúp bạn và nó sẽ giúp người khác.

Bất kỳ chương trình bạn làm và bất kỳ suy nghĩ bạn làm về lập trình là tập thể dục. Làm cho nó đáng giá, nếu không nó sẽ quay lại và cắn bạn.

Nhìn vào mặt tốt mặc dù. Bạn đã hỏi về điều này vì vậy có lẽ bạn đã nhận thức được điểm mà tôi đang thực hiện.


1
Vâng, tôi biết nhưng điểm của câu hỏi chủ yếu là trong bối cảnh nhỏ hơn, chứa đựng dường như không có lý do gì để đúng như vậy. Trong tất cả những năm lập trình của tôi, thực sự đã không có nhiều thứ rón rén quay lại cắn chúng tôi. Tôi nghi ngờ rằng chúng tôi rất đúng đắn. Tôi nghĩ rằng ngôn ngữ và kỳ vọng thay đổi như phần mềm bình thường. Một số ít hơn những người khác. Nhưng cuối cùng, sự kém hiệu quả của một dự án chỉ có thể được nhận ra khi dự án đó trong quá khứ và không còn cần thiết nữa. Nó làm cho nó khó để biện minh cho sự đau đầu của quá cứng nhắc.
Kai Qing

Đó là một điểm công bằng. Quy tắc của ngày hôm nay có thể là hạn chế của ngày mai. Tôi không thích được nói phải làm gì, nhưng tôi rất tôn trọng những người khác đã đi trước và đã học được cách khó khăn. Đôi khi, mặc dù có thể thú vị để tìm hiểu những quy tắc nào hữu ích và những gì hiện đã qua ngày bán của họ.
Daniel Hollinrake

1

Nếu một nhà sản xuất đồ nội thất đang tạo ra một mảnh đồ nội thất được sử dụng trong đó chất lượng không phải là điều quan trọng nhất hoặc chất lượng có thể không được chú ý, họ có nên cố gắng cắt thẳng và thực hiện một công việc phù hợp để ghép các mảnh lại với nhau không?

Nhiều người coi phần mềm là nghề thủ công. Những gì chúng ta xây dựng không nên chỉ thực hiện một chức năng, nó cần phải đáng tin cậy, có thể bảo trì, mạnh mẽ. Làm phần mềm như vậy đòi hỏi kỹ năng, và kỹ năng đó đến từ thực tiễn.

Vì vậy, mặc dù việc lựa chọn một cấu trúc lặp cho những gì bạn đang làm ngày hôm nay có thể không quan trọng, thực tế là bạn cố gắng sử dụng các cấu trúc phù hợp mọi lúc sẽ giúp bạn trở thành một lập trình viên tốt hơn.


Tôi đã gặp các trường hợp trong lập trình mà mã không cần phải duy trì hoặc thực hiện ngoài nhu cầu. Giống như các tiện ích kiosk cho các triển lãm thương mại hoặc các sự kiện rất cụ thể và không có khả năng được sử dụng lại. Trong trường hợp trò chơi của riêng tôi - tôi là người duy nhất duy trì nó, vì vậy cuộc tranh luận đó có thể không được áp dụng nhiều nhất. Tôi vẫn còn nghi ngờ về quan điểm chung về "lập trình viên tốt hơn" bởi vì việc tuân thủ chặt chẽ các hướng dẫn, khả năng duy trì và sử dụng đúng kiểu dữ liệu có thể đủ làm nản lòng khi không hoàn thành dự án. Nếu mã hoạt động như mong đợi, tại sao nó hoàn hảo?
Kai Qing

Ngay cả khi phần mềm bạn đang xây dựng right_now không cần phải bảo trì, hãy viết phần mềm như thể nó đã củng cố các kỹ năng mã hóa của bạn. Khi cuối cùng bạn phải viết mã có thể bảo trì, bạn sẽ có thể làm điều đó dễ dàng hơn.
Bryan Oakley

Tôi phải viết mã duy trì mọi lúc. Chỉ trong một số trường hợp, nó không phải như vậy. Tuy nhiên, tôi có nhiều kinh nghiệm nên tôi thường biết khi nào và nơi nào để cắt góc. Điểm chính của bài đăng này là chỉ khuấy động cuộc trò chuyện về ngưỡng thích hợp và cẩu thả cho bất kỳ mục đích nào. Ví dụ của tôi chỉ quét nhẹ vào nó vì ví dụ đưa ra hầu như vô hại trong một ứng dụng nhỏ hơn. Tuy nhiên, nếu tôi viết phần mềm ngân hàng, tôi sẽ không bao giờ bất cẩn như vậy.
Kai Qing
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.