Здравствуйте, Advanced_User, Вы писали:
A_U>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п. Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
Вот так и разбираешься в чужом коде. Причем с годами приходит тонкое исскуство разбираться только в том чужом коде, что нужно, и ни строкой больше.
Здравствуйте, Advanced_User, Вы писали:
A_U>Здравствуйте, bkat, Вы писали:
B>>Всевозможные "тулзы" для удобной навигации в коде B>>в этом конечно же сильно помогают.
A_U>Можно поподробнее о "тулзах", пожалуйста ?
Хорошая "тулза" должна уметь строить диаграмы классов
и поддерживать регулярные выражения для поиска чего-либо в коде.
SNiFF очень неплох для навигации и поиску по коду.
Он позволяет настроить себя так, что ты из всей массы
файлов будешь видеть только то, что нужно тебе.
Здравствуйте, Advanced_User, Вы писали:
A_U>Мои познания на сегодня: ("частично" — значит не до конца ещё осилил ) A_U>Assembler — с деЦтва A_U>Pascal — успешно забыт A_U>C — Керниган и Ричи A_U>С++ — Дейтелы, частично — Страуструп A_U>Win32 — Петзольд A_U>Advanced Win32 — частично Рихтер. A_U>MFC — частично Круглинский A_U>OOD — частично Буч
A_U>плюс ко всему — физический факультет
A_U>Какие будут ваши рекомендации ?
Здравствуйте, Advanced_User, Вы писали:
A_U>Какие будут ваши рекомендации ?
Есть неплохой метод. Допустим надо разобраться в чужом страшном коде.
Попробуй спроектировать систему сам. Процесс итеративен. При попытке это сделать, ты будешь регулярно выяснять:
1) что у тебя не хватает знаний о том, что должна делать программа, и ты не можешь ее дальше проектировать . Что важно, при попытке дизайнить ты выяснишь конкретно, каких знаний тебе не хватает, и сможешь ликвидировать их недостаток. Пополни свои знания, и повтори попытку.
2) что налицо техническая проблема, которая может быть решена рядом способов. Отлично! Теперь ты будешь не просто глазеть на код, а изучать его на предмет выяснения, какой из вариантов выбрали разработчики. А это уже задача попроще — ты примерно знаешь, что ты должен увидеть. Смотрим в код, качаем головой, говорим "однако!", продолжаем дизайнить.
3) Что тебе это в общих чертах удалось. Здорово. Открывай код. Смотри. Если ты не узнаешь в нем ничего из своего дизайна, это будет конечно проблема. Но это крайне маловероятно. В любом случае, ты будешь уже знаком с проблематикой, и ты будешь способен отличить главное от второстепенного. А это самое важное.
Итак, что в этом деле самое важное? Нет, не знать на что смотреть. Гораздо важнее знать, на что смотреть не надо. Кода много. Весь не прочитаешь — получишь взыв мозга. Читать надо немного кода, и избирательно, проверяя свои гипотезы о дизайне софтины. Правило просто — ни в коем случае не пялится на код просто так, а искать в нем ответы на конкретно поставленные вопросы по дизайну. Постигнешь это ДАО, будет тебе щастье.
Здравствуйте, George Seryakov, Вы писали:
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п. Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
GS>Вот так и разбираешься в чужом коде. Причем с годами приходит тонкое исскуство разбираться только в том чужом коде, что нужно, и ни строкой больше.
Совершенно точно подмечено! Меня мой проект уже забодал, порой возникает такое чувство, что остальные разработчики, с которыми общаюсь по аське, просто ничего не понимают в программировании, проектирования нет никакого, код мутнее мутного... Тешу себя мыслей, что хоть мой код привносит немного света в беспроглядную тьму...
Однажды я заикнулся, что надо все переписать, был послан куда подальше в вежливой форме. Однажды спросил робко про CodeRules, встретил полное непонимание... При этом проект успешно продается и все такое.
Пример из практики — этими разработчиками была написана своя версия функции регистрации COM-сервера, просто потому, что они не знали, что есть стандартная.
Здравствуйте, George Seryakov, Вы писали:
GS>Здравствуйте, Advanced_User, Вы писали:
A_U>>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п. Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
GS>Вот так и разбираешься в чужом коде. Причем с годами приходит тонкое исскуство разбираться только в том чужом коде, что нужно, и ни строкой больше.
Как это близко!!!
Могу еще добавить, что, как правило, код без комментов или с такими, что лучше бы их и не было :D).
Здравствуйте, Demiurg, Вы писали:
D>... Тешу себя мыслей, что хоть мой код привносит немного света в беспроглядную тьму...
А твой код еще не переписывали? Типа — сделал все чистенько: классы, смартпойнтеры, QWAN. А потом заходишь в архив и видишь правку — кто-то убрал смартпойнтеры, понапихал глобальных переменных, испортил логику и т.п. И все просто потому, что не понимал, что написано.
Здравствуйте, Advanced_User, Вы писали:
A_U>Но КАК можно в ЭТОМ всём разобраться, ведь там же ТОЛЬКО исходники
Задача сама по себе довольно сложная и не только для малоопытных специалистов... Сплошь и рядом встреяается необходимость разбираться в чужом коде, причём чаще в коммерческом, чем в открытом. В открытом коде ты может быть захочешь покопаться для себя, для самообразования, а в коммерческом приходится разбираться по долгу службы. Причём код не просто стар, а написан неизвестно по какой спецификации, разными людьми и с ошибками
Короче, это всё лирика, вот какой рецепт понимания чужого кода я для себя с годами выработал, теперь и другим рекомендую:
Научится компилить этот код. Без этого никуда.
Научится дебагать этот код. Т.е. настроить дебаггер и научится этим старьём пользоваться, потому как если кто думает, что всё на свете написано на VS, то он... ошибается.
Экспериментировать. Т.е. что-то менять, компилить, смотреть что получится, если получилось не то, что хотел — дебагать.
Зациклившись на третьем пункте, ты будешь со временем всё лучше и лучше знать нужный тебе код или — что важно — необходимую тебе его часть.
Скажу сразу, что программист я не очень опытный ещё Поэтому часть из моих размышлений о работе в составе команды носит чисто теоретический характер
Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
Мне, как начинающему, интересно разобраться с популярными open-source проектами, такими как, например, eMule, Miranda или, скажем Quake
Но КАК можно в ЭТОМ всём разобраться, ведь там же ТОЛЬКО исходники
Мои познания на сегодня: ("частично" — значит не до конца ещё осилил )
Assembler — с деЦтва
Pascal — успешно забыт
C — Керниган и Ричи
С++ — Дейтелы, частично — Страуструп
Win32 — Петзольд
Advanced Win32 — частично Рихтер.
MFC — частично Круглинский
OOD — частично Буч
Нет ничего страшного, осилишь все сам, было бы желание.
Чужой код (Open source) интересен сам по себе, по нему просто учится можно и получать удовольствие и он снимает зашореннось, которую вдалбливают в процессе учебы
Для начала неплохо бы узнать, а что вообще делает код
с точки зрения пользователя. Когда знаешь, для сего все это сделано,
то намного легче понять как это сделано.
Потом можно придумать какую-нибудь тестовую задачку.
Придумай, что можно полезного добавить или что-то изменить.
Можно попробовать реализовать какую-нибудь фичу повторно.
Не страшно, если это будет просто повторение того, что уже сделано
не тобой. Как минимум ты поймешь "дух" и идеи дизайна
В общем случае нужно иметь какую-нибудь цель и знать, для чего тебе вообще это нужно.
Изучать код просто ради интереса, я лично просто не могу.
Всевозможные "тулзы" для удобной навигации в коде
в этом конечно же сильно помогают.
Здравствуйте, George Seryakov, Вы писали:
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует.
Поэтому желательно нормально комментировать свои проги для того, чтобы тот, кто придет после тебя не ругал тебя последними словами. И вообще писать прогу нужно так, чтобы ее код был читабельным не только для тебя.
Я на своей шкуре сталкивался как с читабельными прогами , так и с полной мутью .
А недавно столкнулся с прогой, которая вроде бы написана красиво (осмысленные всех имен классов, темплейтов и переменных, комментарии и т.д.), но логика работы была настолько запутаной , что я просто переписал все с нуля .
Здравствуйте, Advanced_User, Вы писали:
A_U>Какие будут ваши рекомендации ?
Мои рецепт:
разобрался с переменной/функцией -добавь свой комментарий/переименуй
Так постепенно разберёшся со всем..
кроме того помогает разбиение на более мелкие части и выделение потворноуоптребляющихся частей в модули
Здравствуйте, George Seryakov, Вы писали:
GS>Здравствуйте, Demiurg, Вы писали:
D>>... Тешу себя мыслей, что хоть мой код привносит немного света в беспроглядную тьму...
GS> А твой код еще не переписывали? Типа — сделал все чистенько: классы, смартпойнтеры, QWAN.
В Дельфе нет шаблонов, так что обходимся без смартпойнтеров Как же я ее ненавижу... крик души...
GS> А потом заходишь в архив и видишь правку — кто-то убрал смартпойнтеры, понапихал глобальных переменных, испортил логику и т.п. И все просто потому, что не понимал, что написано.
Со мной, слава б-гу, такого не было (только зачастую мой код к своему страшному стилю приводят), а вот с коллегой как-то ужас такой произошел... Именно из-за непонимания кода, все убрали, по-своему написали (неправильно), пришлось с нуля все переписывать, месяц загублен...
Здравствуйте, Demiurg, Вы писали:
GS>> А твой код еще не переписывали? Типа — сделал все чистенько: классы, смартпойнтеры, QWAN.
D> В Дельфе нет шаблонов, так что обходимся без смартпойнтеров Как же я ее ненавижу... крик души...
Смартпоинтеров там нет не из-за отсутствия шаблонов, а из-за отсутствия автоматических деструкторов.
Здравствуйте, AndrewVK, Вы писали:
D>> В Дельфе нет шаблонов, так что обходимся без смартпойнтеров Как же я ее ненавижу... крик души...
AVK>Смартпоинтеров там нет не из-за отсутствия шаблонов, а из-за отсутствия автоматических деструкторов.
А их там и не может быть, так как исключительно ссылочная модель. Предположим, что они там есть, как реализовать смартпойнтер без шаблонов? Не представляю
Здравствуйте, Demiurg, Вы писали:
D> А их там и не может быть, так как исключительно ссылочная модель. Предположим, что они там есть, как реализовать смартпойнтер без шаблонов? Не представляю
А в чем проблема то? В том что одним единственным смартпоинтером для всех типов не обойтись?
Здравствуйте, AndrewVK, Вы писали:
D>> А их там и не может быть, так как исключительно ссылочная модель. Предположим, что они там есть, как реализовать смартпойнтер без шаблонов? Не представляю
AVK>А в чем проблема то? В том что одним единственным смартпоинтером для всех типов не обойтись?
Именно. Тогда придется писать кучу смартпойнтеров для каждого типа, или извращаться. Лучше тогда вообще их не писать... Для меня указатель это просто указатель на что-то, независимо от типа, а в дельфе эта парадигма уже не соблюдается... Вообще, отсутствие шаблонов — большой сакс... Помню, писал я функцию, в которую объекты разных классов должны передаваться, но обработка для них одна. Такую гадость написал для анализа их типов... Все равно неуниверсально вышло, как ты понимаешь.
Здравствуйте, Demiurg, Вы писали:
D> Именно. Тогда придется писать кучу смартпойнтеров для каждого типа, или извращаться.
Ну зачем так жестоко? Можно создать базовый класс и написать для него смартпоинтер, а потом все управляемые классы наследовать от него.
D>Лучше тогда вообще их не писать...
Ну это уже другой вопрос. Главное что смартпоинтеры отсутствуют прежде всего из-за отсутствия автоматичиеских деструкторов.
Здравствуйте, AndrewVK, Вы писали:
D>> Именно. Тогда придется писать кучу смартпойнтеров для каждого типа, или извращаться.
AVK>Ну зачем так жестоко? Можно создать базовый класс и написать для него смартпоинтер, а потом все управляемые классы наследовать от него.
Не всегда это возможно, к сожалению... А так да.
D>>Лучше тогда вообще их не писать...
AVK>Ну это уже другой вопрос. Главное что смартпоинтеры отсутствуют прежде всего из-за отсутствия автоматичиеских деструкторов.
Здравствуйте, Demiurg, Вы писали:
AVK>>Ну зачем так жестоко? Можно создать базовый класс и написать для него смартпоинтер, а потом все управляемые классы наследовать от него.
D> Не всегда это возможно, к сожалению... А так да.
Ну так народ тут уверял что в Дельфи интерфейсы есть. Вот как раз в данном случае самое оно.
Здравствуйте, AndrewVK, Вы писали:
D>> Не всегда это возможно, к сожалению... А так да.
AVK>Ну так народ тут уверял что в Дельфи интерфейсы есть. Вот как раз в данном случае самое оно.
Интерфейсы есть. Дело не в том, что я не могу сам свои классы унаследовать от одного базового или интерфейса, а в том, что есть уже (допустим) огромная куча чужих классов, и хотелось бы с ними работать через смартпойнтеры. При написании своей программы с нуля эта проблема снимается.
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, George Seryakov, Вы писали:
GS>>Здравствуйте, Demiurg, Вы писали:
D>>>... Тешу себя мыслей, что хоть мой код привносит немного света в беспроглядную тьму...
GS>> А твой код еще не переписывали? Типа — сделал все чистенько: классы, смартпойнтеры, QWAN.
D> В Дельфе нет шаблонов, так что обходимся без смартпойнтеров Как же я ее ненавижу... крик души...
GS>> А потом заходишь в архив и видишь правку — кто-то убрал смартпойнтеры, понапихал глобальных переменных, испортил логику и т.п. И все просто потому, что не понимал, что написано.
D> Со мной, слава б-гу, такого не было (только зачастую мой код к своему страшному стилю приводят), а вот с коллегой как-то ужас такой произошел... Именно из-за непонимания кода, все убрали, по-своему написали (неправильно), пришлось с нуля все переписывать, месяц загублен...
как же так? в проекте нет контроля версии?! Нонсенс.
GS> и мантру русского программиста — "Все это надо переписать"
Да, кто-то из Великих утверждал, что переписывание чужого кода есть явный признак immature программера. По мне так быстро разбираться в чужом коде не более, чем дело привычки. Надо просто набить руку.
Здравствуйте, George Seryakov, Вы писали:
GS>Здравствуйте, Advanced_User, Вы писали:
A_U>>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п. Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
GS>Вот так и разбираешься в чужом коде. Причем с годами приходит тонкое исскуство разбираться только в том чужом коде, что нужно, и ни строкой больше.
Интересно, а как Microsoft разработчики в Windows исходниках разбираются
GS> А твой код еще не переписывали? Типа — сделал все чистенько: классы, смартпойнтеры, QWAN. А потом заходишь в архив и видишь правку — кто-то убрал смартпойнтеры, понапихал глобальных переменных, испортил логику и т.п. И все просто потому, что не понимал, что написано.
Чтобы такого не било, надо поддерживать свои классы самому и не кому не довать
делать в них изменения. А если находится ошибка или надо чего нибудь
изменит, то не делать это самому, а поручать это дело самому разработчику класса.
Время — денги, потому нету смысла тратить время на понимание чужих исходников.
ИМХО самое главное надо знать API
Здравствуйте, George Seryakov, Вы писали:
GS>Здравствуйте, Advanced_User, Вы писали:
A_U>>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п.
GS>Да, и мантру русского программиста — [b]"Все это надо переписать" — разрешается произносить только про себя.[/b]
Я произносил вслух -- жив остался.
GS>Вот так и разбираешься в чужом коде. Причем с годами приходит тонкое исскуство разбираться только в том чужом коде, что нужно, и ни строкой больше.
Здравствуйте, Demiurg, Вы писали:
D> Пример из практики — этими разработчиками была написана своя версия функции регистрации COM-сервера, просто потому, что они не знали, что есть стандартная.
я один раз столкнулся со случаем, когда чел написал вызов методов интерфейсов COM полностью вручную, через IDispatch. Налопатил целую кучу оберток.
Просто он никогда не слышал про #import
Здравствуйте, bkat, Вы писали:
B>SNiFF очень неплох для навигации и поиску по коду. B>Он позволяет настроить себя так, что ты из всей массы B>файлов будешь видеть только то, что нужно тебе.
Зашел на сайт где sniff этот лежит ...
мне показалось, или он действительно стоит 2 с чем-то
штуки баксов ?
Здравствуйте, pivoo, Вы писали:
P>Здравствуйте, bkat, Вы писали:
B>>SNiFF очень неплох для навигации и поиску по коду. B>>Он позволяет настроить себя так, что ты из всей массы B>>файлов будешь видеть только то, что нужно тебе.
P>Зашел на сайт где sniff этот лежит ... P>мне показалось, или он действительно стоит 2 с чем-то P>штуки баксов ?
Да, он недешев.
Но чем больше я с ним работаю, тем больше он мне нравится
Впрочем это всего лишь один из многих тулов...
Не факт, что тебе он понравится.
Здравствуйте, Demiurg, Вы писали:
D> Интерфейсы есть. Дело не в том, что я не могу сам свои классы унаследовать от одного базового или интерфейса, а в том, что есть уже (допустим) огромная куча чужих классов, и хотелось бы с ними работать через смартпойнтеры. При написании своей программы с нуля эта проблема снимается.
А разве те классы не наследуют от общего TObject?
Здравствуйте, Шахтер, Вы писали:
GS>>Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
Ш>Я произносил вслух -- жив остался.
Обычно коммерческий код не переписывается (не поддается переписыванию) потому, что в процессе писания переговорено с тучей разных людей, а переписывать — говорить все эти разговоры по новой.
Но, однако, бывают варианты. Вот сейчас мы наконец домучиваем набор автоматизированных тестов, хорошо покрывающий систему, так я теперь, пожалуй, и начану потихоньку переписывать наиболее одиозные вещи — поскольку любое изменение смогу прогнать по тестам вместо того, чтобы релизить, получать критику и долго обсуждать с кем-то кто знает бизнес — как же все это должно работать. И то — бизнес-логику трогать не хочется, а вот всякие архитектурные ошибки можно и попробовать. То есть не переписывание, а рефакторинг.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Advanced_User, Вы писали:
A_U>>Какие будут ваши рекомендации ?
M>
M>repeat
M> View;
M> Edit;
M> if Need then Undo;
M> if Vagueness then WriteUnitTest;
M>until False;
M>
Ну и что? Разберись с тем, что делает данный блок, для чего он в приницпе нужен. Дай в шапке комментарий ко всему блоку. Изредка адвай комменатрии на строках справа (особенно если длинный if...else). Комментарии другие разработчики вряд ли будут стирать, да и табу это вообще, комментарии текстовые стирать — это ж не закоменченный код, как ни как...
Рано или поздно другие разработчики (не такие трудолюбивые в плане писать комментарии, как ты ) поймут, что писать комментарии — это хорошо, может даже научатся писать их правильно... просто делай свое дело хорошо, оставайся самим собой и все будет хорошо
Здравствуйте, Advanced_User, Вы писали:
A_U>Скажу сразу, что программист я не очень опытный ещё Поэтому часть из моих размышлений о работе в составе команды носит чисто теоретический характер
A_U>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
skip
A_U>Какие будут ваши рекомендации ?
есть одна книжка на эту тему
Диомидис Спинеллис "Анализ программного кода на примере проектов Open Source"
я ее как раз читаю, понравилась(рецензии на нее на руском "никакие" на ACCU она описана намного лучше)
Здравствуйте, George Seryakov, Вы писали:
GS>Здравствуйте, Advanced_User, Вы писали:
A_U>>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п. Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
Изучай чужой код.
Когда я разбирался в eMule, то нигде толково не нашел описание работы протокола. Качнул сырцы, говырялся с ними.
ps. Иногда я просто качаю сырцы популярных и общепризнаных опенсурс проектов только для того, чтобы посмотреть как
люди пишут, как они оформляют свой код.
)
... и изумишься... 
Поэтому часть из моих размышлений о работе в составе команды носит чисто теоретический характер 
Все равно неуниверсально вышло, как ты понимаешь.
