LINUX.ORG.RU
ФорумTalks

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


0

1

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

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

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

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

зы. культуры коллективной разработки уже хватает на стабильную работу в git когда все ковыряются в мастер ветке, потихонечку появляется документация в redmine и doxygen. на хилую троечку в общем.

зыы. у всех линуксы, проект на кьют

Ответ на: комментарий от slackwarrior

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

VladimirMalyk ★★★★★
() автор топика
Ответ на: комментарий от Rzhepish

если можно найти к нему подход.

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

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

Посчитай. Это дешевле, чем курсы повышения.

iBliss
()
Ответ на: комментарий от VladimirMalyk

у нас интерфейсы стабилизируются уже в процессе разработки

Что-то тут тревожное в cловах таких вижу я. Стабилизация стабилизацией, но единое представление об интерфейсах - хотя бы присутствует? Или «вася вчера болел, его забыли предупредить» ВЗРЫВ КИШКИ РАСПИДАРАСИЛО^W^W^W

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

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

slackwarrior ★★★★★
()
Ответ на: комментарий от iBliss

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

VladimirMalyk ★★★★★
() автор топика
Ответ на: комментарий от slackwarrior

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

VladimirMalyk ★★★★★
() автор топика
Ответ на: комментарий от VladimirMalyk

я не осилю организовать такое, не тот уровень тимлида у меня

Подкинь идею генеральному. Наймите на работу какого нибудь бывшего мента или военного. (После развала большой и необъятной и «реформ» в отдельных и независимых их много без дела). Желательно такого который одинаково может и цитировать Ницше и обсуждать результаты работы в духе северстали. Без вложений такое никак.

iBliss
()
Ответ на: комментарий от iBliss

Есть такая штука, как КТУ. Представляет из себя а-ля бонус к ЗП. Нихера не делаешь — нихера не получаешь.

По бонусу, ты писал про бонус на группу или на человека?

Rzhepish
()
Ответ на: комментарий от iBliss

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

VladimirMalyk ★★★★★
() автор топика
Ответ на: комментарий от Rzhepish

По бонусу, ты писал про бонус на группу или на человека?

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

iBliss
()
Ответ на: комментарий от VladimirMalyk

из йт его сраными тапками гнать придется

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

iBliss
()
Ответ на: комментарий от iBliss

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

VladimirMalyk ★★★★★
() автор топика
Ответ на: комментарий от VladimirMalyk

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

Худо - бедно , но это работает. Хотя конечно такая схема попахивает совком.

iBliss
()
Ответ на: комментарий от VladimirMalyk

и вопрос как мне быть когда я не на голову выше и меня не два или три?

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

iBliss
()
Ответ на: комментарий от VladimirMalyk

когда я не на голову выше

ты имел ввиду, что ты сильно опытнее людей в команде (выше на несколько голов) или что ты такой же ростом?

и меня не два или три?

На что ты тратишь сейчас время и на что тебе не хватает времени?

Rzhepish
()
Ответ на: комментарий от VladimirMalyk

тут трудно формализовать цель, условия и критерии оценки.

Вот твои проблемы. Если нет цели — её не достигнуть. Если нет критериев оценки — то всё будет говном/или не говном, в зависимости от настроения.

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

Так не бывает. Если ничего не понятно вообще — стоить потратить немного времени на «оценку реализиуемости» (feasibility study) и дальше составить планы/цели/оценки/раскидать по людям.

Rzhepish
()
Ответ на: комментарий от Rzhepish

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

VladimirMalyk ★★★★★
() автор топика
Ответ на: комментарий от VladimirMalyk

- Записывай/формализируй требования/ТЗ.

- Вовлеки способных к созданию/поддержанию архитектуры исходя из требований

- Участвуй в инспекциях кода и решений по дизайну. К кодированию приступай, если осталось время. Лучше потрать в два раза больше времени, чтоб объяснить людям, что и как ты хочешь, но не делай сам. Дальше должно всё окупиться. На подходе «хочешь сделать правильно - сделай сам» далеко не уедешь.

Rzhepish
()
Ответ на: комментарий от Rzhepish

Добавлю, ещё на лоре тема была «начинаещего руководителя» АйТи отдела, там кидали ссылки на мануалы/книжки. Может найдёшь что полезное для себя.

Rzhepish
()
Ответ на: комментарий от urxvt

Я всегда думал что это приходит с опытом и параллельным чтением литературы.

Трижды плюсую литературу и документацию. Тимлид, каким бы крутым он не был, всё-равно опирается на что-то. Вот это что-то и нужно рекомендовать к изучению разработчикам. Тогда у Вас будет общее видение модели.

backbone ★★★★★
()
Ответ на: комментарий от slackwarrior

Блок-схемы алгоритмов? Они ж вроде не помогают нифига

К интерфейсам наверное надо добавить диаграммы состояний, а то модель будет не полной.

backbone ★★★★★
()
Ответ на: комментарий от VladimirMalyk

VladimirMalyk

вопрос в том что делать и как бороть?

Прочитал как «что делать и как пороть?». А ведь не такая плохая идея :)

drull ★☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.