"Миф о документации": gaperton.livejournal.com
Интересную мысль прочитал по ссылке ниже. Чтобы было ясно, о чём идёт речь, скажу название статьи: "Управление данными. Записки начинающего."
Прочитал, и подумал: "Юнит-тесты!!!" =))
То есть, не обязательно только именно юнит-тесты, это касается вообще связи исходников программ и покрытия их тестами. Если исходный код растёт значительно быстрее, чем покрытие его тестами, то это приводит к отрыву кода (и логики его работы) от тестов, которыми он мог бы проверяться. А код без возможности проверки на регрессию, как известно, демотивирует вносить в него изменения (развивать), и постепенно приходит в застой.
Такая же связь между скоростью роста кода и документации по нему. Большинство программистов не любит писать доки, но без описания хотя бы интерфейса и принципа работы им приходится помногу раз отвечать на одни и те же вопросы новым, а порой одним и тем же, коллегам.
Известна транспортная теорема, формулировку которой я впервые увидел у Переслегина, хотя я не думаю, что авторство принадлежит ему. Звучит оно примерно так: «Товарооборот между колонией и метрополией должен возрастать быстрее, чем благосостояние колонии. Иначе в ней возникнут и начнут укрепляться сепаратистские настроения. Появится значительно число людей, которые будут искренне считать, что жить отдельно от метрополии им будет выгоднее».chibrikin.livejournal.com
В области информации можно сформулировать полный аналог: «Объем обмена данными между общекорпоративной и локальными информационными системами отдельных служб и пользователей должен быть хотя бы сопоставим с объемом данных, накапливаемых в локальных системах. Иначе информационное пространство внутри компании начнет распадаться на плохо связанные между собой кластеры».
Прочитал, и подумал: "Юнит-тесты!!!" =))
То есть, не обязательно только именно юнит-тесты, это касается вообще связи исходников программ и покрытия их тестами. Если исходный код растёт значительно быстрее, чем покрытие его тестами, то это приводит к отрыву кода (и логики его работы) от тестов, которыми он мог бы проверяться. А код без возможности проверки на регрессию, как известно, демотивирует вносить в него изменения (развивать), и постепенно приходит в застой.
Такая же связь между скоростью роста кода и документации по нему. Большинство программистов не любит писать доки, но без описания хотя бы интерфейса и принципа работы им приходится помногу раз отвечать на одни и те же вопросы новым, а порой одним и тем же, коллегам.
Как вы относитесь к разработке на С++ в стиле Си? Это когда система слабо объектно ориентирована, классы имеют вид структур с функциями, а шаблоны используются наравне с макросами как дополнительная возможность хака. И конечно, boost :)
Хотя то, о чем я сказал, к Си слабо относится :) Но не знаю, что может быть ближе.
Хотя то, о чем я сказал, к Си слабо относится :) Но не знаю, что может быть ближе.
По мотивам The C10K problem первый раз увидел статью "Why Events Are A Bad Idea (for High-concurrency Servers)". usenix.org
Странно, почему-то в интернете мне больше попадались статьия о переходе от стратегии "По потоку на каждого клиента" к стратегии "Использования неблокирующих сокетов", например, epoll. Наверное, лучший выбор стратегии для разных серверов будет свой.
Сколько всего я ещё не знаю :)
Странно, почему-то в интернете мне больше попадались статьия о переходе от стратегии "По потоку на каждого клиента" к стратегии "Использования неблокирующих сокетов", например, epoll. Наверное, лучший выбор стратегии для разных серверов будет свой.
Сколько всего я ещё не знаю :)