it-swarm-vi.com

Những cám dỗ có hại trong lập trình

Chỉ tò mò, những loại cám dỗ trong lập trình hóa ra thực sự có hại trong các dự án của bạn?

Giống như khi bạn thực sự cảm thấy thôi thúc phải làm một cái gì đó và bạn tin rằng nó sẽ có lợi cho dự án nếu không bạn sẽ tự lừa mình tin vào điều đó, và sau một tuần bạn nhận ra rằng bạn đã không giải quyết được bất kỳ các vấn đề thực nhưng thay vào đó tạo ra các vấn đề mới hoặc, trong trường hợp tốt nhất, làm hài lòng con thú bên trong của bạn mà không có tác động rõ ràng.

Cá nhân, tôi thấy rất khó để không cấu trúc lại mã xấu. Tôi làm việc với rất nhiều mã kế thừa xấu và phải hít một hơi thật sâu để không chạm vào nó khi tôi không có bài kiểm tra nào để chứng minh việc tái cấu trúc của mình không phá vỡ bất cứ điều gì.

Một con quỷ khác đối với tôi trong giao diện người dùng, tôi thực sự có thể dành hàng giờ để thay đổi bố cục UI chỉ vì tôi thích làm việc đó. Đôi khi tôi tự nhủ mình đang làm việc với khả năng sử dụng, nhưng sự thật chỉ là tôi thích di chuyển các nút xung quanh.

Quỷ lập trình của bạn là gì và làm thế nào để bạn tránh chúng?

97
Dan

Tổng quát hóa sớm là lỗi lớn của tôi; thay vì giải quyết vấn đề trong tay trước và đợi cho đến khi có nhu cầu thực sự cần giải quyết cho trường hợp chung, tôi luôn đi sau trường hợp chung trước và kết thúc việc viết một tấn mã phức tạp hơn mức cần thiết.

Cập nhật:

Xem " Tội lỗi số 1 - Tổng quát hóa sớm " để biết mô tả chuyên sâu.

67
John Bode

"Chúng tôi sẽ quay lại vấn đề này và sửa nó sau. Chúng tôi chỉ cần nó hoạt động ngay bây giờ!"

197
user18041

Hạn chót là rất xa, tôi có quá nhiều thời gian để làm điều đó, vậy tại sao không dành một chút thời gian để lướt web?

105
user281377

"Đây chỉ là mã bằng chứng khái niệm vứt đi. Một khi họ thích nó, tôi sẽ thực sự làm cho nó tốt."

103
davidhaskins
  1. Tái cấu trúc một phần của mã một vài ngày trước khi phát hành.
  2. Internet : Sự phân tâm lớn nhất trong tất cả.
  3. Công nghệ mới: Không thể rời tay khỏi công nghệ mới.
  4. Tối ưu hóa : Tối ưu hóa, tối ưu hóa. .. và tối ưu hóa hơn nữa
  5. Sự hoàn hảo: Chưa bao giờ hài lòng với mã.
  6. TODO : Thiếu todos thời gian sẽ không bao giờ được thực hiện.
  7. Ước tính thời gian : Nhiều PM không coi đây là "ước tính". Họ coi như thực tế.
  8. Lời hứa : Đưa ra quá nhiều lời hứa.
74
Amir Rezaei

Trở thành con mồi để cố gắng xây dựng mọi thứ trong nhà, khi có các khung và thư viện hiện có.

55

Quỷ tái phát của tôi: Tối ưu hóa sớm và áp đảo.

Và tôi vẫn không thể tránh họ 100% ...

48
Tomas Narros

Ước tính quá lạc quan

Khi người quản lý của bạn đang nhìn chằm chằm xuống bạn và bạn cảm thấy cảm giác nóng bỏng muốn đưa ra ước tính thấp hơn so với ruột của bạn đang nói với bạn ... đừng làm thế !

Rốt cuộc, ruột của bạn là có lẽ đã quá thấp rồi!

46
Nicole

Để sử dụng công nghệ/công cụ/ngôn ngữ trong dự án của bạn hoàn toàn vì bạn vừa mới học nó.

Để cố gắng chứng minh bạn là một nhà phát triển giỏi như thế nào.

Để xem xét mã bạn đã viết là của bạn.

33
biziclop

Tôi sẽ nghỉ ngơi và xem stackoverflow.com;)

32
Richard Miskin

Sự cám dỗ tồi tệ nhất:

Oh, tốt .. Tôi đoán một mẹo nhỏ/hack/sửa chữa bẩn sẽ không bị tổn thương.

Đoán xem, nó có đau không. :)

goto

31
Goran Jovic
25
Dan

Creep tính năng

Lập một kế hoạch, bám sát và triển khai. Và sau đó quay lại và thêm những thứ mà mọi người đang yêu cầu.

Tôi đã thấy điều này nhiều lần. Bạn ngồi xuống, thiết kế và bắt đầu viết mã. Người dùng nghe thấy một số điều vô nghĩa nhầm lẫn về tính năng yêu thích của họ bị "mất tích" và họ bắt đầu vận động hành lang cho nó. Sếp của bạn yêu cầu bạn thêm nó vào giờ thứ 11, nó phạm lỗi khi triển khai, nó giới thiệu các lỗi ở khắp mọi nơi và 3 tháng sau, khi mọi người đã ổn định, bạn được yêu cầu xóa nó, bởi vì không ai có thể hiểu tại sao bạn đặt tính năng retro nhảm nhí ở nơi đầu tiên! Bạn không thể nói rằng phần còn lại của thiết kế làm cho nó vô nghĩa?

23
Satanicpuppy
  1. Thêm nhiều tính năng

  2. Cuộc thi có tính năng này. Vì vậy, đây là một tính năng phải có do đó lập trình nhiều hơn là phân tích chiến lược, định vị, v.v.

  3. Cuộc thi KHÔNG có tính năng này. Vì vậy, đây là một tính năng khác biệt do đó lập trình nhiều hơn là phân tích chiến lược, định vị, v.v.

  4. Giải quyết một vấn đề kinh doanh với lập trình nhiều hơn. ví dụ, chuyên môn tốt hơn trong việc quản trị máy chủ linux, trang web của bạn được lưu trữ trên không thể có được thông qua lập trình nhiều tính năng hơn. Đôi khi bạn chỉ cần học cách khắc phục sự cố thay vì mã hóa lại toàn bộ vào C # .Net

  5. Giải quyết một vấn đề tiếp thị với lập trình nhiều hơn. ví dụ: lạm dụng khái niệm bò tím của Seth Godin rằng bạn đang gián tiếp giải quyết vấn đề tiếp thị bằng cách lập trình thêm các tính năng vào sản phẩm của bạn để biến nó thành "con bò tím". Đôi khi, nó chỉ là một con quái vật đột biến.

  6. Giải quyết vấn đề năng suất với việc lập trình nhiều hơn cho chính mình rằng thời gian viết kịch bản này sẽ được lưu lại sau vài giờ thay vì thực sự lập trình công cụ thực sự quan trọng

  7. Lập kế hoạch để mã nhưng chưa mã hóa vì bạn muốn "làm cho đúng"

  8. Mã hóa một phiên bản bẩn và hứa rằng bạn sẽ "làm cho nó tốt hơn sau" nhưng không bao giờ quay lại để "làm cho nó tốt hơn"

  9. Không thực hiện một mockup hoặc sơ đồ trang web vì nó "quá rắc rối". Tôi chỉ có thể chụp màn hình các trang của đối thủ cạnh tranh cho mockup và vẽ sơ đồ trang web "sau này" không bao giờ có. Và sau đó chỉ cần đi thẳng vào lập trình trang đầu tiên tôi hình dung trong đầu.

Thú nhận: Cá nhân tôi đã mắc lỗi 1, 3, 7, 8. Tôi cũng đã mắc 2, 4, 5, 6 nhưng thường tự lừa dối bản thân mình rằng tôi đã không làm.

Tôi hiện đang khắc phục 9.

[~ # ~] chỉnh sửa [~ # ~] Không nhận ra câu hỏi yêu cầu chúng tôi đưa ra giải pháp.

1) Thêm nhiều tính năng hơn Chỉ cần không làm điều đó. Làm việc với doanh nghiệp, tiếp thị, người sáng lập, cố vấn, v.v. và tước ứng dụng của bạn chỉ còn 1 điều.

Hãy đọc về Twitter, Groupon , v.v ... về cách họ chỉ loại bỏ mọi thứ xuống chỉ còn 1 điều dẫn đến thành công của họ.

Nếu bạn nghĩ rằng nó chỉ hoạt động nếu bạn muốn xây dựng các công ty lớn, hãy nghĩ lại. Ctrl + F cho dòng này "Tôi càng thêm nhiều tính năng vào phần mềm, nó càng bán chạy. (Điều này, không cần phải nói, rất không trực quan đối với hầu hết các nhà phát triển phần mềm.)" Trong liên kết này

2) Cuộc thi có tính năng này. Vì vậy, đây là một tính năng phải có

Xem giải pháp 1

3) Cuộc thi KHÔNG có tính năng này. Vì vậy, đây là một tính năng khác biệt

Xem giải pháp 1

4) Giải quyết vấn đề kinh doanh với nhiều chương trình hơn.

Nếu bạn cần thuê một ai đó để dạy bạn, tư vấn, hoặc làm điều đó cho bạn và sau đó ghi lại cách anh ấy đã làm, để bạn có thể tự làm điều đó vào lần tới. CỨ LÀM ĐI!! Không viết lại mã, không vượt qua GO, không thu 200 đô la.

5) Giải quyết vấn đề tiếp thị với nhiều chương trình hơn.

Nếu mọi người không hiểu bạn đang bán gì, thì nó IS một vấn đề tiếp thị. Quay trở lại giải pháp 1 và xoay vòng.

6) Giải quyết vấn đề năng suất với nhiều chương trình hơn

Chờ đợi.

Đợi cho đến khi bạn cảm thấy rằng năng suất của bạn đã gặp phải một vấn đề năng suất cụ thể trong khoảng thời gian dài hơn 2 tuần và điều đó hợp lý sẽ xảy ra trong 2 tuần nữa.

Bây giờ, hãy đánh giá lượng thời gian dành để lập trình một kịch bản để giải quyết vấn đề này. Hãy nhớ lấy ước tính tồi tệ nhất của bạn và nhân với 2.

Nhân ước tính của bạn với tỷ lệ hàng giờ của bạn.

Bây giờ hãy xem xét các giải pháp thay thế: thuê ngoài, mua một giải pháp sẵn có, không làm gì về nó, v.v.

Chọn giải pháp hiệu quả nhất.

Dính vào nó.

7) Lập kế hoạch mã nhưng chưa mã hóa vì bạn muốn "làm cho đúng"

Đi tập thể dục. Bạn sẽ cảm thấy một Rush endorphin sẽ thúc đẩy mông của bạn và khiến bạn có kế hoạch hành động. Tôi biết điều này bởi vì tôi vừa mới tập 5x5 và squats 5x5.

8) Mã hóa phiên bản bẩn và hứa rằng bạn sẽ "làm cho nó tốt hơn sau" nhưng không bao giờ quay lại "làm cho nó tốt hơn"

Thiết lập hệ thống tập tin tickler trong GTD. và tích cực theo dõi. Thực hiện theo tất cả các lời hứa với bản thân và những người khác.

9) Không thực hiện mô hình hoặc sơ đồ trang web vì nó "quá rắc rối".

Đi chi 75 USD cho phiên bản máy tính để bàn balsamiq mockups. Tôi biết điều này bởi vì tôi đã mua nó 3 tuần trước. Nó đã làm cho tôi làm lại các mockup của mình bởi vì tôi cảm thấy như một nghệ sĩ, kiến ​​trúc sư và Visionary all in 1 mặc dù bản vẽ của tôi trong thế giới thực rất tệ. Phông chữ được sử dụng trong balsamiq vô thức nhắc nhở bạn rằng đây chỉ là một mockup, không được đặt trong đá giúp bạn trong RAD.

Kết thúc EDIT

20
Kim Stacks

Một vài loại bia sẽ giúp tôi làm việc tốt hơn và lâu hơn.

17
Adam Crossland

"Vâng, tôi có thể tái cấu trúc mớ hỗn độn khổng lồ gồm 2000 dòng mì spaghetti trong một ngày ..."

16
Hila

"Tôi có thể nhận được mà không cần kiểm tra cho điều đó. Thật khó để kiểm tra."

và đó là anh trai độc ác,

"Tôi phải có một bài kiểm tra cho điều đó, bất kể bài kiểm tra đó khó viết hay hiểu như thế nào."

16
Wayne Conrad

Chần chừước tính nhiệm vụ lạc quan là những tội lỗi lớn nhất của tôi.

Kéo dài, chống đẩy hoặc kéo tạ (hoặc bất kỳ bài tập thể chất nào khác) cho lần đầu tiên và tâm trạng bi quan trước khi đưa ra ước tính cho lần thứ hai.

15
Nikita Barsukov

"Nó dễ dàng hơn nhiều ( 'thành thực hiện lại chức năng từ đầ hơn là hiểu mã hiện có."

13
k3b

Một cám dỗ gây hại ồ ạt mà dự án tôi đang phải chịu là 'Hiệu ứng nền tảng bên trong'. Đây là một cách tiếp cận mà Kiến trúc sư, người đã mất từ ​​lâu, đã đặt ra trí tuệ vô hạn của họ, người đã tạo ra một dự án tạo ra khoảng 20 triệu đô la mỗi năm nhưng chi phí 60 triệu để cập nhật và duy trì (rõ ràng là rất lớn nhưng đây là mức độ lớn của vấn đề).

10
AlexC

NIH - Không được phát minh ở đây

Tôi có một thời gian thực sự khó khăn để cho các giải pháp của bên thứ ba một cơ hội công bằng. Mọi người nên nghi ngờ một cách tự nhiên về các giải pháp của bên thứ ba không phù hợp với họ, nhưng tôi gặp khó khăn khi phải khách quan 100% về nó.

Tiết kiệm thời gian có thể rất lớn đến nỗi ngay cả khi tránh được 9 lần trong số 10 giải pháp của bên thứ ba, tôi cần phải đủ khách quan để nhận ra một sẽ hoạt động.

10
Nicole

Phải có một thư viện thực hiện điều đó ở đâu đó hội chứng.

liên quan chặt chẽ đến

The Flim Plugin

9
Newtopian

Thiết kế, mã hóa và hoặc kiểm tra đơn vị đối với "dữ liệu mẫu" được cung cấp thay vì phân tích một bản sao của cơ sở dữ liệu thực tế của khách hàng. Thời hạn là ngắn và họ cứ nói rằng nó sẽ đến nhưng nó không bao giờ làm được. Khi nó được triển khai, vụ nổ là ngoạn mục. Thực sự, ai có thể mong đợi một khách hàng có 3 khách hàng mẹ.

Tôi sẽ không bao giờ bắt đầu một dự án nữa cho đến khi tôi có một bản sao của dữ liệu real.

9
dwidel

Cầu toàn giết chết; có lẽ các dự án lý do lớn nhất không thành công.

8
Naftuli Kay

Viết lại thay vì tái cấu trúc.

7
Dave O.

Vâng, đôi khi lập trình đưa tôi đến chai.

7
mipadi

Suy nghĩ phải có một cách tốt hơn để làm điều này. Tôi sẽ không giải quyết cho một cái gì đó có thể là "đủ tốt." Tôi không lấy gì làm hoàn hảo! Thông thường điều này được tránh bằng cách nói chuyện với những người khác có thể có quan điểm khác về một vấn đề hoặc nhìn thấy giải pháp từ một góc độ khác.

6
JB King

Tự động hóa mọi thứ đến mức dành nhiều thời gian hơn cho việc duy trì các công cụ hơn là công việc thực tế.

Giải pháp: giống như với tối ưu hóa mã, trước tiên hãy tìm các tắc nghẽn năng suất và chỉ sau khi chúng được phát hiện, hãy chữa chúng bằng một số tự động hóa tốt.

5
Dan

Quỷ lập trình của bạn là gì?

Ngoài những gì một số người khác đã đề cập.

Ưu tiên: Bỏ qua công việc ưu tiên cao đối với dự án và làm việc với những thứ khác trong dự án trước vì, chúng thú vị hơn!

Làm thế nào để bạn tránh chúng?

Với một chút kỷ luật tự hơn. Nghiêm túc, kỷ luật tự giác và động lực bản thân để làm điều đúng giúp tránh hầu hết các "con quỷ".

4
Mahesh Velaga

Bộ não của tôi bị hao mòn từ dự án này. Tôi sẽ nghỉ ngơi nhanh trong dự án phụ ngắn này để trẻ hóa nó.

3
emragins

"There must be a better solution to this."

Và bạn kết thúc suy nghĩ và suy nghĩ, và để cho tâm trí của bạn trôi dạt đến một vùng đất xa xôi cho đến khi bạn nhận ra bạn đã đi quá lâu. Nó sẽ ổn, nhưng không phải khi bạn có thời hạn.

3
gladysbixly

Chúng tôi chưa nhận được sự chấp thuận từ khách hàng nhưng thời hạn đang đến gần, vì vậy đây là một số comps sơ bộ để bạn có thể bắt đầu ...

Sau đó, sau khi bạn hoàn thành việc xây dựng dự án để phù hợp với ...

Ồ, đây là bản sửa đổi của khách hàng, họ chỉ muốn thay đổi một vài điều nhỏ *

(* chức năng chính hoàn toàn khác nhau)

Sau đó, bạn tiếp tục tái cấu trúc mã gốc của mình, dựa trên mô hình thiếu sót ban đầu thay vì chỉ bắt đầu từ đầu vì bạn đang chịu áp lực của thời hạn ngắn và cho rằng đó là những sửa đổi cuối cùng.

Tôi nhận được một chút bởi điều này tất cả các thời gian. Thật khó để tránh là một nhà phát triển web. Lời khuyên tốt nhất của tôi là Đẩy thêm thời gian để bạn có thể thực hiện các thay đổi một cách chính xác.

3
travis

Viết mã mới sau ngày đóng băng mã.

Ngày đóng băng mã phải được đặt trong đá. Bất kỳ mã mới nào được viết sau khi nó phải được chuyển sang bản phát hành trong tương lai, vì nó có thể yêu cầu tất cả các loại thử nghiệm hồi quy.

3
Mag20

Để trả lời câu hỏi về việc tránh chúng: Làm quen với Chống mẫ để bạn có thể gọi chúng khi bạn nhận ra chúng.

3
Lee Kowalkowski

Sự thông minh. Tất nhiên, không phải lúc nào cũng vậy. Một số thông minh và đồng nhất sẽ làm cho mã của bạn trông rất đẹp và dễ bảo trì. Nhưng chỉ vì bạn có thể làm

x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;

thay vì một vài dòng if, không có nghĩa là bạn nên.

Btw, vâng tôi biết có một chút dư thừa trong ví dụ của tôi ... Nếu bạn thậm chí tự bắt nó :)

3
Earlz

Tất cả những thứ khác cộng với tính năng leo trèo: "Sẽ thật tuyệt nếu nó làm điều này và tôi biết khách hàng sẽ thích nó và sẽ đưa nó vào thông số kỹ thuật nếu họ nghĩ về nó". Tôi cố gắng tránh điều này bằng cách hỏi nơi nào trong thông số kỹ thuật thực sự yêu cầu tồn tại cho tính năng tuyệt vời này.

Sau đó, một lần nữa, tôi không thường nhận được thông số kỹ thuật bằng văn bản.

2
PSU

"đó chỉ là phi công, vì vậy không cần thiết phải bảo trì hay mở rộng dễ dàng".

Theo kinh nghiệm của tôi, người ta thường thấy phi công được đưa vào sản xuất và sản phẩm được coi là một phi công sẽ bị loại bỏ so với phi công bị loại bỏ và sản phẩm thực tế được phát triển đến trạng thái sẵn sàng sản xuất.

2
jwenting

Chi quá lâu để chỉnh sửa trình chỉnh sửa. Cố gắng tìm phông chữ và màu sắc tốt nhất để lập trình.

2
dheerosaur

"Tôi đã được chỉ định một tính năng có giao diện với [phần mềm/ví dụ: sharepoint]. Tôi có lẽ nên biết mọi thứ cần biết về phần mềm đó."

Sau đó, bạn dành hàng tuần để nghiên cứu sản phẩm đó, khi tính năng có thể đã được viết và thử nghiệm trong một hoặc hai ngày. Sự khao khát kiến ​​thức có một nền tảng tối. nguyên

2
Steven Evers

"Tôi sẽ bình luận/tài liệu này sau"

điều đó không bao giờ xảy ra, tác giả tiếp tục và sau đó bạn phát hiện ra rằng họ không bình luận mã của họ khi công việc đã được giao cho bạn.

2
sunwukung

Để bắt đầu tấn công một dự án mới, mà không hiểu về nó và tôi thường tránh điều này bằng cách nghiên cứu một chút về miền dự án trước khi tôi thực sự bắt đầu làm việc với nó, chỉ để có một điểm khởi đầu tốt và để chứng minh dự án phức tạp hơn Tôi ban đầu thông qua nó là.

Tôi cũng có một vấn đề là tôi thích di chuyển bằng các nút, chúng rất tuyệt !! Nhưng có lẽ đó là vì tôi đang làm hệ thống đa phương tiện và thiết kế giao diện người dùng ... Vì vậy, đối với tôi, giải pháp cho vấn đề này, là thực sự đưa nó vào chương trình giảng dạy của tôi và nghiên cứu một cái gì đó về nó, để tôi có một lý do hợp lệ nếu có ai nhìn thấy Tôi chơi với UI rất nhiều. (Và bao gồm đặt nền màu xanh lá cây, màu cam văn bản và các biểu tượng có nhiều màu vàng.)

1
Coyote21

Danh sách rất đầy đủ: chống mẫu .

1
vartec
/**
* Calculates the return value for humptyDumpty
*
* return int modifiedHumptyDumpty
*/
function awesomeWayToCalculateSomething(int humptyDumpty) {
.. 
}

TODO: Tôi cần tài liệu này đúng.

Sẽ _never_ xảy ra

1
András Szepesházi

Sử dụng một tính năng ngôn ngữ, một thành ngữ hoặc một mẫu thiết kế không phải vì đó là giải pháp tốt nhất cho vấn đề, mà hoàn toàn là vì lợi ích của việc sử dụng nó.

1
Dima

Tôi nghĩ rằng tôi có nó trong đầu rằng enums hữu ích hơn rất nhiều so với thực tế trong Java. Tôi có xu hướng cố gắng và làm quá nhiều với họ, và sau đó bị sa lầy vì họ không thực sự hỗ trợ đa hình.

1
MattLBeck

hơn cam kết bản thân để tránh phát triển nội bộ, 90% bánh xe không tốt hơn phát minh ra.

1
M. Utku ALTINKAYA

Sử dụng một khung trong khi không hoàn toàn hiểu nó. Nhưng sau đó một lần nữa. một khung chỉ được hiểu hoàn toàn bởi những người tạo ra nó (hầu hết các trường hợp). Tôi không có giải pháp thực sự cho mục đó nhưng cố gắng hiểu càng nhiều càng tốt từ một khung.

1
user18483

Sửa một lỗi khiến bạn phiền lòng vì nó "đơn giản", nhưng không bao giờ nói với QC và/hoặc khách hàng.

Những sửa chữa luôn luôn sụp đổ sản xuất.

1
Scott McIntyre

Có người nói khái quát hóa sớm, nhưng chuyên môn hóa sớm có thể tệ như vậy. Với việc khái quát hóa sớm, bạn có thể có được một phần mềm hoạt động cho 50% các trường hợp, nhưng chuyên môn hóa sớm có thể hoạt động cho 5% hoặc không. Cuối cùng, quản lý thà có 50% hơn 5%.

1
MPelletier

Làm vô số giờ làm thêm cho công ty trong thời gian rảnh của tôi chỉ để tìm ra "đó không phải là hướng họ đang tìm kiếm."

1
user13280

Quỷ lập trình của bạn là gì,

Tất cả mọi thứ đã được đề cập, đặc biệt là sự thôi thúc muốn tái cấu trúc như điên.

và làm thế nào để bạn tránh chúng?

Trước khi bắt đầu bất kỳ chỉnh sửa không cần thiết nào, hãy rời tay khỏi bàn phím trong 5 giây và nhanh chóng cân nhắc các kết quả có thể xảy ra khi thay đổi so với việc rời khỏi nó. Sau đó một lần nữa trước khi cam kết, cân nhắc hậu quả tương tự trong khoảng một phút.

1
Cheezmeister

Để tìm một chiếc ghế sofa thoải mái để làm việc hoặc làm việc nằm trên giường.

1
kiewic

Là "Hoàn hảo"

Mặc dù việc tránh làm cho đúng ngay lần đầu tiên là một vấn đề, nó không tệ như một sự tập trung bất tận vào sự hoàn hảo. Chỉ cần hoàn thành nó, sẽ không có thứ gì là hoàn hảo, và nếu có, nó hoàn toàn tạm thời, hoặc đã được thực hiện và không đáng để dành thời gian để làm lại.

0
blunders