Comments 7
Наработанная кодовая база давит на не желание что-то с ней делать, что в этом случае делать?
Ещё важно выбрать хороший инструмент: язык, фреймворк, библиотеки. На том же реакте как ни пиши, через полгода хочется сжечь написанное
Да, это очень важно. Наше решение перевести в код можно тысячей способов. Упростить процесс можно используя готовые блоки: стандартные паттерны, алгоритмы, структуры, фреймворк и библиотеки. Чем больше из них знаем, тем богаче наши словари для перевода идеи в код, тем увереннее достигается результат, и тем проще его понимать тем, кто владеет теми же инструментами, что и автор кода. Яркий пример - коллекции: кто-то их использует и получает короткий и лаконичный код, кто-то пилит свои велосипеды для повторения части их функционала, и получает огромный малопонятный код, который приходится тщательно изучать, прежде чем получится извлечь идею, заложенную в него. Из-за того что во втором случае один и тот же функционал требует гораздо больших усилий для декодирования, его как минимум стоит избегать - это значительное усложнение кода без надобности. Проблема только в том, что значительная часть программистов до сих пор не в состоянии говорить на языке коллекций, хотя это очень простой инструмент. С более сложными инструментами ситуация может быть ещё более плачевной.
Вспомнилась классика:
Как я пишу легко и мудро!
Как сочен звук у строк тугих!
Какая жалость, что наутро
я перечитываю их!
Не коммитим сразу, перечитываем наутро!
Эта статья маст хэв для новичков.
Я разделяю проект на модули когда кода или сущностей становится много. Новую задачу начинаю с комментария с текстом задачи и шагами решения. Дальше под каждый шаг пишу метод. Если метод парсит или строит какой-то текст то в комментарии пишу пример. Сам метод начинаю с написания todo-шек. Имена методов и переменных всегда говорят о содержании.
Это пришло с опытом. Будучи студентом страдал отсутствием комментов и всё пихал в один файл :)
Почему в вашем коде так сложно разобраться