Только так и никак иначе…
В работе над крупным проектом я все чаще и чаще начал думать об архитектуре кода. И сегодня решил поискать информацию на эту тему. К сожалению именно об архитектуре кода мало что сказано и написано. Эта тема очень сильно связывается с архитектурой программного обеспечения в целом.
Возможно я что-то не понимаю и не то ищу в сети, не правильно определю суть проблемы, не знаю. Постараюсь определить что я хочу сказать и вывести проблематику.
Допустим есть большой проект, я имею ввиду web проект. Так получается что над проектом работает сначала одна группа разработчиком, потом другая, потом третья. Что мы получаем в результате, а получаем мы абсолютный бардак. Горы кода, классов и методов, от js в глобальном пространстве просто тошнит всех браузеров, так как каждый писал свои мега-супер-мини библиотеки и пытался заставить всех использовать именно его. А фишка в том что каждый из разработчиков был примерно одинакового уровня за исключением просто пары халявщиков, или заумных бездарей. На счет последних, они самые опасные для проекта, так как могут натворить делов, их нужно быстро вычислить и дать волшебный пендаль сцуко. Как правило такие люди все знают и все умеют, и умеют убеждать заказчика, и подписывать его на всякую чушь.
В общем мы получаем хаос вместо хорошо спроектированного проекта. Теперь главный вопрос, что с этим всем делать? Заказчик отплатил всему этому табуну мега крутых разработчиков кучу бабла, он ставил задачи, они делали, он платил. Казалось все чики-пуки, ан нет уважаемые, уже пошел обратный отчет, отчет когда проект просто загнется нахер. Почему? До потому что не будет у такого проекта хорошего, быстрого и четкого сопровождения. Придут новые гениальные разработчики и внесу в этот хаос свой великий вклад в виде пары тысяч строк говнокода.
Как решить проблему? А я считаю что это проблема, не как иначе это не называется.
Ищем причины.
А они банальны как всегда:
Одной из больших проблем нашей русской школы программирования является отсутствие системного и качественного преподавания в этой области. По факту все разработчики в нашей стране — самоучки. Где-то что-то у кого-то подсмотрел, пару лет зарабатывал на пиво копипастом имен процедур с мануалов по языку. Дай бог один из ста проходит сертификацию Майкрософта, поневоле почитав умных учебников, не забыв отсыпать новых терминов (с гордостью) друзьям в курилке. Иногда на профессиональном пути встают на день-два призраки Брукса и Кнута, с тем же успехом затем отправляясь собирать пыль на книжной полке. Примерно так рождаются наши программисты, так что все разговоры о капусте, аистах и бородатых админах, желающих странного, нагло ошибаются.
Ну и так далее и тому подобное…
Полностью согласен с автором, ссылка на пост, тут автор тоже размышляет на эту тему.
Наверное пора задумать о чем-то большем чем тупое кодирование. Решил заняться этим вопросом в серьезе, о своих успехах буду писать в своем блоге.
Тоже часто задумываюсь насчет этого, так как сам являюсь самоучкой и многого просто не знаю или не до конца понимаю.
А вообще, я считаю, это проблема «стандартов» в проекте, т.е. когда все пишут гору ховна, а не нормально спроектированные библиотеки и классы.
Я считаю, что в каждой фирме или очень крупном проекте, должны быть оговоренные стандарты разработки, чтобы переменные назвались по стандартам, чтобы на каждый функционал были осмысленные приставки в названиях переменных, чтобы код писался в одном стиле и так далее. Думаю, наличие данных стандартов от части решит проблему сопровождения и поддержки программного кода.
Возможно я ошибаюсь.
Подобные мысли всегда возникают, когда управление проектом возложено на людей, имеющих весьма отдалённое представление о методиках управления проектом. Если изначально слабо была проработана концепция проекта, включающая в себя инструменты, методы и стандарты разработки, а так же заранее не были методично проработаны риски проекта. Концепция проекта должна включать в себя ВСЮ информацию по проекту. Начиная с детального описания проблемы, которую проект призван решить и заканчивая согласованным и отрисованным дизайном интерфейса всех деталей. Если речь идёт о сайте, то отрисовано должно быть все страницы, включая внутренние «админские». Все варианты всплывающих окон и других динамических реакций на действия пользователя.
Под методами я имею ввиду описание того как и где будут храниться исходники, какая будет использоваться система контроля версий, а так же какова схема работы с системой (как будут формироваться релизы, будут ли использованы ветки проекта, для каких целей и т.д.). Под стандартами проекта подразумеваются стиль написания кода (PEAR, ZendFramework Style и т.д.), требование по использованию определённой кодировки, некоторых принципов (например, хранение изображений в MySQL, а самой MySQL-базы c картинками на отдельном домене для экономии трафика и увеличения производительности за счёт отсутствия необходимости обработки кук, принципы авторизации, общие требования к безопасности переменных различных типов).
Тщательно должны быть проработаны риски проекта:
— Что делать, если заболел Ведущий программист?
— Что делать, если в ходе разработки заказчик меняет требования к проекту, реализация которых затрагивает переработку более 30% от общего объёма уже написанного кода?
— Что делать, если увольняется дизайнер?
— Что делать, если вышел из строя сервер на котором велась разработка проекта? Кто его будет восстанавливать, где будут браться бэкапы и реальные сроки работ по восстановлению в случае если с сервером все совсем плохо :)
и т.д.
Если кратко, концепция должна представлять собой детальное описание полностью готового к использованию продукта. Если всё это не было надлежащим образом задокументировано и согласовано участниками проект становится «спонтанно» управляемым (из-за того, что у участников «своё» видение проекта, в соответствии с которым они его реализуют), а итоговый результат — плохо предсказуемым. Все ведущие гиганты-разработчики ПО IBM, HP прошли этот этап ещё в 70-х годах. Именно тогда были сформулированы общие концепции управления проектами, позволяющие повысить эффективность разработки ПО. По методике PMI (pmi.org) соотношение работ по планированию и непосредственно написанию кода должно быть 60/40.
У нас до сих пор часто бытует мнение, что главный человек на проекте — программист :)
Главный Лаборант не ошибается, всё дело в системном подходе и планировании.
ЗЫ: Remember the 8 Ps: Perfect Planning and Prior Preparation Prevents Piss-Poor Performance!
Не все могут позволить такого рода «бюрократию». В этом то и дело что вести правильно проекты могут далеко не все, потому что дороже получается, думаю понятно почему. Проще нанять пару программистов и заваливать хотелками.
Неумелое управление проектом можно даже отнести к рискам, но экономящим деньги. У меня не раз было что тз представляло из себя psd файл с от рисованной главной страницей :)
Хочу отметить что движение в этом направление есть, и это не может не радовать. Системы управления проектами растут как грибы, видимо не просто так.
«Бюрократия», «… риск, экономящий деньги» :)
Глубокое заблуждение. Сэкономите деньги на грамотном координаторе проекта и по ходу разработки неизбежно столкнётесь с ситуацией (процитирую Вас): «Что мы получаем в результате, а получаем мы абсолютный бардак.»
И потом, если бы методики управления были не эффективны, они бы не получили широкого распространения на Западе. Там их оценили именно за то, что они сокращают время разработки проекта и в итоге делают его дешевле.
Я имел ввиду что дороже получается для тех, кто не занимался этим никогда. Примеров из опыта массы, собственник проекта зачастую далек от этого всего, он хочет такой же сайт как у соседа.
Управление проектом это не такая и тривиальная задача, по этому нужен специалист, а на него денег нет.
Чем я не управленец, подумает заказчик и начнет писать в скайп ТЗ :)
@google-eabeeecb310b27ae44540ac4a97533fa:disqus Наверное пора задумать о чем-то большем чем тупое кодирование.
Основы понятия методика разработки:
http://en.wikipedia.org/wiki/Software_development_methodology
Варианты подходов к управлению и разработке:
http://en.wikipedia.org/wiki/List_of_software_development_philosophies
Нужно определить несколько вариантов наиболее близких и понятных Вам и взять их на вооружение.
Есть смысл плотно заняться UML. Предварительная визуальная проработка алгоритмов в итоге делает код более лёгким для восприятия, даёт плюс к производительности. Может показаться, что это лишняя трата времени и т.д., но когда это станет привычкой Вы по-достоинству оцените такой подход. Это и есть профессионализм — когда наиболее передовые и эффективные методы стновятся привычкой.
И завязывайте с ковбой-кодингом :)
http://en.wikipedia.org/wiki/Cowboy_coding