Ответ на сообщение Re: Программист. пользователя tolstopuz
несколько замечаний
> Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности.
Именно поэтому Вы использовали массив в качестве ответа, а не спец класс? Тогда для сведения, и по памяти и по процессору оба решения идентичные, а вот по качеству коду нет.
> лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации
Код должен быть слабо связанным. Для этого деление на модули (архитектура) должно быть в первую очередь сделано исходя из функциональных зависимостей и во вторую очередь исходя из технических. Только в этом случае реализация новой фишки или существенные изменения в поведении системы могут быть произведены относительно безболезненно. Сильно связанный код становится мертвым кодом, его нельзя менять, в одном месте поменяешь в другом отвалится и т.п. сложности.
Поэтому копипаст возможен, в нем гораздо меньше криминала чем в сильной связанности кода.
> лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще.
А чего тогда у Вас в коде была константа SAFE_EQUALS = 0.0001 ? Кстати в этом случае она уместна, так что правило это не годится, но в подавляющем большинстве случаев это действительно так, хотя я надеюсь не имелись ввиду захардкоженные имена событий или там ключей по которым эти значения вытаскиваются :)) Ну и в качестве придирки - это не про лаконичность.
> развернуто. В части документирования и описания созданного ПО.
Я бы хотел добавить, что код должен писаться так, чтобы он был self documenting. Потому что чтобы вы не написали в комментарии и в спецификации - работать будет код и только он, как бы это банально не звучало. Еще и поэтому важны проверки, они еще и "документируют" код. Еще и поэтому важны юнит тесты - чтобы понять как реально работать с каким то модулем - я обязательно загляну в его юнит тесты.
> Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...
Заказчику похер на религию программистов, он покупает решению, которое должно работать на текущем железе, а не на IBM-360. И PHP это далеко не ассемблер. Очнитесь, ситуация 20 летней давности неактуальна уже 20 лет.
З.Ы. доказывать не собираюсь приводя свой код, а в тему влез просто поговорить, просто увидел какой у Вас апломб, Вы весь в белом, вокруг одни копроделы, вот и захотелось разобраться так сказать
> Данные должны как можно меньше переприсваиваться и преобразовываться. Структуры, особенно временные, не должны содержать какой-либо избыточности.
Именно поэтому Вы использовали массив в качестве ответа, а не спец класс? Тогда для сведения, и по памяти и по процессору оба решения идентичные, а вот по качеству коду нет.
> лаконично. Код должен быть максимально модульным. Одно действие должно делаться в ОДНОМ месте кода. "Лишний" код - это всегда копипаст, который приводит к увеличению чтения, интерпретации
Код должен быть слабо связанным. Для этого деление на модули (архитектура) должно быть в первую очередь сделано исходя из функциональных зависимостей и во вторую очередь исходя из технических. Только в этом случае реализация новой фишки или существенные изменения в поведении системы могут быть произведены относительно безболезненно. Сильно связанный код становится мертвым кодом, его нельзя менять, в одном месте поменяешь в другом отвалится и т.п. сложности.
Поэтому копипаст возможен, в нем гораздо меньше криминала чем в сильной связанности кода.
> лаконично. Код НЕ должен содержать хардкодовых констант. По возможности, НИКАКИХ ваще.
А чего тогда у Вас в коде была константа SAFE_EQUALS = 0.0001 ? Кстати в этом случае она уместна, так что правило это не годится, но в подавляющем большинстве случаев это действительно так, хотя я надеюсь не имелись ввиду захардкоженные имена событий или там ключей по которым эти значения вытаскиваются :)) Ну и в качестве придирки - это не про лаконичность.
> развернуто. В части документирования и описания созданного ПО.
Я бы хотел добавить, что код должен писаться так, чтобы он был self documenting. Потому что чтобы вы не написали в комментарии и в спецификации - работать будет код и только он, как бы это банально не звучало. Еще и поэтому важны проверки, они еще и "документируют" код. Еще и поэтому важны юнит тесты - чтобы понять как реально работать с каким то модулем - я обязательно загляну в его юнит тесты.
> Только не надо навязывать Заказчику свою копрокодерскую религию словами "купите себе монитор пошире, жесткий диск побольше, сервер покруче" (нужное подчеркнуть)...
Заказчику похер на религию программистов, он покупает решению, которое должно работать на текущем железе, а не на IBM-360. И PHP это далеко не ассемблер. Очнитесь, ситуация 20 летней давности неактуальна уже 20 лет.
З.Ы. доказывать не собираюсь приводя свой код, а в тему влез просто поговорить, просто увидел какой у Вас апломб, Вы весь в белом, вокруг одни копроделы, вот и захотелось разобраться так сказать
