Điều gì quá tệ về mã hóa sáng tạo? [đóng cửa]

Tôi đã xem Bob Ross vẽ một số "cây hạnh phúc" tối nay và tôi đã tìm ra điều gì đã làm tôi căng thẳng về mã của tôi gần đây.

Cộng đồng của những người ở đây và trên Stack Overflow dường như từ chối bất kỳ sự không hoàn hảo nào. Mục tiêu của tôi là viết mã đáng kính (và do đó có thể duy trì và hoạt động), bằng cách cải thiện các kỹ năng của tôi. Tuy nhiên, tôi viết mã một cách sáng tạo.

Hãy để tôi giải thích những gì tôi có nghĩa là "mã hóa sáng tạo":

• Những bước đầu tiên của tôi trong một dự án thường là ngồi xuống và bash một số mã. Đối với những điều lớn hơn, tôi có kế hoạch một chút ở đây và ở đó, nhưng chủ yếu tôi chỉ lặn vào.
• Tôi không lập sơ đồ bất kỳ lớp nào của mình, trừ khi tôi làm việc với những người khác đang tạo ra các phần khác trong dự án. Ngay cả sau đó, nó chắc chắn không phải là điều đầu tiên tôi làm. Tôi thường không làm việc trên các dự án lớn và tôi không thấy hình ảnh rất hữu ích.
• Vòng mã đầu tiên tôi viết sẽ được viết lại nhiều lần, nhiều lần khi tôi kiểm tra, đơn giản hóa, làm lại và biến bản hack gốc thành thứ gì đó có thể sử dụng lại, hợp lý và hiệu quả.

Trong quá trình này, tôi luôn luôn làm sạch. Tôi xóa mã không sử dụng và nhận xét bất cứ điều gì không rõ ràng. Tôi kiểm tra liên tục.

Quá trình của tôi dường như đi ngược lại với những gì được chấp nhận trong cộng đồng nhà phát triển chuyên nghiệp và tôi muốn hiểu lý do tại sao.

Tôi biết rằng hầu hết sự kìm kẹp về mã xấu là ai đó đã bị mắc kẹt với mớ hỗn độn của nhân viên cũ, và nó tốn rất nhiều thời gian và tiền bạc để sửa chữa. Điều đó tôi hiểu. Điều tôi không hiểu là quá trình của tôi sai như thế nào, cho rằng kết quả cuối cùng giống với những gì bạn sẽ nhận được khi lập kế hoạch cho mọi thứ ngay từ đầu. (Hoặc ít nhất, đó là những gì tôi đã tìm thấy.)

Sự lo lắng của tôi về vấn đề gần đây rất tệ đến nỗi tôi đã ngừng viết mã cho đến khi tôi biết mọi thứ về mọi phương pháp để giải quyết vấn đề cụ thể mà tôi đang làm việc. Nói cách khác, tôi hầu như đã ngừng mã hóa hoàn toàn.

Tôi chân thành đánh giá cao đầu vào của bạn, bất kể ý kiến ​​của bạn về vấn đề này là gì.

Chỉnh sửa: Cảm ơn tất cả các câu trả lời của bạn. Tôi đã học được điều gì đó từ mỗi người trong số họ. Bạn có tất cả là hữu ích nhất.

Không có gì sai với mã kiểm tra-tái cấu trúc-lặp lại, chỉ cần nói với mọi người rằng bạn đang tạo mẫu.

Mặt khác, đối với các dự án lớn hơn, bạn sẽ thấy rằng một số suy nghĩ được đưa ra trước thiết kế sẽ giúp bạn tiết kiệm rất nhiều thời gian trong vòng lặp oh-crap-now-what!

PS: Các kỹ thuật lập sơ đồ giúp bạn học các kỹ năng tư duy trực quan, rất có giá trị ngay cả khi không có ai ngoài bạn nhìn thấy sơ đồ của bạn.

Tôi luôn thích mã rõ ràng, dễ đọc, đơn giản hơn bất kỳ mã được trình bày trực quan, UMLed, theo mẫu thiết kế nào, trong đó lớp / giao diện bao gồm các tên mẫu như "ItemVisitor" (?!). Các mẫu thiết kế, kỹ thuật OO và mọi thứ khác là để chính thức hóa các quy tắc. Những quy tắc đó xuất phát từ lẽ thường.

Không thể làm việc mà không có sự chính thức hóa đó (trừ khi bạn làm việc một mình trong dự án của riêng bạn) và việc chính thức hóa quá mức làm tăng chi phí dự án. Không bao giờ coi thường nhu cầu của người khác để hiểu mã của bạn. Mã tốt nhất là mã đơn giản nhất.

Không bao giờ ngần ngại để viết lại mã của bạn. Tôi sẽ nhận được X downvotes (X> = 10) cho điều này, nhưng tôi sẽ làm cho nó đậm: khả năng sử dụng lại mã không phải là điều quan trọng nhất .

Trước khi nhìn chằm chằm mã hóa, bạn nên xem xét các trường hợp sử dụng mà mã sẽ triển khai. Bởi vì phần mềm sẽ được sử dụng và không được phát triển. Tính khả dụng, hữu ích là hai mục tiêu quan trọng nhất và không quan trọng ai sẽ sử dụng phần mềm đó - một nhà phát triển khác của các bộ phận phụ thuộc của dự án hoặc người dùng cuối.

Tôi cũng giống như vậy. Lắng nghe khi người khác nói với bạn về những điều làm việc cho họ, nhưng bỏ qua bất cứ ai nói với bạn những gì bạn "nên" làm như thể có một số mệnh lệnh đạo đức đối với nó. Nếu bạn tìm thấy một cái gì đó phù hợp với bạn, hãy đi với nó. Ý tôi là, kết quả cuối cùng có quan trọng không? Ai thực sự quan tâm đến con đường bạn đã đi đến đó?

Hãy nhớ rằng: mọi người là khác nhau . Đó là một điều tốt. Đừng lắng nghe những người cố gắng khiến bạn thích họ, và chống lại sự thôi thúc muốn làm cho những người khác thích bạn và bạn sẽ làm tốt.

Có vẻ như bạn là:

1. Cố gắng tìm ra cách tiếp cận tốt nhất (thử nghiệm, thiết kế gia tăng)
2. Viết lại mã để làm cho nó sạch hơn (tái cấu trúc)
3. Liên tục viết bài kiểm tra (phát triển theo hướng kiểm tra)

Những gì bạn đang làm là tuyệt vời! Có vẻ như bạn đang làm điều đó hoàn toàn đúng, đặc biệt là nếu bạn tự mình tìm ra nó và không học nó từ một cuốn sách lập trình (nhanh nhẹn). Rõ ràng có nhiều hơn thế nhưng bạn đã có các giá trị đóng đinh. Chỉ cần nhớ cấu trúc lại và cải thiện thiết kế trong khi bạn đang thêm mã và không cần phải có BDUF .

Bạn đã từng xem xét việc tập trung vào một tính năng nhỏ tại một thời điểm và phát hành sau khi mỗi tính năng được hoàn thành chưa? Điều đó có thể giúp bạn không bị ảnh hưởng từ bất kỳ vấn đề phân tích nào mà bạn đang đấu tranh và chứng minh sự tiến bộ thực sự cho nhà tuyển dụng của bạn.

Ngoài ra, tôi không biết bạn đang nói về "cộng đồng phát triển chuyên nghiệp" nào, nhưng nếu là bạn, tôi sẽ bảo họ quay lại tháp ngà của họ để bạn có thể tiếp tục với công việc của mình!

Brad, anh không cô đơn. Tôi biết các lập trình viên rất giỏi, những người làm việc theo cách chính xác như bạn mô tả. :)

Nếu bạn dọn sạch mã của mình và biết cách làm cho nó hiệu quả và dễ đọc, thì bạn chắc chắn đã phát triển ý thức về cách viết mã sạch và hiệu quả trước.

Hơn nữa, không có gì hoàn toàn có thể được lên kế hoạch trước, và con đường ngắn nhất để khám phá sự tinh tế thường là chạy mã và hiểu các chi tiết bị bỏ qua.

Tôi nghĩ rằng bạn đang làm rất tốt, và phong cách lập trình mà bạn mô tả là hoàn toàn hợp lệ.

Tôi nghĩ rằng nó đáng để hoàn thành các câu trả lời ở trên với một trích dẫn của Alan J. Perlis, từ lời tựa của cuốn sách nổi tiếng MIT "Cấu trúc và giải thích các chương trình máy tính", thường được gọi là "SICP":

Mỗi chương trình máy tính là một mô hình, nở ra trong tâm trí, của một quá trình thực tế hoặc tinh thần. Các quá trình này, phát sinh từ kinh nghiệm và suy nghĩ của con người, có số lượng rất lớn, chi tiết phức tạp và bất cứ lúc nào chỉ được hiểu một phần. Chúng được mô hình hóa theo sự hài lòng vĩnh viễn của chúng tôi hiếm khi bởi các chương trình máy tính của chúng tôi. Do đó, mặc dù các chương trình của chúng tôi được làm thủ công một cách cẩn thận các bộ sưu tập các biểu tượng, khảm các chức năng lồng vào nhau, chúng vẫn tiếp tục phát triển: chúng tôi thay đổi chúng khi nhận thức của chúng tôi về mô hình sâu hơn, mở rộng, khái quát cho đến khi mô hình cuối cùng đạt được một vị trí siêu bền trong một mô hình khác. chúng ta đấu tranh. "

Có thông minh tốt và thông minh xấu.

Thông minh tốt - tỷ lệ cao giữa các dòng mã thông minh so với các dòng trong một thay thế không thông minh. 20 dòng mã giúp bạn tiết kiệm từ việc viết 20000 là Thông minh cực kỳ tốt. Thông minh tốt là về tiết kiệm công việc của bạn.

Thông minh xấu - tỷ lệ thấp giữa các dòng mã được viết so với các dòng mã được lưu. Một dòng mã thông minh giúp bạn tiết kiệm được năm dòng mã là Bad Clever. Thông minh xấu là về "thủ dâm cú pháp".

Chỉ cần lưu ý: Thông minh xấu gần như không bao giờ được gọi là "Thông minh xấu"; nó sẽ thường đi du lịch dưới các bí danh "đẹp", "thanh lịch", "súc tích" hoặc "cô đọng".

Tôi chắc chắn có thể nhận ra bản thân mình theo cách bạn mô tả quy trình làm việc của bạn. Đây là điều: khi tôi bắt đầu làm việc trong môi trường nhóm, hầu như tất cả những thứ HAD phải thay đổi.

Công việc tôi đã làm được khoảng 8 tháng nay thực sự là kinh nghiệm đầu tiên của tôi khi làm việc trong một nhóm các nhà phát triển trong một dự án duy nhất. Cho đến tận bây giờ, theo nghĩa đen, toàn bộ sự nghiệp của tôi là một lập trình viên sói đơn độc, người không phải đối phó với tất cả những gì đi kèm với tinh thần đồng đội. Ngay cả khi tôi làm việc trong một nhóm, nó vẫn luôn hoạt động khá im lặng - tôi đã có dự án của mình là MINE, hoặc phần của tôi là MINE, v.v. Đó là một đường cong học tập thú vị khi tôi tăng tốc với môi trường làm việc nhóm thực sự hợp tác.

Đây là điều chính tôi đã nhận ra: nếu nó không rõ ràng về những gì bạn đang làm, thì có lẽ bạn đang viết một cơn đau đầu tiếp theo của đồng nghiệp. Hầu hết sự băn khoăn "theo quy trình" mà bạn thấy ở đây có liên quan đến thực tế là nhiều người trong chúng ta đã trở thành đồng nghiệp bị đau đầu. Và hầu hết lý thuyết quản lý quy trình phần mềm phải làm với việc giảm thiểu sự đau đầu đó.

Vì vậy, những việc như lên kế hoạch cho một kế hoạch đã được thống nhất trước thời hạn, v.v ... Đó là về việc có một nhóm trên tàu và đồng bộ. Nếu bạn là nhóm, bạn đã đồng bộ với chính mình và điều đó không thực sự cần thiết.

Không có gì sai với cách tiếp cận của bạn như một hình thức nghệ thuật sáng tạo. Nếu bạn đang phát triển vì lợi ích cá nhân, và những gì bạn đang làm cho bạn, và bạn thấy thú vị có lẽ cũng quan trọng như kết quả cuối cùng như chính sản phẩm.

Trong môi trường làm việc chuyên nghiệp, nếu thang thời gian dự án của bạn ngắn, có thể khoảng 2 - 3 tuần hoặc ít hơn, thì cách tiếp cận của bạn được gọi là tạo mẫu nhanh và khá phù hợp với các nhiệm vụ trước mắt.

Tuy nhiên, đối với các dự án dài hơn, ngay cả những dự án khi bạn đang tự làm việc, cách tiếp cận như vậy có lẽ là một sự xa xỉ đắt tiền cho chủ nhân của bạn. Dành vài ngày ngân sách dự án cho thiết kế kiến ​​trúc trả trước và sau đó thử nghiệm kiến ​​trúc dựa trên điều gì nếu quản lý quyết định thay đổi thông số kỹ thuật bằng cách ... thường là dành thời gian tốt và sẽ phát triển kỹ năng của bạn để trở thành một lập trình viên / kiến ​​trúc sư có giá trị hơn nữa trong sự nghiệp của bạn.

Hai quan điểm:

1. Không ai phải duy trì một bức tranh.

2. Bất cứ ai đã từng xem Bob Ross vẽ một bức tranh đều biết rằng tranh có cấu trúc. Nếu bạn định học một bài học từ Bob Ross, thì việc lên kế hoạch trước và làm việc một cách có tổ chức sẽ khiến quá trình diễn ra suôn sẻ và đơn giản.

Tôi viết mã khá nhiều theo cùng một cách. Tôi sẽ chỉ bắt đầu viết và khi tôi thấy các mẫu đang nổi lên, tôi tái cấu trúc. Bạn có thể vẽ mình vào một góc theo cách đó, bạn phải biết khi nào nên ngồi lại và suy nghĩ một vấn đề, nhưng đôi khi bạn chỉ cần đâm vào nó để thực sự hiểu vấn đề.

Nhưng tôi tò mò về điều này:

Cộng đồng của những người ở đây và trên Stack Overflow dường như từ chối bất kỳ sự không hoàn hảo nào. [..] Quá trình của tôi dường như đi ngược lại với những gì được chấp nhận trong cộng đồng nhà phát triển chuyên nghiệp và tôi muốn hiểu lý do tại sao.

Làm thế nào có ai ở Stack Overflow biết quy trình của bạn? Và bạn có ý nghĩa gì khi "từ chối"? Đương nhiên, mã được đăng lên một cộng đồng lập trình sẽ được kiểm tra nghiêm ngặt. Nhưng nếu ai đó phát hiện ra các khu vực nơi mã của bạn có thể được cải thiện, đó chỉ có thể là một điều tốt, phải không?

Hy vọng rằng, khi đăng câu hỏi lên Stackframe, bạn dọn sạch mã của mình và cố gắng giảm nó xuống dạng đơn giản nhất có thể, không tôn trọng độc giả của bạn (đôi khi bạn giải quyết vấn đề của riêng mình chỉ cố gắng trình bày cho người khác), trong đó trường hợp bất kỳ thông tin phản hồi là tốt. Nếu bạn đăng mã mà bạn biết là xấu và bạn biết tại sao nó xấu trước khi đăng, bạn không nên tự nhận mã nếu mọi người nhận thấy rằng nó xấu.

Tôi cũng sử dụng phương pháp của bạn. Nó hoạt động tốt hơn đối với tôi, vì nó làm giảm nguy cơ áp đảo.

Những gì tôi làm rất thường xuyên là giải quyết một vấn đề với ít mã nhất có thể, điều này thường dẫn đến sự phụ thuộc rõ ràng không cần thiết hoặc các vấn đề thiết kế khác. Sau đó, tôi tái cấu trúc mã làm việc thành mã đẹp.
Ví dụ, tôi giảm sự phụ thuộc giữa các mô-đun khác nhau để giao diện ngắn gọn và suy nghĩ về câu hỏi nên giữ dữ liệu ở đâu, cho đến khi mọi mô-đun chỉ phụ thuộc vào sự trừu tượng rất tối giản của các mô-đun khác. Bạn có thể nói, tôi hoãn quyết định cuối cùng, mô-đun nào sẽ có trách nhiệm. Tôi trì hoãn sự trừu tượng.
Đặt quá nhiều suy nghĩ vào việc tách biệt một vấn đề thành các trách nhiệm riêng biệt, thành các khái niệm trừu tượng, là không tốt. Nó sẽ buộc bạn phải uốn cong việc thực hiện của mình để phù hợp với sự trừu tượng mà bạn đã thực hiện. Mã hoạt động, nếu nó tạo ra kết quả bạn muốn và nếu nó có thể duy trì được. Một thiết kế hoạt động, nếu bạn có thể thực hiện nó thông qua mã tốt. Nếu mã không hoạt động, bạn thay đổi nó. Ergo, nếu một thiết kế không hoạt động, bạn cũng sẽ cần phải thay đổi nó. Bạn chỉ có thể xem nếu một thiết kế hoạt động, một khi bạn thực hiện nó.

Do đó, có một bản phác thảo đơn giản trong đầu chỉ là một thiết kế, trước khi bạn bắt đầu đưa nó vào cuộc sống. Thiết kế lại, trừu tượng và tái cấu trúc khi cần thiết .

Tôi nghĩ rằng nếu bạn sẽ giỏi lập trình, ít nhất đôi khi nó phải vui, và điều đó có nghĩa là sáng tạo.

Chắc chắn khi lập trình trong các nhóm có ít nhất các tiêu chuẩn tối thiểu cần phải tuân theo, không phải vì lý do "đạo đức", mà vì những lý do thực tế, khi chúng được áp dụng.

Ngoài ra, thật thú vị và thú vị khi thăm dò các ranh giới để xem những gì có thể tìm thấy ở đó. Một lần khi làm việc với Mini bằng ngôn ngữ lắp ráp, tôi phát hiện ra rằng bạn có thể thực hiện các thói quen có thể chuyển đổi từ cái này sang cái khác với 1 lệnh. Sau đó, tôi đã tìm ra cách tạo ra một thói quen tự có thể tiến lên hai bước, lùi một bước, v.v ... Nó có hữu ích không? Tôi nghi ngờ điều đó. Đó không phải là vấn đề.

Có lần tôi nghe một bài nói chuyện của Edsger Dijkstra, nói về sự sáng tạo trong lập trình. Ông đã đề cập đến cách một sinh viên tìm ra cách thực hiện xoay n-bit của một từ n + m-bit. Nó được thực hiện với 3 bitwaps. Đầu tiên bạn trao đổi các bit n, sau đó bạn trao đổi các bit m, sau đó bạn trao đổi toàn bộ bit n + m. Hữu ích? Không thông minh? Đúng.

Thật tốt khi cảm thấy thoải mái để thử những điều mà không ai có thể làm được.

Đây có thể là một trường hợp "một kích thước không phù hợp với tất cả". Bạn đã làm cho phong cách của bạn làm việc cho các dự án bạn đã thực hiện, vì vậy ai sẽ tranh luận với điều đó? Tuy nhiên, các nhà phê bình bạn đang đọc ở đây và trên SO có thể đang làm việc trên các dự án lớn hơn hoặc các dự án cần sự phối hợp phức tạp giữa các thành viên trong nhóm.

Phong cách phát triển của bạn có thể trở thành một vấn đề nếu bạn từng tham gia vào các dự án lớn hơn có sự hợp tác giữa nhiều nhà phát triển. Thật khó để lên lịch, thật khó để theo dõi tiến trình của bạn và không có cách nào để các lập trình viên của bạn lên kế hoạch cho công việc của họ mà phụ thuộc vào việc biết công việc của bạn đang làm gì.

Bạn có thể quan tâm đến việc đọc Dreaming in Code để xem điều gì có thể xảy ra khi một dự án lớn áp dụng phong cách phát triển tương tự như của bạn.

Rất nhiều sự trấn an rằng phương pháp của bạn không sai, nhưng hãy để tôi thêm một số kinh nghiệm cá nhân. Tôi đã bắt đầu theo cách của bạn, nhưng trong thời gian đó tôi đã học được lợi ích của việc lập kế hoạch trước ít nhất là một phần của cấu trúc chung, và điều này vì một số lý do:

• phần lớn nhất là dễ dàng hơn để xem mã nào có thể được sử dụng lại nếu làm việc xung quanh một chút. Tôi thường viết một đoạn mã, trong khi viết, đột nhiên có vẻ hữu ích cho một phần khác trong sơ đồ chung mà tôi đã treo bên cạnh màn hình của mình (được vẽ trên giấy theo kiểu chỉ đọc được cho tôi).

• Có một lược đồ cho phép bạn cấu trúc lại không chỉ mã mà cả lược đồ. Đôi khi tôi đang bận viết một lớp đột nhiên xuất hiện hữu ích cho một số phần khác trong sơ đồ. Kết quả là lược đồ trở nên đơn giản hơn khi dự án chạy

• Mỗi lần tôi cập nhật sơ đồ đó cũng như đầu vào cần thiết và đầu ra đã cho của các hàm / phương thức và các vị trí có sẵn trong các lớp. Điều này diễn ra nhanh hơn để tái sử dụng các bit: Tôi không phải đi sâu vào mã mỗi lần để kiểm tra chính xác những gì vào và ra. Ngay cả khi nó trong các bình luận, tôi vẫn phải duyệt để nhận được các bình luận

Vì vậy, thực sự, tôi sử dụng phương pháp của bạn là tốt. Tôi chỉ bắt đầu, thử, tái cấu trúc, thử lại, thay đổi một bit khác, nhưng chu kỳ của tôi bao gồm cả sơ đồ. Và khi xong, tôi thêm thông tin cho cái tiếp theo hoạt động trên mã đó.

Tâm trí bạn, đây là cho các dự án mà tôi làm việc một mình. Nếu bạn làm việc với nhiều người hơn trên cùng một mã, lập kế hoạch trước không chỉ là logic, đó là điều cần thiết. Nhưng tôi đoán bạn đã biết điều đó rồi.

Và như những người khác đã nói: đây là cách của tôi , số dặm của bạn có thể thay đổi.