Заполнение списка без очистки может привести к утечкам памяти. Пока не стрельнет сложно обнаружить, где именно могут быть утечки.
Глобальное изменяемое состояние трудно отслеживать. Как правило, точек доступа к глобальным данным много или очень много, и чтобы отследить все сценарии и ничего не забыть, нужно много усилий. Иногда даже слишком много для человека.
Да, и глобальные Singleton'ы трудно тестировать, т.к. его состояние необходимо приводить к исходному для каждого теста, а это не всегда просто (если вообще возможно).
Знаете, уровень необходимых знаний зависит от точки приложения.
И если это простенький сервер с низкой нагрузкой, то даже откровенные тормоза и N + 1 запрос могут быть приемлемыми для заказчика. Так что оценивать уровень разработчика по количеству и работе его проектов в боевых условиях не есть адекватно, хотя может быть показательно. Это как тестирование — оно способно выявить некоторые ошибки, но не гарантировать, что их нет.
А насчет уровня знаний и умений разработчика…
Есть очень много аспектов. Есть знания языка: синтаксис, семантика, порядок вызовов, приоритеты и т.д… Есть знания платформы: устройство памяти, синхронизация потоков, JIT и т.д.
Есть знания framework'ов: открытая документация, знание архитектуры, умение применять в типичных и нетипичных местах, знать подводные камни и известные грабли.
Есть еще знания принципов ООП, функционального программирования, умения строить дизайн, разруливать зависимости, видеть потенциальные проблемы, возможные ошибки новичков, уметь написать так, чтобы ошибки становились очевидными, падали сразу и т.д.
Также еще есть знания среды разработки и исполнения: что где настроить, как подружиться с IDE, как эффективно писать код, всякие там генераторы и т.д.
А теперь, внимание, вопрос: как при таком множестве факторов проверить, является ли кандидат адекватным разработчиков для вашего проекта, или не является?
И второй, встречный вопрос: в какую сторону развиваться человеку, чтобы стать адекватным разработчиком вне зависимости от проекта, в который он попадет?
Вот на пересечении этих интересов и есть истина.
И из личного опыта: чем больше кандидат разбирается в деталях языка и платформы, тем более хороший и качественный код он пишет. Чем шире кругозор — тем проще ему будет вникнуть в незнакомые аспекты, и тем меньше ошибок он допустит. И, за исключением особых случаев, широта лучше глубины. IMHO.
:-)
Как правило этот путь проходит любая система с более-менее налаженным сопровождением.
Потому что предугадать вопросы клиентов часто представляется невозмжоным, а одиночные ответы иногда и нет смысла описывать — проще объяснять.
А вот когда объясняешь уже в третий раз — повод задуматься над автоматизацией процесса.
В этом случае документация уже не спасет. :-)
Хотя, возможно, спасение есть в модульных тестах и рефакторинге.
При условии, что код рабочий.
Если же код не рабочий — выкинуть и переписать заново.
Так говорил Мартин Фаулер, и я с ним полностью согласен.
Как именовать переменные обычно сразу видно из кода, разве не так? :-) А форматирование — современные IDE давно уже научились импорту/экспорту настроек.
Плюс-плюс-плюс!
Но прошу заметить, что обычно проблемы всегда с фиксацией требований, внешних API и требований к окружению.
Поэтому их нужно документировать.
А вот внутренний дизайн проекта, подходы, стандарты кодирования и т.д. — для этого не нужны документы.
Либо за этим следит сама команда разработчиков, либо создает автоматизированные средства контроля, если в этом есть необходимость. И нет никакой необходимости это документировать — обучение путем работы в паре намного эффективнее. При этом код пишет новичок, а матерый программист просто объясняет, что делать, и отвечает на вопросы.
Как-то так.
Если кто не согласен — готов обсудить. Только аргументированно, пожалуйста — холивары ни к чему хорошему не приводят.
:-)
Я лично придерживаюсь концепции «договоров». Я пишу документ с подробным описанием функционала, который мне необходимо реализовать, с учетом взаимосвязей с остальной системой.
После этого отдаю этот документ человеку, который согласовывает и подписывается под ним (комментарием в wiki с указанием версии документа, под которой он подписался). Это позволяет разграничить ответственность между разработчиком (мной) и бизнесом, ставящим задачу и отвечающим на вопрос «как это должно работать с точки зрения пользователя/внешней системы?».
А когда есть четкая граница ответственности, человек более внимательно относится к тому, что в его зоне, и не оставляет на самотек.
Это не решает проблему синхронизации документации, но позволяет иметь актуальную на какой-то момент доку. А дальше, отталкиваясь от нее, с кодом в голове и VCS в руках можно достроить. А если много достраивать — самому же проще поправить доку и пересогласовать. В итоге схема становится самодостаточной.
И при этом она не требует участия всех. Даже если кто-то упорно не хочет писать документацию — она все равно появляется, потому что другим так проще жить.
Очень красивый и емкий язык, для работы с которым нужно перевернуть мышление.
:-)
Вот закончу разбираться с 3D-графикой, и перейду на темную сторону силы — практиковаться в Lisp или Closure.
Я где-то видел примеры статически конфигурируемых связей listener'ов на этапе компиляции.
Вот это было круто — все само связывается, и на этапе компиляции проверяет, что все связи действительно есть.
:-)
Жаль, не могу указать источник.
И если это простенький сервер с низкой нагрузкой, то даже откровенные тормоза и N + 1 запрос могут быть приемлемыми для заказчика. Так что оценивать уровень разработчика по количеству и работе его проектов в боевых условиях не есть адекватно, хотя может быть показательно. Это как тестирование — оно способно выявить некоторые ошибки, но не гарантировать, что их нет.
А насчет уровня знаний и умений разработчика…
Есть очень много аспектов. Есть знания языка: синтаксис, семантика, порядок вызовов, приоритеты и т.д… Есть знания платформы: устройство памяти, синхронизация потоков, JIT и т.д.
Есть знания framework'ов: открытая документация, знание архитектуры, умение применять в типичных и нетипичных местах, знать подводные камни и известные грабли.
Есть еще знания принципов ООП, функционального программирования, умения строить дизайн, разруливать зависимости, видеть потенциальные проблемы, возможные ошибки новичков, уметь написать так, чтобы ошибки становились очевидными, падали сразу и т.д.
Также еще есть знания среды разработки и исполнения: что где настроить, как подружиться с IDE, как эффективно писать код, всякие там генераторы и т.д.
А теперь, внимание, вопрос: как при таком множестве факторов проверить, является ли кандидат адекватным разработчиков для вашего проекта, или не является?
И второй, встречный вопрос: в какую сторону развиваться человеку, чтобы стать адекватным разработчиком вне зависимости от проекта, в который он попадет?
Вот на пересечении этих интересов и есть истина.
И из личного опыта: чем больше кандидат разбирается в деталях языка и платформы, тем более хороший и качественный код он пишет. Чем шире кругозор — тем проще ему будет вникнуть в незнакомые аспекты, и тем меньше ошибок он допустит. И, за исключением особых случаев, широта лучше глубины. IMHO.
:-)
:-)
Потому что предугадать вопросы клиентов часто представляется невозмжоным, а одиночные ответы иногда и нет смысла описывать — проще объяснять.
А вот когда объясняешь уже в третий раз — повод задуматься над автоматизацией процесса.
Хотя, возможно, спасение есть в модульных тестах и рефакторинге.
При условии, что код рабочий.
Если же код не рабочий — выкинуть и переписать заново.
Так говорил Мартин Фаулер, и я с ним полностью согласен.
Но прошу заметить, что обычно проблемы всегда с фиксацией требований, внешних API и требований к окружению.
Поэтому их нужно документировать.
А вот внутренний дизайн проекта, подходы, стандарты кодирования и т.д. — для этого не нужны документы.
Либо за этим следит сама команда разработчиков, либо создает автоматизированные средства контроля, если в этом есть необходимость. И нет никакой необходимости это документировать — обучение путем работы в паре намного эффективнее. При этом код пишет новичок, а матерый программист просто объясняет, что делать, и отвечает на вопросы.
Как-то так.
Если кто не согласен — готов обсудить. Только аргументированно, пожалуйста — холивары ни к чему хорошему не приводят.
:-)
После этого отдаю этот документ человеку, который согласовывает и подписывается под ним (комментарием в wiki с указанием версии документа, под которой он подписался). Это позволяет разграничить ответственность между разработчиком (мной) и бизнесом, ставящим задачу и отвечающим на вопрос «как это должно работать с точки зрения пользователя/внешней системы?».
А когда есть четкая граница ответственности, человек более внимательно относится к тому, что в его зоне, и не оставляет на самотек.
Это не решает проблему синхронизации документации, но позволяет иметь актуальную на какой-то момент доку. А дальше, отталкиваясь от нее, с кодом в голове и VCS в руках можно достроить. А если много достраивать — самому же проще поправить доку и пересогласовать. В итоге схема становится самодостаточной.
И при этом она не требует участия всех. Даже если кто-то упорно не хочет писать документацию — она все равно появляется, потому что другим так проще жить.
:-)
:-)
Вот закончу разбираться с 3D-графикой, и перейду на темную сторону силы — практиковаться в Lisp или Closure.
Напишите компилятор C++ на шаблонах C++. :-)
Вот это было круто — все само связывается, и на этапе компиляции проверяет, что все связи действительно есть.
:-)
Жаль, не могу указать источник.
IMHO, очень полезный признак для определения качества кода.