тренинг и воспитание культуры разработки программистов

Провести тренинг, с последующей аттестацией.

я конечно могу сам насоцинять, но очень хочется хотя бы готовых кусков. напр кроме сабжа еще умение с комстрокой, с гит и прочим работать

для гита - http://progit.org/

для красивых программ - взять сырцы программы, красиво написанной, но небольшой, рассмотреть в примерах. Дать небольшие задачки, рассчитанные на «красивое» решение, пусть закрепят усвоенное.

с небольшими кусками все ок, проблемы с их компоновкой и концептуальным пониманием проекта

Э паря, да я смотрю тебе самому тренинг не помешал бы...

Почему то что раньше по-человечески называлось «курсы», сейчас все кличут «тренинг», ты что с обезьянами работаешь ? Хорошо хоть не «дрессинг»... Долбаные «тренды»...

P.S. Отправь из на нормальные курсы для мотивации(это я типа так пошутил, тратить деньги же придется) и проводи каждую неделю 2ух часовые разборы говн в коде. В понедельник утром. На первый час что бы опаздывать можно было... мотивация однако...

Теперь ты меня понимаешь?

да, и мне не помешал бы. между «курсы» и «тренинг» есть вполне внятная разница в нынешних реалиях. треннинг подразумевает короткий цикл подготовки и формирует склонности и привычки. на курсах добывают знания, что не совсем по сабжу

и концептуальным пониманием проекта

если человек идиот то никакие тренинги не помогут

тут даже сложно что-либо посоветовать, кроме практического опыта.

во многом то может быть и моя вина - когда начинали делать ТЗ не было в принципе и все пришлось сочинять на ходу, не имея опыта в сабже есессно

проблемы с их компоновкой и концептуальным пониманием проекта

концептуальным пониманием

Либо вы набрали идиотов, которым не по зубам такие задачи.

Либо задача поставленна кое-как. Но даже в случае плохопоставленной задачи люди разбираются и делают это, обычно, перед кодированием.

Либо ситуация проще — бывшие студенты всё ещё делают то же самое, что делали в универе — пропихивают залепы преподом на «авось прокатит».

Задача руководителя — разобраться с ситуацией, неподхощих людей на позициях заменить/сменить процесс/организацию работы. 90% тренинг из первого поста ничего не исправит.

Мы пробуем внедрять взаимное тестирование и ревизию кода - один пишет, другой внимательно просматривает код и тестирует. Настраивает на написание читабельного кода. Плюс озвучивание и обобщение возникающих проблем. Процесс не быстрый, но когда человек на своем опыте осознает как вот-то его решение привело к вот этой проблемме - это хорошо усваивается мозгом :). А тренинг - как рефлексы без понимания - как раз и ведет к тому, что

фокусируются на реализации а не на концепциях

имхо.

И еще - если ад начинается при сборке, то можно заподозрить слабую постановку задач (имхо, чем слабее разработчики, тем детальнее нужно продумывать и расписывать задания).

Заставь их зазубрить TDD и какие-нибудь CRC-cards как «Отче наш» - авось поймут, что двигаться надо от интерфейса к реализации

Сорри за грамматику, высокая т-ра даёт о себе знать.

Прочитал как «троллинг и воспитание культуры программистов».

Вообще проблема в том, что они не умеют работать в команде. Это не так плохо - плохо то, что их некому координировать в данном случае.

да, так и есть. и правда что у мну мало опыта в сабже. вопрос в том что делать и как бороть?

Практического опыта чего? «Ошибок трудных»? Наверное, все-таки бывают другие методы обучения. Например, отличать «работающие» методы от «неработающих» можно и нужно на основе чужого практического опыта. Правила хорошего тона в программировании работают только когда становятся привычкой - бывает, молодые лиды пальцы гнут - вот тут отступления от архитектуры (перевод «тут должен быть мой любимый паттерн»), вот тут нарушения Naming Convention (а документ на проекте есть? А случай для квалификации «нарушения» в нем зафиксирован или это лид на ходу придумал?), «в общем куча недостатков!» (Логика! А что ты сделал, чтобы эти недостатки предупредить?) А документов с архитектурой и т.д. нет и в помине. По-моему, нет документа с политикой, «архитектура» существует только в голове и болтовне лида, уснащенной для вящей пущести феней вроде «паттернов» и «воркфлоу»? Какой спрос с простого человека? Для отличения «плохих» привычек от «хороших» необходимы примеры неправильного применения имеющихся средств (и, что немаловажно, - конкретные советы «как бы я сделал» (критикуешь - предлагай), или объяснения почему вот это «не работает», наглядное разоблачение «каргокультизма» и т.д.) Или приходит «рыцарь на белом коне», крестоносец методоложества - все выкидывает без разговоров или по-своему переписывает, на основании «так лучше», «красивее», или все подряд «оптимизирует» без опоры на измерения (как оно там «оптимизировалось»-то? Может, конкретному компилятору пофиг изъебы с арифметикой указателей, inline и макросами? Усилий на рупь, а выхлоп на копейки? Ну и чему у него учиться? Как понты кидать перед начальством?) Ну а управлению проектами, тоже можно и нужно учиться у тех, кто в них понимает. Если люди не видят систему в целом - и свой в ней «участок работы» - значит концепция не переведена на понятный им язык (ТЗ, например, полезно обсуждать, а то, выясняется внезапно, что аналитики имели в виду не совсем то, что написано - и даже не то, как это понимает лид: «Нафиг тут ваш IPC? Вы мне про этот IPC вторую неделю говорите! Заменить на обмен файлами по FTP, но сейчас!» Или «Зачем этот ваш лид сделал тут пейджинг? Тут должен быть обычный скроллинг!»)

В последний раз когда мне предложили поруководить я от напряга мозгов разогнал команду и за неделю переписал всё с нуля)

Но поначалу думал что хорошее ТЗ и раздача задач помогут.

Когда я был малолетним.., ээ.., школотой, то любил грешным делом порисовать каракули. И однажды понравилась мне в книжке картинка, там рыцари, один на лошади, второй на полу, а лошадь рядом, дохлая, меч вытаскивает. В смысле не лошадь дохлая меч вытаскивает, она лежит мирно, а второй рыцарь. А тот, первый на него копьём примеряется. Ну так за чем же дело стало, взял бумажку с карандашом и начал.

Начал конечно с меча. Меч нарисовал, перешёл на жопу лошади. После лошадиной жопы перешёл на второго, и с него дошёл и до первого, так в общем по кругу и прошёл. И тут обнаружил странную вещь. Что-то концы с концами не сходились: второй рыцарь с жопой лошади получился поменьше, а первый, который на живой ещё, чуть побольше и вбок уехал. И понял я что дорисовать эту картинку мне не судьба. Но самый занятный опыт, который я из этого вынес - это то, что окружающие вообще не видели проблемы и говорили «ну давай, дорисовывай, осталось же немного»

Да, а к чему это здесь? Так после этого случая я и понял что контекст важнее текста. И, также, что пока сам не ё^W ушибёшься - скорее всего так и не заметишь этой простой истины. Ну а тебе остаётся только придумать как им устроить расшибание морды лица поэффективнее.

По-моему, нет документа с политикой, «архитектура» существует только в голове и болтовне лида, уснащенной для вящей пущести феней вроде «паттернов» и «воркфлоу»?

как писать такие документы? как их формализовать?

Какой спрос с простого человека?

мыслить концепциями и помогать лиду в принятии решений. иначе на кой черт он тогда нужен? бездумно кодить то что ему на блюдечке занесут? по мне это называется работа на от%?ись

когда начинали делать ТЗ не было в принципе и все пришлось сочинять на ходу.

Обычное дело. Писать ТЗ просто нет времени, да и заказчик толком не представляет что ему надо.

Хорошо помогает UML. И с заказчиком разговаривать проще и организовать работу в группе. Но тут ВСЯ ответственность ложится на того кто UML нарисовал.

А с комментариями... Если их нет, или недостаточно, не принимать код в реп. Ну и тренинг с обучением.

ЗЫ. Я тут эксперимент провел. Весь код что ушел в корзину по всяческим причинам, в отдельный файл собрал. Получилось 24.6% от общего объема кода. Причина: «заказчик толком не представляет что ему надо».

как писать такие документы? как их формализовать?

Эк все вам на блюдечке занеси :) Обсудите с коллегами. Придете к консенсусу - успех. Не придете - значит надо еще обсудить. Отыскать компромиссы. Вообще, naming convention - не та вещь, из-за которой стоит долго ломать клавиатуры в асечке^Wскайпе. Достаточно, чтоб она отражала суть: правила, порядок такой-то, возможные отступления. И нарекания по коду чтоб были на основании пунктов документа, а не «чувства прекрасного» и плохого настроения. Уж точно не «скобочки у тебя не так стоят» (как не так?) и «не нравится мне это название класса, не звучит!» (а оно кого волнует, как звучит название класса?) Архитектура интеснее и сложнее - не все задачи можно натянуть на желательную архитектуру («уложить в концепцию», если угодно - заказчику похеру концепции, ему конкретную проблему решить надо) и любимые паттерны не везде применить. А то читаешь в коде комментарий про такой-то трюк с шаблонами - с цитатой из Александреску... И чего? Этот трюк чего-то тут дает? Знавал одного лида - у него с языка не сходили «концепции», «паттерны», и MVC с синглтоном были везде (хоть в тестовом клиенте, который нужен только для того чтоб был «Сервер передает привет!»). А вот с многопоточностью труба - и хрен ли с его концепций толку? (Переписывать за лидом - не смешно ли?)

«мыслить концепциями» - а как это? Продемонстрируйте :)(Попахивает тавтологией) И... для «помогать в принятии решений» - надо привлекать людей к их принятию. Некоторая самостоятельность и доверие либо сделают человека ответственным, либо он действительно лишний. А ежли все контролировать и не давать свободы - спрос с одного, остальные тут просто работают (ты начальник, ты и думай). Ежели лид весь себе на уме («я сказал!») - пусть его куражится. Жизнь пообтешет. (Сугубое единоначалие оно в армии хорошо. А знаете для чего? Чтоб было на кого списать возможные эксцессы. Если лид все решения принимает сам - и отвечать будет сам. Один. «А почему ты так сделал? А мне лид так велел, но не объяснил зачем - я-то хотел по-другому»)

Эк все вам на блюдечке занеси :)

истории успеха тоже сгодятся

Обсудите с коллегами.

прежден нужно какой-то базис предложить. на сейчас это вики с аля «сопроводительной документацией» к платформе которая пилится постфактум. плюс что в процессе написания такой доки не только стабилизируется концепция, но и проясняются внятно формализованные архитектурные корректировки.

а оно кого волнует, как звучит название класса?

это очень больная тема, ибо название должно отражать концепцию. и если не отражает мы рефакторим

«уложить в концепцию», если угодно - заказчику похеру концепции, ему конкретную проблему решить надо

в том и дело что концепция у нас эволюционирует под требования, но некоторые вещи неизбежны и в них нужен порядок и единообразие

«мыслить концепциями» - а как это?

понимать какова роль твоей подсистемы и как она взаимодействует и какова ее роль для остальных

это очень больная тема, ибо название должно отражать концепцию. и если не отражает мы рефакторим

Мы рефакторим, когда класс сам не «отражает концепцию» - делает не то, что нужно или доказуемо неэффективно. Название класса должно а) отвечать правилу именования б) Быть понятным в контексте проекта (уж точно «синглтон» не должен называться Singleton, только если это не шаблон - в общем, смысл как с комментариями «ничего не говорящий комментарий - лишний комментарий» («капитану очевидность» слова не давали))

понимать какова роль твоей подсистемы и как она взаимодействует и какова ее роль для остальных

Это должно быть ясно из архитектуры - роль документа, UML там или стрелочки на салфетках, в том, чтоб «сложность системы» свести к обозримому набору «коцепций»: вот голова, а вот он хвост. Слона нужно есть по частям, но если дискуссия идет о том, на что похож слон (притча про «трех слепых»: слон похож на змею, на бочку, на колонну) - значит документ а) существует для галочки б) годится в шредер.

Сколько человек пишут код?

со мной пятеро

Я всегда думал что это приходит с опытом и параллельным чтением литературы.
А тут кажут что можно стать программистом за день тренинга. Круто, запишите и меня туда.

Сбор воедино системы в целом так и вовсе ад.

с небольшими кусками все ок, проблемы с их компоновкой и концептуальным пониманием проекта

Договариваться об интерфейсах надо до, а не во время сборки (хоть письменно, хоть устно). Не отвечает интерфейсу - в переплавку (заодно рефакторить научатся или... паттерн фасад освоят :)).

у нас по ходу разработки появлялись классные идеи, в итоге мы достаточно далеко ушли от начальной концепции. хоть и угробили на неё не один день перед доской для рисования

В группе есть один-два сильных программиста, способных помогать тебе следить за «картиной в целом» по имплементации?

есть ребята сильные в технологиях и в линуксе - тут все ок. но концепции, разбор требований и решение проблем роста - все на мне. натаскиваю народ, но уж больно неэффективно - потому и прошу историй успеха

Натаскиваешь всех?

да. любые концепции обсуждаем, все решения проговариваем. но народ со временем теряет нить и внятно улавливает ток свой кусок

Почитать «Человеческий фактор».

пускай описывают свои алгоритмы блок-схемами с комментариями. То есть перед тем как начать что либо писать в коде пусть рисуют блок-схемы.

Больше не общаться неформально, чтобы научиться понимать и уважать друг друга.

Больше общаться неформально, чтобы научиться понимать и уважать друг друга.

//мать-перемать

1) Нужно больше времени отвести формальной документации интерфейсов/взаимодействия компонентов

2) Делегируй часть свой работы на «сильного» человека, первое время придётся тратить время на его обучение и контроль, но если он «разгонится» — станет легче.

Вообще команда у тебя маленькая, больших проблем не должно быть. Как с руководством, так и с контролем, включая написанного.

Обычно делается так:

1) Формализуется задача и назначается человек на её решение

2) Человек может потратить какое-то небольшое время на изучение области, дальше он выкатывает приблизительный план того, что, как и как долго он будет делать.

3) Человек решает задачу, тестирует код, готовит его к сабмиту. Перед сабмитом проводится формальное ревью кода несколькими людьми из команды.

В зависимости от объёма, сложности и т.д. часть моментов опускается. В случае необходимости происходит реитерация. На каждом этапе ведётся контроль, тобой либо людьми, которым ты доверяешь.

но народ со временем теряет нить и внятно улавливает ток свой кусок

Результаты обсуждения документированы? Есть техлид/архитектор/эксперт?

Я не очень понимаю что именно у вас идёт не так.

Это мало поможет. Проверенно на собственном опыте ;)

Идеи это хорошо. Но вписать их в концепцию нужно тоже как-то так, чтоб интерфейсы у людей, над ними работающих, совпали :) Не знаю, раньше плясали от данных - вход такой, выход такой - а чего внутри происходит, хоть цирк с конями, но интерфейс между компонентами трогать не моги. Сейчас всех волнует сопровождабельность (особенно на словах) Но все ее по разному понимают - если кто-то не понимает мой код, значит я непонятно пишу, если я не понимаю его код - значит я «не владею концепциями проекта». Где-то тут махровое кидалово :) (Особенно это выпукло проявляется при обсуждении пресловутой naming convention. А некоторые еще гордятся, что при первой возможности все под себя переделывают.
Я б за такое по рукам бил. Металлической линейкой.^UВвел бы политику: «что твое то твое: „исправил“ чужое, изменил интерфейс - обосновал на цифрах и фактах», а не встал в позу К.О. с «очевидными концепциями»)

не документированы, потому как нет формального способа и методы их записи. на словах в расчете на то что со временем выработается базис понятий и общий стиль системы

простой пример - мы поняли что логику лучше вынести в скрипты, реляции в хранилище данных убрать и вместо этого юзать smarty-подобный шаблонизатор. одно только это изменило систему в корне. но если бы не это фиг бы мы вовремя сдали первую итерацию проекта - требования стремительно менялись.

Это не есть гуд.

Решений несколько — формализировать и описать систему. Или чётко формализировать задачи (включая интерфейсы/зависимости/етц). Или устно передавать знания тем, кто их поймёт и будет по ходу дела выдавать остальным. Ни один пункт не исключает остальные.

Ээээ как это знакомо. Быстро такую ситуацию не исправить. И кстати так не бывает, что отдельные части кода хороши, а вместе говно. Код либо весь говно либо нет. Для начала введите должность проектировщика. Добавьте соревновательный элемент. Типа учреждается призовой фонд в размере >= получки. Определяете задание и из расчёта 1час в день устанавливаете срок. Победитель получает бабосики. В следующий раз соревнование становится командным ( по 2 человека), призовой фонд увеличивается в 2 раза. И так пока весь офис не поделится на 2 фронта. Чтобы не устанавливалось жёстких товарищеских связей - перемешивайте группы. Недовольных а-ля «я не буду работать с Сидоровым» - увольняйте со спокойной душой, от таких только завалы на проектах. Со временем получите вменяемую команду. Не «эгегей» конечно, но они смогут работать группой, а не сидеть каждый в своей песочнице.

Блок-схемы алгоритмов? Они ж вроде не помогают нифига :) Да и Брукс не советовал - мол, блок-схема «отживший анахронизм». Блочная структура и интерфейсы (некоторые любят говорить «воркфлоу», но оно находит отражение во внятных интерфейсах).

И что это в корне меняет? Согласовывать интерфейсы некогда, поэтому забьем на это дело, кинем монетку у кого правильный?

Документация это не решение проблемы, а её часть.

Глупо увольнять сотрудника и искать замену, а потом вкладываться в обучение замены, если можно найти к нему подход.

Про удвоение «вознаграждения» вообще не понял. Если в офисе несколько десятков программистов — сума будет о#*-я, дальше молчу.

Пьянки не считаются.