Документация должна ограничиваться описанием методов, параметров, эксшепшенов и т.п. Т.е. документация для автокомплита ИДЕ
Это один из тезисов, который я несу на протяжении всей статьи.
Проблема заключается в том, что всё очень индивидуально. Что одному очевидно, другому не понятно
Я согласен. Но ведь команда на то и команда — в ней должно быть как можно больше понимания и взаимодействия внутри. Нужно писать документацию так, чтобы понятно было всем. Для этого нужны обсуждения с коллегами (о чем я упомянул).
Всё встало на свои места, когда я его код увидел, он был усыпан документацией и выглядел так
В вашем примере я не вижу ни капли документации. Я вижу одни комментарии, которые создают шум (об этом я кстати тоже упомянул).
Что значит даже? Любая документация несет за собой ответственность за ее поддержку, это очевидно. Независимо от того, в коде это документация, или вне.
«не все можно запихнуть в текст»
Пишите свой код так, чтобы текст комментариев не пришлось никуда «запихивать». Большую часть информации о коде должен предоставлять сам код.
90% документации реально никогда никому не нужно
От куда такая цифра? Проводились какие-то иследования?
Когда я занимался написанием сервера, я не знал ни о пуле потоков, ни о конечном автомате, поэтому искал скорее «не так» а не «не там». За ссылки спасибо, буду смотреть)
Причина — учебный проект)
Статья написана не написана на широкую публику и не показывает что-то новое. Статья скорее для тех кто так же, как и я в свое время, искал способы написания многопоточки в сервере.
MVCC-5. Внутристраничная очистка и HOT
Благодарю и возьму на заметку!
MVCC-5. Внутристраничная очистка и HOT
Ответ описан в первых пару абзацах продолжения)
MVCC-5. Внутристраничная очистка и HOT
Егор, спасибо вам большое за ваш титанический труд!
У меня вопрос по очистке версий строк:
А что будет с этими указателями? Они остаются в странице навсегда? Или в конечном итоге они тоже будут удалены? Если да, то каким образом? Спасибо
Две культуры программирования: почему обе из них важны?
По моему опечатка?
Документирование кодовой базы. Зачем и как?
Документирование кодовой базы. Зачем и как?
Это один из тезисов, который я несу на протяжении всей статьи.
Я согласен. Но ведь команда на то и команда — в ней должно быть как можно больше понимания и взаимодействия внутри. Нужно писать документацию так, чтобы понятно было всем. Для этого нужны обсуждения с коллегами (о чем я упомянул).
В вашем примере я не вижу ни капли документации. Я вижу одни комментарии, которые создают шум (об этом я кстати тоже упомянул).
Документирование кодовой базы. Зачем и как?
Что значит даже? Любая документация несет за собой ответственность за ее поддержку, это очевидно. Независимо от того, в коде это документация, или вне.
Пишите свой код так, чтобы текст комментариев не пришлось никуда «запихивать». Большую часть информации о коде должен предоставлять сам код.
От куда такая цифра? Проводились какие-то иследования?
Многопоточный HTTP-сервер с ThreadPool’ом и конечным автоматом
Многопоточный HTTP-сервер с ThreadPool’ом и конечным автоматом
Статья написана не написана на широкую публику и не показывает что-то новое. Статья скорее для тех кто так же, как и я в свое время, искал способы написания многопоточки в сервере.