Нормально / приемлемо записывать заметки, мысли, алгоритмы, решения при кодировании и обслуживании? [закрыто]

У некоторых людей есть такая проблема, что они не могут думать без слов. И записывать их мысли и решения - самый эффективный способ продолжить.

Итак, это нормально и приемлемо, что я записываю свои мысли и решения в какой-то файл Notepad ++ во время кодирования?

Иногда это должно быть приемлемо, например, при воссоздании технической документации или рассуждениях о более сложных алгоритмах, но иногда это может быть странно, например, когда я рассматриваю варианты проектирования и пытаюсь сделать суждение.

Влияние этой практики на производительность неясно. С одной стороны - рассуждение с внутренними словами может быть быстрее, чем с письменными словами. С другой стороны - более сложные проблемы требуют написания. Кроме того, если кто-то застрял с большим количеством вариантов дизайна, то чувство лучше, когда написано решение, и это поднимает моральный дух.

Это не только нормально, но и хорошая идея.

Там есть известная цитата

«Дайте мне шесть часов, чтобы срубить дерево, и я проведу первые четыре заточки топора».

Потратьте время, чтобы организовать свои мысли и спланировать свою работу, прежде чем кодирование будет хорошо потрачено. Изложение этих мыслей на бумаге даст вам время подумать о своих планах, критиковать их и упорядочить таким образом, что было бы очень сложно, если бы вы делали это только «в своей голове».

Да, это вполне приемлемо и нормально.

Документирование процесса принятия решений часто полезно при повторном рассмотрении кода, чтобы помочь определить, почему код был написан определенным образом.

Эти заметки могут быть включены непосредственно в код в виде комментариев, если они достаточно короткие. Расширенные комментарии часто хранятся как часть внешнего технического документа.

Это чертовски хорошая идея. Прямо до тех пор, пока это не станет способом откладывать.

Ключ баланс. Я нахожу себя наиболее продуктивным, если я не ограничиваю себя, а собираю идеи по мере их поступления.

Если я делаю помол на низком уровне, и приходит идея высокого уровня, я просто записываю ее и возвращаюсь к ней позже.

Планирование работы - хорошая идея, но если вам не нужно общаться или представлять аудитории, лучшие инструменты - это ручка и салфетка. Поймай идею. Не тратьте время на то, чтобы сделать его красивым.

В любой профессиональной ситуации это не только «нормально и приемлемо», это обязательно. Типичный цикл разработки состоит из двух этапов документирования, прежде чем даже начинается любое кодирование:

1. Документ о функциональных требованиях: обычно пишется бизнес-аналитиками с указанием функциональности, которая будет реализована.

2. Детальный проект документа: который в значительной степени о чем вы говорите, просто более формальный, с указанием функциональной декомпозиции (факторинга) системы, алгоритмов и т. Д. Некоторые из моих (очень) старых находятся в сети, например, это .

Для менее формальной документации я на 110% согласен с предыдущими замечаниями по поводу встроенных комментариев. Это единственный путь; так или иначе, все остальное в конечном итоге теряется. Но аккуратные и вдумчивые встроенные комментарии - это отдельный навык кодирования, разработанный с помощью усилий и практики, как и любой другой навык. Вы можете увидеть некоторые из моих (очень) старых вещей, например, здесь . Этот стиль может или не может понравиться вам. Я бы порекомендовал сначала найти хорошо прокомментированный код в стиле, который вам нравится, и эмулировать его в своем собственном коде. Через некоторое время адаптируйте его так, как считаете нужным.

Отличное место для размещения такого рода информации - это сообщение коммита вашей системы контроля версий (SVN, git и т. Д.). Таким образом, вы можете увидеть изменения и их обоснование в одном месте.

В дополнение к другим хорошим ответам я добавлю, что я часто записываю свои мысли о том, что я пытаюсь сделать.

Ясность в формулировании того, что я пытаюсь сделать, помогает мне осознать предположения, предположения и / или требования, которые не обязательно выполняются.

Это тогда намекает на альтернативы, которые я могу затем обдумать лучше по очереди; это письмо помогает спасти мое место, если я думаю о чем-то еще.

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

Записывать все, что может сэкономить вам / (новым) членам команды - это время, которое вы хорошо потратите. Просто убедитесь, что это то, что кому-то может понадобиться позже, и не задумывайтесь, если это не настоящий долгосрочный проект.

Это также не должно занимать какое-то время. Если вы тратите время на размышления, вы можете записать свои мысли от 1 до 1 (при условии, что они будут / могут быть кому-то полезны).

Настоящей проблемой может быть переосмысление того, что вы пишете. Просто потому, что вы пишете, не означает, что вы должны придерживаться какого-то уже существующего формата или должны пройти весь процесс создания полной документации.

Если вы выбираете между тем, чтобы ничего не записывать и просто писать неформальные заметки в блокноте, просто пишите неформальные заметки.

Вы говорите: «У некоторых людей есть такая проблема, что они не могут мыслить без слов. И записывать свои мысли и решения - самый эффективный способ продолжить».

Если записывание ваших мыслей и решений является наиболее эффективным способом для продолжения, почему не было бы нормально и приемлемо действовать наиболее эффективным способом? Вы делаете то, что работает лучше для вас. Это может быть не то, что лучше всего подходит для кого-то еще. В этом случае вы не позволяете кому-то другому говорить вам, что лучше для вас, и вы не говорите им, что лучше для них. Каждый делает то, что для них лучше.

Люди могут держать в голове только семь «вещей» одновременно. Это причина семизначных телефонных номеров. Чтобы программисты работали эффективно, им нужно найти какую-то систему, которая могла бы выгружать вещи из их памяти и быстро извлекать ее позже по мере необходимости. Ваши заметки очевидны и прямолинейны, но каждый, кто работает над чем-то умеренно сложным, должен как- то это делать . Когда вы объединяете программу с кем-то, обратите внимание на его метод.

Одним из распространенных способов является разработка через тестирование. В этой методологии вы пишете один неудачный тест, вы пишете достаточно кода, чтобы пройти этот неудачный тест, затем вы реорганизуете код, чтобы он выглядел лучше, сохраняя при этом все ваши существующие тесты проходящими. Эта методология хранит все ваши заметки в тестах. Люди могут работать очень быстро, не делая заметок, потому что они просто сосредоточены на следующем тесте.

Другой распространенный способ - просто записывать свои заметки в коде как комментарии или заглушки псевдокода, а затем постепенно заменять их реальными вещами. Так я обычно пишу алгоритмы. Мой первый черновик - это просто основная функция с псевдокодом, затем постепенно он проникает в более глубокие и глубокие уровни абстракции.

Не расстраивайтесь, используя какой-либо метод, который вам подходит, но постарайтесь заметить, какие методы используют ваши «эффективные» коллеги. У них те же человеческие ограничения, что и у вас.