Cái gì là / Có cách nào đúng để nói với quản lý rằng mã của chúng ta hút không?

Mã của chúng tôi là xấu. Nó có thể không luôn luôn được coi là xấu, nhưng nó là xấu và chỉ đang xuống dốc. Tôi bắt đầu mới ra trường chưa đầy một năm trước, và nhiều điều trong mã của chúng tôi đánh đố tôi ngoài niềm tin. Lúc đầu, tôi nghĩ rằng là một người mới, tôi nên im lặng cho đến khi tôi biết thêm một chút về cơ sở mã của chúng tôi, nhưng tôi đã thấy nhiều điều để biết rằng điều đó thật tệ.

Một số điểm nổi bật:

• Chúng tôi vẫn sử dụng các khung (thử lấy thứ gì đó ra khỏi chuỗi truy vấn, gần như không thể)
• VBScript
• Nguồn an toàn
• Chúng tôi 'sử dụng' .NET - ý tôi là chúng tôi có các trình bao bọc .net gọi COM DLL khiến cho việc gỡ lỗi gần như không thể dễ dàng
• Tất cả mọi thứ về cơ bản là một chức năng khổng lồ
• Mã không thể duy trì. Mỗi trang có nhiều tệp được tạo mỗi khi một trang mới được tạo. Về cơ bản, trang chính thực hiện Phản hồi.Write () rất nhiều lần để hiển thị HTML (runat = "server"? Không có cách nào). Sau đó, có thể có rất nhiều logic ở phía máy khách (VBScript) và cuối cùng trang sẽ tự gửi (thường lưu trữ nhiều thứ trong các trường ẩn), sau đó nó sẽ đăng lên một trang xử lý có thể thực hiện những việc như lưu dữ liệu vào cơ sở dữ liệu.
• Các thông số kỹ thuật chúng tôi nhận được là buồn cười. Thông thường, họ gọi những thứ như "tự động điền vào trường X với trường Y hoặc trường Z" mà không có dấu hiệu cho biết khi nào nên chọn trường Y hoặc trường Z.

Tôi chắc chắn một số điều này là kết quả của việc không được tuyển dụng tại một công ty phần mềm, nhưng tôi cảm thấy như mọi người viết phần mềm ít nhất nên quan tâm đến chất lượng mã của họ. Tôi thậm chí không thể tưởng tượng được rằng nếu tôi đưa ra một cái gì đó thì mọi thứ sẽ được thực hiện sớm, vì có một thời hạn lớn hiện ra, nhưng chúng tôi vẫn đang tiếp tục viết mã xấu và sử dụng các thực tiễn xấu.

Tôi có thể làm gì? Làm thế nào để tôi thậm chí đưa những vấn đề này lên? 75% nhóm của tôi đồng ý với tôi và đã đưa ra những vấn đề này trong quá khứ, nhưng không có gì thay đổi.

Hãy chắc chắn rằng bạn không phản ứng thái quá. Bạn là người mới, có lẽ chưa từng làm việc ở bất kỳ nơi nào khác (và?), Và vì vậy không được chuẩn bị cho thế giới của "mã đời thực". Mã đời thực là một điều khủng khiếp. Nó giống như mã trường học tốt đẹp của bạn và mã dự án cá nhân được điều chỉnh một cách ám ảnh của bạn đã quan hệ tình dục dưới tầng hầm của lò phản ứng hạt nhân và em bé lớn lên trong một cống thải chất thải độc hại; nó là một dị nhân gớm ghiếc

Nhưng giả sử bạn đúng và mã cũng tệ như bạn nói (nghĩa là tệ hơn cả mã xấu thông thường), thì bạn có quyền được quan tâm. Nói chuyện với nhóm của bạn và xác định xem những người khác có ở bên hay không. Sẽ có công việc để cải thiện tình hình - nếu các thành viên còn lại nhận ra vấn đề nhưng không quan tâm thì bạn đang lãng phí thời gian.

Là một thiếu niên, có lẽ bạn không ở vị trí lãnh đạo. Nếu bạn đi quản lý bản thân, với tư cách là một người thuê mới cũng là một thiếu niên, ý kiến ​​của bạn có thể sẽ bị coi thường. Nhận nhà phát triển chính của bạn hoặc một trong những người cao cấp nhất tham gia. Một lần nữa, nếu không ai trong số những người cao cấp quan tâm thì bạn đang lãng phí thời gian của mình.

Giả sử bạn có thể khiến một số người kỹ thuật cao cấp quan tâm, tôi sẽ hướng tới việc xác định các khu vực có vấn đề và các giải pháp khả thi. Ví dụ: nếu "mọi thứ về cơ bản là một hàm khổng lồ" thì lần tới khi bạn làm việc trong 'hàm khổng lồ' đó, có lẽ bạn nên cấu trúc lại một chút. Một lần nữa, bạn cần phải có được mọi người ở bên. Nếu bạn giải quyết được từng vấn đề nhỏ và cải thiện từng mảnh một thì cuối cùng chúng sẽ trở thành vấn đề ít hơn nhiều. Mỗi khi bạn chạm vào một đoạn mã hãy xem xét liệu nó có thể được cải thiện hay không.

Bạn sẽ không ngồi xuống với quản lý và nói 'mọi thứ đều tệ và cần phải viết lại'. Điều đó không có ý nghĩa đối với họ - chi phí rất nhiều và có khả năng rất rủi ro. Thay vào đó, họ nên được biết rằng có vấn đề và có kế hoạch cải thiện từ từ khi có thay đổi. Họ nên được giáo dục về lợi ích của mã duy trì. Điều này nên đến từ một người cao cấp mà họ tin tưởng về mặt kỹ thuật và chuyên nghiệp - không phải từ bạn.

Viết lại hoàn chỉnh? Hầu như luôn luôn là một ý tưởng tồi.

Cuối cùng, bạn không thể làm gì nhiều vì bạn là người mới. Nếu không ai muốn cải thiện mọi thứ, thì bạn thu thập kinh nghiệm của mình và chuyển đến nơi tiếp theo.

Đọc Joel On Software - những điều bạn không bao giờ nên làm. Hiểu lý lẽ của anh ấy, sau đó đọc một vài bài viết khác về phần mềm xấu và cách khắc phục nó, được viết bởi các nhà quản lý, không phải lập trình viên. Được trang bị thông tin này, bạn sẽ có thể trình bày một trường hợp để sửa nó, theo cách mà các nhà quản lý hiểu và quan tâm. Gợi ý: Các nhà quản lý giỏi không dành thời gian và tiền bạc chỉ dựa trên ý kiến ​​và cảm nhận của lập trình viên về những gì phải làm.

"Mã này là tào lao và cần viết lại" chắc chắn sẽ bị ném trả lại cho bạn, ngay cả khi bạn đúng về mặt kỹ thuật.

"Chúng tôi có thể mất nhiều tháng trong lịch trình dự án hiện tại, chi phí ít hơn và làm cho nó đáng tin cậy hơn." sẽ thu hút sự chú ý của họ (thông báo thiếu đề cập đến CÁCH BẠN dự định làm điều này ở giai đoạn của anh ấy.

Dù bạn nói gì, hãy chắc chắn bạn đúng. Nếu bạn nói nó tệ, thì việc viết lại của bạn phải rất tốt. Nếu bạn nói sẽ mất một tuần, bạn nên chắc chắn rằng đó sẽ là một tuần, và sẽ tốt. Bất kỳ khiếm khuyết nào trong mã được làm lại sẽ khiến bạn phải trả giá đắt, cá nhân, bất kể điều gì có thể xảy ra nếu bạn không thực hiện lại. Nếu ai đó đã ở đó trước bạn và làm hỏng hoặc viết lại, hãy từ bỏ, các nhà quản lý không thích bị lừa và sẽ không để nó xảy ra hai lần. Với mã thông báo đó, đừng làm hỏng nó cho những kẻ theo dõi, bạn chỉ nhận được một cú đánh vào đây ...

Tìm cách để phân bổ chi phí trong một khoảng thời gian hoặc số lượng dự án. Người quản lý ghét rủi ro, đầu tư đầu cơ và dòng tiền âm - làm việc trong phạm vi dung sai của người quản lý của bạn. Bắt đầu với một gợi ý nhỏ, rủi ro thấp, chi phí thấp. Một khi bạn được chứng minh là đúng, bạn có thể đi tìm những con cá lớn hơn.

Trước hết, bạn sẽ tìm thấy những thứ kế thừa ngớ ngẩn ở bất cứ nơi nào bạn làm lập trình viên trừ khi bạn làm việc khi mới khởi nghiệp và bạn là người tạo ra mã kế thừa ngu ngốc ban đầu. Bạn phải có khả năng lăn lộn với những cú đấm này nếu bạn có kế hoạch lập nghiệp.

Thứ hai, thường có những cân nhắc về chi phí để cải thiện các hệ thống cũ. Ví dụ: tôi đã thấy nhiều hơn một công ty có VB6 10 năm và các ứng dụng ASP cổ điển vẫn đang hoạt động. Trong một số trường hợp, điều này là do một dự án lớn để di chuyển .NET đã thất bại nặng nề. Ở những người khác, lý do là "nếu nó không bị hỏng, đừng sửa nó". Nhưng, ở những người khác, chi phí di chuyển là hợp lý vì các vấn đề gây ra bởi hệ thống di sản là lớn để bỏ qua.

Trong những tình huống đã có một thất bại lớn trong quá khứ, gần như không thể mang lại sự thay đổi. Trong trường hợp đó, đánh bóng sơ yếu lý lịch của bạn và bắt đầu tìm kiếm một công việc mới. Nếu nó không bị hỏng, có lẽ bạn sẽ không phải phàn nàn về chính mã đó mà là bạn không đi theo con đường sự nghiệp đang phát triển và hoàn thành. Nếu nó bị hỏng và có vẻ như trong trường hợp của bạn, đó là khi bạn có cơ hội thay đổi.

Cách tiếp cận tốt nhất tôi từng thấy không phải là cắn quá nhiều mà là bắt đầu bằng những thay đổi gia tăng sẽ có tác động tích cực nhất. Dựa trên mô tả của bạn, quản lý các yêu cầu thay đổi tốt hơn sẽ là nơi để bắt đầu. Khi đã được kiểm soát, bạn có thể bắt đầu xem xét việc tạo khung dịch vụ hoặc các cải tiến thiết kế / mã gia tăng khác.

Cách tiếp cận tồi tệ nhất tôi từng thấy là cố gắng tạo ra một bước nhảy vọt trực tiếp từ hệ thống cũ sang hệ thống mới nhất và lớn nhất, ví dụ, chuyển từ hệ thống VB6 / Classic ASP / COM + hoạt động mạnh mẽ sang hệ thống MVC / Entity Framework.

"Này ông chủ, sau Dự án lớn, tôi và nhóm muốn có một thời gian, lý tưởng nhất là X tháng, để tổ chức mã của chúng tôi. Những việc đó có thể được thực hiện trong vài phút vì tất cả đều vô tổ chức. Nếu không thể thực hiện được. ngay sau Dự án lớn, chúng tôi muốn lên kế hoạch thực tế. "

(một phần được diễn giải từ nhận xét của Azkar về câu hỏi)

Bắt đầu đọc Joel trên Phần mềm (Joel Spolsky / Người sáng lập Stack Exchange) ...

Điều đầu tiên tôi sẽ làm là thực hiện một thử nghiệm Joel .

Điều này sẽ cho phép bạn trình bày nó như là "Trong khi tôi đang tìm cách cải thiện như một nhà phát triển ... Tôi đã tình cờ kiểm tra 12 câu hỏi này về môi trường phát triển, vì vậy tôi rất vui khi trả lời họ về nơi tôi làm việc." ... Điều này đến lượt nó làm cho bên thứ 3 phác thảo những gì sai với mã của bạn chứ không phải cá nhân bạn.

Khi bạn đọc thêm về Thực tiễn thực dụng, bạn sẽ cải thiện bản thân và thực hiện những thứ như đỏ / xanh / tái cấu trúc và điều này sẽ cho phép bạn dọn sạch cơ sở mã để có thể duy trì được. (tăng ca)

Mong rằng sẽ giúp! Chào mừng bạn đến với Lập trình (mã ngày hôm nay thường tệ) ;-)

Mẹo nhanh: nếu bạn đề xuất quản lý với một danh sách các lý do tại sao bạn nên viết mã khác nhau, hãy đưa vào như một đối số "Cải thiện tinh thần / điều kiện làm việc cho các lập trình viên".

Làm rõ rằng nhóm công nghệ sẽ viết nội dung nhiều hơn và duy trì mã sạch hơn so với mớ hỗn độn hiện tại này và điều này chắc chắn có thể cải thiện thái độ của bạn đối với công việc. Có thể là một đối số hữu ích.

• Liệu quản lý thực sự ra lệnh cho thiết kế? Nếu bạn có hầu hết các đội phía sau bạn, điều gì ngăn cản bạn? Hãy chủ động và quyết định như một nhóm. Hãy đưa ra một kế hoạch để thực hiện nó tăng dần . Sau đó làm điều đó.
• Có phải quản lý ra lệnh cho các công cụ phát triển bạn sử dụng? Trừ khi có một chi phí thời gian để trao đổi quản lý công cụ thường không quan tâm. Hãy chủ động và quyết định theo nhóm một công cụ phát triển nào bạn muốn sử dụng. Nếu bạn cần mua lại từ ban quản lý thì hãy cho họ xem kế hoạch di chuyển và phân tích lợi ích chi phí. Sau đó làm điều đó.
• Có quản lý ra lệnh các ngôn ngữ bạn sử dụng? Hãy chủ động và quyết định theo nhóm nên sử dụng cái gì thay vì VBScript. Hãy đưa ra một kế hoạch để thực hiện nó dần dần và thực hiện nó. Nếu bạn cần quản lý mua cho họ xem kế hoạch. Sau đó làm điều đó.
• Tôi không có gì cho thông số kỹ thuật. Điều đó thường phụ thuộc nhiều vào con người và quy trình trong công việc của bạn. Xác định những gì bị hỏng và những thay đổi tối thiểu cần thiết để khắc phục quy trình cần có thời gian, phân tích và hiểu về cách mọi thứ hiện đang hoạt động và cách chúng nên hoạt động. Nếu bạn biết rằng bạn có thể đưa ra một kế hoạch và thử và thuyết phục quản lý.

Bạn sẽ nhận được nhiều thay đổi và tôn trọng hơn nếu đề xuất các cách thay đổi không liên quan đến lượng lớn thời gian dành riêng mà không có giá trị kinh doanh (hoặc mềm) để hiển thị cho nó.

Nói từ kinh nghiệm: Nó không dễ dàng. Nó gần như không thể. Quản lý không quan tâm rằng mã bị hút và nhiều khả năng là hoàn toàn không biết gì và / hoặc không biết gì về các vấn đề đang phải đối mặt, hoặc họ sẽ sửa nó từ lâu và bạn sẽ không bị mắc kẹt với nó ngày hôm nay. Điều tốt nhất bạn có thể làm là lập một danh sách các lý do mã bị hút, và sau đó là lý do đằng sau lý do tại sao nó hút để chứng minh giá trị kinh doanh thực tế trong việc tái cấu trúc / viết lại nó.

Một ví dụ có thể là "Mã không thể duy trì":

Mã hiện tại không thể duy trì được do X , Y và Z (liệt kê các lý do tại sao nó không thể xác định được). Điều này làm cho các yêu cầu thay đổi và các tính năng mới rất khó thực hiện, vì X , Y , Z (lý do tại sao thực hiện thay đổi là khó khăn). Vì các thay đổi là khó khăn, nhóm phát triển không thể dễ dàng phản hồi các sửa lỗi và cải tiến.

Hy vọng duy nhất của bạn là sếp và quản lý cấp cao của bạn không quá ngu ngốc để hiểu những phân nhánh nào có trong mã và sẵn sàng ngừng đưa ra các yêu cầu tính năng mới để giải quyết các vấn đề, nếu không thì những nỗ lực của bạn sẽ vô ích . Phát biểu từ kinh nghiệm trong quá khứ, rất có thể họ sẽ không thấy bất cứ điều gì sai với mã và / hoặc đồng nghiệp của bạn quá vô dụng để đưa mối quan tâm của họ đến quản lý.

Chúc may mắn. Bạn sẽ cần đến nó.

"Tôi bắt đầu mới ra trường" - nên trả lời câu hỏi của bạn.

Các quản lý có thể biết có mã là tối ưu phụ. Hầu hết các mã là trừ khi bạn thuê Ray Gosling, Guido Van Rossum hoặc người khác thực sự giỏi và đắt tiền để viết nó.

Quản lý cũng biết nó hoạt động bằng cách sử dụng bất kỳ định nghĩa nào về "công việc" áp dụng cho công ty của bạn (Không sụp đổ, bán, cung cấp báo cáo hoặc bất cứ điều gì).

Họ muốn bạn giữ mã "làm việc" với chi phí tối thiểu. Họ không muốn một đề xuất cho một dự án đắt tiền để viết lại mọi thứ.

Trường hợp kinh doanh gần như không thể thực hiện được vì khả năng cung cấp của bạn là phần mềm hoạt động (những gì họ đã có) không phải là mã thanh lịch.

Thêm vào thực tế là trong phần mềm có chi phí cơ hội lớn từ việc tiếp cận thị trường với các tính năng đầu tiên. Nếu bạn thực sự nghĩ về nó, việc hoàn vốn dài hạn cho khoản đầu tư thời gian không được đảm bảo.

Điều đó nói rằng, nó vẫn là một kế hoạch tốt để tái cấu trúc và sửa chữa những điều nhỏ nhặt (như có được một VSS tốt) trên đường đi trong các vết cắn có thể quản lý được. Cuối cùng, đây là một vấn đề kỹ thuật không phải là một vấn đề quản lý. Chỉ cần làm những gì cần phải làm trong khi vẫn cung cấp những gì bạn hứa và bạn sẽ ổn. Quản lý có lẽ sẽ không quan tâm đến các chi tiết khó chịu về chất lượng mã ngay cả khi bạn tạo ra một trường hợp mạnh.

Chỉ cần rời khỏi ngay khi bạn có thể (có thể không rời đi quá sớm vì bạn không muốn trông giống như một phễu công việc). Thực tế là mã của họ là một mớ hỗn độn và mọi người đang ở đó có nghĩa là bạn có khả năng làm việc với các nhà phát triển kém. Bất kỳ nhà phát triển tử tế nào quan tâm đến công việc của họ sẽ không làm việc lâu như vậy.

Cơ hội viết lại xảy ra khá thấp trừ khi bạn có thể chứng minh rất rõ ràng rằng nó sẽ đáng để đầu tư $$$.

Quản lý không quan tâm đến mã. Họ quan tâm đến việc có một sản phẩm để bán.

Nếu hệ thống kế thừa thực sự, thực sự tồi tệ và nó đang bổ sung một khoản chi phí vô lý cho phần lớn đội bóng (tôi nói đa số vì luôn có một anh chàng hoặc mã hóa khối lớn hoặc tất cả đều biết và biết nó giống như mặt sau của bàn tay của anh ấy) sau đó tiếp cận họ và nói rằng nó tiêu tốn tiền của doanh nghiệp trong thời gian phát triển và nó sẽ có tác dụng với sự hài lòng của khách hàng.

Nhưng một lần nữa, họ vẫn không quan tâm đến mã, họ quan tâm đến một sản phẩm, vì vậy trong khi câu trả lời đó có thể khiến họ phải "Vâng, hãy làm đi", bạn cũng có thể dọn dẹp mã mà không cần xin phép người quản lý. Đừng quá nhiệt tình, hãy chắc chắn rằng bạn nói chuyện với nhóm trước, không ai thích đến và thử sử dụng chức năng đó khiến bạn mất 3 tháng để viết và bây giờ dường như không hoạt động vì nó đã bị hack.

Tiếp cận quản lý theo cách mà bạn cho thấy rằng bạn hiểu các tác động ngân sách khi thực hiện các thay đổi lớn đối với mã và các tác động ngân sách của việc KHÔNG thực hiện các thay đổi. Tôi thích từ ngữ của Emilio.

Điều quan trọng cần ghi nhớ mặc dù mã "cũ" sẽ luôn khủng khiếp. Ý tôi là, tất cả chúng ta đều phát triển như những nhà phát triển liên tục. Chúng tôi viết mã tốt, sau đó học cách viết mã tốt hơn sau đó và mã "tốt" trước đó có vẻ khủng khiếp. Quá nhiều nhà phát triển bị cuốn vào việc liên tục cố gắng làm cho nó tốt hơn và lãng phí nhiều tiền hơn trong thời gian dài. Đó là một hành động cân bằng. Điều đó đang được nói, nó luôn luôn tuyệt vời nếu bạn có thể làm cho nó tốt hơn khi bạn đi. Khi bạn đi sửa đổi chức năng khổng lồ đó, hãy tách nó ra! Cuối cùng, bạn sẽ nhận được một nơi nào đó.

Đừng làm điều đó.

Viết lại một dự án lớn từ đầu là một sai lầm lớn hầu hết mọi lúc.

Tôi chưa bao giờ nghĩ rằng thật dễ dàng để nói với các nhà quản lý, đặc biệt là Người quản lý dự án về mã xấu và tái cấu trúc. Đầu tiên, họ phải tin tưởng bạn, ngay cả khi bạn là đàn anh, bạn vẫn cần thời gian để được tin tưởng. Thứ hai, họ chỉ đơn giản là không hiểu vấn đề tồi tệ như thế nào. Nếu hôm nay là ngày cuối cùng để phát hành bản dựng mới và bản dựng bị lỗi. Họ biết nó nghiêm trọng như thế nào, nhưng họ không bao giờ biết việc xây dựng chỉ thất bại vì nhiều vấn đề như mã xấu, kiểm tra không đầy đủ, v.v.

Tôi đã hoàn thành các nhiệm vụ cấu hình và triển khai trong một dự án web. Thường mất nhiều thời gian để khắc phục các sự cố không mong muốn mỗi khi tôi triển khai bản dựng mới. Hầu hết các vấn đề là bảo mật và tích hợp (giữa một số ứng dụng web / Windows). Mã của chúng tôi hút, mã của người khác hút, họ hoàn toàn là mã spaghetti.

Chúng tôi đã lên kế hoạch cho một phiên bản mới và tôi đặc biệt yêu cầu một số cấu trúc lại, chỉ cần thêm nhật ký chi tiết vào mã đăng nhập / xác thực nơi xảy ra lỗi. Các nhà quản lý đã đồng ý, nhưng sau đó nó đã được đưa vào một danh sách dễ có và tôi không biết liệu nó có được thực hiện hay không vì chúng tôi đã có một danh sách lớn các tính năng và khung thời gian chặt chẽ.

Có hai loại người quản lý: những người giả vờ hiểu những gì bạn làm và những người không làm. Những người giả vờ hiểu phần mềm sẽ thù địch với bạn. Những người không chỉ đơn thuần là làm phiền bạn.

Trong mọi trường hợp, các nhà quản lý đều là những kẻ nói dối nên họ có khuynh hướng mạnh mẽ để cho rằng mọi người khác đều như vậy.

Quan điểm của tôi là, nếu bạn nói rằng phần mềm đã lỗi thời, họ sẽ chỉ lấy nó làm lý do. Họ không quan tâm.