Đã lâu lắm rồi tôi mới đọc một bài viết về lập trình với nụ cười thường trực trên môi.

Grug giống như hầu hết chúng ta, không phải là một nhà phát triển có bộ não lớn, mà là một người thượng cổ đơn giản muốn viết mã có chất lượng tốt và hoàn thành công việc.

Grug không thông minh đến thế, nhưng đó có thể là siêu năng lực của anh ấy. Có nhiều sự khôn ngoan trong văn bản.

Đối với tôi, phải mất vài phút để chìm đắm trong cách thể hiện bản thân của Grug, nhưng điều đó rất đáng giá!

Đọc toàn bộ bài viết tại grugbrain.dev

Đây là một số cốm vàng từ Grug :

phức tạp

sự phức tạp là con quỷ tinh thần xâm nhập vào cơ sở mã hóa thông qua những nhà phát triển và quản lý dự án có ý nghĩa tốt nhưng cuối cùng rất có thể hợp tác với câu lạc bộ, những người không sợ con quỷ tinh thần phức tạp hoặc thậm chí không biết về đôi khi

Nói không

vũ khí tốt nhất để chống lại con quỷ linh hồn phức tạp là từ ma thuật: “không”

không, khó chịu không xây dựng tính năng đó
không, khó chịu không xây dựng tính năng trừu tượng đó

lưu ý, lời khuyên kỹ thuật tốt này nhưng lời khuyên nghề nghiệp tồi: “có” là từ kỳ diệu để chỉ tảng đá tỏa sáng hơn và được giao phụ trách nhóm lớn các nhà phát triển

buồn nhưng đúng: học “có” rồi học đổ lỗi cho người khác khi thất bại, lời khuyên nghề nghiệp lý tưởng

Bao thanh toán mã của bạn

không phải là yếu tố ứng dụng của bạn quá sớm!

các nhà phát triển não lớn thường không thích điều này chút nào và phát minh ra nhiều thứ trừu tượng khi bắt đầu dự án

grug bị cám dỗ với lấy câu lạc bộ và hét lên “bộ não lớn không bảo trì mã! bộ não lớn di chuyển trên ủy ban kiến ​​​​trúc tiếp theo để lại mã cho giải quyết khó khăn với!

thay vào đó, hãy cố gắng hạn chế thiệt hại của nhà phát triển não lớn ngay từ đầu trong dự án bằng cách cung cấp cho họ những thứ như sơ đồ UML (không làm hại mã, dù sao cũng có thể vứt đi) hoặc bằng cách yêu cầu bản demo hoạt động vào ngày mai

bản demo làm việc đặc biệt hay: buộc bộ não lớn tạo ra thứ gì đó thực sự hoạt động để nói về và viết mã để xem xét công việc đó, sẽ giúp bộ não lớn nhìn thấy thực tế nhanh hơn

hàng rào Chesterton

grug hiểu rằng tất cả những người theo chủ nghĩa platon lập trình viên ở một mức độ nào đó đều mong muốn âm nhạc của những quả cầu hoàn hảo trong mã. nhưng nguy hiểm ở đây, thế giới nhiều lần xấu xí và cục mịch và vì vậy cũng phải viết mã

grug không nói không cải thiện hệ thống bao giờ, khá ngu ngốc, nhưng khuyên bạn nên dành thời gian hiểu hệ thống trước, đặc biệt là hệ thống lớn hơn đang và đang tôn trọng mã hoạt động ngày nay ngay cả khi không hoàn hảo

Công cụ

công cụ tình yêu grug

trình sửa lỗi tốt có giá trị bằng đá sáng bóng, trên thực tế còn hơn thế nữa: khi đối mặt với bọ, grug thường đánh đổi tất cả đá bóng và có lẽ ít con để lấy trình gỡ lỗi tốt và dù sao thì trình gỡ lỗi cũng không nặng bằng bất kỳ thứ gì mà grug có thể nói

grug luôn khuyến nghị lập trình viên mới tìm hiểu trình gỡ lỗi có sẵn rất sâu, các tính năng như điểm dừng có điều kiện, đánh giá biểu thức, điều hướng ngăn xếp, v.v. dạy grug mới nhiều hơn về máy tính so với lớp đại học thông thường!

Loại hệ thống

grug rất giống các hệ thống kiểu giúp lập trình dễ dàng hơn. đối với grug, hãy nhập hệ thống có giá trị nhất khi grug nhấn vào dấu chấm trên bàn phím và danh sách những thứ mà grug có thể làm bật lên điều kỳ diệu. 90% giá trị của hệ thống loại này trở lên để gru

luôn có hệ thống loại giá trị nhất: nhấn dấu chấm xem grug có thể làm gì, đừng bao giờ quên!

Tách mối quan tâm

Tách mối quan tâm (SoC) một ý tưởng mạnh mẽ khác đối với tâm trí của nhiều nhà phát triển

ở đây gắt gỏng hơn nhiều so với DRY và trên thực tế, hãy viết bài luận lớn về nguyên tắc thiết kế thay thế địa phương của hành vi (LoB) chống lại SoC

grug thích đặt mã vào thứ thực hiện công việc hơn. Bây giờ khi grug nhìn vào thứ grug biết thứ đó làm gì, luôn luôn nhẹ nhõm!

ghi nhật ký

rất thích ghi nhật ký và khuyến khích ghi nhật ký thật nhiều, đặc biệt là trong đám mây được triển khai. một số người không ghê tởm nói rằng việc khai thác gỗ đắt tiền và không quan trọng. grug sử dụng nghĩ theo cách này không còn nữa

lời khuyên khó chịu khi đăng nhập là:

• ghi nhật ký tất cả các nhánh logic chính trong mã (nếu/cho)
• nếu "yêu cầu" mở rộng trên nhiều máy trong cơ sở hạ tầng đám mây, hãy bao gồm ID yêu cầu trong tất cả để các nhật ký có thể được nhóm lại
• nếu có thể, hãy kiểm soát mức nhật ký một cách linh hoạt, để grug có thể bật/tắt khi cần gỡ lỗi (nhiều!)
• nếu có thể, hãy tạo cấp nhật ký cho mỗi người dùng, vì vậy có thể gỡ lỗi sự cố người dùng cụ thể

nhà phát triển trí não cực lớn từng nói:

tối ưu hóa sớm là gốc rễ của mọi điều ác

grug khuyên bạn luôn nên có hồ sơ hoàn hảo cụ thể, trong thế giới thực hiển thị vấn đề hoàn hảo cụ thể trước khi bắt đầu tối ưu hóa.

không bao giờ biết vấn đề thực sự có thể là gì, sự cáu kỉnh thường gây ngạc nhiên! rất thường xuyên!

API

Người tạo API suy nghĩ quá trừu tượng và có đầu óc lớn

thường cằn nhằn không quan tâm quá sâu đến chi tiết của api: muốn ghi tệp hoặc sắp xếp danh sách hoặc bất cứ điều gì, chỉ muốn gọi write() hoặc sort() hoặc bất cứ điều gì

nhưng các nhà phát triển api não lớn nói:

không nhanh như vậy, grug! tập tin đó có được mở để ghi không? bạn đã xác định Bộ so sánh cho loại đó chưa?

bực bội tìm cách tự kiềm chế với tay với câu lạc bộ một lần nữa

không quan tâm đến những thứ đó ngay bây giờ, chỉ muốn sắp xếp và ghi tệp mr big brain!

Phát triển giao diện người dùng

một số người không ác cảm, khi đối mặt với việc phát triển web, hãy nói:

Tôi biết, tôi sẽ chia cơ sở mã mặt trước và mặt sau của mình thành hai phần và sử dụng thư viện SPA mới hấp dẫn nói chuyện với mặt sau API GraphQL JSON qua HTTP (điều này thật buồn cười vì tôi không chuyển siêu văn bản)

bây giờ bạn có hai hang ổ linh hồn quỷ phức tạp

grug không giống như các thư viện giao diện người dùng phức tạp lớn mà mọi người sử dụng

grug tạo htmx và hyperscript để tránh

giữ độ phức tạp thấp, HTML đơn giản, tránh nhiều javascript, ether tự nhiên của tinh thần phức tạp

có thể họ làm việc cho bạn, nhưng không có tin tuyển dụng, xin lỗi

phản ứng tốt hơn cho công việc và cả một số loại ứng dụng, nhưng bạn cũng trở thành thủ lĩnh của con quỷ phức tạp dù muốn hay không, xin lỗi, đó là cuộc sống phía trước

Sợ trông ngu ngốc

ghi chú! rất tốt nếu grug cấp cao sẵn sàng nói công khai: “hmmm, điều này quá phức tạp đối với grug”!

nhiều nhà phát triển sợ nhìn ngu ngốc (GẤP), tức giận cũng có lúc GẤP, nhưng tức giận học cách vượt qua: rất quan trọng cấp cao cáu kỉnh nói “điều này quá phức tạp và khiến tôi bối rối”

điều này khiến những học sinh cấp dưới khó chịu thừa nhận quá phức tạp và không hiểu cũng không sao, thường là trường hợp như vậy! GẤP GẤP nguồn chính của sức mạnh ma quỷ phức tạp đối với nhà phát triển, đặc biệt là những kẻ trẻ tuổi!

Hội chứng kẻ mạo danh

grug lưu ý rằng nhiều kẻ mạo danh như vậy cảm thấy trong quá trình phát triển

bây giờ, grug làm cho phần mềm có nhiều công việc và thành công nguồn mở vừa phải, nhưng bản thân grug thường cảm thấy không biết mình đang làm gì! rất thường xuyên! grug vẫn sợ phạm sai lầm phá vỡ mã của mọi người và làm thất vọng những grug khác, kẻ mạo danh!

có lẽ bản chất của lập trình là khiến cho hầu hết mọi người cảm thấy mình là kẻ mạo danh và tốt nhất là chấp nhận: không ai là kẻ mạo danh nếu tất cả mọi người đều là kẻ mạo danh

bất kỳ người trẻ tuổi nào đọc đến đây có lẽ sẽ thành công trong sự nghiệp dẫn chương trình ngay cả khi sự thất vọng và lo lắng luôn ở đó, xin lỗi