Як хтось, звик до мислення FP, читав імперативний код?


14

Я закінчив університет близько п’яти місяців тому і працював у місцевому стартапі останні чотири місяці. Перебуваючи в університеті, я самостійно вивчав Haskell, F # тощо. Нас викладали Java в університеті, але я дуже швидко зазнав функціонального програмування, і провів з ним набагато більше часу, ніж я займався імперативним програмуванням. Як результат, мій мозок підключений до функціонального мислення. Компанія, до якої я приєднався, використовує Python, і код вкрай необхідний. Мені дуже важко читати імперативний код. Я не можу відслідковувати мутації. Коли гніздування "для іншого" для ... проходить більше чотирьох рівнів глибиною, я повністю втрачаю слід того, що відбувається в коді. Щоб додати до нього, Python - це динамічна мова, тому в коді немає типів. Це ' Пройшло кілька тижнів, відколи я намагаюся зрозуміти частину нашої кодової бази (яка нібито є «помірно складною»), але я поки що не досяг помітного прогресу в її розумінні. Будь ласка, запропонуйте мені кілька практичних прийомів щодо того, як я повинен розуміти цей код. Спасибі заздалегідь!

Редагувати:
Можливо, я також повинен зазначити, що в коді дійсно не так багато коментарів, і назви також не дуже інтуїтивно зрозумілі.


1
Ви б не мали жодних коментарів чи неточних коментарів? Я впевнений, що коментарі не старіють за умов, які ви згадуєте.
Ларрі Коулмен

Якщо код не міститься в тому надзвичайно малому підмножині коду, який можна віднести до "самокоментування", я хотів би мати хоч якісь коментарі, які, принаймні, можуть містити ряд корисних підказок, щоб провести мене через інакше нерозбірливий хитрець! Але це тільки я!
Джон Тоблер

2
Навіть імперативні програмісти, як правило, обмежують свої побічні ефекти, хоча б інтуїтивно, і пишуть невеликими методами. Я думаю, що ви щойно приземлилися на менш ідеальній базі коду.
Маурісіо Шеффер

Відповіді:


14

Розуміти застарілий код важко. Це майже не має нічого спільного з функціональним та процедурним.

  1. Створіть якусь карту. Складова схема пакетів і модулів Python. Для кожного модуля вам потрібно буде створити діаграми класів.

  2. Використовуйте інтерпретатор Python. Ви повинні мати можливість імпортувати модулі, створювати об’єкти та здійснювати їх інтерактивно. Тому популярний Python. Ви можете надрукувати, type(x)щоб побачити, що саме є змінною ( x ).

  3. Коли ви сумніваєтесь, обов'язково прочитайте код тестування пристрою. Якщо немає одиничного тестового коду, у вас є великі проблеми, що виникають, крім вивчення нової бази кодів.

  4. Запишіть речі. Почніть з бічних документів. Потім, коли ви думаєте, що знаєте, що відбувається, додайте докстрингові коментарі до функцій, методів та класів. Додайте їх рано і часто.

  5. Використовуйте Sphinx за допомогою "autodoc" для збору того, що ви вивчаєте.

Найважливіша частина - це. Важко тримати речі в голові. Простіше зберігати речі у файлах документації.


6
+1. Зрозуміти будь-який застарілий код важко, навіть якщо він добре написаний.
Quant_dev

12

Мені дуже важко читати імперативний код. Коли гніздування "для іншого" для ... проходить більше чотирьох рівнів глибиною, я повністю втрачаю слід того, що відбувається в коді.

Зачекайте ... хтось повністю втратить слід від коду з такими глибокими рівнями вкладення. Або як сказав Лінус Торвальдс:

Якщо вам потрібно більше 3-х рівнів відступу, ви все одно накрутили і повинні виправити свою програму.

Можливо, я також повинен зазначити, що в коді дійсно не так багато коментарів, і назви також не дуже інтуїтивно зрозумілі.

Це не звучить так, ніби ваша компанія дотримується загальних найкращих практик.

Якби я був ти, я просто спробував би зрозуміти базу коду за дисципліною та силою. Просто вкопайтеся в нього, знову і знову і знову. Мабуть, як що-небудь. Зараз ви відчуваєте, що перебуваєте під водою і не можете дихати, але продовжуєте вивчати кодову базу, і незабаром ви випливете на поверхню.

Я боюся, що у вашому запитанні бракує технічних деталей, щоб запропонувати вам гарну пораду, як зрозуміти базу даних коду, але ніколи не помиліться пройти це з досвідченими колегами за кілька сеансів. Дозвольте їм пояснити вам загальну архітектуру та те, як різні компоненти взаємодіють між собою, а також прийняті ними рішення щодо впровадження.

Важко дати загальні поради щодо переходу від функціональних мов до імперативних / OO. Звичайно, я міг би згадати кілька квіткових фраз на кшталт "Вам потрібно думати про стани та поведінку об'єктів", але це вам не допоможе багато, я думаю, це щось, що вам доведеться пережити.


Проблема відступу може бути гірше: коли мова є столбчатим кодом (як RPG), і НЕ який - або фактичний відступу. Деякі інструменти намагаються виправити це ...
Clockwork-Muse

2

Якщо (великі, якщо з поганої практики ви описуєте) є одиничні тести, то ви можете подивитися на ті, щоб побачити, як перевіряється код. Це може добре зрозуміти, що робить код.

Інакше я б запропонував прочитати більш загальний код python, щоб звикнути до того, як це написано.


2

Ви можете спробувати перекласти деякі фрагменти з Python в псевдо-Haskell або що завгодно. Це може дати вам уявлення про те, які імперативні конструкції вільно відображають в які функціональні конструкції. Коли ви отримаєте більше досвіду, імперативні конструкції почнуть відчувати себе ріднішими.

Я перейшов від програмування OCaml та Haskell до програмування Java та Python, і мій досвід полягає в тому, що імперативне програмування не є таким великим стрибком, як динамічне введення тексту, яке донині відчуває себе чужим.


1

Я пропоную вам поставити точки перерви і почати використовувати команду Далі (як ніби ви налагоджуєте), це допоможе вам зрозуміти потік (можливо, на гілках, є шляхи, які, швидше за все, будуть взяті, на ті, на які слід зосередитись, щоб отримати загальне уявлення про код).

(У мене були хороші результати з Eclipse разом із PyDev як плагіном Eclipse)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.