Làm cách nào tôi có thể thuyết phục sếp của mình rằng ANSI C không phù hợp với dự án mới của chúng tôi? [đóng cửa]

Vài tháng trước, chúng tôi đã bắt đầu phát triển một ứng dụng để điều khiển một thiết bị thử nghiệm được phát triển nội bộ và ghi lại một bộ các phép đo. Nó nên có một giao diện người dùng đơn giản và có thể sẽ yêu cầu các luồng do ghi liên tục phải diễn ra. Ứng dụng này sẽ được sử dụng trong một vài năm và sẽ được duy trì bởi một số sinh viên khoa học máy tính trong giai đoạn này.

Ông chủ của chúng tôi đã tốt nghiệp khoảng 30 năm trước (không được coi là một hành vi phạm tội; tôi cũng có hơn một nửa thời gian trên lưng) và đã yêu cầu chúng tôi phát triển ứng dụng này trong ANSI C. Lý do là ông là người duy nhất sẽ ở xung quanh toàn bộ thời gian, và do đó anh ta phải có khả năng hiểu những gì chúng ta đang làm. Ông cũng phán quyết rằng chúng ta không nên sử dụng các loại dữ liệu trừu tượng; anh ấy thậm chí còn đưa cho chúng tôi một danh sách với tên của các biến toàn cục (thở dài) mà anh ấy muốn chúng tôi sử dụng.

Tôi thực sự đã thử cách tiếp cận đó trong một thời gian, nhưng nó thực sự làm tôi chậm lại để đảm bảo rằng tất cả các hoạt động của con trỏ đều an toàn và tất cả các chuỗi có kích thước chính xác. Ngoài ra, số dòng mã thực sự liên quan đến vấn đề trong tay chỉ là một phần nhỏ trong cơ sở mã của chúng tôi. Sau một vài ngày, tôi đã loại bỏ toàn bộ và bắt đầu lại bằng C #. Ông chủ của chúng tôi đã thấy chương trình đang chạy và anh ấy thích cách nó hoạt động, nhưng anh ấy không biết rằng nó được viết bằng ngôn ngữ khác.

Tuần tới hai chúng tôi sẽ gặp nhau để đi qua mã nguồn, để anh ấy "sẽ biết cách duy trì nó". Tôi hơi sợ, và tôi muốn nghe từ các bạn những lý lẽ nào tôi có thể sử dụng để hỗ trợ cho quyết định của mình.

Hèn nhát của bạn,

Lưu ý rằng "Hãy làm như thế này để tôi chắc chắn rằng tôi có thể duy trì nó" thực sự là một yêu cầu rất tốt - hầu hết các chương trình đều được duy trì lâu hơn nhiều so với việc viết và giữ một giải pháp trong một công nghệ đã biết thường là một ý tưởng tốt.

Chỉ cần tưởng tượng nếu một đứa trẻ máy tính mới khi được yêu cầu viết một ứng dụng C # đã viết nó trong Haskell trong hai ngày và nói "Này, nó hoạt động và tôi đã biến mất, tạm biệt" để lại bảo trì cho bạn.

Chỉ cần tưởng tượng nếu một đứa trẻ máy tính mới khi được yêu cầu viết một ứng dụng ANSI C 15 năm trước đã viết nó trong Visual Basic 6 trong hai ngày và để lại nó. Bây giờ bạn phải duy trì nó và Windows 7 đã bắt đầu phàn nàn khi phương tiện cài đặt được chèn .

Đây có thể là một cơ hội tốt để nói - như Heinzi đã nói bóng gió trong các bình luận - rằng "đây là một nguyên mẫu nhanh được viết bằng C # trông rất giống C - chúng ta sẽ làm cho nó sẵn sàng sản xuất, hoặc tái hiện nó trong ANSI C như bạn hỏi ", và sau đó thảo luận ngay bây giờ. Có nguồn thực tế để xem, tốt hơn nhiều so với "Này, chúng ta không nên viết ứng dụng tiếp theo của mình trong Haskell vì nó nhanh hơn".

Nói cách khác - bây giờ bạn có cơ hội chứng minh rằng một nền tảng mới có thể được xem xét. Đưa ra rằng bạn đã viết một nguyên mẫu trước khi xem xét mã - điều này sẽ giúp loại bỏ ấn tượng mà bạn đang cố gắng lén C # trong radar. Tôi muốn đề nghị bạn cũng chứng minh rằng tất cả các mã hiện có được viết bằng ANSI C có thể được sử dụng từ bên trong C #. Cá nhân tôi tin rằng bạn sẽ được thông báo rằng mục tiêu vẫn là ANSI C để ở trong một nền tảng duy nhất.

Sếp của bạn dường như là khách hàng của bạn trong trường hợp này, và yêu cầu chính của anh ta là anh ta có thể duy trì ứng dụng khi bạn tiếp tục. Điều này có vẻ khá hợp lý.

Vì vậy, lựa chọn là làm những gì anh ta yêu cầu, hoặc chứng minh rằng bạn có thể hoàn thành phát triển VÀ dạy anh ta cách duy trì ứng dụng C # trong thời gian hạn chế và với chi phí thấp hơn. Nếu bạn không thể làm điều đó, bạn không đáp ứng các yêu cầu của dự án.

Bạn chưa cung cấp nhiều thông tin nhưng tôi nghĩ C hoàn toàn là lựa chọn đúng đắn - Tôi làm Kỹ sư trong một nhà máy công nghiệp và hầu hết (nếu không phải tất cả) mã của chúng tôi được viết bằng C. Nếu bạn cần lấy số đo từ một thiết bị (tôi giả sử là đồng hồ đo lưu lượng hoặc cặp nhiệt điện hoặc tương tự ở đây) và hiển thị nó ở gần thời gian thực C là một lựa chọn tuyệt vời.

Nó nhanh, di động (Tôi chưa bao giờ viết bằng C # nhưng tôi không nghĩ nó hoạt động mà không có phiên bản cụ thể của khung được cài đặt và nó thường chỉ dựa trên các cửa sổ).

Bằng mọi cách bạn có thể sử dụng ngôn ngữ khác để làm GUI. Nhưng bạn có thể tiết kiệm cho mình công sức và chỉ cần sử dụng gói xu hướng có sẵn (có một số gói mã nguồn mở tốt có sẵn).

Tóm lại, tôi muốn nói rằng giao diện cơ bản với phần cứng C là một lựa chọn tốt.

Trời ơi. Đây là một ứng dụng thời gian thực? Điều khiển thiết bị trong thời gian thực? Thu thập dữ liệu trong thời gian thực? Sử dụng ngôn ngữ với trình thu gom rác? Trời ơi.

Mặc dù tôi đồng ý rằng bạn có thể làm ứng dụng bằng ngôn ngữ hiện đại hơn trong thời gian ngắn hơn, nhưng đó có lẽ không phải là tiêu chí chính. EASE CỦA CHƯƠNG TRÌNH CỦA BẠN LÀ RẤT NHIỀU RẤT NHIỀU QUAN TRỌNG HƠN CÁC TIÊU CHÍ KHÁC, chẳng hạn như những gì ông chủ của bạn đặt ra, VÀ thời gian phản hồi, và hành vi xác định.

Tôi đã đề nghị bạn làm một nguyên mẫu trong C # hoặc Python, chỉ để kiểm tra chức năng chính và giao diện người dùng. THEN kiểm tra cái quái gì đó, đo độ trễ thực tế và thời gian phản hồi, khi ứng dụng bị tấn công với nhiều dữ liệu, trong nhiều ngày chạy liên tục. Vấn đề là, ứng dụng có thể kết thúc quá chậm hoặc bị tụt lại vào những thời điểm ngẫu nhiên, khi VM hoặc trình thu gom rác khởi động.

Tôi đề nghị bạn trình bày những gì bạn đã làm với tư cách là một PROTOTYPE.

Mã hóa trong C không khó lắm. Nếu bạn không theo kịp, hãy nói như vậy. Có rất nhiều người trong chúng ta vượt qua thử thách. (Tôi đã thực hiện mã hóa C thời gian thực trong khoảng vài thập kỷ nay).

Chà, điều đầu tiên cần làm là đến gặp sếp của bạn và đánh bại. Bạn đã bỏ qua yêu cầu rõ ràng của anh ấy, và tệ hơn là đã làm như vậy trong nhiều tháng. Tôi không biết bạn đã dành bao nhiêu thời gian cho việc này, nhưng giả sử rằng phần lớn thời gian dành cho việc thực hiện dự án, bạn phải đối mặt với thực tế là bạn có thể sẽ sớm tìm kiếm một công việc mới.

Càng sớm đối phó với điều này càng tốt.

Thứ hai, tôi không nghĩ bạn có thể thuyết phục anh ta rằng ANSI C là không đủ, điều bạn cần làm là thuyết phục anh ta về một số điều khác (1) rằng c # là đủ, (2) anh ta có thể dễ dàng học cách duy trì c #, (3 ) rằng bạn không có ý định viết nó trong C. Giả sử rằng bạn vẫn còn một công việc và một phần để chơi với dự án này, tôi sẽ tập trung vào 2, nhấn mạnh sự tương đồng giữa c và c #.

Trích dẫn để phản hồi ý kiến ​​...

Vài tháng trước, chúng tôi đã bắt đầu phát triển một ứng dụng [...] Sau một vài ngày, tôi đã loại bỏ toàn bộ và bắt đầu lại bằng C #

đã bắt buộc chúng tôi phát triển ứng dụng này trong ANSI C. Lý do căn bản là anh ấy là người duy nhất sẽ có mặt trong toàn bộ thời gian, và do đó anh ấy phải có thể hiểu những gì chúng tôi đang làm.

Đây là một yêu cầu khá hợp lý.

Ông cũng phán quyết rằng chúng ta không nên sử dụng các loại dữ liệu trừu tượng;

Điều này không có ý nghĩa. Bây giờ nó bắt đầu ngửi thấy một chút nghi ngờ, bởi vì đây là một yêu cầu thiết kế chương trình và không phải là một yêu cầu ngôn ngữ. Nếu mã phải dễ bảo trì, việc triển khai các ADT hoặc sử dụng các thử nghiệm đã được kiểm tra tốt, các mã tồn tại trước sẽ là ưu tiên.

anh ấy thậm chí còn đưa cho chúng tôi một danh sách với tên của các biến toàn cục (thở dài) mà anh ấy muốn chúng tôi sử dụng.

Ok, vậy bây giờ nó bốc mùi. Bây giờ chúng tôi có thể nói rằng ông chủ của bạn có kinh nghiệm hạn chế không chỉ từ các ngôn ngữ lập trình khác nhau, mà còn từ lập trình nói chung. Một lập trình viên kỳ cựu có tay nghề cao, bất kể ưu tiên ngôn ngữ, sẽ không bao giờ đưa ra tuyên bố như vậy. (Ngoại lệ duy nhất mà tôi có thể nghĩ đến là nếu hầu hết mã được dự định chạy trên một hệ thống nhúng khá nhỏ, và do đó, tất cả bộ nhớ làm việc cần thiết cho mã được dự kiến ​​sẽ được cấp phát trước. Tuy nhiên, dự kiến ​​sẽ có một giao diện người dùng ở cấp độ màn hình lập luận chống lại mạnh mẽ rằng đó là trường hợp, tuy nhiên).

Tôi đoán rằng ông chủ của bạn chưa bao giờ tham gia vào các dự án phần mềm quan trọng, quy mô lớn, nhưng anh ta có nhiều khả năng nổi xung quanh trong các dự án chất lượng thấp khác nhau.

Vì vậy, điều này không liên quan gì đến ngôn ngữ lập trình C. Bạn cũng có thể dễ dàng viết các chương trình icky bằng nhau trong C #. Đó là một sai lầm rất phổ biến để tin rằng thiết kế chương trình tốt phụ thuộc vào ngôn ngữ. Đó chỉ đơn giản là không đúng sự thật!

C # chắc chắn có cú pháp đẹp hơn, gọn gàng hơn và ít tối nghĩa hơn C. Nó có rất nhiều hỗ trợ thiết kế chương trình, vì nó có nhiều từ khóa liên quan đến OO hơn C. Nhưng ngoài ra, nó không cho bạn biết cách viết chương trình của bạn. Nếu bạn tin rằng mọi thứ được viết bằng C theo mặc định là khủng khiếp và mọi thứ được viết bằng C # là thiên đường theo mặc định, tôi cá là bạn hiện đang viết các chương trình C # khá khủng khiếp mà không nhận ra điều đó.

Những gì tôi muốn đề nghị là bạn thực hiện một thiết kế chương trình trừu tượng, độc lập với ngôn ngữ, nhưng chi tiết trước mọi thứ khác. Sử dụng cách tiếp cận bình thường, hướng đối tượng. Những đối tượng nào ở đó và làm thế nào để chúng giao tiếp với nhau, những phụ thuộc cần thiết, v.v. Khi bạn đã thiết kế chương trình đủ suy nghĩ và đưa nó xuống giấy, điều đó không quan trọng với bạn cũng như với sếp của bạn ngôn ngữ bạn đã chọn để thực hiện nó trong.

Vấn đề đầu tiên bạn phải giải quyết là một vấn đề tình cảm, phi lý. Ngành công nghiệp CNTT là một trong những thay đổi liên tục và, mặc dù có những nơi cho tất cả mọi thứ, từ chối cải thiện hoặc chấp nhận thay đổi là một vấn đề.

Tại sao ông chủ của bạn bám vào ANSI C? Nếu đó là ngôn ngữ duy nhất anh ấy hoặc cô ấy biết thì có lẽ đã đến lúc thay đổi nhưng một lập luận hợp lý có thể không đủ. Sếp của bạn sẽ cảm thấy bị đánh giá thấp hoặc có thể bị sa thải nếu bị buộc phải làm việc trong một ngôn ngữ xa lạ? Nhấn mạnh kinh nghiệm mà anh ta có và những lợi ích khác mà anh ta mang lại.

Nếu bạn không giải quyết vấn đề này, tất cả các lý lẽ hợp lý bạn có thể mang lại sẽ bị lãng phí. Là cấp dưới, bạn có thể không phải là người có thể có cuộc thảo luận này với anh ta. Có lẽ giới thiệu chủ đề này cho một trong những người quản lý khác, nếu có.

Cũng xem xét nó từ quan điểm của bạn. Tại sao bạn muốn sử dụng C #? Bao nhiêu trong số này là mong muốn sử dụng một cái gì đó mới và mát mẻ? Thành thật với chính mình. Nếu bạn nhận ra điều này, nó sẽ giúp bạn tranh luận hiệu quả hơn.

Vấn đề thứ hai là một trong những rủi ro và chi phí. Phần mềm viết là đắt tiền và sự lựa chọn ngôn ngữ là một yếu tố chính trong đó. Xem xét:

1. Sẽ mất bao lâu để viết bằng C # so với C? Với định hướng đối tượng dễ dàng hơn và thu gom rác tốt hơn, C # có thể dễ dàng hơn. Tuy nhiên, nếu ứng dụng sử dụng nhiều lệnh gọi API không được quản lý, C có thể dễ dàng hơn.
2. Nếu bạn sử dụng C #, bạn có cần mua thêm công cụ không? Nghe có vẻ như bạn đã sử dụng Visual Studio nhưng bạn có cần các công cụ bổ sung để bản địa hóa, xem xét và phân tích mã, gỡ lỗi hay không?
3. Làm thế nào dễ dàng để duy trì? Nếu bạn tìm thấy một lỗi, làm thế nào nó có thể được sửa chữa nhanh chóng. C # có thể làm giảm định hướng đối tượng này. Bộ sưu tập rác tự động cũng tránh được hầu hết các vấn đề rò rỉ bộ nhớ và con trỏ.
4. Làm thế nào dễ dàng để hỗ trợ? Nếu bạn có nhân viên hỗ trợ, họ có thể biết cách đọc một bãi chứa sự cố nhưng họ có biết cách sử dụng Windbg với SOS không? Các máy mục tiêu đã có phiên bản thích hợp của khung .Net chưa được cài đặt chưa?
5. Cân nhắc nhân sự. Có bao nhiêu người biết C so với C #? Nếu một trong hai hoặc cả hai bạn rời khỏi tổ chức, việc thay thế bạn sẽ dễ dàng như thế nào? Là nhà phát triển C rẻ hơn hay đắt hơn nhà phát triển C #?

Tôi có thể tiếp tục nhưng vấn đề là ngừng tranh luận về giá trị kỹ thuật của các ngôn ngữ. Giá trị kỹ thuật là những điều chỉ có bạn và sếp của bạn hiểu. Nếu bạn bắt đầu nói về tác động kinh doanh, bạn kéo theo một nhóm người rộng hơn nhiều và đưa ra một lập luận thuyết phục hơn nhiều.

Có lẽ C là một lựa chọn tốt hơn. C # không tự động tốt hơn cho tất cả các tình huống. Có thể bạn thực hiện dự án này bằng C nhưng thực hiện bằng chứng khái niệm C # cho lần tiếp theo. Hãy nhớ rằng bạn có thể thua trận chiến nhưng vẫn chiến thắng trong cuộc chiến.

Có thể là một lập luận khác: Có lẽ rất khó để tìm sinh viên khoa học máy tính có đủ kinh nghiệm để viết mã C mà không mắc lỗi. ANSI C không phải là điều đầu tiên mọi người học ngày nay.

Bây giờ tất cả sinh viên khoa học máy tính sẽ giết tôi.

Bạn đã hoàn toàn thất bại trong việc thuyết phục chúng tôi rằng ANSI C là không đủ. C là một ngôn ngữ tuyệt vời có vẻ thích nghi với loại nhiệm vụ bạn đã mô tả. Với mô tả ngắn về nhiệm vụ (ngoại trừ yêu cầu ngôn ngữ), tôi cũng muốn giới thiệu C (hoặc có thể đi).

Tôi nghĩ vấn đề là bạn đã lập trình trong C với suy nghĩ của bạn trong C #. Tôi có một vấn đề tương tự khi tôi chuyển từ Perl sang C hoặc java. Bạn phải học cách thích nghi với ngôn ngữ, và không học cách dịch từ cách suy nghĩ của bạn sang ngôn ngữ trong ngày.

Vấn đề không phải là sếp của bạn hay ngôn ngữ C, vấn đề là mở mang đầu óc của bạn theo những cách nghĩ khác nhau. Thay đổi ngôn ngữ lập trình là điều sẽ có lợi cho bạn.

Trước hết, bây giờ bạn cần nói với sếp của mình bằng một ngôn ngữ khác. Anh ấy sẽ (có thể hiểu được) tức giận nếu bạn mang lại một cái gì đó có chủ đích trái với yêu cầu mà không cần thông báo trước.

Bây giờ, cách tốt nhất để giải thích những điều này cho sếp / người quản lý là đưa nó về thời gian và tiền bạc. Ước tính thời gian dự án như vậy sẽ mất bao nhiêu thời gian trong ANSI C, và sau đó ước tính thời gian thực hiện ở cấp độ cao hơn như C #. Lưu ý tôi nói cấp cao hơn, không hiện đại. Điều này có thể giúp làm cho mọi thứ trơn tru hơn. Ý tôi là, bạn sẽ không giải quyết việc sơn một căn phòng chỉ bằng một chiếc cọ sơn nhỏ xíu, bạn sẽ sử dụng các con lăn và những thứ khác làm cho mỗi nét (dòng mã) bao phủ nhiều diện tích của dự án. Ngoài ra, nếu bạn hoặc một trong các thành viên trong nhóm của bạn không biết C, hoặc thoải mái thực hiện một dự án lớn ở C, điều này sẽ ăn sâu vào vấn đề thời gian hơn nữa vì họ sẽ phải tăng tốc.

Nó cũng có vẻ như ông chủ của bạn đang cố gắng để vi mô. Tôi chắc chắn một trong những câu trả lời khác sẽ cố gắng giải thích làm thế nào để sếp của bạn làm điều đó ít hơn

Sự ác cảm của người giám sát đối với các ADT đã được đề cập ở nơi khác, vì dường như các nhà phát triển dường như không nhận thức được chi phí của GC, vì vậy tôi sẽ tập trung vào "chủ đề".

Có lẽ thay vì suy nghĩ theo cách phân luồng .NET (hoặc JVM, nếu được truyền bá), điều bạn có thể muốn là nhiều quy trình, sử dụng một số cơ chế giao tiếp giữa các quá trình (IPC) để giao tiếp giữa chúng. Ví dụ - tin nhắn windows, bộ nhớ dùng chung, bộ đệm tập tin ánh xạ bộ nhớ, tên ống, bất cứ điều gì. Dành các quy trình nhỏ để tương tác với thiết bị hoặc khía cạnh của thiết bị và kiểm tra IPC để liên lạc với các bản cập nhật và xác nhận yêu cầu, đồng thời có một quy trình lớn hơn để duy trì GUI và giao tiếp với "màn hình" của thiết bị bằng bất kỳ IPC nào bạn chọn.