Помните, в прошлый раз я рассказывал Вам историю о том, как я боролся с ошибками программистов?

Вот что было дальше.

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

Казалось бы — все скрипты проектируются с использование ООП, перед выкладкой они проверяются, ручная выкладка запрещена, юнит-тесты делаются. И всё равно ошибки лезут так, что мама не горюй.

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

Но всё равно ошибки возникали вновь и вновь. Что делать?

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

Не оставалось ничего другого как снова лезть в коды и анализировать причину сбоев.

Вы не поверите, но я был шокирован тем, что увидел.

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

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

Т.е. на всё, чему они обучались, было откровенно положено с большой горки.

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

В общем, полнейшее разгильдяйство и пофигизм.

У меня даже депрессия была после этого.  Ужасно неприятно видеть людей, которым нас..ть на результаты своего и чужого труда (извините за выражение).
Что же сделать, думал я? Вроде бы сделано всё, что только можно. Что придумать?

Тогда я собрал все проблемы в одну кучу:

  • Программисты не пишут юнит-тесты
  • Написанные юнит-тесты не анализируются на наличие ошибок
  • Неверно проектируются классы
  • Классы пишутся заново вместо того, чтобы повторно использовать уже имеющиеся

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

Вот что было сделано:

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

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

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

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

И вот каким был результат:

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

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

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

В результате количество ошибок сильно сократилось.

Конечно, не очень понятно на сколько хватит этих мер, но пока они помогают.

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

Итоги

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

  • Перейти на ООП. При этом крайне важно разработать правильную структура классов с использованием шаблонов проектирования
  • Научить программистов проектировать классы правильно
  • Лучше всего нанять системного архитектора, который будет заниматься проектированием классов вместо программистов. А программистам оставить тупое кодирование и документирование исходных кодов
  • Обеспечить контроль качества исходного кода хотя бы с помощь его визуального просмотра
  • Исключить влияние человека на выкладку изменений на сайт. Сделать автоматические сборки боевого и тестовых серверов
  • Не давать проводить сборки при отсутствии юнит-тестов или при их ошибочных срабатываниях
  • Увеличить интервал стабильности боевой системы
  • Нанять системного аналитика для составления технических заданий и тщательной проработки альтернатив
  • Поставить составление тест-кейсов для ручного тестирования на поток. Сделать так, чтобы тестировщик тупо тестировал и ставил галочки, и не делал никакой аналитической работы

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

Переломить людей и заставить их думать над своими действиями очень и очень трудно. Задача не имеет решения.

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

Попробуйте его, может быть он сработает и у Вас.

Связанные записи

Share →

6 Responses to Программисты — олухи? Или как добить программиста и сделать его машиной для кодинга

  1. Angel:

    Я чуть прозрел от статьи… Есть много сомнений, но все же полезное почерпнул. Спасибо!

  2. Александр:

    Евгений, конечно, бывают программисты олухи. Он пишет так, что кроме самого него никто ни чего не понимает. Но заказчики и постановщики программ  — вот это олухи! Зачем программы задают бессмысленные вопросы? Программисты не виноваты — таков заказ!

  3. Весьма вероятно. Рекомендую в этих случаях нанимать системного аналитика, чтобы он составлял подробные ТЗ

  4. Angel:

    Согласен, каков заказ, таков и результат. Когда мне не дают ТЗ и я сам все думаю, то так же бывают глюки. К примеру я делал программы бухгалтерам и когда по одному бланку делаешь программу, а потом тебе заявляют о том, что я чего то не учел…
    Но опять же, автор говорит про большие проекты, про управление таких проектов. Мне, к примеру, нету возможности нанять системного аналитика…

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

    http://sitecoders.ru/category/%d0%ba%d0%b0%d0%ba-%d0%be%d0%b1%d1%89%d0%b0%d1%82%d1%8c%d1%81%d1%8f-%d1%81-%d0%b7%d0%b0%d0%ba%d0%b0%d0%b7%d1%87%d0%b8%d0%ba%d0%b0%d0%bc%d0%b8/

    Проблема вот в чем:

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

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

    Т.е. получается, что Заказчик заранее даёт Вам неверную информацию.

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

    Т.е. Вы, конечно, не виноваты. Но отсюда все беды.

    А решение очень простое: в каждой задаче Вам нужно обязательно разобратьсяв том, какая у Заказчика бизнес-цель. Зачем ему нужна эта программа.

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

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

    Может быть для этого ему вовсе и не отчеты нужны?

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

    И здесь Вы должны взять всё в свои руки и сделать правильно.

    И для этого Вам придётся хорошенько разобраться в предметной области.

  6. Angel:

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

    P.S.: Спасибо за статьи, я теперь ваш постоянный читатель. У вас своего форума нет? Могу предложить общение у себя на форуме, буду рад. Правда, я думаю у меня пониже уровень знаний, я программист БД и с нетом только знакомлюсь, но сайт и форум будут серьезные, надо только разогнаться, а времени практически ноль…

Добавить комментарий