OSDev

для всех
Текущее время: 22 ноя 2017, 13:55

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 56 ]  На страницу Пред.  1, 2, 3, 4, 5, 6
Автор Сообщение
 Заголовок сообщения: Re: Miraculix OS
СообщениеДобавлено: 11 апр 2013, 15:44 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Существует физическое ограничение на быдлокод, связанное с тем, что недокументированный код бесполезен при командной разработке. Без документации другие участники проекта не смогут использовать твои модули. Недокументированный код чаще возникает при одиночной разработке, ведь контроля ни какого, даже со стороны рядовых сотрудников.
Я лично пишу мало комментариев, но стараюсь писать текст кода так, чтобы он получался как бы самодокументированным. А для сложных проектов вообще требуются не комментарии, а общее описание принципа работы системы, без этого мало что понятно рассматривая отдельные процедуры даже с комментариями.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Miraculix OS
СообщениеДобавлено: 11 апр 2013, 23:33 

Зарегистрирован: 19 май 2011, 14:54
Сообщения: 73
Не важно работает человек за зарплату или нет. Программируя на себя не станешь лучшим программистом, чем работая в компании. Работая одиночкой или в мелкой компании подцепляешь всякие негативные стереотипы. Сегодня разработка программных продуктов уже более-менее отработана, не то, что 10-15 лет назад. В любом хорошем управляемом проекте есть проектная документация. Проектная документация делается и со стороны заказчика и со стороны разработчика. Заказчик пишет как он понимает то, что ему нужно, разработчик, со своей стороны описывает как он это собирается реализовывать. Поддерживаемые протоколы, взаимодействия и т.д. Детализация на уровне функциональных блоков, списков поддерживаемых функций, протоколов, форматов входных выходных данных, ошибочных ситуаций и т.д. Документация по отдельным проектам на 3-4 календарных месяца достигает иногда 300 или более страниц. (При длительных проектах как правило на каждого разработчика приходится по документу страниц в 150 - 300). Что касается разработки отдельных конкретных модулей, тут глубокой документации как правило не делается, не видел проектов, которые бы сумели сделать на этом уровне документацию, отражающую действительность.

Вместо документации на сам код, сегодня применяется юнит-тестирование и интеграционное тестирование, а также Continuous Integration сервера. В функциональность Continuous Integration сервера входит автоматический билд системы при изменении исходников в системе контроля версий, автоматическом прогоне юнит тестов, интеграционных тестов, если таковые автоматизированные имеются. Но это еще не всё.

Кроме того, чтобы проводить юнит тесты существуют, к примеру библиотеки типа Mockito, позволяющие для любого даже пустого интерфейса создавать mock-объект и задавать принудительно возврат нужного результата операции внутри метода или например выбрасывание исключения и т.д.. Есть также возможности создавать spy - объекты на основе существующих объектов, для изменения только некоторых методов, есть возможность проверить а вызвался ли такой-то метод такого то объекта с указанными параметрами с сколько раз....

Но тесты еще не все. Без грамотного отображения их результатов в них не было бы смысла. Существуют такие программные продукты как Cobertura для Java, позволяющие отображать на веб-странице покрытие исходного кода тестами. Причем отображать не просто покрытие абы как. А вплоть до каждого ветвления и каждой строчки.

Кроме всего выше перечисленного для промышленных языков программирования сегодня существуют IDE, включающие в себя мощнейшие средства для автоматического рефакторинга исходного кода. Что тоже помогает. А знание и применение паттернов проектирования, наконец, дает вам возможность быстро на лету схватывать любой вменяемый современный код.

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

Кроме юнит тестирования и интеграционного тестирования, существует еще функциональное тестирование и приемочное тестирование. На тесты пишется отдельная документация иной раз превышающая по размерам девелоперскую. Все это тщательно согласовывается с заказчиком, а для тестов применяются другие технолологии. Но это уже в Q&A и глубоко в этой сфере я уже не кручусь.

Многих подобных технологий 10 лет назад не существовало. Сегодня наличие упомянутых средств, а также далеко продвинувшуюся вперед программисткая наука, сформулировавшая явно принципы dependency inversion, применившая на практике dependency injection..., разобравшаяся наконец более менее в том, что такое OOП, а также развивающая новые языки программирования в том числе функциональные и т.д. Все это вместе сделало промышленную разработку совсем другой.

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

Наличие "говнокода" в проекте это сегодня не правило, а признак плохого управления проектом. Практика показывает, что средства для получения качественного кода сегодня есть и эти средства вполне по силам к внедрению в большинстве проектов и на моей памяти я видел в том числе и вполне некоммерческий проект, применяющий все средства автоматизации сборок, покрытия тестами, стилями, со вполне вменяемым менеджментом даже... Проект этот назывался http://jtalks.org, разрабатывали они что-то для форумов на базе javа. Я в курсе, просто из-за того несколько моих коллег работающих в одной комнате в этом участовали. Проект кажется закончился удачно, если судить по сайту http://javatalks.ru, на котором результаты применили, как я погляжу. Проект судя по всему продолжается, на сайте можно посмотреть что там применяется http://jtalks.org. Часть средств разработки для проекта была предоставлена бесплатно http://jtalks.org/display/jtalks/Our+Sponsors, после начала проекта соотстветсвующими компаниями разработчиками. Проект был инициирован на форуме javatalks.ru за счет исключительно кармы нескольких модераторов и активных участников.


Последний раз редактировалось achesnokov 12 апр 2013, 11:51, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Miraculix OS
СообщениеДобавлено: 12 апр 2013, 10:46 
Аватара пользователя

Зарегистрирован: 16 апр 2010, 10:10
Сообщения: 319
Откуда: Псковская обл.
:shock: А кто будет писать документацию на саму документацию. :?: Бюрократия!

Как люди ломают защиту без документации и вообще без исх. к. .Это кормушка для тех кто вокруг.

Перечитал еще раз и понял что согласен со всеми. Но как же проще было раньше.


Последний раз редактировалось iz56 12 апр 2013, 11:09, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Miraculix OS
СообщениеДобавлено: 12 апр 2013, 11:09 

Зарегистрирован: 19 май 2011, 14:54
Сообщения: 73
iz56 писал(а):
:shock: А кто будет писать документацию на саму документацию. :?: Бюрократия!
Как люди ломают защиту без документации и вообще без исх. к. .Это кормушка для тех кто вокруг.


Это эмоции и троллинг а не прагматичный подход. Я не утверждал, что нельзя что-то делать неправильно - можно.
Когда люди ломают защиту - они лишь вставляют свои часы работы в чужие сотни или даже тысячи человеко-дней.

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

Я лишь описал, что сегодня реально применяется с перечислением конкретных средств автоматизации и тулкитов.
Все это позволяет делать проекты с zero bug quality - это когда после внедрения не поступает _НИ_ОДНОГО_ бага,
кроме CR (Change Request).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Miraculix OS
СообщениеДобавлено: 12 апр 2013, 11:14 
Аватара пользователя

Зарегистрирован: 16 апр 2010, 10:10
Сообщения: 319
Откуда: Псковская обл.
Да, это эмоции. И протест против времени, наверно.
И вопрос что можно применить для ОС разработки - из инструментов и подходов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Miraculix OS
СообщениеДобавлено: 12 апр 2013, 11:23 

Зарегистрирован: 19 май 2011, 14:54
Сообщения: 73
iz56 писал(а):
Да, это эмоции. И протест против времени, наверно.
И вопрос что можно применить для ОС разработки - из инструментов и подходов.


Сам над этим медитирую. Вопрос стоящий отдельной длительной темы обсуждения.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 56 ]  На страницу Пред.  1, 2, 3, 4, 5, 6

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB