Каждый раз, когда я заканчиваю проект, всегда есть что-то, чему я научился (иначе я не нахожу это очень мотивирующим). Но я не могу вспомнить все, и гораздо позже я могу наткнуться на ту же проблему, с которой я столкнулся в предыдущем проекте, но уже не на то, как я ее решил (или, по крайней мере, на какие попытки я пытался).
Так что было бы неплохо записать это в каком-нибудь журнале? Я знаю, что писать вещи - это как писать документацию (что не всем нравится делать), и надеюсь, что наша память будет служить нам, когда это необходимо. Но имея документальное подтверждение, им можно поделиться с другими программистами и узнать, какие уроки они извлекли.
Так что ты думаешь?
experience
documentation
journal
gablin
источник
источник
[visible text](http://url.to/page)синтаксис;) Как этоКажется хорошей идеей проанализировать, что было сделано в конце проекта и обнаруженные проблемы, и посмотреть, что вызвало эти проблемы и как их избежать. Запись в журнале также является хорошей идеей, поскольку она облегчает вспоминание и позволяет избежать тех же проблем позже.
Совместное использование, с другой стороны, должно быть сделано с осторожностью. Конечно, это полезно для других разработчиков и руководителей проектов, но если вы работаете с клиентами, и эти клиенты могут прочитать о проблемах, которые у вас были в прошлом, они будут менее склонны начинать / продолжать работать с вами, потому что:
источник
У меня есть журнал Elder Scrollsy, где я записываю вещи каждый раз, когда узнаю что-то новое. Как вы можете себе представить, он стал довольно большим и полным информации.
На самом деле, я думал о создании программного обеспечения, которое позволит мне писать заметки и помечать их так же, как сайты SE с вопросами.
Я бы смог:
Это было бы очень полезно для меня.
источник
Я попробовал это однажды, с ежедневным журналом того, что я сделал, размышляя о том, что могло бы пойти лучше и что я должен попробовать по-другому в следующий раз. Это не были технические вещи - речь шла о взаимодействии с другими людьми в команде, решениях, принимаемых на собраниях и т. Д. (Да, у этой компании было достаточно собраний, и у меня было что написать каждый день!).
В конце концов я обнаружил, что журнал - это память только для записи: возможно, опыт написания его помог мне упорядочить свои мысли или оценить то, что я сделал, но примерно через шесть недель я обнаружил, что никогда не возвращался и не просматривал то, что я сделал. написано так что я перестал держать это.
Что касается технических примечаний, я не буду хранить их, если не буду представлять их конференции или клиенту. В противном случае мне достаточно набора закладок в Pinboard.in.
источник
Безусловно, следует вести журнал извлеченных уроков и извлеченных уроков. Первый объединяет самый дорогой тип обучения, полученный благодаря непосредственному опыту. Последнее требует / стимулирует активное обучение, которое необходимо, чтобы не сосать.
Журналирование является одним из старейших известных инструментов саморазвития, и оно вызывает (само) рефлексию, что является еще более старым методом. Нужны оба.
источник
Абсолютно. Правдивая история. Вскоре после прочтения этого вопроса я столкнулся с проблемой, которую, как я знал , решил раньше (проблема конфигурации, если она имеет значение). Я пролистал свой блокнот «Извлеченные уроки» (бумажное и ручное издание), и было решение: скопировать файл a в папку b.
Этот блокнот помогает мне двумя способами: во-первых, предоставляя место для поиска ответов на ранее заданные вопросы и решенные проблемы, а во-вторых, путем подкрепления знаний путем их записи (что-то вроде объяснения кому-то еще).
Конечно, я время от времени теряю эту записную книжку ...
источник
Это то, для чего предназначена система управления проектами / проблемами, например, TRAC, Jira или что у вас есть. На работе я разместил подробные комментарии, процедуры, зависимости в нашем TRAC и Jira, и поэтому, когда мы сталкиваемся с ранее замеченной проблемой, простой поиск дает нам ответ.
источник