Có nên sử dụng mã giả trước khi mã hóa thực tế?

Mã giả giúp chúng ta hiểu các nhiệm vụ theo cách bất khả tri về ngôn ngữ. Đó có phải là cách thực hành tốt nhất hoặc cách tiếp cận được đề xuất để tạo mã giả như là một phần của vòng đời phát triển? Ví dụ:

• Xác định và phân chia các nhiệm vụ mã hóa
• Viết mã giả
• Được phê duyệt [bởi PL hoặc TL]
• Bắt đầu mã hóa dựa trên mã giả

Đây có phải là một cách tiếp cận được đề xuất? Có phải nó được thực hành trong ngành công nghiệp?

Viết mã giả trước khi mã hóa chắc chắn tốt hơn là chỉ viết mã mà không lập kế hoạch, nhưng nó không phải là một cách thực hành tốt nhất. Phát triển dựa trên thử nghiệm là một cải tiến.

Thậm chí tốt hơn là phân tích miền vấn đề và giải pháp thiết kế bằng các kỹ thuật như câu chuyện của người dùng, trường hợp sử dụng, thẻ CRC, sơ đồ hóa, được tán thành bởi các phương pháp như Cleanroom, RUP, Lean, Kanban, Agile, v.v.

Hiểu thấu đáo bản chất của vấn đề và các thành phần bạn sử dụng để thực hiện giải pháp là nguyên tắc đằng sau các thực tiễn tốt nhất.

Tôi sử dụng các bình luận như một loại mã giả rất cao cấp, trong đó tôi viết các bình luận trước khi tôi viết mã. Tôi thấy rằng suy nghĩ thông qua toàn bộ vấn đề, thậm chí ở mức cao, cải thiện đáng kể mã của tôi.

Không, không giả mã trước

Đây là quá nhiều chi phí. Bạn đang làm công việc viết logic mà không có lợi ích nào. Tôi muốn đề xuất bất kỳ điều nào sau đây:

1. Nguyên mẫu trong ngôn ngữ bạn sẽ gửi cùng (AKA Viết một để ném đi )
2. Sơ đồ kiến ​​trúc w / đoạn mã để kiểm tra các giả định / thiết kế khóa
3. Kiểm tra hướng phát triển trong đó bạn viết giao diện / cấu trúc mã của mình trước, tiếp theo là kiểm tra, sau đó là triển khai mã.

Tất cả ba trong số này di chuyển bạn trực tiếp đến giải pháp của bạn, không giống như mã giả. Cá nhân tôi có xu hướng sử dụng các kỹ thuật 1 hoặc 2 tùy thuộc vào quy mô đội. Đối với các nhóm nhỏ hơn (ví dụ 5 người trở xuống), tạo mẫu hoạt động rất tốt. Đối với các nhóm lớn hơn có nhiều nhóm nhà phát triển hoạt động song song, tôi thấy rằng tài liệu được sản xuất sớm bởi kỹ thuật 2 hoạt động tốt vì nó mang lại cho bạn điều gì đó để thảo luận sớm và giúp bạn xác định ranh giới thành phần tốt hơn. Tôi chắc chắn TDD cũng sẽ hoạt động rất tốt, nhưng tôi vẫn chưa làm việc trong một nhóm đã cam kết với quy trình này.

Theo tôi, mã giả chỉ có hai mục đích hợp lệ:

(1) Dành cho sinh viên lập trình, những người cần học các khái niệm về mô đun và thuật toán, nhưng chưa thành thạo ngôn ngữ lập trình.

(2) Để truyền đạt cách thức một cái gì đó sẽ làm việc với một người không có kỹ thuật, hoặc chỉ vì lợi ích của một cuộc họp loại bảng trắng.

Mã giả là một cách tiếp cận được đề xuất? Đối với những lập trình viên mới bắt đầu, tôi nói có. Nó giúp lập trình viên mới học cách dịch một vấn đề thành mã mà không cần lo lắng về cú pháp chính xác của ngôn ngữ. Điều này định hình quá trình suy nghĩ và có thể giúp ăn sâu những thói quen hữu ích (và tôi cho rằng cũng có những thói quen xấu). Đây là lý do tại sao nó được sử dụng trong các trường học rất nhiều.

Nó được thực hành trong công nghiệp? Theo kinh nghiệm của tôi, không. Không ai có thời gian để phác thảo dự án giữa các tài liệu (yêu cầu, thông số kỹ thuật, bảng câu chuyện, trường hợp sử dụng hoặc bất cứ điều gì khác mà họ sử dụng) và mã thực tế. Người ta thường cho rằng suy nghĩ đầy đủ đã được đưa vào vấn đề trước khi bật đèn xanh để viết mã. Tại thời điểm đó, mã hóa dự án quan trọng hơn việc thêm một lớp chuẩn bị thiết kế.

Tôi chắc chắn sẽ đề nghị mã giả. Nó giúp bạn làm rõ những gì bạn sẽ làm và xác định các mục bạn có thể đã quên hoặc các vấn đề tiềm ẩn. Việc sửa mã của bạn dễ dàng hơn / nhanh hơn khi nó vẫn đang trong giai đoạn lập kế hoạch thay vì chờ đợi cho đến khi bạn đã mã hóa một phần lớn mã.

Mã giả có thể hữu ích nếu bạn không quen với ngôn ngữ hoặc nếu bạn cần thay đổi bối cảnh tinh thần. Trong dịp hiếm hoi tôi viết mã giả, nó nằm trên giấy. Đôi khi chỉ cần rời tay khỏi bàn phím và viết nguệch ngoạc trên giấy có thể giúp vượt qua một khối tâm thần.

Nhưng là một phần chính thức của quá trình phát triển? Không đời nào. Đây là một công cụ hữu ích cho các cá nhân. Có nhiều cách tốt hơn để "biết những gì bạn viết trước khi viết", như:

1. xác định hợp đồng (điều kiện trước / bài / bất biến) của phương thức trước khi bạn bắt đầu
2. TDD
3. 1 và 2 kết hợp (viết bài kiểm tra để thực hiện hợp đồng)

Tôi cũng đề nghị rằng việc nhận bất kỳ loại phê duyệt nào trước khi bạn bắt đầu viết mã có thể gây ra nhiều rắc rối hơn giá trị của nó. Đánh giá thiết kế (thực hiện trước) có thể hữu ích, nhưng chúng cần ở mức cao hơn các thuật toán riêng lẻ.

Tôi sẽ không đồng ý với các câu trả lời trước đó và nói không, nhưng với một lời cảnh báo: bạn chỉ có thể thoát khỏi psuedocode nếu bạn hết sức nhiệt tình để cấu trúc lại mã của mình để xử lý các vấn đề phát sinh. Psuedocode, về bản chất, là một cách xác định mã của bạn trước khi bạn xác định mã của mình; đó là một sự trừu tượng không cần thiết trong nhiều trường hợp và vì mã của bạn sẽ không bao giờ hoàn hảo ngay lần đầu tiên (và có thể, không tuân theo thiết kế của psuedocode để hoàn thành), nó dường như không liên quan đến tôi.

Nếu bạn đang viết COBOL hoặc C, mã giả có thể hữu ích vì việc viết mã thực tế sẽ mất nhiều thời gian hơn và nếu bạn có thể xác minh thuật toán / yêu cầu của mình từ mã giả, bạn có thể tiết kiệm thời gian.

Trong các ngôn ngữ hiện đại hơn, mã giả không có ý nghĩa nhiều như vậy. Những gì sẽ làm việc tốt hơn là viết sơ khai phương thức, và điền logic cấp cao nhất, và càng chi tiết cần thiết để xác minh thuật toán và yêu cầu, tất cả điều này trong mã thực tế. Sau đó, bạn có thể hiển thị mã đó cho Trưởng nhóm để phê duyệt và mã thực sự của bạn đã bắt đầu.

Lần duy nhất tôi sử dụng mã giả trong 10 năm qua là khi phỏng vấn khi chúng tôi làm việc trên bảng trắng và ngôn ngữ cụ thể không thành vấn đề.

Nó chắc chắn hữu ích để nói chuyện thông qua một quá trình / thuật toán trong điều kiện lỏng lẻo mà không bị sa lầy với cú pháp. Ví dụ, viết một lớp C ++ có thuộc tính C #, chỉ để minh họa điểm.

Nó có vị trí của nó, nhưng chỉ nên được sử dụng khi cần thiết (nó hoạt động mà bạn sẽ vứt bỏ) và chắc chắn không phải là một phần của quy trình chính thức, trừ khi bạn có các tiêu chuẩn loại ISO khăng khăng.

Đối với bản thân tôi và những người tôi đã làm việc trong vài năm qua, mã giả đã biến thành mã thực sự không hoàn hảo. trừ khi bạn làm việc với nhiều ngôn ngữ cùng một lúc, hầu hết mọi người dường như bắt đầu suy nghĩ theo mô hình chung của ngôn ngữ chính của họ. Tôi đã làm việc trong các cửa hàng .net trong một thời gian vì vậy hầu hết những người viết bảng trắng vẽ nguệch ngoạc quanh văn phòng có xu hướng trông giống như vb hoặc c # với một số dấu câu bị thiếu.

Bài tập vẫn có giá trị khi tranh luận về các lựa chọn và như vậy, nhưng bit bất khả tri ngôn ngữ có xu hướng trôi đi khi bạn dành nhiều thời gian hơn với một vài ngôn ngữ.

Ngày càng nhiều, mã giả được viết bằng đồ họa với các công cụ như UML. Ví dụ, hãy thử yUML .

một công cụ trực tuyến để tạo và xuất bản các sơ đồ UML đơn giản. Nó giúp bạn thực sự dễ dàng:

• Nhúng sơ đồ UML trong blog, email và wiki.
• Đăng sơ đồ UML trong diễn đàn và bình luận blog.
• Sử dụng trực tiếp trong công cụ theo dõi lỗi dựa trên web của bạn.
• Sao chép và dán sơ đồ UML vào tài liệu MS Word và bản trình bày Powerpoint ...

... yUML giúp bạn tiết kiệm thời gian. Nó được thiết kế để dành cho những người thích tạo sơ đồ và phác thảo UML nhỏ.

Nếu không có yUML, việc tạo sơ đồ UML có thể liên quan đến việc tải lên một công cụ UML, tạo sơ đồ, đặt tên cho nó, thay đổi bố cục, xuất nó thành bitmap và sau đó tải nó lên trực tuyến ở đâu đó. yUML không bắt bạn phải làm điều đó ...

Công việc tuyệt vời Bạn đã bắt đầu một cuộc thảo luận tốt. Đối với tôi, tôi thường viết mã giả khi tôi đang học lập trình để hiểu các vòng lặp và thuật toán khác nhau. Điều này đã hơn một thập kỷ trước. Ngày đó, ngay cả các ngôn ngữ lập trình cũng không mạnh mẽ lắm ... và lập trình hướng sự kiện là tương lai. Bây giờ với 4GL và 5GL, chúng tôi nghĩ bằng ngôn ngữ chứ không phải bằng tiếng Anh. Khi chúng ta nghĩ về một vấn đề, chúng ta nghĩ về các đối tượng và hoạt động. Và cho đến khi nó là một thuật toán phức tạp, việc viết mã giả (hoặc PSEU-DO-Code, chỉ đùa thôi) không có ý nghĩa gì. Tốt hơn, đại diện cho giải pháp một cách đồ họa.

Phụ thuộc vào ngôn ngữ được sử dụng và sự quen thuộc của bạn với nó.

Nhiều ngôn ngữ hiện đại như Python hay Java đã rất gần với mã giả mà việc viết một số mã giả ad hoc trước tiên là lãng phí, IMHO. Tốt hơn là chỉ cần làm điều đó ngay lập tức bằng cách sử dụng phương pháp đánh dấu viên đạn .

Đó là một thỏa thuận khác nếu bạn tạo ra một số thứ cấp thấp, gần với đồ kim loại hoặc chưa thoải mái với ngôn ngữ bạn đang sử dụng. Sau đó, mã giả chắc chắn có thể hữu ích.

Có một vài trường hợp trong đó mã giả có xu hướng bị phá vỡ trong công việc của tôi, đó là ở học viện nơi lập trình có xu hướng được sử dụng như một công cụ hoặc "và bây giờ chúng tôi giải quyết nó" ở giữa một dự án:

1. Khi mã sẽ phản tác dụng hơn với sự hiểu biết thực tế về những gì sẽ xảy ra so với mã giả sẽ. Ví dụ, SAS sẽ chiếm một nửa bảng trắng thực hiện một số nhiệm vụ lập trình khá cơ bản. Xem thêm C, mà một số áp phích khác đã thảo luận.
2. Với rất nhiều phân tích dữ liệu và mã hóa thống kê, có xu hướng có rất nhiều vấn đề với mã khi kết quả được tạo ra. Mã giả có phần dễ sử dụng hơn cho "ở đây là một quá trình qua lại, nếu âm mưu chẩn đoán không đúng, hãy thử X".
3. Học sinh học nhiều ngôn ngữ lập trình khác nhau. Ví dụ, trong số những người tôi biết, một vấn đề thống kê có thể được phân tích bằng SAS, R hoặc Stata. Một cái gì đó đòi hỏi một cái gì đó gần gũi hơn với lập trình truyền thống có thể được thực hiện trong R, Matlab, C, C ++, Java, Python ... nó thực sự phụ thuộc vào sinh viên cụ thể đang thực hiện chương trình và cho mục đích gì. Nhưng nó vẫn hữu ích cho người Java và người Python và người Matlab để có một ý tưởng chung về những gì người khác đang làm và cách tiếp cận , thay vì chính mã, hoạt động.

Đây không phải là một câu hỏi có / không. Thay vào đó, người ta nên tự hỏi khi nào nên sử dụng mã giả. Điều quan trọng là phải hiểu vấn đề trước khi thiết kế một giải pháp, và điều quan trọng là phải có một cái nhìn rõ ràng về giải pháp trước khi bạn thực hiện nó. Mã giả có thể được sử dụng trong bất kỳ bước nào sau đây:

1. Khi xác định vấn đề, thông thường viết ra các trường hợp sử dụng, đôi khi sử dụng các chuỗi hành động.
2. Khi thiết kế một giải pháp. Biểu đồ lớp là tốt, nhưng chúng chỉ mô tả phần "tĩnh", tức là dữ liệu. Đối với phần động, ngay khi bạn cần xử lý một vòng lặp và dữ liệu không tầm thường, tôi thấy mã giả là phương pháp tốt nhất hiện có. Các lựa chọn thay thế đồ họa bao gồm các máy trạng thái (tốt cho luồng điều khiển phức tạp với ít dữ liệu) và sơ đồ dataflow (tốt cho các luồng đơn giản với dữ liệu phức tạp).
3. Khi thực hiện giải pháp (hoặc chỉ trước đó). Một số ngôn ngữ lập trình khó đọc (nghĩ, lắp ráp). Một đại diện thay thế có thể có giá trị trong trường hợp này. Nếu bạn không quen thuộc với các ngôn ngữ, nó cũng đáng để làm.

Mã giả thực sự là mã phù hợp trong ngôn ngữ cấp cao cũng được sử dụng, nó thường được gọi là tạo mẫu.

Ngoài việc đạt được sự hiểu biết, mã giả cũng tốt cho giao tiếp.

Nếu bạn đang tự hỏi nếu bạn nên sử dụng mã giả một cách thường xuyên, cá nhân tôi chống lại tất cả các loại quy tắc cứng nhắc. Điều này có thể dễ dàng biến thành một sự lãng phí thời gian nhàm chán nếu được sử dụng cho các vấn đề tầm thường mà mọi người trong nhóm đều hiểu. Sử dụng mã giả cho các thông số kỹ thuật mà bạn duy trì trong suốt vòng đời của dự án cũng có thể tốn kém và cung cấp ít giá trị.