Возможно, вы имели ввиду «теоретический минимум»: sharpc.livejournal.com/67583.html
Но он не является списком литературы, хотя и содержит некоторые ссылки.
Кстати, почему для проекта в век DVCS выбрана централизованная система контроля версий?
Я бы на github залил, там люди смогут легко делать форки и отправлять правки-предложения. Cupper
Разделять можно хотя бы для того, чтобы отделить сервис от данных.
В эрланге, как мне известно, можно подменять отдельные участки кода, там же где этого нет искаропки, приходится выполнять разделение на несколько сервисов.
Да и действительно, не очень php подходит для демонов, то, что какая-то морда сделана на php не значит, что на нем надо делать все.
Зашел случайно в тред, видимо, уведомление раньше попало в спам.
Если еще актуально:
1) особой организации не было, была страничка в гитхабе у человека, который первый начал этим заниматься, были контакты, я написал и присоединился;
2) по желанию, я перевел одну главу, кто-то чуть более
3) формального ревью (с допуском) не было, я работал в своем форке, более опытные коллеги комментировали или вносили правки, далее pull request или слияние вручную
4) вроде, нет, последний этап — влить это все в официальный реп
5) — 6) очень удобно, возможно, не для всех книг такой процесс подойдет, т.к. книга свободная, как и перевод.
Разве Apple покупают исключительно для разработки? Кроме разработки им же просто пользуются, как и любыми другими ноутами/девайсами. Перешел недавно на Apple и ни разу не жалею (хоть и не пишу непосредственно под ios).
Речь ведь о заработке индивидуального разработчика?
Под остальные платформы тоже был софт, и шаровары писали, возможно только зарабатывали на этом немногие.
По мне так и то и другое хорошо — тесты для обеспечения преемственности (что новый код не ломает старый), ревью (преимущественно, конечно) — для обеспечения качества нового кода.
Кроме градации «плохо-хорошо» есть «хорошо» и «качественно»
также бывают большие проекты, в которых «команда» не владеет кодом целиком (каждый участник может с ходу поправить любой участок), а над кодом работает много команд и т.п.
Возможно, это предположение верно, если сложность решаемой задачи не растет (например, код просто «поддерживается» и нужно минимизировать ресурсы). Просто впервые слышу о том, чтобы отказывались от code review.
Code review не означает недоверия, мне кажется. Ревью применяется в серьезных компаниях без особой текучки кадров, вроде Google, просто потому что две головы всегда лучше чем одна.
А в проектах вроде софта для авионики вообще каждая строчка обосновывается документами в десятикратном размере.
Even then, you're never really sure. How do you know the formal verification process itself isn't buggy? It's turtles all the way down. I know some folks who were trying to build a formally verified OS, and they stopped using ACL2 after discovering a few bugs in it. After all, how can you trust your proof if the proof system itself has bugs? ACL2 is old and crusty, but that's precisely why it's used for more hardware FV than everything else combined, outside of Intel and IBM (both of whom have their own, excellent, internal tools). It's old enough to have great libraries. There are newer systems that have better architectures, but they don't have anything approaching the same level of library support for hardware. Yet another tradeoff of time to market vs. correctness. It can't be avoided.
Интересное замечание: если хочется избежать ошибок в программе, то можно формально ее верифицировать. Это может занять месяцы для очень простых программ (сам пробовал), однако, даже в этом случае ошибка в верификаторе или в компиляторе может все испортить.
ядро linux вполне старается поддерживать бинарную совместимость, ну и драйверы обновляются по возможности.
в большинстве проектов из классической экосистемы gnu/linux codebase не меняется так резко.
вроде он
research.microsoft.com/en-us/
да, но в московском офисе, вроде как, есть пара инженеров без в/о
Но он не является списком литературы, хотя и содержит некоторые ссылки.
В вебе часто используется гит (у нас например, в небольшой компании), ну и в крупных тоже (в Google активно используют гит).
Я бы на github залил, там люди смогут легко делать форки и отправлять правки-предложения.
Cupper
В эрланге, как мне известно, можно подменять отдельные участки кода, там же где этого нет искаропки, приходится выполнять разделение на несколько сервисов.
Да и действительно, не очень php подходит для демонов, то, что какая-то морда сделана на php не значит, что на нем надо делать все.
Если еще актуально:
1) особой организации не было, была страничка в гитхабе у человека, который первый начал этим заниматься, были контакты, я написал и присоединился;
2) по желанию, я перевел одну главу, кто-то чуть более
3) формального ревью (с допуском) не было, я работал в своем форке, более опытные коллеги комментировали или вносили правки, далее pull request или слияние вручную
4) вроде, нет, последний этап — влить это все в официальный реп
5) — 6) очень удобно, возможно, не для всех книг такой процесс подойдет, т.к. книга свободная, как и перевод.
Под остальные платформы тоже был софт, и шаровары писали, возможно только зарабатывали на этом немногие.
также бывают большие проекты, в которых «команда» не владеет кодом целиком (каждый участник может с ходу поправить любой участок), а над кодом работает много команд и т.п.
Возможно, это предположение верно, если сложность решаемой задачи не растет (например, код просто «поддерживается» и нужно минимизировать ресурсы). Просто впервые слышу о том, чтобы отказывались от code review.
А в проектах вроде софта для авионики вообще каждая строчка обосновывается документами в десятикратном размере.
Интересное замечание: если хочется избежать ошибок в программе, то можно формально ее верифицировать. Это может занять месяцы для очень простых программ (сам пробовал), однако, даже в этом случае ошибка в верификаторе или в компиляторе может все испортить.
в большинстве проектов из классической экосистемы gnu/linux codebase не меняется так резко.