Майже кожен досвідчений програміст каже, що дуже корисно читати код інших професіоналів. Зазвичай вони консультуються з відкритим кодом.
Чи читаєте ви це чи ні? Якщо так, то як часто і яка процедура читання коду? Також новачкам трохи важко впоратися з SVN - згустками файлів. Яке рішення?
Відповіді:
Чи читаєте ви це чи ні?
Так.
Якщо так, то як часто
Щодня. Постійно. Я працюю з численними проектами з відкритим кодом (в основному пов'язані з Python) і повинен прочитати джерело, оскільки це найбільш точна документація.
і яка процедура читання коду?
Гм. Відкрийте і прочитайте.
Також новачкам трохи важко впоратися зі SVN - згустками файлів. Яке рішення?
Відкрийте і прочитайте. Потім читайте більше.
Це не легко. Ніщо не спрощує. Королівської дороги до розуміння немає. Це вимагає роботи.
До головоломки у вас є кілька шарів. Спочатку почніть з високого рівня, так би мовити, з пташиного польоту. Після того, як ви перевірите проект, у структурі каталогу з’явиться купа файлів. Це те саме, чи ви дивитесь на відкритий чи закритий джерело (вихідний код все-таки є вихідним кодом). Тож почніть з цього:
Це вимагає практики, але це, безумовно, можливо. Чим більше ви знаєте про бібліотеки та рамки, якими користується додаток, тим більше ви знаєте, як потрібно впорядкувати код і де шукати відповіді на конкретні запитання. Деякий код дотримуватися трохи складніше, особливо якщо він досить непрямий. Ось чому вам потрібен олівець і папір. Зрештою в голові згасає лампочка, і ти її отримуєш. Ось якщо читати решту коду має набагато більше сенсу.
Це не читання, як ти читаєш роман, а більше, як ти читаєш довідник. Хороший спосіб - вибрати нещодавно виправлену помилку з повідомлення в чеку, зробіть різницю, що змінилося, і прочитайте відповідні частини, поки не зрозумієте і проблему, і рішення. Добре розрекламовані вразливості безпеки - це цікаві помилки, оскільки їх можна обговорити на форумах. Потім виберіть одну з помилок "низько висячих фруктів" із трекера помилок і прочитайте, поки не зрозумієте, як її виправити самостійно. Більшість професіоналів з читання коду роблять випадково під час виправлення помилок або додавання функцій.
Зазвичай найкращі зразки коду ледь помітні. Ви моментально їх зрозумієте, не читаючи їх більше одного разу. Вони виглядають так, що писати було надзвичайно просто, навіть незважаючи на те, що хороший код зазвичай проходить через багато проектів. Це створює парадоксальне відчуття, що, звичайно, даний код - це очевидний спосіб зробити це, навіть якщо це не перший спосіб, який ви придумали.
Коли ви зіткнетеся з таким кодом, постарайтеся зрозуміти розуміння, яке було написане ним, та принципи проектування, тому, коли ви опинитесь у подібній ситуації в майбутньому, ви можете сподіватися застосувати ті самі принципи.
Один трюк, який я досить часто використовую, читаючи якусь складну функцію, кодовий сегмент - це розпочати рефакторинг на щось більш читабельне без зміни логіки.
Як важко поводитися з "купою файлів"? Це не відрізняється від написання власного коду, за винятком того, що ви не маєте попередніх знань про його організацію, якщо це не підтверджено документально.
Якщо ви, як заявлений програміст, не можете зрозуміти структуру проекту з "купки файлів", або це надзвичайно погано організований проект, або ви невмілий програміст (або, в крайньому випадку, обидва).
Почніть читати, спробуйте знайти деякі вхідні точки або інакше важливі основні класи / методи і побудуйте розуміння того, як все це відбувається звідти. Не буде миттєво, знадобиться час, але це можна зробити, навіть якщо документації взагалі немає.
Найкраще, на що ви можете сподіватися, читаючи код іншого проекту, будь то API чи фрагмент програмного забезпечення, - це те, що змінні, функції та назви макросів не скорочуються неоднозначно і не називаються, щоб ви могли з'ясувати їх наміри.
Але крім цього, потрібен пристойний обсяг знань, поширених на мові, методах програмування, а також про призначення самого коду, щоб можна було зануритися в складний код.
Я зараз намагаюся побачити, як Луа виконує щось своє чарівне, але я переходжу до точки, де багато ідентифікаторів названі неясно і досить скорочено до того, що я не можу зрозуміти, яка лінія намагається робити те, що я знаю, треба робити в якийсь момент коду функції ... Часті змінні однієї літери та досить скорочені імена макро / функцій роблять мою голову.
Подивившись на "По-перше, почніть з високого рівня, з виду пташиного польоту", як @Berin Loritsch засумував, ви можете шукати одиничні тести та / або інтеграції, якщо такі є.
Експерименти цікаво подивитися, як (api-) деталі працюють.
Інтеграціятесту зазвичай дає хороший огляд бізнес-процесів.