Không đồng ý với dự án dẫn về các tiêu chuẩn mã hóa [đóng]

Vì vậy, tôi đang làm việc trên một dự án mới cùng với dự án của tôi trong 1 năm qua.

Ban đầu chúng tôi có các dự án con riêng của chúng tôi cư trú trong các git repos riêng biệt, tôi có ít tương tác với mã của anh ấy, vì vậy mùi mã không làm phiền tôi. Khoảng 6 tháng sau tôi bắt đầu duy trì và thêm các tính năng vào mã của anh ấy, vì tôi đang đảm nhận vai trò lớn hơn trong dự án.

Bây giờ tôi là nhà phát triển chính cho cả hai dự án phụ (nhóm sắp phát triển; anh ấy vẫn ở trên tôi), những điều này làm phiền tôi và tôi muốn chăm sóc chúng, nhưng đã bị từ chối:

1. Không có dấu ngoặc nhọn, hàm viết hoa, sử dụng dấu ngoặc kép (logic kép và đơn / ẩn), không sử dụng ===, các lớp lớn với các hàm lớn. Tóm lại, có thể tốt hơn.
2. Dựa vào tùy chọn của PHP để tắt thông báo / cảnh báo. Mã có đầy đủ các cách sử dụng không được kiểm tra của các biến và khóa mảng. Các biến được định nghĩa bên trong ifs.

Đối số cho 2 vấn đề trên:

1. Không muốn thực thi một phong cách mã hóa trên người.
2. Được coi là một tính năng ngôn ngữ, nó cho vay mã ngắn hơn / hiệu quả hơn.

Tôi tin rằng một số quy tắc cần phải có và mã phải phòng thủ. Tôi đã đề nghị sử dụng các cài đặt mặc định của PHPStorm để định dạng, sử dụng dấu ngoặc nhọn và quy ước đặt tên được cộng đồng chấp nhận.

Tôi muốn căn chỉnh cả hai dự án để sử dụng cùng một hướng dẫn, vì chúng không thể tách rời.

Tôi có sai không? Tôi có áp đặt sở thích cá nhân của tôi?

Nếu bạn có thể đưa ra một trường hợp mạnh mẽ về lý do tại sao bạn tốt hơn (và những vấn đề lớn nào có thể xảy ra khi sử dụng nó), thì bạn không áp đặt sở thích cá nhân, tôi nghĩ, mà thay vào đó, cố gắng thiết lập một dự án để thành công.

Nếu anh ta có thể tạo ra một trường hợp mạnh mẽ hơn tại sao anh ta tốt hơn và loại vấn đề nào sẽ ngăn cản bạn không thể, thì anh ta đã khiến bạn nổi giận.

Quản lý cấp trên có thể thấy được ưu điểm trong đó, nhưng đó là những điểm họ sẽ (và nên) quan tâm: không phải là nhà phát triển dễ dàng hơn hay "không muốn buộc mọi người làm việc như robot" (mà là một điểm vô lý, nhưng đừng sử dụng nó như một điểm đau đối với quản lý cấp trên). Họ (nên) quan tâm đến sự ổn định liên tục của dự án.

Theo nhận xét của tôi ở trên:

Nếu anh ấy là trưởng dự án, điều đó dường như ngụ ý rằng về cơ bản đó là cuộc gọi của anh ấy.

Đó là suy nghĩ của tôi. Nếu bạn muốn thay đổi tiêu chuẩn nhưng anh ta không nhúc nhích, thì a) tìm cách vượt lên trên anh ta, b) đi nơi khác làm việc, hoặc c) thử những việc nhỏ bạn có thể làm mà không làm anh ta bực mình quá nhiều.

Ở trên anh ta sẽ chỉ làm việc nếu bạn làm một trường hợp mạnh mẽ tại sao nên có tiêu chuẩn tốt hơn.

Về cơ bản:

• bạn không thích phong cách mã hóa của anh ấy. Đó là quyền của bạn.
• anh ấy thấy nó ổn như nó và thấy việc dành nhiều ngày / tuần / hơn nữa chỉ cần điều chỉnh phong cách là một sự lãng phí thời gian . Đó là quyền của anh ấy.

Đặt bản thân vào vị trí của người khác. Những lợi ích của nỗ lực của bạn, bên cạnh việc tiêu tốn của công ty rất nhiều tiền (tiền lương của bạn) là gì? Có phải anh ấy luôn luôn nitpicking? Anh ấy không thấy có nhiều thứ quan trọng hơn phải làm bây giờ sao?

Về cơ bản, bạn phải tìm một số loại thỏa hiệp mà bạn có thể sống cùng, hoặc mối quan hệ của bạn sẽ trở nên chua chát. Nó cũng phụ thuộc rất nhiều vào cách bạn giao tiếp với anh ấy. Đặt cái tôi của bạn sang một bên và cố gắng trở nên hữu ích ... bởi vì cuối cùng bạn đang hỏi anh ấy những điều bạn muốn, không phải là điều mà anh ấy quan tâm. Nói cách khác, bạn đang yêu cầu anh ấy một việc .

Nó cũng thường phụ thuộc vào cách bạn yêu cầu. Ví dụ:

Bạn muốn gì:

làm cho mã đẹp hơn

Điều không nên nói:

mã của bạn hút theo cách của nó

Phải nói gì:

Tôi thực sự sẽ đánh giá cao nó nếu tôi có thể làm cho cả hai dự án phù hợp, chỉ là những điều cơ bản, và nó sẽ chỉ mất một ngày.

Bạn muốn gì:

không còn cảnh báo không được kiểm tra

Điều không nên nói:

mã của bạn hút theo cách của nó

Phải nói gì:

Tôi biết một cách nhanh chóng để thoát khỏi điều này và cảnh báo đó. Sau đó, bằng cách kích hoạt lại chúng, chúng tôi có thể phát hiện nhanh hơn nếu có thể bị hỏng trong tương lai.

Và cuối cùng:

Tôi biết đó không phải là một ưu tiên. Vì vậy, tôi có thể sẵn sàng làm điều đó một khi công cụ ưu tiên cao ra khỏi bàn trước.

Hoặc, nếu điều đó không thành công hoặc bạn có mối quan hệ xấu với anh ta, hãy cân nhắc việc rời đi. Nếu bạn không thể sắp xếp mọi thứ ngay bây giờ, không có khả năng sẽ tốt hơn trong tương lai ... và đặt cái tôi của bạn sang một bên.

Lưu ý bên

Tôi nghĩ rằng những người cao cấp trở nên khoan dung hơn. Họ biết rằng mã sẽ bị hủy trong một hoặc hai thập kỷ nữa (vì thay đổi công nghệ, API cũng vậy, các nhóm, đối tác kinh doanh, yêu cầu, quyết định toàn cầu, bất cứ điều gì ...). Họ có ít bản ngã hơn và tập trung vào việc nó hoạt động hơn là hoàn hảo. Mặc dù tôi có xu hướng hoàn thiện bản thân, tôi không thể đổ lỗi cho họ.

Điều này có thể sẽ gây tranh cãi nhưng ...

Chúng tôi đã nói chuyện và đồng ý không đồng ý và chuyển nó lên cấp quản lý cao hơn

Không bao giờ. Không bao giờ. Làm. Điều này. KHÔNG BAO GIỜ. Mỗi khi bạn làm điều này, nó đặt tất cả chúng ta trở lại một thập kỷ. Đây là cách nó sẽ diễn ra:

• Quản lý cấp cao 1: "Chúng tôi đã được yêu cầu giải quyết vấn đề này blah, blah, blah, một cái gì đó về tiêu chuẩn mã hóa và lãng phí thời gian."

• Quản lý cấp cao 2: "Và họ đang yêu cầu chúng tôi giải quyết các cuộc chiến trên sân cỏ của họ bởi vì?"

• Quản lý cấp cao 3: "Bởi vì họ là những đứa trẻ không biết giao tiếp và không quan tâm / không hiểu giá trị kinh doanh là gì? *"

• Quản lý cấp cao 2: "Đó phải là nó. Ai là người chơi golf?"

Rồi đến thời gian xem xét hiệu suất của bạn và sếp:

"[Quản lý cấp cao cho sếp của bạn]: Tôi xin lỗi nhưng có một số lo ngại rằng bạn không thể quản lý các báo cáo trực tiếp của mình và bạn có thể không tuân theo các thực tiễn tốt nhất (mặc dù tôi không biết bạn làm gì ngoại trừ nhập một số mumbo jumbo điều đó làm cho phần mềm hoạt động tốt) "

"[quản lý cấp cao cho bạn]: Tôi xin lỗi nhưng có một số lo ngại rằng bạn không liên quan tốt đến các đồng nghiệp của mình và gặp khó khăn khi làm theo chỉ dẫn của người giám sát trực tiếp của bạn."

Và đây là lý do tại sao chúng tôi chủ yếu trả lương thấp hơn so với giá trị chúng tôi tạo ra. **

Bạn cần phải A) vượt qua nó hoặc B) chuyển đến một cửa hàng có các tiêu chuẩn được điều chỉnh gần hơn một chút theo ý thích của bạn. FWIW, tôi sẽ làm B (và hy vọng chuyển sang một ngôn ngữ không cho phép sự tàn bạo đó). Nhưng không bao giờ leo thang tranh chấp kỹ thuật cho các vụ kiện trừ khi nó liên quan đến một cái gì đó bất hợp pháp hoặc có khả năng thảm khốc (lỗ hổng bảo mật). Chỉ gây phiền nhiễu không cắt nó ***.

* Vì lợi ích của những người sẽ đọc và hiểu lầm, tôi không nói rằng OP và ông chủ của anh ấy giống như vậy (tôi nhận ra rằng chất lượng / mức độ dễ đọc của mã có ảnh hưởng trực tiếp đến lợi nhuận của doanh nghiệp), tôi đang nói rằng họ sẽ được nhận thức như thế này bởi quản lý phi kỹ thuật.

** Đối với những người cho rằng chân dung quản lý cấp trên của tôi là không có lỗ hổng là không thực tế, hãy hiểu rằng các nhà quản lý quan tâm (lý tưởng) về việc quản lý mọi người theo cách chúng tôi quan tâm về việc quản lý mã. Họ có thể không biết gì về các vấn đề kỹ thuật, nhưng họ biết mọi người, và đó là lý do nhiều hơn khiến họ tranh chấp rằng A) họ có thể không đủ điều kiện để giải quyết và B) hai bạn có thể giải quyết mà không cần giúp đỡ làm cho bạn trông xấu

*** Có, tôi nhận ra rằng nợ kỹ thuật có thể chồng chất đến mức nhấn chìm doanh nghiệp. Tôi chỉ không nghĩ rằng niềng răng xoăn sẽ cứu bạn (như đã nói, tôi không bao giờ bỏ qua niềng răng và rất thích những người khác không thích).

IMHO, bạn đang đối mặt với một nhà phát triển 'nó đang hoạt động', không phải là nhà phát triển quan tâm đến việc tiếp theo sau họ. Lập luận của anh ta chỉ là vô giá trị.

Tất cả những gì bạn nói về mã của anh ta chỉ là sự lười biếng thô sơ. Có các dự án theo cùng tiêu chuẩn mã hóa là về sự nghiêm ngặt. Bạn không phải là robot; bạn là kỹ sư; bạn được cho là nghiêm ngặt.

Bạn có thể chỉ ra một số ví dụ rằng bạn đang gặp khó khăn khi đọc mã của anh ấy và đó là một sự mất năng suất rất lớn đối với bạn, nhưng tôi không có ý tưởng thực sự nào để mang nó đến cho anh ấy.

Nhưng tôi có thể sẽ trả lời cho bạn một cái gì đó là giai điệu:

Nó đang hoạt động, không có điểm nào để thay đổi

Lời khuyên của tôi: nếu anh ấy thực sự cùn và không muốn đầu bất cứ điều gì, hãy để nó đi. Đợi lỗi / lỗi / tiến hóa xảy ra trong dự án của mình. Khi có, chỉ cần sửa và viết lại phần mã được sửa đổi / thêm vào một cách thích hợp; đừng đi đến anh ta để nói bất cứ điều gì về nó. Anh ta sẽ không áp đặt cho bạn phong cách mã hóa của anh ta, vì dù sao bạn cũng không phải là robot ....

Khi bạn làm việc trong một dự án, bạn phải đặt ưu tiên.

Ưu tiên số 1 là hòa đồng với đồng nghiệp của bạn. Ưu tiên số 1 được theo sau bởi một khoảng cách rất lớn. Sau đó, ưu tiên cho những thứ như mã đang hoạt động, có thể kiểm tra, thử nghiệm, ghi lại, có thể bảo trì, vv Sau đó đến một khoảng cách lớn khác, và sau đó đến các tiêu chuẩn mã hóa.

Và việc thay đổi mã hiện có để tuân thủ các tiêu chuẩn mã hóa mới thực sự thấp trong danh sách ưu tiên.

Tái bút "Tối ưu hóa vi mô" so với "máy tính siêu nhanh": Đối số hoàn toàn sai. Đối số chống lại tối ưu hóa vi mô không phải là máy tính chạy nhanh, lập luận là lãng phí thời gian cho tối ưu hóa vi mô có nghĩa là bạn không có thời gian để tiết kiệm thực sự .

Tái bút Nếu bạn chỉ mất một ngày để thực hiện các thay đổi giúp mã trở nên tốt hơn đối với bạn, nhưng làm cho đồng nghiệp của bạn khó chịu và biến bạn thành kẻ thù, thì bạn đã lãng phí một ngày vào thứ gì đó chỉ phản tác dụng.

PHP không phải là nhóm ưu tú nhất trong nghề nghiệp của chúng tôi. Thật ra bạn đang chỉ trích hệ thống phần mềm có lẽ khó thắng của anh ấy. Tiêu chuẩn chuyên nghiệp của bạn cao hơn như anh ấy.

Sau đó, nếu bạn không có thời gian để cải thiện mã theo trách nhiệm của mình, cuối cùng chỉ có một giải pháp: tiếp tục .

Tôi không biết về thị trường PHP hiện tại tại địa điểm của bạn, nhưng trước tiên bạn có thể đa dạng hóa phần nào. Tìm hiểu một số ngôn ngữ cường điệu quá, hoặc một thích hợp như C #.

Bạn có thể không có được một công việc tốt như vậy, nhưng bạn sẽ tiến xa hơn, một cách chuyên nghiệp. Vì vậy, có kiên nhẫn, và làm một số tự học. Tiền an toàn. Sau đó yêu cầu một số chậm trễ trong các dự án của bạn, hoặc nhận một số lời mời làm việc.

Tôi thấy khó tin rằng # 1 là lý do thực sự của anh ấy vì không muốn thay đổi các tiêu chuẩn mã hóa. Nếu bạn sở hữu cơ sở mã, bạn sẽ có thể thực thi bất kỳ tiêu chuẩn mã hóa nào mà bạn (và các nhà phát triển khác) đồng ý. Nếu bạn đạt được sự đồng thuận với các nhà phát triển khác (giả sử khách hàng tiềm năng không còn thực hiện bất kỳ công việc phát triển nào nữa) thì không có lý do gì để anh ta thực sự quan tâm, ngoại trừ điều này:

Là sửa chữa phong cách của cơ sở mã sử dụng tốt nhất thời gian của bạn ngay bây giờ?

Tôi chắc chắn bạn có thể giao hàng. Mất bao nhiêu thời gian để đi qua và cải thiện phong cách ở mọi nơi trong cơ sở mã khác? Điều gì nếu bạn giới thiệu lỗi bằng cách sửa lỗi không đúng cách? Từ chú Bob:

Tất nhiên mã xấu có thể được làm sạch. Nhưng nó rất đắt. Khi mã rots, các mô-đun tự khắc vào nhau, tạo ra nhiều phụ thuộc bị ẩn và rối. Tìm kiếm và phá vỡ sự phụ thuộc cũ là một nhiệm vụ dài và khó khăn.

Cải thiện kiểu mã như thế này hầu như không bao giờ là cách sử dụng tốt thời gian như một mục chạy nước rút độc lập . Cách tôi muốn thực hiện các loại cải tiến này là cái mà tôi gọi là "Chính sách hàng xóm tốt": đừng đi sửa tất cả các cấu trúc logic và phong cách bạn có thể tìm thấy, bởi vì bạn có thể đầu tư nhiều thời gian như bạn muốn và vẫn sẽ không được thực hiện Thay vào đó: bất cứ khi nào bạn thực hiện thay đổi đối với một phần của mã, hãy sửa kiểu trong khi bạn ở đó và để nó tốt hơn bạn đã tìm thấy. Nếu bạn đang vật lộn để thực hiện một tính năng vì mã được thiết kế xấu, hãy sửa kiểu để bỏ chặn chính bạn thay vì đập đầu vào nó.

Theo cách này, mỗi thay đổi:

1. Có một động lực kinh doanh ngoài động lực cầu toàn kỹ thuật
2. Sẽ không được xem là một khoản đầu tư thời gian lớn (vì không phải vậy!)
3. Sẽ thiết lập thói quen phong cách tốt chính xác bởi vì bạn và nhóm của bạn đang làm điều đó theo thời gian
4. Sẽ không gây rủi ro lớn cho cơ sở mã vì bạn không thay đổi quá nhiều cùng một lúc

Vài tháng sau, bạn sẽ nhìn lên và nhận thấy rằng "gói khủng khiếp" sẽ không còn tệ nữa và sếp của bạn sẽ thấy rằng đội của anh ấy hạnh phúc hơn. Nhưng vì đó không phải là một cuộc đối đầu trực tiếp nên nó đã được thực hiện và anh ta sẽ không có gì để phàn nàn vì bạn đã không lãng phí thời gian (trong tâm trí của anh ta) bằng cách thêm một dự án tái cấu trúc lớn vào danh sách việc cần làm. Anh ta có thể sẽ không bao giờ nói với bạn rằng bạn đã đúng, nhưng dù sao đó cũng không phải là mục tiêu (phải không?).

Đặt những câu hỏi về khách hàng tiềm năng của bạn.

• Họ đã từng làm việc một mình hay với một nhóm rất nhỏ?
• Họ đã chủ yếu mã hóa tại một cửa hàng này?
• Họ đã từng đưa ra quyết định?
• Có phải họ đã từng "hoàn thành nó"?
• Họ đã viết hầu hết các mã?

Nếu câu trả lời là "có", thì tôi sẽ vẽ một bức tranh về một loại lập trình viên cụ thể. Nếu nó phù hợp với những gì bạn đã trải nghiệm, có thể nó sẽ giúp đi vào đầu họ. Nếu không, bỏ qua câu trả lời này .

Đây là một người đã ở đó từ ngày đầu tiên, đã dành nhiều năm ở cùng một công việc làm việc trên cùng một cơ sở mã, đã quen với cách của họ và không có nhiều kinh nghiệm với những cách khác.

Họ không xem xét người khác khi viết mã vì tất cả đều có ý nghĩa với họ. Tất nhiên là có, họ đã viết nó, hoặc họ đã dành nhiều năm để hiểu nó.

Họ coi phong cách mã hóa là một sở thích cá nhân, không phải là một công cụ để giảm bảo trì và lỗi. Khi tranh luận về phong cách mã hóa, họ sẽ đấu tranh để nghe lập luận của bạn bởi vì có lẽ họ chưa bao giờ nghĩ nhiều về lý do tại sao họ làm mọi thứ theo cách của họ. Những gì họ sẽ nghe là "Tôi muốn làm theo cách của tôi" hoặc "Tôi muốn làm theo cách mới, lạ mắt, hợp thời trang".

Họ được thiết lập theo cách của họ. Bởi vì họ đã làm điều đó theo cùng một cách trong một thời gian dài, tất cả các công cụ và trình soạn thảo của họ và bộ não được cấu hình vi mô chính xác theo phong cách của họ. Bất kỳ sai lệch từ phong cách này sẽ xung đột với cách làm việc được sắp xếp cẩn thận, nhưng rất dễ vỡ. Nỗ lực thay đổi sẽ thu hút những lời phàn nàn về trình soạn thảo, công cụ của họ, cách họ thích làm việc hoặc "khó đọc". Họ từ chối thay đổi vì họ đã bao bọc bản thân quá chặt chẽ trong hiện trạng mà họ không thể thay đổi.

Đây là một người chưa bao giờ học đúng kỹ thuật phần mềm và kiến ​​trúc phần mềm. Họ chỉ sắp xếp mọi thứ với nhau.

Bạn có một vấn đề con người, không phải là một công nghệ.

Bạn sẽ phải kiềm chế sự dẫn dắt của mình, hoặc bạn sẽ phải nghỉ việc.

Đi đến quản lý là một phương sách cuối cùng . Cả hai vì lý do @JaredSmith chỉ ra và vì bạn sẽ thua. Anh chàng này đã dành nhiều năm để kiếm tiền cho họ. Ông viết công ty của họ. Anh ta dập tắt nhiều vụ hỏa hoạn. Đối với bạn anh ấy là một đầu bếp cao bồi làm mì spaghetti. Đối với họ anh ấy là một anh hùng đã xây dựng và cứu công ty.

Để đào tạo lại, bạn sẽ phải ...

• Có được lòng tin của anh ấy.
• Tìm hiểu làm thế nào anh ấy nghĩ.
• Giải quyết nỗi sợ hãi của anh ấy về sự thay đổi.
• Làm cho thay đổi dễ dàng hơn.
• Chỉ ra làm thế nào điều này là tốt hơn cho anh ta .

Hãy nghiêm túc với phong cách của anh ấy và vào trong đầu anh ấy. Hỏi anh ấy về nó. Tại sao anh ta làm mọi thứ theo cách anh ta làm? Anh ta thấy gì khi đọc nó? Làm thế nào để nó tương tác với các công cụ của mình? Làm thế nào để anh ta di chuyển qua mã? Biết tất cả những điều này sẽ cho phép bạn hiểu và giải quyết sự phản đối của anh ấy.

Tìm nguồn gốc khách quan của sự phản đối chủ quan của anh ấy, làm cho chúng có thể hành động. "Thật khó đọc" là chủ quan, và nó không cung cấp cho bạn thông tin. Bạn không thể làm bất cứ điều gì về điều đó. "Tôi mù màu và tô sáng cú pháp không hoạt động" là mục tiêu, nó cung cấp cho bạn thông tin và bạn có thể làm gì đó về điều đó. Tôi muốn giới thiệu một cuốn sách có tên Bắt đầu Có để biết thêm về điều đó.

Khi bạn gặp phải vấn đề gốc, vấn đề thực sự anh ấy gặp phải, hãy xem liệu bạn có thể khắc phục hoặc giảm thiểu nó không. Sau đó, nó không phải là một vấn đề. Họ có thể vẫn còn có vấn đề về cảm xúc với việc thay đổi, nhưng ít nhất họ không còn có thể tranh luận rằng đó là một vấn đề thực sự.

Làm một chút tại một thời điểm. Đây là một người đã làm điều đó theo cách tương tự trong nhiều năm. Anh ta đã quen nhìn thấy các mẫu nhất định trong mã và sử dụng chúng để hiểu nó. Đột nhiên thay đổi tất cả những mô hình sẽ gây nhầm lẫn. Bực bội vì sẽ từ từ đưa chúng lên tốc độ với thực tiễn tốt đã biết, bạn phải đưa anh ấy vượt qua nó.

Vận động cho một phong cách cộng đồng tiêu chuẩn. Điều này loại bỏ lập luận rằng đó là về sở thích cá nhân và gây áp lực cho họ để biện minh cho lý do tại sao phong cách khác nhau của họ tốt hơn nhiều. Nếu bạn có kế hoạch tuyển dụng, việc tích hợp các tuyển dụng mới sẽ dễ dàng hơn.

Ủng hộ cho phong cách mã tự động. Thực hiện theo đúng kiểu chỉ bằng một nút nhấn. Sử dụng một công cụ bắt đầu với một kiểu tiêu chuẩn, cho phép bạn định cấu hình nó theo sở thích của mình và có thể sắp xếp lại mã bằng một nút nhấn. Làm cho nó dễ dàng nhất có thể để làm theo phong cách loại bỏ nhiều tranh luận về mức độ khó theo dõi. Họ có thể viết mã theo cách họ thích, và khi họ hoàn thành, họ nhấn nút và nó theo một phong cách mà người khác có thể đọc.

Vì người này không có suy nghĩ về người khác, bạn sẽ phải cho thấy những thay đổi này mang lại lợi ích cho họ như thế nào. Nó có thể đơn giản như "vì đây là tiêu chuẩn bây giờ, bạn sẽ không phải trải qua cuộc chiến này một lần nữa với người tiếp theo bạn thuê". Hoặc có thể là "nếu chúng tôi có các bài kiểm tra, bạn có thể mạnh dạn hơn trong việc thay đổi mã và bớt lo lắng về việc thay đổi mọi thứ". Hoặc "nếu có tài liệu tốt, mọi người sẽ không phải làm phiền bạn với các câu hỏi về cách thức hoạt động của mã". Để điều này có hiệu quả, bạn sẽ phải biết họ muốn gì - một số người thích bị làm phiền, điều đó khiến họ cảm thấy quan trọng.

Đó là một con đường dài và dài. Bạn sẽ phải quyết định xem bạn có đủ kiên nhẫn để quản lý và đào tạo lại sếp hay không. Hãy nghĩ về bản thân bạn như là giáo viên của họ hơn là người dưới quyền thất vọng của họ, và bạn có thể cảm thấy tốt hơn về điều đó.

Tôi có sai không?

Tôi không biết PHP, vì vậy tôi không thể đưa ra đánh giá trực tiếp, nhưng tôi sẽ cho rằng vì lý do rằng phong cách mã hóa ưa thích của bạn là "tốt hơn" so với mã bạn gặp phải, vì mã của bạn phù hợp hơn với các công cụ tự động hiện có.

Sau đó, bạn không sai khi đề xuất cải tiến cho phong cách mã hóa.

Dòng dưới cùng, không phải mã tôi muốn làm việc với

Bạn có thể sai khi từ chối làm việc với mã không đáp ứng các tiêu chuẩn ưa thích của bạn, nhưng chỉ ở mức độ bằng cách làm việc cho công ty, bạn đã đồng ý làm việc với mã của họ ngay từ đầu. Cuối cùng, không có gì là "sai" khi bỏ công việc của bạn nếu điều đó khiến bạn yêu cầu không theo ý thích của bạn, vì đó là quyền của bạn và kết quả là bạn có thể tìm được công việc tốt hơn.

Tôi có áp đặt sở thích cá nhân của tôi?

Không. Anh ấy là người dẫn đầu dự án còn bạn thì không. Đó là cuộc gọi của anh ấy, mặc dù trong trường hợp này anh ấy "được ủy thác trở lên".

Anh ta cũng có thể đã quyết định ủy thác cho bạn, với tư cách là nhà phát triển chính của các dự án phụ, và cho bạn tự do thiết lập các tiêu chuẩn mã hóa cho các dự án phụ và đồng nghiệp làm việc trong tương lai. Nhưng vì bất cứ lý do gì, anh ấy cảm thấy khá mạnh mẽ rằng bạn không nên tiêu chuẩn hóa. Ngay cả khi anh ta sai về phong cách mã hóa, bạn không thể mong đợi để yêu cầu một cơ quan mà anh ta đã không cho phép bạn.

Tuy nhiên, vì anh ta nói "Tôi không muốn thực thi các kiểu mã hóa", ít nhất bạn có thể viết mã mới theo kiểu ưa thích của bạn (và đã làm như vậy). Cuối cùng, điều này có thể dẫn đến các cơ hội để chứng minh lợi ích khách quan của phong cách của bạn. Đó sẽ là thời điểm tốt để có một lần thứ hai làm cho trường hợp của bạn.

Bạn cũng có thể (tôi nghĩ) một cách hợp lý yêu cầu những người chỉnh sửa tệp, làm như vậy theo kiểu tệp đã được viết. Điều đó cho phép bạn duy trì các tiêu chuẩn trong các tập tin bạn đã viết. Thật không may, mặt trái của điều này là bạn phải chỉnh sửa các tệp anh ấy đã viết theo cách tương tự với phong cách của mình.

Ngay cả khi giả định rằng bạn có một bộ kiểm tra thực sự tốt, và do đó có thể tái cấu trúc trong sự an toàn tương đối, vẫn có những lý do (thừa nhận khá ít) không thể vượt qua và định kiểu lại toàn bộ tệp. Cái chính là đó là một cơn ác mộng khi cố gắng hợp nhất, sắp xếp lại hoặc hoàn nguyên các thay đổi được thực hiện trước và sau một thay đổi lớn về cấu trúc. Nhưng nó cũng có thể là trong dự án đặc biệt này hầu như không bao giờ xảy ra.

[Người quản lý của tôi nói rằng anh ấy không thích thực thi các kiểu mã hóa trên mọi người [vì] chúng tôi không phải là robot.

Bạn có bao giờ tự hỏi tại sao chúng ta không vứt mã nguồn đi sau khi chúng ta biên dịch nó và nó vượt qua tất cả các bài kiểm tra không? Mã nguồn là dành cho con người, và nó không chỉ dành cho con người để viết mà còn để đọc .

Sớm hay muộn, ai đó sẽ có lý do để quay lại và đọc mã. Có lẽ họ sẽ cần phải thay đổi nó, có thể để ghi lại nó, có thể sử dụng lại nó. Bất cứ điều gì. Điều đó sẽ xảy ra và mã sẽ dễ đọc hơn và dễ làm việc hơn nếu tất cả theo một kiểu nhất quán.

Ngay cả một phong cách xấu vẫn tốt hơn là không có phong cách nào cả.