Как держать в голове проект по программированию над которым работаешь не каждый день?
Mrrl: если у вас возникает такая проблема - у вас проблема со сложностью кода. функции, классы, переменные - все это должно решать только одну свою задачу, и быть при этом настолько маленьким, насколько возможно. если есть например функция, которая вычисляет силу тока по закону Ома - что в ней такого может поменяться?
"изобретать" имя переменной не надо - через некоторое оно само становится очевидно.
а забывать на самом деле нужно. нужно изолировать завершенную функциональность в отдельных классах или хотя бы файлах, если нет ООП, а все остальное запомнит система контроля версия. мозг должен быть свободен для работы над более высокоуровневыми абстракциями.
ну а в самом деле, неужели у вас такой цейтнот, что некогда нормальное имя переменной придумать? оно в любом случае стоит того, чтобы потратить на это время.
создавая функцию с однобуквенными переменными вы как раз себе и создаете проблемы с пониманием этого кода через определенное время.
код пишется для человека а не для машины. если знаете за собой, что забываете всякое - помогите себе, напишите комментариев.
звучит так, будто вы программируете в состоянии напряжения. найдите источник этого напряжения.
если вы не успеваете записывать свой код - вероятно вы не в полной мере используете возможности современных IDE.
То же самое что и zoom на карте: 1. делаете общую схему с функциональными блоками и их связями. блоки - нумеруются. 2. каждый блок - детализируете в новой схеме. * тут делаете текстовые описание связей и все, что относится к схеме/к процессу в отдельном docx/xlsx-документе. (google docs) * на основе этого - не составит труда описать функции для кодинга, если позволяет уровень детализации данной схемы. 3. goto 2.
(разумно использовать draw.io и подключить к google docs/google disk)
- Вконтакте
Желательно использовать ООП. При использовании ООП можно сначала нарисовать схемы - так называемые диаграммы UML — в них обычно написано что какой класс делает и нарисовано как он связан с другими.
Сначала рисуете диаграммки что с чем как связано и потом пишете код.
Выглядит примерно так:
На данных диаграммах в первой строчке - название класса, во втором блоке - названия переменных, в третьем блоке - названия методов(функций). Стрелочки показывают как классы взаимодейтсвуют между собой, кто от кого наследуется и кто какие методы вызывает и т.д.
В целом для получения общей картины очень удобно использовать диаграммы, чтобы не забыть что где как устроено если программа большая. Во многих IDE есть возможность получить полное дерево классов.
- Вконтакте
- Вконтакте
- Вконтакте
- Вконтакте
Кажется, автору вопроса надо внимательно проработать книги: 1) Стив Макконнелл - "Совершенный код" 2) Мартин Фаулер и др. - "Рефакторинг. Улучшение существующего кода."
А по поводу "потом трудно вспомнить на чем я остановился, зачем введены те или или иные куски кода" - помогут системы управления версиями при условии комментирования изменений.
- Вконтакте
Dum_spiro_spero: Дело в том, что если упомянутые книги я перечитал даже не раз, и во многом они изменили мой подход к кодированию, то системами управления версий я вего лишь немного побаловался лет 10 назад и пока их не применяю. Это из-за того, что программирую немного и небольшие . их даже проектами назвать сложно, эдакие микропроектики. Там запутаться сложно.
А системы управления версиями действительно необходимы, когда проекты большие и/или их много и/или код запутанный.
Данных систем есть несколько разных, народ вроде бы сходится во мнении, что попроще и для малых проектов - svn (Subversion), для больших проектов и понавороченнее - например, git.
- Вконтакте
- Вконтакте
- Вконтакте
therhino: комментировать нужно, чтобы уменьшить время на вхождение в проект или отдельные области кода, особенно при командной работе, особенно в больших проектах.
Dum_spiro_spero: хорошо продумывать необязательно, можно делать и менять в процессе. Как ни странно, но изначально хорошо продуманные проекты нередко остаются просто хорошо продуманными проектами, без реализации или же с никому не нужной реализацией. Даже если все продумано и сделано идеально, со временем будет бардак. Миром правит хаос :)
Измельчать следует аккуратно, если переусердствовать, проект может получится излишне сложным. Нечто вроде лабиринта, путешествие по которому не будет доставлять никакого удовольствия и будет съедать много времени.
А писать в любом случае полезно, поскольку помогает не только вспомнить что-то, но и обнаружить ошибки и недоработки. Я вот уже с ноября пишу статейку по одному из своих проектов, за это время сделал два выпуска новых версий продукта и третий на подходе. Саму статью пока не дописал, но изменения в проекте сделал как раз из-за выявленных недоработок в процессе написания статьи :-)
В молодости, еще помню, была память хорошая, все держалось в голове и даже комментарии можно было не писать. Но старею, проектов становится больше и они существенно крупнее и сложнее. Дело доходит до того, что каждый понедельник приходится вспоминать, над чем я работал в пятницу. Быстро вспоминать помогает использование единых правил разработки, заметки в комментариях, если я что-то не доделал или запланировал на будущее, ну и задания самому себе :-) В заданиях, если использовать систему управления проектами, что-нибудь на подобии Assembla, ссылку на которую я показал в своем ответе, можно описывать ход выполнения задачи. Например обычно, когда я отправляю изменения кода в систему контроля версий, то указываю комментарий к заданию, к которому относятся изменения. Потом можно просто открыть задание и посмотреть ход его выполнения. Главное не забыть название и расположение проекта, над которым работаешь :-))