Comments 18
Занимаюсь разработкой «с нуля» новой версии САПР на основе старой немецкой. Причин было много — основные — крайне устаревшая модель системы 30летней давности, проблемы с пересборкой и и необходимость внедрения нового функционала.
Никаких графиков не чертил, а сначала изучал старую систему в течение 2х лет, занимаясь ее допиливанием и поддержкой. Когда стало ясно, что перспектива не лучшая, убедил начальство, что надо разработать систему заново на современных платформах (Java), и не старый код курочить, а писать понимая суть дела.
Затем написал ТЗ, рисовал кучу архитектурных картинок — просто, в Visio, без наворотов.
Потом были проектирование БД, споры с коллегами как лучше сделать, презентации новой системы.
Что-то рисовали конечно, но старый код и реализации вообще не копировали и не рефакторили. Брали за основу только принципы.
Сейчас прошло 2 года, над системой работали несколько человек, и на носу 2хтысячная SVN-ревизия. Новая система уже запущена.
Никаких графиков не чертил, а сначала изучал старую систему в течение 2х лет, занимаясь ее допиливанием и поддержкой. Когда стало ясно, что перспектива не лучшая, убедил начальство, что надо разработать систему заново на современных платформах (Java), и не старый код курочить, а писать понимая суть дела.
Затем написал ТЗ, рисовал кучу архитектурных картинок — просто, в Visio, без наворотов.
Потом были проектирование БД, споры с коллегами как лучше сделать, презентации новой системы.
Что-то рисовали конечно, но старый код и реализации вообще не копировали и не рефакторили. Брали за основу только принципы.
Сейчас прошло 2 года, над системой работали несколько человек, и на носу 2хтысячная SVN-ревизия. Новая система уже запущена.
Мне как-то не хватило убедительности на такой шаг, да и мы перед этим проводили анкетирование разных самарских компаний по поводу «переписать все или нет». Если сумею, то выложу результаты этой анкеты и саму анкету. Но кратко, там практически единоличное мнение «ни в коем случае нельзя все переписывать». В любом случае Вы герой.
У нас тоже было практически единоличное мнение начальства против. За наше с коллегой «новый САПР» на презентации нас ругали на чем свет стоит.
У вас пожалуй посовременнее система, раз там есть прослойка к БД на C#.
А у нас разработка 80х кодов — С, Фортран, Shell, гора файлов, скриптов и бинарников. И куча ошибок.
так что просто не было другого выхода.
У вас пожалуй посовременнее система, раз там есть прослойка к БД на C#.
А у нас разработка 80х кодов — С, Фортран, Shell, гора файлов, скриптов и бинарников. И куча ошибок.
так что просто не было другого выхода.
Это надо решать не анкетированием, а сравнением трудозатрат: цена поддержки старого плюс стоимость внесения изменений в старый код по сравнению со стоимостью переписывания и оценочной стоимостью внесения изменений в новый код.
> а сравнением трудозатрат
Напишите про это статью? Мне было бы интересно почитать, как и кем это делается на практике.
> не анкетированием
Да, метод не точный, зато хорошо выявляет настроение людей. Мы не машины, если мы изначально на что-то смотрим с негативом, то работа не пойдет в полном темпе. Зато после анкетирования мы со всеми лучше познакомились, с кем-то отдельно встретились, нам дали ценные советы и т.д… Польза все-таки была.
Напишите про это статью? Мне было бы интересно почитать, как и кем это делается на практике.
> не анкетированием
Да, метод не точный, зато хорошо выявляет настроение людей. Мы не машины, если мы изначально на что-то смотрим с негативом, то работа не пойдет в полном темпе. Зато после анкетирования мы со всеми лучше познакомились, с кем-то отдельно встретились, нам дали ценные советы и т.д… Польза все-таки была.
Не, ну чего люди не придумают — лишь бы не программировать :)
А программирование по вашему это быстрый набор корректных с точки зрения синтаксиса наборов символов в IDE?
Речь о том, что делать подобное «исследование» (кластеризацию) — это лишь трата времени. Вроде же речь о C#, тогда вообще какая проблема получить методы обращающиеся к одной таблице — вида «дай все ссылки, где это используется». И потом работать с каждой таблицей отдельно. Зачем красивые графики?
> это лишь трата времени
Так говорили и про Unit-тестирование, и про TDD, и про написание человеческих спецификаций. Трата времени — делать что-либо не имея возможности построить прогноз. Однако в этом случае мы уже посмотрели на айсберг снизу, еще не начав рыть верхушку.
> получить методы обращающиеся к одной таблице
Это вы как хотите сделать? Через поиск подстроки? Утомитесь, я думаю. Несколько сотен таблиц и пара тысяч методов… Мой средний темп был не более 20-ти методов в день. Есть методы, которые за один день-то не сделаешь. Я попробовал недельку и быстро понял, что пора как-то по-другому браться за задачу.
> Зачем красивые графики?
Зачем иллюстрации? Ну вот не все люди понимают текст без опоры на визуальную информацию. Я, например, такой. Очень рад за Вас, если куча текста без единой иллюстрации воспринимаются Вашей головой в полном объеме и без проблем.
Так говорили и про Unit-тестирование, и про TDD, и про написание человеческих спецификаций. Трата времени — делать что-либо не имея возможности построить прогноз. Однако в этом случае мы уже посмотрели на айсберг снизу, еще не начав рыть верхушку.
> получить методы обращающиеся к одной таблице
Это вы как хотите сделать? Через поиск подстроки? Утомитесь, я думаю. Несколько сотен таблиц и пара тысяч методов… Мой средний темп был не более 20-ти методов в день. Есть методы, которые за один день-то не сделаешь. Я попробовал недельку и быстро понял, что пора как-то по-другому браться за задачу.
> Зачем красивые графики?
Зачем иллюстрации? Ну вот не все люди понимают текст без опоры на визуальную информацию. Я, например, такой. Очень рад за Вас, если куча текста без единой иллюстрации воспринимаются Вашей головой в полном объеме и без проблем.
Спасибо за интересное исследование.
В книжке про чистый код упоминается паттерн active record.
Я правильно понимаю, что в Вашей статье, речь как раз про выявление таких объектов, для связи с БД?
В книжке про чистый код упоминается паттерн active record.
Я правильно понимаю, что в Вашей статье, речь как раз про выявление таких объектов, для связи с БД?
Структурно это довольно близко к active record.
Это было бы так, если ваши методы занимались лишь записью/считыванием (select/insert/update/delete одной конкретной таблицы). Но судя по тому, что вы написали — это не так. Я так понимаю в рамках метода может быть обращение к нескольким разным процедурам. Это аналогично хранимой процедуре в SQL-сервере. А раз так, то вам нужно было выбрать только те методы которые занимаются записью/считыванием, а не обработкой данных. Тогда это и было бы создание active record.
> в рамках метода может быть обращение к нескольким разным процедурам
и соответственно, к разным таблицам.
и соответственно, к разным таблицам.
Я не утверждаю, что это AR. Однако действительно есть классы вида «класс-на-таблицу» с методами операций CRUD. Также будет генерироваться класс-Reference, в который будут сброшены такие методы, которые оперируют несколькими таблицами, но одна из низ признана главной. Все будет в продолжении, не переживайте.
Очень интересно. Только это не взгляд со стороны предметной области, а попытка (надеюсь успешная) разбить систему на подсистемы не вникая в предметную области а с точки зрения абстрактной функциональности и простой арифметики.
Я ни в коем случае не берусь критиковать такой подход, если он работает — это было бы круто. На практике все может разрушиться из-за пары мелких нюансов, незаметных без глубокого изучения бизнес-логики.
Я ни в коем случае не берусь критиковать такой подход, если он работает — это было бы круто. На практике все может разрушиться из-за пары мелких нюансов, незаметных без глубокого изучения бизнес-логики.
Интересно ли почитать статью по NRefactory?
Стоит ли написать отдельно статью по написанию рефакторингов в Resharper?
Весьма интересно будет почитать и чтобы достаточно подробно касательно технических моментов.
Sign up to leave a comment.
God object. Анализ сложных проектов