Các mô hình chống tồi tệ nhất bạn đã gặp trong sự nghiệp là một lập trình viên là gì?

Tôi chủ yếu tham gia vào java, mặc dù nó có thể độc lập với ngôn ngữ.

Tôi nghĩ điều tồi tệ nhất của nó là cái mà tôi gọi là mô hình chống chính . Nó có nghĩa là chương trình bao gồm một lớp duy nhất, cực kỳ lớn (đôi khi đi kèm với một cặp các lớp nhỏ) chứa tất cả logic. Thông thường với một vòng lặp lớn chứa tất cả logic kinh doanh, đôi khi có hàng chục ngàn dòng mã.

Nhận xét ra mã. Khối của nó, có thể hàng trăm dòng. Theo lý thuyết, nó được bình luận, nó không gây hại gì và có thể chúng ta sẽ cần nó trong tương lai.

Tôi sẽ nhấn một cái rõ ràng khác với "copy-pasta". Sao chép mã gần giống với những gì bạn muốn, sau đó thay đổi một số thứ (thay vì trích xuất thành một phương thức).

Điều này đặc biệt phổ biến trong một số mã kiểm tra chức năng và API từ cuối những năm 90: Nghĩa đen là hàng trăm (hoặc thậm chí hàng ngàn) trường hợp kiểm thử gần giống nhau có thể được chia thành một vài chức năng có 3 hoặc 4 tham số - hoặc thậm chí tốt hơn , một cái gì đó dựa trên dữ liệu. Công việc đầu tiên của tôi khi ra trường là đúng 8 tháng viết lại và tái cấu trúc hàng ngàn dòng mì ống đang sử dụng các phương pháp không dùng nữa. Vào thời điểm tôi hoàn thành, các tệp kiểm tra nhỏ hơn một phần 10 kích thước ban đầu của chúng và dễ bảo trì hơn nhiều (và có thể đọc được!).

Tôi nghĩ rằng tôi có thể viết rất nhiều về Mô hình Mania và các giải pháp có thể được giải quyết với ít nỗ lực hơn, nhưng tôi muốn chỉ ra một bài viết tuyệt vời mà tôi đã đọc gần đây với một ví dụ tuyệt vời về cách một giải pháp đơn giản có thể được áp dụng quá mức .

Làm thế nào (không) để viết Factorial bằng Java hoặc do đó chúng tôi đưa một nhà máy vào thuật toán của bạn

Búa vàng

Tôi có một cái búa và mọi thứ khác là một cái đinh.

Vùng

Trong C #, bạn có thể xác định vùng mã có thể được thu gọn trong IDE, do đó ẩn nó trừ khi bạn muốn xử lý mã đó. Tôi đã tham gia (hiện đang thực hiện) một dự án trong đó các vùng kéo dài hàng trăm dòng (ước gì tôi đang phóng đại) và có nhiều vùng trong một hàm hàng nghìn (một lần nữa tôi ước mình đang đùa).

Về mặt tích cực, nhà phát triển đã tạo ra khu vực đã làm rất tốt trong việc xác định các chức năng cụ thể trong một khu vực. Đến nỗi tôi đã có thể thực hiện một phương pháp trích xuất trong khu vực và tiếp tục.

Các khu vực khuyến khích các nhà phát triển "che giấu" tào lao của họ trong tầm nhìn rõ ràng.

Đối với tôi mẫu tồi tệ nhất là Sao chép / Dán .

Phương pháp không quá tải:

// Do something
public int doSomething(Data d);

// Do same thing, but with some other data
public int doSomething2(SomeOtherData d);

Rõ ràng cho thấy rằng các lập trình viên không hiểu quá tải.

Trình tự chuyển mạch vòng

http://en.wikipedia.org/wiki/Loop-switch_ resultence

Họ làm phiền tôi đến tận cùng và thực sự cho thấy các nhà phát triển thiếu kinh nghiệm như thế nào

Mã hóa mềm , tức là khi các lập trình viên ra khỏi con đường của họ để tránh mã hóa cứng và kết thúc ở phía bên kia của thang đo - phụ thuộc "mã hóa cứng".

Giữ trạng thái trong khách hàng.

Sau khi làm việc với một ứng dụng web trong đó tất cả trạng thái được giữ trong trình duyệt. (Để đảm bảo khả năng mở rộng không gặp sự cố, tất cả các ngoại lệ đã bị bỏ qua).

Checkins lớn

Tôi ghét khi tôi thấy một nhà phát triển đã không thực hiện đăng ký trong hơn một tuần. Điều đó có nghĩa là anh ta hoặc bị mắc kẹt và không tìm kiếm sự giúp đỡ, hoặc anh ta kết hợp một loạt các tính năng vào một lần đăng ký lớn. (Tôi đã bỏ qua tình huống xấu nhất, anh ta không làm gì cả. Thật dễ để giải quyết ... hai từ nghe có vẻ như bạn được thuê.)

Nếu bạn đang thực hiện một đăng ký lớn, bạn sẽ mất rất nhiều lợi ích của SCM, như có thể liên kết một thay đổi với một tính năng cụ thể. Ngoài ra, bạn có thể có rất nhiều việc phải làm và điều đó không nhất thiết phải dễ dàng để làm đúng.

Hiện tại, tôi đang làm việc với một đoạn mã kế thừa và tôi thích cách mà lập trình viên trước đó có được yếu tố đầu tiên của danh sách:

String result;
for(int i = 0; i < someList.size(); i++) {
    result = someList.get(i);
    break;
}

Nhưng điều tồi tệ nhất tôi từng thấy trong mã này là xác định các lớp trang JSP nội tuyến, viết tất cả HTML, CSS và Javascript bằng scriptlet và out.println :-(

Một trong những kiểu chống hành vi tồi tệ nhất mà tôi đã thấy là một cửa hàng chỉ cho phép mã được kiểm tra để kiểm soát phiên bản sau khi nó được sản xuất. Kết hợp với kiểm tra độc quyền trong VSS, điều này dẫn đến một quá trình hoàn tác khó kiểm tra nếu một lỗi sản xuất cần được sửa chữa trước khi phát hành tiếp theo, chứ đừng nói đến việc nhiều người cần thay đổi một tệp nhất định cho bản phát hành sắp tới.

Thực tế rằng đây là một chính sách bộ phận làm cho nó thậm chí còn tồi tệ hơn trường hợp của một nhà phát triển duy nhất hành xử theo cách này.

Khóa trên một chuỗi chữ

synchronized("one") { /* block one A*/ }

synchronized("one") { /* block one B*/ }

Tên lớp rất dài. (trong JRE)

com.sun.java.swing.plaf.nimbus.
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

Cơ cấu thừa kế kém

com.sun.corba.se.internal.Interceptors.PIORB extends
com.sun.corba.se.internal.POA.POAORB extends
com.sun.corba.se.internal.iiop.ORB extends
com.sun.corba.se.impl.orb.ORBImpl extends
com.sun.corba.se.spi.orb.ORB extends
com.sun.corba.se.org.omg.CORBA.ORB extends 
org.omg.CORBA_2_3.ORB extends
org.omg.CORBA.ORB

Một ngoại lệ không phải là.

public interface FlavorException { }

Xử lý lỗi vô nghĩa và khó hiểu

if (properties.size() > 10000)
   System.exit(0);

Tạo vật thể không cần thiết

Class clazz = new Integer(0).getClass();
int num = new Integer(text).intValue();

Ném một ngoại lệ cho các mục đích khác

try {
    Integer i = null;
    Integer j = i.intValue();
} catch (NullPointerException e) {
    System.out.println("Entering "+e.getStackTrace()[0]);
}

Sử dụng các đối tượng thể hiện cho các phương thức tĩnh.

Thread.currentThread().sleep(100);

Đồng bộ hóa trên một trường không phải là cuối cùng

synchronized(list) {
   list = new ArrayList();
}

Bản sao vô nghĩa của một chuỗi không đổi

String s = new String("Hello world");

Cuộc gọi vô nghĩa đến String.toString ()

String s = "Hello";
String t = s.toString() + " World";

Gọi tới System.gc () để giải phóng bộ nhớ

Đặt biến cục bộ thành null để giải phóng bộ nhớ

    // list is out of scope anyway.
    list = null;
}

Sử dụng ++ i thay vì i ++ vì lý do hiệu suất (hoặc bất kỳ tối ưu hóa vi mô nào khác)

Mã rắc:

// TODO: 

hoặc là

// TODO: implement feature 

không có thêm thông tin.

Lặp đi lặp lại cho người giả:

Iterator iCollection = collection.iterator();
for(int i = 0 ; i < collection.size() ; i++ ){
    if(collection.get(i) == something){
       iCollection.remove();
    }
 }

Xưởng sản xuất Singletono:

public class SomeObject{
   private SomeObject() {}
   public static SomeObject getInstance(){
       return new SomeObject();
   }
}

if-other thúc đẩy phát triển (còn được gọi là nguyên tắc đóng mở - mở để sửa đổi gần để hiểu):

if (sth1){
...  
}else if(sth2){
..
}
...
..
else if(sth1000000000000){
...
}

StringPotype (còn được gọi là StringObject):

a) sendercode
if(sth1)
   str+="#a";
if(sth2)
   str+="#b";
...
if(sth1000)
   str+="#n";

b) receiver
   regexp testing if str contains #a, #b, ... #n

Nó không quá giống với mẫu mã hóa mà là mẫu hành vi, mặc dù nó khá tệ: sửa đổi một cái gì đó trong mã (giả sử các yêu cầu đã thay đổi), sau đó điều chỉnh tất cả các thử nghiệm đơn vị cho đến khi mã vượt qua. Tinh chỉnh hoặc đơn giản là loại bỏ tất cả mã kiểm tra khỏi phương thức kiểm tra, nhưng để phương thức đó ở đó.

Mặc dù vậy, điều này được liên kết với một mẫu chung hơn, mẫu Điều đó sẽ làm , đây là một dòng mã đại diện cho nó:

int num = new Integer( stringParam ).parseInt( stringParam );

Nó hoạt động, sau khi tất cả.

Tôi hoàn toàn coi thường sự đảo ngược trừu tượng , hoặc phát minh lại các nguyên thủy cấp thấp trên các nguyên thủy cấp cao. Đôi khi, mặc dù, điều này được gây ra bởi các nhà thiết kế ngôn ngữ xấu, không phải lập trình viên xấu. Ví dụ:

1. Sử dụng một lớp phương thức duy nhất không có biến thành viên và giao diện tương ứng, (được thực hiện theo các bảng của con trỏ hàm), thay vì một con trỏ hàm. Lưu ý rằng trong các ngôn ngữ như Java, bạn có thể không có lựa chọn nào khác.

2. Trong MATLAB và R, nhấn mạnh rằng mọi thứ là một vectơ / ma trận chứ không phải là nguyên thủy.

3. Trong khi chúng ta đánh bại MATLAB, thì thực tế là nó không có số nguyên, vì vậy khi bạn cần một số nguyên, bạn phải sử dụng một số kép.

4. Các ngôn ngữ chức năng thuần túy nơi bạn phải sử dụng các lệnh gọi hàm để viết một vòng lặp.

Nó chắc chắn sẽ được sao chép / dán, tôi đã thấy rất nhiều mã xấu được thực hiện vì nó, mã hóa cao bồi và mọi thứ bắt nguồn từ đó. (Các lớp học thần, phương pháp cực lớn, thuật toán suy nghĩ xấu, v.v.)

Và nếu các mẫu thiết kế được cho phép, chúng sẽ nói: Thực hiện một dự án như một tập hợp các hành động từ một kế hoạch, mà không thực hiện bất kỳ phân tích thiết kế hoặc miền nào.

Đậu java đa dụng -

Một java bean có rất nhiều biến, được sử dụng trong một vài loại hoạt động khác nhau. Mỗi hoạt động sử dụng một số tập hợp con tùy ý của các biến bean và bỏ qua các biến khác. Một vài biến cho trạng thái gui, một vài biến được đưa vào để chuyển xung quanh giữa các thành phần, một số biến có thể thậm chí không được sử dụng nữa. Các ví dụ tốt nhất không có tài liệu, điều này sẽ cản trở sự đánh giá của mẫu.

Ngoài ra, không thể quên người yêu dấu

try{ 
   ... //many lines of likely dangerous operations
}
catch(Exception e){}

Một đồng nghiệp cũ có thói quen sử dụng lại các đối tượng bằng cách ghi đè các thuộc tính của họ, thay vì chỉ đơn giản là tạo các đối tượng mới. Tôi không bao giờ có thể tưởng tượng được số lượng vấn đề này đã gây ra khi thực hiện các tính năng mới.

Một cái gì đó đã gây cho tôi rất nhiều đau buồn là mô hình "Bản đồ lớn trên bầu trời". Ném xung quanh một bản đồ thay vì sử dụng các đối tượng thích hợp. Bạn không biết nó chứa "biến" nào mà không cần gỡ lỗi và bạn không biết nó có thể chứa gì mà không theo dõi mã ngược. Thông thường ánh xạ Chuỗi thành Đối tượng hoặc Chuỗi thành Chuỗi, mà bạn có khả năng phải phân tích cú pháp thành nguyên thủy.

Một trong những kiểu chống phát triển yêu thích của tôi là việc sử dụng "thiết kế" cơ sở dữ liệu yêu cầu liên tục thêm các cột bổ sung vào một hoặc nhiều bảng theo chương trình . Đây là anh em họ của "thiết kế" tạo ra một bảng mới cho mỗi phiên bản của một thực thể. Cả hai chắc chắn gặp phải những hạn chế của máy chủ cơ sở dữ liệu, nhưng thường là cho đến khi hệ thống được sản xuất khá lâu.

Tôi nghĩ rằng một trong những kiểu chống tồi tệ nhất tôi từng thấy liên quan đến việc sử dụng bảng Cơ sở dữ liệu làm bộ nhớ tạm thời thay vì sử dụng bộ nhớ máy tính.

Miền vấn đề là độc quyền khiến tôi không thể giải thích nó, nhưng không cần thiết phải hiểu vấn đề cơ bản. Đây là một ứng dụng GUI được viết bằng Java với Cơ sở dữ liệu phụ trợ. Đó là lấy một số dữ liệu đầu vào, thao tác và sau đó cam kết dữ liệu đã xử lý vào cơ sở dữ liệu.

Dự án của chúng tôi có một thuật toán khá phức tạp giúp lưu các giá trị trung gian để xử lý sau này. Thay vì đóng gói các đối tượng tạm thời trong ... các đối tượng, một bảng cơ sở dữ liệu đã được tạo như vậy "t_object". Mỗi khi một giá trị được tính toán, nó được thêm vào bảng này. Sau khi thuật toán hoàn thành, nó sẽ chọn tất cả các giá trị trung gian và xử lý tất cả chúng trong một đối tượng Bản đồ lớn. Sau khi tất cả quá trình xử lý đã kết thúc, các giá trị còn lại được đánh dấu sẽ lưu sẽ được thêm vào lược đồ cơ sở dữ liệu thực và các mục tạm thời trong bảng "t_object" sẽ bị loại bỏ.

Bảng cũng được sử dụng như một danh sách duy nhất, dữ liệu chỉ có thể tồn tại một lần. Đây có thể là một tính năng tốt của thiết kế nếu chúng tôi đã triển khai các ràng buộc trên bảng, nhưng cuối cùng chúng tôi đã lặp lại qua toàn bộ bảng để xem liệu dữ liệu có tồn tại hay không. (Không, chúng tôi thậm chí không sử dụng các truy vấn được sử dụng trong các mệnh đề có CONTAIN)

Một số vấn đề chúng tôi gặp phải do thiết kế này đã được gỡ lỗi cụ thể. Ứng dụng được xây dựng để truyền dữ liệu, do đó sẽ có nhiều GUI xử lý trước dữ liệu trước khi đến thuật toán này. Quá trình gỡ lỗi là xử lý một trường hợp thử nghiệm và sau đó tạm dừng ngay sau khi hoàn thành phần trên. Sau đó, chúng tôi sẽ truy vấn cơ sở dữ liệu để xem dữ liệu nào được chứa trong bảng này.

Một vấn đề khác mà chúng tôi phát hiện ra là dữ liệu không được xóa đúng cách khỏi bảng tạm thời này, điều này sẽ gây trở ngại cho việc chạy trong tương lai. Chúng tôi phát hiện ra điều này là do Ngoại lệ không được xử lý đúng cách và do đó ứng dụng không thoát đúng cách và không xóa dữ liệu trong bảng mà nó kiểm soát.

Nếu chúng ta đã sử dụng Thiết kế hướng đối tượng cơ bản và giữ mọi thứ trong Bộ nhớ, những vấn đề trên sẽ không bao giờ xảy ra. Đầu tiên, việc gỡ lỗi sẽ đơn giản vì chúng ta có thể dễ dàng thiết lập các điểm ngắt trong ứng dụng và sau đó kiểm tra bộ nhớ trong ngăn xếp và đống. Thứ hai, khi thoát khỏi ứng dụng bất thường, bộ nhớ java sẽ được dọn sạch một cách tự nhiên mà không phải lo lắng về việc xóa nó khỏi cơ sở dữ liệu.

LƯU Ý: Tôi không nói rằng mô hình này vốn đã xấu, nhưng trong ví dụ này tôi thấy nó không cần thiết khi các nguyên tắc OO cơ bản sẽ có hiệu lực.

Tôi không chắc chắn về tên cho mẫu chống này vì đây là lần đầu tiên tôi thấy bất cứ điều gì như thế này được thực hiện. Bất kỳ tên tốt mà các bạn có thể nghĩ cho mô hình này?

Giỏ hàng trước khi ngựa - còn gọi là YouMightNeedIt

Ví dụ:

• Tạo một lược đồ RDMB với các khái niệm trừu tượng, các tham chiếu chéo - về bản chất là một khối dữ liệu được khái quát hóa quá mức ... Và THEN viết các tính năng xung quanh một mô hình mọi thứ.

IMO mẫu chống mẫu tồi tệ nhất tôi từng thấy là "Chúng tôi không cần bất kỳ mẫu nào của stinkin": Ý tưởng cho rằng các mẫu thiết kế rất lãng phí thời gian và bạn có thể viết mã nhanh hơn bằng cách ghép chúng lại và sao chép / dán khi cần thiết.

Đề cập đáng trân trọng là có mã tải một đối tượng từ cơ sở dữ liệu bằng cách sử dụng kiểu VB6 cũ của:

Foobar oFoo = new Foobar();
oFoo.FooID = 42;
if (oFoo.Load()) { 
    // do something with oFoo
}

không thực sự là một mô hình chống đối, nhưng cho thấy sự thiếu tận dụng kiến ​​trúc phù hợp và tách biệt các mối quan tâm.

Ngoài ra, những thứ như thế này:

// this name is misleading, we may not always want to stand in fire,
// we may want to stand in slime or voidzones or ice patches...
public Foobar StandInFire() { }

// why is this here???
public string BeatWithNerfBat(string whom) { }

// ????
public int GivePony(string to) { }