Мар
29
Эволюция архитекторов и каменщиков программных проектов
Март 29, 2009 |
К написанию этой заметки подтолкнуло недавнее общение с одним человеком в ICQ. Для того, чтобы было понятнее, краткое описание предшествующих событий.
Предыстория
Жил-был один проект, построенный некоторое время назад. Построенный не то, чтобы очень качественно, но жизнеспособно. Почему не слишком качественно - сейчас уже не докопаешься. Возможно, человеку, которого поставили архитектором, знаний и опыта не хватало, возможно времени, возможно злой умысел, а возможно просто разгильдяйство и недосмотр. Но, в любом случае, так случилось. Через некоторое время пути проекта и человека, стоявшего на позиции архитектора, разошлись. На место архитектора стал другой человек. Вот с этим человеком и произошел диалог примерно следующего содержания:
Shedar
> пока стараюсь набираться опыта и развиваться
что интересного узнал за последнее время?
> постоянно ковыряюсь в [вырезано цензурой]
расскажешь какую-нибудь интересную багу? фичу которой ему серьезно не хватает?Тот самый человек:
> что интересного узнал за последнее время?
увлекся рефакторингом и паттернами, активно изучаю и практикуюсь на [вырезано цензурой], переделываю [вырезано цензурой]
> интересную багу? фичу которой ему серьезно не хватает?
пока ничего интересного
Небольшая аналогия
Раз уж речь зашла о архитекторах, то аналогия будет из строительства. Был человек, который спроектировал дом на побережье. А на случай приливов он сделал дом на ножках. Вот только немного несбалансированный. И если больше половины жильцов дома подойдут полюбоваться морем одновременно, то они в этом самом море и окажутся. Но пока все живы.
Потом этот человек ушел и на его место поставили другого. Задачу ему поставили - сделать этот дом лучшим на всем побережье. И начал он менять все окна и двери на шикарные и надежные. Возможно, если на стороне удаленной от моря будет больше дверей и окон, а новые потяжелее старых, то баланс дома немного выровняется. А возможно и наоборот - ухудшится. Это уж как повезет. И угроза падения дома остается. Хотя каждое окно и дверь проверено в куче экстремальных условий и являются практически образцом надежности…
Новый человек вероятно замечательный строитель, каменщик. Но, если он стал на место архитектора, то желательно начинать не с замены окон и дверей, даже если новые лучше старых.
Немного выводов
В последнее время все чаще наблюдаю подмену понятий. Когда архитектором называют человека, владеющего шаблонами проектирования. Я не говорю, что шаблоны проектирования это плохо. Это хорошо, потому как позволяет в ряде ситуаций не изобретать велосипед. Но этого не достаточно.
Высказывание “сделать из г-на конфетку” работает и в обратную сторону “сделать из конфеток г-но”. И возникает такой случай как раз тогда, когда считают design pattern-ы и тесты достаточным условием разработки качественных систем.
Давайте называть вещи своими именами.
P.S. чтобы совесть меня не мучила, стоит отметить, что тем человеком из начала истории, сделавшим первую кривоватую версию был я =)
Comments
11 Comments so far
-
Sphinx - отличная штука для полнотекстового поиска. Но, всегда есть неприятные мелочи, порой довольно неожиданные, на которые натыкаешься в неподходящие моменты. Краткий список предостережений (актуален на момент написания, дополнения и поправки приветствуются):6 hours ago, comment
- поддерживая строковые атрибуты, не умеет сортировать по ним
- в rt индексах не поддерживаются MVA
- в rt индексах не поддерживаются префиксы и суффиксы
- В xmlpipe2 datasource не поддерживается тип bigint для атрибутов, только 32 бита
- не поддерживает персистанс для апдейтов MVA атрибутов, более того, "Due to internal technical difficulties, currently it is not possible to store (flush) any updates on indexes where MVA were updated"
взгляните не так глубоко, сейчас есть и “программисты на html”). Всё намного хуже!
З.ы.: инетересно, я догадываюсь о чём речь, или .. просто мне так кажется…
> инетересно, я догадываюсь о чём речь
Думаю догадываешься =)
> сейчас есть и “программисты на html”). Всё намного хуже!
Для программистов на html что-то писать бесполезно =) А в данной области, может заставит задуматься.
Интересно. А вот правильно или нет? Все зависит от конкретной ситуации и целей, которые должны быть достигнуты. Если Вы как архитектор, проектировали и строили жилой дом и цель у вас разместить для жилья 100 человек, и что бы эти 100 человек заплатили приемлемую цену за свое жилье, то в таком случае решается классическая мини-максная задача. И если Вы данную задачу решили успешно, то почет Вам и хвала. Но есть и другой класс задач, когда мини-макс не ставится априори, а просто определяется задача из разряда “вот хочу, вот такое, какого нет у других”. Ну тут и пошло. Набежали сверхмодные архитекторы и наперебой вот и тут мы так сделаем, а тут кекса из-за кордона привезем, а тут модную технологию вкрутим, а тут кое что подучим да попытаемся применить. Вы только деньги давайте. И началось строительство. Используя модную технологию 1 окно поставили в сжато короткие сроки 1 неделя, с дверями пришлось повозиться ушло 2 недели. Ну и так далее. А 100 человек ждет своего жилья, а бюджет вырос в 5 раз, а дома все нет. Ничего Вам это не напоминает? К сожалению это наша жизнь, это наше бытие. Сплошной лоходром под эгидой модных технологий. Современные технологии нужны, и никто не оспаривает их необходимость, и тем более их применение. Но когда современные технологии оказываются заложником производственных задач, а тем более в руках аборигенов, пытающихся использовать эти технологии на других и за чужой счет, а тем более учиться строить прямо на стойплощадке, вот это и есть большая проблема. Производство и наука, суть два разных бытия, которые не могут жить друг без друга. Но в этой совместной жизни они должны жить на паритетных условиях. А производство прежде всего мини-максная задача и решается она по законам “жанра” в первую очередь. :))))
> А вот правильно или нет?
Правы ли были те кто заказывал “не знаю что, но покруче” - нет.
правы ли были те, кто вместо строительства учились за чужой счет - вопрос не однозначный. С точки зрения личного эгоизма - они научились, им еще и заплатили, т.е. довольно выгодно. С точки зрения порядочности - не учиться вообще (т.е. соответственно не развиваться) непорядочно и только учиться тоже непорядочно. Есть та самая грань, именуемая золотой срединой, которая у каждого своя, и определяется воспитанием, окружением, условиями заказчика и многим другим.
Потому в описанной ситуации заказчик неправ, а судить неправы ли исполнители нельзя из-за нехватки данных =)
Вот интересно, как можно начинать исправлять то, что дом может упасть, без уверенности в том, что твои испрвления не завалят дом сразу и вообще? Выходит, чтобы быть в этом уверенным, необходимо отличное понимание того, как он построен сейчас и тесты того, что внося определенные изменения, они как минимум не ухудшат текущего состояния. Я так понимаю, что изначально тестов никто не писал, поэтому в первую очередь их надо написать, прежде чем делать какие-либо изменения. Если изначальный архитектор ушел, значит разбираться в том, из какого материала построен дом, как велась кладка и почему может дом завалиться, придется новым строителям. Теперь перейдем в программный мир. Если никто не оставлял комментариев, не писал тестов и проектировал без паттернов, то придется немало усилий затратить, чтобы разобраться в том, как все работает. А лучший способ разобаться и сделать лучше - это написать тесты, провести рефакторинг и применить паттерны там, где их не хватает. Потом уже и проблемы завала дома решать лечше, не опасаясь, что твои решения угробят все на корню. В конце концов, даже новых окон не поставишь, если не уверен, что они не завалят дом
Еще один тот самый человек, по пунктам.
> в первую очередь их надо написать
Написание тестов в первую очередь - не лучшая идея. Чтобы писать тесты, надо понимать что тестить, как тестить и главный вопрос ЗАЧЕМ тестить. 100% покрытие кода тестами - это тесты ради тестов.
> и почему может дом завалиться
Как я говорил, недостаток “визуально” заметен, и вовсе ни к чему для этого ковыряться в кладке.
> Если никто не оставлял комментариев,
Оставлял, другой момент, что при переносе отдельные человеки запороли процентов 90 из них, но это совсем другая история.
> и проектировал без паттернов
паттерны наше всё? =)
> сделать лучше - это написать тесты
тесты сами по себе не делают код лучше
Тесты под те фрагменты кода кторые будут переделываться - это да. Если код нужно переделать (а для этого уже нужно знать зачем его переделать). А “тесты - наше все” - чушь.
> провести рефакторинг
рефакторинг как самоцель - это как танцы, может быть приятно, красиво, но если не преследует конкретной цели (нужно решить задачу Х, но при этом в месте У без рефакторинга фича Z вкручивается очень туго) - бесполезно.
Обобщая выше сказанное - подход, описанный в Вашем комментарие преследует скорее цель достичь программистского оргазма, чем решить конкретную задачу.
Программистский оргазм, по-моему, лучше достигать на чем-то новом, чем переделывать или улучшать старое
Паттерны - это не наше все, это опыт многочисленных людей в решении _часто_ возникающих _типовых_ проблем. Тесты - это безопасность от собственных промахов. 100% покрытия, согласен, не надо. “Наше все” - это, скорее, кооперация всех составляющих для решения контретной задачи (или в даном случае проблемы). Отсутсвие одной из них - либо не решит проблему, либо решит ее долго и некачественно.
Вам бы познакомится с одним индусом, который написал 20000 строк кода в одной фукнции, работа, которой очень напоминала Ваш дом. Проблема в том, что люди очень часто переходили на сторону моря и дом очень часто падал. Но уже даже сам архитектор не мог понять, что же именно там не работало
Без рефакторинга и тестов ошибки в том коде искали бы еще лет 20. Просто не вижу другого способа нахождения и исправления ошибок, если уж было принято решение оставить исходных код, а не писать все заново.
> Тесты - это безопасность от собственных промахов.
тесты это скорее безопасность от опечаток. И при активном рефакторинге, когда переписывается часто и много и вероятность опечаток довольно высока, штука полезная. В этом согласен. Но от тех ошибок, которые программист не видит - тесты не спасут, ведь он не осознает возможность ее возникновения. Можно хоть весь дом перестроить, но если таки не посмотреть в чем были проблемы старого то будет ли у нового та же проблема - это не более чем вопрос удачи, как повезет.
> Просто не вижу другого способа нахождения и исправления ошибок
я уже несколько раз писал - нужно отойти чуть всторону, посмотреть и подумать. Не залазя в кладку и окна, просто стать сбоку и подумать, как же могут повести себя жильцы. И вот когда станет понятно что не так, зачем мы вообще будем что-то переделывать, когда мы осознаем проблему, вот тогда брать и переделывать нужную часть, попутно занимаясь написанием тестов в тех местах где они нужны, рефакторингом и решением возникшей проблемы.
> который написал 20000 строк кода в одной фукнции
я где-то написал что нужно делать такие функции? о_О я лишь за то что применение тестов паттернов и рефаторинга должно решать какую-то конкретнкую задачу. Паттерны бесспорно штука полезная, но применять красивые паттерны в местах где они с вероятностью 99,3% не дадут преимущества ближайшие 15 лет - пустая трата сил, времени и денег заказчика.
Можно написать калькулятор, поддерживающий только суммирование с использованием кучи паттернов, что даст мне неоспоримые преимущества в случае если я решу из него сделать matlab, вот только какова вероятность такого развития событий?
Красавчег! Пиши исчё!