Là thực hành lập trình xấu điển hình trong ngành công nghiệp phần mềm? [đóng cửa]

Tôi mới bắt đầu công việc đầu tiên là một nhà phát triển phần mềm hơn một tháng trước. Tất cả mọi thứ tôi đã học về OOP, RẮN , DRY , YAGNI, các mẫu thiết kế, SRP , v.v. đều có thể được ném ra ngoài cửa sổ.

Họ sử dụng C # .NET Webforms và thực hiện hầu hết mọi thứ trong Code Phía sau với rất ít Lớp bên ngoài, chắc chắn không được gọi là đối tượng. Họ sử dụng các điều khiển tùy chỉnh và tái sử dụng chúng. Về các đối tượng duy nhất được sử dụng là bởi Entity Framework . Họ sử dụng lại Mã phía sau cho mỗi khách hàng. Họ có các phương pháp dài 400 dòng, thực hiện tất cả các loại công cụ. Đối với khách hàng mới, họ lấy aspx và aspx.cs và loại bỏ mã máy khách và bắt đầu thêm mã dành riêng cho khách hàng mới.

Lý do đầu tiên của họ sẽ là thêm bảo trì bổ sung, và nhiều mã hơn là bảo trì nhiều hơn. Đó là một cửa hàng nhỏ gồm ba nhà phát triển bao gồm cả bản thân tôi. Một nhà phát triển có hơn 30 năm kinh nghiệm và nhà phát triển khác có hơn 20 năm kinh nghiệm. Một người từng là nhà phát triển trò chơi và người kia luôn làm việc trong C và C ++.

Làm thế nào phổ biến là trong ngành công nghiệp phần mềm? Làm cách nào tôi có thể đảm bảo rằng tôi luôn đứng đầu OOP và các nguyên tắc liên quan? Tôi luyện tập trong thời gian rảnh rỗi và tôi cảm thấy mình thực sự cần phải làm việc dưới một nhà phát triển có kinh nghiệm hơn để trở nên tốt hơn tại OOP.

1. Các nguyên tắc mà bạn đã trích dẫn trong câu hỏi của bạn chỉ là ... nguyên tắc. Họ không phải là nhiệm vụ, luật pháp hoặc mệnh lệnh.
2. Trong khi những người đưa ra các nguyên tắc này rất thông minh, họ không phải là người có thẩm quyền tuyệt đối. Họ chỉ là những người cung cấp những hiểu biết và hướng dẫn của họ .
3. Không có cách "chính xác" để lập trình. Điều này được chứng minh bằng thực tế rằng cách "được chấp nhận" mà chúng ta làm đã thay đổi và tiếp tục thay đổi, hoàn toàn theo thời gian.
4. Vận chuyển một sản phẩm thường có thể được ưu tiên hơn là làm theo cách "đúng". Đây là một thực tế phổ biến đến nỗi nó có một tên: Nợ kỹ thuật.

5. Một số kiến ​​trúc phần mềm được sử dụng phổ biến là không lý tưởng. Thực tiễn tốt nhất đang phát triển từ các ứng dụng lớn, nguyên khối hướng tới các bộ sưu tập mô-đun kết hợp lỏng lẻo.

6. Bối cảnh rất quan trọng. Nhiều nguyên tắc kiến ​​trúc chỉ chứng minh giá trị của chúng khi bạn làm việc với các chương trình lớn hoặc các miền cụ thể. Ví dụ, kế thừa hầu hết hữu ích cho các hệ thống phân cấp UI và các cấu trúc khác được hưởng lợi từ các sắp xếp được lồng ghép chặt chẽ, gắn kết chặt chẽ.

Vậy làm thế nào để bạn đi theo một con đường "đúng", một con đường nguyên tắc, để bạn có thể nổi lên từ nơi hoang dã?

1. Nghiên cứu sự phù hợp, hơn là tính đúng đắn. Cách "đúng" để làm bất cứ điều gì trong phát triển phần mềm là cách đáp ứng hiệu quả nhất các yêu cầu cụ thể của bạn.
2. Nghiên cứu đánh đổi. Tất cả mọi thứ trong phát triển phần mềm là một sự đánh đổi. Bạn có muốn sử dụng nhiều tốc độ hơn hoặc ít bộ nhớ hơn? Bạn có muốn một ngôn ngữ lập trình rất biểu cảm với ít học viên, hoặc một ngôn ngữ ít biểu cảm mà nhiều nhà phát triển biết không?

3. Nghiên cứu vượt thời gian. Một số nguyên tắc đã đứng trước thử thách của thời gian và sẽ luôn có liên quan. Loại hệ thống là phổ quát. Chức năng hạng nhất là phổ quát. Cấu trúc dữ liệu là phổ quát.

4. Học chủ nghĩa thực dụng. Thực tế là quan trọng. Độ tinh khiết toán học, kiến ​​trúc nhà thờ pha lê và các nguyên tắc tháp ngà là vô dụng nếu bạn không thể vận chuyển.

5. Hãy là một nghệ nhân, không phải là một người nhiệt tình. Các nhà phát triển phần mềm tốt nhất là những người biết các quy tắc, và sau đó biết cách phá vỡ chúng khi có ý nghĩa để làm như vậy. Họ là những người vẫn biết cách giải quyết vấn đề và tự suy nghĩ. Họ sử dụng các nguyên tắc để thông báo và hướng dẫn lựa chọn của họ, không sai khiến họ.
6. Viết mã. Rất nhiều của nó. Nguyên tắc thiết kế phần mềm là tối ưu hóa sớm cho đến khi bạn viết rất nhiều mã và phát triển bản năng về cách áp dụng chúng một cách chính xác.

Nó không hiếm cho lắm. Một điều cần nhận ra là ngành công nghiệp phần mềm rất đa dạng. Một số công ty đang cắt giảm. Các trường đại học hàng đầu và các công ty phần mềm sáng tạo (thậm chí một số phòng thí nghiệm lớn!) Cũng như những người hay nhóm người may mắn như nhóm bốn người phân tích các vấn đề xảy ra với những cách phổ biến để làm mọi thứ và phát minh ra ngôn ngữ, máy móc, công cụ và mô hình mới. Các công ty mới, thường tách ra hoặc tách ra, cố gắng sử dụng những thương mại đó, và đôi khi có được thành công đáng kinh ngạc. Hãy suy nghĩ Facebook hoặc Google.

Nhưng phần mềm được sử dụng hầu hết mọi nơi trong những ngày này, có lẽ chủ yếu ở các công ty không thực sự là công ty phần mềm. Tôi đã làm việc chủ yếu trong ngành vận tải (ô tô và đường sắt), và có một túi kinh nghiệm hỗn hợp. Nhưng không ai trong số họ ở gần "đỉnh cao". Đôi khi họ không thể; phần mềm liên quan đến an toàn phụ thuộc vào các công cụ được hiệu đính tốt (chúng tôi hiện đang sử dụng trình biên dịch C ++ được xác thực từ những năm 1990). Đôi khi họ không có đúng người. Thông thường phần mềm được phát triển bởi các kỹ sư trong các lĩnh vực khác, những người tình cờ chuyển sang phát triển phần mềm trong công ty của họ khi phần mềm ngày càng trở nên quan trọng. Người ta không thể mong đợi họ biết hoặc sử dụng các nguyên tắc kỹ thuật phần mềm.

Một điều khác cần xem xét là những gì quan trọng trong một kỹ sư trong thế giới thực. Thường thì nhiệm vụ trong tay là, hoàn toàn theo nghĩa đen, không phải là khoa học tên lửa. Các vấn đề bánh mì và bơ trong các công ty phi phần mềm có thể được giải quyết bằng các phương tiện phần mềm khiêm tốn. Điều làm cho một kỹ sư phần mềm hữu ích, thậm chí có thể là một phần tạo nên một kỹ sư tổng hợp giỏi: Hãy đáng tin cậy; tổ chức và ghi chép công việc của bạn một cách có trách nhiệm; được hợp tác; lập dự toán chi phí và thời gian tốt (tính hợp lệ của ước tính quan trọng hơn chi phí và thời gian thực tế!); hiểu những gì bạn có thể và không thể làm. Thiếu sót rõ ràng ở đây là "biết và sử dụng các công cụ và quy trình hiện đại". Những gì bạn mô tả là một công ty đã thiết lập một bộ công cụ và quy trình làm việc cho họ. Họ có thể sẽ không bao giờ sản xuất bất cứ điều gì gợi cảm hoặc phi thường, nhưng họ đáp ứng đủ nhu cầu của khách hàng đủ để tạo ra một nguồn doanh thu đủ ổn định. Đó có thể là định nghĩa của kỹ thuật ;-).

Vì vậy, có: Những gì bạn học ở trường đại học thực sự không phổ biến trong nhiều lĩnh vực.

Tôi muốn thêm một phần an ủi, hoặc một ghi chú lạc quan hơn. Những gì bạn học được không nên ném ra khỏi cửa sổ. Bạn có thể áp dụng các nguyên tắc tốt hơn trong công việc hàng ngày, nơi nó không phá vỡ mọi thứ. Có lẽ sẽ có một cửa sổ cơ hội để giới thiệu một công cụ mới hoặc mẫu thiết kế. Cơ hội là tốt nhất khi cách làm cũ gây khó chịu cho đồng nghiệp, hoặc nếu họ gặp vấn đề với việc quản lý sự phức tạp hoặc bảo trì (hai vấn đề độc hại nhất được giải quyết bằng các sáng kiến). Hãy sẵn sàng để cung cấp các cải tiến khi có cơ hội. Hãy là người có ảnh hưởng tích cực và cải thiện dần các phương pháp và công cụ; truyền bá kiến ​​thức nơi nó được đánh giá cao.

Họ sử dụng Biểu mẫu web C # .Net và thực hiện hầu hết mọi thứ trong Mã phía sau với rất ít Lớp bên ngoài

Có lời giải thích của bạn ngay tại đó. Nếu bạn không biết, mã Biểu mẫu Web ngoài luồng hoàn toàn trái ngược với OOP, RẮN, DRY, YAGNI, Mẫu thiết kế, SRP , v.v. Ngay cả các ví dụ chính thức từ Microsoft từ vài năm trước sẽ làm cho bạn co rúm ngày hôm nay.

Các hình thức web đẩy chính nó theo một luồng thủ tục, với một số "sự kiện" giả được kích hoạt bởi các nhấp chuột kiểm soát và tương tự. Các nhà phát triển đã dành nhiều thời gian để làm Biểu mẫu web cũng thường có vẻ miễn cưỡng rời khỏi nó, có lẽ vì họ đã mất quá nhiều thời gian để tìm hiểu vòng đời trang và cách thực hiện các điều khiển được hiển thị linh hoạt mà họ không muốn loại bỏ kiến ​​thức đó ngay bây giờ khi đối mặt với các phương pháp mới hơn / tốt hơn. Một phiên bản vô thức của ngụy biện chi phí chìm. Những nhà phát triển này đã dành nhiều năm để học cách làm xáo trộn các Biểu mẫu Web và bây giờ sẽ không dễ dàng rời khỏi chuyên môn đó, do đó họ nói về thời gian "bảo trì".

Và điều này khá phổ biến trong không gian .NET Web Forms, btw.

Làm thế nào phổ biến là trong ngành công nghiệp phần mềm?

Rất phổ biến. Về sự phổ biến tương tự như có một thợ sửa ống nước phá hủy hệ thống ống nước của bạn, một thợ mộc giao rác, hoặc một thợ may rẻ tiền làm cho một bộ đồ không phù hợp. Tức là tất cả con người.

Có một lý do chính đáng tại sao điều này xảy ra: những người không thực sự được đào tạo (hoặc không nhiệt tình) phải thực hiện một cái gì đó dưới áp lực.

Đây không phải là vấn đề của những người đó, chủ yếu, mà thường là về các cấu trúc xung quanh phát triển phần mềm trong công ty đó. Ví dụ, một công ty có thể có một nhóm thực tập viên phát triển phần mềm nội bộ của họ; ngay cả khi những thực tập viên đó thông minh và hiểu biết, họ sẽ chỉ ở đó trong vài tuần hoặc vài tháng và quyền sở hữu sẽ chuyển đổi thường xuyên.

Hoặc một số người tuyệt vời trong miền, nhưng không phải là lập trình viên, có thể hack một số ứng dụng VBA, v.v. bởi vì nó có vẻ khá dễ dàng ngay từ đầu.

Hoặc một ứng dụng được tạo ra kết thúc trong giai đoạn bảo trì, tất cả các nhà phát triển giỏi đều tiếp tục và sau đó nó sẽ tiếp tục được phát triển bởi một số người (trường hợp xấu nhất: một người) ít biết về nó, không có tài liệu, v.v.

Làm cách nào tôi có thể đảm bảo rằng tôi luôn đứng đầu OOP và các nguyên tắc liên quan? Tôi luyện tập trong thời gian rảnh rỗi và tôi cảm thấy mình thực sự cần phải làm việc dưới một nhà phát triển có kinh nghiệm hơn để trở nên tốt hơn tại OOP.

Có hai câu trả lời có thể:

• Hoặc là: thảo luận điều này với sếp của bạn và đảm bảo bạn tham gia vào các dự án sạch sẽ. Nếu không thể, hãy tìm một ông chủ mới.
• Hoặc: tự chịu trách nhiệm về việc này. Điều đó có nghĩa là tự mình làm điều đó - trong thời gian rảnh rỗi, hoặc nếu bạn có thể, trong công ty, nhưng do chính bạn điều khiển (không chắc).

Nếu câu trả lời thứ hai nghe có vẻ quá cay độc đối với bạn, thì hãy để tôi đảm bảo với bạn rằng nó không phải vậy. Một thợ mộc người có một cửa hàng đồ gỗ tại nhà sẽ nhất chắc chắn là một người thợ mộc tốt hơn so với một người thì không.

Ví dụ, điều này hoàn toàn có thể và rất nhiều niềm vui đối với một số người, ví dụ, đào sâu vào một ngôn ngữ mới như Ruby, không chỉ học cú pháp, mà còn hiểu sâu sắc các khía cạnh OO đặc biệt của ngôn ngữ đó và thực sự lặn sâu. Tất cả trong thời gian rảnh rỗi của bạn, mà không có bất kỳ kết nối với công việc của bạn. Nó sẽ chỉ là một sở thích, nhưng là một chuyên gia được đào tạo như bạn, nó có thể hiệu quả (hoặc hơn thế) khi ngồi cạnh một nhà phát triển chính và cố gắng làm theo những gì họ đang làm. Điều này sau đó sẽ được nghiêm ngặt cho sự phát triển cá nhân và niềm vui của riêng bạn. Nếu bạn không vui khi làm điều này, hoặc nếu bạn thấy rằng đơn giản là bạn không thể đạt được bất kỳ sự hiểu biết nào, thì hãy gãi nó và quay lại câu trả lời đầu tiên.

Đó là phát triển dẫn người đang đào tạo bạn đã khá có khả năng học được những thứ mà chính xác theo cách này ...

Tôi nghĩ rằng ở Tây Ban Nha là một hằng số bởi vì khi một nhà phát triển vượt qua nhiều năm trong một công ty, anh ấy (hoặc cô ấy) thường được thăng chức lên nhiều lĩnh vực quản lý như phân tích và quản lý dự án. Kết quả là không có đánh giá ngang hàng được thực hiện và mã thường được viết bởi những người ít kinh nghiệm hơn.

Thất bại của những người có kinh nghiệm này không bao giờ được sửa chữa: thay vào đó, họ chỉ tập trung để hoàn thành công việc. Kết quả là, ngày càng có nhiều thực hành sai được tích lũy trong mã.

Cuối cùng, một số ass thông minh nói rằng "giải pháp" tốt nhất là thay đổi sang một công nghệ mới nổi sẽ tạo ra mã sạch hơn và dễ bảo trì hơn, tạo ra một ứng dụng mới. Như thể công nghệ tự nó có thể làm điều đó.

Một lần nữa, các lập trình viên chưa có kinh nghiệm được đưa vào làm việc trong công nghệ mới đó, không ai xem lại mã và vòng tròn được đóng lại .... mãi mãi ....

Một số "thực hành tốt nhất" mà bạn học được ở trường không thực tế hoặc hiệu quả về chi phí đối với các dự án trong thế giới thực. Một trong những thay đổi lớn nhất tôi nhận thấy là trong định dạng và bình luận. Hầu hết các giáo sư của tôi nhấn mạnh tầm quan trọng của việc viết tư liệu rộng rãi cho mã của bạn, nhưng trong thế giới thực, mã tốt thường không phải là tự giải thích và quan trọng hơn là nhiều ông chủ không muốn trả tiền cho bạn để dành thêm thời gian viết bình luận.

Đôi khi bạn sẽ thấy các lập trình viên bị ép thời gian sử dụng các phím tắt và các mẫu chống yêu cầu ít nồi hơi hơn các giải pháp chất lượng.

Tuy nhiên, một trong những vấn đề lớn nhất tôi nhận thấy ở nhiều nhóm và dự án là không sẵn lòng học hỏi những điều mới. Nhiều lập trình viên lớn tuổi mà tôi đã nói chuyện đã bắt đầu sự nghiệp của họ trong thời kỳ "Miền Tây hoang dã" khi trình độ bắt đầu và kết thúc với sự sẵn sàng viết mã. Họ thường học chuyên ngành trong các lĩnh vực hoàn toàn khác nhau và nhảy vào lập trình với ít hoặc không có giáo dục chính thức khi có cơ hội (ví dụ: chủ nhân của họ không có lập trình viên và cần ai đó học để xây dựng phần mềm nội bộ). Một số lập trình viên tự học cũ này không bao giờ nỗ lực để học các thực hành mã hóa hiện đại, và tiếp tục viết mã theo bất kỳ phong cách nào họ đã học cách đây hàng thập kỷ. Khi họ kết thúc phụ trách các dự án mới do thâm niên, họ có xu hướng giữ lại các dự án và làm tổn hại đến chất lượng mã tổng thể.

Tất nhiên, những điều trên không áp dụng cho tất cả các lập trình viên cũ và các lập trình viên thế hệ mới hơn có thể giống như tội lỗi. Tôi đã làm việc với nhiều lập trình viên trẻ tuổi, người đã chọn một vài công cụ và thư viện mới ra trường và sau đó ngừng học hoàn toàn. Họ sẽ tải xuống IDE hoặc thư viện một lần và không bao giờ cập nhật nó trừ khi công ty của họ yêu cầu (đôi khi bạn có thể đoán được lập trình viên tốt nghiệp năm nào dựa trên thư viện của anh ta đã lỗi thời). Họ không theo kịp các tính năng mới trong (các) ngôn ngữ họ chọn và không bao giờ học ngôn ngữ mới. Họ không học các chiến lược lập trình mới và có thể lạm dụng các mô hình hoặc mô hình vì họ không biết các lựa chọn thay thế phù hợp hơn (oh MVC, bạn đã lạm dụng nghệ thuật nhiều như thế nào). Thời gian trôi qua, quy trình làm việc của họ ngày càng trở nên lỗi thời và họ trở thành một người có trách nhiệm hơn là một tài sản.

Tóm lại, hai trong số những nguyên nhân lớn nhất của các cơ sở mã hóa lộn xộn là thời hạn gấp rút và các lập trình viên với kiến ​​thức lỗi thời hoặc không đầy đủ. Thật không may, trách nhiệm cho cả hai vấn đề có thể ảnh hưởng lớn đến ông chủ hoặc CTO, người phải đảm bảo rằng thời hạn là thực tế và nhân viên luôn cập nhật về kiến ​​thức và kỹ năng của họ. Nếu ông chủ không biết gì về thực hành lập trình tốt, điều tốt nhất bạn có thể làm là cố gắng đề xuất thay đổi và hy vọng họ cởi mở với các đề xuất. Thật không may, họ có thể có xu hướng tin tưởng vào lời của một lập trình viên cao cấp hơn, những người không hiểu OOP và thích viết 10.000 lớp dòng.

Một số thực tiễn lập trình xấu là kết quả của việc phải làm việc với phần mềm cũ bắt đầu phát triển cách đây hàng thập kỷ. Nếu có một phần mềm phức tạp khổng lồ, viết lại mọi thứ có thể không phải là một lựa chọn. Thậm chí có thể cực kỳ khó hiểu mọi thứ mà mã thực sự đang làm. Tùy chọn tốt nhất có thể là chỉ sao chép những gì hoạt động trong khi cũng cố gắng tích hợp các thực tiễn lập trình tốt hơn nếu bạn có thể làm như vậy mà không phá vỡ bất cứ điều gì.

Tôi nghĩ điều quan trọng không chỉ là nói đúng từ sai mà còn phải biết lý do đằng sau mọi điều đúng và sai. Khi bạn biết lý do bạn có thể dự đoán hậu quả. Tại sao sử dụng nguyên tắc này hay nguyên tắc đó không phải vì nó được mô tả trong một cuốn sách, mà bởi vì chúng ta biết nó giúp ích như thế nào và chính xác những gì xảy ra nên chúng ta phá vỡ nó. Nếu bạn biết điều gì xảy ra khi đó bạn có thể cân nhắc ưu và nhược điểm và đưa ra quyết định. Điều này cũng sẽ giúp bạn tranh luận vị trí của bạn mỗi lần. RẮN và OOP cũng có thể giảm bảo trì nếu được sử dụng tốt.

RẮN nếu được sử dụng quá giáo điều dẫn đến quá nhiều lớp và phương pháp không tốt cho lắm. Đừng làm quá. Đây là một phần vấn đề lớn với sách giáo khoa và hướng dẫn của chúng tôi vì họ thường cố gắng thúc đẩy các ý tưởng mà không có lý do chính đáng. OOP cũng có nhược điểm của nó. Nhiều nguyên tắc và mô thức mâu thuẫn với nhau. Bạn không cần phải đứng đầu, bạn cần làm mọi thứ hợp lý, hợp lý, thanh lịch và đơn giản.

Ngoài ra, vì đây là công việc đầu tiên của bạn, rất có thể những lập trình viên này không có nhiều kỹ năng. Nhưng một lần nữa, có lẽ họ đang được tin tưởng với những nhiệm vụ không quá khó có thể được thực hiện mà không cần nhiều kỹ năng và với mức lương thấp hơn bởi các lập trình viên rẻ hơn có tay nghề thấp hơn. Đây là cách kinh tế làm việc. Mỗi nơi làm việc là khác nhau.

Tôi hiểu bạn cảm thấy thế nào. Đừng hoảng sợ . Bạn sẽ cần những gì bạn biết, có thể không ngay lập tức, nhưng nó sẽ giúp bạn. Có thể ở một nơi làm việc khác, có thể trong một số dịp. Bạn có thời gian trước bạn để đi xa hơn.