Русские документы
Ежедневные компьютерные новости RSS rusdoc.ru  Найти :
Новости
Последние поступления
Книжный магазин
  Hardware:
Видеоустройства
Системные платы
Процессоры
Мобильные устройства
Аудиосистема
Охлаждение системы
Накопители информации
КПК и ноутбуки
Телефоны и связь
Периферия
Система
Сети
Разные устройства
 
  Programming:
Web-разработка
Языки программирования
Технологии и теория
Разработка игр
Программная инженерия
 
  Software:
Операционные системы
Windows 7
Базы данных
Обзоры программ
Графика и дизайн
   
  Life:
Компьютерная жизнь
Разные материалы
   
Партнеры
Публикация
Правовая информация
Реклама на сайте
Обратная связь
Экспорт в RSS Экспорт в RSS2.0
    Читать в Яндекс.Ленте



Дорабатывать или переписывать

Раздел: Programming / Теория разработки @ 26.03.2012 | Ключевые слова: версия для печати

Автор: Dreddik
Источник: habrahabr

Основная мысль этой статьи: переписывайте с нуля работающий и внедренный проект только под дулом пистолета.



Далее, представим, что вы работаете один, и ни с кем не делитесь печеньками.

Ситуэйшн №1: маленький проект


Представьте, что вы студент. Пишите ваш первый студенческий проект – больше, чем лабораторная, но меньше, чем реальный коммерческий проект. Размер примерно 1000 строк кода.
Вы написали его и захотели улучшить. Но вдруг обнаружили, что в архитектуре у вас ошибка, и исправление проблемно. Переписали. Потом еще раз. Станете ли вы переписывать его в четвертый раз? Возможно.
Небольшие проекты можно переписывать бесконечно, пока они не будут доведены до совершенства. Но вот проблема: где эта грань между совершенством и сумасшествием?
Я думаю, что хоть немного средний проект нельзя довести до совершенства, ведь сегодня вам кажется, что совершенны одни методы, а завтра – другие. А время будет потеряно. В конце концов вы можете сдать полурабочий проект, который застрял на стадии третьего переписывания (вы ведь студент, и в первом проекте решили не использовать VCS, ведь это мейнстрим).

Ситуэйшн №2: свободное плавание


Теперь вы уже продвинутый студент, и захотели пофрилансить. А может просто создать свой проект, свою игру, свой аукцион с блекджеком и… ну вы поняли.
Есть отличная идея, вы ее описали, запрограммировали, сделали, оптимизировали. Дали протестить тестерам. Казалось бы, ничего не предвещало беды.
Но вот вы обнаруживаете, что встраивать новые возможности вам все сложнее, а где-то в глубине души вас грызет червь переписывания.
Подумайте, цените ли вы свое время и результаты своей работы, чтобы переписать ваш чудесный проект размером 5000 строк кода. Если не цените, то пожалуйста, начинайте с чистого листа. Помните, что в этом случае, ваш проект врядли будет закончен.

Ситуэйшн №3: чужой код



Это самый опасный путь, скользкая, мерзкая и пакостная дорожка. Итак, представьте, что свой студенческий проект вы кое как сдали, свой личный проект забросили (извините, конечно же отложили, чтобы вернуться, когда будет время!).
И вот, к вам попадает чужой код в 10-15 тысяч строк. Говнокод. По-вашим представлениям. Внедрение обновлений равносильно выстрелу себе в ногу. Переписываем?
Не торопитесь. Сначала оцените свои возможности. Сколько времени вам потребуется, чтобы это переписать? Как это будет оплачено? Заложено ли нужное время?
Переписывание чужого кода чревато несколькими проблемами.
Первая проблема: код, скорее всего, уже внедрен и работает. В этом случае, вам не только нужно будет заново разработать весь его функционал, но и учесть все костыли, на которые наткнулся бывший говнокодер.
Вторая проблема: вы можете не потянуть проект, начать прокрастинировать, и в конечном итоге, окончательно завалите проект.
Третья проблема: почему вы так уверены, что вы сами не напишите такой же говнокод?

Ситуэйшн №4: устаревший проект или специфичные инструменты


Возможно, это единственное частичное оправдание полному переписыванию проекта. Известно, что сейчас многие работающие программы стары, как дерьмо мамонта, но люди продолжают ими пользоваться. Потому что они работают, отлажены, и ошибки в них возникают известно где. Такой проект действительно можно переписать с нуля, при учете жестко и четко сформулированных требований, моря тестов и многих часов отладки. Однако помните, что даже в этом случае нет гарантий, что проект заработает сразу, как нужно. Возможно поэтому до сих пор существуют программы, старые как… ну вы поняли.



Итак, когда не надо переписывать проект:
1) Когда вы дорожите своим временем, и временем других людей, которое они вложили в проект;
2) Когда вы не уверены, что сможете точно повторить функционал проекта;
3) Когда вы не до конца разобрались с проектом, не знаете его особенностей;
4) Когда вы говнокодер;
5) Когда никто не угрожает вашему любимому хомячку.
6) Размер проекта превышает 10000 кода, без учета инструментов и фреймворков. Даже этого будет много чтобы оценить, стоит ли овчинка выделки.

Когда, возможно, стоит переписать проект:
1) Когда внедрение доработок занимает чрезвычайно много времени и/или очень много средств из-за чрезмерной сложности системы;
2) Когда вы изучили проект досконально и знаете каждую его деталь;
3) Когда вам доставляет удовольствие в пятидесятый раз переписывать свой любимый калькулятор;
4) Когда заказчик пришел к вам домой и настойчиво утверждает, что ваш или чей-то чужой говнокод очень плохо работает, и он хочет, чтобы вы сделали все замечательно с первого раза;
5) Когда вам предлагают невообразимую кучу денег за небольшой проект.

И еще помните, что серьезные люди считают, что переписывание проектов с нуля – это признак непрофессионализма.
Удачи.

Все, что Вы хотели знать о гаджетах и новейших технологиях, читайте в электронном "Журнале для гиков", который выходит раз в месяц. Только для настоящих гиков









версия для печатиРаспечатать статью


Вернуться в раздел: Programming / Теория разработки


Реклама:
Читать наc на:

Add to Google
Читать в Яндекс.Ленте






Rambler's Top100
© Copyright 1998-2012 Александр Томов. All rights reserved.