Phân tích những lỗi thường gặp của người mới lập trình, pt. 2

Xin chào lần nữa mọi người! Chúng ta sẽ tiếp tục xem xét các vấn đề mà một lập trình viên trẻ và chưa trưởng thành có thể gặp phải trong công việc đầu tiên của mình. Phần đầu tiên có thể được tìm thấy ở đây . Tiếp tục đi.

13. Không tuân thủ các nguyên tắc về phong cách viết mã.

Các nhóm phát triển thường tuân theo một phong cách mã hóa duy nhất. Nghĩa là, các nhà phát triển riêng lẻ tuân theo các quy tắc bằng văn bản hoặc bất thành văn nhất định để đảm bảo rằng phong cách viết mã của họ không khác với những người khác. Đừng cố gắng tạo sự khác biệt bằng phong cách viết mã đặc biệt: điều này không làm cho bạn trông đẹp hơn. Nếu bạn là người mới tham gia dự án, bạn nên tìm hiểu ngay xem có tài liệu nào xác định nguyên tắc chung về phong cách mã hóa hay không. Có thể có một số tệp kiểu cho dự án cụ thể mà bạn cần yêu cầu và nhập vào IDE của mình (ví dụ: IntelliJ IDEA), để IDE có thể cung cấp gợi ý kiểu mã hóa chính xác. Ví dụ: kiểu có thể yêu cầu sử dụng công cụ sửa đổi cuối cùng bất cứ khi nào có thể. Tệp kiểu cho phép IntelliJ IDEA đánh dấu màu vàng bất kỳ biến nào mà điều này không được tôn trọng.

14. Trở nên chán nản vì sai lầm

Sai lầm là điều bạn phải làm quen. Họ đã, đang và sẽ như vậy. Không quan trọng bạn là người mới bắt đầu hay một kiến ​​trúc sư nghiêm túc, bạn sẽ luôn mắc sai lầm. Số lượng và mức độ nghiêm trọng của những sai lầm của bạn có thể thay đổi nhưng chúng sẽ đồng hành cùng bạn trong suốt sự nghiệp. Đôi khi bạn phải vật lộn để hoàn thành công việc cả tuần, bạn mắc sai lầm, rồi đến tối thứ Sáu, bạn lẻn về nhà như một con chó bị đánh mà không thể sửa được sai lầm chết tiệt đó. Đó là một cảm giác khó tả nhưng không phải là điều khiến bạn nản lòng. Suy cho cùng, một điểm khác biệt quan trọng giữa một nhà phát triển có kinh nghiệm và một người mới vào nghề là cách họ xử lý lỗi. Các nhà phát triển có kinh nghiệm không để tâm đến chúng mà thay vào đó coi chúng là kinh nghiệm. Sẽ không ai mắng bạn vì đã phạm sai lầm. Điều này là bình thường - ai cũng có lúc gặp rắc rối. Một lần nữa, bạn có thể nhờ đồng nghiệp giúp đỡ. Và đừng quên những người như người quản lý dự án (PM). Nếu bạn gặp khó khăn về điều gì đó, bạn nên liên hệ ngay với Thủ tướng. Anh ấy hoặc cô ấy có thể giúp bạn tìm một người là chuyên gia trong lĩnh vực có vấn đề. Trong mọi trường hợp, PM cần được thông báo về bất kỳ vấn đề nào bạn gặp phải trong dự án. Công việc của Thủ tướng là giúp giải quyết tất cả các loại vấn đề, bao gồm cả giao tiếp và tương tác giữa các thành viên trong nhóm. Tóm lại: Sai lầm xảy ra , đừng để chúng giết chết bạn. Thay vào đó, hãy chấp nhận chúng như một thử thách đối với bạn và kỹ năng của bạn. Cuối cùng, đó chỉ là một phần của công việc.

15. Không thực hiện an toàn chỉ.

Không có gì tốt được tạo ra một cách dễ dàng. Mọi nhà phát triển cần hiểu rằng việc viết chức năng cụ thể, cho dù đó là mô-đun hay chỉ là một phương thức, đều cần có kế hoạch về những gì sẽ được thực hiện và cách thức thực hiện. Theo quy định, khi phát triển chức năng ở bất kỳ mức độ phức tạp nào, bạn cần tuân thủ quy trình sau: Nhiều lỗi phát sinh trong mã do người mới lập trình viết có liên quan đến các bước trong quy trình này. Tất nhiên, bạn không thể loại trừ khả năng có những lúc bạn cần viết mã nhanh chóng mà không do dự ngay khi nhìn thấy nhiệm vụ. Nhưng điều này thường chỉ có tác dụng đối với một số nhiệm vụ và phương pháp nhỏ nhất định mà việc thực hiện chúng rõ ràng và không cần phải suy nghĩ nhiều. Quy trình phát triển được đề cập ở trên phù hợp hơn với các nhiệm vụ phức tạp và lớn có thể được chia thành các nhiệm vụ phụ. Sẽ không phải là một ý tưởng hay khi bắt đầu viết mã mà không hiểu rõ bạn muốn viết gì. Đầu tiên, bạn cần suy nghĩ kỹ lưỡng và lên kế hoạch cho mọi việc. Cũng có thể hữu ích nếu bạn lấy một tờ giấy và một cây bút chì rồi cố gắng phác thảo các ý tưởng thực hiện của mình. Tôi luôn làm điều này khi lập kế hoạch cho chức năng phức tạp. Một lập trình viên dành phần lớn thời gian của mình không phải để viết mã mà là suy nghĩ về cách cấu trúc các chức năng được yêu cầu . Thật vậy, một khi bạn đã lên kế hoạch và suy nghĩ về mọi thứ, việc viết mã sẽ trở thành một quá trình máy móc thuần túy không rắc rối.

16. Làm việc quá sức

từ bộ phim "Câu lạc bộ chiến đấu" (1999) Có lẽ mọi người mới bắt đầu đều nghĩ rằng làm việc đến đêm sẽ bắt đầu hoàn thành được nhiều nhiệm vụ hơn và được giao phó nhiều trách nhiệm hơn. Trước đây tôi cũng nghĩ vậy, nhưng bây giờ thì không. Tôi nhận thấy rằng sẽ có lúc bạn chạm đến giới hạn của mình, khi bạn không còn khả năng suy nghĩ thỏa đáng nữa. Bạn bắt đầu trở nên khá buồn tẻ và cảm thấy sương mù tinh thần. Phải mất một giờ để làm những việc mà bạn có thể làm trong 10 phút nếu đầu óc bạn tỉnh táo. Hầu như không có ngoại lệ, sau khi vượt qua ranh giới mệt mỏi này, bạn gặp phải một số vấn đề tưởng chừng như không thể vượt qua. Nhưng sáng hôm sau khi đến làm việc bạn lại giải quyết được trong chớp mắt. Vì vậy, khi bạn cảm thấy mình đã đạt đến điểm này, đừng thức khuya. Chỉ cần về nhà và nghỉ ngơi thật tốt. Rốt cuộc, nếu bạn ngồi ở bàn làm việc đến tận đêm khuya, bạn không những không đạt được kết quả đặc biệt nổi bật trong những giờ phút dày vò này mà đồng thời còn có nguy cơ nghỉ ngơi kém (không đủ) trước ngày làm việc tiếp theo, khi bạn' sẽ làm hỏng việc một lần nữa. Hãy nghĩ về sức khỏe của bạn: có đáng để bạn hủy hoại nó như thế này khi mới bắt đầu sự nghiệp không? Tôi nghĩ là không. Đó là một thời gian đắt tiền để bị bệnh. Và hãy nghĩ về người chủ của bạn. Bằng cách làm việc quá sức, bạn đang khiến mọi việc trở nên tồi tệ hơn không chỉ cho bản thân mà còn cho cả chủ nhân của bạn. Ai cần một nhân viên thường xuyên buồn ngủ, người vì kiệt sức nên không thể thực hiện thuật toán sắp xếp đơn giản nhất? Vâng, chắc chắn có những lúc bạn phải đối mặt với thời hạn gấp gáp, những lúc mọi thứ không như ý muốn, và những lúc - và đây là sở thích cá nhân của tôi - "chúng ta cần cái này ngày hôm qua". Nhưng những tình huống này nhìn chung rất hiếm và khi bạn đã vượt qua được chúng, bạn cần phải ngồi xuống và xem xét cẩn thận xem chúng có thể xảy ra như thế nào và cách tránh chúng trong tương lai.

17. Bỏ bê kỹ năng tiếng Anh

Nhiều nhà phát triển đầy tham vọng ưu tiên học công nghệ và trì hoãn việc học tiếng Anh. Đây là một sai lầm nghiêm trọng, vì thông thường một lập trình viên hoàn toàn phù hợp cho vị trí cấp dưới (hoặc thực tập sinh), nhưng lại không nhận được việc làm do kỹ năng tiếng Anh yếu. Vâng, tất nhiên, có những trường hợp bạn có thể vượt qua mà không cần tiếng Anh. Theo quy định, những người như vậy được thuê tại địa phương cho các dự án ở các quốc gia không nói tiếng Anh. Nhưng các công ty địa phương không trả lương giống như các công ty nước ngoài. Và sẽ rất, rất khó để có được một mức lương xứng đáng, thậm chí theo thời gian. Chính vì vậy bạn không nên bỏ qua tiếng Anh. Thay vì gác lại tiếng Anh, bạn cần học nó để tập trung ngay vào các dự án tiếng Anh. Thật vậy, hãy suy nghĩ một chút - tiếng Anh hiện là ngôn ngữ kinh doanh quốc tế. Dù bạn đi đến quốc gia nào, bạn cũng có thể tìm được ngôn ngữ chung với người khác nếu bạn biết tiếng Anh. Điều này cũng đúng trong các dự án phát triển. Không quan trọng dự án có trụ sở ở đâu: Đức, Úc, Pháp hoặc nơi khác - tất cả thông tin liên lạc, tất cả nhiệm vụ, tài liệu, v.v. sẽ bằng tiếng Anh. Và nếu bạn suy nghĩ một chút, bạn sẽ đồng ý rằng điều này rất tiện lợi phải không?

18. Theo đuổi công nghệ thời thượng

Khi các nhà phát triển bắt đầu con đường của mình, họ thường cố gắng theo kịp các công nghệ mới nhất. Đó có phải là điều đúng đắn để làm? Một mặt thì có: những công nghệ, dự án mới nhất ... Nhưng liệu việc đặt điều này lên ưu tiên hàng đầu có đáng không? Có lẽ tốt hơn nên theo đuổi "bộ công cụ cổ điển" dành cho một chuyên gia trong lĩnh vực của bạn? Mới chắc chắn là tốt, nhưng bạn không được quên những công nghệ cơ bản trong lĩnh vực của mình. Và chỉ khi đó, sau khi bạn đã có được một chút kinh nghiệm và kiến ​​thức sâu sắc về những điều cơ bản, bạn mới có thể thử một điều gì đó mới mẻ. Cũng nên lưu ý rằng các công nghệ mới có thể vượt trội hơn ở một số khía cạnh tinh tế, nhưng chúng có thể mất đi lợi thế ở những khía cạnh khác. Cho đến khi một nhà phát triển mới làm quen hiểu được những sự cân bằng này, tốt hơn hết là bạn nên gắn bó với các giải pháp đã được thử nghiệm theo thời gian. Ví dụ: nếu một lập trình viên đang phát triển một ứng dụng tương tác với một số dữ liệu, thì đừng vội sử dụng giải pháp NoSQL mới nhất chỉ vì nó đang thịnh hành. Một cơ sở dữ liệu SQL đã được thử và đúng thông thường (MySQL, PostrgreSQL, v.v.) rất có thể có tài liệu và giải pháp chi tiết trên StackOverFlow cho bất kỳ vấn đề tiềm ẩn nào :)

19. Học nhiều công nghệ và/hoặc ngôn ngữ khác nhau cùng một lúc

Ở trên chúng tôi đã nói về những người mới bắt đầu cố gắng học các công nghệ thời thượng. Chà, còn việc nghiên cứu đồng thời nhiều công nghệ hoặc ngôn ngữ thì sao? Rõ ràng, bạn đã từng nghe nói đến những lập trình viên biết nhiều hơn một ngôn ngữ lập trình và thông thạo nhiều công nghệ. Nhưng tôi sẽ nhanh chóng chỉ ra rằng những người này không hề mới làm quen với lập trình. Đây là những người có nhiều năm kinh nghiệm đằng sau họ. Họ đã làm chủ được công nghệ ban đầu của mình và ngày càng tiến xa hơn. Những người mới bắt đầu cố gắng nắm vững mọi thứ cùng một lúc nên nhớ câu tục ngữ xuất sắc: "đuổi theo hai con thỏ rừng và bạn sẽ không bắt được con nào". Hậu quả có thể là bạn sẽ không nắm vững tốt môn nào mà chỉ học các môn một cách hời hợt. Sẽ có nhiều nhu cầu về một chuyên gia biết sâu một ngôn ngữ hơn là một người biết một chút về mọi thứ. Vì vậy, nếu bạn muốn biết nhiều ngôn ngữ và công nghệ, bạn cần tiếp cận chúng một cách khôn ngoan. Để bắt đầu, bạn cần chọn một ngôn ngữ cơ bản, cốt lõi mà bạn phải học sâu. Và chỉ khi đó bạn mới nên bắt đầu nghiên cứu các lĩnh vực khác. Ví dụ: trở thành chuyên gia Java, sau đó học Python như ngôn ngữ thứ hai. Sau đó, bạn có thể tìm hiểu điều gì đó về phản ứng/góc cạnh cho giao diện người dùng. Trong trường hợp này, chúng ta đang nói về những công nghệ không thể thay thế cho nhau, chẳng hạn như C# và Java, mà bổ sung cho nhau, mở rộng cơ hội nghề nghiệp của bạn. Nhưng một lần nữa tôi nhắc lại: bạn không nên cố gắng học mọi thứ cùng một lúc. Bạn cần phải đi tuần tự. Có thể nói như vậy là bắt từng con thỏ một.

20. Mục tiêu được xây dựng không chính xác

Bạn đặt mục tiêu cho mình như thế nào? Trở thành một nhà phát triển thú vị? Hãy nhớ điều này một lần và mãi mãi: bạn cần đặt ra những mục tiêu cụ thể, hay nói cách khác - những mục tiêu có thể đạt được. Tôi đang nói về cái gì vậy? Chẳng hạn, bạn đặt cho mình mục tiêu: “Tôi muốn trở nên giàu có”. Nhưng làm thế nào bạn biết được liệu bạn đã đạt được mục tiêu này hay chưa? Hoặc làm thế nào để bạn đo lường mức độ gần đạt được mục tiêu đó? Chà, nếu bạn đặt mục tiêu “Tôi muốn kiếm một triệu đô la” thì sẽ rõ ràng hơn một chút phải không? Khi bạn đã kiếm được 10.000 đô la, bạn sẽ tiến gần hơn tới mục tiêu của mình là 10.000 đô la — chỉ còn 990.000 đô la nữa. Vẫn còn rất nhiều điều phải đạt được, nhưng bạn có thể cảm nhận được sự tiến bộ của mình và hiểu được đích ở đâu, vì vậy bạn sẽ có động lực để tiếp tục. Về sự nghiệp của bạn, bạn nghĩ thế nào về việc đặt cho mình một mục tiêu cụ thể hơn? Ví dụ: Tôi muốn trở thành trưởng nhóm. Hoặc một nhà phát triển cấp cao. Hoặc cuối cùng là một kiến ​​trúc sư. Chà, mọi nhiệm vụ lớn đều cần được chia thành các nhiệm vụ nhỏ. Bạn không trở thành trưởng nhóm khi bắt đầu sự nghiệp. Đặt thời hạn nếu có thể và phù hợp, đồng thời tập trung vào giai đoạn hiện tại.

1. Nếu chúng ta đang nói về việc trở thành một nhà phát triển cấp cao thì mục tiêu nhỏ đầu tiên sẽ là tìm được một công việc thực tập hoặc một công việc với tư cách là nhà phát triển cấp dưới tại một công ty.
2. Tiếp theo, bạn có thể đặt mục tiêu để nâng cao kiến ​​thức về một số công nghệ nhất định. Liên quan đến Java, bạn có thể chuẩn bị lấy chứng chỉ Cấp 1 của Oracle. Chúng tôi thiết lập khung thời gian để chuẩn bị và đạt được mục tiêu.
3. Sau đó, ví dụ: bạn có thể đặt mục tiêu cải thiện tiếng Anh của mình lên một cấp độ (ví dụ: từ B1 lên B2). Chúng ta vạch ra kế hoạch học tập, sắp xếp thời gian và tiến tới mục tiêu.

Đây là cách chúng ta có thể từng bước đạt được mục tiêu cuối cùng của mình (đồng thời tích lũy kinh nghiệm phát triển phần mềm).

21. Lý thuyết mà không thực hành

Một thực tế không thể chối cãi là chúng ta trở thành những chuyên gia giỏi hơn bằng cách nghiên cứu các công nghệ mới và đi sâu hơn vào các chủ đề mà chúng ta đã biết. Nhưng khi bắt đầu cuộc hành trình, các nhà phát triển hiếm khi nhận ra rằng việc ngấu nghiến hết cuốn sách kỹ thuật này đến cuốn sách kỹ thuật khác không mang lại lợi ích to lớn nếu kiến ​​thức mới không được thử nghiệm trong thực tế. Cá nhân tôi đã gặp điều này hơn một lần. Nếu bạn dành nhiều thời gian cho một cuốn sách nhưng không thực hành bất cứ điều gì từ nó, thì gần như tất cả những kiến ​​thức mới thu được sẽ bị lãng quên: bạn chỉ còn lại một ký ức mơ hồ chung về cách mọi thứ hoạt động. Kết quả là lãng phí rất nhiều thời gian mà không mang lại kết quả rõ ràng. Tại sao chúng ta nên lãng phí thời gian của mình? Cuộc sống không kéo dài mãi mãi. Điều đáng chú ý là khi học một công nghệ mới, bạn không nên tập trung vào lý thuyết: viết ra các ví dụ đã cho song song với việc đọc, thử nghiệm công nghệ mới. Đây là cách duy nhất để khiến bộ não của bạn ghi nhớ thông tin. Đúng, bạn sẽ tiếp thu những tài liệu mới chậm hơn, nhưng bạn sẽ tiếp thu được nhiều hơn đáng kể những gì bạn đọc. Hơn nữa, nếu bạn thành thạo một công nghệ thì công nghệ tiếp theo sẽ còn dễ dàng hơn để thành thạo (giống như học ngôn ngữ).

22. Chủ nghĩa cầu toàn quá mức

Hầu hết các nhà phát triển đều là người cầu toàn: những người phấn đấu cho sự hoàn hảo. Điều này có nghĩa là mã của họ cũng phải hoàn hảo. Vậy là mã của bạn đã được viết, kiểm tra, tinh chỉnh và có vẻ như đã đến lúc gửi nó đến nhánh chính. Nhưng bạn vẫn chưa hài lòng với đoạn mã đó nên bạn bắt đầu vặn vẹo nó theo cách này cách khác, tốn nhiều thời gian cho nỗ lực này. Và trong trường hợp này, thời gian là tiền của khách hàng. Những lập trình viên mới vào nghề dễ bị ảnh hưởng hơn trong việc tìm kiếm sự hoàn hảo này. Các nhà phát triển có kinh nghiệm đã quen với cảm giác rằng mã sẽ không bao giờ hoàn hảo và họ nên cố gắng viết nó tốt hơn. Nhưng đồng thời họ không đi đến cực đoan trong nỗ lực tiến gần hơn đến “lý tưởng”. Vì vậy, hãy nhớ học cách đạt được một phương tiện hạnh phúc: không phải theo kiểu cẩu thả và không cố gắng tạo lại Mona Lisa bằng mã.

23. Không suy nghĩ về kiến ​​trúc

Hãy để tôi nói lại lần nữa: bạn không nên viết mã lộn xộn. Ngoài khả năng đọc và hiệu suất, bạn cũng cần suy nghĩ về việc mã của bạn có thể ảnh hưởng như thế nào đến toàn bộ phần còn lại của ứng dụng. Ví dụ: việc mở rộng mã của bạn sẽ khó khăn như thế nào, v.v. Vấn đề là các nhà phát triển mới vào nghề, do thiếu kinh nghiệm, có thể không nhận ra ngay chức năng mới của họ sẽ ảnh hưởng đến ứng dụng như thế nào trong tương lai. Tầm nhìn xa này chắc chắn cần rất nhiều thực hành để phát triển. Nhưng những người mới tập phải làm gì? Không viết mã? Trong những tình huống này, chúng tôi có thể sử dụng nhiều mô hình lập trình khác nhau. Ví dụ: các nguyên tắc RẮN hoặc các mẫu thiết kế khác nhau có thể truyền đạt các phương pháp thực hành hữu ích cho bạn. Những mô hình này cũng cần được xử lý một cách thận trọng và không đi quá xa. Nhưng làm thế nào để bạn xác định được điểm khi bạn đang làm quá mức? Đây là lúc việc đánh giá mã của một đồng nghiệp có kinh nghiệm hơn sẽ giúp ích cho bạn. Bằng cách mang lại cái nhìn mới mẻ và khách quan, đồng nghiệp của bạn có thể chỉ cho bạn hướng đi đúng đắn.

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

Hội chứng kẻ mạo danh là một hiện tượng tâm lý trong đó một người không thể gán thành tích của mình cho phẩm chất, khả năng và nỗ lực cá nhân. Bất chấp những bằng chứng bên ngoài về hiệu suất nhất quán của họ, những người dễ mắc phải hội chứng này vẫn tiếp tục tin rằng họ là những kẻ lừa đảo và không xứng đáng với thành công mà họ đã đạt được. Nhiều nhà phát triển mắc hội chứng này. Có lẽ nó mang lại cho chúng ta sự kiên trì thúc đẩy chúng ta tiếp cận những kiến ​​thức và công nghệ mới. Bạn nhìn vào những đồng nghiệp giàu kinh nghiệm và thành đạt hơn và bạn cảm thấy khó chịu, như thể mình không xứng đáng với mức lương của mình. Hãy tin tôi, điều này không đúng. Sẽ luôn có những nhà phát triển giỏi hơn hoặc kém hơn bạn. Người khác nhìn bạn và cảm thấy khó chịu, nghĩ rằng họ sẽ không bao giờ trở nên giống bạn. Và điều này là bình thường. Phản hồi từ nhóm của bạn, đánh giá mã và thảo luận sẽ giúp bạn giảm bớt cảm giác này một chút. Tin tôi đi, ý kiến ​​​​của người ngoài sẽ làm bạn ngạc nhiên một cách thú vị, nhưng chỉ khi bạn thực sự không bỏ bê công việc và sự phát triển nghề nghiệp của mình. Nếu bạn lơ là những điều đó thì bạn đã chọn sai nghề rồi. Trong nghề này, bạn cần phải luôn học hỏi những điều mới mẻ và phấn đấu để đạt được điều tốt nhất. Nhưng tôi nghĩ những người tụ tập ở đây không hề lười biếng. Thay vào đó, người dân nơi đây đang kiên định hướng tới mục tiêu ấp ủ của mình. Nếu điều đó mô tả về bạn thì bạn không có gì phải sợ hãi.

25. Hiếm khi thực hiện cam kết

Hãy nhớ thực hiện các cam kết thường xuyên! Không phải cứ nửa giờ một lần, nhớ nhé. Nếu bạn dành một tuần để triển khai một số chức năng, thì bạn không nên thực hiện một lần xác nhận vào tối thứ Sáu mà nên thực hiện năm lần xác nhận. Hầu hết mọi nhiệm vụ lớn đều có thể được chia thành các nhiệm vụ nhỏ hơn để thuận tiện. Vì vậy, bạn hoàn thành những nhiệm vụ nhỏ hơn này và cam kết. Và đừng quên gửi những cam kết này đến máy chủ từ xa ngay lập tức. Nếu không, bạn có thể thực hiện các cam kết cả tuần và sau đó máy tính của bạn gặp lỗi phần cứng vào giờ ăn trưa thứ Sáu, và sau đó bạn mất cả tuần mà không được gì! Nhưng nếu bạn đã tải các cam kết của mình lên một máy chủ từ xa thì bạn sẽ chỉ cần kéo nhánh có cam kết cuối cùng của mình sang một máy tính khác và tiếp tục làm việc. Một điều nữa: không gửi chức năng mới tới máy chủ sản xuất trực tiếp vào tối thứ Sáu. Hãy tin tôi đi. Bạn không cần điều đó. Rất có thể những lỗi không mong muốn sẽ lộ ra và bạn sẽ dành cả ngày cuối tuần để sửa chúng. Và điều đó không vui chút nào. Bạn cần nghỉ ngơi vào cuối tuần. Tôi đoán đó là tất cả cho ngày hôm nay. Tái bút Một mẹo cuối cùng: viết thật nhiều mã. PPS Viết một lượng lớn mã TUYỆT VỜI, vì đó là cách duy nhất để có được nhiều kinh nghiệm cần thiết.