Làm thế nào "đơn giản" là một giải pháp KISS thực sự? [đóng cửa]

Tôi thú nhận : Tôi có một vấn đề là "Giữ cho nó đơn giản và ngắn gọn" bởi vì cố gắng làm cho nó theo những cuốn sách tôi đã đọc, những mẫu thiết kế mà tôi đã nghe, v.v. cảm giác rằng tôi đang đi đúng hướng đến một sự hoàn hảo có thể xảy ra.

Mặt khác, vâng, điều đó gây thêm căng thẳng cho tôi về việc đưa ra thời hạn đôi khi ...

Nhưng bất cứ khi nào tôi nói với bản thân mình, "Lần sau hãy giữ nó đơn giản, bạn thật ngu ngốc!" Tôi thấy thật khó để làm cho nó "đơn giản" khi lần tới, bởi vì nó bắt đầu cảm thấy kỳ lạ ... và không thoải mái sau một thời điểm.

Sau đó, tôi bắt đầu đánh giá sự hiểu biết của mình về 'đơn giản' ...

SIMPLE có nghĩa là quá ngắn để nó hoạt động nhưng khó bảo trì và mở rộng?

SIMPLE có nghĩa là phá vỡ nhiều nguyên tắc OOP?

SIMPLE có nghĩa là gian lận?

Có phải SIMPLE có nghĩa là chỉ giữ đúng thời hạn mà không cần không? Vân vân.

Thật ra, nó là gì?

Câu hỏi là : Bạn có thể viết định nghĩa CHÍNH XÁC của SIMPLE theo nguyên tắc KISS không? -nếu đó là.

Cảm ơn!

Hãy học một KISS tiếng Pháp:

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. - Antoine de Saint-Exupéry

Được dịch thành:

Sự hoàn hảo đạt được, không phải khi không còn gì để thêm, mà là khi không còn gì để lấy đi. - Antoine de Saint-Exupéry

Kịch bản

Bạn cần phải cắt và véo.

Giải pháp A: Không phải KISS

Giải pháp B: KISS

Đối với một định nghĩa chính xác : Thật khó để xác định một thang đo tuyệt đối để đo lường sự đơn giản. Chủ yếu là vì sự đơn giản thực sự ngăn cản sự hiểu biết thực sự về vấn đề và điều đó hiếm khi đạt được. Nhưng hãy nói rằng giải pháp A và B minh họa sự khác biệt giữa các giải pháp có xu hướng hướng tới sự phức tạp hóa và đơn giản tương ứng.

"Làm mọi thứ đơn giản nhất có thể, nhưng không đơn giản hơn" -Einstein

Giữ mã càng đơn giản càng tốt, nhưng không đơn giản hơn phụ thuộc vào vấn đề đang được giải quyết. Miễn là vấn đề được giải quyết có xu hướng thay đổi, KISS cũng vậy.

Có một sự cân bằng giữa kỹ thuật quá mức (ồ người đàn ông này trông giống như một nơi tuyệt vời để thể hiện các kỹ năng Mẫu thiết kế của tôi!) Và dưới kỹ thuật (nếu tôi sử dụng một nhà máy, tôi sẽ không có khớp nối này khiến tôi phải tạo ra 20 thay đổi mã ...). Mục tiêu là khả năng duy trì.

Đơn giản không có nghĩa là phá vỡ các nguyên tắc lập trình tốt. Trong thực tế, nó có nghĩa là nhiều ngược lại.

SIMPLE có nghĩa là quá ngắn để nó hoạt động nhưng khó bảo trì và mở rộng?

Không khó để duy trì và mở rộng là một triệu chứng lớn của sự phức tạp. Trong thực tế, tôi thấy rằng việc tạo mã có thể mở rộng dẫn đến mã đơn giản hơn, vì bạn không giải quyết mọi trường hợp đơn lẻ để bắt đầu, bạn có thể giữ mã cơ sở đơn giản hơn.

SIMPLE có nghĩa là phá vỡ nhiều nguyên tắc OOP?

Không. Hầu hết các nguyên tắc OOP được thiết kế để giữ cho mã sạch hơn và có tổ chức hơn, cuối cùng, đơn giản hơn.

SIMPLE có nghĩa là gian lận?

Không viết khó để duy trì mã & hack dưới chiêu bài giữ thời hạn là.

Có phải SIMPLE có nghĩa là chỉ giữ đúng thời hạn mà không cần không? Vân vân.

Không có thời hạn và sự đơn giản của mã của bạn là hai vấn đề riêng biệt. Viết mã đơn giản không mất nhiều thời gian để viết (mặc dù đó là một quan niệm sai lầm phổ biến).

Điều này rất khó giải thích vì đơn giản không có nghĩa là điều tương tự với mọi người.

Thí dụ. Một số nhà phát triển nghĩ rằng đó ?:là đơn giản nhưng những người khác nghĩ rằng một iftuyên bố là tốt hơn. Khi nó xuống đến mức này, bạn không thể làm hài lòng tất cả mọi người.

Nói chung, phương tiện đơn giản mà không phức tạp . Để hiểu được sự đơn giản, chúng ta cần hiểu sự phức tạp.

Có hai loại phức tạp:

Sự phức tạp thiết yếu đề cập đến một tình huống trong đó tất cả các giải pháp hợp lý cho một vấn đề phải phức tạp (và có thể gây nhầm lẫn) vì các giải pháp "đơn giản" sẽ không giải quyết thỏa đáng vấn đề. - Wikipedia

Sự phức tạp ngẫu nhiên là sự phức tạp nảy sinh trong các chương trình máy tính hoặc quá trình phát triển của chúng (lập trình máy tính) không cần thiết cho vấn đề cần giải quyết. - Wikipedia

Bạn có thể kiểm tra độ phức tạp cần thiết với các câu hỏi sau:

Giải pháp này có đơn giản không? Tôi có thể giải thích nó cho bạn bè của mình trong một vài phút và họ có được không? Có một giải pháp đơn giản hơn cho vấn đề? Nếu có, có sự đánh đổi nào giữa giải pháp phức tạp so với giải pháp đơn giản không? Chúng ta có thể sống với những sự đánh đổi đó không? Ví dụ, nhiều lập trình viên mắc lỗi tối ưu hóa vi mô mọi thứ và giải pháp của họ (cũng như mã) trở nên quá phức tạp.

Kiểm tra độ phức tạp tình cờ của bạn:

Mã có đơn giản không? Nếu tôi trở lại với nó trong ba tháng, tôi sẽ mất bao lâu để xây dựng bối cảnh trong não để tôi có thể thực hiện thay đổi mà tôi cần thực hiện? Có phải mọi thứ trong mã nguồn của tôi đều có mục đích rõ ràng và nó truyền đạt mục đích đó một cách hiệu quả cho tôi và các nhà phát triển khác ? Làm thế nào là khó để kiểm tra mã của tôi? Thông thường mã của bạn càng phức tạp thì càng khó kiểm tra đơn vị, vì vậy tôi thường sử dụng mã này như một thước đo độ phức tạp. Bạn thường muốn các lớp và phương thức nhỏ, được đặt tên tốt và tập trung. Các mẫu thiết kế thường giúp bạn đạt được những điều này là tốt.

Nếu bạn thấy mình muốn sử dụng một mẫu thiết kế chỉ vì bạn chỉ đọc về nó, có lẽ nó sẽ giới thiệu sự phức tạp tình cờ. Nếu bạn thấy mình muốn đặt một cái gì đó vào vì bạn nghĩ rằng 'nó thông minh', nó có thể sẽ giới thiệu sự phức tạp tình cờ.

Tôi hy vọng điều này sẽ giúp và đừng quên: Đơn giản không có nghĩa là DỄ DÀNG .

Tôi luôn cảm thấy như các nguyên tắc đằng sau X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) đáng để lưu tâm. Tôi không luôn luôn thành công trong mục tiêu này.

Cụ thể, tôi cứ phải tự nhắc nhở mình ... "Không thêm chức năng mới trừ khi bạn biết một số ứng dụng thực sự sẽ yêu cầu nó." Và "Nếu bạn có thể nhận được 90 phần trăm hiệu ứng mong muốn cho 10 phần trăm công việc, sử dụng giải pháp đơn giản hơn. "

Câu hỏi là: Bạn có thể viết định nghĩa CHÍNH XÁC của SIMPLE theo nguyên tắc KISS không? -nếu đó là.

Không.

Đơn giản - trong bối cảnh cụ thể này là hoàn toàn ngược lại với phức tạp. Đơn giản không có nghĩa là cần thiết: Mọi người có đầu óc ngu ngốc đều phải hiểu nó - nhưng bạn phải chắc chắn rằng, bạn có thể hiểu nó, ngay cả khi bạn không tự viết nó.

Sự phức tạp có thể đạt được bằng cách tham khảo tyo khó hiểu - loại bỏ chúng! Nhiều tệp / lớp liên kết với nhau - không có cách nào! Và mã phức tạp (có nghĩa là: các chuỗi vòng, nhiều lớp ITE, v.v.) - không ai muốn đọc điều đó.

Theo tôi: Rất dễ dàng để thêm một chức năng khác, trong các lớp bạn cũng có thể thêm các chức năng riêng tư, vì vậy bạn không gây rối với giao diện. Vậy tại sao không sử dụng lợi thế này và giới hạn các chức năng / quy trình của bạn xuống 50 dòng. Thậm chí có thể ít hơn. Lấy một số tên có ý nghĩa. Bằng cách này, bạn làm cho hầu hết các ý kiến ​​lỗi thời. Bằng cách này, các chức năng của bạn dễ đọc, dễ sửa đổi / mở rộng.

Tất nhiên ... một vài câu cuối sẽ có tác dụng như: Trong các lớp có sẵn để xác định các hàm riêng tư, chỉ cần sử dụng khả năng này để phân chia các hàm thành 50 lớp để dễ đọc hơn nhiều (đừng quên tên hay, vì vậy bạn không cần phải bình luận nhiều như vậy).

NHƯNG: Việc đọc mọi thứ sẽ đơn giản hơn nhiều (!) Nếu có một đoạn dừng hoàn chỉnh cho thấy: Tôi đã hoàn thành một ý nghĩ, hãy tiếp tục với điều tiếp theo.

Đó là những gì tôi sẽ định nghĩa là đơn giản.