Проектирование
- Лучше потратить большOе количество времени на этапе проектирования информационной системы, чем потерять время и деньги потом.
- Ошибки в проектировании могут повлечь за собой: затягивание сроков, многократное удорожание проекта.
- Проектировать систему стоит целиком от начала и до конца (без добавления дополнительного функционала) или предусматривать модульность:
— разработка и доработка концепции полностью.
— разработка очень подробного технического задания.
— разработка схемы базы данных
— разработка сценариев контроллеров
— разработка дизайна шаблонов представления
— разработка сценария поведения пользователя (он же сценарий тестирования)
— СЕО
— ... - На создание проектной документации и технического задания лучше создать тендер, а затем провести аудит. Возможно на начальном этапе вы потратите больше денег, но зато сможете сэкономить в разы больше в дальнейшем.
Разработка
1. В разработке применяйте готовые и стабильные решения: это значит, что для работы с базой данных лучше применять MVC (Model View Controller) фреймворк или ORM (Object Relational Mapping) или AR (Active Record), а для работы со стандартными сценариями CRUD (Create Read Update Delete) — генератор, который создает код без ошибок.
Ваше мастерство низкоуровневого разработчика никто не оценит, а вот если система работает стабильно и без ошибок будет гораздо большим плюсом.
2. Документируйте код.
3. Создавайте хорошую и понятную техническую документацию.
4. Используйте докер.
5. Используйте системы автоматической сборки версий.
Организация работы команды
- Применяйте системы контроля версий, я в своей работе использовал git.
- Разделяйте работу разработчиков по разным функциональным модулям, для того, что бы когда ветки системы контроля версий будут сливаться в одну — не возникало конфликтов.
- Не занимайтесь экстремальным программированием на коленке, когда на решение задачи отводится от нескольких часов до нескольких дней.
Ставьте задачи минимум на неделю и максимум на месяц до выхода следующей сборки.
Тестирование
- Не используйте системы постановки и исправления задач для тестировщиков.
- Используйте автоматизированные тесты: создайте модуль программных тестов, который будет запускаться каждый раз перед сборкой и тестировать всю систему автоматически.
Цикл разработки
После того, как вы создали качественное техническое задание, можно приступить к разработке, далее приведу повторяющийся цикл:
1. Постановка задач разработчикам в различных системах контроля выполнения задач так, что бы они не затрагивали код друг друга, например разделив систему по модулям, при этом каждый работает в своей ветке.
Задачи должны выполняться в течение недели.
После выполнения каждой задачи, разработчик должен запускать автоматизированные программные тесты, которые покрывают всю систему полностью.
2. Каждый понедельник происходит слияние кода каждого разработчика в главную ветку.
После того, как в главной ветке появляется результат работы всей команды, каждый из разработчиков копирует себе главную ветку.
Далее цикл повторяется.
При таком подходе
- Количество ошибок в результате выполнения задач будет минимальным.
- Вы сможете создать более качественный программный продукт.
- Вы сэкономите время.
- Вы сэкономите деньги.
- Команда будет работать быстрее, эффективнее, слаженнее ( не конфликтуя в плане изменения кода).
- Вы сможете выполнять задачи в срок.
- Выполненные задачи будут более качественными.
- Вам не придется вносить дополнительные задачи, такие как: изменение дизайна, функционала или чего то еще во время хода работ.
Что сделает результат более предсказуемым и простым и понятным.
Программирую уже больше 10 лет, всем интересных и удачных проектов!
Комментарии (16)
berez
06.03.2019 10:23Вам не придется вносить дополнительные задачи, такие как: изменение дизайна, функционала или чего то еще во время хода работ.
К вам никогда не прибегал заказчик с горящими глазами и «небольшими уточнениями» к ТЗ? Еще прибежит. :)
conopus
06.03.2019 10:28Поясните, пожалуйста, на чем основана рекомендация: «Не используйте системы постановки и исправления задач для тестировщиков.»
BALEHOK
06.03.2019 11:24Я, конечно, извиняюсь, но описанный подход кажется довольно узким. Даже для веба так не всегда сработает.
Пара комментариев из моего личного опыта работы (примерно 10 лет в вебе):
1. При работе в команде continuous integration — это наше все! Когда задача выполняется за 1, максимум 2 дня, конфликтов возникает сильно меньше. Соответственно, каждый пулит код из гита ежедневно, а то и не раз (простите, я настолько привык к гиту, что не представляю проект, где работает больше одного человека, без него).
2. К continuous integration добавляется continuous delivery — выкатываем новый релиз, как только готова фича (ежедневно? раз в 2-3 дня?). Это тоже работает не всегда и не везде. Для веба подходит прекрасно, но оно требует определенных усилий на внедрение…
3. Подробное ТЗ — это прекрасно. Но опять же не всегда. Например, для какого-нибудь стартапа чаще дешевле и правильнее выкатить фичу, сделанную «на коленке» за пару дней (или часов), и посмотреть как оно работает. Планирование дизайна при этом никто не отменял — замечательно, если оно сделано так, чтобы через неделю эту «какашку» можно было выкинуть за 2 минуты или превратить в адекватно написанный код малой кровью.
PchelaBeshena
06.03.2019 11:24+1не сочтите за грубость, но статья — повествование «очевидного тривиала» ?! Спасибо, кэп ;)
zsiteru
06.03.2019 11:24Разделяйте работу разработчиков по разным функциональным модулям, для того, что бы когда ветки системы контроля версий будут сливаться в одну — не возникало конфликтов.
В такой ситуации нет защиты от фактора автобуса. Если разработчик который делал конкретный модуль заболел, уволился, в отпуске то работа по этому модулю встанет.
Тут скорее нужно решать через организацию модулей в коде, что бы слияние не выдавало конфликтов, а не через организацию работы разработчиков.
sshikov
06.03.2019 12:03>Вы сэкономите время.
>Вы сэкономите деньги.
>Выполненные задачи будут более качественными.
И все это одновременно? Простите, но автор либо троллит (причем плохо, не интересно), либо откровенно обманывает. Вероятнее всего — себя.Padaboo Автор
06.03.2019 17:01-1Покрывая все тестами:
вы сокращаете количество появляющихся ошибок.
сокращаете затраты на тестировщиков.
прорабатывая тех задание хорошо вы оскращаете количество фишек которые нужно внедрить и количество задач которые нужно выполнить.
увеличивая время на выполнение задачи — вы даете возможность ее качественно проработать.
Я бы не кидался такими обвинениями.sshikov
06.03.2019 20:08>Я бы не кидался такими обвинениями.
А я вот себе позволю. Практически каждый в IT знает формулу: «Мы умеем делать быстро, качественно, и дешево — выберите любые два пункта из трех». А у вас эти пункты перечислены все вместе, так, как будто вы можете достичь их всех одновременно. Что, очевидно, неправда.
Но судя по вашему ответу, вы похоже будете настаивать, что можете достичь всех трех?Padaboo Автор
07.03.2019 08:03Для крупных проектов эта формула выгоднее чем любая другая — я в этом убежден.
Я разработчик и мне в этом плане важен стабильный код.
Если конечно как писалось одним из комментаторов выше вы не делаете: утилиту, драйвер или интернет магазин.
vilgeforce
Я тут на питоне тулзинку пишу для преобразования одного формата файла в другой. Не подскажете, куда мне там Docker прицепить и зачем?
Количество опечаток в написанном грусть наводит на меня :-(
Padaboo Автор
Да вот именно, что я загнал в проверку орфографии перед тем, как написать.
А пишете вы в основном космический корабль на самописном коде и говорите, что те кто фреймворками пользуются программировать не умеют :)
vilgeforce
Те, кто такие статьи пишет, не представляют что программирование бывает за пределами ихнего(!) вэба. А там есть и драйвера, где низкоуровневые выкидоны как раз очень даже нужны, и много чего еще.
sshikov
Да они и ихнего веба похоже не представляют. Вы хоть на упоминание MVC поглядите, в контексте базы данных. А потом сравните с классическим определением MVC, где база данных вовсе не упоминается — а речь идет просто о данных (модели).