Tôi hy vọng đây không phải là quá chung chung của một câu hỏi; Tôi thực sự có thể sử dụng một số lời khuyên dày dạn.

Tôi mới được tuyển dụng làm "Kỹ sư SW" duy nhất trong một cửa hàng khá nhỏ gồm các nhà khoa học đã dành 10-20 năm qua để cùng nhau xây dựng một cơ sở mã lớn. (Nó được viết bằng một ngôn ngữ gần như lỗi thời: G2 - nghĩ Pascal với đồ họa). Chương trình này là một mô hình vật lý của một nhà máy xử lý hóa chất phức tạp; nhóm đã viết nó có kiến ​​thức miền cực kỳ sâu sắc nhưng ít hoặc không được đào tạo chính thức về các nguyên tắc cơ bản lập trình. Gần đây họ đã học được một số bài học khó về hậu quả của quản lý cấu hình không tồn tại. Những nỗ lực bảo trì của họ cũng bị cản trở rất nhiều bởi sự tích lũy khổng lồ của "bùn" không có giấy tờ trong chính mã. Tôi sẽ dành cho bạn "chính trị" của tình huống ( luôn luôn có chính trị!), nhưng đủ để nói, không có sự đồng thuận về ý kiến ​​về những gì cần thiết cho con đường phía trước.

Họ đã yêu cầu tôi bắt đầu trình bày cho nhóm một số nguyên tắc phát triển phần mềm hiện đại. Họ muốn tôi giới thiệu một số thực tiễn và chiến lược theo tiêu chuẩn ngành về các quy ước mã hóa, quản lý vòng đời, các mẫu thiết kế cấp cao và kiểm soát nguồn. Thành thật mà nói, đó là một nhiệm vụ khá khó khăn và tôi không biết bắt đầu từ đâu.

Ban đầu, tôi có xu hướng dạy kèm cho họ trong một số khái niệm trung tâm của Lập trình viên thực dụng , hoặc Tái cấu trúc của Fowler ("Mùi mã", v.v.). Tôi cũng hy vọng sẽ giới thiệu một số phương pháp Agile. Nhưng cuối cùng, để có hiệu quả, tôi nghĩ rằng tôi sẽ cần phải trau dồi vào 5-7 nguyên tắc cơ bản cốt lõi; nói cách khác, các nguyên tắc hoặc thực tiễn quan trọng nhất mà họ có thể thực sự bắt đầu thực hiện sẽ mang lại cho họ nhiều "cú hích nhất".

Vì vậy, đó là câu hỏi của tôi: Điều gì sẽ bạn đưa vào danh sách của bạn trong những chiến lược hiệu quả nhất để giúp duỗi thẳng ra spaghetti (và ngăn chặn nó trong tương lai)?

Lời tựa

Đây thực sự là một nhiệm vụ khó khăn và có rất nhiều điều cần làm. Vì vậy, tôi khiêm tốn đề nghị đây là hướng dẫn toàn diện cho nhóm của bạn, với các gợi ý cho các công cụ và tài liệu giáo dục phù hợp.

Hãy nhớ rằng: Đây là những hướng dẫn , và như vậy có nghĩa là được thông qua, điều chỉnh hoặc loại bỏ dựa trên hoàn cảnh.

Coi chừng: Bỏ tất cả những thứ này vào một đội rất có thể sẽ thất bại. Bạn nên cố gắng chọn các yếu tố anh đào sẽ mang lại cho bạn những giọt mồ hôi tốt nhất, và giới thiệu chúng từ từ, từng cái một.

Lưu ý: không phải tất cả điều này áp dụng trực tiếp cho Hệ thống lập trình trực quan như G2. Để biết thêm chi tiết cụ thể về cách giải quyết những vấn đề này, hãy xem phần Phụ lục ở cuối.

Tóm tắt điều hành cho người thiếu kiên nhẫn

• Xác định cấu trúc dự án cứng nhắc , với:
  • mẫu dự án ,
  • công ước mã hóa ,
  • hệ thống xây dựng quen thuộc ,
  • và bộ hướng dẫn sử dụng cho cơ sở hạ tầng và công cụ của bạn.
• Cài đặt một SCM tốt và đảm bảo họ biết cách sử dụng nó.
• Hướng chúng đến các IDE tốt cho công nghệ của chúng và đảm bảo chúng biết cách sử dụng chúng.
• Thực hiện kiểm tra chất lượng mã và báo cáo tự động trong hệ thống xây dựng.
• Kết hợp hệ thống xây dựng để tích hợp liên tục và hệ thống kiểm tra liên tục .
• Với sự giúp đỡ của ở trên, xác định "điểm nóng" chất lượng mã và cấu trúc lại .

Bây giờ cho phiên bản dài ... Chú ý, hãy cố gắng lên!

Độ cứng là (Thường) Tốt

Đây là một ý kiến ​​gây tranh cãi, vì sự cứng nhắc thường được xem là một lực lượng chống lại bạn. Điều đó đúng với một số giai đoạn của một số dự án. Nhưng một khi bạn thấy nó là một hỗ trợ cấu trúc, một khung làm mất đi sự phỏng đoán, nó sẽ giảm đáng kể thời gian và công sức lãng phí. Làm cho nó hoạt động cho bạn, không chống lại bạn.

Độ cứng = Quy trình / Thủ tục .

Phát triển phần mềm cần có quy trình và quy trình tốt vì những lý do chính xác giống như các nhà máy hoặc nhà máy hóa chất có hướng dẫn sử dụng, quy trình, diễn tập và hướng dẫn khẩn cấp: ngăn chặn kết quả xấu, tăng khả năng dự đoán, tối đa hóa năng suất ...

Sự cứng nhắc đến trong chừng mực!

Độ cứng của cấu trúc dự án

Nếu mỗi dự án đi kèm với cấu trúc riêng, bạn (và người mới) sẽ bị mất và cần phải nhận lại từ đầu mỗi khi bạn mở chúng. Bạn không muốn điều này trong một cửa hàng phần mềm chuyên nghiệp và bạn cũng không muốn điều này trong phòng thí nghiệm.

Độ cứng của hệ thống xây dựng

Nếu mỗi dự án trông khác nhau, có một cơ hội tốt họ cũng sẽ xây dựng khác nhau . Một bản dựng không cần quá nhiều nghiên cứu hoặc quá nhiều phỏng đoán. Bạn muốn có thể làm điều kinh điển và không cần phải lo lắng về chi tiết cụ thể: configure; make install, ant, mvn install, vv ...

Sử dụng lại cùng một hệ thống xây dựng và làm cho nó phát triển theo thời gian cũng đảm bảo mức chất lượng nhất quán.

Bạn cần nhanh chóng READMEchỉ ra các chi tiết cụ thể của dự án và duyên dáng hướng dẫn người dùng / nhà phát triển / nhà nghiên cứu, nếu có.

Điều này cũng hỗ trợ rất nhiều cho các phần khác trong cơ sở hạ tầng xây dựng của bạn, cụ thể là:

• tích hợp liên tục ,
• kiểm tra liên tục .

Vì vậy, hãy luôn cập nhật bản dựng (như dự án của bạn), nhưng làm cho nó chặt chẽ hơn theo thời gian và hiệu quả hơn trong việc báo cáo các vi phạm và thực tiễn xấu.

Không phát minh lại bánh xe, và sử dụng lại những gì bạn đã làm.

Đề nghị đọc:

• Tích hợp liên tục: Cải thiện chất lượng phần mềm và giảm rủi ro (Duval, Matyas, Glover, 2007)
• Phân phối liên tục: Phát hành Sotware phát hành thông qua xây dựng, thử nghiệm và tự động triển khai (Humble, Farley, 2010)

Sự cứng nhắc trong lựa chọn ngôn ngữ lập trình

Bạn không thể mong đợi, đặc biệt là trong môi trường nghiên cứu, có tất cả các nhóm (và thậm chí ít hơn tất cả các nhà phát triển) sử dụng cùng một ngôn ngữ và công nghệ. Tuy nhiên, bạn có thể xác định một bộ công cụ "được hỗ trợ chính thức" và khuyến khích sử dụng chúng. Phần còn lại, không có lý do chính đáng, không nên được cho phép (ngoài nguyên mẫu).

Giữ cho ngăn xếp công nghệ của bạn đơn giản, và duy trì và mở rộng các kỹ năng cần thiết đến mức tối thiểu: một lõi mạnh.

Độ cứng của các quy ước và hướng dẫn mã hóa

Các quy ước và hướng dẫn mã hóa là những gì cho phép bạn phát triển cả danh tính với tư cách là một nhóm và một biệt ngữ chung . Bạn không muốn mắc lỗi vào terra incognita mỗi khi bạn mở tệp nguồn.

Các quy tắc vô nghĩa làm cho cuộc sống trở nên khó khăn hơn hoặc cấm các hành động tự do đến mức các cam kết bị từ chối dựa trên các vi phạm đơn giản là một gánh nặng. Tuy nhiên:

• một quy tắc nền tảng được suy nghĩ kỹ càng lấy đi rất nhiều lời than vãn và suy nghĩ: không ai nên phá vỡ trong mọi trường hợp;

• và một bộ quy tắc được đề nghị cung cấp hướng dẫn bổ sung.

Cách tiếp cận cá nhân: Tôi rất tích cực khi nói đến các quy ước về mã hóa, một số người thậm chí còn nói nazi , vì tôi tin vào việc có một ngôn ngữ chung , một phong cách dễ nhận biết cho nhóm của tôi. Khi mã tào lao được đăng ký, nó nổi bật như một vết loét lạnh lẽo trên khuôn mặt của một ngôi sao Hollywood: nó tự động kích hoạt đánh giá và hành động. Trên thực tế, đôi khi tôi đã đi xa tới mức ủng hộ việc sử dụng các móc nối trước để từ chối các cam kết không tuân thủ. Như đã đề cập, nó không nên quá điên rồ và cản trở năng suất: nó sẽ thúc đẩy nó. Giới thiệu những điều này từ từ, đặc biệt là vào lúc bắt đầu. Nhưng cách tốt hơn là dành quá nhiều thời gian để sửa mã bị lỗi mà bạn không thể làm việc với các vấn đề thực sự.

Một số ngôn ngữ thậm chí thực thi điều này theo thiết kế:

• Java có nghĩa là để giảm số lượng crap buồn tẻ mà bạn có thể viết với nó (mặc dù không có nghi ngờ gì nhiều người quản lý để làm điều đó).

• Cấu trúc khối của Python bằng cách thụt lề là một ý tưởng khác theo nghĩa này.

• Đi, với gofmtcông cụ của nó , nó hoàn toàn lấy đi mọi tranh luận và nỗ lực ( và bản ngã !! ) vốn có của phong cách: chạy gofmttrước khi bạn cam kết.

Hãy chắc chắn rằng mã thối không thể trượt qua. Các quy ước mã , tích hợp liên tục và kiểm tra liên tục , lập trình cặp và đánh giá mã là kho vũ khí của bạn chống lại con quỷ này.

Ngoài ra, như bạn sẽ thấy bên dưới, mã là tài liệu và đó là một lĩnh vực khác, nơi các quy ước khuyến khích tính dễ đọc và rõ ràng.

Độ cứng của tài liệu

Tài liệu đi đôi với mã. Mã chính nó là tài liệu. Nhưng phải có hướng dẫn rõ ràng về cách xây dựng, sử dụng và bảo trì mọi thứ.

Sử dụng một điểm kiểm soát duy nhất cho tài liệu (như WikiWiki hoặc DMS) là một điều tốt. Tạo không gian cho các dự án, không gian cho các thử nghiệm và thử nghiệm ngẫu nhiên hơn. Có tất cả các không gian sử dụng lại các quy tắc và quy ước chung. Hãy cố gắng làm cho nó một phần của tinh thần đồng đội.

Hầu hết các lời khuyên áp dụng cho mã và công cụ cũng áp dụng cho tài liệu.

Độ cứng trong nhận xét mã

Mã ý kiến, như đã đề cập ở trên, cũng là tài liệu. Các nhà phát triển muốn bày tỏ cảm xúc của họ về mã của họ (chủ yếu là niềm tự hào và sự thất vọng, nếu bạn hỏi tôi). Vì vậy, không có gì lạ khi họ thể hiện những điều này không có ý nghĩa không chắc chắn trong các bình luận (hoặc thậm chí mã), khi một đoạn văn bản trang trọng hơn có thể truyền đạt ý nghĩa tương tự với ít nội dung hoặc kịch tính hơn. Bạn có thể bỏ qua một vài lý do vui vẻ và lịch sử: đó cũng là một phần của việc phát triển văn hóa đội nhóm . Nhưng điều rất quan trọng là mọi người đều biết điều gì có thể chấp nhận và điều gì không, và tiếng ồn bình luận đó chỉ là: tiếng ồn .

Độ cứng trong Nhật ký Cam kết

Nhật ký cam kết không phải là một "bước" khó chịu và vô dụng trong vòng đời SCM của bạn: bạn KHÔNG bỏ qua nó để về nhà đúng giờ hoặc tiếp tục với nhiệm vụ tiếp theo hoặc để bắt kịp những người bạn đã rời đi ăn trưa. Họ quan trọng, và, giống như (hầu hết) rượu vang tốt, thời gian trôi qua càng có giá trị. Vì vậy, làm cho họ đúng. Tôi lúng túng khi thấy đồng nghiệp viết một tấm lót cho những cam kết khổng lồ, hoặc cho những vụ hack không rõ ràng.

Các cam kết được thực hiện vì một lý do và lý do đó không phải luôn được thể hiện rõ ràng bằng mã của bạn và một dòng nhật ký cam kết bạn đã nhập. Có nhiều hơn thế.

Mỗi dòng mã có một câu chuyện và một lịch sử . Các khác biệt có thể nói lịch sử của nó, nhưng bạn phải viết câu chuyện của nó.

Tại sao tôi cập nhật dòng này? -> Vì giao diện thay đổi.

Tại sao giao diện thay đổi? -> Vì thư viện L1 xác định nó đã được cập nhật.

Tại sao thư viện được cập nhật? -> Vì thư viện L2, chúng tôi cần tính năng F, phụ thuộc vào thư viện L1.

Và tính năng X là gì? -> Xem tác vụ 3456 trong trình theo dõi vấn đề.

Đó không phải là lựa chọn SCM của tôi và cũng có thể không phải là lựa chọn tốt nhất cho phòng thí nghiệm của bạn; nhưng Gitcó quyền này và cố gắng buộc bạn viết nhật ký tốt hơn hầu hết các hệ thống SCM khác, bằng cách sử dụng short logsvà long logs. Liên kết ID nhiệm vụ (có, bạn cần một) và để lại một bản tóm tắt chung cho shortlogvà mở rộng trong nhật ký dài: viết câu chuyện của bộ thay đổi .

Đây là nhật ký: Đây là để theo dõi và ghi lại các cập nhật.

Nguyên tắc chung: Nếu bạn đang tìm kiếm điều gì đó về thay đổi này sau đó, nhật ký của bạn có khả năng trả lời câu hỏi của bạn không?

Dự án, Tài liệu và Mã là SỐNG

Giữ chúng đồng bộ, nếu không chúng không hình thành thực thể cộng sinh đó nữa. Nó hoạt động kỳ diệu khi bạn có:

• xóa các bản ghi trong SCM của bạn, w / liên kết đến ID nhiệm vụ trong trình theo dõi vấn đề của bạn,
• trong đó vé của trình theo dõi này tự liên kết với các thay đổi trong SCM của bạn (và có thể với các bản dựng trong hệ thống CI của bạn),
• và một hệ thống tài liệu liên kết đến tất cả những thứ này.

Mã và tài liệu cần phải được gắn kết .

Độ cứng trong kiểm tra

Quy tắc của ngón tay cái:

• Bất kỳ mã mới nào cũng sẽ đi kèm với (ít nhất) các bài kiểm tra đơn vị.
• Bất kỳ mã kế thừa được tái cấu trúc sẽ đi kèm với các bài kiểm tra đơn vị.

Tất nhiên, những nhu cầu này:

• để thực sự kiểm tra một cái gì đó có giá trị (hoặc chúng là một sự lãng phí thời gian và năng lượng),
• được viết và nhận xét tốt (giống như bất kỳ mã nào khác mà bạn đăng ký).

Chúng cũng là tài liệu và chúng giúp phác thảo hợp đồng mã của bạn. Đặc biệt nếu bạn sử dụng TDD . Ngay cả khi bạn không, bạn cần chúng để bạn yên tâm. Chúng là mạng lưới an toàn của bạn khi bạn kết hợp mã mới (bảo trì hoặc tính năng) và tháp canh của bạn để bảo vệ chống lại sự thối mã và các lỗi môi trường.

Tất nhiên, bạn nên đi xa hơn và có các bài kiểm tra tích hợp và kiểm tra hồi quy cho từng lỗi có thể lặp lại mà bạn sửa.

Độ cứng trong việc sử dụng các công cụ

Nhà phát triển / nhà khoa học không thường xuyên muốn thử một số trình kiểm tra tĩnh mới trên nguồn, tạo biểu đồ hoặc mô hình bằng cách sử dụng khác hoặc triển khai mô-đun mới bằng DSL. Nhưng tốt nhất là nếu có một bộ công cụ kinh điển mà tất cả các thành viên trong nhóm dự kiến ​​sẽ biết và sử dụng.

Ngoài ra, hãy để các thành viên sử dụng những gì họ muốn, miễn là họ TẤT CẢ:

• năng suất cao ,
• KHÔNG thường xuyên cần hỗ trợ
• KHÔNG thường xuyên điều chỉnh cơ sở hạ tầng chung của bạn ,
• KHÔNG làm gián đoạn cơ sở hạ tầng của bạn (bằng cách sửa đổi các khu vực phổ biến như mã, xây dựng hệ thống, tài liệu ...),
• KHÔNG ảnh hưởng đến công việc của người khác ,
• ABLE để thực hiện kịp thời bất kỳ nhiệm vụ yêu cầu .

Nếu đó không phải là trường hợp, sau đó thực thi rằng họ dự phòng mặc định.

Độ cứng so với tính linh hoạt, khả năng thích ứng, tạo mẫu và trường hợp khẩn cấp

Linh hoạt có thể là tốt. Để ai đó thỉnh thoảng sử dụng hack, cách tiếp cận nhanh chóng hoặc công cụ thú cưng yêu thích để hoàn thành công việc là ổn. KHÔNG BAO GIỜ để nó trở thành thói quen và KHÔNG BAO GIỜ để mã này trở thành cơ sở mã thực tế để hỗ trợ.

Các vấn đề về tinh thần đồng đội

Phát triển cảm giác tự hào về Codebase của bạn

• Phát triển ý thức về niềm kiêu hãnh trong mã
  • Sử dụng bảng
    • ban lãnh đạo cho một trò chơi tích hợp liên tục
    • bảng để quản lý vấn đề và đếm khuyết tật
  • Sử dụng trình theo dõi vấn đề / theo dõi lỗi

Tránh các trò chơi đổ lỗi

• NÊN sử dụng các trò chơi Tích hợp liên tục / Kiểm tra liên tục: nó thúc đẩy cạnh tranh hiệu quả và hiệu quả .
• KHÔNG theo dõi các khiếm khuyết: đó chỉ là giữ nhà tốt.
• NÊN xác định nguyên nhân gốc rễ : đó chỉ là quá trình chứng minh trong tương lai.
• NHƯNG KHÔNG gán trách nhiệm : nó phản tác dụng.

Đó là về quy tắc, không phải về các nhà phát triển

Làm cho các nhà phát triển nhận thức được chất lượng mã của họ, NHƯNG làm cho họ thấy mã là một thực thể tách rời và không phải là một phần mở rộng của chính họ, không thể bị chỉ trích.

Đó là một nghịch lý: bạn cần khuyến khích lập trình ít bản ngã cho một nơi làm việc lành mạnh nhưng phải dựa vào bản ngã cho mục đích tạo động lực.

Từ nhà khoa học đến lập trình viên

Những người không coi trọng và tự hào về mã không tạo ra mã tốt. Để tài sản này xuất hiện, họ cần khám phá xem nó có giá trị và thú vị như thế nào. Chuyên nghiệp tuyệt vời và mong muốn làm điều tốt là chưa đủ: nó cần đam mê. Vì vậy, bạn cần phải biến các nhà khoa học của mình thành lập trình viên (theo nghĩa rộng).

Có người tranh luận trong các ý kiến ​​rằng sau 10 đến 20 năm về một dự án và mã của nó, bất kỳ ai cũng sẽ cảm thấy gắn bó. Có thể tôi sai nhưng tôi cho rằng họ tự hào về kết quả của mã và về công việc cũng như di sản của nó, chứ không phải về bản thân mã hoặc về hành động viết mã.

Từ kinh nghiệm, hầu hết các nhà nghiên cứu coi tiền mã hóa là một điều cần thiết, hoặc tốt nhất là một sự phân tâm thú vị. Họ chỉ muốn nó hoạt động. Những người đã khá thành thạo về nó và có hứng thú với lập trình dễ dàng hơn rất nhiều để thuyết phục việc áp dụng các thực tiễn tốt nhất và công nghệ chuyển đổi. Bạn cần phải có được một nửa ở đó.

Bảo trì mã là một phần của công việc nghiên cứu

Không ai đọc tài liệu nghiên cứu crappy. Đó là lý do tại sao chúng được đánh giá ngang hàng, đọc bằng chứng, tinh chỉnh, viết lại và được phê duyệt hết lần này đến lần khác cho đến khi được coi là sẵn sàng để xuất bản. Điều tương tự cũng áp dụng cho một luận án và một cơ sở mã!

Làm rõ rằng việc tái cấu trúc và làm mới liên tục một cơ sở mã sẽ ngăn ngừa sự thối mã và giảm nợ kỹ thuật, và tạo điều kiện cho việc tái sử dụng và điều chỉnh công việc trong tương lai cho các dự án khác.

Tại sao những thứ này??!

Tại sao chúng ta bận tâm với tất cả những điều trên? Đối với chất lượng mã . Hay đó là mã chất lượng ...?

Những hướng dẫn này nhằm mục đích thúc đẩy nhóm của bạn hướng tới mục tiêu này. Một số khía cạnh làm điều đó bằng cách đơn giản chỉ cho họ cách và để họ làm điều đó (tốt hơn nhiều) và những người khác nắm lấy chúng (nhưng đó là cách bạn giáo dục mọi người và phát triển thói quen).

Làm thế nào để bạn biết khi nào mục tiêu là trong tầm tay?

Chất lượng là đo lường được

Không phải luôn luôn định lượng, nhưng nó có thể đo lường được . Như đã đề cập, bạn cần phát triển cảm giác tự hào về đội của mình, và cho thấy sự tiến bộ và kết quả tốt là chìa khóa. Đo lường chất lượng mã thường xuyên và hiển thị tiến trình giữa các khoảng thời gian và cách nó quan trọng. Hãy nhìn lại để suy nghĩ về những gì đã được thực hiện, và làm thế nào nó làm cho mọi thứ tốt hơn hoặc tồi tệ hơn.

Có những công cụ tuyệt vời để kiểm tra liên tục . Sonar là một thứ phổ biến trong thế giới Java, nhưng nó có thể thích nghi với mọi công nghệ; và có nhiều người khác Giữ mã của bạn dưới kính hiển vi và tìm kiếm các lỗi và vi khuẩn gây phiền nhiễu.

Nhưng nếu Mã của tôi đã tào lao thì sao?

Tất cả những điều trên đều thú vị và dễ thương như một chuyến đi đến Never Land, nhưng điều đó không dễ thực hiện khi bạn đã có (một đống mã ướt át và có mùi) và một đội không muốn thay đổi.

Đây là bí mật: bạn cần bắt đầu ở đâu đó .

Giai thoại cá nhân: Trong một dự án, chúng tôi đã làm việc với một cơ sở mã có trọng lượng ban đầu là 650.000+ Java LỘC, hơn 200.000 dòng JSP, 40.000+ JavaScript LỘC và hơn 400 MB phụ thuộc nhị phân.

Sau khoảng 18 tháng, đó là 500.000 LỘC Java (SẠCH NHẤT) , 150.000 dòng JSP và 38.000 JavaScript LỘC, với sự phụ thuộc xuống chỉ còn 100 MB (và những thứ này không còn trong SCM của chúng tôi nữa!).

chúng tôi đã làm nó như thế nào? Chúng tôi chỉ làm tất cả những điều trên. Hay cố gắng hết sức.

Đó là một nỗ lực của nhóm, nhưng chúng tôi chậm tiêm trong quy trình và các công cụ của chúng tôi để theo dõi nhịp tim của sản phẩm của chúng tôi, trong khi vội vàng cắt giảm đi những "chất béo": Mã tào lao, phụ thuộc vô dụng ... Chúng tôi đã không ngừng phát triển để tất cả làm điều này: đôi khi chúng ta có những khoảng thời gian hòa bình và yên tĩnh tương đối, nơi chúng ta có thể tự do phát điên trên cơ sở mã hóa và xé nó ra, nhưng hầu hết thời gian chúng ta làm tất cả bằng cách mặc định ở chế độ "xem lại và tái cấu trúc" mỗi khi chúng ta có được : trong quá trình xây dựng, trong bữa trưa, trong khi chạy nước rút sửa lỗi, vào các buổi chiều thứ Sáu ...

Có một số "công trình" lớn ... Chuyển đổi hệ thống xây dựng của chúng tôi từ một bản dựng Ant khổng lồ của 8500+ XML LỘC sang bản dựng Maven đa mô-đun là một trong số đó. Sau đó chúng tôi đã có:

• các mô-đun rõ ràng (hoặc ít nhất là nó đã tốt hơn rất nhiều và chúng tôi vẫn có kế hoạch lớn cho tương lai),
• quản lý phụ thuộc tự động (để bảo trì và cập nhật dễ dàng và để loại bỏ các dep vô dụng),
• bản dựng nhanh hơn, dễ dàng hơn và có thể tái tạo,
• báo cáo hàng ngày về chất lượng.

Một cách khác là tiêm "đai công cụ tiện ích", mặc dù chúng tôi đã cố gắng giảm sự phụ thuộc: Google Guava và Apache Commons làm giảm mã của bạn và giảm bề mặt cho các lỗi trong mã của bạn rất nhiều.

Chúng tôi cũng thuyết phục bộ phận CNTT của mình rằng có thể sử dụng các công cụ mới của chúng tôi (JIRA, Fisheye, Crucible, Confluence, Jenkins) tốt hơn các công cụ tại chỗ. Chúng tôi vẫn cần phải đối phó với một số người mà chúng tôi coi thường (QC, Sharepoint và SupportWorks ...), nhưng đó là một trải nghiệm được cải thiện tổng thể, với một số chỗ còn lại.

Và mỗi ngày, giờ đây có một mánh khóe từ một đến hàng chục cam kết chỉ liên quan đến sửa chữa và tái cấu trúc mọi thứ. Thỉnh thoảng chúng tôi phá vỡ mọi thứ (bạn cần kiểm tra đơn vị, và tốt hơn là bạn nên viết chúng trước khi bạn tái cấu trúc lại công cụ), nhưng nói chung, lợi ích cho tinh thần VÀ cho sản phẩm của chúng tôi là rất lớn. Chúng tôi nhận được một phần trăm phần trăm chất lượng mã tại một thời điểm. Và thật vui khi thấy nó tăng lên !!!

Lưu ý: Một lần nữa, sự cứng nhắc cần phải được lắc để nhường chỗ cho những điều mới và tốt hơn. Trong giai thoại của tôi, bộ phận CNTT của chúng tôi có phần đúng khi cố gắng áp đặt một số điều lên chúng tôi và sai cho những người khác. Hoặc có thể họ đã từng đúng . Nhiều thứ thay đổi. Chứng minh rằng chúng là những cách tốt hơn để tăng năng suất của bạn. Chạy thử và nguyên mẫu là ở đây cho điều này.

Chu trình tái cấu trúc mã Spaghetti siêu bí mật cho chất lượng tuyệt vời

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

Khi bạn có một số công cụ chất lượng tại toolbelt của mình:

1. Phân tích mã của bạn với kiểm tra chất lượng mã.

   Linters, phân tích tĩnh, hoặc những gì có bạn.

2. Xác định các điểm nóng quan trọng của bạn VÀ trái cây treo thấp .

   Vi phạm có mức độ nghiêm trọng và các lớp lớn với số lượng lớn mức độ nghiêm trọng cao là một lá cờ đỏ lớn: như vậy, chúng xuất hiện dưới dạng "điểm nóng" trên các kiểu xem của bộ tản nhiệt / bản đồ nhiệt.

3. Sửa các điểm nóng trước.

   Nó tối đa hóa tác động của bạn trong một khung thời gian ngắn vì chúng có giá trị kinh doanh cao nhất. Lý tưởng nhất là các vi phạm nghiêm trọng nên được xử lý ngay khi chúng xuất hiện, vì chúng là các lỗ hổng bảo mật tiềm ẩn hoặc nguyên nhân sự cố và có nguy cơ cao gây ra trách nhiệm pháp lý (và trong trường hợp của bạn, hiệu suất kém cho phòng thí nghiệm).

4. Làm sạch các vi phạm cấp thấp bằng quét cơ sở mã hóa tự động .

   Nó cải thiện tỷ lệ tín hiệu trên tạp âm để bạn có thể thấy các vi phạm đáng kể trên radar của bạn khi chúng xuất hiện. Ban đầu thường có một đội quân vi phạm nhỏ nếu chúng không bao giờ được chăm sóc và cơ sở mã của bạn bị bỏ rơi trong tự nhiên. Chúng không có "rủi ro" thực sự, nhưng chúng làm giảm khả năng đọc và bảo trì của mã. Khắc phục chúng khi bạn gặp chúng trong khi thực hiện một nhiệm vụ hoặc bằng các nhiệm vụ dọn dẹp lớn với quét mã tự động nếu có thể. Hãy cẩn thận với quét tự động lớn nếu bạn không có bộ kiểm tra và hệ thống tích hợp tốt. Đảm bảo đồng ý với đồng nghiệp đúng thời điểm để điều hành họ để giảm thiểu sự khó chịu.

5. Lặp lại cho đến khi bạn hài lòng.

   Mà, lý tưởng nhất, bạn không bao giờ nên, nếu đây vẫn là một sản phẩm hoạt động: nó sẽ tiếp tục phát triển.

Mẹo nhanh để giữ nhà tốt

• Khi ở chế độ hotfix , dựa trên yêu cầu hỗ trợ khách hàng:

  • Đó thường là cách tốt nhất để KHÔNG đi khắc phục các vấn đề khác, vì bạn có thể giới thiệu những vấn đề mới một cách miễn cưỡng.
  • Đi theo nó theo kiểu SEAL: vào trong, tiêu diệt bọ, thoát ra và vận chuyển bản vá của bạn. Đó là một cuộc tấn công phẫu thuật và chiến thuật.

• Nhưng đối với tất cả các trường hợp khác , nếu bạn mở một tệp, hãy đặt nó là nhiệm vụ của bạn:

  • chắc chắn: xem lại nó (ghi chú, báo cáo vấn đề tập tin),
  • có thể: làm sạch nó (dọn dẹp kiểu và vi phạm nhỏ),
  • lý tưởng: tái cấu trúc nó (tổ chức lại các phần lớn và neig Harbor của họ).

Chỉ cần không bị lãng phí khi dành một tuần từ tệp này sang tệp khác và kết thúc với một loạt thay đổi lớn của hàng ngàn bản sửa lỗi bao gồm nhiều tính năng và mô-đun - điều này khiến việc theo dõi trong tương lai trở nên khó khăn. Một vấn đề trong mã = ​​một vé trong trình theo dõi của bạn. Đôi khi, một bộ thay đổi có thể tác động đến nhiều vé; Nhưng nếu nó xảy ra quá thường xuyên, thì có lẽ bạn đã làm sai điều gì đó.

Phụ lục: Quản lý môi trường lập trình trực quan

Vườn treo tường của hệ thống lập trình Bespoke

Nhiều hệ thống lập trình, như G2 của OP, là những quái thú khác nhau ...

• Không có "Mã"

  Thường thì họ không cấp cho bạn quyền truy cập vào biểu diễn văn bản của "mã" nguồn của bạn: nó có thể được lưu trữ ở định dạng nhị phân độc quyền hoặc có thể nó lưu trữ mọi thứ ở định dạng văn bản nhưng giấu chúng khỏi bạn. Các hệ thống lập trình đồ họa Bespoke thực sự không phải là hiếm trong các phòng thí nghiệm nghiên cứu, vì chúng đơn giản hóa việc tự động hóa các quy trình xử lý dữ liệu lặp đi lặp lại.

• Không dụng cụ

  Bên cạnh của họ, đó là. Bạn thường bị hạn chế bởi môi trường lập trình của họ, trình gỡ lỗi của riêng họ, trình thông dịch riêng của họ, các công cụ và định dạng tài liệu của riêng họ. Chúng là những khu vườn có tường bao quanh , ngoại trừ nếu cuối cùng chúng thu hút được sự quan tâm của ai đó đủ động lực để đảo ngược các định dạng của chúng và xây dựng các công cụ bên ngoài - nếu giấy phép cho phép.

• Thiếu tài liệu

  Rất thường xuyên, đây là những hệ thống lập trình thích hợp, được sử dụng trong môi trường khá kín. Những người sử dụng chúng thường xuyên ký NDA và không bao giờ nói về những gì họ làm. Cộng đồng lập trình cho họ rất hiếm. Vì vậy, nguồn lực đang khan hiếm. Bạn đang bị mắc kẹt với tài liệu tham khảo chính thức của bạn, và đó là nó.

Điều mỉa mai (và thường làm nản lòng) là tất cả những điều mà các hệ thống này làm rõ ràng có thể đạt được bằng cách sử dụng các ngôn ngữ lập trình chính thống và mục đích chung, và có lẽ hiệu quả hơn. Nhưng nó đòi hỏi kiến ​​thức sâu hơn về lập trình, trong khi bạn không thể mong đợi nhà sinh vật học, nhà hóa học hoặc nhà vật lý của mình (kể tên một vài người) biết đủ về lập trình, và thậm chí ít có thời gian (và mong muốn) để thực hiện (và duy trì) hệ thống phức tạp, có thể tồn tại hoặc không tồn tại lâu. Vì lý do tương tự, chúng tôi sử dụng DSL, chúng tôi có các hệ thống lập trình bespoke này.

Giai thoại cá nhân 2:Trên thực tế, tôi đã làm việc trên một trong những bản thân mình. Tôi đã không liên kết với yêu cầu của OP, nhưng dự án của tôi là một bộ phần mềm xử lý dữ liệu và lưu trữ dữ liệu lớn được kết nối với nhau (chủ yếu dành cho nghiên cứu tin học sinh học, chăm sóc sức khỏe và mỹ phẩm, mà còn dành cho doanh nghiệp thông minh, hoặc bất kỳ miền nào ngụ ý theo dõi khối lượng lớn dữ liệu nghiên cứu dưới bất kỳ hình thức nào và chuẩn bị quy trình xử lý dữ liệu và ETLs). Một trong những ứng dụng này, khá đơn giản, là một IDE trực quan sử dụng chuông và còi thông thường: giao diện kéo và thả, không gian làm việc của dự án được phiên bản (sử dụng tệp văn bản và tệp XML để lưu trữ siêu dữ liệu), rất nhiều trình điều khiển có thể cắm vào nguồn dữ liệu không đồng nhất và trực quan canvas để thiết kế các đường ống để xử lý dữ liệu từ N nguồn dữ liệu và cuối cùng tạo ra các đầu ra được chuyển đổi M, và có thể trực quan hóa sáng bóng và báo cáo trực tuyến phức tạp (và tương tác). Hệ thống lập trình trực quan bespoke điển hình của bạn, mắc một chút hội chứng NIH dưới sự giả vờ thiết kế một hệ thống phù hợp với nhu cầu của người dùng.

Và, như bạn mong đợi, đó là một hệ thống đẹp, khá linh hoạt cho nhu cầu của nó mặc dù đôi khi hơi quá mức để bạn tự hỏi "tại sao không sử dụng các công cụ dòng lệnh thay thế?", Và không may luôn dẫn đầu ở quy mô trung bình các nhóm làm việc trong các dự án lớn cho nhiều người khác nhau sử dụng nó với các thực tiễn "tốt nhất" khác nhau.

Tuyệt vời, chúng tôi đã bị lúng túng! - Chúng ta làm gì về nó?

Vâng, cuối cùng, tất cả các bên trên vẫn giữ. Nếu bạn không thể trích xuất hầu hết các chương trình từ hệ thống này để sử dụng các công cụ và ngôn ngữ chính hơn, bạn "chỉ cần" điều chỉnh nó theo các ràng buộc của hệ thống.

Về phiên bản và lưu trữ

Cuối cùng, bạn hầu như luôn có thể phiên bản mọi thứ, ngay cả với môi trường bị ràng buộc và có tường nhất. Thường xuyên hơn không, các hệ thống này vẫn đi kèm với phiên bản riêng của chúng (điều không may thường khá cơ bản và chỉ cung cấp để trở lại các phiên bản trước mà không có nhiều khả năng hiển thị, chỉ giữ các ảnh chụp nhanh trước đó). Nó không chính xác bằng cách sử dụng các thay đổi khác biệt như SCM của bạn có thể và có thể không phù hợp với nhiều người dùng gửi thay đổi cùng một lúc.

Tuy nhiên, nếu họ cung cấp chức năng như vậy, có lẽ giải pháp của bạn là tuân theo các hướng dẫn tiêu chuẩn công nghiệp yêu thích của chúng tôi ở trên và chuyển chúng sang hệ thống lập trình này !!

Nếu hệ thống lưu trữ là một cơ sở dữ liệu, nó có thể hiển thị các chức năng xuất hoặc có thể được sao lưu ở cấp hệ thống tệp. Nếu nó sử dụng định dạng nhị phân tùy chỉnh, có thể bạn chỉ cần thử phiên bản nó với một VCS có hỗ trợ tốt cho dữ liệu nhị phân. Bạn sẽ không có quyền kiểm soát chi tiết, nhưng ít nhất bạn sẽ có phần lưng được bảo vệ chống lại thảm họa và có một mức độ tuân thủ khắc phục thảm họa nhất định.

Về kiểm tra

Thực hiện các thử nghiệm của bạn trong chính nền tảng và sử dụng các công cụ bên ngoài và công việc nền để thiết lập sao lưu thường xuyên. Rất có thể, bạn kích hoạt các thử nghiệm này giống như bạn sẽ kích hoạt các chương trình được phát triển với hệ thống lập trình này.

Chắc chắn, đó là một công việc hack và chắc chắn không theo tiêu chuẩn phổ biến cho lập trình "bình thường", nhưng ý tưởng là thích nghi với hệ thống trong khi cố gắng duy trì một quy trình phát triển phần mềm chuyên nghiệp.

Con đường dài và dốc ...

Như mọi khi với môi trường thích hợp và các hệ thống lập trình bespoke, và như chúng tôi đã trình bày ở trên, bạn xử lý các định dạng lạ, chỉ một bộ hạn chế (hoặc hoàn toàn không tồn tại) của các công cụ có thể cồng kềnh và thay thế cho cộng đồng.

Khuyến nghị: Cố gắng thực hiện các hướng dẫn bên ngoài bên ngoài hệ thống lập trình bespoke của bạn, càng nhiều càng tốt. Điều này đảm bảo rằng bạn có thể dựa vào các công cụ "phổ biến", có hỗ trợ cộng đồng và ổ đĩa cộng đồng phù hợp.

Giải pháp thay thế: Khi đây không phải là một tùy chọn, hãy thử trang bị thêm khung toàn cầu này vào "hộp" của bạn. Ý tưởng là phủ lớp kế hoạch chi tiết này của các thực tiễn tốt nhất theo tiêu chuẩn công nghiệp lên trên hệ thống lập trình của bạn và tận dụng tốt nhất nó. Lời khuyên vẫn được áp dụng: xác định cấu trúc và thực tiễn tốt nhất, khuyến khích sự phù hợp.

Thật không may, điều này ngụ ý rằng bạn có thể cần phải lao vào và thực hiện một số lượng lớn công việc chân. Vì thế...

Những từ cuối cùng nổi tiếng và những yêu cầu khiêm tốn:

• Tài liệu mọi thứ bạn làm.
• Chia sẻ kinh nghiệm của bạn.
• Nguồn mở bất kỳ công cụ nào bạn viết.

Bằng cách làm tất cả những điều này, bạn sẽ:

• không chỉ tăng cơ hội nhận được sự hỗ trợ từ mọi người trong những tình huống tương tự,
• nhưng cũng cung cấp trợ giúp cho những người khác và thúc đẩy thảo luận xung quanh công nghệ của bạn.

Ai biết được, bạn có thể vào đầu rất của một cộng đồng sôi động mới của Obscure Ngôn ngữ X . Nếu không có, bắt đầu một!

• Đặt câu hỏi về Stack Overflow ,
• Thậm chí có thể viết một đề xuất cho một trang web StackExchange mới trong Khu vực 51 .

Có thể bên trong nó rất đẹp , nhưng không ai có đầu mối cho đến nay, vì vậy hãy giúp gỡ bức tường xấu xí này và để người khác nhìn trộm!

Bước đầu tiên sẽ là giới thiệu Hệ thống kiểm soát phiên bản (SVN, Git, Mercurial, TFS, v.v.). Điều này là phải có cho một dự án sẽ có bao thanh toán lại.

Chỉnh sửa: liên quan đến VSC - Mọi gói kiểm soát nguồn có thể quản lý nhị phân, mặc dù có một số hạn chế. Hầu hết các công cụ trên thị trường có khả năng sử dụng trình xem và trình chỉnh sửa khác biệt tùy chỉnh, sử dụng khả năng này. Các tệp nguồn nhị phân không phải là lý do để không sử dụng kiểm soát phiên bản.

Có một bài viết tương tự về cách xử lý mã kế thừa , đây có thể là một tài liệu tham khảo tốt để làm theo - Lời khuyên khi làm việc với mã kế thừa

Khi tôi phải làm việc với mã spaghetti, điều đầu tiên tôi làm là mô đun hóa . Tìm những nơi mà bạn có thể vẽ các dòng và trích xuất (ít nhiều) các đoạn độc lập của cơ sở mã. Chúng có thể sẽ không nhỏ, do mức độ liên kết và khớp nối cao, nhưng một số dòng mô-đun sẽ xuất hiện nếu bạn tìm chúng.

Khi bạn có các mô-đun, sau đó bạn sẽ không phải đối mặt với nhiệm vụ khó khăn là dọn dẹp toàn bộ chương trình lộn xộn nữa. Bây giờ, thay vào đó, bạn có một số mô-đun lộn xộn độc lập nhỏ hơn để dọn dẹp. Bây giờ chọn một mô-đun và lặp lại trên quy mô nhỏ hơn. Tìm những nơi mà bạn có thể trích xuất các hàm lớn thành các hàm nhỏ hơn hoặc thậm chí các lớp (nếu G2 hỗ trợ chúng).

Điều này dễ dàng hơn rất nhiều nếu ngôn ngữ có một hệ thống loại đủ mạnh, bởi vì bạn có thể yêu cầu trình biên dịch thực hiện nhiều công việc nặng nhọc cho bạn. Bạn thực hiện một thay đổi ở đâu đó sẽ (cố ý) phá vỡ tính tương thích, sau đó cố gắng biên dịch. Các lỗi biên dịch sẽ dẫn bạn trực tiếp đến những nơi cần thay đổi và khi bạn ngừng nhận chúng, bạn đã tìm thấy mọi thứ. Sau đó chạy chương trình và kiểm tra mọi thứ! Kiểm tra liên tục là rất quan trọng khi tái cấu trúc.

Tôi không biết đây có phải là một lựa chọn cho bạn không, nhưng tôi sẽ bắt đầu cố gắng thuyết phục họ thuê những nhà phát triển chuyên nghiệp hơn . Bằng cách này, họ có thể tập trung vào các vấn đề tên miền (tôi chắc rằng họ có đủ ở đó).

Tôi tin rằng họ là những người rất thông minh, nhưng để trở thành một nhà phát triển giỏi đòi hỏi nhiều thời gian. Họ đã sẵn sàng dành quá nhiều thời gian cho một hoạt động không phải là hoạt động kinh doanh chính của họ? IMHO, đây không phải là cách để đạt được kết quả tốt nhất.

Ồ Âm thanh như bạn có một thách thức thực sự lớn trước bạn! Tôi sẽ làm một cái gì đó dọc theo các dòng sau:

• Trước hết: Ưu tiên . Bạn muốn đạt được điều gì đầu tiên? Điều quan trọng nhất đối với tình trạng hiện tại của dự án là gì? Bạn sẽ nhận được nhiều nhất từ ​​bao nhiêu so với thời gian để đến đó.
• Đảm bảo rằng bạn có một hệ thống kiểm soát phiên bản . Git hoặc Mercurial chẳng hạn.
• Nhận một số loại hệ thống tích hợp liên tục (ví dụ Jenkins ) và chạy.
• Nhận một hệ thống theo dõi lỗi lên và chạy. Thần chú là khá tốt đẹp theo ý kiến ​​của tôi.
• Xem xét phân tích mã tĩnh (nếu có sẵn ngôn ngữ bạn đang làm việc).
• Cố gắng đạt được sự thống nhất trong mọi thứ từ đặt tên biến cho đến các quy ước và hướng dẫn mã chung trong cơ sở mã.
• Nhận hệ thống đang thử nghiệm . Điều này là cực kỳ quan trọng đối với một hệ thống di sản lớn như thế này theo ý kiến ​​của tôi. Sử dụng các trường hợp thử nghiệm để ghi lại hành vi hiện có , bất kể hành vi đó có cảm thấy kỳ lạ hay không (thường có lý do là tại sao mã có vẻ chắc chắn tại sao, có thể tốt hay xấu hoặc cả hai; P). Michael Feathers làm việc hiệu quả với mã di sản là một nguồn tài nguyên tuyệt vời cho việc này.

Họ nói rằng bước đầu tiên trong việc giải quyết vấn đề là thừa nhận rằng bạn có một vấn đề. Với ý nghĩ đó, bạn có thể bắt đầu bằng cách tạo một biểu đồ phụ thuộc minh họa mớ rối lớn là cơ sở mã hiện tại của bạn. Công cụ tốt để tạo sơ đồ phụ thuộc? là một vài năm tuổi nhưng có chứa một số gợi ý cho các công cụ có thể giúp tạo ra các biểu đồ như vậy. Tôi sẽ đi với một biểu đồ lớn, xấu xí thể hiện càng nhiều càng tốt để lái xe về nhà. Nói về các vấn đề xuất phát từ quá nhiều phụ thuộc lẫn nhau và có thể gặp rắc rối từ Buckaroo Banzai :

Bạn có thể kiểm tra giải phẫu tất cả những gì bạn muốn, và mặc dù có thể có biến thể bình thường, khi nó đi thẳng vào nó, điều này ở xa trong đầu tất cả đều trông giống nhau. Không, không, không, đừng kéo mạnh về điều đó. Bạn không bao giờ biết những gì nó có thể được gắn vào.

Từ đó, giới thiệu một kế hoạch để bắt đầu thẳng ra mớ hỗn độn. Chia mã thành các mô-đun càng khép kín càng tốt. Hãy cởi mở với các đề xuất về cách thực hiện điều đó - những người bạn đang nói để biết lịch sử và chức năng của mã tốt hơn bạn. Tuy nhiên, mục tiêu là đưa ra một vấn đề lớn và biến nó thành một số vấn đề nhỏ hơn mà sau đó bạn có thể ưu tiên và bắt đầu dọn dẹp.

Một số điều cần tập trung vào:

• Tạo giao diện sạch giữa các mô-đun và bắt đầu sử dụng chúng. Mã cũ có thể, cần thiết, tiếp tục không sử dụng các giao diện mới tốt đẹp đó trong một thời gian - đó là vấn đề bạn đang bắt đầu giải quyết. Nhưng khiến mọi người đồng ý chỉ sử dụng các giao diện mới trong tương lai. Nếu có thứ gì đó họ cần không có trong giao diện, hãy sửa giao diện, đừng đi xung quanh chúng.

• Tìm kiếm các trường hợp chức năng tương tự đã được lặp lại. Làm việc hướng tới thống nhất.

• Nhắc nhở mọi người theo thời gian rằng những thay đổi này là để làm cho cuộc sống dễ dàng hơn, không khó khăn hơn. Chuyển đổi có thể gây đau đớn, nhưng đó là một mục đích tốt, và càng nhiều người trên tàu thì lợi ích sẽ đến càng nhanh.

Sau khi xem xét Gensym G2 một chút, có vẻ như cách tiếp cận vấn đề này sẽ phụ thuộc rất nhiều vào mức độ cơ sở mã trông như thế này:

hoặc này:

so với điều này, lịch sự của 99 Chai Bia :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

Trong trường hợp sau, bạn đang làm việc với mã nguồn thực sự là một đại lượng đã biết và một số câu trả lời khác đưa ra một số lời khuyên rất hiền để xử lý nó.

Nếu hầu hết các cơ sở mã là sau này, hoặc thậm chí nếu một đoạn mã lớn, bạn sẽ gặp phải vấn đề thú vị là có mã có thể không thể được cấu trúc lại do cực kỳ chuyên biệt, hoặc tệ hơn nữa, một cái gì đó trông giống như nó có thể tháo rời được, nhưng trừ khi nó được ghi lại đúng cách, bạn không biết liệu bạn có đang xóa mã quan trọng hay không (nghĩ gì đó dọc theo dòng của thao tác scram ) thoạt nhìn không giống như vậy.

Mặc dù rõ ràng ưu tiên hàng đầu của bạn là sẽ có được một số loại kiểm soát phiên bản trực tuyến, như ElYusubov đã chỉ ra , và có vẻ như kiểm soát phiên bản đã được hỗ trợ kể từ phiên bản 8.3 . Vì G2 là sự kết hợp của một vài phương pháp ngôn ngữ khác nhau, nên bạn có thể thấy nó hiệu quả nhất khi sử dụng điều khiển phiên bản được cung cấp cùng với nó, trái ngược với việc cố gắng tìm một cái gì đó khác và khiến nó hoạt động.

Tiếp theo, mặc dù một số người có thể ủng hộ việc bắt đầu tái cấu trúc, tôi là người ủng hộ mạnh mẽ để đảm bảo bạn hiểu đầy đủ về hệ thống mà bạn đang làm việc trước khi bắt đầu chạm vào bất kỳ mã nào, đặc biệt là khi xử lý mã và sơ đồ trực quan được phát triển bởi các nhà phát triển với đào tạo chính thức (hoặc nền tảng) về phương pháp kỹ thuật phần mềm. Lý do cho điều này là nhiều lần, nhưng lý do rõ ràng nhất là bạn đang làm việc với một ứng dụng có khả năng làm việc hơn 100 năm và bạn thực sự cần chắc chắn rằng bạn biết nó đang làm gì và bao nhiêu tài liệu có trong đó. Như bạn đã không nói hệ thống nào được triển khai, Dựa trên những gì tôi đã đọc về G2, có vẻ an toàn khi cho rằng đó có thể là một ứng dụng quan trọng, thậm chí có thể có tiềm năng mang lại ý nghĩa an toàn cho cuộc sống. Vì vậy, hiểu chính xác những gì nó đang làm sẽ rất quan trọng. Đó là mã không được ghi lại làm việc với những người khác trong nhóm để đảm bảo rằng tài liệu được đưa vào để đảm bảo mọi người có thể xác định mã đó làm gì.

Tiếp theo bắt đầu kiểm tra đơn vị xung quanh bao nhiêu cơ sở mã và sơ đồ trực quan mà bạn có thể. Tôi phải thừa nhận một số sự thiếu hiểu biết liên quan đến cách thực hiện điều này với G2 nhưng gần như có thể đáng để tạo khung thử nghiệm của riêng bạn để thực hiện điều này. Đây cũng là thời điểm lý tưởng để bắt đầu giới thiệu các thành viên khác trong nhóm để giúp họ sử dụng một số thực hành kỹ thuật nghiêm ngặt hơn liên quan đến chất lượng mã (tức là tất cả các mã phải có bài kiểm tra đơn vị và tài liệu).

Khi bạn có các bài kiểm tra đơn vị tại chỗ với số lượng mã hợp lý, bạn có thể bắt đầu tiếp cận tái cấu trúc theo cách như đề xuất của haylem ; tuy nhiên, hãy nhớ rằng bạn đang đối phó với thứ gì đó có nghĩa là để phát triển hệ thống chuyên gia và tái cấu trúc nó có thể là một trận chiến khó khăn. Đây thực sự là một môi trường mà đôi khi có điều gì đó để nói về việc không viết mã cực kỳ chung chung.

Cuối cùng, hãy chắc chắn rằng bạn chú ý đến những gì các thành viên khác trong nhóm nói, chỉ vì chất lượng mã và sơ đồ không phải là tốt nhất không nhất thiết phản ánh kém về họ. Cuối cùng, trong thời gian này, họ có khả năng biết nhiều hơn về những gì ứng dụng làm hơn bạn, đó là lý do tại sao điều quan trọng nhất đối với bạn là ngồi xuống và đảm bảo bạn hiểu những gì nó làm trước khi thực hiện các thay đổi sâu rộng.

Thông thường những khiếu nại bạn nghe thấy trước không liên quan gì đến những vấn đề quan trọng. Rốt cuộc, việc nghe những khiếu nại này trong bất kỳ dự án phần mềm nào là hoàn toàn bình thường.

Khó hiểu mã? Kiểm tra. Cơ sở mã lớn? Kiểm tra.

Vấn đề thực sự là mọi người rời đi, và khi người mới gia nhập tổ chức, có một sự mất phương hướng điển hình. Hơn nữa, có một vấn đề về những kỳ vọng không thực tế và các vấn đề về chất lượng mã.

Đây là những gì tôi sẽ giải quyết, theo thứ tự:

1. Sao lưu, cả máy chủ và phiên bản cục bộ
2. Thiết lập trình theo dõi lỗi
3. Thiết lập hệ thống phiên bản
4. Thiết lập FAQ / Wiki
5. Cuộc phỏng vấn đầu tiên của tất cả các nhà khoa học / lập trình viên
   • Nhắc nhở họ về quy tắc 80/20. 20% lỗi là nguyên nhân của 80% các vấn đề.
   • Tập trung vào các vấn đề lớn nhất và tiếp tục yêu cầu nâng cao.
   • Mục đích ở đây không phải là để dọa mọi người bằng một danh sách lớn, mà là một danh sách những chiến thắng nhỏ có thể đạt được. Rốt cuộc, bạn phải chứng minh giá trị của bạn là tốt.
6. Thiết lập hệ thống xây dựng
   • Bắt đầu làm việc để có được các bản dựng đáng tin cậy (điều này có thể mất một lúc)
   • xác định và đặt tên cho mỗi dự án
   • xác định phụ thuộc theo chu kỳ
   • nếu có nhị phân từ một số dự án nguồn mở, hãy thử lấy nguồn
7. Xác định cách mã hóa G2 có thể được mô đun hóa, ví dụ: API, dịch vụ
8. Xác định cách mã G2 có thể được kiểm tra, ghi lại.
9. Thiết lập hệ thống đánh giá mã
10. Mảnh vỡ thứ hai
    • Một mô-đun lý tưởng trông như thế nào?
    • Làm thế nào để loại bỏ mã cũ
    • Cách bọc mô-đun mới xung quanh mã cũ (Xem Mẫu Strangler http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-potype-of-choice-for.html )
11. Xác định một nhóm crack gồm các lập trình viên tốt hơn và làm việc với họ để bọc các mô-đun của họ.
12. Đánh giá mã có ở giai đoạn này để cải thiện giao tiếp và tài liệu. Giữ nó dễ dàng ở giai đoạn này. Sắp xếp bất kỳ vấn đề quá trình.
13. Tung ra hệ thống cho các lập trình viên khác. Hãy để các thành viên nhóm crack trở thành cố vấn ngang hàng với phần còn lại. Hãy nhớ rằng nhân rộng là vấn đề ở đây. Bạn có hiệu quả trong vai trò quản lý.

Những câu hỏi như thế này là toàn bộ lý do dự án Mộc phần mềm tồn tại.

Trong 14 năm qua, chúng tôi đã dạy cho các nhà khoa học và kỹ sư các kỹ năng phát triển phần mềm cơ bản: kiểm soát phiên bản, thử nghiệm, cách mô đun hóa mã, v.v. Tất cả các tài liệu của chúng tôi đều có sẵn miễn phí theo giấy phép Creative Commons và chúng tôi điều hành một vài chục hội thảo hai ngày miễn phí mỗi năm để giúp mọi người bắt đầu.

Dựa vào đó, tôi nghĩ rằng điểm khởi đầu tốt nhất có lẽ là cuốn sách xuất sắc (ngắn) của Robert Glass Sự kiện và sai lầm của Kỹ thuật phần mềm : cách tiếp cận dựa trên bằng chứng của nó là một cách tốt để thuyết phục các nhà khoa học rằng những gì chúng ta nói với họ về thực hành lập trình tốt là không chỉ là ý kiến.
Đối với thực tiễn cụ thể, hai cách mà mọi người sẵn sàng áp dụng là kiểm soát phiên bản và kiểm tra đơn vị; một khi chúng được đặt đúng chỗ, chúng có thể giải quyết kiểu tái cấu trúc có hệ thống mà Michael Feathers mô tả trong Làm việc hiệu quả với Bộ luật kế thừa .
Tôi không còn đề xuất Lập trình viên thực dụng (rất nhiều lời khích lệ, khó cho người mới thực hành) và tôi nghĩ rằng Bộ luật hoàn chỉnh của McConnell quá nhiều để bắt đầu (mặc dù đó là một điều tuyệt vời để cung cấp cho họ sáu tháng hoặc một năm, một khi họ đã nắm vững những điều cơ bản).

Tôi cũng rất muốn giới thiệu bài viết xuất sắc của Paul Dubois "Duy trì tính đúng đắn trong các chương trình khoa học" ( Tính toán trong khoa học & kỹ thuật , tháng 5 tháng 6 năm 2005), trong đó mô tả cách tiếp cận "phòng thủ theo chiều sâu" kết hợp hàng tá thực tiễn khác nhau theo cách hợp lý, mạch lạc đường.

Tôi nghĩ trước hết bạn phải làm rõ tình hình của bạn. Họ muốn gì ở bạn?

• Rất khó có khả năng họ muốn bạn học một ngôn ngữ cổ, bởi vì điều này bây giờ dường như là một ngõ cụt: có cơ hội giảm dần để tìm thấy bất cứ ai biết hoặc muốn học G2, vì vậy kiến ​​thức sẽ bị chôn vùi trong đống mã bị sụp đổ khi các nhà khoa học hiện tại để lại hoặc mã vá tất cả thất bại ngày càng thường xuyên hơn.
• Các nhà khoa học (hoặc một số trong số họ) đã sẵn sàng để học một ngôn ngữ mới và rất nhiều mô hình lập trình? Hay họ muốn tách biệt hoạt động lập trình và khoa học trong dài hạn, và có lẽ có thêm một số lập trình viên nếu cần? Điều này có vẻ như một sự tách biệt hợp lý và hiệu quả hơn về chuyên môn.

Tôi nghĩ yêu cầu cốt lõi ở đây là "tiết kiệm kiến ​​thức trong hệ thống", vì vậy bạn phải đi và khai quật nó!

Nhiệm vụ đầu tiên là viết một tài liệu.

Phân tích cấu trúc và các yêu cầu như thể đây sẽ là một nhiệm vụ mới, nhưng với sự trợ giúp của một hệ thống hiện có. Họ sẽ hài lòng vì bạn HỎI thay vì GIẢNG DẠY trước - và bạn sẽ nhanh chóng có đủ, nhưng kiến ​​thức nền tảng có tổ chức hơn từ quan điểm của một lập trình viên: "chuyện gì đang xảy ra ở đây?" Các tài liệu (cấu trúc tĩnh hệ thống, quy trình làm việc, các thành phần, sự cố) sẽ ngay lập tức có giá trị đối với chúng và có thể sẽ hiển thị nhiều thông tin liên quan đến chúng hơn so với bạn (một số kẻ có thể có "AHA!" Và bắt đầu sửa một số mã ngay lập tức ) ...

Sau đó bạn nên bắt đầu hỏi họ muốn đi đâu?

Nếu họ sẵn sàng rời khỏi G2, họ muốn xem hệ thống nào (nền tảng, ngôn ngữ, giao diện, cấu trúc chung)? Bạn có thể bắt đầu viết một trình bao bọc bên ngoài xung quanh hệ thống nếu có thể, có cấu trúc đích, nhưng vẫn giữ các thành phần gốc, do đó từ từ bắt đầu một loại khung cho phép các thành phần mới được thực hiện trong môi trường đích này. Bạn phải tìm các dịch vụ cốt lõi (kết nối dữ liệu liên tục và "bộ công cụ": tính toán lõi, bản vẽ, ... thư viện), và do đó bạn cung cấp cho chúng một môi trường quen thuộc trong một nền tảng và ngôn ngữ mới, cho phép bạn chuyển đổi hoặc chúng: lấy các mã cũ từng cái một, thực hiện lại (và SẠCH!) chúng trong môi trường mới. Khi điều đó đã sẵn sàng, họ biết ngôn ngữ mới; và lớp dịch vụ (chủ yếu do bạn thực hiện, xin lỗi) đã sẵn sàng để lưu trữ các thành phần mới.

Nếu họ không di chuyển , bạn phải tìm hiểu G2 và tạo khung mô-đun ở đó, nơi bạn hoặc họ nên di chuyển các thành phần (với việc dọn dẹp). Dù sao, ngôn ngữ chỉ là một chuỗi tuần tự của cây dữ liệu và thuật toán ...

Trong khi phân tích và viết các tài liệu, hãy đọc, sử dụng và quảng cáo các mẫu Thiết kế GoF! :-)

... 2 xu của tôi

Tôi vừa hoàn thành một loạt các bài thuyết trình về các nguyên tắc RẮN của Robert Martin cho các đồng nghiệp của tôi. Tôi không biết các nguyên tắc này dịch sang G2 tốt như thế nào, nhưng vì bạn đang tìm kiếm 5-7 nguyên tắc cơ bản cốt lõi, nên những nguyên tắc này có vẻ giống như một bộ được thiết lập tốt để bắt đầu. Nếu bạn muốn làm tròn đến 7, bạn có thể bắt đầu với DRY và ném vào Fail-Fast.

Vấn đề sản xuất duy nhất nghe có vẻ như một vấn đề quản lý thay đổi. Nếu đó là trường hợp và phần mềm thực hiện theo cách khác thì mục đích đầu tiên tôi sẽ đưa ra là chống lại sự thôi thúc phải làm quá nhiều quá nhanh.

Kiểm soát nguồn, tái cấu trúc, các nhà phát triển được đào tạo nhiều hơn đều là những gợi ý tốt, nhưng nếu đây là lần đầu tiên bạn phải xử lý loại vấn đề này di chuyển chậm và thực hiện các thay đổi có kiểm soát thì không thể nhấn mạnh đủ.

Đôi khi sự thôi thúc muốn vượt qua mớ hỗn độn sẽ rất lớn, nhưng cho đến khi bạn hoàn toàn đảo ngược đủ để bạn biết rằng bạn có thể kiểm tra phiên bản thay thế của mình một cách đầy đủ, bạn cần phải rất cẩn thận.

Các nguyên tắc quan trọng nhất để làm việc trong tình huống như vậy là:

1. Kiên nhẫn. Một lỗ mất 20 năm để đào sẽ không được lấp đầy trong một vài tuần.

2. Hãy tích cực. Chống lại sự cám dỗ để phàn nàn và càu nhàu.

3. Hãy thực dụng. Nhìn vào một sự thay đổi tích cực mà bạn có thể hoàn thành trong một ngày và thực hiện điều đó ngay hôm nay. Có một hệ thống kiểm soát phiên bản chưa? Thực hiện nó và đào tạo mọi người. Sau đó nhìn và xem nếu bạn có thể tự động hóa thử nghiệm (Thử nghiệm đơn vị hoặc một cái gì đó tương tự). Rửa sạch. Nói lại.

4. Hãy là một người mẫu. Chỉ cho mọi người thấy cách nhanh nhẹn hoạt động bằng cách nhanh nhẹn. Ba điểm đầu tiên ở trên là chìa khóa để trở thành một Người tốt, là tiền thân để trở thành một anh chàng Agile hiệu quả. Theo tôi, những người là nhà phát triển đáng ngưỡng mộ không chỉ thông minh, họ còn là những nhân viên và đồng nghiệp mẫu mực.

5. Bản đồ lãnh thổ của bạn. Tôi có một kỹ thuật để lập bản đồ cơ sở di sản khổng lồ. Tôi sao chép repo, tạo một bản sao hoạt động, và sau đó tôi cố gắng thay đổi một cái gì đó, và xem những gì khác phá vỡ. Bằng cách điều tra khớp nối (thông qua trạng thái toàn cầu hoặc API bị hỏng hoặc thiếu API nhất quán hoặc bất kỳ sự trừu tượng hoặc giao diện nào để lập trình) và bằng cách đọc mã bị hỏng khi tôi thay đổi mọi thứ, tôi phát hiện ra câu hỏi, tôi đặt câu hỏi dẫn đến hiểu biết sâu sắc từ phần còn lại của đội (Oh ​​chúng tôi đã thêm rằng vì Boss X 5 năm trước đã yêu cầu điều đó, nó không bao giờ hoạt động!). Theo thời gian, bạn sẽ có được một bản đồ tinh thần của lãnh thổ. Khi bạn biết nó lớn như thế nào, bạn sẽ biết đủ để tạo bản đồ và về nhà. Khuyến khích người khác lập bản đồ lãnh thổ của cơ sở mã khổng lồ của bạn và xây dựng kiến ​​thức kỹ thuật của nhóm. Một số người chùn bước tại "tài liệu" bởi vì nó không nhanh nhẹn Bất cứ điều gì. Tôi cũng làm việc trong môi trường khoa học và tài liệu là vua đối với tôi, những bản kê khai nhanh nhẹn bị nguyền rủa.

6. Xây dựng các ứng dụng nhỏ. Khi làm việc với một cơ sở mã di sản, tôi thấy tôi đi xuống một bột giấy. Tôi lấy lại tinh thần bằng cách xây dựng các ứng dụng trợ giúp nhỏ. Có thể những ứng dụng đó sẽ giúp bạn đọc, hiểu và sửa đổi cơ sở mã G2 khổng lồ đó. Có lẽ bạn có thể tạo một IDE nhỏ hoặc công cụ phân tích cú pháp sẽ giúp bạn làm việc trong môi trường của mình. Có nhiều trường hợp lập trình Meta và xây dựng công cụ không chỉ giúp bạn thoát ra khỏi những bế tắc khổng lồ mà các cơ sở mã hóa kế thừa áp đặt lên bạn, chúng còn cho não bạn khả năng bay không bị giới hạn bởi ngôn ngữ G2 của bạn. Viết công cụ và người trợ giúp của bạn bằng bất kỳ ngôn ngữ nào bạn có thể thực hiện chúng nhanh nhất và tốt nhất. Đối với tôi, những ngôn ngữ đó bao gồm Python và Delphi. Nếu bạn là một anh chàng Perl, hoặc bạn thực sự THÍCH lập trình bằng C ++ hoặc C #, thì hãy viết các công cụ trợ giúp của bạn bằng ngôn ngữ đó.

1. Kiểm soát sửa đổi : cho các chuyên gia tên miền thấy lợi ích của việc có thể hoàn nguyên, xem ai đã thay đổi cái gì, v.v. (Điều này khó khăn hơn với các tệp nhị phân, nhưng nếu nội dung thực sự là mã, chắc chắn có một số loại G2-to- trình chuyển đổi văn bản có thể cho phép tìm khác biệt.)

2. Kiểm thử và tích hợp liên tục : khiến các chuyên gia tên miền tham gia vào việc tạo các thử nghiệm đầu cuối (dễ dàng hơn, vì họ phải có đầu vào và đầu ra dự kiến ​​ở đâu đó) và thử nghiệm đơn vị nhỏ (khó hơn, vì mã spaghetti có thể liên quan đến nhiều biến toàn cục) bao gồm gần như tất cả các chức năng và trường hợp sử dụng.

3. Tái cấu trúc mã phổ biến thành các thói quen và các thành phần có thể tái sử dụng. Những người không phải là phần mềm không có kiểm soát sửa đổi có thể sao chép và dán 100 dòng một lần để tạo thói quen. Tìm chúng và cấu trúc lại chúng, cho thấy rằng tất cả các bài kiểm tra đều vượt qua và mã đã ngắn hơn. Điều này cũng sẽ giúp bạn tìm hiểu kiến ​​trúc của nó. Nếu bạn may mắn vào thời điểm bạn phải bắt đầu đưa ra các quyết định kiến ​​trúc khó khăn, bạn có thể xuống tới 100KLOC.

Về mặt chính trị , nếu bạn tìm thấy sự kháng cự từ các bộ tính giờ cũ trong quy trình này, hãy thuê một chuyên gia tư vấn để đến và nói chuyện về phương pháp phần mềm tốt. Hãy chắc chắn rằng bạn tìm thấy một quan điểm tốt mà bạn đồng ý và yêu cầu quản lý mua chuộc sự cần thiết của nhà tư vấn ngay cả khi các chuyên gia tên miền không. (Họ nên đồng ý - sau tất cả, họ đã thuê bạn, vì vậy rõ ràng họ nhận ra rằng họ cần chuyên môn về kỹ thuật phần mềm.) Đây là một mánh khóe lãng phí tiền, tất nhiên, nhưng lý do là nếu bạn - lập trình viên trẻ tuổi nóng bỏng mới - nói Họ cần phải làm một cái gì đó, họ có thể bỏ qua nó. Nhưng nếu ban quản lý trả cho một nhà tư vấn 5000 đô la để đến và nói với họ những gì họ cần làm, họ sẽ đặt niềm tin nhiều hơn vào đó. Điểm thưởng: nhờ chuyên gia tư vấn tư vấn thay đổi gấp đôi số tiền bạn muốn, sau đó bạn có thể là "người tốt" và bên cạnh các chuyên gia tên miền, thỏa hiệp chỉ thay đổi một nửa so với nhà tư vấn đề xuất.

"Bản thân chương trình là một mô hình vật lý của một nhà máy xử lý hóa chất phức tạp ..."

"Vì G2 giống như không phải mã, mà là mã tự động được viết bởi một số GUI tiện lợi ..." - Erik Reppen

Giả sử mục tiêu chính của phần mềm của bạn là mô phỏng (có thể tối ưu hóa, chạy ước tính tham số) một nhà máy hóa chất phức tạp hoặc các bộ phận của một ... sau đó tôi muốn đưa ra một đề xuất khá khác:

Bạn có thể làm tốt để xem xét sử dụng ngôn ngữ mô hình toán học cấp cao để trích xuất bản chất, các mô hình toán học cốt lõi, từ phần mềm được mã hóa bằng tay.

Điều mà một ngôn ngữ mô hình làm là tách rời mô tả vấn đề khỏi các thuật toán được sử dụng để giải quyết vấn đề. Các thuật toán này thường được áp dụng cho hầu hết các mô phỏng / tối ưu hóa của một lớp nhất định (ví dụ các quy trình hóa học) trong trường hợp chúng thực sự không nên được phát minh lại và duy trì trong nhà.

Ba gói thương mại được sử dụng rộng rãi trong ngành của bạn là: gPROMS, Aspen Custom Modeller và (nếu mô hình của bạn không bao gồm các hiện tượng được phân phối dọc theo các miền không gian) có các gói phần mềm dựa trên Modelica, chẳng hạn như Dymola.

Tất cả các gói này đều hỗ trợ "phần mở rộng" theo cách này hay cách khác, do đó, nếu bạn có các phần của mô hình yêu cầu lập trình tùy chỉnh, chúng có thể được gói gọn vào một đối tượng (ví dụ: .DLL) có thể được tham chiếu bởi các phương trình trong mô hình. Trong khi đó, phần lớn mô hình của bạn vẫn cô đọng, được mô tả dưới dạng dễ đọc bởi các nhà khoa học. Đây là một cách tốt hơn nhiều để nắm bắt kiến ​​thức và IP của công ty bạn.

Hầu hết các chương trình này cũng sẽ cho phép bạn 'bắt đầu nhỏ' và chuyển các phần nhỏ (mô hình con) của mã nguyên khối sang định dạng của chúng, bằng cách được gọi bên ngoài. Đây có thể là một cách tốt để duy trì một hệ thống làm việc và xác nhận nó từng phần một.

Từ chối trách nhiệm đầy đủ: Tôi đã làm việc như một kỹ sư phần mềm tại công ty đằng sau gPROMS trong 8 năm. Trong thời gian đó, tôi đã thấy (và đôi khi được kết hợp) các phần mềm tùy chỉnh (ví dụ đến từ học viện) đã bắt đầu nhỏ và gọn gàng, thực hiện một số giải pháp hoặc thuật toán thông minh, nhưng sau đó bùng nổ qua nhiều năm với các phần mở rộng và sửa đổi - mà không có hướng dẫn hữu ích của một kỹ sư phần mềm để giữ cho nó sạch sẽ. (Tôi là một fan hâm mộ lớn của các đội đa lĩnh vực.)

Vì vậy, tôi có thể nói với một số kinh nghiệm rằng một số lựa chọn chính được đưa ra từ rất sớm trong quá trình phát triển phần mềm (như ngôn ngữ hoặc thư viện khóa) có xu hướng gắn bó và gây đau đớn trong một thời gian dài ... Họ đã 'định hình' phần mềm xung quanh họ. Tôi nghe có vẻ như bạn có thể phải đối mặt với nhiều năm làm sạch mã thuần túy ở đây. (Tôi ngần ngại sử dụng các con số nhưng tôi đang suy nghĩ hơn 10 năm tuổi, có thể nhiều hơn nữa nếu bạn không thể chuyển mã từ G2 sang thứ gì đó hỗ trợ các công cụ tái cấu trúc tự động tốt như Eclipse / Java thông minh nhanh.)

Mặc dù trạng thái mặc định của tôi là "tái cấu trúc và giữ một hệ thống làm việc", tôi cũng nghĩ rằng một khi vấn đề trở nên "quá lớn", thì một sự thay đổi / viết lại triệt để hơn sẽ trở nên nhanh hơn. (Và có thể mang lại lợi ích bổ sung, như nhảy sang một công nghệ hiện đại hơn.) Tôi nói rằng với một số kinh nghiệm chuyển sang nền tảng phần mềm mới, nhưng từ những gì tôi thu thập được, nó thậm chí còn ấn tượng hơn với một cổng mô hình toán học.

Để đưa ra một số quan điểm, bạn có thể khá ngạc nhiên về việc giảm kích thước. Ví dụ, 200.000 LoC thực sự có thể được biểu diễn trong khoảng 5.000 dòng phương trình (OK tôi đoán ở đây, nhưng tôi có thể thử và nhận cho bạn một lời chứng thực từ bạn bè trong doanh nghiệp); cộng với một vài mô-đun chức năng tương đối nhỏ được viết bằng thứ gì đó như C (ví dụ: tính toán thuộc tính vật lý - mặc dù một lần nữa các gói có thể tồn tại tùy thuộc vào quá trình hóa học của bạn). Điều này là bởi vì bạn thực sự chỉ cần vứt bỏ mã giải pháp thuật toán và để cho một 'bộ giải' toán học có mục đích chung thực hiện công việc khó khăn. Khi bạn có các mô phỏng đang chạy, bạn có thể làm nhiều hơn với chúng, như tối ưu hóa quy trình - mà không thay đổi một dòng mã.

Cuối cùng tôi sẽ nói: nếu tài liệu đáng tin cậy duy nhất của các mô hình toán học (và thuật toán) khác nhau là chính mã, bạn sẽ muốn có sự giúp đỡ của các nhà khoa học và tác giả gốc để giúp trích xuất các mô hình đó, càng sớm càng tốt một số trong số họ có thể đã di chuyển trên. Họ nên thấy rằng một ngôn ngữ mô hình toán học là một cách rất tự nhiên để nắm bắt những mô hình đó - họ thậm chí có thể (sốc kinh dị) thích thú (viết lại) nó.

Cuối cùng, vì câu trả lời của tôi có thể không đúng, tôi chỉ muốn thêm một cuốn sách nữa vào danh sách những cuốn sách hay đã được tham khảo ở đây: Clean Code của Robert Martin. Có đầy đủ các mẹo đơn giản (và hợp lý), dễ học và áp dụng, nhưng có thể tạo ra một thế giới khác biệt cho những người phát triển mã mới tại công ty của bạn.

Tôi sẽ ném xuống như sau:

1. Có một lập trình viên ở đây. Vít chính trị. Họ biết giao dịch của họ. Bạn biết bạn. Đánh dấu lãnh thổ đó ngay cả khi bạn phải đái vào nó. Họ là những nhà khoa học. Họ có thể tôn trọng những thứ đó hoặc nên vì họ thường xuyên làm điều tương tự. Thông qua bất cứ điều gì có nghĩa là bạn có thể, đánh dấu các ranh giới bây giờ. Đây là những gì tôi sẽ sửa chữa. Đây là những gì tôi không thể chịu trách nhiệm.

2. Các nhà khoa học viết / kiểm tra các thuật toán. Các nhà khoa học muốn viết thuật toán của riêng họ bằng 1-3 ngôn ngữ, mọi người đều có thể đồng ý cho bạn chuyển đổi sang mã lõi. Điều đó đặt thử nghiệm công cụ của họ trên chúng. Ngoài ra, họ sẽ phải giúp bạn cách ly những thứ khoa học quan trọng so với những người biết điều tốt lành về những gì họ đã làm cho kiến ​​trúc. Các codebase được hosed. Có rất nhiều dấu gạch chéo và ghi sẽ cần phải được thực hiện. Cung cấp cho họ các tùy chọn để trao cho bạn phiên bản làm việc của những thứ sử dụng những gì họ biết rõ nhất để bạn có thể làm những gì bạn làm tốt nhất. Ghi kiến ​​thức của họ vào một hộp mà họ chịu trách nhiệm nhưng bạn có thể làm việc cùng.

3. Sử dụng ngôn ngữ thân thiện với sự kiện với các chức năng hạng nhất nếu bạn có thể. Khi tất cả các cách khác đều thất bại, kích hoạt một sự kiện hoặc ném một cuộc gọi lại đến một đối tượng nào đó với một cơ chế giao diện và trạng thái thực sự có ý nghĩa có thể là một trình tiết kiệm thời gian rất lớn khi bạn không hiểu sâu về mã mà không có ý nghĩa đẫm máu và hoàn toàn không bao giờ có thể sẽ. Các nhà khoa học dường như thích Python. Không khó để kết dính những thứ C chuyên sâu về toán học với điều đó. Chỉ cần nói

4. Hãy tìm ai đó đã giải quyết vấn đề này hoặc một vấn đề tương tự. Dành thời gian nghiên cứu nghiêm túc. Những người này đã nghe về G2 từ ai đó.

5. Mẫu thiết kế. Bộ điều hợp. Sử dụng chúng. Sử dụng chúng rất nhiều trong các tình huống như thế này.

6. Tìm hiểu những gì bạn có thể của khoa học. Bạn càng biết nhiều, bạn càng có thể xác định ý định trong mã.

Làm phân tích trước.

Tôi sẽ làm một số phân tích trước khi quyết định những gì để dạy. Chỉ ra các điểm đau lớn nhất là ở đâu. Sử dụng chúng để ưu tiên những gì thực hành để đi qua.

Chỉ giới thiệu một vài thay đổi tại một thời điểm (trong tình huống tương tự tôi đã thực hiện 2-3 lần thực hành mỗi 2 tuần) .

Tôi sẽ giới hạn các thực hành ở mức ~ 3 tùy thuộc vào mức độ thay đổi theo kiểu lập trình SDLC; cho đến khi họ bắt đầu thấy thoải mái với họ (tôi sẽ cố gắng giới thiệu 1 thay đổi mới mỗi ~ 1-2 tuần khi họ cảm thấy thoải mái hơn với ý tưởng học các phương pháp mới). Đó cũng là một ý tưởng tốt để xác định các tiêu chí để thành công là gì. Những gì thực hành nên thực hiện (ngay cả khi đó là một mục tiêu mềm như tinh thần đồng đội). Bằng cách đó bạn có thể hiển thị nếu nó hiệu quả hay không.

• Tại sao phải giới hạn số lượng thay đổi?

Ngay cả khi bạn cho rằng những người này muốn trở thành lập trình viên giỏi hơn và sẵn sàng học hỏi, vẫn có giới hạn về mức độ và tốc độ mọi người có thể học các khái niệm mới và áp dụng chúng; đặc biệt là nếu họ không có nền tảng CS hoặc đã tham gia Vòng đời phát triển phần mềm trước đó.

Thêm một cuộc họp kết thúc hàng tuần để thảo luận về cách thức thực hành ảnh hưởng đến họ.

Cuộc họp nên được sử dụng để thảo luận về những gì diễn ra tốt đẹp và những gì cần làm việc. Cho phép họ có tiếng nói và được hợp tác. Thảo luận và lập kế hoạch để giải quyết các vấn đề họ đang gặp phải và để xem trước các thay đổi tiếp theo sắp tới. Giữ cuộc họp tập trung vào các thực tiễn và ứng dụng của họ. Thực hiện một chút truyền giáo về những lợi ích mà họ nên bắt đầu nhìn thấy từ việc áp dụng các thực hành.

Một số thực hành được ưu tiên.

Việc sử dụng đúng hệ thống kiểm soát phiên bản (IMO) hơn hẳn mọi thứ khác. Gần phía sau là những bài học về mô đun hóa, khớp nối / gắn kết và theo dõi vé tính năng / lỗi.

Loại bỏ các thực hành không hoạt động.

Đừng sợ để thoát khỏi các thực hành không hoạt động. Nếu có một chi phí cao và ít hoặc không có lợi ích, hãy loại bỏ thực hành.

Cải tiến là một quá trình.

Truyền đạt rằng cải tiến bền vững, nhất quán là một quá trình. Xác định các điểm đau lớn nhất, áp dụng một giải pháp, chờ đợi / huấn luyện viên và sau đó lặp lại. Nó sẽ cảm thấy chậm chạp ban đầu cho đến khi bạn xây dựng một số động lực. Giữ cho mọi người tập trung vào những cải tiến đang đến và sự cải tiến đã thành công.

Âm thanh như bước đầu tiên bạn có là bán cho nhóm cần đầu tư vào phương pháp phần mềm mới. Theo tuyên bố của bạn, không có sự đồng thuận trong nhóm và bạn sẽ cần nó để có thể cày trước với việc "nâng cấp" mã chậm.

Tôi sẽ (nếu tôi có thể) đích thân học những bài học khó đã học và giới thiệu từng khái niệm chính mà bạn muốn làm giải pháp cho vấn đề trong ngành công nghiệp phần mềm.

Ví dụ: hai nhà phát triển có các bản sao khác nhau và cuối cùng đã triển khai một bản phát hành chưa được kiểm tra lai -> Giới thiệu kiểm soát phiên bản, phân nhánh và thử nghiệm.

Ai đó đã xóa một vài dòng mã mà họ không hiểu và gây ra sự cố ngừng hoạt động -> giới thiệu DDD.

Nếu những bài học khó không được chia sẻ với bạn một cách chi tiết, thì hãy chỉ ra những ví dụ của riêng bạn về cách mọi thứ đã sai khi môn học này không được tuân thủ.

Kiểm soát mã nguồn là bước số 1 như đã nêu nhiều lần. Mặc dù những người bạn làm việc cùng có thể không phải là nhà phát triển chuyên nghiệp và họ sẽ không phản hồi với nhiều doanh nghiệp hoặc người khổng lồ nhanh nhẹn. Chúng cũng không phải là những con khỉ mã cấp thấp và cố gắng đối xử với chúng như vậy bằng cách buộc chúng làm những việc 'theo cách của bạn' sẽ không bay được.

Bạn đã phải khảo sát những gì ngoài đó. Nếu họ chưa sử dụng kiểm soát mã nguồn thì chỉ cần xác định đúng phiên bản mã (nếu có thể) và tất cả các sản phẩm có thể cung cấp sẽ mất nhiều thời gian. Sau đó, bạn sẽ có nhiệm vụ dạy cho các đồng nghiệp của mình cách sử dụng kiểm soát mã nguồn và thuyết phục họ rằng nó đáng để họ dành thời gian. Bắt đầu với những lợi ích!

Trong khi bạn đang làm điều đó, tìm trái cây treo thấp khác và khắc phục những vấn đề đó.

Trên hết, hãy lắng nghe những gì họ nói và làm việc để cải thiện tình hình của họ. Đừng lo lắng về việc cố gắng đặt dấu ấn của bạn vào những gì họ làm.

Chúc may mắn!