Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Корявенько конечно… «судовой журнал» это вообще в какую тему?
Никогда не вел подобных журналов, особенно к очевидным вещам. С другой стороны, если бы и вёл — это надо как-то дополнительно систематизировать, иначе они станут абсолютно бесполезными когда в той горе бумаг невозможно будет найти что-то конкретное. Или когда не знаешь что конкретно искать и единственный способ — это перечитать все записи. А если их читать… то это запросто можно залипнуть на N часов а то и дней.
Никогда не вел подобных журналов, особенно к очевидным вещам. С другой стороны, если бы и вёл — это надо как-то дополнительно систематизировать, иначе они станут абсолютно бесполезными когда в той горе бумаг невозможно будет найти что-то конкретное. Или когда не знаешь что конкретно искать и единственный способ — это перечитать все записи. А если их читать… то это запросто можно залипнуть на N часов а то и дней.
Если вы не может ЭТО нарисовать или записать — значит этого нет в природе и нет даже в ваших мыслях.
Кто то еще использует физические журналы? Там же копи-паст не работает!
Всегда и всё записываю, уже почти двадцать лет (без фанатизма, но тем не менее — ключевые моменты — когда что зарелизилось, митинги, идеи, и т.д.). Много раз помогало, а иногда и спасало. За это время выработал нехитрую систему меток и оглавлений, так что минимальный поиск по записям работает. Хороший блокнот и приличная авторучка — что может быть лучше?
Для железа — да, возможно, что-то делается просто потому что это эффективнее всего.
С программированием все куда интереснее. Если ваш код при прочтении вызывает вопросы — это либо плохой код, либо грязные хаки (то есть борьба с плохим кодом другого программиста / железом). Первое надо исправлять, второе — документировать.
Если программист начинает делать журнал записей, чтобы не забыть, почему он делает то или иное (не документацию к внешним интерфейсам, а именно журнал того, как он делает) — он делает что-то не так.
Вот вам дзен питона про это:
С программированием все куда интереснее. Если ваш код при прочтении вызывает вопросы — это либо плохой код, либо грязные хаки (то есть борьба с плохим кодом другого программиста / железом). Первое надо исправлять, второе — документировать.
Если программист начинает делать журнал записей, чтобы не забыть, почему он делает то или иное (не документацию к внешним интерфейсам, а именно журнал того, как он делает) — он делает что-то не так.
Вот вам дзен питона про это:
Явное лучше, чем неявное.
Простое лучше, чем сложное.
…
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
…
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Если программист начинает делать журнал записей, чтобы не забыть, почему он делает то или иное (не документацию к внешним интерфейсам, а именно журнал того, как он делает) — он делает что-то не так.
Вообще-то системы контроля версий и тикетов (например, jira и git) это и есть этот самый журнал, если они используются правильно. По идее, должны быть задокументированы все изменения сделанные в команде, иначе потом концов не найдешь.
P.S. Что насчет перевода, какой-то он странный, как будто гуглом переводчиком перевели, а потом самые крупные косяки поправили и выложили.
Тут шире вопрос стоит. В оригинале есть видео объясняющее.
Возможно у задачи существовало 5 совершенно разных решений, вы выбрали одно из них, в журнале описать почему. Либо в проекте использовали какую-либо библиотеку, чем обосновывался выбор и почему не подошли другие.
Сомневаюсь что в документации и самом коде это будет.
Ну или два дня потратили на выбор фотоаппарата, сравнивая характеристики и отзывы. Тоже можно кратко описать суть. Чтобы через год не пришлось заново мучительно вспоминать почему был сделан то или иной выбор.
Возможно у задачи существовало 5 совершенно разных решений, вы выбрали одно из них, в журнале описать почему. Либо в проекте использовали какую-либо библиотеку, чем обосновывался выбор и почему не подошли другие.
Сомневаюсь что в документации и самом коде это будет.
Ну или два дня потратили на выбор фотоаппарата, сравнивая характеристики и отзывы. Тоже можно кратко описать суть. Чтобы через год не пришлось заново мучительно вспоминать почему был сделан то или иной выбор.
Когда я работал инженером дата-центра, у нас был самописный сайт с БД, который так и назывался «Дневник». Ничего особо — просто поле ввода и кнопка отправить, при нажатии на которую автоматически к сообщению добавлялось имя отправителя и дата. Естественно был реализован поиск. Записывали все: когда какой клиент приходил, почему сервер не подключили, когда была аномалия в трафике, куда положили жесткие диски, когда обслуживали кондиционер и тд. Это нас выручало не раз. Когда перешел в другую компанию, подобного решения очень не хватало
Отчасти испытываю такие же чувства, как автор оригинальной статьи. Дело испортили квадратные бумажки, на которых записывается что-то ценное перед походом, например, в серверную. Потом информация вносится в заявку/запрос на изменение (в лучшем случае), а бумажка выбрасывается. Когда вместо бумажек был блокнот, было как-то удобнее. Особый интерес вызывали записи трехлетней данности — «ух ты, так вот куда мы его подкючили!». :)
«Почему я в конечном итоге поставил это конкретный номинал и тип конденсатора?»
В последнее время я, чтобы избежать подобных проблем, использую систему контроля версий. В которой отлично хранятся не только файлы программы, но и бинарные файлы схем и трассировки. После каждого более-менее серьёзного изменения делаю апдейт и сопровождаю его комментариями. В результате можно с лёгкостью не только вспомнить что и зачем ты сделал, но и когда сделал. А главное вернуться назад в любой момент при необходимости в случае если попал в тупиковую ветку.
Это намного удобнее и никакой макулатуры!
Кстати, слышал аналогичную историю от авторов исследовательского проекта. Они писали его вместе и обновляли на github.
Теперь подумываю и сам попробовать :)
Теперь подумываю и сам попробовать :)
Очень полезно, особенно когда работаешь над проектом командой. Не раз были неприятности когда вдруг в последний момент в библиотеку попадал непостижимым образом компонент с неправильным паттерном, а в результате приходилось колдовать над платой с паяльником и скальпелем. После того, как начал использовать TortoiseHg всё это в прошлом. Сегодня слава богу популярные системы версий обзавелись графическими оболочками и стали доступны для понимания даже домохозяйкам, после некоторого интенсива конечно.
(Найдите оригинал, прочтите, предложите лучшее название, близкое оригиналу, потом будете минусовать — пп).
Хорошим тоном в случае публикации перевода, является размещение ссылки на оригинал, а не отсылка читателей в неизвестном направлении. Чтобы тебя уважали, следует уважать своих читателей, даже если критикуешь их.
В хабаре всегда в переводах есть ссылка на оригинал между оценкой статьи и именем автора, вот такого вида: «Clive Maxfield».
P.S. Открыл оригинал, нажал перевести в гугл. транслейте и получил этот текст с минимальными изменениями со всеми нелепицами в переводе на русский вроде: судового журнала, я повесил голову от стыда и т.п. Неужели это так тяжело переписать полстраницы текста нормальным русским разговорным языком?
P.S. Открыл оригинал, нажал перевести в гугл. транслейте и получил этот текст с минимальными изменениями со всеми нелепицами в переводе на русский вроде: судового журнала, я повесил голову от стыда и т.п. Неужели это так тяжело переписать полстраницы текста нормальным русским разговорным языком?
Спасибо за перевод и как раз очень кстати. я начал вести свой журнал (или дневник — как хотите, так и называйте) после того, как начал работу за границей. Мне тогда мой шеф принёс такой журнал и рассказал о том, что на основе этих записей можно отстаивать своё авторство идеи в суде (позже я прочитал, что Чарльз Таунс так же записал себе в журнал и свою идею по созданию мазера, возможно ему в суде и пригодилось).
С тех пор у меня всё важное записано. Скопилось уже 6 или 7 таких журналов, перевозить сложно, а выбросить нельзя. Вот вчера писал отчёт и пытался вспомнить номер оптического волокна (в каталоге производителя) для которого я делал расчёты год назад. Журнал и помог, так как в нем было всё. Попутно нашел формулу и ссылку на источник, которые обещал найти для другого человека несколько дней назад.
Так что всем инженерам, исследователям и учёным советую пользоваться таким журналом.
Нужно еще сказать, что есть электронная версия в виде файла на компьютере. Но она дополняется медленно. Не знаю почему она не так привлекательна для меня как простой бумажный вариант.
С тех пор у меня всё важное записано. Скопилось уже 6 или 7 таких журналов, перевозить сложно, а выбросить нельзя. Вот вчера писал отчёт и пытался вспомнить номер оптического волокна (в каталоге производителя) для которого я делал расчёты год назад. Журнал и помог, так как в нем было всё. Попутно нашел формулу и ссылку на источник, которые обещал найти для другого человека несколько дней назад.
Так что всем инженерам, исследователям и учёным советую пользоваться таким журналом.
Нужно еще сказать, что есть электронная версия в виде файла на компьютере. Но она дополняется медленно. Не знаю почему она не так привлекательна для меня как простой бумажный вариант.
Какой аналог бумажному журналу можно использовать в электронном мире? Evernote?
Расшаренный на всю команду Гугл док, например?
Я долгое время пользовался OneNote. Но в конце концов пришел к тому с чего и начал — просто файловая система. Никаких ограничений на структуру и форматы.
Уже два года использую Microsoft Office OneNote. Очень удобно разбивать проекты по вкладкам и страницам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Инженер, который пренебрегает записями, неосторожен