Đưa ra một bài thuyết trình về phong cách thiết kế mã và các mẫu thiết kế mã [đóng]

Công ty của tôi (nhỏ, khoảng 40 người trên 3 văn phòng) thỉnh thoảng có "hội thảo dành cho nhà phát triển" trực tuyến nơi một trong những nhà phát triển tổ chức một buổi thuyết trình về một số chủ đề công nghệ. Đó không nhất thiết là về công việc của chúng tôi, mà chỉ để giúp mọi người cải thiện kỹ năng và sự hiểu biết của họ.

Tôi đã được yêu cầu lưu trữ phần tiếp theo và chủ đề (được chọn từ danh sách tôi cung cấp) là kiểu mã và mẫu thiết kế. Tôi biết những điều đó không liên quan chặt chẽ nhưng chịu đựng tôi. Tôi đã thấy nhiều nơi trong cơ sở mã của chúng tôi có thể được cải thiện, một số nơi thậm chí có thể đủ điều kiện cho DailyWTF, vì vậy tôi muốn bản trình bày này có hiệu quả nhất có thể. Vấn đề là tôi chỉ không biết chính xác những gì sẽ bao gồm trong một giờ.

Ý tưởng đầu tiên của tôi là sử dụng mã riêng của chúng tôi làm ví dụ, để lái xe về nhà theo quan điểm "vui lòng thực sự áp dụng điều này vào công việc của bạn." Nhưng chủ đề rất rộng.

Một số điều sai với mã của chúng tôi (PHP) bao gồm:

• OO tối thiểu. Nó đã được cải thiện gần đây, nhưng vẫn còn rất nhiều chức năng toàn cầu. Tôi phải mất một thời gian để tìm thấy mọi thứ.
• Cấu hình toàn cầu (ý kiến ​​tôi đoán). Bạn có thể tìm thấy $ GLOBALS ['blah'] nằm rải rác trong mỗi tệp.
• Kiểu niềng răng không nhất quán. Nghe có vẻ tối thiểu, nhưng điều này thực sự gây ra lỗi cú pháp được đẩy về nguồn gốc năm ngày trước, mà vẫn không được sửa chữa như ngày hôm qua.
• Cấu trúc không hiệu quả. Tôi đã có thể thực hiện một số cải tiến cơ bản giúp giảm 70% thời gian chạy ở một số khu vực.

Tôi muốn thứ này hữu ích nhất có thể, mà không có âm thanh hạ thấp đồng nghiệp của tôi. Vì vậy, những khía cạnh của "phong cách" tôi nên tập trung vào, và những mẫu thiết kế nào có thể hữu ích nhất để giải thích?

Hãy cực kỳ cẩn thận khi sử dụng mã thực trong bài thuyết trình trước những người viết mã này.

Tốt nhất là bạn sẽ làm phiền nhóm của bạn bằng cách chỉ tay vào họ trước mặt mọi người. Và những gì bạn sẽ nhận được thay vì "Bạn thực sự mở mắt" là "WTF trước mặt mọi người? Thậm chí bạn có nhìn vào mã của riêng mình không .."

Lấy ví dụ thực tế nhưng sửa đổi nó hoặc chắc chắn rằng nó không thể được truy tìm đến bất cứ ai đã viết nó. Hoặc lấy mã thực từ những người bạn biết nhưng cũng lấy một số mã cũ của BẠN và chơi hài hước và bên trong trò đùa với những người này, phong cách nổi bật :)

Để trả lời các câu hỏi ban đầu của bạn: Mọi thứ liên quan đến khả năng đọc: các chức năng với càng ít đối số càng tốt, OOP, tên và bình luận biến dài và chi tiết.

Tôi đoán rằng bạn có một hệ thống theo dõi lỗi trong tổ chức của bạn. Rút ra một số lỗi khó chịu nhất từ ​​kho lưu trữ, xem báo cáo sửa lỗi về lý do tại sao nó xảy ra (các biến toàn cục trở nên tồi tệ, các chức năng làm những thứ mà chúng không có nghĩa là v.v.) và sau đó thảo luận về kiểu mã hóa và các mẫu thiết kế có thể giúp tránh vấn đề này .

Đó là một công việc khó khăn để thực hiện nghiên cứu này, nhưng đây là cách mạnh nhất để lái xe về nhà những gì bạn đang trình bày thực sự hiệu quả .

"Vẫn còn hàng tấn các chức năng toàn cầu".

Đầu tiên, có được một danh sách. Hoàn thành là lý tưởng.

Thứ hai, phân vùng danh sách này thành các lớp tiềm năng. Hãy suy nghĩ về các định nghĩa lớp.

Trong bài thuyết trình thực tế, chọn lớp tiềm năng lớn nhất, rõ ràng nhất, rõ ràng nhất, ít gây tranh cãi nhất sẽ hấp thụ một loạt các chức năng toàn cầu đó.

Là một chủ đề thảo luận. Bạn có một ý tưởng. Bạn cần có được sự đồng thuận. Và trả lời các câu hỏi trên đường đi. Và giúp họ hiểu tại sao đó là một lớp đối tượng, không phải là một nhóm các chức năng ngẫu nhiên chia sẻ toàn cầu.

Sau đó, sau khi thảo luận về vấn đề này đến mức họ chỉ hiểu lớp này và cách bạn đến với nội dung ....

Bật máy chiếu.

Bắt đầu gõ.

Sửa mã. Chạy lại bài kiểm tra đơn vị của bạn.

Thiết kế mẫu và phong cách mã hóa và công việc đang được thực hiện. Tất cả trong một gói.

trong 1 giờ bạn sẽ làm tốt để vượt qua sự hiểu biết tối thiểu về những điều cơ bản.

tôi đề nghị chọn 3 điều từ mỗi chủ đề và tập trung vào những chủ đề đó; giới hạn các slide đến 5 - 7 từ để mọi người lắng nghe bạn thay vì đọc các slide; sử dụng các ví dụ trang điểm (để bạn không giẫm lên ngón chân của mọi người, theo đề xuất của người khác); đưa ra các tài liệu tham khảo ở cuối (URL tốt hơn sách) như một bài tập cho những người muốn tìm hiểu thêm; đăng các slide của bạn trên mạng nội bộ của bạn sau khi trình bày. (Đối với vấn đề niềng răng, hãy sử dụng một trình định dạng mã; đó có lẽ không phải là một trận chiến đáng để chiến đấu)

Đề tài đề xuất:

• Kiểu mã hóa

  • Zen của OOP trong PHP: Mã hóa với phong cách!
  • 5 lý do tại sao các chức năng toàn cầu gây ra ung thư
  • Những gì trong một cái tên? Các quy ước và ý thức chung (hoặc đừng làm tôi suy nghĩ!)

• Mẫu thiết kế

  • Một số mẫu GoF trong Mã của chúng tôi; một lời giới thiệu
  • Mô hình chỉ là công cụ, không phải là Tin lành
  • Tốt nhất và tồi tệ nhất: Mẫu và Chống mẫu

lưu ý: cấu hình toàn cầu đôi khi khó tránh; Một biện pháp dễ dàng là đặt tất cả các tham chiếu đến chúng trong một hàm init

Hãy cẩn thận: Tôi chỉ biết đủ PHP để phá vỡ wordpress và thực hiện các sửa lỗi trang web nhỏ

Về việc sử dụng mã thực trong bản trình bày - nếu được sử dụng, chỉ sử dụng nó cho các ví dụ tốt, KHÔNG BAO GIỜ được các ví dụ xấu. Đối với cái xấu, tạo nên của riêng bạn, hoặc tìm thấy nó trên web. Điều này cho phép đồng nghiệp của bạn tự hào về công việc của họ và được công nhận cho nó. Nó cũng tránh được kịch bản mà họ có thể tức giận / bối rối vì bị chỉ trích là một nhà phát triển tồi.

Phong cách mã hóa là những thói quen xấu. Khó thoát khỏi. Cách tốt nhất để cho ai đó bỏ một thói quen xấu? Hãy để anh ấy thấy tận mắt nó xấu xí, kinh tởm hay có hại như thế nào.

Cho họ xem mã xấu, hỏi họ những gì xấu về nó. Hãy để họ suy nghĩ về nó trong một giây, sau đó cho họ một "Aaahaaa!" Khoảnh khắc bằng cách cho họ thấy một trường hợp cạnh (vấn đề Hàng rào, có lẽ?) hoặc một trường hợp trong đó thiết kế xấu của họ làm sụp đổ mọi thứ khác.

Những người của bạn bị các vấn đề thiết kế xấu thường xuyên, có vẻ như. Chỉ cho họ một ví dụ về cách một chức năng toàn cầu thay đổi theo cách vô hại gây hại cho các chức năng khác tùy thuộc vào nó, nhưng không biết nó đã bị thay đổi. Chỉ cho họ một vấn đề đồng bộ hóa cổ điển với biến toàn cục.

Làm điều đó theo một cách hài hước để thu hút họ, thay vì nhàm chán hoặc khiến họ đảm nhận vị trí phòng thủ (anh chàng này là ai để chỉ trích chúng tôi?); ví dụ cho họ thấy một chức năng thực hiện công việc của mình theo hai bước (1- nhập tên vợ) (2 cửa hàng trên toàn cầu) (3 tên chồng nhập và lấy tên vợ từ toàn cầu để lưu trữ trong cơ sở dữ liệu) (4 - cười như kết quả đồng bộ hóa kém ở những người đàn ông có vợ 'mới'), như một trò đùa đề xuất viết một chức năng thống kê ly hôn.

Tin tưởng có thể hiểu được về phong cách lập trình, bởi vì chúng ta lập trình những gì chúng ta nghĩ, và khi thiết kế lập trình bị chỉ trích, một số người coi đó là một sự xúc phạm đến cách suy nghĩ của họ và do đó trí thông minh của họ, vì vậy bạn phải có cách tiếp cận thú vị với nó.

Đảm nhận các chức năng xấu của bạn, che giấu nó bằng một số thay đổi để không gây khó chịu cho chủ sở hữu mã và làm việc & tương tác với khán giả để cải thiện nó. Kết quả: Hệ thống kiểm soát mã nguồn của bạn vào sáng hôm sau sẽ rất bận rộn, vì vậy hãy lấy một tách cà phê và mỉm cười với nhật ký thay đổi.