История изменений

Когда в СПЕЦИФИКАЦИИ больше пары сотен страниц, ее перестают читать даже ведущие разработчики, уже на первой сотне становится понятно, что ты читаешь bullshit.

Ммм. Помнишь книгу о человекомесяц? Вот у них были спеки из нескольких десятков толстых-толстых книг. И ничего, справлялись. Наоборот, там это всех мотивировало: т.к. было четко и ясно куда стремиться, а что выбросить в мусорную корзину.

Может тут еще играет менталитет, т.к. я заметил, что запад (и восточная азия) стремится минимизировать времязатраты на разработку кода, в то время как другие пытаются минимизировать время на разработку спецификаций. К слову, спецификацию писать проще, потому что она похожа на книгу о фэнтези: выдумываешь, выдумываешь и выдумываешь. А код просто так не выдумаешь, ибо тут у нас ограничения по CPU, тут по ОЗУ, тут еще сетевой стек кривой и не наш, а тут файловая система не обновлена и т.п. Масса ограничений, масса вопросов, которые надо решать. Но все эти технические вопросы быстро решаются, когда есть опыт.

Из этого делаю следующий вывод: лучшая спецификация - это сама система. Применительно к языкам, «язык программирования» - это то, что умеет собирать мой компилятор.

Назови ЯП у которых есть спеки и у которых нет (ответ). Вот автор Erlang призновался (книга с интервью разработчиков ЯП), что ему трудно было написать спецификацию к языку. И что в итоге? В итоге, C это mainstream-язык, потому что есть стандарт.

Кстати, в US, в отличие от СНГ, просто так писать код на ЯП без стандартов в ряде случаев нельзя: для гос. структур, для военных нужд и т.д. Скажешь бюрократия? Нет, все логично, потому что когда наступит момент выяснения ответа на вопрос «кто виноват» спецификация ответит на 95% этого вопроса. Ответ будет скорей всего: разработчик. Не потому что плохо пишет код, или у него синдром архитектуры, а потому что он проглядел спецификацию.

Лучше всего для специфицирования использовать ТЕСТЫ, написанные на языке программирования. Создание нового теста можно считать внесением нового требования в спеку, тз, anything.

От спецификации вреда никогда не будет, если за спецификацией следить и исправлять.

Когда в СПЕЦИФИКАЦИИ больше пары сотен страниц, ее перестают читать даже ведущие разработчики, уже на первой сотне становится понятно, что ты читаешь bullshit.

Ммм. Помнишь книгу о человекомесяц? Вот у них были спеки из нескольких десятков толстых-толстых книг. И ничего, справлялись. Наоборот, там это всех мотивировало: т.к. было четко и ясно куда стремиться, а что выбросить в мусорную корзину.

Может тут еще играет менталитет, т.к. я заметил, что запад (и восточная азия) стремится минимизировать времязатраты на разработку кода, в то время как другие пытаются минимизировать время на разработку спецификаций. К слову, спецификацию писать проще, потому что она похожа на книгу о фэнтези: выдумываешь, выдумываешь и выдумываешь. А код просто так не выдумаешь, ибо тут у нас ограничения по CPU, тут по ОЗУ, тут еще сетевой стек кривой и не наш, а тут файловая система не обновлена и т.п. Масса ограничений, масса вопросов, которые надо решать. Но все эти технические вопросы быстро решаются, когда есть опыт.

Из этого делаю следующий вывод: лучшая спецификация - это сама система. Применительно к языкам, «язык программирования» - это то, что умеет собирать мой компилятор.

Назови ЯП у которых есть спеки и у которых нет. Вот автор Erlang призновался (книга с интервью разработчиков ЯП), что ему трудно было написать спецификацию к языку. И что в итоге? В итоге, C это mainstream-язык, потому что есть стандарт.

Кстати, в US, в отличие от СНГ, просто так писать код на ЯП без стандартов в ряде случаев нельзя: для гос. структур, для военных нужд и т.д. Скажешь бюрократия? Нет, все логично, потому что когда наступит момент выяснения ответа на вопрос «кто виноват» спецификация ответит на 95% этого вопроса. Ответ будет скорей всего: разработчик. Не потому что плохо пишет код, или у него синдром архитектуры, а потому что он проглядел спецификацию.

Лучше всего для специфицирования использовать ТЕСТЫ, написанные на языке программирования. Создание нового теста можно считать внесением нового требования в спеку, тз, anything.

От спецификации вреда никогда не будет, если за спецификацией следить и исправлять.