[Q] Как да четем чужд код?


4
Здравейте колеги. Намерих няколко теми в Google, но реших да се допитам и до вас. Та въпроса е ясен : "Как да четем чужд код?".
Откъде да започнеш, когато ти дадат един проект и ти кажат "Напиши метод, който..." и реално се окаже, че се използват сума ти методи, класове и тн, докато се стигне до мястото, в което ще ползваш твоя метод. Проблемът се увеличава, именно когато започнеш да пишеш и се наложи да използваш стария код, с който разполагаш. Доколко е хубаво да се задълбава в него? Добра идея ли е като видиш метод за събиране на 2 числа (примерно) да си кажеш :"аха, той събира 2 числа. Не ме интересува как и защо." и ако евентуално ти трябва, да го използваш или е по-добре да задълбаеш в него, като се има в предвид, че той ще доведе до навлизането в други методи, те от своя страна в други и тн.



Отговори



4
Програмирането не е изкуство от към начин на подреждане на кода и цялостно форматиране. Качественият код е писан по определени правила, които ти позволяват да се ориентираш бързо в него. Задължително е всеки от нас да пише по тези правила. Част от тези правила е да даваш ясни имена на методите, които да ти казват какво прави метода без да има нужда да задълбаваш. В общия случай може и да нямаш достъп до някой метод. Реално целта е да има повечко абстракция и да се постига именно този ефект - да разбираш кода без да знаеш как работи.

от kbrizov (357 точки)


2
Здравей, в заданието би трябвало да ти бъдат определени входни и изходни данни, какво трябва да извършва методът, какви готови методи, класове и интерфейси можеш да използваш. За друго не се досещам.
Евентуално към тестовете може да се зададат изрично някои изисквания.

от ellapt (6303 точки)


6
Талантлив е не този програмист, който може да се ориентира за секунди в чужд код, а този, чиито код можеш да ползваш след само няколко секунди разглеждане.
Талантливия програмист ще ти е оставил точно толкова "вратички" (virtual и public методи), колкото е необходимо и безопасно за неговия код, и ще е скрил всичко, което не би трябвало да пипаш.
Проблема става много сериозен, когато се окаже че трябва да бръкнеш в "private" частта на кода, тази която програмиста е решил че няма да е достъпна за широката общественост. Да, талантливия програмист по инерция би трябвало и там да е спазвал конвенциите за четим код, но нерядко в дълбините на някои библиотеки нещата не са толкова белстящи, колкот би се искало на наследнците, получили кода за доработка. Да не говорим, че рядко можеш да се възползваш пълноценно от всички вътрешни методи, без да се запознаеш в детайли с цялата библиотека, не почувстваш стила и начина на мислене на човека, писал програмата.

от JulianG (5316 точки)


2
По принцип затова се пишат коментарите към методите. За да може някой друг колега да използва твойте методи и да знае за какво се използват.
Ако екипът е малък винаги можеш да отидеш до някой колега и да го попиташ да ти обясни с 2 думи какво прави този код и защо му се е наложило да използва еди какво си. Колкото и да е зает, предполагам винаги може да ти отдели 5 мин да ти каже това.
Накрая за код депендъсито, което си се опитал да опишеш. Ползваш само крайната функция и я разбираш. Ако се викат методите от други места в нея, само разбираш този метод какво прави и не го гледаш толкова подробно.
Качествено написания код улеснява четенето и разбирането на кода, но нищо повече. Писането на функции със значещи имена помага, когато няма коментари.

от yonchoy (2134 точки)


1

Привет от мен, ето мойте $0.02:
TL;DR: Ако средата ти го позволява - задълбавай, докато разбираш кода.

Чужд код, който ще четеш, може да идва от няколко места. Ще се опитам да разгледам вариантите.
1) Код от Open Source проект с поне 5 разработчика, които го поддържат. Там можеш да си почти сигурен, че методът прави това, което е написал, че прави. Неписано правило е, че всички public методи (достъпни за ползване) се документират (най-често с Doxygen). Виж примерно как са документирани тук: http://dbus.freedesktop.org/doc/api/html/group__DBusHashTable.html Тази документарция е автоматично генерирана от коментари в кода. Та при такива проекти, и големи корпоративни проекти, в които се спазват тези неписани правила, също можеш да имаш доверие.
2) Код писан от някой познат колега. Тогава в общи линии с опита се научаваш кой как пише, и просто на Пешо имаш доверие, на Гошо проверяваш за всеки случай, а на Иван - направо го пренаписваш. Няма двама души, които да пишат еднакъв код .
3) Код, свален от нета (stack overflow, други форуми). Там е винаги добра идея първо да разбереш какво сваляш, чак тогава го ползваш.

По твоя въпрос - виж на Joel Spolsky есето "The Law of Leaky Abstractions". Рано или късно ще ти се наложи да се запознаеш. Но има и нещо друго - всеки нов програмист, когато започне работа по съществуващ проект, винаги му е трудно. Неопитните скачат на "Леле, това е пълен боклук, толкова е омазано, че трябва да се пренапише от нула" . Не съм видял досега случай, в което това да е правилното решение, и от гледна точка на програмист, нито пък от бизнес гледна точка (Виж какво стана с Netscape, помни ли ги някой вече?). Другото - просто ще трябва да влезеш в начина на работа на екипа. 

Аз лично предпочитам да задълбавам. Отнема време отначало, но това време се изплаща многократно. Лично аз, преди 5 години и половина почнах да работя като мрежов програмист, ама не можеш нито код да пиша, нито от мрежи разбирах. Ама задълбавах (попаднах на страхотен тийм-лийдър, който ми даваше свободата да си върша работата добре, аз много рядко съм бил притискан от крайни срокове). Сега - ами сега се чувствам комфортно да чета код в ядрото на Linux примерно; и от ниво "Лампичките светят ли", стигаш до ниво "В kernel драйвера на DMA controller-а на Freescale има бъг, по-добре не ползвай I/OAT при копиране на пакетите от kernel space към user space, че ги реже; виж tcp_dma_copybreak, за да направиш workaround". И виждаш различни парадигми на практика. И почваш се научаваш с един поглед да различаваш работещ от неработещ код. И добре написан, от зле написан. 

Поздрави!
 




1
Това е най-трудното в тази професия, (поне за мен). Да научиш един език за програмиране и алгоритмите е по-лесно отколкото да екстендваш чужд код. Уви в много компании на качестото на кода не се държи особено, така че по-добре е човек от по-рано да се настрои за това. Честа практика е дори да няма предварителен проект, документация или задание, сяда се и почва да се пише нещо, после друг до дописва преправя, накрая става нещо страшно. За това е важно да се учат добри практики. Иначе универсални правила няма, зависи в каква идиотска обстановка ще попаднеш

от bgotov (1559 точки)