Все же есть в этом мире порой некоторые вещи, которые можно обсуждать бесконечно.
И что самое замечательное, каждый раз такое обсуждение может закончиться совершенно непредсказуемым результатом, как для автора, так и для читателей.
Любому разработчику известно для чего нужды костыли, велосипеды и грабли. И наверняка у каждого уже есть парочка в гараже, а так же бубен на стенке для особых случаев. Если у вас еще их пока нет, вы либо совсем недавно присоединились к нам (Возможно, только вчера открыли «PHP для чайников» и через пару дней у вас они тоже будут. Костыли будут конечно же свои, не многие из нас открывают свои чуланы чужим.) или ставите задачи для вашей армии раз***в (пусть тут будет слово близкое вам сегодня), когда очередное недоразумение уронит вам сервер, выведет кривой отчет или просто откажется запускаться программа. Оставлю тихую надежду, что остальные, те кто пользуется плодами этого совместного творчества сюда не зайдут.
Начнем с определения.
«Костыль — приспособление для поддержания веса тела пациента при стоянии и ходьбе» (с) Вики
То есть «костыль» не такое уж и плохое решение, как может показаться. Думаю, не один здравомыслящий человек не будет отказывать от возможности ходить, когда этого лишён, но он точно не захочет опираться на клюку когда все в порядке.
Определение есть, теперь немного о предмете (пациенте)
Считается что приложение (решение, система…) пишется с первого раза, без ошибок и не требует не только поддержки, но и развития. О процессе утилизации — переходе от одного решения к другому (вы надеюсь не верите в зубных фей и в вечно работающие сервера, базы данных, платформы, технологии) промолчим, как и об оценке каждого их этих этапов.
Вообще все ещё немного страшнее, существует целые направления в науке занимающие оценкой проектов, анализу рисков и остальной околоразработческой деятельности.
Назовем эту простую стратегию – «Стратегия святого Грааля разработки». Никто никогда не видел быстро-качественно-дешево, но все уже хотят еще вчера, и что самое интересное все знают, что это такое — «сделайте мне красиво».
Результат очевиден.
В итоге, в погоне за великой целью гибнут многие из нас, кто в странных технологиях: гибкая разработка, автоматизированное тестирование, парное программирование и т.д., и т.п.; кто в темных углах различных средств и языков, начиная от C++, Java, Pyton, PHP, JS; кто на подобных форумах ^_^
А давайте предположим, что пациент изначально больной (в надежде что не головой, бывают и такие варианты). Что, если единственно, что ему надо — не научиться бегать (конечно бегать, ведь ходить или ползать неинтересно, где вы встречали вменяемые сроки отведенные на разработку), а получить представление о беге, почувствовать ветер и скорость, пусть это будет просто вентилятор и человек бегающий с кустом в руках вокруг. И тогда все становиться гораздо проще.
Тогда достаточно используя различные костыли создать нечто способное ковылять и по мере развития, если конечно оно последует (реальный бизнес такая не предсказуемая вещь), мы потихоньку будет сначала убирать, то один, то другой, при условии полной или частичной «реабилитации» «пациента».
В итоге каждый получит что хотел: клиент получить возможность бегать и не надорвётся в попытках взять стометровку на олимпийских спринтах, да и разработчики не будут судорожно подбирать очередную клюку в надежде, что вот как раз теперь она нужного размера.
Резюмируя.
Исходя из нашего предположения, вы как разработчик всегда должны проектировать две системы (а иногда и больше, гораздо больше): первая это то, что можно сделать прямо сейчас, и «идеальная» — включающая идеальное представление о том, какой она должна быть (вдруг и правда, нужно будет выиграть олимпиаду).
Вы должны уметь в уме создавать решения способные изменять любую имеющуюся систему на набор костылей и наоборот.
И главное, в следующий раз, когда будет решать ну прямо очень сложную задачу, попробуйте для начала вот ту палку в углу, которую поставили пару дней назад, возможно, что и не заработает, но поковыляет.
И что самое замечательное, каждый раз такое обсуждение может закончиться совершенно непредсказуемым результатом, как для автора, так и для читателей.
Любому разработчику известно для чего нужды костыли, велосипеды и грабли. И наверняка у каждого уже есть парочка в гараже, а так же бубен на стенке для особых случаев. Если у вас еще их пока нет, вы либо совсем недавно присоединились к нам (Возможно, только вчера открыли «PHP для чайников» и через пару дней у вас они тоже будут. Костыли будут конечно же свои, не многие из нас открывают свои чуланы чужим.) или ставите задачи для вашей армии раз***в (пусть тут будет слово близкое вам сегодня), когда очередное недоразумение уронит вам сервер, выведет кривой отчет или просто откажется запускаться программа. Оставлю тихую надежду, что остальные, те кто пользуется плодами этого совместного творчества сюда не зайдут.
Начнем с определения.
«Костыль — приспособление для поддержания веса тела пациента при стоянии и ходьбе» (с) Вики
То есть «костыль» не такое уж и плохое решение, как может показаться. Думаю, не один здравомыслящий человек не будет отказывать от возможности ходить, когда этого лишён, но он точно не захочет опираться на клюку когда все в порядке.
Определение есть, теперь немного о предмете (пациенте)
Считается что приложение (решение, система…) пишется с первого раза, без ошибок и не требует не только поддержки, но и развития. О процессе утилизации — переходе от одного решения к другому (вы надеюсь не верите в зубных фей и в вечно работающие сервера, базы данных, платформы, технологии) промолчим, как и об оценке каждого их этих этапов.
Вообще все ещё немного страшнее, существует целые направления в науке занимающие оценкой проектов, анализу рисков и остальной околоразработческой деятельности.
Назовем эту простую стратегию – «Стратегия святого Грааля разработки». Никто никогда не видел быстро-качественно-дешево, но все уже хотят еще вчера, и что самое интересное все знают, что это такое — «сделайте мне красиво».
Результат очевиден.
В итоге, в погоне за великой целью гибнут многие из нас, кто в странных технологиях: гибкая разработка, автоматизированное тестирование, парное программирование и т.д., и т.п.; кто в темных углах различных средств и языков, начиная от C++, Java, Pyton, PHP, JS; кто на подобных форумах ^_^
А давайте предположим, что пациент изначально больной (в надежде что не головой, бывают и такие варианты). Что, если единственно, что ему надо — не научиться бегать (конечно бегать, ведь ходить или ползать неинтересно, где вы встречали вменяемые сроки отведенные на разработку), а получить представление о беге, почувствовать ветер и скорость, пусть это будет просто вентилятор и человек бегающий с кустом в руках вокруг. И тогда все становиться гораздо проще.
Тогда достаточно используя различные костыли создать нечто способное ковылять и по мере развития, если конечно оно последует (реальный бизнес такая не предсказуемая вещь), мы потихоньку будет сначала убирать, то один, то другой, при условии полной или частичной «реабилитации» «пациента».
В итоге каждый получит что хотел: клиент получить возможность бегать и не надорвётся в попытках взять стометровку на олимпийских спринтах, да и разработчики не будут судорожно подбирать очередную клюку в надежде, что вот как раз теперь она нужного размера.
Резюмируя.
Исходя из нашего предположения, вы как разработчик всегда должны проектировать две системы (а иногда и больше, гораздо больше): первая это то, что можно сделать прямо сейчас, и «идеальная» — включающая идеальное представление о том, какой она должна быть (вдруг и правда, нужно будет выиграть олимпиаду).
Вы должны уметь в уме создавать решения способные изменять любую имеющуюся систему на набор костылей и наоборот.
И главное, в следующий раз, когда будет решать ну прямо очень сложную задачу, попробуйте для начала вот ту палку в углу, которую поставили пару дней назад, возможно, что и не заработает, но поковыляет.
