Thực hành lập trình nào mà bạn từng thích kể từ khi bạn thay đổi ý định? [đóng cửa]

Khi chúng tôi lập trình, tất cả chúng tôi đều phát triển các phương pháp và mẫu mà chúng tôi sử dụng và dựa vào. Tuy nhiên, theo thời gian, khi sự hiểu biết, sự trưởng thành và thậm chí cả cách sử dụng công nghệ của chúng ta thay đổi, chúng ta nhận ra rằng một số phương pháp mà chúng ta từng cho là tuyệt vời đã không (hoặc không còn được áp dụng).

Một ví dụ về một thực hành mà tôi đã từng sử dụng khá thường xuyên, nhưng đã thay đổi trong những năm gần đây, đó là việc sử dụng mẫu đối tượng Singleton .

Thông qua kinh nghiệm của bản thân và các cuộc tranh luận lâu dài với các đồng nghiệp, tôi nhận ra rằng các singlelet không phải lúc nào cũng mong muốn - chúng có thể làm cho việc thử nghiệm khó khăn hơn (bằng cách ức chế các kỹ thuật như chế nhạo) và có thể tạo ra sự kết hợp không mong muốn giữa các phần của hệ thống. Thay vào đó, bây giờ tôi sử dụng các nhà máy đối tượng (thường là với một IoC container) để che giấu bản chất và sự tồn tại của các singleton khỏi các phần của hệ thống mà không cần quan tâm - hoặc cần biết. Thay vào đó, họ dựa vào một nhà máy (hoặc bộ định vị dịch vụ) để có được quyền truy cập vào các đối tượng như vậy.

Những câu hỏi của tôi đối với cộng đồng, với tinh thần tự hoàn thiện, là:

• Gần đây bạn đã xem xét lại những mẫu hoặc thực hành lập trình nào và bây giờ cố gắng tránh?
• Bạn đã quyết định thay thế chúng bằng gì?

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Điểm trở lại duy nhất.

Tôi đã từng ưa thích một điểm quay lại duy nhất cho mỗi phương pháp, bởi vì với điều đó, tôi có thể đảm bảo rằng mọi thao tác dọn dẹp cần thiết theo quy trình đều không bị bỏ qua.

Kể từ đó, tôi đã chuyển sang các quy trình nhỏ hơn nhiều - vì vậy khả năng bỏ qua việc dọn dẹp giảm đi và trên thực tế, nhu cầu dọn dẹp cũng giảm - và nhận thấy rằng việc trả về sớm làm giảm độ phức tạp rõ ràng (mức lồng ghép) của mã. Các phần tử của điểm trả về duy nhất - giữ các biến "kết quả" xung quanh, giữ các biến cờ, mệnh đề điều kiện cho các tình huống chưa thực hiện - làm cho mã có vẻ phức tạp hơn nhiều so với thực tế, khiến nó khó đọc và khó bảo trì hơn. Các lối thoát sớm và các phương pháp nhỏ hơn, là cách để đi.

• Cố gắng mã hóa mọi thứ một cách hoàn hảo trong lần thử đầu tiên.
• Cố gắng tạo mô hình OO hoàn hảo trước khi mã hóa.
• Thiết kế mọi thứ để linh hoạt và cải tiến trong tương lai.

Trong một từ khai thác quá mức .

Ký hiệu Hungary (cả Dạng và Hệ thống). Tôi đã sử dụng tiền tố mọi thứ. strSomeString hoặc txtFoo. Bây giờ tôi sử dụng someString và textBoxFoo. Nó dễ đọc hơn và dễ dàng hơn cho một người mới đến và chọn. Như một phần thưởng bổ sung, việc giữ cho nó luôn nhất quán là điều nhỏ nhặt - camelCase kiểm soát và thêm một tên hữu ích / mô tả. Hình thức Hungary có nhược điểm là không phải lúc nào cũng nhất quán và Hệ thống Hungary không thực sự thu được nhiều lợi ích của bạn. Việc gộp tất cả các biến lại với nhau không thực sự hữu ích - đặc biệt là với IDE hiện đại.

Kiến trúc "hoàn hảo"

Tôi đã nghĩ ra kiến trúc THE cách đây vài năm. Đã thúc đẩy bản thân về mặt kỹ thuật hết mức có thể để có 100% các lớp được ghép nối lỏng lẻo, sử dụng rộng rãi các đại biểu và các đối tượng nhẹ. Đó là thiên đường kỹ thuật.

Và nó là tào lao. Sự thuần khiết về mặt kỹ thuật của kiến ​​trúc chỉ khiến nhóm nhà phát triển của tôi chậm lại mục tiêu hướng đến sự hoàn hảo hơn là kết quả và tôi gần như đã thất bại hoàn toàn.

Giờ đây, chúng tôi có kiến ​​trúc đơn giản hơn ít hoàn hảo về mặt kỹ thuật hơn nhiều và tỷ lệ phân phối của chúng tôi đã tăng vọt.

Việc sử dụng caffine. Nó đã từng khiến tôi tỉnh táo và ở trong tâm trạng lập trình vui vẻ, nơi mà mã bay khỏi ngón tay tôi với sự uyển chuyển đáng kinh ngạc. Bây giờ nó không làm gì cả, và nếu tôi không có nó, tôi sẽ đau đầu.

Nhận xét ra mã. Tôi từng nghĩ rằng mã đó là quý giá và bạn không thể xóa những viên ngọc tuyệt đẹp mà bạn đã tạo ra. Bây giờ tôi xóa bất kỳ mã được nhận xét nào mà tôi gặp trừ khi có một VIỆC CẦN LÀM hoặc LƯU Ý được đính kèm vì quá nguy hiểm để để nó vào. Nói một cách dí dỏm, tôi đã xem qua các lớp cũ với các phần được nhận xét rất lớn và tôi thực sự bối rối tại sao chúng đã ở đó: gần đây họ có bình luận không? đây có phải là một sự thay đổi môi trường phát triển không? tại sao nó làm khối không liên quan này?

Hãy nghiêm túc xem xét việc không bình luận về mã và thay vào đó chỉ xóa nó. Nếu bạn cần, nó vẫn nằm trong kiểm soát nguồn. YAGNI mặc dù.

Việc lạm dụng / lạm dụng các chỉ thị # khu vực. Chỉ là một điều nhỏ, nhưng trong C #, trước đây tôi sẽ sử dụng các lệnh #region ở khắp nơi, để tổ chức các lớp học của mình. Ví dụ: tôi muốn nhóm tất cả các thuộc tính của lớp lại với nhau trong một vùng.

Bây giờ tôi nhìn lại mã cũ và hầu hết chỉ thấy khó chịu bởi chúng. Tôi không nghĩ nó thực sự làm cho mọi thứ rõ ràng hơn hầu hết thời gian, và đôi khi chúng chỉ đơn giản là làm chậm bạn. Vì vậy, bây giờ tôi đã thay đổi suy nghĩ của mình và cảm thấy rằng các lớp học được bố trí tốt hầu hết sẽ sạch hơn mà không có chỉ thị vùng.

Phát triển thác nước nói chung và cụ thể, thực hành viết các thông số kỹ thuật thiết kế và chức năng hoàn chỉnh và toàn diện, bằng cách nào đó được mong đợi là chuẩn và sau đó mong đợi việc triển khai các thông số kỹ thuật đó là đúng và được chấp nhận. Tôi đã thấy nó được thay thế bằng Scrum, và tôi nói. Thực tế đơn giản là bản chất thay đổi của nhu cầu và mong muốn của khách hàng làm cho bất kỳ thông số kỹ thuật cố định nào trở nên vô dụng; cách duy nhất để thực sự tiếp cận đúng vấn đề là với cách tiếp cận lặp lại. Tất nhiên, không phải Scrum là một viên đạn bạc; Tôi đã thấy nó bị lạm dụng và lạm dụng rất nhiều lần. Nhưng nó đập thác.

Không bao giờ bị rơi.

Nó có vẻ là một ý tưởng hay, phải không? Người dùng không thích các chương trình bị lỗi, vì vậy chúng ta hãy viết các chương trình không bị lỗi, và người dùng nên thích chương trình, phải không? Đó là cách tôi bắt đầu.

Ngày nay, tôi có xu hướng nghĩ rằng nếu nó không hoạt động, nó không nên giả vờ như nó đang hoạt động. Không thành công ngay khi bạn có thể, với một thông báo lỗi tốt. Nếu bạn không làm như vậy, chương trình của bạn sẽ gặp sự cố thậm chí còn khó hơn chỉ với một vài hướng dẫn sau đó, nhưng với một số lỗi null-pointer nondescript sẽ khiến bạn mất một giờ để gỡ lỗi.

Mẫu "không bị rơi" yêu thích của tôi là:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

Bây giờ, thay vì yêu cầu người dùng của bạn sao chép / dán thông báo lỗi và gửi cho bạn, bạn sẽ phải đi sâu vào các nhật ký để cố gắng tìm mục nhập nhật ký. (Và vì họ đã nhập ID người dùng không hợp lệ, nên sẽ không có mục nhập nhật ký.)

Tôi nghĩ rằng thật hợp lý khi áp dụng các mẫu thiết kế bất cứ khi nào tôi nhận ra chúng.

Tôi không biết rằng tôi thực sự đang sao chép các kiểu từ các ngôn ngữ lập trình nước ngoài, trong khi ngôn ngữ mà tôi đang làm việc cho phép tạo ra các giải pháp thanh lịch hơn hoặc dễ dàng hơn nhiều.

Việc sử dụng nhiều (rất) ngôn ngữ khác nhau đã giúp tôi mở rộng tầm mắt và khiến tôi nhận ra rằng tôi không cần phải áp dụng sai giải pháp của người khác cho những vấn đề không phải của mình. Bây giờ tôi rùng mình khi nhìn thấy mô hình nhà máy được áp dụng bằng một ngôn ngữ như Ruby.

Thử nghiệm ám ảnh. Tôi đã từng là một người đề xuất điên cuồng về sự phát triển trước tiên thử nghiệm. Đối với một số dự án, nó rất có ý nghĩa, nhưng tôi nhận ra rằng nó không chỉ không khả thi mà còn gây bất lợi cho nhiều dự án nếu tuân thủ chặt chẽ một học thuyết về việc viết các bài kiểm tra đơn vị cho mọi phần chức năng.

Thực sự, quá tuân thủ bất cứ điều gì có thể gây hại.

Đây là một việc nhỏ, nhưng: Quan tâm đến vị trí của các dấu ngoặc nhọn (trên cùng một dòng hay dòng tiếp theo?), Độ dài dòng tối đa được đề xuất của mã, quy ước đặt tên cho các biến và các yếu tố khác của kiểu. Tôi nhận thấy rằng mọi người dường như quan tâm đến điều này hơn tôi, vì vậy tôi chỉ đi theo dòng chảy của bất kỳ ai tôi đang làm việc hiện nay.

Chỉnh sửa: Tất nhiên là ngoại lệ khi tôi là người quan tâm nhất (hoặc là người ở vị trí thiết lập phong cách cho một nhóm). Trong trường hợp đó, tôi làm những gì tôi muốn!

(Lưu ý rằng điều này không giống như không có kiểu nhất quán. Tôi nghĩ rằng một kiểu nhất quán trong cơ sở mã là rất quan trọng để dễ đọc.)

Có lẽ "thực hành lập trình" quan trọng nhất mà tôi đã thay đổi suy nghĩ của mình, đó là ý tưởng rằng mã của tôi tốt hơn những người khác. Điều này là phổ biến đối với các lập trình viên (đặc biệt là người mới).

Các thư viện tiện ích. Tôi đã từng mang theo một hội đồng với nhiều phương thức và lớp trợ giúp khác nhau với lý thuyết rằng một ngày nào đó tôi có thể sử dụng chúng ở một nơi khác.

Trên thực tế, tôi vừa tạo một không gian tên khổng lồ với rất nhiều chức năng được tổ chức kém.

Bây giờ, tôi chỉ để chúng trong dự án mà tôi đã tạo ra. Trong tất cả khả năng tôi sẽ không cần nó, và nếu có, tôi luôn có thể cấu trúc lại chúng thành thứ có thể tái sử dụng sau này. Đôi khi tôi sẽ gắn cờ chúng bằng // TODO để có thể trích xuất vào một hội đồng chung.

Thiết kế nhiều hơn tôi viết mã. Sau một thời gian, nó chuyển thành tê liệt phân tích.

Việc sử dụng DataSet để thực hiện logic nghiệp vụ. Điều này liên kết mã quá chặt chẽ với cơ sở dữ liệu, cũng như DataSet thường được tạo từ SQL, điều này làm cho mọi thứ trở nên mong manh hơn. Nếu SQL hoặc Cơ sở dữ liệu thay đổi, nó có xu hướng nhỏ giọt đến mọi thứ mà DataSet chạm vào.

Thực hiện bất kỳ logic nghiệp vụ nào bên trong một hàm tạo đối tượng. Với sự kế thừa và khả năng tạo các constructor quá tải có xu hướng gây khó khăn cho việc bảo trì.

Viết tắt tên biến / method / table / ...

Tôi đã từng làm điều này mọi lúc, ngay cả khi làm việc bằng các ngôn ngữ không có giới hạn bắt buộc về độ dài của tên (chúng có thể là 255 hoặc gì đó). Một trong những tác dụng phụ là rất nhiều bình luận rải rác khắp mã giải thích các chữ viết tắt (không chuẩn). Và tất nhiên, nếu tên được thay đổi vì bất kỳ lý do gì ...

Bây giờ tôi thích gọi mọi thứ là thực sự của chúng, bằng những cái tên có tính mô tả tốt. chỉ bao gồm các chữ viết tắt tiêu chuẩn . Không cần bao gồm các bình luận vô ích và mã dễ đọc và dễ hiểu hơn nhiều.

Bao bọc các thành phần Truy cập Dữ liệu hiện có, như Thư viện Doanh nghiệp, bằng một lớp tùy chỉnh của các phương thức trợ giúp.

• Nó không làm cho cuộc sống của bất kỳ ai dễ dàng hơn
• Nhiều mã hơn có thể có lỗi trong đó
• Rất nhiều người biết cách sử dụng các thành phần truy cập dữ liệu EntLib. Không ai ngoài nhóm địa phương biết cách sử dụng giải pháp truy cập dữ liệu nội bộ

Lần đầu tiên tôi nghe nói về lập trình hướng đối tượng khi đọc về Smalltalk vào năm 1984, nhưng tôi không có quyền truy cập vào ngôn ngữ oo cho đến khi tôi sử dụng trình biên dịch cfront C ++ vào năm 1992. Cuối cùng tôi đã sử dụng Smalltalk vào năm 1995. Tôi đã háo hức mong đợi. công nghệ và ý tưởng rằng nó sẽ tiết kiệm cho việc phát triển phần mềm.

Bây giờ, tôi chỉ thấy oo là một kỹ thuật có một số ưu điểm, nhưng nó chỉ là một công cụ trong hộp công cụ. Tôi thực hiện hầu hết công việc của mình bằng Python và tôi thường viết các hàm độc lập không phải là thành viên của lớp và tôi thường thu thập các nhóm dữ liệu trong các bộ dữ liệu hoặc danh sách mà trước đây tôi đã tạo một lớp. Tôi vẫn tạo các lớp khi cấu trúc dữ liệu phức tạp hoặc tôi cần hành vi liên kết với dữ liệu, nhưng tôi có xu hướng chống lại nó.

Tôi thực sự quan tâm đến việc thực hiện một số công việc trong Clojure khi tôi có thời gian, điều này không cung cấp các phương tiện oo, mặc dù nó có thể sử dụng các đối tượng Java nếu tôi hiểu đúng. Tôi không sẵn sàng để nói bất cứ điều gì như oo đã chết, nhưng cá nhân tôi không phải là người hâm mộ tôi đã từng.

Trong C #, sử dụng _notationcho các thành viên riêng tư. Bây giờ tôi nghĩ nó xấu xí.

Sau đó, tôi đã đổi thành this.notationdành cho thành viên riêng tư, nhưng nhận thấy tôi không nhất quán trong việc sử dụng nó, vì vậy tôi cũng đã bỏ nó.

Tôi đã ngừng sử dụng phương pháp thiết kế được đề xuất trước khi thực hiện. Làm việc trong một hệ thống hỗn loạn và phức tạp đã buộc tôi phải thay đổi thái độ.

Tất nhiên tôi vẫn làm nghiên cứu mã, đặc biệt là khi tôi chuẩn bị chạm vào mã mà tôi chưa từng chạm vào trước đây, nhưng thông thường tôi cố gắng tập trung vào các triển khai nhỏ nhất có thể để có được thứ gì đó trước. Đây là mục tiêu chính. Sau đó, dần dần tinh chỉnh logic và để thiết kế tự xuất hiện. Lập trình là một quá trình lặp đi lặp lại và hoạt động rất hiệu quả với cách tiếp cận nhanh nhẹn và có nhiều cấu trúc lại.

Mã sẽ không giống với tất cả những gì bạn nghĩ lần đầu tiên nó trông như thế nào. Xảy ra mọi lúc :)

Tôi đã từng rất quan tâm đến việc thiết kế từng hợp đồng. Điều này có nghĩa là phải kiểm tra rất nhiều lỗi ở đầu tất cả các chức năng của tôi. Hợp đồng vẫn quan trọng, từ khía cạnh tách biệt các mối quan tâm, nhưng thay vì cố gắng thực thi những gì mã của tôi không nên làm, tôi cố gắng sử dụng các bài kiểm tra đơn vị để xác minh những gì nó làm.

Tôi sẽ sử dụng static trong rất nhiều phương thức / lớp vì nó ngắn gọn hơn. Khi tôi bắt đầu viết các bài kiểm tra, cách luyện tập đã thay đổi rất nhanh.

Đã kiểm tra ngoại lệ

Một ý tưởng tuyệt vời trên giấy - xác định hợp đồng rõ ràng, không có chỗ cho sai lầm hoặc quên kiểm tra một số điều kiện ngoại lệ. Tôi đã bị bán khi lần đầu tiên tôi nghe về nó.

Tất nhiên, nó trở thành một mớ hỗn độn trong thực tế. Đến mức có các thư viện ngày nay như Spring JDBC, ẩn các ngoại lệ đã kiểm tra kế thừa như một trong những tính năng chính của nó.

Mọi thứ đáng giá chỉ được mã hóa bằng một ngôn ngữ cụ thể. Trong trường hợp của tôi, tôi tin rằng C là ngôn ngữ tốt nhất từ ​​trước đến nay và tôi không bao giờ có lý do gì để viết mã bất kỳ thứ gì bằng bất kỳ ngôn ngữ nào khác ... từ trước đến nay.

Kể từ đó, tôi đánh giá cao nhiều ngôn ngữ khác nhau và những lợi ích / chức năng mà chúng cung cấp. Nếu tôi muốn viết một cái gì đó nhỏ - nhanh chóng - tôi sẽ sử dụng Python. Nếu tôi muốn làm việc trong một dự án lớn, tôi sẽ viết mã bằng C ++ hoặc C #. Nếu tôi muốn phát triển một khối u não, tôi sẽ viết mã ở Perl .

Khi cần tái cấu trúc lại, tôi nghĩ sẽ nhanh hơn và gọn gàng hơn nếu bắt đầu ngay lập tức và triển khai thiết kế mới, sửa các kết nối cho đến khi chúng hoạt động. Sau đó, tôi nhận ra rằng tốt hơn nên thực hiện một loạt các tái cấu trúc nhỏ để tiến triển từ từ nhưng đáng tin cậy đối với thiết kế mới.

Có lẽ điều lớn nhất đã thay đổi trong cách viết mã của tôi, cũng như những người khác, là việc chấp nhận các lớp và thư viện bên ngoài được tải xuống từ internet làm cơ sở cho các hành vi và chức năng trong các ứng dụng. Ở trường vào thời điểm tôi học đại học, chúng tôi được khuyến khích tìm ra cách làm cho mọi thứ tốt hơn thông qua mã riêng của chúng tôi và dựa vào ngôn ngữ để giải quyết vấn đề của chúng tôi. Với những tiến bộ trong tất cả các khía cạnh của giao diện người dùng và dịch vụ / tiêu thụ dữ liệu, đây không còn là một khái niệm thực tế nữa.

Có một số thứ nhất định sẽ không bao giờ thay đổi trong một ngôn ngữ, và có một thư viện bao bọc mã này trong một giao dịch đơn giản hơn và với ít dòng mã hơn mà tôi phải viết là một điều may mắn. Kết nối với cơ sở dữ liệu sẽ luôn giống nhau. Việc chọn một phần tử trong DOM sẽ không thay đổi. Việc gửi email qua tập lệnh phía máy chủ sẽ không bao giờ thay đổi. Việc phải viết hết lần này đến lần khác làm lãng phí thời gian mà tôi có thể sử dụng để cải thiện logic cốt lõi của mình trong ứng dụng.

Khởi tạo tất cả các thành viên trong lớp.

Tôi đã từng khởi tạo rõ ràng mọi thành viên trong lớp bằng một thứ gì đó, thường là NULL. Tôi đã nhận ra rằng điều này:

• thông thường có nghĩa là mọi biến được khởi tạo hai lần trước khi được đọc
• là ngớ ngẩn vì trong hầu hết các ngôn ngữ tự động khởi tạo các biến thành NULL.
• thực sự thực thi một cú đánh hiệu suất nhỏ ở hầu hết các ngôn ngữ
• có thể mở rộng mã trên các dự án lớn hơn

Giống như bạn, tôi cũng chấp nhận các mô hình IoC trong việc giảm sự ghép nối giữa các thành phần khác nhau trong ứng dụng của tôi. Nó làm cho việc bảo trì và hoán đổi các bộ phận trở nên đơn giản hơn nhiều, miễn là tôi có thể giữ cho từng bộ phận độc lập nhất có thể. Tôi cũng đang sử dụng nhiều khuôn khổ quan hệ đối tượng hơn như NHibernate để đơn giản hóa công việc quản lý cơ sở dữ liệu.

Tóm lại, tôi đang sử dụng các khuôn khổ "mini" để hỗ trợ xây dựng phần mềm nhanh chóng và hiệu quả hơn. Các khung công tác nhỏ này tiết kiệm rất nhiều thời gian và nếu được thực hiện đúng cách có thể làm cho một ứng dụng trở nên cực kỳ đơn giản để duy trì hoạt động. Cắm 'n Chơi để giành chiến thắng!