Nếu ý nghĩ về mã viết tay có vẻ ngớ ngẩn, bạn có thể ngạc nhiên khi biết rằng điều đó là không thể tránh khỏi. Nếu bạn không chắc chắn, hãy nghĩ về cuộc phỏng vấn xin việc gần đây nhất mà bạn đã làm, và nhớ rằng phòng phỏng vấn không có máy tính như thế nào - chỉ có người phỏng vấn của bạn, một tờ giấy trắng và một cây bút bi màu xanh.
Đối với các sinh viên trong số các bạn, đó thậm chí còn là một vấn đề lớn hơn khi điểm số của bạn bám vào các dòng mã mà bạn đã có chiến lược chen vào khoảng trống có sẵn trong phiếu trả lời của mình.
Và không chỉ vậy, các lập trình viên có kinh nghiệm có thể chỉ cho bạn gói tờ A4 mà họ đã lấy ra khỏi máy sao chép văn phòng để viết nguệch ngoạc về một thuật toán đặc biệt phức tạp mà họ đang làm việc.
Vì vậy, cho dù bạn là sinh viên đang ôn thi, người được phỏng vấn xin việc tiềm năng hay ai đó muốn giải quyết những ngõ cụt lập trình của họ, tôi hy vọng bài viết này sẽ giúp bạn khi bạn đặt bút lên giấy để viết mã.
Mặc dù tôi sẽ tập trung vào khía cạnh tương tự của việc viết mã, nhưng bạn có thể áp dụng các bước này để viết mã dưới bất kỳ hình thức hoặc ngôn ngữ nào. Vì vậy, hãy coi đây cũng giống như một hướng dẫn viết mã chung phù hợp với tôi nhưng cũng có thể rất hữu ích cho bạn trong công việc của bạn.
Tại sao phải viết nó ra?
Trước khi bắt đầu, điều cần thiết là phải hiểu rằng không ai mong đợi bạn ghi lại mã sẵn sàng sản xuất vào sổ tay. Nó không giống như bạn có thể thả nó vào một trình soạn thảo mã và biên dịch nó mà không có lỗi. Nếu mục tiêu tạo ra mã hoàn hảo, bạn sẽ được ngồi trước máy tính trong phòng phỏng vấn và phòng thi.
Mục đích của mã viết tay là làm việc thông qua logic trước. Người ta mong muốn được “vào trình duyệt” trong thiết kế càng sớm càng tốt, nhưng thông thường có sự khôn ngoan trong việc phác thảo thiết kế bằng tay. Phương tiện có độ trung thực thấp khuyến khích thử nghiệm nhanh chóng và những sai lầm không tốn kém.
Điều này cũng có thể đúng với mã, chủ yếu là khi làm việc với cú pháp và ngữ nghĩa. Điều đó nói rằng, nhận được cú pháp và ngữ nghĩa chính xác là luôn luôn một điểm cộng, mặc dù không phải là trọng tâm duy nhất của toàn bộ bài tập viết tay.
Hãy xem chúng ta có thể bắt đầu từ đâu khi nói đến mã viết tay.
Biết câu hỏi của bạn
Trong năm cuối đại học, tôi không thể thực tập hoặc thậm chí tham gia các cuộc phỏng vấn trong khuôn viên trường vì lý do sức khỏe. Kết quả là, cuộc phỏng vấn xin việc đầu tiên của tôi khá đúng nghĩa với số tiền đặt cọc cao.
Khi tôi nhìn lại bây giờ, cuộc phỏng vấn khá dễ dàng. Nhưng chưa bao giờ tham dự một lần nào trước đây, tôi đã lo lắng ngoài lý do. Điều đầu tiên mà những người phỏng vấn hỏi về lập trình là liệu tôi có thể tạo ra một hình tam giác ngược làm bằng dấu hoa thị hay không. Như tôi đã nói, nó thật dễ dàng - không có gì for vòng lặp không thể xử lý, phải không? Nhưng như tôi đã nói, sự lo lắng của tôi cũng xuyên qua mái nhà.
Tôi hít một hơi thật sâu, ấn lòng bàn tay vào tờ giấy trắng mà họ đã trải sẵn cho tôi, trượt nó càng chậm càng tốt về phía tôi trên bàn (tất nhiên là câu giờ), bấm bút, rồi tôi làm gì đó. bên phải.
Đầu tiên tôi vẽ một hình tam giác ngược làm bằng dấu hoa thị. Đó là cách tôi tìm thấy đôi chân của mình trên mặt đất để bắt đầu trả lời câu hỏi của họ.
Tôi đã từng chứng kiến những nhà phát triển xuất sắc gặp phải sai sót gì đó đơn giản vì họ không bao giờ hoàn toàn hiểu được những gì họ đang giải quyết.
Những câu hỏi mà chúng tôi làm việc không giống như những câu hỏi mà các nhà vật lý hay toán học giải quyết. Họ nhận được một tập hợp các tham số và tìm những thông số còn thiếu; câu hỏi của chúng tôi cũng là kết quả của chúng tôi. Chúng tôi đã được cho biết kết quả của chúng tôi là gì - chúng tôi phải tìm ra cách để đạt được chúng. Đó là lý do bắt buộc phải biết rõ câu hỏi vì bạn sẽ thấy kết quả.
Viết ra hoặc vẽ ra những gì bạn muốn xuất ra là một trong những cách tốt nhất để bắt đầu viết mã của bạn. Tôi hiểu rằng trong ngành công nghiệp có nhịp độ nhanh của chúng tôi, kỳ vọng là chúng tôi phải nhảy ngay vào lập trình bằng cách chạy bản demo “chào thế giới”. Và điều đó thật tuyệt khi bạn làm quen với một cú pháp không quen thuộc và rũ bỏ sự lo lắng của bạn về việc thử một cái gì đó mới.
Nhưng khi ai đó hỏi bạn một câu hỏi và cung cấp cho bạn một kết quả để nỗ lực, chẳng phải tốt hơn hết là bỏ điều đó xuống đầu tiên phải không? Câu hỏi / kết quả đó không chỉ là điểm xuất phát mà còn là điểm tham chiếu của bạn. Ở bất kỳ bước nào trong quá trình viết mã, bạn có thể xem xét nó để đảm bảo rằng bạn đang làm việc hướng tới nó và bạn đang đi đúng hướng.
Vì vậy, cho dù trong phiếu trả lời của bạn hay trong tờ giấy A4 trắng mà bạn chuẩn bị viết, hãy bắt đầu bằng cách dành một giây và viết ra những gì bạn đang cố gắng xuất ra. Bạn có thể đặt nó vào lề hoặc một góc nếu bạn không muốn nó trở thành một phần trong câu trả lời của mình. Chỉ cần đảm bảo rằng nó ở đâu đó mà bạn có thể tiếp tục tham khảo nó.
Phác thảo mã của bạn
Bước này giống như một con dao hai lưỡi. Nó có thể giúp bạn có một lộ trình cho chương trình của mình hoặc lãng phí thời gian của bạn. Công việc của tôi là đảm bảo nó là cái cũ.
Vì vậy, trước hết, tôi muốn nói: mã phác thảo là không cần thiết nếu phạm vi vấn đề hoặc câu hỏi của bạn nhỏ. Một lần nữa, thực hành này không mang tính quy định cũng không phổ biến cho tất cả các dự án hoặc tình huống. Hãy tưởng tượng tôi là người phỏng vấn bạn và tôi yêu cầu bạn viết cách căn giữa một phần tử trong trang web bằng cách sử dụng CSS theo nhiều cách nhất có thể. Chính xác là bạn sẽ không cần một phác thảo cho việc này. Các đoạn mã tương đối nhỏ cho mỗi phương pháp.
Nhưng bây giờ, giả sử tôi chỉ định bạn viết một ứng dụng web ghi lại chữ ký của người dùng thông qua giao diện màn hình cảm ứng và sau đó lưu chữ ký trên máy chủ. Không đơn giản như vậy, phải không? Bạn có nhiều điều cần tìm hiểu. Có lẽ, một chút phác thảo có thể giúp ích.
- Giao diện người dùng để ghi lại chữ ký - HTML Canvas? WebGL?
- Tắt các sự kiện con trỏ trên phần còn lại của trang web khi người dùng đang ký
- Chuyển đổi và lưu hình ảnh đã chụp thành tệp PNG - JS
- Sau đó, chuyển đổi nó thành blob (có thể) và lưu nó vào bảng dữ liệu nhật ký của khách truy cập.
Tôi đã viết một chuỗi các hành động thô mà tôi nghĩ rằng tôi có thể phải viết mã. Nó có thể ngắn hơn hoặc dài hơn, tùy thuộc vào những gì tôi muốn từ nó.
Tôi thực sự khuyên bạn nên phác thảo mã cho các dự án khách hàng. Viết phác thảo cùng với yêu cầu người dùng của bạn hoặc trên mặt sau của khung dây bạn đã in ra.
Ảnh chụp nhanh các điểm đầu dòng cung cấp cho bạn bản đồ, danh sách việc cần làm và danh sách kiểm tra để xác minh khi bạn kết thúc dự án - phần lớn bản tóm tắt toàn bộ dự án của bạn trong danh sách có độ trung thực thấp. Nó cũng có thể trở thành một mẫu để bắt đầu dự án tương tự tiếp theo của bạn.
Nhưng như tôi đã nói trước đây, bước này giống như một con dao hai lưỡi. Bạn sẽ phải giữ lại thông tin này ngắn gọn cho người kiểm tra và người được phỏng vấn khi có hạn chế về thời gian.
Nếu bạn không biết bắt đầu từ đâu, hãy chỉ viết ra ba chức năng cần thiết mà bạn sẽ phải viết mã trong ứng dụng của mình và nếu bạn có thời gian, hãy viết nó thành năm chức năng.
Nhưng đó là về nó. Dành càng ít thời gian càng tốt cho việc này và đừng đổ mồ hôi cho các chi tiết. Đề cương sẽ không giúp bạn ghi thêm điểm. Nó chỉ để giúp bạn đảm bảo rằng bạn đã trang trải mọi thứ. Nó ghi lại phản ứng ruột ban đầu của bạn và giữ cho bạn trung thực trong suốt vòng đời của dự án.
Tốc ký so với tốc ký
Đã đến lúc bắt đầu viết mã. Vì vậy, những gì bạn viết? “Bdrs” hoặc “border-radius“; "div -> p" hoặc "<div><p></div></p>“; "pl()" hoặc "println()“; "q()" hoặc "querySelector()"?
Nếu ai đó đang phân loại mã của bạn, thì không có lựa chọn nào khác. Bỏ qua các từ viết tắt, mã giả, phím tắt Emmet và bất kỳ hình thức viết tắt nào khác. Nếu không, không có lý do gì để cho rằng bất kỳ ai đọc bài này đều biết chữ viết tắt của bạn có nghĩa là gì.
Nó thực sự tùy thuộc vào bạn.
Nếu bạn đã mất liên lạc với việc viết bằng tay - và nhiều người trong chúng ta cũng vậy - tốt hơn là không nên viết quá nhiều với các ký hiệu tay dài, vì chúng trở nên tẻ nhạt. Đồng thời, không có gì gọi là quá tiết kiệm với bài viết của bạn. Không phải nếu bạn muốn một ngày nào đó có thể nhìn lại nó và hiểu những gì bạn đã viết ra.
Tôi có một tệp đang mở trong ứng dụng ghi chú của mình và một tập giấy ghi chú lót trên bàn, nơi tôi viết ra các đoạn mã mà tôi muốn lưu để tham khảo sau này. Chúng không có tổ chức, chỉ là một dòng dài các đoạn trích. Đó là lý do tại sao khi tôi duyệt qua các ghi chú cũ, tôi sẽ không biết mình muốn viết gì nếu tôi không viết chúng ra một cách rõ ràng.
Tôi quên cú pháp mọi lúc. Ví dụ: tôi đã sử dụng ký hiệu mũi tên cho các hàm JavaScript kể từ khi nó được giới thiệu (vì nó ngắn hơn) và tôi khá chắc chắn nếu ai đó đột nhiên yêu cầu tôi xác định một hàm bằng cách sử dụng function từ khóa, tôi thậm chí có thể đặt sai dấu ngoặc đơn hoặc tên hàm, gây ra lỗi cú pháp.
Không có gì lạ khi chúng ta quên các cú pháp mà chúng ta đã không sử dụng trong một thời gian. Đó là lý do tại sao tốt hơn nên viết ghi chú của bạn một cách rõ ràng khi bạn biết rằng bạn cần chúng để tham khảo trong tương lai.
Luồng mã không tuần tự
Không giống như bước cuối cùng, không áp dụng cho những người được phỏng vấn và những người làm bài kiểm tra của bạn, bước này đặc biệt dành cho bạn.
Hầu hết các ngôn ngữ lập trình được thông dịch, biên dịch và thực thi để đôi khi mã viết sẵn trong nguồn được thực thi sau khi được gọi. Chúng tôi làm điều đó trong JavaScript, chẳng hạn, với việc gọi hàm - các hàm có thể được định nghĩa ban đầu, sau đó được thực thi sau đó. Người kiểm tra và người được phỏng vấn có thể sử dụng điều này để bắt đầu làm việc với điểm quan trọng trong câu trả lời của bạn trước tiên.
Như tôi đã nói ngay từ đầu, mục đích của mã viết tay là để thông qua hoặc kiểm tra tính logic của bất cứ thứ gì mà bạn lập trình. Tốt nhất là bạn nên tập trung giải quyết vấn đề đó trước.
Hãy lấy một ví dụ sách giáo khoa cổ điển - một chương trình để tìm thứ n Số Fibonacci. Nếu tôi viết một dàn ý đơn giản cho nó, nó sẽ như thế này:
- Nhận đầu vào.
- Tính số Fibonacci.
- Tổng kết đầu ra.
- In đầu ra.
Tất cả các bước trong đề cương đó đều rất cần thiết; tuy nhiên, 1, 3 và 4 là bắt buộc hơn. Chúng cần thiết nhưng không đủ quan trọng để tập trung vào ngay lập tức.
Tốt hơn là nên bắt đầu viết mã để tính số Fibonacci hơn là tìm nạp đầu vào. Gói nó trong một hàm, sau đó tiếp tục và viết mã tuần tự và viết ra một dòng để gọi hàm đó nếu thích hợp.
Dành thời gian của bạn để viết mã tập trung vào trọng tâm của vấn đề.
Các chuyên gia thực sự có thể bỏ qua phía trước. Giả sử tôi có một dự án khách hàng và tôi phải làm việc với một số hình học tam giác - có hai cạnh, góc đối diện và phải tìm độ dài của cạnh thứ ba. Và tôi quyết định viết nguệch ngoạc trên giấy để bắt đầu thay vì mở IDE.
Đầu tiên, tôi sẽ vẽ hình tam giác, tất nhiên (đó là điều mà tôi rất có kinh nghiệm, như bạn có thể nói). Tôi sẽ viết ra một số độ dài và góc mẫu. Sau đó, tôi sẽ viết công thức (chắc chắn là những lời khen ngợi về việc tìm kiếm trực tuyến), và sau đó tôi sẽ chuyển ngay đến mã cho hàm.
Tôi không có ích gì khi viết ra các bước bắt buộc mặc dù tôi sẽ cần chúng trong mã sẵn sàng sản xuất. Nhưng sẽ khác nếu tôi phải viết điều đó vào phiếu trả lời trong một kỳ thi. Tôi không thể bỏ qua các bước khác; tuy nhiên, tôi vẫn có thể bắt đầu với mã cho công thức.
Mã giả
Chris đã viết một bài viết hữu ích về mã giả mà tôi thực sự khuyên bạn nên đọc một cách chắc chắn.
Đối với tất cả những người chuyên nghiệp cảm thấy như toàn bộ mã viết tay có vẻ không giống như tách trà của bạn nhưng vẫn có thể tò mò liệu nó có thể giúp gì cho bạn, thì mã giả có thể là số dư bạn đang tìm kiếm.
Nó tương tự như việc phác thảo mã, như tôi đã đề cập ở một trong các bước trước. Tuy nhiên, nó ngắn gọn hơn và cảm thấy giống như viết mã tốc ký. Nó đôi khi còn được gọi là “mã bộ xương”.
Dưới đây là một số mã giả nhanh cho bố cục lưới CSS:
Grid
5 60px rows
6 100px columnsKhông có nhiều thứ để viết! Vì vậy, mặc dù việc viết một chiếc bút chì lên giấy là một cách tuyệt vời cho việc này, nhưng việc ghi một số mã giả vào bất kỳ chương trình nào bạn đang sử dụng cũng hiệu quả, nhanh chóng và không tốn kém.
Không gian và nhận xét
Tôi tin rằng mã là 90% từ khóa và 10% tab. Withoutspacesthereadabilityofwordsdecreases. Thụt lề cũng cần thiết cho mã viết tay. Tuy nhiên, vui lòng không sử dụng nó cho mọi cấp độ vì chiều rộng của giấy sẽ giới hạn bạn. Sử dụng khoảng trống một cách thận trọng, nhưng hãy sử dụng chúng.
Nếu bạn đang viết mã cho mục đích sử dụng của mình, tôi cũng tin rằng nếu bạn đã làm theo mọi thứ tôi đã đề cập cho đến nay và đã viết ra đầu ra của bạn và một dàn bài trên trang, bạn thậm chí có thể không cần bao gồm nhận xét. Nhận xét cho bạn biết nhanh chóng bộ mã sau của nó có chức năng gì. Nếu bạn đã viết và đọc đề cương cho mã, thì nhận xét là ghi chú thừa.
Tuy nhiên, nếu phán đoán của bạn nói rằng hãy bỏ qua một điều, thì hãy làm điều đó. Thêm nó vào phía bên phải của mã (vì bạn sẽ không thể chèn nó giữa các dòng đã viết theo cách bạn có thể, chẳng hạn như VS Code). Sử dụng dấu gạch chéo, dấu ngoặc vuông hoặc mũi tên để biểu thị rằng chúng là nhận xét.
Đối với những thí sinh không tự tin với một cú pháp nào đó, hãy ghi lại những nhận xét. Bằng cách này, ít nhất, bạn đang cho người chấm điểm bài báo của bạn biết ý định của bạn với mã định dạng không chính xác đó. Và chỉ sử dụng các dấu phân cách chính xác để biểu thị nhận xét - ví dụ: đó sẽ là dấu gạch chéo về phía trước cho JavaScript.
Tương tự và kỹ thuật số
Như tôi đã đề cập trước đó, mọi thứ tôi đang cung cấp ở đây có thể là lời khuyên về mã hóa chung. Nếu bạn không muốn thử điều này với giấy vật lý, bất kỳ ứng dụng ghi chú nào cũng hoạt động.
Nhưng nếu bạn định thử con đường kỹ thuật số, khuyến nghị của tôi là hãy thử sử dụng một cái gì đó khác hơn là một ứng dụng ghi chú thẳng. Làm việc với các công cụ kỹ thuật số trực quan hơn - sơ đồ luồng, bản đồ tư duy, khung hình dây, v.v. Chúng có thể giúp bạn hình dung kết quả, đường viền và bản thân mã.
Tôi không phải là một công dân kỹ thuật số (ngoại trừ làm việc trên web và gần đây chuyển sang đọc sách điện tử), vì vậy tôi gắn bó với máy tính xách tay vật lý.
Công cụ yêu thích của tôi cho mã viết tay
Bất kỳ bút chì và giấy sẽ làm! Nhưng có rất nhiều tùy chọn ngoài đó, và đây là một vài công cụ lựa chọn tôi sử dụng:
Không có cách "viết" để viết mã
Tôi hy vọng, nếu không có gì khác, cách viết mã nhỏ bằng bút chì và giấy của tôi sẽ giúp bạn đánh giá cách bạn đã lập kế hoạch và viết mã. Tôi thích biết cách các nhà phát triển khác tiếp cận công việc của họ và đây là cách của tôi để bạn có thể hiểu rõ hơn về cách tôi thực hiện công việc.
Một lần nữa, không có gì ở đây là khoa học hay nghệ thuật chính xác. Nhưng nếu bạn muốn thử lập kế hoạch mã viết tay, đây là mọi thứ chúng tôi đã đề cập trong một danh sách có thứ tự đẹp mắt:
- Bắt đầu bằng cách viết ra (với dữ liệu mẫu, nếu cần) kết quả đầu ra của mã của bạn.
- Viết phác thảo cho mã. Vui lòng giữ nó thành ba bước cho các dự án nhỏ hoặc những dự án ít phức tạp hơn.
- Sử dụng ký hiệu dài tay. Các nhà phát triển viết cho chính họ có thể sử dụng ký hiệu viết tắt miễn là văn bản dễ đọc và có ý nghĩa đối với bạn khi bạn tham khảo nó sau này.
- Khi bị hạn chế về thời gian, hãy cân nhắc viết mã giải quyết trọng tâm của vấn đề trước. Sau đó, hãy ghi lại lệnh gọi tới mã đó vào đúng vị trí trong mã tuần tự của bạn.
- Nếu bạn cảm thấy tự tin, hãy thử viết mã giả đề cập đến ý chính.
- Sử dụng các khoảng cách và thụt lề thích hợp - và lưu ý đến chiều rộng của giấy.
Đó là nó! Khi bạn đã sẵn sàng để thử viết mã bằng tay, tôi hy vọng bài viết này giúp bạn bắt đầu dễ dàng. Và nếu bạn đang chuẩn bị cho một kỳ thi hoặc một cuộc phỏng vấn, tôi hy vọng điều này sẽ giúp bạn tập trung vào việc trả lời đúng câu hỏi.
